Wikivoyage:Travellers' pub

Welcome to the pub

Shortcuts:
WV:Pub
WV:TP

The travellers' pub is for general discussion on Wikivoyage, and the place to ask questions when you're confused, lost, afraid, tired, annoyed, thoughtful, or helpful. To start a new topic, click the "Add topic" tab, so that it gets added at the bottom of the page, and sign your post by appending four tildes (~~~~)

Before asking a question or making a comment:

• Have a look at our Help, FAQ and Policies pages.
• If you are a new user and you have any questions about using the website, try the Arrivals lounge.
• If you have a question or suggestion about a particular article, use the article's talk page to keep the discussion associated with that article.
• If you'd like to draw attention to a comment to get feedback from other Wikivoyagers, try Requests for comment.
• If you are wanting travel advice on a specific matter see the tourist office.
• If you have an issue you need to bring to the attention of an administrator, try Ongoing vandalism.
• If you are having a problem that you think has to do with the MediaWiki software, please post that on Phabricator instead.
• If you want to celebrate a significant contribution to Wikivoyage by yourself or others, hold a party at Celebrate a contribution.
• Discuss issues related to more than one language version of Wikivoyage in the Wikivoyage Lounge on Meta.
• Anything that is Nigeria-related is now meant to go in the Nigeria café instead. Anything that is Kosovo or Albania related is now meant to go in the Kosovo and Albania café instead. This includes announcements, initiatives, celebrations, and issues with certain articles.

You can review old Pub discussions in the Wikivoyage:Travellers' pub/Archives.

Pull up a chair and join in the conversation!

Click here to start a new thread

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

In mobile view collapsing / de-collapsing doen not work in some articles. In portrait mode de-collapsing does not work. In landscape mode all sections are de-collapsed but cannot be collapsed, making scrolling though a large article time consuming. Examples: Vulcano, Panarea. FredTC (talk) 10:29, 18 August 2026 (UTC)Reply

Has it always been like that, or is this a new behavior? WhatamIdoing (talk) 16:23, 18 August 2026 (UTC)Reply

+1 – I thought it was always like that. //shb (t | c | m) 21:21, 18 August 2026 (UTC)Reply

It happens with some articles, but not all articles. Example: Luang Prabang is OK. FredTC (talk) 06:26, 19 August 2026 (UTC)Reply

When I switch to mobile view on my laptop, I cannot collapse chapters in the above mentioned Vulcano and Panarea, but collapsing Luang Prabang is done correct. FredTC (talk) 13:55, 25 August 2026 (UTC)Reply

Now, over a month later, the problem still exists. Nothing has changed. FredTC (talk) 11:26, 29 September 2026 (UTC)Reply

I think you should file a Phabricator task; I don't think most people are technically skilled enough to replicate the issue, let alone fix it. //shb (t | c | m) 11:32, 29 September 2026 (UTC)Reply

I created phab:T439558 for the problem. FredTC (talk) 12:24, 30 September 2026 (UTC)Reply

The task was closed with: "Aklapper closed this task as Invalid". Aklapper could not reproduce the problem. So, I tried to do the actions that have the problem in a not-logged-in situation, and ... there was no problem. I started looking at my "preferences" and after changing the "Use the new Parsoid wikitext parser" setting from "Never (opt-out)" to "According to wiki configuration (default)", the problem had gone. However I changed this setting after a discussion about a probem I had earlier this year. And why should I have the setting I have now??? I am not a developper, but an contributing editor; so, I don't need "Developer tools" and the setting should be "Never (opt-out)". FredTC (talk) 05:03, 10 October 2026 (UTC)Reply

Pinging @AKlapper (WMF) and CAnanian (WMF) aka cscott, who knows about all things Parsoid.

I would not take the "developer" label at Special:Preferences#mw-prefsection-editing-developertools too literally. WhatamIdoing (talk) 17:01, 10 October 2026 (UTC)Reply

Still, users should not be assumed to enable settings in the developers section. Here, there was a change from the default – but fixing an issue shouldn't require your touching developer/advanced settings (although all too common advice for many kinds of computer/smartphone problems). –LPfi (talk) 17:58, 10 October 2026 (UTC)Reply

In about 4 weeks' time, I will be co-judging the conference's editing challenge. Specifically for Wikivoyage, participants will be asked to update any page in Alberta since the conference will take place in Edmonton. Peak editing will take place between September 24-26. Based on the same contest from past 2 years, I'm expecting 10-15 editors to participate (though there might be more this year because we will be awarding physical prizes to top 3 at the end of the conference). Please ping me for any problematic edits you observed so that I can discount their score. OhanaUnited^{Talk page} 04:27, 19 August 2026 (UTC)Reply

Sounds like a great initiative! Looking forward to the results. //shb (t | c | m) 04:59, 19 August 2026 (UTC)Reply

@OhanaUnited: curious to hear how this ended up going. //shb (t | c | m) 07:00, 28 September 2026 (UTC)Reply

People are still submitting their results as we speak. I gave them an extra day to enter as some have already started flying this morning. Please see T7 in the table for the results so far. I think many focused exclusively on Edmonton, with a few focusing on other Alberta pages. OhanaUnited^{Talk page} 07:18, 28 September 2026 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I do want to quickly flag that my talk to introduce new Wikivoyage tools and initiatives in the past year (travel forum, travel map, trip planner) was rejected even though I correctly filed my proposal under the "underrepresented communities" track. I was able to slide my talk in through the Unconference session but obviously with a much smaller audience. During today's discussion, conference attendees mentioned that attention and talks continue to be dominated by the "big 3" (Wikipedia, Commons, Wikidata) while other projects receive little attention. Attendees want to see more diversity in presentations from projects like Wikibooks and Wikisource. In the conference feedback session, I voiced that there is a mismatch between what attendees want to hear from other projects and what the conference's programs committee thinks are the most suitable talks. OhanaUnited^{Talk page} 07:33, 28 September 2026 (UTC)Reply

That's a bummer; still really appreciated that you tried to give this site more of a voice, though. :) //shb (t | c | m) 07:40, 28 September 2026 (UTC)Reply

I wonder whether "Underrepresented communities" was meant to communicate something like "presenters from a historically disadvantaged demographic group" instead of "about a smaller wiki". WhatamIdoing (talk) 13:28, 28 September 2026 (UTC)Reply

I don't believe "underrepresented communities" was ever defined even though it has been an option for tracks since 2023 (and possibly earlier). Of course this term covers things like Indigenous communities, visible minorities, LGBTQ2+, women, disability groups and others. But if we examine it from a project-to-project perspective, Wikivoyage is an underrepresented community and our voices are often drowned out by the big 3. While English Wikipedia struggles with declining pageviews, we here at English Wikivoyage is getting nearly 200% increase in pageviews year-over-year. So we collectively must be doing something right. I'll be happy if the program committee thinks that Wikivoyage is no longer a small wiki or underrepresented project, but we know we're far from reaching the level and status of the big 3. OhanaUnited^{Talk page} 03:18, 1 October 2026 (UTC)Reply

Looking at the stats how is Seychelles generating 3 million pageviews if it is not some sort of bot operation for AI? I know travel data is in especially high demand for AI firms so that would seem to make sense...Superb Owl (talk) 04:49, 1 October 2026 (UTC)Reply

Looking at this page, it seems the top countries remain the US, India, Brazil and the Philippines in that order? Or am I looking at the wrong page. //shb (t | c | m) 04:54, 1 October 2026 (UTC)Reply

That's the right page and it no longer lists Seychelles at that link - weird Superb Owl (talk) 15:57, 1 October 2026 (UTC)Reply

It's not just you. On today it's showing US, Seychelles, Brazil and India. But we have far less content pages than Wikipedia to crawl. Not sure what kind of travel data AI bots are interested in. (Casual, conversational tone? Reddit has a bigger and more diverse pool. Travel specific? Bots could crawl Tripadvisor's forum) OhanaUnited^{Talk page} 18:55, 2 October 2026 (UTC)Reply

The head of enterprise partnerships for the Wikimedia foundation mentioned this spring that AI companies were especially interested in Wikivoyage when he mentioned it to them (and that many did not know about it at the time). I am guessing that Wikimedia foundation might not be looking as closely at Wikivoyage statistics to try and differentiate between bot and human traffic as it does with Wikipedia? Superb Owl (talk) 05:01, 3 October 2026 (UTC)Reply

I believe that it's the same system processing all the page views. WhatamIdoing (talk) 23:14, 3 October 2026 (UTC)Reply

I've started compiling evidence showing that the growth in traffic since the end of 2024 seems entirely driven by undetected AI/bots + submitted a bug report Superb Owl (talk) 05:03, 9 October 2026 (UTC)Reply

This could be something interesting to present as a talk at next year's WCNA (if you are based in North America). OhanaUnited^{Talk page} 04:33, 13 October 2026 (UTC)Reply

Gladly and this forthcoming article in the Signpost explains in lots of detail much of what is surfaced on the Phabricator ticket (he adds that we should only use Mobile data when looking for pageview trends since most bots access/scrape the site via a desktop) Superb Owl (talk) 02:15, 14 October 2026 (UTC)Reply

Ohana, I see the logic, but if the people choosing sessions for that track have a different POV, then they're not going to choose a session that doesn't align with their POV. WhatamIdoing (talk) 12:41, 1 October 2026 (UTC)Reply

Here's the final results: 15 editors edited Wikivoyage pages as part of the contest. They focus heavily towards Edmonton and its district pages (probably because many said this was the first time they were in Edmonton), though there were some edits that were outside the city. One new page, Coutts, was created during the event and needs expansion. OhanaUnited^{Talk page} 14:44, 14 October 2026 (UTC)Reply

One of my favourite userspace pages has to be User:DaGizza/Articles by country by DaGizza. Not only does that show which countries have had the most progress in terms of coverage on this site, but also which areas lack the most coverage. I had quite some spare time today, so I've decided to put all of it into a map. Should go without saying that numbers are never the whole story; some countries will be dark red because they're genuinely not large in size, and that's not necessarily a bad thing. //shb (t | c | m) 04:18, 4 September 2026 (UTC)Reply

Thanks for making the map. I've wanted to create more tables which show the breakdown of the larger countries by state/province but I've never gotten around to do it. There is a skew and bias within countries as well. Gizza ^(roam) 05:44, 4 September 2026 (UTC)Reply

I love Gizza's table and now your map. Just a heads-up. There's a new tool on toolforge called Maphue (https://maphue.toolforge.org/) that everyone can use to create map in editable SVG. In case you're busy in the future and someone wants to update your map (or the visa entry requirement maps), they can directly edit the file without having to completely recreate the map from scratch. OhanaUnited^{Talk page} 06:27, 4 September 2026 (UTC)Reply

Ooh, thanks for that – will bookmark that tool. //shb (t | c | m) 06:54, 4 September 2026 (UTC)Reply

eugh...annoyingly that gadget has no Kosovo option :( (XK also doesn't appear as an ISO dropdown) //shb (t | c | m) 13:29, 4 September 2026 (UTC)Reply

No problem. This tool was created right after Wikimania (i.e. late July) so not a lot of people are aware of it, especially if you're not on the Wikimania Telegram chat. It still miss some functionalities like you can only map worldwide, Europe and Africa (no other continents). It's not the tool maker's fault though, since those maps are not properly done (SVG wise) and don't carry the country level data to allow for the picker to work. OhanaUnited^{Talk page} 16:34, 6 September 2026 (UTC)Reply

Well, one way of dealing with the size discrepancy is to use a ratio: the number of articles to area, population, or number of urban settlements. Daggerstab (talk) 11:38, 4 September 2026 (UTC)Reply

Ideally yes. But I unfortunately don't have the skills to execute an SQL query that fetches all of those from Wikidata and also the number of articles breadcrumbed to a country. //shb (t | c | m) 12:23, 4 September 2026 (UTC)Reply

Do you just need a query? You could ask an AI to build one for you (preferably one connected to the internet so it can read the docs). Brycehughes (talk) 07:23, 5 September 2026 (UTC)Reply

More or less I don't actually know how to do a multiwiki query on Quarry. But seems Andree got the job done anyway :P //shb (t | c | m) 08:07, 5 September 2026 (UTC)Reply

Fine, you beat me to it! It was fun vibecoding this :D

Here is some graphics of distributions (yellow=less, blue=more) - total number of articles, #articles/country size, #articles/population, #articles/WP country article views:

total:

size:

population:

views:

I can provide CSVs (or the script) that work for maphue.com if someone wants it... maphue.toolsforge requires manually entering csv per category, it seems, not really convenient :-/

-- andree 07:36, 5 September 2026 (UTC)Reply

oh this is good...I love these. //shb (t | c | m) 08:05, 5 September 2026 (UTC)Reply

@Andree.sk: Any reason why Greenland, Faroe Islands, Denmark, New Caledonia, French Polynesia, Falkland Islands and Puerto Rico are grey (no data)? Also, we need legends in the file description! OhanaUnited^{Talk page} 16:41, 6 September 2026 (UTC)Reply

no idea, honestly... It was a one-shot test, but if you think it would be useful, I can try to setup some repeating thingie on toolforge, and check what's up with the above... We can also compare with de:, fr: and others :) -- andree 16:44, 6 September 2026 (UTC)Reply

Thanks for the further maps Andree. Other ratios which I think would be interesting are pages per GDP, total tourist arrivals and tourism revenue. Also because this is English Wikivoyage, pages per total number of English speakers. Gizza ^(roam) 00:38, 7 September 2026 (UTC)Reply

Something else I can't help but notice, at least for Europe, is that the countries that speak a less spoken language seem to have more coverage per population (Czechia, Slovakia, Hungary, Slovenia, Croatia, Montenegro, Albania, NMK, Greece, Finland). It has correlated directly with my real-life experience using English in Northern/Central Europe over Western Europe, though. //shb (t | c | m) 00:42, 10 September 2026 (UTC)Reply

I assume that developed/populous European countries have branches of Wikivoyage in their own language, so most of the locals willing to contribute to Wikivoyage do it in the respective branch rather than English (and translating requires more work). The same phenomenon explains the thick coverage of native English speaking countries and India. Daggerstab (talk) 05:55, 10 September 2026 (UTC)Reply

That does explain. //shb (t | c | m) 07:06, 13 September 2026 (UTC)Reply

@SHB, what does NMK stand for? Northern Macedonia (Makedonia or something like that in their language, I guess)? Ikan Kekek (talk) 13:04, 13 September 2026 (UTC)Reply

Yep, it's North Macedonia, specifically the code found on North Macedonian license plates (sorry I realise that's pretty obscure come to think of it – I got a bit too lazy). //shb (t | c | m) 13:08, 13 September 2026 (UTC)Reply

@Andree.sk (or anyone who is interested): Would you like to write up something like this for https://diff.wikimedia.org/about/#can-i-publish ? It doesn't have to be long or complicated, but I think more people would be interested in this than are likely to see this page. WhatamIdoing (talk) 06:18, 13 September 2026 (UTC)Reply

@WhatamIdoing, I'm not sure what diff does and what information/write up would they welcome :) Could you describe a bit further what you have in mind? ~2026-50209-42 (talk) 18:51, 15 September 2026 (UTC)Reply

Diff is a blog to talk about Wikimedia movement broadly. Any editor can contribute to this blog. I support writing in diff to promote our project. But make sure to fix the map before publishing the diff story or this becomes another map with "no data available for Greenland". OhanaUnited^{Talk page} 19:12, 15 September 2026 (UTC)Reply

Diff seems to like posts whose main point is "Look at the cool thing we did". Since a lot of them are either from the WMF or from Wikipedia editors/event organizers, it's always good to have something from Wikivoyage.

Any community member is welcome to submit something. It doesn't have to be of Earth-shattering importance, and it doesn't have to be complex. A couple of maps and a few paragraphs to explain them would be perfect. (You can sign the blog posts either with your username or your real-world name, in case that matters to you/anyone who wants to write something for them.) WhatamIdoing (talk) 23:17, 15 September 2026 (UTC)Reply

Hey, maintainer here. I did CSV as it’s the most versatile but tell me what you need I will be more than happy to look into it and make it happen :) Schiste (talk) 17:57, 22 September 2026 (UTC)Reply

Oh well, I implemented a quick update :

• Import country,category rows in one pass. The app detects the columns, previews the colors on the map, and groups assignments by legend category.
• The preview flags unrecognized countries, unmatched categories, and conflicting duplicate assignments. Repeated identical rows are merged; unlisted countries keep their current colors.
• Kosovo is recognized by name, XK, and XKX. Category values must match existing legend labels.
• The old single-category country-list import still works.

I'm not sure it's what you needed exactly, but that's what this discussion inspired me to do. As for the maps, I'm not an SVG pro, but I'm asking around to find someone to help create some more. Especially continental ones. Schiste (talk) 21:10, 22 September 2026 (UTC)Reply

@Schiste: Many thanks for the fixes! :) //shb (t | c | m) 22:23, 22 September 2026 (UTC)Reply

Thanks are my fuel, I made a blank SVG map generator to fix the issue of missing maps structure. I started a discussion on Commons to redo all SVG maps. If the topic interests you : the discussion I started on Commons. The question I also have is either to make it a standalone tool, bake it into maphue or to keep it as a CLI and just redo all maps. Would love to hear what would you think would be best :) Schiste (talk) 06:38, 23 September 2026 (UTC)Reply

And I feel like spamming (and if anyone was wondering yes I am AuDHD and this me at my worse ːD). But since this morning, I also made it an online tool https://map-generator.toolforge.org/ and it's now connected to https://maphue.toolforge.org/. Basically you should be able to generate custom maps. There are few features missing, but I like to share early to have real users feedbacks. Oh and I needed to make an API and I guess it means you could even automate things probably ː) Schiste (talk) 14:55, 23 September 2026 (UTC)Reply

I don't understand the CSV format... Could you put there some example, how to e.g. color a few countries with one color/label, and others with other? So far I only see the option to pick a few countries to highlight them? -- andree 18:54, 24 September 2026 (UTC)Reply

Was going to say standalone tool, but this is great. Going to bookmark those urls. //shb (t | c | m) 23:25, 23 September 2026 (UTC)Reply

@SHB: I had forgotten about it but I found a similar table I started specifically for Australian states and territories in 2018. I've updated as of Sep 2026. Here's the link. My first thoughts are that WA probably has scope for growth, considering it has less articles than SA and both states are centred around one city and otherwise mostly outback but WA still has a larger population and area overall. I haven't done anything like this for any other country as yet though. Gizza ^(roam) 07:08, 28 September 2026 (UTC)Reply

Thanks for that table – something else that also sticks out to me is how few articles there are for Victoria. It has ten times the population of Tasmania only 1.6x as many articles (I think it comes down to fewer park articles). //shb (t | c | m) 07:33, 28 September 2026 (UTC)Reply

After ~10 years of improving South Korean town articles, it seems we are actually reaching the end of the road with my students in this topic area, at least for the quality level that they are capable off (i.e. it seems we are running out of missing or stub-level articles on Korean towns). I compiled a list of the last few low hanging fruits at w:User:Piotrus/Ideas_for_students#Wikivoyage_suggestions, and it seems we are now going to be working on the county and province level articles (for Korea; for China there is still lots of room for improvement at that level).

This leads me to a practical question - how to find lists of low and missing articles by topic (ex. lists of all low-level county articles in Korea, etc.). Also, I would like to be able to point to students the best examples in a given topic area. What we have (or at least, what I was able to find) is pretty inadequate for my purposes and, honestly, hard to find (AFAIK Wikivoyage lacks article category structure as well as region-dedicated WikiProjects, with their assessment matrixes, which I rely on on Wikipedia). What I found at Wikivoyage is:

• Star articles - but the entries are divided by country, not by level (Town/county/province). I see no other pages presenting content of star articles organized in a different way, nor comparable pages for other quality levels
• categories like Category:Guide articles, but they provide no subcategories for regions, and there seem to be no category for stub articles at all (there is none at Category:Article status), which means there is no way for me to tell students "here are low quality Korea articles for you to work on"

Is there anything, any useful tool I am missing? I relied on ChatGPT to generate a list of topic suggestions for the above list at my Piotrus page, sigh.

What I'd like to do is to get a list of highest and lowest (and missing) quality level articles related to Korea, as well as highest level examples outside Korea for province/country and such topics, so I can tell students - this is what you can work on, and this is how it should look like.

Barring any large fixes (tools I am missing), I'd appreciate if experienced Wikivoyagers could tell me what you think are the best examples of Korea topics by category (town, county, province, general topic), what are best examples of such content overall, and if there is a list of low quality Korean topics that I can direct the students who have no idea what to work on. Any suggestions on how to do it (other than ask ChatGPT for suggestions) is much appreciated :)

Hanyangprofessor2 (talk) 01:40, 16 September 2026 (UTC)Reply

From the top search bar, under "Advanced Search", you can combine multiple Categories in a query. For example, here's a search combining "South Korea" and "Outline articles". It appears to work for nested subcategories. Gerode (talk) 02:54, 16 September 2026 (UTC)Reply

Petscan is quite a handy tool. It's the main tool I used to create and update the table of the number of articles existing for each country. And you can search for multiple categories at one time. There are e.g. 11 articles on guide cities in South Korea. They would be the benchmark for other cities to follow. FWIW, as of May 2026, South Korea had less destination articles than Hungary and Portugal, countries with slightly smaller areas and significantly smaller populations and economies. Portugal receives more international tourists than South Korea but Hungary receives less. So there probably is scope for expanding South Korea somewhere.

If you feel that destinations have almost been fully covered, you can consider getting your students to work on travel topics. There are only 4 dedicated travel topics on South Korea/Korea generally at the moment: Korean palaces, Korean War, Pre-modern Korea and Rail travel in South Korea. For comparison, there are 32 travel topics related to Japan. Our lack of coverage of K-pop and K-drama are big omissions. Likewise with itineraries. As far as I can tell, we have no South Korea-specific itineraries. Gizza ^(roam) 03:53, 16 September 2026 (UTC)Reply

I stand partially corrected. K-pop exists, but it was not categorised/breadcrumbed correctly so I couldn't find it. And there is one Korean itinerary Gwandong Palgyeong. Gizza ^(roam) 05:06, 17 September 2026 (UTC)Reply

From what I've seen, it's quite random. We have articles like Haman County, and others like Muan. It may be a good idea to make a rule and move all articles one way or another. I think on en wiki, all counties are called as such. (So on en wiki, Muan is under Muan County). I am not sure how to get an exact list of affected articles, but this search may help: https://en.wikivoyage.org/w/index.php?limit=250&advancedSearch-current=%7B%22fields%22%3A%7B%22deepcategory%22%3A%5B%22South+Korea%22%5D%7D%7D&fulltext=1&ns0=1&profile=advanced&search=county+deepcat%3A%22South+Korea%22&title=Special%3ASearch&searchToken=5a1tjvw8qxh0jv59rqmga5yrt (it does, unfortunately, pick up higher level articles that just mention the word county). Hanyangprofessor2 (talk) 03:32, 16 September 2026 (UTC)Reply

There are 11 South Korean articles that include the word "County" in their title (Ctrl + F "county"). It would easier to remove the word from all of these articles than to add it where it's missing, which will require more manual work. But it should be doable either way. Gizza ^(roam) 03:58, 16 September 2026 (UTC)Reply

See Wikivoyage:Naming conventions STW932 (talk) 04:50, 16 September 2026 (UTC)Reply

@STW932 My reading of it suggests we should remove the county from the name unless it is needed for a disambig (and then it should be in parenthesis)? Hanyangprofessor2 (talk) 05:04, 17 September 2026 (UTC)Reply

That's my reading of it too, but I'm not particularly familiar with Korean counties. If this discussion were about Chinese counties, however, I would say we need to make an exception for counties with one-syllable names - e.g. Yi County, Shou Country, etc. In those cases, the word 'County' is an inseparable part of the name. STW932 (talk) 12:03, 17 September 2026 (UTC)Reply

Wikipedia name (usage of County) stem from w:Wikipedia:Naming_conventions_(Korean)#Counties which explicitly states "replace "-gun" and "-kun" with "County"". I am honestly sure why they have this recommendation, however. Hanyangprofessor2 (talk) 05:07, 17 September 2026 (UTC)Reply

I don't have an opinion about this but do want to make the point that "County" is part of the names of counties in the U.S. that are covered by articles, not a disambiguation in many cases. Ikan Kekek (talk) 14:01, 17 September 2026 (UTC)Reply

I see. I also asked about this here if anyone wants to look into this further https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Korea#Inconsisenty_in_Wikipedia:Naming_conventions_(Korean) Hanyangprofessor2 (talk) 07:49, 18 September 2026 (UTC)Reply

@DaGizza @Ikan Kekek @STW932 Since I keep running into problems such as students not finding an article because it is under "X county" and trying to create a new article, resulting in merge needed (see Cheongdo) or just time wasted, I'd like to get consensus here for fixing this one way or another. For example, if we prefer no County unless a disambig is needed, can I move Okcheon County to Okcheon and do it for all similar Korean entries (remove County)? Just a moment ago a student told me that they want to work on Okcheon, sigh. Hanyangprofessor2 (talk) 09:07, 29 September 2026 (UTC)Reply

I don't really understand how your students are searching for articles. If you type the name into the search bar, the county name will appear. Ikan Kekek (talk) 11:44, 29 September 2026 (UTC)Reply

Anyway, I have no expertise on whether "County" should be used or not, so don't look to me to resolve the issue. Ikan Kekek (talk) 11:45, 29 September 2026 (UTC)Reply

You should not assume all students are digitally literate. We have students who never used PC before going to university ("smart"phone generation, sigh). Hanyangprofessor2 (talk) 01:52, 2 October 2026 (UTC)Reply

They don't search for anything with their phones? Ikan Kekek (talk) 01:58, 2 October 2026 (UTC)Reply

Some do, some don't... some sadly rely on AI and add hallucinations (despite an entire module we had dedicated to teacing them it is bad idea, and not allowed). Side note: these days I wouldn't trust any listing added that doesn't have a URL or Wikidata link. All the listings my students are adding should have at least one of these entries, and I think it should be a project-wide requirement. Hanyangprofessor2 (talk) 04:25, 2 October 2026 (UTC)Reply

Well, you might require your students to use the search bar to check on whether a place already has an article covering it. But not every worthwhile place has its own URL or Wikidata entry. Ikan Kekek (talk) 05:27, 2 October 2026 (UTC)Reply

I suggest that you also allow listings that have links to images on Commons. This saves the students from creating Wikidata pages for every minor statue, place to wild camp etc that they want to list. AlasdairW (talk) 09:47, 2 October 2026 (UTC)Reply

Although there are probably a lot of campsites and well-used wild camping sites with no images on Commons (nor Wikidata entries)… –LPfi (talk) 14:35, 4 October 2026 (UTC)Reply

@AlasdairW I am not sure how this is related to what we are discussing here? My students have not yet begun the Wikidata module, and in general, I don't recall them ever creating Wikidata pages for such items. That said, in general, if something has a listing, it should have a Wikidata page, I can think of almost no reasonable exceptions... Hanyangprofessor2 (talk) 02:59, 5 October 2026 (UTC)Reply

Among eat, drink and sleep listings, I believe only famous or historically significant ones should have Wikidata entries. On the other hand, for off-the-beaten path locations, we often list the local hamburger restaurant or kebab-pizzeria, which would typically never have a Wikipedia article. If Wikidata entries are created for the latter, it's purely for Wikivoyage purposes (there are a number of lean-to pages on Wikidata, to offload hiking itineraries). –LPfi (talk) 08:46, 5 October 2026 (UTC)Reply

Tried in Firefox and Chrome. Nothing happens when I click add listing; nothing prints to the console. Brycehughes (talk) 03:41, 16 September 2026 (UTC)Reply

Ok the site seems to be having bigger issues. Maybe the listing editor was the canary who died to warn the rest of us. I should have been more respectful of its sacrifice. Brycehughes (talk) 06:50, 16 September 2026 (UTC)Reply

It looks like it worked for you yesterday. WhatamIdoing (talk) 18:32, 16 September 2026 (UTC)Reply

Alas, no more. I blame entropy. Brycehughes (talk) 23:06, 16 September 2026 (UTC)Reply

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

(Apologies for posting in English. You can help by translating it)

Hello, I’m Danny from Wikimedia Deutschland’s Wikidata For Wikimedia Projects team.
We have been investigating and examining how Wikidata’s use in the Special:RecentChanges and Special:Watchlist pages can be made to be more useful, or less ‘noisy’ (fewer edits that have little value to the reader).

We are currently exploring to make a change in the volume and the type of Wikidata edits that appear in these pages, and we need your feedback to help us ensure this is a positive change for the Wikis and won’t disrupt your workflows.
Language links are also known as sitelinks or interlanguage links and describe when a Wikidata item is connected to a Wiki, adding it to the language dropdown tool for other connected Wikis.

The request for feedback is whether you support the removal of these language link edits from the Recent Changes and Watchlist feed, or would you oppose such a change and if so, why? Please share you thoughts on the dedicated metawiki Talk page.

Further information about this change: m:Wikidata_For_Wikimedia_Projects/Hide_Language_Link_edits

Thank you for any participation or feedback you give, -- User:Danny Benjafield (WMDE) 12:23, 25 September 2026 (UTC)Reply

We are now ~2 weeks past the dealine for my students to choose their topics. As usual, there are a few stragglers, and extra credit topics will be chosen much later (in December usually), but here is the main list of articles I encourage regulars here to watchlist - any major edits there are likely be my students (see also discussions above if needed): Benxi, Bogildo, Cheongdo County, Cheongpyeong, Cheongyang, Daqing, Donghae, Dongyang, Dunhua, Gokseong, Goryeong, Gwangyang, Hanam, Hongcheon, Huangshi, Huatugou, Heijing, Hunchun, Imsil, Jianshui, Jiaozuo, Jeongeup, Liaocheng, Liupanshui, Longyou County, Mantes-la-Jolie, Mianyang, Namhae, Namwon, Osan, Qingchengshan-Dujiangyan National Park, Renqiu, Taean County/Taean, Uiseong, Xuancheng, Yanggu, Yangsan, Yeongcheon, Yeongdeungpo-Guro, Yinan, Yiwu, Yuyao, Yuzhong, Zhaoqing, Zhoushan. I will try to update this list when/if students tell me any other topics. If you spot any problems (such as unapproved districts), please let me know. Hanyangprofessor2 (talk) 04:19, 27 September 2026 (UTC)Reply

Looks like some on EN WP are wanting to remove airport destinations. I find this very useful for travel planning. Wondering if we should accept it here?[1] Travel Doc James (talk · contribs · email) 16:18, 27 September 2026 (UTC)Reply

Yes, we should definitely list airport destinations on Wikivoyage. However, I think it should be limited to regular flights, and I'm open to prose, list and tabular ways to list them. Sbb1413 (he) (talk • contribs) 17:00, 27 September 2026 (UTC)Reply

That discussion is awful! But anyway...destinations are what we do here. The only problem is that we've tended to avoid trying to give exhaustive lists of destinations because we lack the huge complement of editors Wikimedia has and therefore don't believe we can keep them current. But in principle, we should take them on and rephrase them as originating airports, keeping in mind that we emphasize "Get in" in destination articles and normally wouldn't want "Go next" to be a list of airports, except maybe in some huge airport articles. Ikan Kekek (talk) 17:10, 27 September 2026 (UTC)Reply

I agree. That's why I suggest to avoid listing charter flights in airports unless they have a sense of regularity (like during Hajj), so that we can focus on the mundane ones. I might also suggest listing destinations by continent/region instead of by airline to avoid duplicating them per airline. Sbb1413 (he) (talk • contribs) 17:22, 27 September 2026 (UTC)Reply

The last major discussion here was a few years ago, and if memory serves, we decided against having comprehensive lists because we don't have enough folks to maintain them. Also, we only have 106 airport articles, and I believe there's something like 4,000 airports with scheduled passenger service in the world. We cannot replicate that information without significant changes to Wikivoyage:What is an article? WhatamIdoing (talk) 17:43, 27 September 2026 (UTC)Reply

I use Flight Connections in case it helps. Brycehughes (talk) 00:54, 28 September 2026 (UTC)Reply

Late, but I also religiously use that website. Especially when I'm bored in uni lectures. //shb (t | c | m) 08:09, 2 October 2026 (UTC)Reply

Thank you for this link. I'm currently using it for airline destinations at flying to India. Sbb1413 (he) (talk • contribs) 08:41, 2 October 2026 (UTC)Reply

Again?! WhatamIdoing (talk) 17:37, 27 September 2026 (UTC)Reply

We might be able to recruit the editors working on this material along with the material itself... I sort of like the tables of destinations by airline that EN WP includes. Travel Doc James (talk · contribs · email) 17:41, 27 September 2026 (UTC)Reply

Would you like to reach out to them and see if they'd like to maintain the material here? I think we should be flexible on WV:WIAA, if the alternative is to lose information that's useful to travelers. Ikan Kekek (talk) 18:32, 27 September 2026 (UTC)Reply

See Wikivoyage:Airport Expedition for our current criteria on airport articles. Would these allow accepting the material under discussion? My guess is no, so we may need discussion on whether & how to change the criteria. Pashley (talk) 18:40, 27 September 2026 (UTC)Reply

I think we don't need to create scores of airport articles just to list destinations, and I think it's perfectly fine to list them in (say) Kolkata#By plane or Hyderabad#By plane where there's at least one airport listing without an article. I have come across many city articles in India where various rail services are listed in bullets or tables, and I have also added some of them in bullets. Sbb1413 (he) (talk • contribs) 19:00, 27 September 2026 (UTC)Reply

Agreed, that could be a good solution. Ikan Kekek (talk) 19:25, 27 September 2026 (UTC)Reply

Yes, expecially if the number of flights / destinations is small these could go in the location articles. And would only need separate articles on the airports themselves when those are large. I have reached out to one of the folks involved and suggested this as a solution on EN WP. Travel Doc James (talk · contribs · email) 19:37, 27 September 2026 (UTC)Reply

I cautiously support the transfer of destination lists from Wikipedia to the airport articles or "Get in#By plane" section of Wikivoyage. If some Wikipedians migrate and help maintain the currency and accuracy of the information, even better. We don't have to do it for all 4,000 or so airports with scheduled commercial passenger flights. Maybe start with 100 or 200 major airports and see how it goes. Gizza ^(roam) 02:42, 28 September 2026 (UTC)Reply

Seconded Gizza. //shb (t | c | m) 23:18, 28 September 2026 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Having been an active editor on airport destination articles on en.wp, we need to think about how we incorporate airport destination content into Wikivoyage without using references. In my opinion, the most ideal place to store & update airport destination information is Wikidata, which then can be passed on to any opting Wikipedias and Wikivoyages. This will ensure that all languages are using up-to-date information rather than having different versions maintained by different language editors. OhanaUnited^{Talk page} 04:19, 12 October 2026 (UTC)Reply

I agree with centralizing information to Wikidata. Sbb1413 (he) (talk • contribs) 05:08, 12 October 2026 (UTC)Reply

Excellent idea. Travel Doc James (talk · contribs · email) 18:28, 12 October 2026 (UTC)Reply

Above (22 August 18:01) WhatamIdoing asked "We have an edit notice that pre-fills the outline. Are people using that? Could we make it easier to discover (e.g., mention in Welcome pages)?"

Although I know that the templates are there in the new page edit form, I often have to use a few more seconds to find them, because the links are black, not blue.

Links that do not look like links are easily missed, at least by people like me (I have sometimes asked for help, not finding how to proceed on a form where the "next" link was a big red box, as I subconsciously dismissed it as an advertisement or disclaimer). Here, to see that they indeed are links, one has to move the pointer to them – nothing in their appearance hints at it.

I find this bad design, although I understand that the intention is to have them stand out from the links to guidelines (or is the intention to highlight the guideline links?). There is the text "please click on one of the following links", but who reads instructions? Today's net overwhelms you with all kind of content demanding attention. The most important skill is to be able to ignore anything but the thing you are there for, in this case, start editing.

Five short paragraphs is not that much, but why read it at all? (If you say, "of course you should", then ask yourself how many you think have read the Terms of use (at many sites actually containing quite odd demands) – indeed, have you noticed the link to them at that page?

–LPfi (talk) 11:25, 28 September 2026 (UTC)Reply

The relevant/lower part edit notice says:

To start, please click on one of the following links to pre-fill this article with the standard sections:

City/town • City district • Rural area • Region • National/regional park • Phrasebook • Huge airport • Huge station • Dive site • Itinerary • Event • Topic article • Disambiguation • Redirect

But as LPfi says, those links are text-black instead of link-blue. I also think that's strange. Could we change the color? WhatamIdoing (talk) 13:19, 28 September 2026 (UTC)Reply

Bump. Does anyone how a preference for the text-like links or can we go forward changing the text? Does anyone know what page to edit (or how to easily find it)? –LPfi (talk) 14:41, 4 October 2026 (UTC)Reply

I like where you're going with this. I propose going even further, as I doubt simply bluelinking the templates will have a dramatic effect. What if we arranged the template links as a vertical list of buttons, so they took up more visual space and added a bit of friction before the freeform text box below? This quick mockup needs a lot more polish, but makes those links even harder to ignore.

You've followed a link to a page that doesn't exist yet. (...)

To start, please click on one of the following links to pre-fill this article with the standard sections:

• City/town
• City district
• Rural area

Please do not create new articles for hotels, restaurants or attractions; list those in existing destination articles instead.

As for how to do this, this was as far as I got. I can't tell if we're using this or not.

Gerode (talk) 15:31, 4 October 2026 (UTC)Reply

Yes, the links are using the preload. Don't worry about the URLs; they're correct. The only thing that needs to be changed is the styling.

I can't find the text of the edit notice, so I'm not sure what page we need to edit to change this. WhatamIdoing (talk) 16:30, 4 October 2026 (UTC)Reply

I would also change the text referring to a pile of guidelines. Which ones do we actually want a newcomer to read instead of just starting the article – among those newcomers who would actually read them? If they are there to tell a newcomer that we actually have rules, what's the ratio of the right and wrong people scared away or made more careful?

I think enough of that text should stay to allow a hesitating newcomer to get to the guideline they need, but at least without bold text.

–LPfi (talk) 20:05, 4 October 2026 (UTC)Reply

Salut! I've just added a map to Narrow Road to the Deep North, which is an itinerary with numbered stages. Some of the stages aren't on the map, which is causing the map-numbers and the itinerary-numbers to desync. Is there a way to force the map pins to display a specific number? The only solution I've found is to duplicate entries, which seems prone to mistakes. Strawbreevee (talk) 16:54, 28 September 2026 (UTC)Reply

You can force the numbering to restart at 1, by using the counter= parameter, but I don't know a way to get markers to miss out numbers. See Roman Empire for an example of an article using counter=. AlasdairW (talk) 22:14, 28 September 2026 (UTC)Reply

Can you put everything on the map? The {{marker}} template can be used to add a number in an ordinary paragraph. WhatamIdoing (talk) 16:55, 30 September 2026 (UTC)Reply

Wondering if folks have improvements to maps they wish to see here? We (Wiki Project Med) are bringing on a programmer who is part time at OSM to help us improve maps within the Wikimedia World.

One thing we are thinking to look at is bringing topographical overlays locally so they can appear as default in certain articles. Rather than needing to use third party overlays for this. Travel Doc James (talk · contribs · email) 01:10, 29 September 2026 (UTC)Reply

That would be very nice, at least for park articles. For them, also other terrain features, such as marshes and woods, would be welcome. In most cases, the current maps contain little of interest when on the trail (no chance even finding places I want to add markers for). Hills are relevant also when visiting hilly towns, especially if you aren't that fit.

Another problem I have is when writing about places without big roads. I have to zoom in very close to see the actual roads of the area. For an example, see the map in the Savukoski article – yes, most of those markers are indeed accessible by road.

–LPfi (talk) 08:42, 29 September 2026 (UTC)Reply

Well, as above it'd be quite nice to be able to force map pins to display specific numbers. Being able to use letters or symbols might be nice for things like airport terminals, or split paths. Strawbreevee (talk) 09:04, 29 September 2026 (UTC)Reply

I would welcome topographical overlays, but I wouldn't want it to be "defualt" on anything. For the vast majority of our articles (usually city or region), the contour lines would just be clutter. It should however, be provided as an option for park and itinerary articles, but as an option, not the default. //shb (t | c | m) 09:07, 29 September 2026 (UTC)Reply

Thus why I said “certain articles”. So editors can decide if present by default or not. Travel Doc James (talk · contribs · email) 10:55, 29 September 2026 (UTC)Reply

Here's a few usability ideas I've collected but haven't gotten around to tinkering with.

• Ways to make it easier to jump between the map and listings. Right now, clicking on the listing prose marker pops up a map, but clicking on a map marker doesn't take you to any form of listing prose.
• On the mobile site, a way to pin a map to the corner of a screen as I scroll through listings.
• A one-click way to lookup and populate the lat/long of the address provided to the listing.
• A way to better emphasize metro/transit stops in the OSM render, to lessen the need for redundant map markers.

Gerode (talk) 15:51, 29 September 2026 (UTC)Reply

Actually, clicking on a map marker shows the listing name, which may be linked. On region article maps, most markers are for cities and other destinations, which have articles, linked from the name. Travel topic articles should likewise (but not always have) the listings linked to the main listings in destination articles (so when you click on the marker for Smeaton’s Tower in Plymouth in the Lighthouses' map, you get a link to Plymouth (England)#Q3995634). It might be better to get a link to the listing in the article, at least if the listing name isn't linked. That would work also for listings in lowest-level destination articles (where listings seldom have internal links onward). One could also consider showing the listing's "content" prose (the name could still be linked). –LPfi (talk) 13:23, 30 September 2026 (UTC)Reply

I would love an option to show the user's current location on the map. —Granger (talk · contribs) 16:47, 11 October 2026 (UTC)Reply

Excellent idea. Will need to see if our privacy rules allow this. Travel Doc James (talk · contribs · email) 18:42, 11 October 2026 (UTC)Reply

This can be done by sending e-mail to legalwikimedia.org. Who wants to send the message? WhatamIdoing (talk) 16:20, 12 October 2026 (UTC)Reply

There's already a gadget (Locator) for that, you just need to enable it in your settings... -- andree 19:36, 11 October 2026 (UTC)Reply

The setting description says it works locally, without sending out any data. –LPfi (talk) 16:07, 12 October 2026 (UTC)Reply

Tested it and it worked well. Though not sure how it works. Travel Doc James (talk · contribs · email) 18:29, 12 October 2026 (UTC)Reply

Yes. I found the Wikivoyage Travellers' Pub. It is a place where Wikivoyage users can ask questions and discuss general issues about Wikivoyage. If I have a question about editing or using Wikivoyage, I can ask for help there. Buryab0ne (talk) 06:47, 29 September 2026 (UTC)Reply

Yes, you can. There is also the Wikivoyage:Arrivals lounge, which is preferred for simple questions.

However, if you want to answer an assignment question, you should use another page (and you don't have to use a boldface font).

–LPfi (talk) 08:46, 29 September 2026 (UTC)Reply

My most sincere apologies for a Substack link: https://read.hereandthere.club/p/the-tour-du-mont-blanc-goes-reservation ―Justin (koavf)❤T☮C☺M☯ 16:17, 29 September 2026 (UTC)Reply

I don't think there's anything wrong with linking a Substack page to a talk page. Ikan Kekek (talk) 04:19, 30 September 2026 (UTC)Reply

As far as I'm aware, they have not changed their "Nazis are fine" policy: https://www.theguardian.com/media/2026/feb/07/revealed-how-substack-makes-money-from-hosting-nazi-newsletters ―Justin (koavf)❤T☮C☺M☯ 05:12, 30 September 2026 (UTC)Reply

That's terrible, of course, but there are also many good Substack pages. -- Ikan Kekek (talk) 05:24, 30 September 2026 (UTC)Reply

Yes one needs reservations before hand at accommodations before one can set off on the Tour Du Mont Blanc Travel Doc James (talk · contribs · email) 12:34, 30 September 2026 (UTC)Reply

Articles such as budget travel, responsible travel and sustainable travel could certainly bring up more case studies of overtourism, and the regulations, fees and protests which react to them. /Yvwv (talk) 13:24, 30 September 2026 (UTC)Reply

I created a community wishlist wish here requesting a bot to flag dead/usurped links for projects like Wikipedia and (potentially) Wikivoyage. Have there been any similar efforts/cautionary tales? Any thoughts/ideas? Superb Owl (talk) 20:06, 30 September 2026 (UTC)Reply

User:InternetArchiveBot does a lot of this for us, though it is far from perfect. Are there features you would like to see that this bot isn't handling? Gerode (talk) 20:11, 30 September 2026 (UTC)Reply

I'm guessing we have to point the bot at articles for it to run? I've spent a lot of time deleting defunct businesses in San Francisco that could've seemingly been caught and flagged by a bot that the url is not functional. An archived version of those websites aren't as useful for Wikivoyage, since many of those businesses are not operational and need to be flagged and deleted. Superb Owl (talk) 20:15, 30 September 2026 (UTC)Reply

It runs in the background across Wikivoyage. I don't know its schedule, but there's a few links it flags as false positives every few weeks. I'm not sure why it isn't flagging the links you're manually deleting, but I'm not surprised :p

We don't use the archives it creates from the links; I think Internet Archive uses wiki links to build its own list of archival targets. Gerode (talk) 20:29, 30 September 2026 (UTC)Reply

Oh, well then that might already be happening. Most of my edits were a few months back so it could've been before the bot really got going on Wikivoyage? I'll keep an eye out and see if I find new examples of urls it is missing Superb Owl (talk) 20:34, 30 September 2026 (UTC)Reply

Nah, your frustrations are valid, the bot has been running for years and it is not catching the stuff you're deleting in San Francisco district articles. The way it identifies a dead link is less sophisticated than we would like - it's not catching "Squarespace Website Expired" and sites that get immediately squatted by crypto/gambling spam. Gerode (talk) 20:43, 30 September 2026 (UTC)Reply

Well, I will reach out and see what they are working towards since that seems like a logical place to start.Superb Owl (talk) 04:55, 1 October 2026 (UTC)Reply

There is a bot like that on en.wp and it would be useful to have one here as well. As I recall, the bot that already does some checking occasionally has false negatives. ―Justin (koavf)❤T☮C☺M☯ 20:20, 30 September 2026 (UTC)Reply

InternetArchiveBot marks dead links using Template:Dead link. If you enable ErrorHighlighter in the Gadgets tab of your preferences, you will see a yellow Dead Link marker by each link that has been flagged. If a link is flagged as dead them starts working again there are two dates in the dead link template and a formerly dead link marker. Unfortunately many website now only want humans to read them and so there are often false dead links flagged - the bot will ignore any link that has Template:Cbignore next it. I see that you have removed listings with dead link templates, but the bot is flagging links in San Francisco districts less often than I would expect. AlasdairW (talk) 11:10, 1 October 2026 (UTC)Reply

One thing that's different here (vs enwiki) is that we don't display {{dead link}} to readers. It's visible in the visual editor and of course if you search directly for the template in the wikitext, but readers won't see it. This is consistent with the local community's values, and not unreasonable given the uncertainty of the tagging process. I just partly cleaned up one article with a lot of links tagged as being dead, but not all of them are actually dead.

Ah well that may explain why I haven't been noticing the dead link tags Superb Owl (talk) 16:02, 1 October 2026 (UTC)Reply

One thing that's unfortunately the same here is that there is more interest in automated tagging of links than in fixing them. Category:Articles with dead external links has 7700 (mostly) dead links in it. WhatamIdoing (talk) 15:39, 1 October 2026 (UTC)Reply

For sure and hopefully we can get a Bot that is good enough at flagging so we can continue to automate these kind of maintenance tasks that people seem least interested in tackling Superb Owl (talk) 16:02, 1 October 2026 (UTC)Reply

We don't necessarily need more flagging. We need more fixing. We need less "Let's put a template here!" and a lot more "That URL is dead because the business closed, so let's remove the whole thing from the article." WhatamIdoing (talk) 14:44, 2 October 2026 (UTC)Reply

It seems safe to assume that if the tags were public-facing, then more maintainers and new/casual users (like myself) would actually see the flags and help address them while those that already were aware of them might be more motivated to clean up the page. Why do we hide those flags? Superb Owl (talk) 16:25, 2 October 2026 (UTC)Reply

It should be possible to change the template so that it displays to autoconfirmed users such as yourself via CSS. WhatamIdoing (talk) 23:29, 3 October 2026 (UTC)Reply

Also, if you'd like to work on fixing a subset of these links (e.g., all articles with known-bad links from a particular country), I can probably make a list for you. WhatamIdoing (talk) 23:44, 3 October 2026 (UTC)Reply

I appreciate the offer/tips but first am hoping to see evidence of systemic changes that indicate that Wikivoyage is on a positive upward spiral. The conversation below on how to fix the bot issue and explaining why the decision was made not to show flags for dead links is really heartening. I would rather wait and help to test the bot than to use any current workarounds.Superb Owl (talk) 17:55, 4 October 2026 (UTC)Reply

I'm not sure what "testing the bot" would involve, or what "current workarounds" you're talking about.

• You asked for a bot, but we already have a bot (i.e., the same one that the English Wikipedia uses). There's nothing to "test" here.
• You said that you didn't realize the bot existed because the template is invisible; I suggested making the dead link template not be invisible for all logged-in editors with a few edits. Making our dead link template behave more like enwiki's w:Template:Citation needed (at least for editors) instead of like enwiki's w:Template:Use American English (which is invisible to everyone) isn't a "workaround".

I'm sorry, I misunderstood and thought you were suggesting that I change a personal css setting - I fully support making dead link flags more visible Superb Owl (talk) 00:19, 5 October 2026 (UTC)Reply

If you are worried that we might go the way of Wikinews, then have a look at the stats for active editors. Compare them against, e.g., the decline in Wikibooks, lower but level numbers in Wikiquote, and the recent spike at Wikisource. WhatamIdoing (talk) 20:18, 4 October 2026 (UTC)Reply

There is a user setting to expose dead links during regular browsing, but it's buried:

Preferences -> Gadgets -> Experimental -> enable ErrorHighlighter Gerode (talk) 23:48, 3 October 2026 (UTC)Reply

Why is it buried, and what does that mean? Hard to find? Ikan Kekek (talk) 00:29, 4 October 2026 (UTC)Reply

Hard to find; i.e., buried deep in the settings menu Gerode (talk) 00:48, 4 October 2026 (UTC)Reply

Enabling this also enables highlights for some other errors, like incorrectly formatted phone numbers, and a few others that are uncommon. The Dead Link template was introduced when a bot was first used to check links and I think we wanted to avoid casual readers being put off by all the flags, and we didn't know how many false positives there would be.

My experience is that about 50% of places to eat with dead links have closed. Others are still there but have just given up on that website, usually to just use Facebook but sometimes smallvillecafe.co.uk is dead and it is now on smallvillecafe.com. With other links, the closed rate is much lower, and the bot may have failed a "are you a human test", the website is now https, the website has been reorganised and that page has moved, the business has changed name but the same staff are there or the link may just be too slow for the bot etc.

We could change dead link to display something for all readers, but as there is a high false positive rate, it would need to be something subtle. AlasdairW (talk) 09:38, 4 October 2026 (UTC)Reply

I'd not be opposed to switching it on for all autoconfirmed users as a minimum. //shb (t | c | m) 00:14, 5 October 2026 (UTC)Reply

We could have it display something like ^{[check link]} It could link to template documentation or some other page explaining that if the link is good, then you should put Template:Cbignore next to it. (If the link is bad, I think registered editors here are smart enough to figure out what to do.) WhatamIdoing (talk) 23:39, 5 October 2026 (UTC)Reply

WhatamIdoing: I fixed all the A's. I'm not sure if this is what you were looking for. A few observations in case they're of use:

• About 50% of dead links seem to be bus companies. A further 20% other forms of transportation (e.g. airlines). This may be biased because transportation external links tend to be outside of templates.
• It appears that in the year 2020, the bot checked links in listing templates. I have not seen any deadlink templates inside listing template dated after 2020.
• I am currently in Indonesia. A significant number of links seem to be blocked at the CDN level because I am in Indonesia. If I VPN to western countries I am usually unblocked because the VPN servers I use usually don't appear on blocklists. My point being that I wonder if the bot is being blocked due to its IP being in a suspicious range.
• A lot of broken http links resolve automatically to working https sites in my browser. I am not sure if this is my browser following explicit redirects or simply taking a guess that https is the working site. Regardless, it does feel like the bot could be more sophisticated in its resolving strategy. I have to use cbignore a lot. I'm not sure if captcha's are blocking it (cloudflare's is a common one).
• It might be worthwhile increasing the request timeout on the bot. Many sites take a long time to respond, and we tend to tag these as dead.
• Both adding and subtracting the www subdomain seems to be a common source of error.

Brycehughes (talk) 11:23, 4 October 2026 (UTC)Reply

Thanks for fixing a load of links. InternetArchiveBot started in 2023, earlier dead links were flagged by WRH2Bot which was local to Wikivoyage. AlasdairW (talk) 11:58, 4 October 2026 (UTC)Reply

Thanks for that work; it is really helpful.

IABot is blocked from many sites, and the proportion of sites has increased significantly this calendar year. WhatamIdoing (talk) 16:35, 4 October 2026 (UTC)Reply

@WhatamIdoing: I'd assume most of those were tagged by IAbot, though? //shb (t | c | m) 13:48, 2 October 2026 (UTC)Reply

I assume that nearly all of them were. WhatamIdoing (talk) 14:42, 2 October 2026 (UTC)Reply

There could be a problem with the bot checking San Francisco districts. Most districts have never has a link flagged on them and those that had were last marked in 2023, but the bot is regularly flagging links on San Francisco. I can't see the page that configures the bot for this site - could an admin please check that there isn't something that is preventing it checking these pages. One possibility is that there is a limit in the number of characters in the page name, as San Francisco has some long names like San Francisco/Union Square-Financial District with 46 characters. The old Wrh2Bot regularly flagged links on district pages. AlasdairW (talk) 21:00, 2 October 2026 (UTC)Reply

Oh wow, the problem is much larger than just San Francisco. I think IABot is only flagging links in prose, and not links inside listing templates. None of the last 50 flagged dead links were inside templates. San Francisco is conspicuous because it's all Guide/Star status, so most of its links are tightly categorized. I think we need to configure IABot to work with our listing templates, as described here. Gerode (talk) 22:15, 2 October 2026 (UTC)Reply

Pinging @Cyberpower678, Harej:. //shb (t | c | m) 01:39, 3 October 2026 (UTC)Reply

Hi there. Can you be a little more specific with template issue? —CYBERPOWER (Chat) 12:41, 8 October 2026 (UTC)Reply

I don't see any templates configured for this wiki, and I can't find templates like Cite Web on this wiki. —CYBERPOWER (Chat) 12:45, 8 October 2026 (UTC)Reply

@Cyberpower678, Harej:, Thanks for looking into this.

The commonly used templates with links in them here are listing and its derivatives. I think we would like the bot to check links in the "url=" field of the following templates: Template:Marker, Template:Listing, Template:Buy, Template:Do, Template:Eat, Template:Go, Template:See, Template:Sleep, and Template:Event. If you want to try one to start with Template:Eat is most likely to have dead links, as it is used for listings of restaurants in city guides. An example of the sort of page that started this discussion is San Francisco/Civic Center-Tenderloin. AlasdairW (talk) 13:33, 8 October 2026 (UTC)Reply

@AlasdairW:, note that {{Ping}} does not work if you don't sign the post. So going back to a previous comment and adding it without adding a new ~~~~ will not actually ping anyone. ―Justin (koavf)❤T☮C☺M☯ 14:59, 8 October 2026 (UTC)Reply

Pings in an edit summary also work. WhatamIdoing (talk) 16:36, 8 October 2026 (UTC)Reply

There can be dead links in both the "url=" and "content=" fields of those templates. Gerode (talk) 16:40, 8 October 2026 (UTC)Reply

Should be added now. —CYBERPOWER (Chat) 17:17, 8 October 2026 (UTC)Reply

@Cyberpower678: Thank you updating the bot! Not sure if this was addressed elsewhere, but it looks like Alasdair's list is missing one common template Template:Drink. Many urls to bars, pubs and clubs become dead too. Gizza ^(roam) 00:50, 9 October 2026 (UTC)Reply

It's in there too. —CYBERPOWER (Chat) 15:25, 9 October 2026 (UTC)Reply

FWIW, I occasionally record the number of articles with dead external links along with the number of articles in other maintenance categories here in a not-so-presentable way. Based on the times when I've checked, the number of articles with dead links peaked in December 2020 when there were 8537 such articles. This is assuming that the bot is working and capturing all dead links, including those within listing templates, which may not be the case. Also I suspect the articles starting "A" had more bus company dead links because I and others have gone through the A's and replaced/removed the dead links of other types of links, which were relatively lower hanging fruit. Trying to find the correct bus company link is tricky at times. Gizza ^(roam) 00:04, 6 October 2026 (UTC)Reply

I see an updated bot starting to make the rounds on our listing templates, thank you so much! I see one minor issue: it is reformatting the line breaks within the template (i.e., it's moving all the ~15 fields into a single line of text), which will make these listings more annoying to edit by source in the future. Is there a way to preserve these line breaks? If not, IMO it's tolerable. Gerode (talk) 17:16, 8 October 2026 (UTC)Reply

Thanks, the bot is doing a good job. I see that it is putting dead link after the listing template, rather than next the link which would be slightly better. Listings can be edited using the dedicated edit link next each listing - with text like (updated Jun 2025 | edit), but the dead link marker can't be removed when doing this. For those that haven't seen the improved bot in action, see Aviation history. AlasdairW (talk) 20:16, 8 October 2026 (UTC)Reply

Tracked in Phabricator ^(?)
Task T275457

I wonder if it's following TemplateData formatting. There isn't currently a way to specify our formatting style there. We could switch them all to block formatting, though; that would be about halfway correct instead of mostly wrong. WhatamIdoing (talk) 22:05, 8 October 2026 (UTC)Reply

@Cyberpower678: Could you please configure these additional templates for dead link flagging, if they aren't already? These often have external links in them.

• Template:Infobox
• Template:Cautionbox
• Template:Warningbox

Gerode (talk) 21:47, 26 October 2026 (UTC)Reply

(Apologies for cross-posting in English, translating it will help spread the message)

Editors on group 1 wikis, including Wikiquote, Wikibooks, Wikiversity, Wikivoyage, and Wikisource, will no longer see notifications on Recent Changes and Watchlist when a link to another language version of a page is added, removed, or changed in its Wikidata item. This change will begin on October 5 at 07:00 UTC as a two-week trial to reduce high-volume, low-value notifications and make higher-value changes easier to identify. Editors who rely on these notifications should be aware of the change and can share feedback or concerns on the project or talk page.
Please reach out if you have any questions, thank you! -- Danny Benjafield (WMDE) (talk) sent via MediaWiki message delivery (talk) 12:42, 1 October 2026 (UTC)Reply

I notice that some of the students working on articles about Korea are putting long Naver map links in the url tabs of listings. I assume those violate WV:What not to link to. Do you all agree? Ikan Kekek (talk) 12:37, 2 October 2026 (UTC)Reply

Attn: @Hanyangprofessor2. Ikan Kekek (talk) 12:39, 2 October 2026 (UTC)Reply

@Ikan Kekek I believe this is useful for verifying places really exist. Some places do not have official pages, but these days I am requiring students to prove an entity exists, either by linking to Wikidata/Wikipedia or by adding an URL. Otherwise we can risk a flood of AI hallucinated listings. The cited guideline may merit a revision with regards to "Map services". That said, it already says "Blogs, forums and social networking sites (Facebook, etc), with the exception of when a business has no other official web presence". When such a business has no social networking or other official presence, linking to its entry on the local map service (Naver is the most popular in Korea) seems reasonable. I'd revise the "no Map services" to say they are allowed if no official presence is found. Hanyangprofessor2 (talk) 02:56, 5 October 2026 (UTC)Reply

A url is not supposed to merely provide a location, and I don't understand why we should treat Maver maps differently from Google Maps. Ikan Kekek (talk) 02:59, 5 October 2026 (UTC)Reply

Is anyone else reading this thread? I think we're going to have a lot of cleanup/deletion on our hands. Ikan Kekek (talk) 13:27, 5 October 2026 (UTC)Reply

Yes we have. I understand the requirement of an URL – we have included that in the AI proposal – but we want official URLs. Is it uncommon for venues we are interested in not to have even a Facebook page, or is it just that lazy students don't look those up? Where do they find the other information on the venue? Is everything from that map service? –LPfi (talk) 15:41, 5 October 2026 (UTC)Reply

I would think that venues too small to bother even to set up a Facebook page are too insignificant to list, unless they are truly extraordinary (or the only eatery around). There should either be a personal experience or a good article mentioning it. Could one list that article in an edit summary instead, on the talk page, or as an HTML comment? They should be the exception rather than the rule, so some extra work is not too big a burden, neither for editors, nor for patrollers – unless the internet presence is low in South Korea. –LPfi (talk) 15:46, 5 October 2026 (UTC)Reply

I don't agree with the idea that nothing without a URL can be listed, and would expect some great stalls to continue to lack their own web pages. Note that Facebook pages are sometimes set up by fans and not official. I understand why a professor would want to require verification, but a map site is not close to being an attraction's own website and should not be in the url tab. Such urls can be provided to the professor separately. Ikan Kekek (talk) 15:55, 5 October 2026 (UTC)Reply

I checked one of the Yeongcheon listings with a Naver maps URL – and Naver maps linked to the venue's Instagram page. Pure laziness? I don't want to check many of them – the site seems to be resource-heavy and problematic privacy-wise. –LPfi (talk) 16:24, 5 October 2026 (UTC)Reply

In general, I am trying to discourage students from listing anything in the eat/drink/sleep, as I find those entries mostly useless anyway - spam/random places/half-time alraedy closed, functionality-wise, this part of WV works much worse than any local popular map service anyway, on all levels (convinience, up-to-date, content). So I am likely to revise that requirement and likely tell the students not to bother with these sections anyway in my future revisions of the assignment, which should reduce low quality information submitted by students here.

What I am more concerned with is verifying that a place exists, particulalry for the key elements of the page, which for me are see/do. Since the raise of the AI tools I've seen fake beaches, museums, temples, etc. I expect the problem will disapper in a few years, but for now it's a major concern IMHO. Therefore I believe a proof is required, and the most convinient place for everyone do submit it is the URL parameter (if there is no Wikidata entry to connect). By everyone, I don't mean just me, but also you and the reader as well. Do you want to look at edit summary to verify if this is not AI spam, or do you want to just accept some entries with no equivalent of a reference will be AI spam? The no reference required rule was fine until the AI era, but now it is a major risk for WV. If there is consensus URL is not required, that's fine, but I am, sorry, not going to be checking each and every one of them myself, trying to guess if some obscure place with possibly badly translated name from Korean or Chinese or such is real or hallucinated. Requiring a proof of it from students in another way (my talk page, email) is just to inconvinient and also, some students will just ignore this requirement anyway. Of course, one solution is to just delete all student-created listings that have no URL. Note that this means some types of entries will be disallowed (ex. many natual landmarks don't have official URLs).

In either case, if the consensus is we don't want map URLs here, I will be introducing a rule to my students starting now that a listing is required to have a non-map official URL (so, no reviews, no news articles, no scholarly works, etc.) or otherwise I will be deleting them. Hanyangprofessor2 (talk) 02:02, 6 October 2026 (UTC)Reply

I think that Eat and Sleep are important sections. I would like to see the students add something for those. Yes, restaurants may have relatively short lifespans, but the buildings themselves tend to still contain a restaurant. Alice's Restaurant turns into Bob's Burgers, which turns into Chris's Café, but if you've got the street address, you'll find something to eat, even if they name is now wrong. WhatamIdoing (talk) 17:28, 6 October 2026 (UTC)Reply

@WhatamIdoing Rather than listing individual places, outside the ones that are famous, I find it much more useful for such sections to tell me what are the local food specialties and such. For example, for peope visiting my hometown (Katowice), I'd rather describe the local Silesian food like zurek soup. It can be had in many restaurants, but I'd rather tell the visitors it exist and is worth trying - location is of secondary importance, IMHO. Hanyangprofessor2 (talk) 06:52, 20 October 2026 (UTC)Reply

Sure, but why not both? If I read about local specialties, I want to know where I can have good renditions of them. Ikan Kekek (talk) 10:22, 20 October 2026 (UTC)Reply

Piotrus, your "hometown" is a metropolitan area with millions of residents and probably more than a thousand restaurant. Most of our articles are about places a tenth that size, or a hundredth. What works at the large end of the spectrum doesn't work at all on the small end.

For example, last night, I cleaned up a few things in Armstrong (Iowa). (There was a dead link, and I thought I'd try to fix it up a bit while I was there.) It is in the middle of nowhere, and the population is under 1,000. As far as I can tell, there is only one place to eat in town. There are also two small stores that sell food (a gas station with a convenience store, and a small grocery store that will probably die when the owner–operator does). There are no "local food specialties" unless you count the w:hotdish that old Mrs Smith has been bringing to the potlucks at the Lutheran church for the last 60 years.

I think we should do whichever best suits the situation, but in the case of a large metropolitan area, I could imagine, as Ikan suggests, a description of zurek soup and a recommended place to try it. I could also imagine a description of zurek soup, and a list of restaurants chosen for other reasons (e.g., a restaurant whose staff speak French, for the sake of French-speaking travelers). WhatamIdoing (talk) 19:05, 20 October 2026 (UTC)Reply

@WhatamIdoing Fair point. I certainly agree that for small villages and towns listing individual places make sense. For big ones, a few can be listed. What I worry about is that in some articles, these section contain a lot of random, obsolete locations that are not particularly special. On the other hand, for big and small places, a non-listing overview of the local specialties, food or sourvenirs or like, is a good idea (if, of course, there is anything remarkable to write about). Hanyangprofessor2 (talk) 06:56, 23 October 2026 (UTC)Reply

Could the students put the map URL in the edit summary instead of in the article? WhatamIdoing (talk) 23:43, 5 October 2026 (UTC)Reply

That's a good idea. @Hanyangprofessor2, the litany you put in parentheses above is precisely what's in wv:what not to link to, so please enforce that going forward. All these map urls have given us loads of off-topic stuff to delete, which you are responsible for. Next time, check with us before you encourage students to violate Wikivoyage policies or guidelines to suit yourself. Thanks in advance. Ikan Kekek (talk) 03:05, 6 October 2026 (UTC)Reply

We're approaching the end of the year, and while it is still October, it doesn't hurt to plan early. Unlike the last two contests, which were primarily Asia-themed, I'd like to broaden the theme and cover the entire globe this summer. Two reasons:

• We're very close to reaching 35,000 articles – if I'm not mistaken, this will be the first major article count milestone we've had since COVID (30,000). Currently, this number sits at 34,818 (so 182 left).
• Asia is not the only "underrepresented" part of the world – by broadening coverage to accept articles worldwide, we increase the number of participants, thus improving the site's coverage more than if we'd just constrained it to Asia.

I'd probably keep the rules the same as we did the last two years, just for simplicity. As for dates, would prefer to broaden it from 1 November to 15 January, which covers almost 3 months. Other thoughts? //shb (t | c | m) 06:29, 4 October 2026 (UTC)Reply

(cc @Lord Ravager, OhanaUnited:) //shb (t | c | m) 06:30, 4 October 2026 (UTC)Reply

Also created Wikivoyage:Wikivoyage 14 as a placeholder. //shb (t | c | m) 07:40, 4 October 2026 (UTC)Reply

I support. I would like to see the page name mentioning Wikivoyage Asian Month to increase campaign recognition. Same rules apply. And award given for participation, not a contest. OhanaUnited^{Talk page} 14:36, 4 October 2026 (UTC)Reply

That's fair – would you perhaps think maybe 2x points if the article was about Asia would be a good way to still maintain some relevance to WAM? //shb (t | c | m) 22:38, 4 October 2026 (UTC)Reply

Alternatively, possibly maybe 2 bonus points in total if there's at least one Asia-related article? //shb (t | c | m) 23:18, 4 October 2026 (UTC)Reply

Or even simpler, check a box if they submitted at least one Asia-related article and be eligible for WAM prize (last year I got a nice postcard sent from Taiwan, which was pretty nice). OhanaUnited^{Talk page} 16:01, 6 October 2026 (UTC)Reply

2.5 months is too much. I'd rather do January 1 – January 31. That way, if people hear about us on our 'birthday', they can still join the contest.

Having helped (a little) with one of these a couple of years ago, I'm firmly in favor of maximizing how much of the contest work can be automated. WhatamIdoing (talk) 20:03, 4 October 2026 (UTC)Reply

I think the dates should be better aligned with Wikipedia Asian Month (WAM) since it has better brand recognition than Wikivoyage 14 and WAM is already running a CentralNotice advertisement. OhanaUnited^{Talk page} 21:14, 4 October 2026 (UTC)Reply

WAM wants 30 days in November or December (e.g., November 1–30 or November 15–December–15). WhatamIdoing (talk) 23:46, 5 October 2026 (UTC)Reply

@WhatamIdoing:: re "I'm firmly in favor of maximizing how much of the contest work can be automated." – I'm massively in favour of this too. Currently experimenting something that autoverifies article's eligibility while making submissions easier than it would be to do manually (using MediaWiki's OOUI for a searchable box). No idea if it will be successful, how easy it'll end up being, or whether it'll increase participation, but I'll see where time takes me. //shb (t | c | m) 03:57, 6 October 2026 (UTC)Reply

Okay I might have done it (with enough Gemini help) – User:SHB/Wikivoyage14.js, though I need to run it through to see if there are any other bugs. The gadget atp simply involves a search box, listing which country it's in (allows for multiple), and autosorts it into one of the two columns. Invalid submissions are automatically handled (see examples). //shb (t | c | m) 12:57, 6 October 2026 (UTC)Reply

Looking at the conversation above about Category:Articles with dead external links: Is there any way we could encourage removal or correction of dead URLs? Maybe a #hashtag in the edit summary so it could be automatically counted? WhatamIdoing (talk) 16:39, 8 October 2026 (UTC)Reply

@WhatamIdoing: Sorry I missed this earlier – replacing URLs do count towards the 2000-byte count (though removing dead ones don't, but no points will be lost). Maybe this should perhaps be explicitly mentioned? //shb (t • c) 05:30, 15 October 2026 (UTC)Reply

I think WhatamIdoing may have been suggesting to give bonus points for removing or updating dead links beyond the byte count because of the scale of the problem currently. Gizza ^(roam) 13:02, 15 October 2026 (UTC)Reply

Hmm, I do wonder if that will complicate the criteria too much. Part of what worked very well in WV12 and 13, but not WV10, was the simple criteria. But I am very much open to a flat bonus (maybe 2 points for 50+ dead links replaced/removed), requiring user submission, which could work. //shb (t • c) 13:07, 15 October 2026 (UTC)Reply

Would November 1 be a good start date? This way some of Hanyangprofessor2's students will also be able to make submissions for the contest. //shb (t • c) 01:27, 21 October 2026 (UTC)Reply

+1 Hanyangprofessor2 (talk) 06:53, 23 October 2026 (UTC)Reply

Hello everyone! I’m Luxbane, and I’ll be taking charge of the Wikimedia Small Projects activities focused on the communities (this is nothing new—it’s a continuation of the work already done by Galahad and Lord Ravager). I’m certainly glad there’s an initiative to keep celebrating Wikivoyage's anniversary.

My points: 1.- I think it’s an excellent idea to expand this globally, rather than focusing solely on content from Asia. Internally, it was suggested that we name this and future campaigns "Wikivoyage around the globe"—what do you think? 2.- Originally, "Wikivoyage Asian Month" ran from November 20 to January 20, which covered our anniversary (without overlapping with the start of "Wikipedia Asian Month" or conflicting with Wikipedia’s anniversary). Would you like to keep those dates? Alternatively, we could set a global timeframe—from November 1 to January 20—within which each community can choose when to participate. 3.- In response to OhanaUnited's question about the awards, if Wikipedia Asian Month is going to give the awards, they request that it be a contest-style award, not based on participation. However, since this would now be a global campaign, we could create postcards representing different continents (initially in a digital format, until we have the budget to cover physical mailing).

What do you think? --Luxbane (talk) 17:09, 21 October 2026 (UTC)Reply

As noted before, if we want (my) educational project to be involved, the semester ends in late December, so something spanning a year won't work (for me). Of course, if it works for most of the others, more power to you. Hanyangprofessor2 (talk) 06:54, 23 October 2026 (UTC)Reply

WAM 2026 timeline is November 1 to December 31. Are we on track to launch it a week from now? And do we end on December 31 or earlier? OhanaUnited^{Talk page} 20:28, 23 October 2026 (UTC)Reply

I'd still like to end it on January 15 to align it with our site's birthday. As for whether everything is on track, I'd say yes – the autoverification script (User:SHB/Wikivoyage14.js) will need to be moved out, but I can do that sometime later this week. //shb (t • c) 09:55, 24 October 2026 (UTC)Reply

I suppose we can start on December 1 or December 15, and ends on January 15? OhanaUnited^{Talk page} 05:59, 25 October 2026 (UTC)Reply

What about Nov 15? That way Piotrus' students can still submit articles for WV14. //shb (t • c) 06:42, 25 October 2026 (UTC)Reply

In learning about Wikivoyage I came across a number of instances where the project said it catered to users wanting print out articles.

1. Is the "Printable version" of articles being requested often?
2. Is a print-friendly format still a major project goal?

Superb Owl (talk) 22:41, 5 October 2026 (UTC)Reply

I don't think we know how often articles get printed.

I think that being print-friendly is less important than it was when that goal was originally established. Perhaps these days it's better described as "desirable" rather than "a major goal"? WhatamIdoing (talk) 23:49, 5 October 2026 (UTC)Reply

I second WhatamIdoing. As far as I can tell, we don't have data on printouts. Also our policies have historically been influenced by catering to the printed version of our guides and it is only slowly changing. For instance, until recently our Manual of Style required the days of the week to be abbreviated to one or two letters, so Monday would be "M" and Tuesday would be "Tu" to distinguish it from Thursday "Th". This was to make our guides as short as possible but with the potential downside of losing comprehensibility, as these abbreviations are not common outside Wikivoyage and some of the abbreviations (M for Monday and F for Friday) can be confused with months. Gizza ^(roam) 00:13, 6 October 2026 (UTC)Reply

Yeah, I'm guessing the rule predates the ubiquity of smartphones. I know a handful of people who still prefer printed to electronic sources for critical stuff like directions to their hotel, so our pages shouldn't be utterly unprintable, but I think we can shift to "print-possible" instead of "print-friendly". Gerode (talk) 00:20, 6 October 2026 (UTC)Reply

You're correct. I wasn't here in the very beginning, but joined about two years after it launched and the assumptions and culture were very different at the time. Also, in 2003/2005, it was far more common to print off materials from online to use offline and a substantial majority of the world's population did not have regular Internet access (~10% versus ~70%). We should definitely still keep those who may use this site without a persistent Internet connection in mind, but we should not prioritize that cohort, which honestly, probably doesn't exist in any meaningful sense anyway (I find it highly unlikely that rural Laotians are printing off Wikivoyage guides). ―Justin (koavf)❤T☮C☺M☯ 00:35, 6 October 2026 (UTC)Reply

I agree. There are still people without regular internet access as you say, but if you created a Venn diagram of the world's population that is 1. literate 2. has regular electricity access and 3. has regular mobile internet access, it is starting to look like a single circle. Even the lower-middle classes of most third world countries have regular mobile internet access nowadays. Gizza ^(roam) 00:47, 6 October 2026 (UTC)Reply

+1 to what Gizza said. //shb (t | c | m) 01:41, 6 October 2026 (UTC)Reply

I also brought up this topic a number of months ago and several users insisted that we maintain a print-forward policy. (This was in regards to adding audio/video media to the guide.) I would like to reiterate that a print-first does not comport to how this site is realistically used and made a lot more sense in 2003 than it does in 2026. It is very important to generally make resources useful in print form, but we should not bias the guide toward it and should assume that almost all users are going to be using an active Internet connection that allows them to request new media. ―Justin (koavf)❤T☮C☺M☯ 00:30, 6 October 2026 (UTC)Reply

I'm guessing there may still be tens of miles of Central Californian coastline through Big Sur with no phone signal. I agree that being able to use this site well online is the priority, but we should still be careful how much undownloadable material we have here. Ikan Kekek (talk) 01:09, 6 October 2026 (UTC)Reply

Would be nice if there was an offline feature integrated within the site...which would've been possible were the WMF interested in actually building a dedicated app for Wikivoyage. //shb (t | c | m) 03:20, 6 October 2026 (UTC)Reply

So it sounds like while printing is not as much of a priority, having the ability for the content to be useful in any kind of offline setting is still a goal? (e.g. through the Wikivoyage Kiwix app) Superb Owl (talk) 03:45, 6 October 2026 (UTC)Reply

I'm not really familiar with Kiwix but agree with you. Ikan Kekek (talk) 03:48, 6 October 2026 (UTC)Reply

I assume that print friendly means that you can save a PDF, which could be common for those assuming bad signal or an offline time (or time with ridiculous fees) until you get a local SIM (or even a local phone, if yours doesn't support the frequencies). –LPfi (talk) 06:37, 6 October 2026 (UTC)Reply

Yes, I think that saving a PDF, or just keeping the tab open in your phone's browser, is a not-unusual form of offline use.

I wonder if there is a way to put a whole article in an e-mail message. phab:T89850#1057885 has the code for sending just a link and the title, but if we could get something that was like copy/pasting the whole article into the person's own e-mail message, that might encourage offline uses, too. WhatamIdoing (talk) 17:38, 6 October 2026 (UTC)Reply

Perhaps I am a dinosaur, but I don't get this. Sending the link is easy if you know how to use email and have a sensible browser (which makes the URL available). If you want to send the page, then in what format? The HTML the browser got (perhaps with some header and sidebar stuff removed), the HTML + images, stylesheets, javascript etc., PDF or something else? If you are offline, you probably cannot send email (save a draft?), and may have a slow connection, from which sending the link makes much more sense than sending the page, which the receiver could very well fetch for themself with a better connection.

(RFC 1521 had an "external-body" option, which would allow having the page appear as being included, when actually retrieved only when needed, depending on configuration.)

–LPfi (talk) 19:51, 8 October 2026 (UTC)Reply

Sending the URL isn't useful for offline use. Sending the contents of the article would be useful for offline use. WhatamIdoing (talk) 21:14, 8 October 2026 (UTC)Reply

To yourself? To your friend out there?

If they don't have a good internet connection, they don't want to download that large email (while they might want to read your emails otherwise). If they get the link, they can download the article when they have good Wi-Fi.

For yourself: if you can read the article, you can as well save it directly instead of first mailing it out and then download it from the email server.

I can see some niche scenarios, but having good bandwidth to your email server but not to Wikivoyage doesn't seem like a common case, other than where Wikivoyage gets blocked..

–LPfi (talk) 21:26, 8 October 2026 (UTC)Reply

About 20 years ago I had email at work, but no internet browser access, but this would be unusual today. These days I would consider sending a pdf of an article if I wanted to circulate it to many colleagues on the same email server, as that way there is only one internet access and we are all reading the same version of the article, AlasdairW (talk) 22:07, 8 October 2026 (UTC)Reply

Also, people know how e-mail works: you put the content in the message, and it's there forever. "Saving it directly" is technical magic for a lot of people. WhatamIdoing (talk) 22:12, 8 October 2026 (UTC)Reply

:-) –LPfi (talk) 22:22, 8 October 2026 (UTC)Reply

@Doc James knows a lot about Kiwix. WhatamIdoing (talk) 17:32, 6 October 2026 (UTC)Reply

You can simply download the offline Wikivoyage app if you are on an android[2] or download the Kiwix app followed by the Wikivoyage library if you are on an iPhone. We also ship it with Internet-in-a-Box. Travel Doc James (talk · contribs · email) 18:44, 6 October 2026 (UTC)Reply

In a thread up the page, User:Hanyangprofessor2 said: "I am trying to discourage students from listing anything in the eat/drink/sleep, as I find those entries mostly useless anyway - spam/random places/half-time alraedy closed, functionality-wise, this part of WV works much worse than any local popular map service anyway, on all levels (convinience, up-to-date, content)."

I suppose the same criticisms would apply to "Buy".

Truth be told, I use Google Maps quite a lot to decide on new places to eat, based on the ratings and how many votes there were, plus the menus and descriptions on the restaurants' own sites, though I also often go places simply because I walk past and like their menus, and in addition, I don't create restaurant listings on Wikivoyage nearly as often as I'd really like to, because it's time-consuming. But I think sites like Google Maps and Tripadvisor can be too indiscriminate in some ways but also miss some very good places, and Yelp is probably worse - for example, when I was at 103 St. and Lexington in New York, it didn't mention anyplace in Harlem at all, only places south of 96 St., and we went to a taqueria in a supermarket that was great and unique that got recommendations on Google Maps. I think there's still value in having a curated group of listings in these sections, but since it is indeed somewhat time-consuming to update them, if we want to keep them, we should probably have dedicated expeditions focusing on such listings several times every year. In theory, the advantage of Wikivoyage is that we are non-profit, but in practice, many of the listings in these sections were indeed added by self-interested parties and/or copied from promotional sites. I've stated before that I would never trust hotel listings on this site because of that.

What are your thoughts? I miss the days when food discussion sites like Chowhound and eGullet were excellent sources of recommendations for eateries, because you could get to know the tastes of different posters and also had confidence that those sites tended to attract and keep people with generally good taste and block spam effectively. But is Hanyangprofessor2 right in implying that we should more or less give up on listing specific eateries, bars, stores and hotels, except for maybe longstanding, famous ones or something? Ikan Kekek (talk) 04:07, 6 October 2026 (UTC)Reply

I agree that this content seems to be the lowest quality and least useful. The main concern is just how daunting of a maintenance burden these sections are (linkrot, spam, etc.). If there is broader interest in cutting these sections down quite a bit, we could borrow Wikipedia's notability standard for inclusion, where if a Buy/Sleep/Eat/Drink place does not have a Wikipedia article, then it is excluded. Superb Owl (talk) 04:50, 6 October 2026 (UTC)Reply

Truth be told, apart from maybe park articles, I've never once found eat/drink/sleep listings useful, buy even less so. //shb (t | c | m) 04:53, 6 October 2026 (UTC)Reply

There is a risk that the Eat/Drink/Sleep listings were added by touts or spambots but that risk is present on Google Maps, Tripadvisor and every online crowdsourced source of information. The only recommendation I can reliably trust are real-life friends of mine who have similar tastes to mine. I agree that Wikivoyage isn't able to monitor whether a place has closed or not as quickly as Google because of the fewer number of users here. But what would the alternative be? Do we mention particular streets where certain types of establishments can be found? These sections will become very bare and almost pointless. Most small cities and towns don't have any famous places but just run-of-the-mill joints. And then the article will just feel incomplete. With Buy, while we list individual stores, we also list things like farmers markets and shopping malls which are much broader, more useful and less prone to touting. Gizza ^(roam) 04:56, 6 October 2026 (UTC)Reply

I don't think limiting the listings to Wikipedia-covered stuff is a good idea. Wikivoyage is supposed to be its own thing, and it makes no sense to be just duplicating Wikipedia. There's also the chance that Wikipedia's coverage is incomplete, i.e. nobody has gotten around to writing an article about a place yet - the English version has a coverage bias towards Anglophone countries, and smaller Wikipedias often have coverage issues due to the smaller pool of volunteers (which leads to prioritising other topics as more important) and the lack of digital sources. If Wikivoyage is going towards "list only things found in Wikipedia/Wikidata", you might as well shutter the project, as editing those two will be a better use of people's time and effort. Daggerstab (talk) 09:51, 6 October 2026 (UTC)Reply

I will also add that many such places (particularly outside sleep) don't have official pages, and verifying if they are real in the age of AI hallucinations is a problem. It's not just students, but more and more people rely on AI to find information for them, and they often are very incorrect. I know well WV long ago decided we don't need footnotes - fine, but if we have a URL field in listings, we need to make use of it.

On a side note, I just finished the "add an event-type do listing". Setting aside the technical problem that Template:Event does not have the accompanying "edit this listing" subbutton, I am running into a Chinese-specific problem that my Chinese studnets are failing to find official festival websites (unlike my Korean students). I am unsure if this is their skill issue, or if Chinese Internet is different and events like this don't have centralized webpages. I am getting usually URLs for government news about events that happened, and at best, students show me a search URL saying people have to check search results for a given event under the government website to find out the new edition. I am not sure if such URLs are acceptable? Do we prefer no URLs in such cases? Hanyangprofessor2 (talk) 08:28, 6 October 2026 (UTC)Reply

The event website issue is probably explained by most events being organised top-down by local governments and other organisations with multiple functions that run many types of events throughout the year, so an individual event may only get recurring news items on the website of the parent organisation (for example, that's the case with "city day/festival" celebration in Bulgaria, which are organised by the local municipalities). In contrast, outside of China many events are organised by clubs or ad-hoc grassroots organisations of private citizens dedicated to running that particular event, so a separate website makes sense. Daggerstab (talk) 09:38, 6 October 2026 (UTC)Reply

I don't think a URL that just reports about an event after the fact is really useful to travelers, only one that provides information before the fact, particularly including the date of the next festival. Ikan Kekek (talk) 12:27, 6 October 2026 (UTC)Reply

I also agree that listing and maintaining individual "buy", "eat" and "drink" listings in those sections is burdensome. So, I suggest grouping them into single listings (or sections) of their corresponding buildings or streets. For example, instead of listing every single bookshop on the same street in North Kolkata, I have just given a single listing on College Street with a generic description that would be applicable for all bookshops. Same for shopping malls and legacy retailers. We can also include some highlights in the listing.

For "sleep" section, you can list chain hotels from Wikidata to fill the "Splurge" section, like I have done for Kolkata, Bengaluru and Delhi (other details are from official websites). For "Budget" and "Mid-range", it's better to list accommodations based on verified information. Sbb1413 (he) (talk • contribs) 09:22, 6 October 2026 (UTC)Reply

@Sbb1413 I like the idea. Outside of very famous places (likely notable on Wikipedia), describing streets/neighborhoods makes sense for many places. Hanyangprofessor2 (talk) 03:16, 10 October 2026 (UTC)Reply

I think we should make a distinction between Eat/Drink/Buy/Sleep sections and EDBS listings. The sections are useful in country and regional articles for general remarks about what's available and what's good (e.g. characteristic types of souvenirs can be listed in countries' Buy sections). Aside from that, individual sites' Buy sections can also be useful for things like ATM locations, antique shops, traditional craftsmen, etc. I also agree with DaGizaa about farmers' markets and shopping malls. As for Sleep, I usually put at least one hotel there when creating a new page to prevent a WV:SLEEPTHERE challenge, and Sleep listings are useful in rural areas and national parks, where having a map with the locations of e.g. mountain huts is more important than the hotels in a large city or in a resort that consists of little else other than hotels. Daggerstab (talk) 09:27, 6 October 2026 (UTC)Reply

I think that the sections are useful, but the listings are less so. In a city it is useful to know the streets that have several restaurants, but if there are several that don't require reservations I don't need the details; in a small village I want to know if there is anywhere that I can get a meal at 7pm. In sleep, individual listings are useful in villages, but if a place has more that 5 hotels then I rough idea of the total may be enough perhaps with an idea of the busier (more expensive) days in the year. AlasdairW (talk) 10:20, 6 October 2026 (UTC)Reply

My two cents:

• I've never used Sleep listings. On a fundamental level, I don't think wiki-style crowdsourcing can compete with map apps and hotel aggregators who can source and surface customer feedback much more comprehensively. The listings are also hard to curate as a local, since I never stay in hotels close to home. The only place where they seem remotely useful are for rural places with highly-constrained lodging options, like U.S. National Parks. The section prose can be helpful for deciding which part of town to stay in, and Sleep map markers do give me a sense of what areas have options, but I'm open to better ways to communicate that info.
• Eat and Drink listings aren't that useful to me because I have some dietary constraints, but the map apps and review platforms aren't great either, so I have conflicting thoughts. High-quality listings are hard to write, and for a median-quality listing, I don't have a reason to trust One Guy On The Internet over 1000 Guys On Google Maps, as low-quality as any individual review is on those platforms. I can envision a path where Wikivoyage has curated food listings that add value over other platforms, but I don't know how to get on that path.
• I actually like our Buy listings. They tend to be much better curated across the site, pointing to a small handful of notable shops. There's also less downside to a low-quality listing; I can walk into a shop that One Guy On The Internet said was good, then walk out a minute later if I don't like it.

Gerode (talk) 15:05, 6 October 2026 (UTC)Reply

I have never really found Eat, Drink, Buy, Sleep listings to be useful in Wikivoyage or other travel guides. I use Google maps and hotel booking sites. I do see merit in listing typical foods, or a renowned place, like Montreal bagel shops, or Toronto's peameal bacon sandwich shops. Shops selling items for which a city or region is known -- those are useful. Or shops that are something to see on their own. The supermarket and convenience store listings that fill up our Philippines articles? Really not useful. Having said that, I don't have an idea for how to navigate this issue. Ground Zero (talk) 15:18, 6 October 2026 (UTC)Reply

If most of the Buy sections I see were filled with convenience stores, I'd feel the same way you do! For whatever reason, they seem to have less repetitive junk in the places I go to. Would strengthening the notability guidelines help?

If I go to a place with an interesting food scene, my typical process is to try to find recommendations from individual reviewers who seem to have good taste, then scan local subreddits for restaurant discussions with consensus picks, then use Google Maps to fill in the gaps. I'd love to see Wikivoyage be a good substitute for that middle step. Gerode (talk) 15:58, 6 October 2026 (UTC)Reply

Re: Gerode, I like your thoughtful opinion.

• I totally agree that accommodation listings shine better in rural areas with limited lodging options. Of course, other listings also shine in rural areas as useful for travellers.
• I don't know whatever dietary restrictions you have, but I think there should be separate sections for people with dietary restrictions, especially vegetarian, vegan, kosher (Jewish) and halal (Muslim). They add better value in WV than mainstream food listings.
• I definitely agree that buy listings always add better value as long as they focus on local stuff.

Sbb1413 (he) (talk • contribs) 15:39, 6 October 2026 (UTC)Reply

I think it's a good idea to have Eat and Sleep sections. (Since I don't like caffeine or alcohol, I don't have strong views about the Drink section.) However, I think that these sections often need updating in two ways:

• To figure out whether the business still exists (or at least whether there is still a restaurant or hotel at that location).
• To say something about the business that goes beyond name/location/hours.

For example, years ago, a friend of mine had a favorite restaurant in a tourist town. In this case, the business closed a few years ago, so the important thing would be to remove it. (I just checked; it's not listed.) But if it were still open, it would be important to say something like "California–Chinese fusion food" or "Usually a quiet atmosphere" (one in six adults is affected by hearing loss, and restaurant reviewers say that the #1 question they get is for a restaurants that aren't noisy).

So when I see editors saying that these sections seem useless, I wonder whether we're talking about the typical (bad) state of an average article, or if we're talking about what an article could do. WhatamIdoing (talk) 16:19, 7 October 2026 (UTC)Reply

Oh no, ideally, every section of every article should be good, helpful, and not distorted by self-interested editing. I will say that this site is being helped immeasurably by several editors who have been doing very methodical checks of whether establishments are still in business and updating rates, hours, URLs and contact information. Ikan Kekek (talk) 16:48, 7 October 2026 (UTC)Reply

I agree. I did just a little bit of that recently, and it took me to quite a lot of outdated articles. I updated the Eat and Sleep sections of Bellville (Ohio) (a little place in the middle of nowhere; you're either there because your grandmother lives there, or you're on a road trip and want some place with a restaurant or a hotel right by the highway) yesterday, as an example to make sure my advice was on the right track. I tried for a 'minimal change' for my experiment, and I was correct: the two listed restaurants had both changed names and sometimes style, and half the hotels had changed brand names, but the restaurants are still restaurants, and the hotels are still hotels. It's quite a bit better, but I will probably go back and remove at least one of the boring chain hotels. WhatamIdoing (talk) 16:47, 8 October 2026 (UTC)Reply

Because OpenStreetMap cannot incorporate our POI due to conflicting licenses, it seems redundant to try and maintain our own list of POI like the ones in these sections. I would strongly support either transitioning to using OSM POI data so that we are not duplicating efforts or scrapping these sections altogether to focus just on the unique contributions that Wikivoyage brings to the open universe Superb Owl (talk) 19:46, 8 October 2026 (UTC)Reply

I'm toying with the thought of making some sort of widget that slurps up and presents all the OSM lodging POIs within a city, so I can replace neglected Sleep sections with that widget. Gerode (talk) 20:46, 8 October 2026 (UTC)Reply

I don't think that would be useful, except for small towns (e.g., population < 25,000 in the US). In larger areas, there will simply be too many. WhatamIdoing (talk) 21:19, 8 October 2026 (UTC)Reply

It might be a bad idea, but we have thousands of articles for towns under 25,000 people with poorly-maintained Sleep sections. Gerode (talk) 22:21, 8 October 2026 (UTC)Reply

Not a bad experiment tbh. //shb (t | c | m) 23:38, 8 October 2026 (UTC)Reply

Big fan of this experiment! I wonder also if we could have a bot that updates POI fields like these as soon as it is updated in OpenStreetMap? (@Mxn: any thoughts?) Superb Owl (talk) 02:31, 9 October 2026 (UTC)Reply

I think I'd prefer a gadget over a bot, just so there's some human review involved. //shb (t | c | m) 07:57, 9 October 2026 (UTC)Reply

Wikivoyage:Listings got more distinct inclusion criteria some year ago; see Wikivoyage:Listings#Shops, restaurants and other hospitality venues and Wikivoyage:Listings#Historic buildings, sites and natural formations. Would you say that these criteria are useful? /Yvwv (talk) 09:59, 9 October 2026 (UTC)Reply

That won't be very useful outside of Anglophone, relatively rich/online areas. And I suspect that the barrier to entry to editing OSM is higher than to editing Wikivoyage (or any MediaWiki-based wiki), you'd be replacing one poorly maintained set of data with another. Daggerstab (talk) 11:16, 9 October 2026 (UTC)Reply

@Gerode, Superb Owl, Daggerstab, Sbb1413, Yvwv, Ikan Kekek: I've somewhat vibecoded a tool at User:SHB/OSMFetch which autofetches listings from OSM (it can take up to 90 seconds to load, and sometimes you may need to try again if it fails first try) – see the history of Wangaratta or Idrija for some examples. Still have yet to write documentation for it, but the UI is very self-explanatory. //shb (t | c | m) 12:35, 9 October 2026 (UTC)Reply

Thanks, that seems helpful. I noticed a small capitalization error: "Pasta, pizza" in the "content" tab shouldn't capitalize the second word. Ikan Kekek (talk) 19:07, 9 October 2026 (UTC)Reply

Appreciate the feedback. :) I'll have to figure out how to maybe omit the description altogether since the descriptions atp are mainly just raw data from OSM (that have been converted into plain text). //shb (t | c | m) 21:55, 9 October 2026 (UTC)Reply

This is cool! Took me a while to find the tool until I looked in the "..." menu, but it was straightforward from there. It's finding the same POIs I was pulling up from the Overpass API yesterday. Gerode (talk) 00:09, 10 October 2026 (UTC)Reply

Wanted to note that there still may be some outstanding licensing issues on how we use OSM data in Wikivoyage. Have created a section here: Wikivoyage:Cooperating with OpenStreetMap#Points of Interest (POI) summarizing this discussion. Superb Owl (talk) 21:09, 9 October 2026 (UTC)Reply

Thankfully CC licenses are backwards compatible – that is, we can use OSM data since OSM licenses its data under a CC-BY-SA 2.0 license, whereas OSM can't use ours because we use a CC-BY-SA 4.0 license. Not great for OSM, but works out for us. //shb (t | c | m) 21:53, 9 October 2026 (UTC)Reply

any reason why we can't change the license? -- andree 12:13, 11 October 2026 (UTC)Reply

Licenses are only forwards compatible – since we already use 4.0, we can't go back and change it to 2.0 or 3.0. OSM, on the other hand, can legally change their license to 4.0, though the mechanisms for doing so are complex (but there's similar past precedent for it with Wikinews). But the simple answer really is there's no licensing issue on our end using OSM data. //shb (t • c) 12:50, 11 October 2026 (UTC)Reply

https://osmfoundation.org/wiki/Licence says that the OSM license changed to the Open Database License, "ODbL" 1.0 in 2012. WhatamIdoing (talk) 15:09, 11 October 2026 (UTC)Reply

I stand corrected on the specific license; it doesn't change my point, however, that there's no licensing issue our way using OSM data (so long as it's attributed to OpenStreetMap per that page's guidelines you linked). //shb (t • c) 20:12, 11 October 2026 (UTC)Reply