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 Vandalism in progress.
• 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. This includes announcements, initiatives and celebrations as well as issues with certain articles.
• Anything that is Kosovo or Albania related is now meant to go in the Kosovo and Albania café instead. This includes announcements, initiatives and celebrations as well as issues with certain articles.

Pull up a chair and join in the conversation!

Click here to start a new thread

Experienced users: Please sweep the pub

Keeping the pub clean is a group effort. If we have too many conversations on this page, it gets too noisy and hard to read. If you see an old conversation (i.e. a month dormant) that could be moved to a talk page, please do so, and add "{{swept}}" there, to note that it has been swept in from the pub. Try to place it on the discussion page roughly in chronological order.

• A question regarding a destination article should be swept to the article discussion page.
• A discussion regarding a policy or the subject of an expedition can be swept to the policy or expedition discussion page.
• A simple question asked by a user can be swept to that user's talk page, but consider if the documentation needs a quick update to make it clearer for the next user with the same question.
• A pointer to a discussion going on elsewhere, such as a notice of a star nomination or a request to comment on another talk page, can be removed when it is old. Any discussion that occurred in the pub can be swept to where the main discussion took place.

Any discussions that do not fall into any of these categories, and are not of any special importance for posterity, should be archived to Wikivoyage:Travellers' pub/Archives and removed from here. If you are not sure where to put a discussion, let it be—better to spend your efforts on those that you do know where to place.

Images

Hello, all. Work-me is here with a suggestion that some of the Wikivoyages volunteer to be a "test wiki" for one of the dev teams.

Background: Web browsers don't "speak" wikitext. They speak HTML. So we write in wikitext, but it gets transformed ("parsed") into HTML. What we see, except inside the wikitext editor itself, is the parsed HTML. The old parser is very, very old (in software terms), and it's being replaced with a new-ish parser. The old parser doesn't formally have a name, but it has traditionally been called "the PHP parser" (after the software language it was written in). The newer parser is called "Parsoid". The new one does basically the same thing, plus some extra bells and whistles, and minus a few old bugs (and presumably plus a few new bugs, but those technically aren't part of the plan ;-)).

The project: Eventually, the old PHP parser will be deleted, and Parsoid will take its place. They've been working on how it handles images recently (main Phab task: T314318). The image part is already running at mw:, and it seems to be okay. I've done some fairly complex stuff there (e.g., galleries in translated pages) with zero problems. In fact, I never noticed that they switched the parser. It is supposed to be a seamless transition, and that's how I experienced it there. They want to try it out on a few more wikis.

My thinking: I think we should volunteer. First, this is going to end up here eventually, so it'd be better if if worked for us from the very beginning. I don't want Wikivoyage, which does a few unusual things with images (e.g., page banners), to be an after-thought. Second, if something goes wrong now, we'd be at the top of the list for fixes, with a team of devs available to help (or to instantly revert us back to the old parser if it can't be fixed right away). That level of hands-on support can happen if we are, say, #3 on the deployment list, and unlikely to happen if we are in the usual deployment process when they think the work is done. Just as a practical matter, if you deploy software to 500 wikis on the same day, they can't all be the #1 priority if something goes wrong. But if you're the only one this week, then you automatically are the top priority. Third, this team is very careful with their work. They have a system that can identify changes of just a single pixel(!) out of an entire page. So I think we'll be in good hands.

So I'm asking you: Are you willing to have us at the front of the line? If you all think it's okay, then I can officially ask the team to consider us. Whatamidoing (WMF) (talk) 04:49, 24 August 2022 (UTC)

Support. We don't generally use many images per WV:IP, so a significant change wouldn't really many pages. It's nice that the developers put this wiki as a priority, and given you've convinced me that, I'm all in favour of this. SHB2000 (talk | contribs | meta) 08:15, 24 August 2022 (UTC)

Despite the "minimal use of images", we do have images on virtually every page of the travel guide, so if anything major went wrong it would affect a lot of pages. But if it does, better to have the developers' full attention, right? Since it's coming for us regardless, it makes sense to support the proposal to be a guinea pig.--ThunderingTyphoons! (talk) 08:36, 24 August 2022 (UTC)

@ThunderingTyphoons!: Sadly most outline articles lack images (and sadly most of en.voy's articles are outlines) but agree that it'll affect a lot of pages. Maybe we should all go and add heaps of images to every single article to make the travel guide more colourful... ;-) SHB2000 (talk | contribs | meta) 09:16, 24 August 2022 (UTC)

I agree that it is probably better to get the problems now than to get them later. Anything major affecting all wikis will probably be noticed by the devs before rolling out the change, while what will affect us are probably minor glitches or pagebanner related stuff, things that either won't be a catastrophe or won't be noticed before it is turned on for Wikivoyage. But I don't support heaps of images on every article, we have enough for noticing problems, unless it is about unusual use of images, which I think the Wikipedias or Wikibooks will take care of. –LPfi (talk) 09:32, 24 August 2022 (UTC)

Every article with a pagebanner (so, basically all articles, including those with non-custom banners) has at least one image, so I stand by my statement. But any issue with images is unlikely to compromise the body of an article, so is a 'risk' worth taking.--ThunderingTyphoons! (talk) 09:43, 24 August 2022 (UTC)

Oh yes, how could I forget the pagebanner. SHB2000 (talk | contribs | meta) 09:44, 24 August 2022 (UTC)

@LPfi: I said "Maybe we should all go and add heaps of images to every single article to make the travel guide more colourful... " as a joke to lighten up this discussion – it was supposed to be sarcastic. Did you actually think I was being serious when I said that? SHB2000 (talk | contribs | meta) 09:44, 24 August 2022 (UTC)

No, not really. Sorry. I have just developed an allergy to the actual building of image heaps in short articles (by some on wp-sv), so couldn't take the joke. –LPfi (talk) 10:15, 24 August 2022 (UTC)

No need to apologise. Rereading my earlier comment, it does seem a bit satirical in some ways, but I too have been fed up with one user who thinks filling up entire articles full of images is a good thing or galleries that don't add a lot of meaning. SHB2000 (talk | contribs | meta) 10:19, 24 August 2022 (UTC)

Support. Whatamidoing's argument is very convincing. Vidimian (talk) 22:39, 24 August 2022 (UTC)

Requesting changes

Thanks for the support. It might be helpful / expedient if I had the privileges necessary to edit any interfaces that may be broken by the change. For example, I've requested the following change in preparation, Template_talk:Banner#Prepare_for_T314318. But I'm happy to work with any editors who can facilitate the changes. Arlolra (talk) 21:54, 13 September 2022 (UTC)

Arlolra is Arlo Breault from the mw:Parsoid team. I say this without exaggeration: These are the folks who know, better than anyone else in the world, how wikitext gets turned into what readers see on their screens. We really ought to take him up on his offer to fix things for us. I think admin rights will be enough, but it's possible that interface_admin will be needed at some point. WhatamIdoing (talk) 15:46, 14 September 2022 (UTC)

Thanks, WhatamIdoing for the much-needed introduction. Would you like to nominate Arlo at WV:URN? --ThunderingTyphoons! (talk) 20:06, 14 September 2022 (UTC)

Does that feel like it would be a conflict of interest? WhatamIdoing (talk) 23:44, 15 September 2022 (UTC)

Since there were no further comments, I have posted Wikivoyage:User rights nominations#Arlolra. WhatamIdoing (talk) 02:07, 21 September 2022 (UTC)

Deployed

The change was deployed and is now live on wiki https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/830707 Please let us know if it causes any disruption. Thank you Arlolra (talk) 13:24, 21 September 2022 (UTC)

Would you like to test the “show nearby articles” feature in Kartographer?

Hello!

The Technical Wishes team from Wikimedia Germany is deploying an additional feature to Kartographer: soon it will be possible to automatically show nearby articles on a map in an article page.

Would English Wikivoyage like to be among the first wikis to test the show nearby feature?

It will be available on the first wikis presumably at the end of September or beginning of October. More information, also regarding Wikivoyage’s similar “Show nearby destinations” feature can be found on the project page, questions and discussions are welcome here.

Please let me know here if you are in favour.

Thanks a lot,

Timur for the TechWishes team Timur Vorkul (WMDE) (talk) 15:22, 8 September 2022 (UTC)

Who might be interested in this? FredTC and Renek78 were asking about map problems a while ago, but who else? WhatamIdoing (talk) 16:06, 8 September 2022 (UTC)

Ooh that seems fancy and useful. I'm definitely in favour of this new feature. SHB2000 (talk | contribs | meta) 00:45, 10 September 2022 (UTC)

• Sounds and looks interesting to try out! - Matroc (talk) 04:28, 12 September 2022 (UTC)

We already have this, see: here. But it seems that they will improve it. Right now it needs manual updating of a list/table somewhere (I don't know where). In the Venice article you can see that it needs to be updated, the sestieri San Marco and Castello have no markers using this function now. --FredTC (talk) 08:19, 13 September 2022 (UTC)

Thanks for your reactions!

So I interpret the positive responses and the general excitement as a yes and have included enWikivoyage into the deployment ticket

Tracked in Phabricator ^(?)
Task T316782

. I will let you know the exact deployment date when it's set.

Thanks also for providing the example of Venice so we can keep an eye on once the new feature is available. Timur Vorkul (WMDE) (talk) 11:24, 14 September 2022 (UTC)

@WhatamIdoing @FredTC @Renek78@SHB2000 @Matroc

The deployment of the feature is going to happen next week. The question now is how to proceed with the already existing “show nearby destinations feature”. Technically, both are not in conflict with each other and can exist in parallel for testing purposes.

• Should the existing feature already be turned off or should the old and the new co-exist during the testing?
• If turned off, would you like to do it or should the Technical Wishes team?

Thanks again for you input. Timur Vorkul (WMDE) (talk) 17:19, 27 September 2022 (UTC)

I lean towards having both, but I don't feel strongly about it. WhatamIdoing (talk) 16:12, 29 September 2022 (UTC)

The show nearby articles feature in Kartographer was just deployed to your wiki. Please don't hesitate to share your impressions or ask questions on the project's discussion page. Your input on the prepared feedback questions will help to improve the feature. Thanks! Timur Vorkul (WMDE) (talk) 15:30, 12 October 2022 (UTC)

InternetArchiveBot

InternetArchiveBot has started editing pages here. I think that some of this is useful, but in many cases the dead link may be of more use to readers than an archive page. A dead link for a restaurant warns that the place might of closed, and I expect most readers would make other checks before visiting, but if they don't notice the archive banner, they will see last year's menu and assume that the place is open.

It probably is worth archiving links in Understand and similar background information, but not those in Eat or Sleep. It might also be useful to provide the archive page after the dead link, with an explanation: eg: timetable (dead link, archived page). AlasdairW (talk) 22:30, 11 September 2022 (UTC)

Alasdair, I agree with you about the risks, and I've disabled the bot for now. Ocaasi, Cyberpower678, Harej, why are you running User:InternetArchiveBot here? Are you running it on any other Wikivoyages? See Wikivoyage:Welcome, Wikipedians#Style differences: "Wikivoyage articles use no references." There are consequently no sources for the bot to rescue on this wiki. I don't think that the bot should be adding archive.org links at any of the Wikivoyages.

If, on the other hand, you were willing to add {{dead link}} (which places the article in Category:Articles with dead external links), then I imagine that some editors might think that was useful. WhatamIdoing (talk) 05:30, 12 September 2022 (UTC)

I went through the first five edits by the bot. All of them were suboptimal. Some needed removal (e.g., ferry service that appears to have shut down); some needed a correct link (e.g., new domain name or re-arranged website). None of them were edits that the bot could have made correctly. WhatamIdoing (talk) 05:42, 12 September 2022 (UTC)

I've indefinitely blocked the bot as an unauthorized bot and will rollback all the bot's edits. The bottom line is, there's simply no need to run a bot like that on a travel guide. SHB2000 (talk | contribs | meta) 08:12, 12 September 2022 (UTC)

Reverted all. I will also add that this bot has also been removing dead link tags and supposedly replacing them with archive.org urls which is worse than nothing. SHB2000 (talk | contribs | meta) 08:29, 12 September 2022 (UTC)

It's not necessary for the bot to be blocked. It has a built-in system for disabling it on any wiki. You don't even need to be an admin to do this. WhatamIdoing (talk) 17:46, 12 September 2022 (UTC)

@WhatamIdoing: We didn't realize that the act of adding archive URLs was actually doing Wikivoyage a disservice. Since the bot is approved as a global bot and enwikivoyage is listed among the wikis that allow them, we simply deployed to this wiki. This of course is in contrast to what SHB2000 (talk · contribs) is claiming, since they blocked the bot as unauthorized. Either way it seems the act of marking links as dead is much preferred over adding archives to them. We can modify the bot to accommodate this.—CYBERPOWER (Chat) 12:49, 12 September 2022 (UTC)

@WhatamIdoing: I thought Wrh2's bot already did the same thing (though it's not currently running). SHB2000 (talk | contribs | meta) 08:30, 12 September 2022 (UTC)

I agree that these edits are not appropriate. Thank you for reverting them, SHB2000. It's useful for a bot to tag dead links for human review, but automatically replacing them with archived copies allows out-of-date information to remain unnoticed. This is a big difference between a travel guide (full of practical advice that needs to be updated often) and an encyclopedia (full of factual exposition that is often historical in nature). —Granger (talk · contribs) 09:34, 12 September 2022 (UTC)

If Ryan's bot isn't currently running, and IABot could do this now, I think we should unblock the bot and let them tag dead links for us. And to forestall any potential confusion, I mention now that if a website is down for an hour, then anyone (bot or human) might mistakenly believe that it was a dead link. We should always expect a small percentage of false positives in this kind of work.

@Cyberpower678, I think you'll want to use tag-only mode at all the Wikivoyages, and be careful about the namespace for Wikisources. Also, I don't think the local template technically supports the |date= parameter, but I think it would be a good idea to include a date anyway. I believe that's how the bot is already set up anyway. WhatamIdoing (talk) 15:55, 12 September 2022 (UTC)

The bot is generally very flexible with how it should behave. The only thing I need to do is actually add an option to reconfigure the bot to do tag-only work, since the bot was designed around the principle that archives are better than dead links. This shouldn't take very long to implement. I have opened a phabricator ticket to track this work at phab:T317553. —CYBERPOWER (Chat) 17:00, 12 September 2022 (UTC)

Thanks. I think that would be helpful. WhatamIdoing (talk) 17:36, 12 September 2022 (UTC)

Yes: thank you. –LPfi (talk) 11:12, 13 September 2022 (UTC)

I see that InternetArchiveBot tag only feature is now being tested - see User:Cyberpower678/sandbox. SHB2000, I think that the bot can now be unblocked, but I would ask that the bot only tags a few pages per day until it has been further discussed. AlasdairW (talk) 23:13, 30 September 2022 (UTC)

@AlasdairW: Done. SHB2000 (talk | contribs | meta) 23:34, 30 September 2022 (UTC)

We are back (student assignment in Asia)

Hello Wikitravellers! After a few years break, I am back to unleash a bunch of students (mostly Korean and Chinese) on some topics (you can find some old annoucements of mine and accompanying discussions in the pub's archives). Interested editors may also want to check our syllabus (tinyurl.com/wikivoydata) and/or dashboard (tinyurl.com/dashwikivoydata2022). The student list in the dashboard as well (account names). I expect most activity to be concentrated in the topics related to South Korea and China; I'll do my best as usual to ensure the editing is constructive and so on, and I apologize in advance for any extra work. Hopefully, just like in the past, we will end up with several new or improved articles for those regions. For results of past projects see the list I maintain at https://en.wikipedia.org/wiki/User:Piotrus/Educational_project_results (CTRL+F Wikivoyage). Thanks for hosting us :) Piotrus (talk) 10:44, 15 September 2022 (UTC)

Ooh another expedition – that sounds nice. I'm willing to do any cleanups if necessary, but thanks for hosting this expedition :-). SHB2000 (talk | contribs | meta) 11:53, 15 September 2022 (UTC)

Welcome back, Piotrus, and welcome to your students! Is there any type of editing you'd like us to hold off on for a particular period of time while your students work? Ikan Kekek (talk) 00:02, 16 September 2022 (UTC)

@Ikan Kekek @SHB2000 Thanks! No, carry on as usual :) Ideally, when reverting students, it would be best to leave them explanation on their talk page or edit summar AND ping me so I can notice this and provide my own explanation of the problem, in class or otherwise. My past experience is that most students don't expect constructive, or any feedback from wiki volunteers, so some don't even realize they've been reverted, and if they do, they don't know why (particularly, please note, most students won't notice comments in edit summaries, not until I individally point that feature out, or show it in class numerous times). On a side note, do note that most of my students will have issues with English proficiency (despite taking an English-language university class, which is what I am teaching), so expect that some edits will need routine copyediting for grammar/vocabulary (more than if I was teaching the class in a country of native English speakers). Piotrus (talk) 03:06, 16 September 2022 (UTC)

Sure thing. I usually try to abstain reverting edits made during an expedition unless it’s a serious copyvio and/or if it’s out of scope. I’m willing to try making the text more idiomatic if needed. ——SHB2000 (talk | contribs | meta) 05:38, 16 September 2022 (UTC)

@Piotrus: you make a good point, not just with your students but newbies more generally, that communicating with them via edit summaries is often a pointless exercise. I've seen experienced editors do this on all wikis and they often link to policies using jargon and acronyms, which a new editor would have no clue about. It won't make them learn about the rules and policies here if 1. they don't know what edit summaries are and where to find them and 2. the policies aren't explained more clearly and simply (e.g. even if a new editor reads the edit summary, reverting an edit and typing WV:MOS is not going to make the editor read the manual of style). It's something I try to avoid to do when I copyedit a newbie's edits. Best of luck to your students! Gizza ^(roam) 06:12, 16 September 2022 (UTC)

@DaGizza Indeed. Whatever we write in an edit summary is a message to other experienced editors, but expecting a new editor to notice it is futile. If one wants to communicate with a newbie, leaving them a message on their talkpage is the only reasonable approach. In other news, students are startign to select their topics. 1/3 of the expected list (2/3 haven't decided yet) is Jeju, Sokcho, Daegu, Jiaxing, Damyang, Gunpo (will need to be created, see :wikipedia:Gunpo), Xishuangbanna....if anyone feels like watchlisting them early until the end of the year :) I'll report other topics in a week or so. Piotrus (talk) 08:49, 16 September 2022 (UTC)

Nice. Just a heads-up, your tinyurl link (tinyurl.com/wikivoydata) is broken. Would be interesting if they wish to expand Korean and Chinese Wikivoyage articles after the course is over. I know it's out of the scope of your class, but those wikis are in worse shape than English. OhanaUnited^{Talk page} 06:07, 17 September 2022 (UTC)

@OhanaUnited My bad, it shoul be tinyurl.com/wikivoydata2022 (I can't link url as tinyurl and google docs are blacklisted as spam links or such at media wiki level, sigh). Note there is no live Korean Wikivoyage project. In my Wikipedia classes, I have students edit Korean and Chinese Wikipedia, but due to no Korean WIkivoyage, we just focus on English Wikivoyage for the WV class. I'd love to see Korean WV started one day, maybe by one of my students, but so far it hasn't happened yet... Piotrus (talk) 08:57, 19 September 2022 (UTC)

@Piotrus: btw, there's a Korean Wikivoyage currently in the Wikimedia Incubator – see incubator:Wy/ko/위키여행:대문. It still needs quite a lot of expansion, though. SHB2000 (talk | contribs | meta) 11:09, 19 September 2022 (UTC)

@SBH2000 Right, I did find it before, but incubator is not "live"; I gave up trying to explain to my students how to use it (I don't think pages there can be connected to wikidata, for example). Frankly, I think we are doing a disservice to everyone keeping stuff hidden there - it should be live and then it could grow (for example, with the help of my students, whom I could get to write or translate a dozen+ articles every year). Piotrus (talk) 12:32, 19 September 2022 (UTC)

@SHB2000 Ooops, pinged a wrong user... Piotrus (talk) 12:32, 19 September 2022 (UTC)

URL shorteners are blocked everywhere because they tend to be favored by spammers. I thought you could like directly to full URLs for Google docs, though. Yours is https://docs.google.com/document/d/1tdHX3H7_fQZSthOXGAXYWbVlVBPbkIyorXvjIa1rgaQ/edit. WhatamIdoing (talk) 16:06, 19 September 2022 (UTC)

Oh yeah, I almost forgot - some of you may find it fun to check out my Prezis about Wikivoyage (see https://en.wikipedia.org/wiki/User:Piotrus/Sociology_course_prezis#Wikivoyage_and_Wikidata). I may develop some more (ideas are welcome!). --Piotrus (talk) 13:58, 19 September 2022 (UTC)

@User:SHB2000, User:OhanaUnited, User:Ikan Kekek. Updating with list of articles chosen to improve by students for those who would like to watchlist them: Daegu, Damyang, Dongducheon, Gunpo, Hwaseong Fortress, Jeju, Jiaxing, Jinzhong, Jirisan National Park, Laiwu, Lianyungang, Pohang, Rivierenland, Sokcho, Tongren (Guizhou), Weihai, Xishuangbanna, Yeongdeok County, Zhangjiajie, Zhoushan. --Piotrus (talk) 06:50, 1 October 2022 (UTC)

Thank you for providing us with the list of articles. I'll definitely be putting at least some of them on the watchlist. Feel free to let your students create new articles if they meet WV:WIAA. Small towns are welcome if they are adequate tourist destinations as well. --Comment by Selfie City (talk) (contributions) 14:40, 3 October 2022 (UTC)

Thanks for this list. Also, for the regulars: Edit conflicts are really difficult for newbies to handle. Please try not to jump on the article until the students have stopped editing. I don't know what to expect from this specific group, but the rule of thumb from some enwiki research is that if someone hasn't saved an edit in the last half hour, they're probably offline. WhatamIdoing (talk) 16:21, 3 October 2022 (UTC)

Incubator links

Hello. I noticed the existence of {{Incubator}} template. Documentation is rather contradictory as it first states it's for linking another language Wikivoyage like interwiki does, but for Incubator test Wikivoyage instead, and then the rest of the documentation says default project is Wikipedia and Wikivoyage isn't even listed at all. I began my question at Template talk:Incubator if that is intended or somebody wasn't quite paying attention while copying template over from Wikipedia I guess. It's rather confusing and I don't know if that template is even needed. However it seems like it would be quite useful template to raise awareness of newly developed languages of Wikivoyage (just a side note, we're building a Czech Wikivoyage over on Incubator), but that would be only possible if Wikivoyage was even supported (yes, I have tried it on Wikivoyage:Graffiti wall, didn't save the changes, only displayed a preview, which is enough). I intended to come here and use that template to link up newly developed article over on the Czech Wikivoyage that's still in Incubator, to kind of bring more people into it, hopefully fellow Czech people living abroad or knowing English enough they are active here. But there are more languages of Wikivoyage currently developed, and I can see the template isn't actually used anywhere. What is the true purpose of the template then? Polda18 (discussion • contributions) 06:36, 20 September 2022 (UTC)

@Congariel:, as you evidently imported it. —Justin (koavf)❤T☮C☺M☯ 06:41, 20 September 2022 (UTC)

Seems like it's intended to be at phrasebooks, which seems sensible enough. —Justin (koavf)❤T☮C☺M☯ 06:48, 20 September 2022 (UTC)

I see. It does specify a language article, which may indeed mean a phrasebook. I didn't quite notice that at first. Polda18 (discussion • contributions) 07:22, 20 September 2022 (UTC)

Listings in travel topic articles

I noted that some listings in Public transportation#Museums covering urban rail include phone numbers, opening hours or other details that are prone to change, and none of them link to the listing in the relevant destination article. All instead link to the venue's web site. This means that readers might miss the description in the primary listing and that any updates have to be done in two places or one will be outdated, probably this one.

I think we have kind of consensus that listings should foremost be in the destination article, and a listing elsewhere "would probably just duplicate content that should instead be placed in the main [destination] articles". Should something be written into some guideline, such as (the yet to be created) Wikivoyage:Travel topics?

A listing in an article can be linked using the name of the venue as given in the listing: Brooklyn/Downtown#New York Transit Museum will take you to the listing as long as the name parameter isn't changed. Using the Wikidata ID as in Brooklyn/Downtown#Q6886122 is more reliable as Wikidata IDs don't change, but less obvious (and the listing may still be moved to another page).

Should we start linking the primary listings in secondary listings, such as in travel topic articles: "name=[[Brooklyn/Downtown#Q6886122|New York Transit Museum]]" (or "name=...#New York Transit Museum|...")? I think listings in the travel topic articles should contain just the information needed for the reader to decide whether they are interested in the place listed. If the URL of the place(which often is very relevant to that decision) isn't shown, two clicks would be needed to reach the site, but I think that is less of an issue than that you might have a listing with a dead link, updated in an article you perhaps cannot easily find.

In some articles the link to the main listing is in the directions parameter, leading to the article where the listing is assumed to be. Consistently linking the listing would more or less ensure that editors find the article which really contains the listing, and have them create the listing there if not already present.

(Links in itineraries should probably be discussed separately, as their listings aren't always relevant in other contexts.)

–LPfi (talk) 07:51, 21 September 2022 (UTC)

I would support writing this into the guidelines if it isn't already.--ThunderingTyphoons! (talk) 08:22, 21 September 2022 (UTC)

I would mostly support this. The only exceptions should be if a travel topic covers a listing that does not have a city or park article, or if it's listed in a topic article but would fail WV:WORSHIP. SHB2000 (talk | contribs | meta) 08:32, 21 September 2022 (UTC)

Support. I think the guideline should be: only provide the name of the attraction, tell why it would be interesting to the readers of the topic article in question and give an internal link (could be in various forms; I don't have a specific preference and usually copy the style the previous editors of an article overwhelmingly used) to the destination article, the lowest in the geographical hierarchy possible, where it is (or is expected to be, if not already) listed or otherwise mentioned (e.g. the region articles), and leave the further details to that article. As an aside, I've found the topic articles to be very helpful in catching what listings are missing in the linked destination articles. Vidimian (talk) 10:16, 21 September 2022 (UTC)

Though before we proceed to rounds of edits removing the extra details discussed here from the topic articles, I'd recommend checking the destination articles to see if they are already provided there, and if not, moving them, so we don't get rid of valuable information once and for all from anywhere at Wikivoyage. Vidimian (talk) 10:21, 21 September 2022 (UTC)

I'd hesitate to try to require users to use Wikidata links. There's a learning curve and a hassle factor to finding them. Ikan Kekek (talk) 17:37, 21 September 2022 (UTC)

No, we shouldn't. I think we should either just recommend copying the name from the listing (and checking that the link works) or additionally point out the Wikidata option, to be used at editors' discretion when the name might be unstable. –LPfi (talk) 19:20, 21 September 2022 (UTC)

Generally I support adding this to the guidelines. In most cases I think it is sufficient to just link to the city article without linking to the individual listing - in some cases a topic may have one listing and the city article has two or more (e.g. some cities linked from Art Deco architecture). Many listings don't have Wikidata values and we shouldn't suggest that these need to be created. There are very few cases where a listing belongs in a topic, and so a specialist reader might make an international journey to see it, and yet not in the city article for a general reader who is walking past; an exception might be for very local travel topics.

I prefer to keep the URL in the topic article, as this can point to a topic relevant part of the site for complex attractions and for ease of tracking things as an editor - if I edit the topic, it gets added to my watchlist and then I know if a bot flags the link as dead, but I am probably not watching the city article. AlasdairW (talk) 22:21, 21 September 2022 (UTC)

The Vector 2022 skin as the default in two weeks?

The slides for our presentation at Wikimania 2022

Hello. I'm writing on behalf of the Wikimedia Foundation Web team. In two weeks, we would like to make the Vector 2022 skin the default on this wiki.

We have been working on it for the past three years. So far, it has been the default on more than 30 wikis, including sister projects, all accounting for more than 1 billion pageviews per month. On average 87% of active logged-in users of those wikis use Vector 2022.

It would become the default for all logged-out users, and also all logged-in users who currently use Vector legacy. Logged-in users can at any time switch to any other skins. No changes are expected for users of these skins.

• Top of an article
• 
  Vector legacy (current default)
• 
  Vector 2022

• A section of an article
• 
  Vector legacy (current default)
• 
  Vector 2022

About the skin

[Why is a change necessary] The current default skin meets the needs of the readers and editors as these were 13 years ago. Since then, new users have begun using Wikimedia projects. The old Vector doesn't meet their needs.

[Objective] The objective for the new skin is to make the interface more welcoming and comfortable for readers and useful for advanced users. It draws inspiration from previous requests, the Community Wishlist Surveys, and gadgets and scripts. The work helped our code follow the standards and improve all other skins. We reduced PHP code in Wikimedia deployed skins by 75%. The project has also focused on making it easier to support gadgets and use APIs.

[Changes and test results] The skin introduces a series of changes that improve readability and usability. The new skin does not remove any functionality currently available on the Vector skin.

• The sticky header makes it easier to find tools that editors use often. It decreases scrolling to the top of the page by 16%.
• The new table of contents makes it easier to navigate to different sections. Readers and editors jumped to different sections of the page 50% more than with the old table of contents. It also looks a bit different on talk pages.
• The new search bar is easier to find and makes it easier to find the correct search result from the list. This increased the amount of searches started by 30% on the wikis we tested on.
• The skin does not negatively affect pageviews, edit rates, or account creation. There is evidence of increases in pageviews and account creation across partner communities.

[Try it out] Try out the new skin by going to the appearance tab in your preferences and selecting Vector 2022 from the list of skins.

How can editors change and customize this skin?

It's possible to configure and personalize our changes. We support volunteers who create new gadgets and user scripts. Check out our repository for a list of currently available customizations, or add your own.

Our plan

If no large concerns are raised, we plan on deploying in the week of October 3, 2022. If your community would like to request more time to discuss the changes, hit the button and write to us. We can adjust the calendar.

Request for more time to discuss the change

Also, if you'd like ask our team anything, if you have questions, concerns, or additional thoughts, please ping me here or write on the talk page of the project. We will also gladly answer! See our FAQ. Thank you! SGrabarczuk (WMF) (talk) 03:19, 22 September 2022 (UTC)

Questions for the devs

@SGrabarczuk (WMF): Thank you for the presentation of the new skin, and for this period of consultation. There's a lot to take in.

I have a question: on most desktop versions of Wikivoyage (though not the one you tested on - de.voy), the table of contents of all mainspace articles appears in the pagebanner (Template:Pagebanner) at the top of the page. As I crudely understand it, the presence of a pagebanner on a WV page overrides the current default table of contents. Will this feature still work with the new, 'sticky' TOC? Your FAQs suggest they might not be compatible. (mw:Reading/Web/Desktop Improvements/Frequently asked questions#How can I get both the old and the new table of contents?). As far as I know (I'm not active on every project), the Wikivoyages are the only wikis to use pagebanners in this way. Have you tested the new skin on a wiki with pagebanners? --ThunderingTyphoons! (talk) 07:38, 22 September 2022 (UTC)

I switched to the new skin and it looks like both the pagebanner and sidebar TOCs work under the new skin. I do have a few observations:

• The new TOC can be hidden but I can't find a way to unhide it without reloading the page.
• The "sticky header" doesn't seem to work here -- the screenshot shows the search icon, page title, and other icons remaining at the top of the screen, but I don't see that here on Wikivoyage. Possibly because our page titles appear superimposed on our pagebanners?
• The reduced content width negatively affects the appearance of our pagebanners. In particular, the TOC text on them is now too small, but the banners themselves also appear too short (vertically); aesthetically they would look better taller.
• If there is *any* way we could get the pagebanners to stay at the top of the page as people scroll (the way the new TOC does) it would be awesome. If that could be done we could hide the new TOC by default.
• The new skin doesn't play well with the experimental Mobile Sidebar Preview gadget.

-- Powers ^(talk) 13:10, 23 September 2022 (UTC)

I gave it a quick try and I think that I generally prefer the old skin.

• The larger left margin and some extra stuff at the top results in the page (at first) displaying less of the article - I prefer the old width of margin.
• I liked the way that the left margin disappeared (into a button) when I reduced the browser window size.
• I didn't like the language links now appearing as a drop down at the top of the page - this take up space and I have to click on the link to see what languages are available.
• The Wiki Love Monuments banner now displays across the full width of the page.
• The pub TOC (this page's TOC) now has a scroll bar. Many entries which were one line in the old skin now spill into two.
• When I scroll down in the pub, "Add Topic" is displayed on the static bar at the top, but not other editing tools. I wonder if this might result in new editors adding new topics when they just wanted to add to an exiting one.

I note that some other wikis have very high opt-out rates of active editors. Has any investiagtion been done as to why it is so high (90%) on viwikibooks? AlasdairW (talk) 14:40, 23 September 2022 (UTC)

I've been using the 2022 for awhile and generally find it a vast improvement.

• 2022 Header is "sticky" on the pub, but not on article pages. Would be great to have it working everywhere.
• 2022 ToC is missing an "unhide" option as powers mentioned, but for me it's not a big deal.
• WV pagebanners have some display issues with the new theme which I have addressed for myself here and here. I got consensus to make some of these changes awhile ago, but not permission to edit the global CSS file. I'd be happy to apply any updates people want. Let me know if interested.
• The "stickyness" of pagebanners isn't important to me. The new ToC handles it well and takes up less screen real estate.
• Thank you for all the hard work putting vector 2022 together!

ButteBag (talk) 15:01, 23 September 2022 (UTC)

@ThunderingTyphoons!, @LtPowers, @AlasdairW, @ButteBag, thank you for your comments. You've shared a lot of good feedback to address! I very much respect that. It's a pleasure to see this much constructiveness. 🙇 Allow me to only address some points now, though.

• "Can't find a way to unhide it" - that may be a problem indeed. There are different situations:
  • In some namespaces, like Wikivoyage or Talk - there is the sticky header; when you collapse the ToC, the ToC icon appears next to the page title or in the sticky header.
  • In some namespaces, like main - there's no sticky header; the icon appears next to the page title or in the bar where the page title would be. So you need to go all the way to the top of the page. But if there's no page title, the icon is on the right side of the screen, next to the language switcher. Right now, I'm not sure if this is the best solution. I'll be happy to talk about that more.
• The appearance of our pagebanners - that's an interesting point. Any ideas what could improve this?
• Get the pagebanners to stay at the top of the page as people scroll - this is a bit beyond the skin itself, but let's keep talking.
• Mobile Sidebar Preview and other gadgets - we provide support to adjust gadgets, update their compatibility with API, and make them more future-proof.
• Banners being displayed at the full width - while limiting the content width helps readability, banners are "consumed" differently. There seemed to be no reason to change their width.
• High opt-out rate - we haven't done that. The results are relatively new, so we haven't had the opportunity to do that yet.

SGrabarczuk (WMF) (talk) 21:29, 23 September 2022 (UTC)

So part of the issue is that we hide the page title and then use it superimposed on our pagebanners. So the fancy "keep the page title at the top" magic of Vector 2022 doesn't work right. Is there any way to identify the breadcrumb trail and pagebanner as parts of the page that should be kept at the top? I'd even be fine dropping the TOC from our pagebanners since the new TOC is off to the left, out of the way. Powers ^(talk) 22:45, 23 September 2022 (UTC)

Discussion

Meanwhile the wikis are burning in my eyes due to the white background, because most software and systems support a dark mode nowadays, just the wiki world does not. As a workaround I wrote some dark mode styles which works almost fine on the most wikis here especially my home wiki voy/de. You can take a look there. If somebody is interested, there.., but your system has to be set to dark mode. My styles use a media query - and I use the nice timeless skin.

But anyway, I would recommend to you to remove all color and designs statements from your templates and use classes instead. we did it on voy/de and besides we use a voy- Prefix to avoid crashes with other classes. So you are prepared for future developments and the user have a better chance to create some own styles. I got the message here recently with color statements in the box and had no chance to read it. Drop me a line, if you need some help. Winter is coming and maybe I have some time. -- DerFussi 18:51, 24 September 2022 (UTC)

A bit concerned about the lack of discussion here, given the imminence of the change and the disruption to our page formats. Powers ^(talk) 21:35, 29 September 2022 (UTC)

Thanks for the alert. I didn't realize this change was in the works because I haven't scrolled through the pub in a while. I've just switched to Vector 2022 and I think it looks cleaner than the previous style. I'm noticing some quirks with the spacing that need changes, but given the near date of implementation, I'd suggest we implement the new style first, and then focus on ironing out the minor quirks? --Comment by Selfie City (talk) (contributions) 21:55, 29 September 2022 (UTC)

To me, the worst problem with the current skin is the waste of screen real estate for the left column. I do sometimes need that stuff but do not want to pay what I see as exorbitant cost to get it. The new skin not only does not fix that, it makes it worse by widening the column. Pashley (talk) 01:52, 30 September 2022 (UTC)

Are you concerned about the collapsible side bar (e.g., links to RecentChanges)? I tend to just collapse it and only open it when I need it. WhatamIdoing (talk) 04:18, 30 September 2022 (UTC)

I use the skin on de.voy whilst reading and I quite like it. However, one of the key issues is that our main page map doesn't cater the new skin. If someone can fix that, then I might use it. SHB2000 (talk | contribs | meta) 02:07, 30 September 2022 (UTC)

Maybe I can take a look it as well and do some tests. I have switched to the new vector on this wiki and will look around everywhere. -- DerFussi 07:15, 30 September 2022 (UTC)

Should we postpone the implementation? From my reading above, the issues aren't marginal, and having them fixed before implementation would avoid disruption (re-adjusting to some features being moved around is very frustrating). I don't have much to say otherwise, as I haven't been playing around much with Vector 2022 (and not at all on this site) and don't use legacy Vector, so comparing is difficult. –LPfi (talk) 08:15, 30 September 2022 (UTC)

Support postponement. I'm still trying the skin out, and am pleased to see my concerns about the TOC in the banner were unfounded, but have noticed other issues that irritate:

• The listing template is H U G E, like the dialogues on an early 2000s PC game.
• Sister project links are absent.
• Interlanguage links are two clicks away instead of one.
• Essential sysop buttons like other users' contribution history and user rights tucked away god knows where.

Clearly many of those won't affect new or logged-out users, but the narrow pagebanners and weird listing editor definitely will.--ThunderingTyphoons! (talk) 09:41, 30 September 2022 (UTC)

I also support postponement. As I mentioned earlier, the main page map gets cut off – you can't see anything east of Kerguelen / Heard Island and McDonald Islands. I don't have an issue with the not so large listing template, but maybe that's on my screen. Like tt!, I also have an issue with the narrow pagebanner. SHB2000 (talk | contribs | meta) 09:48, 30 September 2022 (UTC)

Actually, never mind, the listing editor is really huge. SHB2000 (talk | contribs | meta) 09:49, 30 September 2022 (UTC)

I assume the sister project links are in the "main menu" together with the toolbox etc. also for you.

The rest of the left menu is less relevant for casual readers, but the language links (now in the top right corner) and the sister project links really add to what we are trying to serve readers. Moreover, while you can click the menu button for things like the permanent link or the Travellers' Pub when you need them, and the current menu icon placement may be natural for them, the sister project links are intimately connected to each article and you don't want to click the menu on and off for them. Should they be placed with the language links? ("2 languages<br/>3 other projects")

–LPfi (talk) 10:21, 30 September 2022 (UTC)

The listing editor seems to be about 150% zoom on my laptop. I don't entirely dislike it, but it is definitely big.

Sister links (e.g., Wikipedia) are in the collapsible left sidebar. Interlanguage links (e.g., German Wikivoyage) are at the top of the page. The top-of-page button gets used more, so if your goal is to increase traffic between the Wikivoyages, then the new location is better. WhatamIdoing (talk) 14:23, 30 September 2022 (UTC)

The problem is that Wikipedia, Commons, Wikidata & al are hidden away together with entries that mostly interest regulars. They should be moved to be together with the language links. Especially Wikipedia is of interest for most readers, but I think all of the sister project links should be available without having the main menu visible all the time or clicking it on (and off) for every guide visited. –LPfi (talk) 15:36, 30 September 2022 (UTC)

I agree with you. Ikan Kekek (talk) 17:58, 30 September 2022 (UTC)

I don't like the language links being separated from the sister project links. The language links are now in the same place as on many other websites, but we are different from other websites which usually have the complete website translated into another language. We don't - we have a different website with different content. I think that occasional readers will come here, start reading the article on a major destination like London, choose their preferred language from the 20 available on that page, and then conclude that we don't have an article on Berwick-upon-Tweed because they haven't chosen one of the 3 languages that has a page for there. Keeping the language links next sister projects makes it clearer that they are different pages. AlasdairW (talk) 22:49, 30 September 2022 (UTC)

Hello everyone. Thank you for these comments. I see that you're having a nice discussion, and you'd like to have more time. I'll definitely address your ideas for fixes. First though, I wanted you to know that we decided to start with a smaller number of even smaller wikis, Wikipedias only. I'm sorry for confusion! According to the current plan, we could make the change here in the week of October 17.

If you're interested in the project, I'm encouraging you to subscribe to the newsletter, and keep an eye on the timeline of deployments.

Thank you again. SGrabarczuk (WMF) (talk) 13:58, 5 October 2022 (UTC)

Announcing the preliminary results of the 2022 Board of Trustees election Community Voting period

You can find this message translated into additional languages on Meta-wiki.

More languages • Please help translate to your language

Hi everyone,

Thank you to everyone who participated in the 2022 Board of Trustees election process. Your participation helps seat the trustees the community seeks on the Wikimedia Foundation Board of Trustees.

These are the preliminary results of the 2022 Board of Trustees election:

• Shani Evenstein Sigalov
• Mike Peel

You may see more information about the Results and Statistics of this Board election.

The Board will complete their review of the most voted candidates, including conducting background checks. The Board plans to appoint new trustees at their meeting in December.

Best,

Movement Strategy and Governance

This message was sent on behalf of the Board Selection Task Force and the Elections Committee.

Zuz (WMF) (talk) 08:52, 22 September 2022 (UTC)

Does Wikovoyage accept articles about individual castles?

Some castles are very large, UNESCO level, need their own maps, etc. But I checked and Louvre, Himeji Castle, Wawel, Windsor, Nueschwanstein, anything else I checked is just a listing, occasionally a section with several listing in an article about a given location (the only exception I found so far is Beijing/Forbidden_City. Is this intentional? Would any attempt to create an article about a castle or similar attraction in the form of a dedicated article be reverted? For more context, one of my students (see few posts above) wanted to write a guide for Suwon Hwaseong (a large castle, UNESCO heritage site, in Korea), now just a short listing in Suwon. Can he start to write stuff at Suwon/Hwaseong Fortress or should I tell him to chose a different topic? Piotrus (talk) 05:54, 3 October 2022 (UTC)

No, castles should be listed in the article for the nearest town. The Forbidden City is far from being just a castle. See Wikivoyage:What is an article. Ikan Kekek (talk) 05:59, 3 October 2022 (UTC)

Most listings for castles have links to Wikipedia articles. You could add any info to those articles if it's relevant. -- WOSlinker (talk) 10:02, 3 October 2022 (UTC)

...but we have articles on some ruins (Ephesus), also on some airports. If it's a few pages long article with floor maps, links, pictures, some 'short history'/context info... I'd reckon such a castle article would be OK? Basically a better equivalent to guide pamphlet (or audioguide) you get along with your ticket in such places... -- andree 08:44, 4 October 2022 (UTC)

What article do we have that's about a single building? A castle is a single building. If this is more than a single building, I don't think it's just a castle. Ikan Kekek (talk) 08:56, 4 October 2022 (UTC)

Based on w:Hwaseong Fortress, this is much more than a castle and might fulfill the criteria of Wikivoyage:What is an article. But I'd suggest starting it as a listing and seeing how much travel-related (non-encyclopedic) information is in the listing and whether it starts to overwhelm the Suwon article. Ikan Kekek (talk) 08:59, 4 October 2022 (UTC)

Yep, iterative approach sounds like the right way... -- andree 11:01, 4 October 2022 (UTC)

Basically I was thinking about something like Versailles, sans the city POIs. Indeed, if it's just one small-ish building, it may not make sense. But if there are gardens, multiple buildings, various interesting statues or whatnot, I could imagine an interesting article (something like inventory, even without encyclopedic details). Just my 2¢ as counterargument... -- andree 11:00, 4 October 2022 (UTC)

Suwon might benefit from Districtification. A major attraction could perhaps have a ===Subsection=== with several paragraphs about it.

If there are many important things to see in Hwaseong Fortress, then it might be possible to write an itinerary. Another possibility is adding it to the pages about Cultural attractions, like the Imperial tombs of the Ming and Qing dynasties. If you look through the list at UNESCO World Heritage List then you can see the many different ways various attractions have been handled. WhatamIdoing (talk) 17:06, 3 October 2022 (UTC)

See also Wikivoyage:Listings#Historic buildings, sites and natural formations. A private mansion unlikely to draw visitors, would not be listed at all. A small castle of historical importance would in the typical case be a see entry. A colossal castle with various amenities (a gift shop, a restaurant etc) could have multiple entries in different categories. /Yvwv (talk) 11:09, 4 October 2022 (UTC)

Thanks everyone. I think for now I'll direct my students to work mostly on articles about cities/town etc. Maybe a province if they insist as some occasionally do, but probably city/town level is the easiest. Piotrus (talk) 07:51, 6 October 2022 (UTC)

Call for presentations for WCNA 2022 and Mapping USA

Call for presentations for WikiConference North America 2022 and OpenStreetMap US's Mapping USA This is a call for presentations by Sunday, October 15 for WikiConference North America (Nov 11-13) held jointly with OpenStreetMap US's Mapping USA. We encourage you to please submit your Wikivoyage and other Wikimedia project proposals at Wikiconference:2022/Submissions and OpenStreetMap US proposals at Call for Proposals: WikiConference North America + Mapping USA. On Friday, Nov 11, we are looking for lightning talks in particular. We welcome workshops, editathons/mapthons, birds of a feathers, and presentations on Saturday and Sunday. Some suggestions: Cultural similarities and differences, for instance OpenStreetMap and Wikivoyage (map and describe what you know) versus Wikipedia (verify with citations) Type of licensing for each project and how they differ: Wikivoyage, OpenStreetMap, Commons, Wikidata, and Wikipedia The flow of information from one project into another, and how maps are generated and used How OpenHistoricalMaps works and possible interactions with Wikimedia projects Your ideas! Peaceray (talk) 15:22, 3 October 2022 (UTC)

MaggieMaps CC-By-SA

Topic suggestion — conversion of OSM maps to Wikivoyage static maps

It seems that the discussion regards cooperation between OpenStreetMap and Wikivoyage. I'd suggest that a tool be created to easily convert OpenStreetMap dynamic maps into Wikivoyage-style static maps. --Comment by Selfie City (talk) (contributions) 15:47, 3 October 2022 (UTC)

Perhaps OSMwiki:SVG#Ways to create an SVG map from OpenStreetMap & OSMwiki:OSM on Paper (see Outputs column on latter) may contain useful information for converting OpenStreetMap dynamic maps to SVG, PNG, & JPEG. Does anyone here have experience using such tools & be willing to offer a presentation or a lightning talk about it? Peaceray (talk) 15:00, 6 October 2022 (UTC)

Where to stick digital nomading information

Where can I stick information about the ease/difficulty/etc. of digital nomadry in an article? Work? Connect? Thanks, Brycehughes (talk) 05:45, 5 October 2022 (UTC)

I think it depends on the information. Advice about internet access should go in "Connect", whereas work-specific aspects (visas, coworking spaces, tax implications, etc.) should go in "Work". General summaries along the lines of "Lilliput is a great/difficult/popular place for digital nomads" should probably go in "Work", IMO. —Granger (talk · contribs) 09:37, 5 October 2022 (UTC)

That'll work. Thanks. Brycehughes (talk) 16:30, 5 October 2022 (UTC)

See vs do

Can I get some tips on what attractions go under see, and what under do? Ex. is park a see or do? What about a theater? Museum? Etc. Piotrus (talk) 07:49, 6 October 2022 (UTC)

You can check out Wikivoyage:Where you can stick it for some tips. --Ypsilon (talk) 07:56, 6 October 2022 (UTC)

To put it simply, anything that requires just your eyes is a see (museums, mountains, monuments, historic sites, etc.), and if something requires movement (excluding walking inside a museum) is a do. WV:ABC has some better advice, though. SHB2000 (talk | contribs | meta) 07:58, 6 October 2022 (UTC)

Mountain-climbing is a "Do," though. Also, anything that's a sporting event you're watching or a performance is a "Do," even if you're just sitting in the audience. Ikan Kekek (talk) 08:25, 6 October 2022 (UTC)

For the mountain: advice on lookouts where you can see it are See, even if they are a bit off. If you need a proper hike, then it is a Do. An urban park is a See even if you would want to take a long walk through it, while directions for a walk would be a Do. There are many borderline cases, where you have to use common sense, including cases where you want to keep sees and dos for the same attraction together. It is easy, though, for any more experienced user to move the listing if your common sense contradicts practice (such as perhaps for spectator sports). –LPfi (talk) 08:57, 6 October 2022 (UTC)

Formalised rollback policy

Given the recent saga on whether one admin has been misusing rollback, I've decided to draft out a formal policy on User:SHB2000/rollback. It's mostly summarised off Wikivoyage:User rights nominations#Misused rollbacks and various other formal rollback policies on other wikis, but it mostly outlines when RB should and shouldn't be used, the consequences of misusing it, and a bit about fingerslips. Feel free to copyedit it, but what does it need before it becomes policy? --SHB2000 (talk | contribs | meta) 12:49, 6 October 2022 (UTC)

I don't think we should have a policy like this.

I think that we should, in fact, consider not worrying about most forms of "misuse" of rollback at all.

The primary differences between rollback and undo are:

• whether it is possible to add a custom edit summary, and
• whether you can mass-revert every edit (very convenient for someone who vandalizes a lot of pages).

That's it. The second (which is why the tool was created) is almost never the source of disputes.

The proposed policy is literally trying to make a huge deal out of the difference between clicking a button that produces this:

• (Reverted edits by 172.0.0.1 (talk) to last version by Example) Tag: Rollback

and clicking a button that produces this:

• (Undo revision 1234567 by 172.0.0.1 (talk)) Tag: Undo

I think it would be silly to believe that the difference between "Reverted edits" and "Undo revision", or between "Tag: Rollback" and "Tag: Undo" actually makes much difference, then I'm guessing that the problem with misuse of rollback is actually: sometimes people don't add a custom edit summary when we think you should.

Related to that, I suggest that we consider a comment posted in a very different context above: "particularly, please note, most students won't notice comments in edit summaries, not until I individually point that feature out, or show it in class numerous times".

So: the wording isn't that different, plus newbies won't see the wording anyway. I think we should remove the claim in Wikivoyage:Administrators' handbook#Rollbacks that it's "potentially insulting" to use rollback (no more insulting than the Undo button, as far as I can tell) and perhaps adjust our view to place rollback in the same category as w:en:Wikipedia:Don't template the regulars – something that might upset a few experienced editors who have picked up enwiki's cultural baggage around this tool, and occasionally a missed opportunity for direct communication and strengthening social bonds, but not actually a problematic behavior per se. WhatamIdoing (talk) 16:42, 6 October 2022 (UTC)

Yeah, the only issue is whether a message is posted to the user's user talk page when that's appropriate to do. Using the rollback tool routinely for first-time offenders of rules on touting that most new users won't know and then not informing them of what they did wrong is bad. Ikan Kekek (talk) 18:59, 6 October 2022 (UTC)

I agree. It's why I think we should have some policy that prohibits these kinds of rollbacks (keep in mind that {{tout}} was not placed on this user's talk). SHB2000 (talk | contribs | meta) 21:33, 6 October 2022 (UTC)

So we have two issues: when a notice must (?) be placed on the user page, and when you must (?) leave an edit comment other than the default one. I haven't bothered with the former when the touting is in an obviously wrong context, like this (it might have been spam, but I don't bother to check that either, other than concerning other edits on WV by the same user/IP). The latter is a bigger problem when the edit isn't a formal rollback or undo (which give you an alert), but a regular edit that is part of an edit war across articles. Sure, a rollback is an insult in that context, and not constructive, but it is at least obvious. –LPfi (talk) 05:17, 7 October 2022 (UTC)

@LPfi: The page isn't complete, so please plunge forward and expand the draft as you feel so. I would say the warning is only a must when rollback is used against touting in namespace 0 (i.e. mainspace). SHB2000 (talk | contribs | meta) 05:48, 7 October 2022 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I think this is a useful piece to explain to admins when and when not to use rollback. It is basically an elaboration of this cursory advice from Wikivoyage:Administrators' handbook:

"Rollbacks are a hard (and potentially insulting) measure, and should mostly be used for vandalism and spam. Good faith edits should be undone with an explanation in the edit summary."

I have had my edits rolled back by admins in content or style disputes. I felt it was abuse of admin editing privileges, but without any detailed advice, it comes down to an unwritten sense of what is "appropriate" and what is not.

I understand the aversion to having a lot of policies to tell us how to behave, but when I was a new contributor, I was very frustrated when what I thought was a legitimate edit was reverted by an admin without comment. When I questioned the revert, I was told (paraphrasing) "that's not how we do things here; you have to spend time here to observe how our little community behaves". There was no policy, just an unwritten consensus. That really made me feel like I had stumbled into a private club where I was tolerated, but not welcome.

I think that SHB's piece, with some edits, would make a useful addition or addendum to Wikivoyage:Administrators' handbook that would help new admins, particularly, not abuse this awesome power with which they have been entrusted. Ground Zero (talk) 08:01, 7 October 2022 (UTC)

I think I'd favour a separate page because patrollers also have the ability to misuse this tool; I think we all know that one user who was rightfully stripped of their patroller privilege in 2020 for blatantly misusing it to revert legitimate good-faith edits (one that routinely had a crusade against GZ's edits) and is now indeffed on enwiki. This would also bring the English Wikivoyage in line with most other WMF-wikis per Q5148465 (Wikipedia:Rollback). SHB2000 (talk | contribs | meta) 08:09, 7 October 2022 (UTC)

GZ, is the problem "using the Rollback button in a dispute, without any detailed advice"? Would "using the Undo button in a dispute, without any detailed advice" have felt good? WhatamIdoing (talk) 17:02, 7 October 2022 (UTC)

Using the Rollback button is harsher, because it is done by an admin with one click, saying "this is so wrong it doesn't deserve consideration". But we would do well to provide advice on using the Undo function politely, too. Ground Zero (talk) 18:47, 7 October 2022 (UTC)

I only have to click the Undo button once, and I'm not even an admin. How is it harsher to click the Rollback button once than to click the Undo button once? WhatamIdoing (talk) 23:51, 7 October 2022 (UTC)

I was going to argue against this addition to policy until I started reading the comments. I've changed my mind: I think we should formalize that rollbacks are only to be used in cases of obvious vandalism, but we should add this to the handbook, not a new policy page. We have enough policy pages, but many of them are short, so for specific policies I think it would be best to add the information to the policy pages that are already in existence. --Comment by Selfie City (talk) (contributions) 18:15, 7 October 2022 (UTC)

Having a separate page because of patrollers makes sense, but I am not entirely sure we need more advice than currently. I don't think there is any big problem in the use of the tool, except for a few persons, and reminders on their talk pages might suffice. However, it seems we have some disagreement about when the tool should be used. Should the discussion be at Wikivoyage talk:Administrators' handbook? –LPfi (talk) 19:22, 7 October 2022 (UTC)

I would have also favoured an addition to the admins' handbook, but that would exclude patrollers. SHB2000 (talk | contribs | meta) 23:12, 7 October 2022 (UTC)

I think that a tool-agnostic change like this would be sufficient, and it actually addresses the real problem:

Tool-agnostic change

Current version

Suggested version

Rollbacks are a hard (and potentially insulting) measure, and should mostly be used for vandalism and spam. Good faith edits should be undone with an explanation in the edit summary.

You can't add a useful edit summary when you use the Rollback button, so it is mostly useful when no explanation is needed (e.g., obvious vandalism and spam). No matter which tool you use, if you are removing good-faith edits, you should normally provide an explanation somewhere. If you don't explain your reversion in an edit summary, then explain on the talk page or on the other editor's talk page. Most newcomers will never see edit summaries or use article talk pages, so even if you explain in an edit summary, you may need to repeat that explanation on the newcomer's talk page.

What do you think? WhatamIdoing (talk) 00:02, 8 October 2022 (UTC)

I like it. Ikan Kekek (talk) 00:29, 8 October 2022 (UTC)

I'm happy to replace this current version with the suggested version, in addition to the rollback policy I've proposed above. Remember, patrollers also have the ability to misuse rollback.

I know I've been told countless times that I'm trying to make this site more bureaucratic, but I really think this site should be more bureaucratic (though not like Wikipedia). The lack of policies regarding admins misusing their tools creates a system open to abuse. I don't know which user Ground Zero is referring to, but on most wikis, that user would have been desysopped by now (if they were a patroller, they'd have lost patroller privileges). However, if we did have this policy, then it is crisp clear what's acceptable and what's not, and the consequences for misusing it. This ultimately makes Wikivoyage a friendlier place to edit. SHB2000 (talk | contribs | meta) 01:31, 8 October 2022 (UTC)

I like some though possibly not all of what's in your draft, too, but I think WhatamIdoing is right that the main issue isn't whether simple reversion, a hard revert or a rollback is used, but whether information is provided to a user that is not a vandal or a bot, either in the form of a user talk page message and/or an edit summary, that explains the reasons for the reversion by any of these methods. I also think that a pattern of reversion by any method without informing users who are not strictly vandals or bots why their edit was reverted should be grounds for a desysop nomination, but neither patrollers nor admins should be expected to be perfect, just to avoid making a habit of not communicating. In other words, I think you are overemphasizing the method of reversion. Ikan Kekek (talk) 04:02, 8 October 2022 (UTC)

> The lack of policies regarding admins misusing their tools creates a system open to abuse.

No. Our reliance on humans creates a system open to abuse. It does not matter how many rules you write, or how crisp and clear they are. What matters is whether humans are allowed to use their judgement. If they are, there will be errors of judgement, and sometimes those errors will rise to the level that we might call abuse. Writing down rules doesn't solve the problem.

I also disagree with the idea that telling experienced editors exactly how they'll be punished (let's avoid the euphemism "consequences" here) for having a different viewpoint about whether a reversion needed an explanation in the edit summary is a way of making Wikivoyage friendlier.

> on most wikis, that user would have been desysopped by now

No. On a handful of wikis, that user might have been considered for desysopping, depending on a lot of factors, including whether that community feels like they have plenty of admins to spare, and how many enemies the admin has made. Most of the time, at most wikis, the only response (if there is any response at all) is a reminder that it can be helpful to provide an edit summary. The official page at the German-language Wikipedia, for example, says this:

• "Sollten andere Benutzer dennoch unwissentlich oder häufig für normale Wiederherstellungen „rollback“ nutzen, so kannst du sie beispielsweise mit dieser Vorlage {{subst:Hinweis Zurücksetzen}} oder mit einem eigenen Text auf ihrer Diskussionsseite darauf hinweisen, dass die Rollback-Funktion nur für die Zurücksetzung nach Vandalismus genutzt werden sollte."
• ("If other editors nevertheless inadvertently or frequently use "rollback" for normal reversions, you can post the [reminder] template or write your own comment to their talk page, to tell them that the rollback function should only be used after vandalism.")

There's no mention of any punishment specific to using rollback, rollback is widely available to experienced editors, and they don't seem to have a big problem with it. WhatamIdoing (talk) 20:22, 9 October 2022 (UTC)

@Ikan Kekek: I've rewritten part of the abuse section, so now there is an emphasis on communication more so than removal. Here's my new wording:

If you find a user misusing rollback, start a discussion with them about their use of rollback, or at least give a formal warning. If the user reforms their behaviour and their use of rollback, then you've made progress. However, if repeated discussions fail to make a difference, make it firm that desysop or removal of patroller privileges is always an option. If the user still continues to misuse rollback, you may start a desysop request if that user is a sysop, and let an uninvolved admin know for patrollers.

As you'd probably know by now, I have a tendency to interpret policies like interpreting the law. I've tried to avoid writing this without it sounding like a legal document, but it might still sound like one. To @WhatamIdoing:, I've adjusted it so that desysop/removal of patroller privileges are a last resort. Does that work out? SHB2000 (talk | contribs | meta) 03:36, 16 October 2022 (UTC)

I think the main question is whether we need a formal document. We try to avoid policies. Without a formal policy users can use their best judgement, which should be enough and sometimes better than rules. If that judgement isn't enough, we can discuss any issues, also then more flexibly than using a rules document. We have had problems with some users using the rollback tool sloppily, but has there been unsolvable problems with agreeing on what is sloppy use and what isn't? It is useful to document best practices, but that is different from a policy. –LPfi (talk) 05:48, 16 October 2022 (UTC)

This is another example of "how we do things" that new users can't know about if it's not written down. I didn't know that "we try to avoid policies", but I've only been here since 2016, so I guess I haven't learned that lesson the hard way yet.

The reason for proposing this policy or adding it to the Administrators Handbook is that we have example of users' best judgement not being very good, and causing problems. Writing this down makes it easier to have those discussions on user talk pages. It allows someone to say "There is already a consensus on this -- it isn't just your best judgement against my best judgement", rather than, "this isn't the way we do things around you, and you'll learn this after you've spent more time here". Ground Zero (talk) 07:09, 16 October 2022 (UTC)

Ground Zero perfectly sums up possibly why Wikivoyage's editor base is (significantly) smaller than it's potential. Every policy requires editors to use their judgment. From WV:TTCF to WV:TONE to WV:TOUT, many policies and guidelines are subjective. There isn't a clear line between what's useful for a traveller and what's not, there isn't a clear line between what's an acceptable tone and what's not, there isn't a clear line between what's touting and what's not. Having a formal policy does not necessarily mean that editors cannot use their judgment. A policy makes it clear if a certain use of rollback is unacceptable or not; honestly, the English Wikivoyage should be ashamed of itself for allowing or not taking much action against rollbacks like this or this. Editors can still use their judgment for borderline cases. SHB2000 (talk | contribs | meta) 07:42, 16 October 2022 (UTC)

I still don't think the issue is the misuse of rollbacks per se as much as it is using them and then making a habit of not attempting to communicate with good faith or potentially good faith users who were rolled back to tell them why you did so. I accept that rollbacks can be more insulting to some users than other forms of reversion, because some of you have said they are to you, but I maintain that the lack of communication is a bigger issue. Ikan Kekek (talk) 09:09, 16 October 2022 (UTC)

Adjusted per your comment. See Special:Diff/4542376. SHB2000 (talk | contribs | meta) 09:22, 16 October 2022 (UTC)

I think it is good to document best practises, didn't I make that clear? Thus I support adding to the advice on reverts, rollbacks and communication in the Administrators' handbook, but not adding the page as a formal policy as suggested. One can easily point to the relevant section as "there is consensus on this", without saying "you are violating policy". The two examples given by SBH are obvious examples of abuse and sloppy use of rollback, respectively, and handling them doesn't require pointing to a policy. Indeed, I think that pointing to a policy in cases like those is derogatory to the community: instead of saying "please don't do that" (assuming good faith) one would say "be warned!" (relying on punishments). –LPfi (talk) 11:58, 16 October 2022 (UTC)

In terms of "another example of "how we do things" that new users can't know about": How many new users have a rollback button? I assumed that the number was zero, and that therefore it wasn't something that new users needed to know about. WhatamIdoing (talk) 22:37, 17 October 2022 (UTC)

I'm sure what GZ is referring to in "that new users can't know about" is how experienced users are supposed to use rollback. Keep in mind that a vast majority of users have their start on the encyclopedia before editing Wikivoyage, and I guarantee that most reasonably-experienced Wikipedias (i.e. users who've maybe made more than ≈2000 edits) know what rollback is. SHB2000 (talk | contribs | meta) 10:20, 18 October 2022 (UTC)

@WhatamIdoing: actually what I was referring to was LPfi's comment that "We try to avoid policies." I didn't know that after more than 6 years here. Maybe it is written down somewhere and I haven't read it, but it sounds to me like an unwritten consensus amongst thise who were here before me. Ground Zero (talk) 19:29, 19 October 2022 (UTC)

One of the things that most fascinates me about this community's formal structure is its desire to not have any hemi-demi-semi rule pages. Until a couple of years ago, it was either a mandatory policy, or it was some unofficial good advice. There no in-between state; we had no guidelines, supplements, or other hierarchy in the rules. I think it was remarkably functional and served this group well.

Now that we have Template:Guideline (there is no Template:Policy, and Template:Essay is unused except by its creator), it seems the temptation to tag pages is not resisted as often as it could be. Once you can slap labels all over pages and sort them into ever-finer categories, there will be someone who finds that work deeply satisfying.

As an example of this, Wikivoyage:Goals and non-goals, a page that predates w:en:Wikipedia:Five pillars and seems similar in purpose and style, was boldly declared to be a guideline a while ago. Does it need to be tagged? I'd argue for w:en:WP:NOTAG, just like I've long (and successfully) argued for no tag on 5P at enwiki. If it needs a tag, is that the right one? I'm doubtful about that. But it's been tagged. The only practical way to stop people from doing that would be to delete the tag.

But the tag was discussed and accepted, because someone wanted to import a page that's tagged as an essay at the English Wikipedia and make other people follow its advice. They seemed to feel that the tag was an essential component of that last bit, so now we have the tag, and since we have the tag, we have it creeping on to other pages. WhatamIdoing (talk) 03:20, 20 October 2022 (UTC)

Do new users need to know how experienced users are supposed to use advanced tools?

If you were trying to help someone make their first edits here, would an explanation of how other people use tools that this newcomer has no access to make the top 10 on a list of things newbies need to know? Would it even make the top 100? Wikivoyage:Welcome, Wikipedians contains 106 sentences, and yet does not mention rollback once.

IMO what the newcomer needs to know is that we have people who will explain problems and encourage contributions. Since edit summaries are neither the only way to explain things nor the most effective way to explain anything to a new editor, explaining problems is not actually incompatible with "bad" uses of rollback. WhatamIdoing (talk) 15:35, 18 October 2022 (UTC)

Philosophy of policy writing

I like to write policies and guidelines; I even seem to be fairly good at it (although editors who are bad at it are frequently unaware of this, so perhaps I'm just unaware of my limitations). I have my own notions of what works best, plus my own preferences and biases, and I've seen more approaches to policy in wiki-based communities than most. I give this background to say that the rest of this is kind of philosophical, and if that doesn't interest you, then you don't have to read it.

Different folks like different approaches. Almost everyone believes that their view is the middle ground, and everyone believes that their view is the best. So I'm telling you that these are mine, not that they're the only options.

One rule of thumb that I've recommended at the English Wikipedia, and which I think applies everywhere, is this:

➤ Never make a written rule for any situation unless there have been at least two separate incidents (=not involving any of the same editors and not involving the same page/content) that could not be resolved through any of the normal, existing processes (e.g., asking other editors to join a discussion).

Another principle that I think is universal is:

➤ It is usually better, and sufficient, to establish positive "norms" instead of "violations" and "punishments".

This means that we say "Here's how we do this" or "This is a popular choice", but we don't say "If you don't follow this rule, then we will punish you for violations". There are exceptions, generally involving obvious matters (e.g., we punish spammers and vandals by blocking them) and legal matters. However, in everyday editing, the goal is to have interactions that are free of threats. Threats are intended to produce fear. Threats don't say you should do it because it's good and right and fills the world with rainbows and butterflies; threats say you should do it because I'll punish you if you don't. Fear produces bad experiences, bad relationships, bad behavior, and bad communities.

By contrast, when you tell people that something is normal or popular, they usually want to do it. People want to prove their membership in the group, by behaving the way the group does. People assume that experienced editors have figured out most of it in the past, and they want to take advantage of that knowledge, rather than figuring out everything through trial and painful, time-wasting error themselves.

Here's a principle that isn't quite universal, but it's my strong preference:

➤ The smaller the community, the fewer rules you should have.

This means, e.g., that the smallest wikis should have basically no rules at all. They should just wave at the core content policies in passing and probably have a statement somewhere about copyright violations being a bad idea, or at least remove copyvios even if they didn't bother to write down locally that copyvios are against the rules. Otherwise, contributors should emulate the behaviors and contributions that they think are working, and avoid things that don't seem to be working, and mostly live and let live in the service of content. The overall level of organization and rules should be no more complicated than a group of neighbors showing up at a school or park to pick up trash some afternoon.

The mid-sized wikis should have a few rules and a few processes. These rules should address only common questions and generally aim to make things easier for newcomers. Most of the rules should be about establishing a very broad range of acceptable actions, to maximize the amount of effort spent creating content and to keep self-appointed rule-enforcers from fighting over things like whether to use the w:serial comma (even though everyone should! ;-)) or what the One True™ Way to do something is. Questions outside those common ones should be decided as they come up by folks who consider the situation in light of the group's values (e.g., Wikivoyage:The traveller comes first, being welcoming), its Wikivoyage:Goals and non-goals, and their current capabilities, always with an eye to the effect of the decision on interpersonal relationships.

The English Wikivoyage generally does a stellar job on that last point. It is not a point that is easily handled by mindlessly following rules. It's a point that works best when you respond to a situation by knowing what else is going on with all the individuals. For example: Is this really a fight about that one edit, or is it a symptom of something bigger? Is someone worn down from dealing with a persistent vandal, and could this outburst be a sign that the group needs to provide more practical support, rather than a sign that we need to punish people for expressing the fact that they're overburdened and overwhelmed? The overall level of organization and rules for these mid-sized wikis should be on the order of arranging a potluck dinner for 100 people. You have to establish some roles and organize a few things (e.g., who's going to clean up afterwards? Where should we put the trash cans?), but you mostly let people do what they want and try to keep the group happy without trying to control any individual participants.

The biggest wikis should have enough rules to prevent repeated problems and enough processes to let interested people specialize. Overall, the goal for large wikis is still to have the fewest rules possible, but to recognize that the fewest possible is still a lot of rules. When you have a lot of contributors, with a typical "established editor" lifespan of a few years, there are a lot of problems that come up over and over.

IMO absolutely no wikis should have rules that settle everything in advance. The rules should leave as much room for creativity as possible. This is because most people contribute because they want to build something, not so they can follow a bunch of rules or get bossed around by a rule enforcer. You may have seen these comparisons before:

• People like to cook, but nobody really loves washing dishes. Why? Cooking is creative. Washing up isn't.
• People like to sew clothes, but nobody really loves washing laundry. Why? Sewing is creative. Laundry isn't.

While a certain level of organization is necessary and helpful, additional rules beyond that point tend to be counterproductive. It stops being fun. It starts being boring. And when that happens, people discover that there is a whole internet outside that wiki, and they leave.

I don't think my view here is universal. Leaving aside the build-it-and-they-will-come sorts, who naïvely believe that translating the English Wikipedia's extensive (and self-contradictory) ruleset and templates and bots and general bureaucracy into the local language will result in a large community appearing to fill all roles (it never has yet...), there are a few circumstances in which one might choose a different approach, such as:

• A corporate wiki on a sensitive subject (e.g., human resources policies) might have an especially high degree of desire for control. Lawsuits have hinged on the punctuation in a contract.
• A community of autistic people might value what I'd call a stifling level of rule-following. Especially if you spend much of your life wondering if you're violating some shrouded social convention, there is a comfort in knowing that you are definitely doing the right thing by clicking the blue button instead of the yellow one, even if both buttons do basically the same thing. Such a community might value predictability, conformity, and control more than creativity. (As a side note, autistic individuals tend to be tireless contributors when they find a task that fits their skills and interests.)
• Young school children might need a very color-by-numbers approach to contributions, because they don't have the maturity needed to make good contributions otherwise.

But I wouldn't want to be part of a community like that, and I suspect that's true for most of us. We're not here to take delight in following the rules perfectly. We're here to have fun creating new information about a fun subject, with great volunteers to help us (and to be helped by us in turn).

And now, if you'll bear with me while I connect this long-winded statement back to the above dispute:

1. IMO we don't need a rule, because this situation basically involves one dispute, and it's basically been resolved through existing, normal processes. Maybe some aren't happy with the resolution, but we did reach a resolution.
2. If we decide to have any rules, we don't need to threaten anyone. It's likely to be sufficient to give positive statements ("If you revert anything except obvious vandalism, explain why. That's usually done in a custom edit summary or on a talk page").
3. We are doing an awesome job of handling discussions around this, because people keep going back to core values, such as being welcoming and encouraging to newcomers by explaining why their first attempt had to be reverted.

This last point makes me happy to be here. WhatamIdoing (talk) 05:45, 18 October 2022 (UTC)

@WhatamIdoing: You make some good points; I would generally agree with many of your points. On the other hand, there are some that I disagree with, but a lot of it doesn't specificially relate to the rollback policy.

re "Never make a written rule for any situation unless there have been at least two separate incidents (=not involving any of the same editors and not involving the same page/content) that could not be resolved through any of the normal, existing processes (e.g., asking other editors to join a discussion).": it's true, but in this case, we've had various cases of different users misusing rollback, not just the two diffs I've mentioned.

I realise this is gravely off-topic, but in response to "The smaller the community, the fewer rules you should have.", the lack of policies is what makes smaller wikis defy Wikimedia norms. In many cases, a sysop on a small wiki may have been a spammer in the past, or may be blocked on a larger wiki, such as enwiki. FWIW, I believe there are two users on shn.voy who have copied various templates from en.voy without any attribution. I was thinking about warning both of these users, but one of these users is an admin on shn.voy and I feel hesitant warning both these users or fixing this attribution issue. I might eventually have to do this myself, but otherwise I might bring this up with them on meta. Unfortunately, both of their babel scales claim they're a shn-3 and a my-3, with zero mention of English. Burmese is certainly on Google Translate, but knowing absolutely nothing about Burmese, this would be an issue. The point is, communication is difficult on small wikis, especially on wikis where most users speak virtunally zero English (and back to the shn.voy issue, most people in Myanmar don't speak English).

Back on-topic, I'm not so sure about whether mid-sized wikis should only have a few rules and processes. FWIW, I'm reasonably active on en.wb, a wiki with fewer editors, has more processes (including an admins' noticeboard, an edit filter false positives page, an administrative assistance page – I could go on), but they generally have fewer issues with dealing with vandalism, spam, users with behavioural issues, and so on. In simple words, there's the policy, nearly users adhere to it, and there's no drama. Here, what's happening is users think they can use rollback whenever they want, stirring up a drama, eventually driving users away or otherwise making others feel uninvited to this "private club". If most wikis aren't having snags about the use of a MediaWiki feature and several users on the English Wikivoyage are, then who's (i.e. which wiki) at fault here?

I do agree that we don't want to go rule-enforcing, but I would encourage everyone here to have a look how en.wb does things. I'm sorry to disappoint many of you, but en.wb does things a lot better than en.voy, and it is for that reason why it's not a wiki that is easily suseptible of demise as soon as you lose a few editors (a la The Other Site). From dealing with vandalism, spam, problematic users, policies, and so on, en.wb has not had such a saga, at least not that I know of. If anything, the most controversial discussion on en.wb ever since I started editing has been whether to allow strategy guides for video games. End of ramble.

To finish this up on a positive note, in no way am I suggesting that Wikivoyage is bad at handling vandalism, spam, or problematic users; what I am saying is if we follow en.wb's model, it may no longer be a wiki only 1% of enwiki's size. Such small steps like having a basic policy that outlines what's acceptable and what's not don't necessarily make the site more bureaucratic, nor is it threatening (should we abolish WV:TOUT because it's threatening? no, we shouldn't). A rollback policy should have no bearing on how a user should (constructively) contribute.

Apologies to anyone to had to read through my long scramble and chunks of text. I'm typing this late at night, in addition to a fall when climbing up the stairs at a train station today. If anything doesn't make sense, I'm happy to clarify. --SHB2000 (talk | contribs | meta) 12:23, 18 October 2022 (UTC)

You have documented zero incidents of rollback misuse that the community has been unable to handle through its normal, everyday process of having a discussion. Therefore, writing down rules won't actually help. It will only result in w:en:WP:Instruction creep. (Note that "handle" is different from "get people to follow your orders" or "produce uniform behavior".)

You have such strong faith in writing down rules. Written rules are not magic spells. Even at the English Wikipedia, which many people would describe as being rule-bound, it frequently takes two years for a written rule to start having an effect on editors' actual behavior.

As for "I do agree that we don't want to go rule-enforcing", then why do you do so much of that? Trying to get that editor desysopped because you disagreed about the use of rollback is rule enforcement. When it didn't work, you proposed changing the rules to make the behavior more obviously punishable, so you can try to enforce them to the letter next time. If you don't want to "go rule-enforcing", then stop trying to enforce the rules on other contributors.

Wikibooks has less "drama" because it has both fewer editors than this site and much less interaction between those users. Their equivalent of this page contains one non-bot comment. This is not surprising, since the idea there is that I write my book over here and you write yours over there, whereas here, the idea is that we all work on everything to produce a single good page for each destination. Just based on those two structural elements, one would expect substantially less drama.

Other wikis have little drama over the use of rollback because nobody cares which button is used to revert people. The page about rollback at the English Wikibooks, for example, does not say that rollback can only be used for vandalism, does not say that editors must explain non-vandalism reverts, and does not even hint that desysopping is a proportionate response to "misusing" rollback, which is not surprising, because under their rules, it would be almost impossible to misuse it. I see some editor over there using rollback to revert what was probably a test edit, rather than vandalism, and I don't expect anybody to complain at him. I see an admin removing an external link. Here's another editor rolling back a good-faith clarification of a word in the text. Here's an admin rolling back a simple grammar error and a single-character typo. About half the uses of rollback at that wiki are actions you're trying to ban here. If you want us to be more like the English Wikibooks, then let's start by adopting their laissez faire attitude towards which button gets used to remove unwanted edits. WhatamIdoing (talk) 16:17, 18 October 2022 (UTC)

It is good to have these policies in mind. Many of our policy pages are artifacts from The Other Site, and might sometimes address issues that we rarely see. Wikivoyage:Listings has been brought up some times lately, with the inclusion of temples and historic buildings as case studies. Hopefully we can make the policy writing more encouraging and universal. /Yvwv (talk) 16:38, 18 October 2022 (UTC)

A brief response: some of the links you've mentioned like b:Special:Diff/4195113 or b:Special:Diff/4195008 are reverts of LTAs. I'll respond to the rest of your message once I come home. SHB2000 (talk | contribs | meta) 20:36, 18 October 2022 (UTC)

A full response:

• "You have documented zero incidents of rollback misuse that the community has been unable to handle through its normal, everyday process of having a discussion.". Uhm, Talk:Berlin? That's just one example.
• "You have such strong faith in writing down rules. Written rules are not magic spells." I've made my point already and won't repeat it.
• "As for 'I do agree that we don't want to go rule-enforcing', then why do you do so much of that?". Avoiding rule-enforcing means not having a bot that warns a user every time they link a disambig page in mainspace or the alike. It does not mean not calling out users for their behaviour.
• "Other wikis have little drama over the use of rollback because nobody cares which button is used to revert people." If that is the case, then why are rollbacks of good-faith edits basically nonexistent on other wikis. I'm not trying to advocate for using the undo button in the case of bad-faith test edits, unlike what you claim, such as b:Special:Diff/4194730 or b:Special:Diff/4194722.

So in reality, none of the uses of rollback on en.wb were a misuse and perfectly acceptable were User:SHB2000/rollback to be a policy. SHB2000 (talk | contribs | meta) 08:33, 19 October 2022 (UTC)

• Talk:Berlin happened four years ago, and was resolved through normal, everyday discussions. This discussion even included a polite apology from the person who used the rollback button. What more could you expect?
• Calling out users for behavior is a form of rule enforcement.
• Are you saying that changing "is Filipino-Spanish" to "is a Filipino-Spanish" is bad-faith test edit? I'd say it was a good-faith edit from someone who doesn't speak English natively. Bad grammar, but not bad faith. How do you know that this person was actively trying to harm Wikibooks? Ditto for changing "level" to "levl". How do you know that was a deliberate attempt to cause harm, rather than an accident? Note that I don't say it's against any of Wikibooks' rules; I only say that it's not blatant vandalism.

WhatamIdoing (talk) 02:51, 20 October 2022 (UTC)

Couple quick questions

• Are there any experienced travel topic editors who could say if Cycling in the United States is at guide status? I think it is, but I've never written a travel topic before, and I was hoping for a little reassurance!
• Any interest in combining some regions into a new Eastern Massachusetts region?
• Tech question: is it possible to use openstreetmap to combine (for example) this, this, and this into a single relation?

Thank you in advance and sorry about the noise! ButteBag (talk) 00:11, 7 October 2022 (UTC)

No need to apologise. The pub does get quiet at times and it's not really a big deal. Answering your questions:

1. I'm no experienced travel topic editor, but it looks like it's at guide.
2. My Inkscape crashed yesterday just as I finished making the map for New England (New South Wales) and it's ridiculously slow when I start it (and the Bezier pen misbehaves). I'll get back to this once I try and fix it.
3. Unfortunately I'm still a novice editor on OSM and have no idea how to.

SHB2000 (talk | contribs | meta) 08:19, 7 October 2022 (UTC)

LOL! I meant the USA New England region, but thank you for your comments. ButteBag (talk) 12:34, 7 October 2022 (UTC)

Lol it just happened to be a coincidence that I was this happened after I uploaded File:New England NSW regions map.png. The Bezier pen issues happened trying to make a map for Venice. I thought you meant a new map for Massachusetts.

Alternatively, given how the boundaries for MA seem to be mostly straight lines, you could consider using geojson.io and uploading the data to Commons. Renek78 made this great tool so you could just paste the geojson.io code and you'll have fresh new mapmasks just out of the oven. See Las Vegas, Canberra, or Singapore for examples on how this is used. It is time consuming though – it took me a few hours to perfect the Canberra mapmask. SHB2000 (talk | contribs | meta) 12:55, 7 October 2022 (UTC)

Holy crap this districtifier thing is amazing! TY for making it @Renek78 and bringing it to my attention! I guess this is basically what I want, but ideally the borders would display only where two districts touch if that makes sense. create_geoline_from_wikidata_array() or something. Sounds like it's possible to do that by creating a super-region on OSM... but you need a computer science degree and months of free time to create something they don't want anyway. Oh well, close enough.

I can use these tools to update some regions in Mass if anyone supports that. Thanks again! ButteBag (talk) 15:16, 7 October 2022 (UTC)

As for the combining o relations, it's definitely possible to create a relation combining multiple other relations. But I think OSM don't want/like private 'helper' data (like such stuff for grouping various objects into one), unless it makes some geographical/administrative sense. But you can always just use the three {{mapshape}}'s in WV and e.g. specify zero border (stroke-opacity=0) to make it look more nicely... -- andree 11:52, 7 October 2022 (UTC)

Thank you! Yeah it would be nice to keep the stroke tho... ButteBag (talk) 12:58, 7 October 2022 (UTC)

A minor static map request

Unfortunately, my Inkscape is unwilling to properly work after it recently crashed, so I'm wondering if anyone here's is willing to do a minor change to the static map in Southeastern New South Wales.

Currently, the text in the northeastern region says "Far South Coast". However, our article is now called Eurobodalla – I'm wondering if anyone is able to edit the text to say "Eurobodalla" instead of "Far South Coast".

Thanks in advance,

--SHB2000 (talk | contribs | meta) 08:01, 9 October 2022 (UTC)

I made a try, commenting out the tspan etc. of "Far" and replacing "South" and "Coast" with "Euro-" respectively "bodalla". I don't know the SVG syntax, so something went wrong: the text was still placed at the former two lines, not the latter ones. It doesn't look very nice like this, but if nobody is fixing it soon, I'll upload that version. Note that it's the SVG version that should be edited, not the PNG version linked from the image. –LPfi (talk) 08:44, 9 October 2022 (UTC)

Thanks for the fix. I guess I don't know what I did to the file, but something is better than nothing. SHB2000 (talk | contribs | meta) 10:15, 9 October 2022 (UTC)

I can give it a try today. --Comment by Selfie City (talk) (contributions) 14:41, 9 October 2022 (UTC)

Done --Comment by Selfie City (talk) (contributions) 23:58, 9 October 2022 (UTC)

Thank you, SelfieCity! It looks great :-). SHB2000 (talk | contribs | meta) 00:16, 10 October 2022 (UTC)

For sure! It's odd that Inkscape would've crashed like that. I feared that the same would happen when I opened the file, but it did not.

By the way, I wasn't sure on the size of the original image and since there was a slight issue on the lower side of the file, I adjusted the crop somewhat.

Keep up the nice static maps whenever you get Inkscape back — the one I just edited looks really good. --Comment by Selfie City (talk) (contributions) 02:39, 10 October 2022 (UTC)

I tried uninstalling and reinstalling Inkscape and it worked! I don't know what would have happened to cause that, though. I also tried reopening File:New England NSW regions map.png again and to my surprise, Inkscape works completely fine. Either way, thanks for the compliment :-). You and Shaundd did kinda inspire me to start drawing static maps, and I must say, I'm now really into it. SHB2000 (talk | contribs | meta) 03:35, 10 October 2022 (UTC)

New article

Would ‘buses in the UK/united kingdom’ be a good article? 2006toyotacorrola (talk) 06:24, 11 October 2022 (UTC)

That could be a totally valid topic if you have enough distinct information. Note that we already have Bus travel in former Yugoslavia. —Justin (koavf)❤T☮C☺M☯ 06:30, 11 October 2022 (UTC)

If the article is started, it would be preferable to keep the format, so the redlink would be Bus travel in the United Kingdom. --Comment by Selfie City (talk) (contributions) 12:16, 11 October 2022 (UTC)

United Kingdom Coronation Date announced.

https://www.westminster-abbey.org/abbey-news/the-king-coronation-date-set-for-saturday-6th-may-2023

Which gives Wikivoyage a few months to prepare a travel guide for viewing processionals/ceriomonals open to the public and so on. ShakespeareFan00 (talk) 09:03, 12 October 2022 (UTC)

Could be added to Monarchy of the United Kingdom. Could we possibly get this article featured for April-May 2023? /Yvwv (talk) 17:58, 13 October 2022 (UTC)

Open letter to WMF to improve Wikimedia Commons

There is an open letter to WMF about Wikimedia Commons. If you are interested (or frustrated about commons as I am) take a look: Think big - open letter about Wikimedia Commons -- DerFussi 11:25, 12 October 2022 (UTC)

Was it just a coincidence that I just so happened to be reading that letter halfway before I stumbled across your message? Anyway, I've signed the doc and hope more people from this community will sign it. SHB2000 (talk | contribs | meta) 11:46, 12 October 2022 (UTC)

Hello, I just wanted to post a message here. :-) Thank you @DerFussi, and thanks everybody for your support! Ziko (talk) 19:51, 14 October 2022 (UTC)

@Ziko: I have mass message rights. We should have draft a message and send it to all Wikivoyage pubs. Too late - next time. :) -- DerFussi 20:00, 14 October 2022 (UTC)

Travel guides with only POW attractions?

I had thought of creating a travel guide on Ausgram, a rural area in Rarh. However, as I have surfed into Commons categories and images, I fail to find attractions other than places of worship (aka Hindu temples), considering our Wikivoyage guideline on listings eschews such listings. However, certain temples do look good architecturally, but... Sbb1413 (he) (talk • contribs) 18:11, 12 October 2022 (UTC)

Eureka, I found Pandu Rajar Dhibi, an archaeological site within the Ausgram area. Sbb1413 (he) (talk • contribs) 18:24, 12 October 2022 (UTC)

There is nothing wrong with Hindu temples, but if the destination is somewhere with temples all around, they need to be quite special to be worth a listing, and very special to warrant a city article. Nice that you found something else also. Commons' coverage of sights is quite random. –LPfi (talk) 19:29, 12 October 2022 (UTC)

Wikivoyage:Listings#Places of worship looks a bit harsh. Do we have a serious problem that some destinations list too many places of worship? /Yvwv (talk) 21:46, 12 October 2022 (UTC)

If it seems harsh, we should edit it. It's certainly distressing that anyone, let alone a non-short-term user, could interpret that section as meaning that places of worship shouldn't be listed. "Reasons to list a place of worship could include guided tours, service in multiple languages, historical or architectural importance, that it is the city's only or largest place of worship for a religion, or anything else that makes it distinct." So unless the Hindu temples in question are boring, please list them! Ikan Kekek (talk) 21:53, 12 October 2022 (UTC)

I wonder whether the original concern (the one that prompted writing the advice in Listings) was that if you list the First Church of Smallville, you might want to also list Second Church of Smallville, and so forth. I believe that in the US there is typically more than one church per 1,000 residents, so a medium-size city of 250,000 residents could easily have 25 to 30 churches, plus perhaps five non-Christian religious organizations. Even in a large article, you would probably want to list no more than the usual 7±2, and the advice suggests that they be chosen based on qualities such as biggest, oldest, best known, nearest the tourist areas, the only mosque or synagogue in town, etc., rather than on the basis of their religious doctrines. WhatamIdoing (talk) 02:35, 13 October 2022 (UTC)

I mostly agree but would caution that more than 9 houses of worship can be fine to list, although we don't want 30. Ikan Kekek (talk) 02:57, 13 October 2022 (UTC)

To answer the original question asked by Sbb1413, I would say it should be fine to create the article because of the archeological site.

To others in the thread, any proposal to change or modify our POW policy should be discussed at Wikivoyage talk:Listings; until then, articles are by no means "exempt" and m:IAR doesn't apply here. I strongly support the existing wording – as LPfi mentions, "they [the temples] need to be quite special to be worth a listing", but that is a discussion for another day.

To Sbb, that doesn't mean it's not fine mentioning the most interesting Hindu temples to visit – in fact, if a temple is interesting, then by all means list them. Alternatively, to make the article more interesting, you could also create an itinerary article along the lines of Historic churches of Buffalo's East Side or include it in the article's "Do" section (I did something similar a while back but with war memorials on Canberra/North Canberra#Anzac Parade). SHB2000 (talk | contribs | meta) 08:20, 13 October 2022 (UTC)

Thank you all for your inputs. I have created the rural area in question with Pandu Rajar Dhibi and terracotta temple listings. Besides, I've heard that local authorities might be transforming the area into a tourist site. Sbb1413 (he) (talk • contribs) 08:22, 13 October 2022 (UTC)

Ooh, that would be cool. If that's the case, then the question of whether we should have an article for this or not is a no-brainer: definitely yes. SHB2000 (talk | contribs | meta) 08:31, 13 October 2022 (UTC)

Temples of Ausgram or Temples of Rarh could be a travel topic or itinerary with an opportunity to list temples and religious sites that would be to many to fit in Ausgram or Rarh, as an appendix to Sacred sites of South Asia (which would never be able to list them all). /Yvwv (talk) 14:52, 13 October 2022 (UTC)

I made a more inclusive rewording of Wikivoyage:Listings#Places of worship. /Yvwv (talk) 16:27, 16 October 2022 (UTC)

How to change the banner?

The one at Chorzów is very unappealing, showing some boring blocks of flat. And the coloring is very meh. Here are some better pics; I assume we need something that stretches horizontally? File:2022-0423 Horzow 102130.jpg (still boring, but at least more colorful); File:Chorzów, Dzielnica Chorzów II - fotopolska.eu (306185).jpg (nice pond, but picture has watermarks?); or one of these, if they are horizontal enough File:Chorzow poczta glowna.jpg , File:Chorzow poczta.jpg, File:Chorzow Plac Matejki.jpg, File:Chorzów - Ul. 3-go Maja 01.JPG, File:Chorzow Rynek estakada.jpg, File:Chorzow Wolnosci Street 2019.jpg... nothing great, but I think all would be superior to the current, very sad, image. Piotrus (talk) 04:04, 13 October 2022 (UTC)

See Wikivoyage:Banners. You can make a new banner with another image and just replace it in the guide like any other image. Agreed that the current one is pretty bleak. :/ —Justin (koavf)❤T☮C☺M☯ 04:17, 13 October 2022 (UTC)

Unless it's blindingly obvious, the procedure is to propose one or more new banners and ask for opinions on the talk page of the article in question, then change if/when a consensus develops. Ikan Kekek (talk) 06:06, 13 October 2022 (UTC)

The watermarks would easily be cropped out if using the pond. It seems there is a historic centre and modern (1970s?) residential areas. If tourists would be staying in the centre, I'd suggest using images from there for banner, otherwise the choice is more or less about what image can be cropped to give a nice banner. –LPfi (talk) 07:03, 13 October 2022 (UTC)

The banner expedition suggests a more consistent scheme (similar banners for regions, big cities and small cities), but I don't think we are using it. –LPfi (talk) 07:04, 13 October 2022 (UTC)

Continuing with what Ikan said, you can crop these photos into a banner using the CropTool. All you need to do is set the aspect ratio to 7:1 and crop the part of the image you want as a banner. SHB2000 (talk | contribs | meta) 09:11, 13 October 2022 (UTC)

@Piotrus, I've been using Wikivoyage:Banner suggestions if an article doesn't have an existing banner. Several of the more skillful volunteers watch that page and make the banners when I suggest them. I think this is something that you could recommend to your students, if the idea of doing it themselves seems intimidating. If an article already has a banner, then of course it's best to talk about it at the article's talk page, but when no banner image exists, this is an option. WhatamIdoing (talk) 19:20, 13 October 2022 (UTC)

@WhatamIdoing I like it! I'll show this page to students next week and probably do an activity, so expect several suggestions from them there! Piotrus (talk) 11:20, 16 October 2022 (UTC)

Tyrol

Any input on Wikivoyage talk:User ban nominations#What do we do with Tyrol? would be appreciated in regards to dealing with a banned user's work (all made after they were banned). --SHB2000 (talk | contribs | meta) 11:01, 14 October 2022 (UTC)

Wikivoyage portal (www.wikivoyage.org)

Hi, I have been updating project portals (e.g. www.wiktionary.org) to the new coding infrastructure to avoid storing them in pages in meta (m:Www.wikivoyage.org_template) among other reasons including better search experience, consistent design, better look, etc. Now every project has been migrated except wikivoyage because its portal is completely different (the picture of sunset).

I have been wondering if this is okay to change it to the standard portal design (like wikipedia.org) because:

• This is not accessible, the contrast of the text is too low (because of the background image) for people with visual impairments.
• The design is not following the Wikimedia standard (https://design.wikimedia.org/style-guide) for example the blue is not #36c
• The general look doesn't follow the standard all other projects follow, that's part of the movement's brand.
• The current design doesn't really take into account that we might have more wikivoyage languages in the future, doesn't have proper space for them (unlike the standard design)
• The current design is completely broken on mobile.

I mentioned this in meta but didn't get any response. So I thought I bring it up here. Fixing this would take care of a lot of legacy infrastructure we have. Thanks! Ladsgroup (talk) 12:19, 15 October 2022 (UTC)

• Support. That sounds like a good idea to me. Ground Zero (talk) 12:26, 15 October 2022 (UTC)
• Support. I've never been in love with the current design as soon as I saw it. I've always favoured Wikipedia's and Wikibooks' portal for the reasons you've mentioned above. SHB2000 (talk | contribs | meta) 12:28, 15 October 2022 (UTC)

What picture of a sunset? Is that only in the mobile portal? Ikan Kekek (talk) 18:32, 15 October 2022 (UTC)

@Ikan Kekek It's this page not the wiki's main page. Ladsgroup (talk) 18:43, 15 October 2022 (UTC)

I see. I have no great attachment to the sunset, so if the Wikimedia standard also has the virtue of being more visible on mobile phones, etc., sure, let's go with it. Ikan Kekek (talk) 22:41, 15 October 2022 (UTC)

• Support. --Comment by Selfie City (talk) (contributions) 11:51, 16 October 2022 (UTC)
• Support; I never really cared for that background image anyway. Might want to mention this on Wikivoyage-l or in the cross-language Pub on Meta. Powers ^(talk) 22:42, 16 October 2022 (UTC)

  sent to wikivoyage-l Ladsgroup (talk) 14:31, 17 October 2022 (UTC)

• Support These are all good reasons individually, let alone in concert. —Justin (koavf)❤T☮C☺M☯ 22:55, 16 October 2022 (UTC)
• Comment Do you have a mock-up of the revised design? OhanaUnited^{Talk page} 03:53, 17 October 2022 (UTC)

  @OhanaUnited unfortunately not but it'll be basically the same as any other portal (like https://wikiquote.org) except with different logo. Ladsgroup (talk) 14:32, 17 October 2022 (UTC)

• Support Sounds perfectly reasonable based on the justification provided. Travel Doc James (talk · contribs · email) 15:15, 17 October 2022 (UTC)

Forced work warnings in SE Asia articles

The Work sections of many Southeast Asian countries have recently been festooned with very lengthy and dramatic explanations (eg. Cambodia#Work) about the practice of basically taking foreigners hostage and forcing them to work, typically in scam call centers, under the threat of extreme violence. It's a real enough problem, but the scam operators seems to target Chinese speakers almost exclusively, meaning that English Wikivoyage is unlikely to be of much assistance here. Unless there are objections, I'll templatize the warning and cut it down to a few lines or so. Jpatokal (talk) 15:10, 16 October 2022 (UTC)

FWIW, I would expect most Chinese speakers who know at least a decent amount of English to read the English Wikivoyage. As it stands, zh.voy is nothing more than a few skeletons. SHB2000 (talk | contribs | meta) 06:30, 17 October 2022 (UTC)

@Jpatokal: Thanks for your opinion. For the following reasons I disagree with removing the warningbox templates from these articles, simply because they "only affect Chinese or Chinese-speaking people":

1. Chinese or Chinese-speaking people are not the only victims: there have been Malaysians, Vietnamese, Filipinos, and even Americans fell into victim of these heinous modern slavery schemes (all links are in Chinese, though you can verify by Google translate).
2. By practice it is OK to leave nationality-specific security warnings in Wikivoyage articles. For example we left warning that Chinese visitors should exercise additional precaution in Myanmar and Thailand, due to anti-government activist's hostility towards the Chinese government/state. Alternatively we wrote in Iran that state-sponsored hatred against the USA rarely projects on typical American travellers.
3. Per the opinion of SHB2000, Chinese Wikivoyage is really really empty. See these zh voy article about Cambodia or Thailand, and you'll have an immediate understanding on how empty these articles are. A reasonable Chinese-speaking reader will certainly not go for them, especially if they can read some basic English.

That said, if you have idea on how to simplify things, please leave a note. I indeed placed and consolidated some information at Working abroad#Human trafficking and modern slavery, and I'm OK with leaving a link and brief warning inside each warningbox templates within these affected articles.廣九直通車 (talk) 07:22, 17 October 2022 (UTC)

Quick comment from an English speaker (well, kind of) working with Asian (including Chinese students). Many don't have "a decent amount of English", but they do read English WV or Wikipedia (since they are larger) - but they do so using machine translation. It's a new phenomena, but the last few years are really seeing this trend on the rise. Those of you not working with young people or not working with non-English speakesr may not be aware of that, but it's a growing trend. Piotrus (talk) 07:25, 17 October 2022 (UTC)

I agree that we should serve all people. The question is about how much screen real estate of all readers to use. The warning on the country pages should be prominent and thorough enough for a traveller to realise they could be in danger, and the rest should be explained somewhere else. We should also concentrate on how to avoid the scam and how to get away when you still can, while specific facts on what has happened are unimportant. –LPfi (talk) 08:13, 17 October 2022 (UTC)

Thanks for the comments. To be clear, I don't want to remove them entirely, just trim them down a bit and use a shared template, and linking to a longer scam page is perfect. I've sketched out a draft at Template:Overseasjobscam and you can see it in action at Template:Overseasjobscam/Test. Jpatokal (talk) 08:18, 17 October 2022 (UTC)

• Support cutting down the size of the warning to like 25% of the current size and than link out to an article that provides further details to those who are interested. Support User:Jpatokal changes. Travel Doc James (talk · contribs · email) 15:18, 17 October 2022 (UTC)
• I support reducing the size (Doc James' suggestion of 25% sounds reasonable. Just in case anyone hasn't clicked through, here's what we're talking about:

	WARNING: Telecommunication fraud and illegal remote gambling are rampant in Cambodia, particularly Sihanoukville. Criminal enterprises rely on bait and switch to recruit pawns by offering seemingly high-paid jobs with little to no experience needed. Criminals may also invite victims travel to Cambodia or nearby countries on vacation. When targeting professionals, they may be invited for jobs requiring their profession in Cambodia organized by purported companies. A newer method is by establishing front companies in your country. After victims were employed and were given some tasks in their job, the company organizes a guided tour and uses the tour as a method to traffic victims en masse. In all cases, once arrived and under control, they will resort to coercion, false imprisonment and violence to force victims to work for them. Victims may be subjected to human trafficking and/or illegal organ transplantation. They may also be forced to recruit acquaintances or more travellers to join the enterprise, or simply taken hostage. Deaths caused by torture are not unheard of. Travelers from southeast Asia and Chinese-speaking regions are known to fall victim into this scam. Criminal syndicates have sufficient manpower and weapons to guard their bases, and it is nearly impossible for victims to escape on their own once abducted. Local authorities and the police in Cambodia may collude with criminal enterprises. Seeking help from uninvolved higher authorities or your country's diplomatic mission is probably a better choice to exert pressure and seek freedom. Even if you are freed, you may still face criminal prosecution in your own country for your acts committed in Cambodia. In any case: Always verify the employer's background and its address before your journey — criminal syndicates may leave fake addresses which can be identified through maps. Criminal syndicates may organize seemingly formal interviews or show faked employment environment to cover up their intention. To make their claim more appealing, criminal syndicates may claim that they have booked air tickets and hotels, or have brought insurance on behalf of the victims. Check with airlines, hotels and insurance companies to verify whether the booking is true or simply a facade. If you are going on a guided tour, always check if the travel agent is properly registered in your country. Recruitment ads posted on social media are particularly dangerous. Job advertisements published in places using Traditional Chinese but written in Simplified Chinese may be a hint of fraudulent job offer — they are likely written by Chinese criminal syndicates or Chinese victims. Do not easily trust recruitment ads or travel invitations send by your acquaintances. They could be already abducted and under the control of criminal syndicates — personal promises and experiences can be easily faked by coercion. If you suspect your acquaintances are under danger, STOP. Immediately report to the police to ensure investigation is opened swiftly. Applying for a normal tourist visa to work in a foreign country means the offer is at best illegal, at worst bogus. When arriving at your destination, avoid using transportation offered by the employer. Getting on the vehicle could well mean abduction and slavery aftermath. If you suspect that you are falling victim, STOP, contact your country's diplomatic mission immediately to seek help. Foreign criminal enterprises may also collaborate with gangs in your country to force and subdue victims. If you are first introduced to a hotel in your country to stay for a few days, or is supervised by suspicious persons during recruitment or departure, STOP, you are likely placed under control of local gangs. Try to contact local police by any means. It is much harder to seek freedom once you leave your country. Finally, if the job offer is too good to be true, it probably is. If you cannot ascertain the validity of the offer, reject it without hesitation. The following report hotlines may be useful if you unfortunately fall into victim. Seeking help from Facebook accounts of Cambodian government agencies may also help. However, make sure that your report and conversation are private and secure. Cambodia National Police: ☏ 0312012345 ☏ 0316012345 Cambodia National Police, Sihanoukville Branch: ☏ 011 506 677 ☏ 011 516 677 ☏ 011 526 677 Official WeChat account of Minister of the Interior Sar Kheng (who was in charge of dealing with the problem): ☏ +855 092 686 969
	Government travel advisories Hong Kong
	(Information last updated 19 Aug 2022)

That warning is longer than most articles. WhatamIdoing (talk) 22:45, 17 October 2022 (UTC)

Indeed. It should be collapisble at least. Also, it seems Cambodia-specific, so it should not be used in other SE Asia articles unless it is rewritten. Piotrus (talk) 03:47, 18 October 2022 (UTC)

Here's the proposed template, with parameters used for Cambodia-specific content. Jpatokal (talk) 04:04, 18 October 2022 (UTC)

WARNING: Overseas job scams are rampant in Cambodia, particularly Sihanoukville. People are lured in by offers of a high-paid job with little to no experience or work visa needed, then held hostage under threats of violence and forced to work in call centers, online gambling, etc. See Human trafficking for details. Chinese speakers are most frequently targeted, but others have been trapped as well. If you or somebody you know have been caught in this scam, contact your country's diplomatic mission, or local authorities at: Cambodia National Police: ☏ 0312012345 ☏ 0316012345 Cambodia National Police, Sihanoukville Branch: ☏ 011 506 677 ☏ 011 516 677 ☏ 011 526 677 Official WeChat account of Minister of the Interior Sar Kheng (who was in charge of dealing with the problem): ☏ +855 092 686 969

Government travel advisories Hong Kong

@Jpatokal: Thanks for your template work, and this specific warning box maintains the seriousness of the warning, yet is more slim and redirects a bulk of the information under Working abroad#Human trafficking and modern slavery. I support your solution.廣九直通車 (talk) 07:26, 18 October 2022 (UTC)

Ah, and I also just made the variable related to "2" (contact list for local authorities) to be an option, so that if we typed nothing in there, we won't get ugly unfilled items. Like, for example in rebel-held area in Myanmar (where criminals establish their bases due to complex environment), it's pointless to contact the Burmese police as they have no control over these area.廣九直通車 (talk) 07:36, 18 October 2022 (UTC)

Perfect, thank you. I'll add some docs to the template and swap it into the relevant SE Asia country articles. Jpatokal (talk) 03:04, 19 October 2022 (UTC)

"Add listing" not showing up on user page.

I am currently working on the User:RonanHoogmoed/Rivierenland page, where so far I have been adding listings manually. To save time and add information to Wikidata as well, I would like to use the "add listing" button since it's more convenient than working with templates. Is there a way to enable this on my user page, or is this limited to main space pages? Thank you in advance. RonanHoogmoed (talk) 06:46, 17 October 2022 (UTC)

@RonanHoogmoed Hmmm. I didn't realize it was under User/ prefix (userspace). Could it be that "add listing" functionality is mainspace-limited? Maybe it's time to copy your draft to Rivierenland and see if the "add listing" option appears there? Piotrus (talk) 07:21, 17 October 2022 (UTC)

@RonanHoogmoed: The "add listing" feature is limited to mainspace only, but you can still edit a listing using the listing editor in your userspace. SHB2000 (talk | contribs | meta) 07:21, 17 October 2022 (UTC)

@SHB2000 Funny question: what is a listing editor? If there is no add listing button, I am copy pasting the code. Never noticed another way to add a listing. Piotrus (talk) 07:23, 17 October 2022 (UTC)

The listing editor is the editor that pops up when you click "edit" to the right of a listing. You'll need to have JavaScript enabled, though. SHB2000 (talk | contribs | meta) 07:57, 17 October 2022 (UTC)

@SHB2000 Ah, yes, we use it, but it's often frustrating for much conten there is no 'listification' button. 'Add listing' should be an option for all headings, and there should be a 'listify' button, which would cut the highlighted content and dump it into the listing editor (description) section. Piotrus (talk) 03:45, 18 October 2022 (UTC)

[edit conflict] There should be buttons above the edit window (for the wikitext mode, I have never tried the visual editor at Wikivoyage). One way to come around the problem is to open a mainspace page for editing, perhaps using a redlink, add listings and then copy the resulting wikitext to the user space draft and close the mainspace page tab without saving. I assume the listing editor (the small print "edit" link at listings) should work in user space – if there already is a listing on the page, that link wouldn't be confusing like the "add listing" links would be on a normal user page (I haven't checked). –LPfi (talk) 08:05, 17 October 2022 (UTC)

@Piotrus, these buttons appear only in the 2010 wikitext editor (which is what your students should default to, if they're not in the visual editor).

I don't think there is any real need to restrict the feature from the User: namespace. We could consider turning it on there. WhatamIdoing (talk) 22:43, 17 October 2022 (UTC)

I agree that there's no good reason not to enable it in userspace. Ikan Kekek (talk) 00:03, 18 October 2022 (UTC)

Good idea! How can we do this? Piotrus (talk) 03:47, 18 October 2022 (UTC)

Well... I was going to say that we ask @Andyrom75 or Wrh2, but then I looked at the code, and I think it already is.

@Piotrus, the listing editor responds to specific section headings. I see it at User:WhatamIdoing/sandbox#Do. I don't know why it's not appearing at User:RonanHoogmoed/Rivierenland#Eat. WhatamIdoing (talk) 05:52, 18 October 2022 (UTC)

WhatamIdoing & Co., notwithstanding I haven't checked the code, I recall that the logic of (not) showing the "[add listing]" link is that the "region/country article" are supposed to be developed describing its content with verbose text, while "city article" are supposed to be structured with listings. That said, if a listing is present on "region/country articles", listing editor works normally (regardless the presence of the "[add listing]" link); see Tuscany as an example. To "guess" the type of article, the code check the presence of specific section titles. --Andyrom75 (talk) 07:47, 18 October 2022 (UTC)

What Andyrom75 said... the listing editor isn't supposed to appear on region articles to prevent people from adding listings to those articles. If an article has any of the following headings, the editor is disabled: '#Cities', '#Other_destinations', '#Islands', '#print-districts'. User:RonanHoogmoed/Rivierenland#Other destinations causes the editor to think that page is a region article and thus disables the editor. See also Wikivoyage:Listing editor#Configuration DISALLOW_ADD_LISTING_IF_PRESENT. -- Ryan • (talk) • 02:37, 19 October 2022 (UTC)

@Andyrom75, Wrh2: Just a suggestion, but it might be worth considering adding the section headers "Cities and towns", "Settlements", "Towns" as many of our region articles use these section headers. Unfortunately, there will be a few cases like Canberra/Tuggeranong and Country ACT which has a "towns" header, but I suppose the same logic can be applied. SHB2000 (talk | contribs | meta) 06:56, 19 October 2022 (UTC)

I assume there are many more variants. I have seen "Municipalities". But are there many region articles that don't have Other destinations? I somebody has a database dump handy, one could collect all level-2 headings before Get in and check what names are used, perhaps sorting and counting on the combination of headings (so that "Cities"+"Bungos"+"Other destinations" would count different from only "Bungos"), to avoid having to worry about local heading names where there also is a standard heading that can be used. –LPfi (talk) 07:51, 19 October 2022 (UTC)

@SHB2000, what we do on it:voy is to standardize the articles in a way that the main sections would be always present. We can clearly add subsections if and where needed.

For example, in it:voy we use "Centri abitati" that indicates any group of people that lives in a certain area, this include anything between metropolis and villages. I don't know if a similar approach can be used also in en:voy. Not strictly related to the listing editor, but in general if it worth to create uniformity between the various articles of the same type (countries, cities, regions, parks, etc.). Andyrom75 (talk) 14:00, 20 October 2022 (UTC)

To add onto this, I see that pages like Gyeonggi and Jeju also make use of listings, despite being region pages. I did notice that there's way less of them so I will adjust this on my page for Rivierenland, but I agree that it would be beneficial if it is possible to add listings to the sections that are common on region articles, since it seems like this is already happening frequently despite the lack of the "Add listing" button. RonanHoogmoed (talk) 05:57, 21 October 2022 (UTC)

@RonanHoogmoed: It is happening frequently, but a large proportion of that is touting. Mostly the listings should be placed elsewhere. The advice on that in the guideline was recently rewritten, so it is natural that there are a lot of articles where the current guideline isn't followed, and quite much work done to get rid of those listings. I cannot judge whether having pass-by editors put listings in regions is better than them not being able to. With the button missing, some will put them in the right place instead, some listings that we don't want will not appear, and some listings we want will not appear. I have no feel for which cases dominate, and no idea on how to get figures on it. –LPfi (talk) 07:14, 21 October 2022 (UTC)

@Andyrom75 But what about items that are located outside any locations, in villages that don't need their own WV article, or just "out there"? Shouldn't they get a listing in the region/country (well, region, country will likely never need them)? Piotrus (talk) 03:06, 21 October 2022 (UTC)

See Wikivoyage:Listings#Listings outside a destination. In some cases they should be placed in the region article, but it is problematic (less important attractions and facilities in backwater villages get more prominence than the main attractions in the cities) and there are other options. –LPfi (talk) 07:14, 21 October 2022 (UTC)

Piotrus, I haven't said that is forbidden to use a listing in a region article, I've just said that in the large majority of the cases, is much more appropriate to insert verbose content in place of structured content; that's why the "add listing"-link is missing in those article. --Andyrom75 (talk) 07:55, 21 October 2022 (UTC)

@LPfi The way I look at it, the important attraction in cities will have good listing in articles about the cities. The current way seems to discriminate against attractions, some of which can be very important (even UNESCO level) that are not in big cities. Piotrus (talk) 08:41, 21 October 2022 (UTC)

Most UNESCO World Heritage Sites will have some sort of nearby small settlement. Take Joggins as an example – normally, the village wouldn't have its own article, but it does because of the world heritage site. Otherwise, they could be park articles. SHB2000 (talk | contribs | meta) 08:50, 21 October 2022 (UTC)

Note the first bullet in the linked guideline: major points of interest can be included as "other destinations" in the region article. For minor attractions (some of which wouldn't be listed if they were in a city), listing them in the region article gives them excess prominence. LPfi (talk) 10:04, 21 October 2022 (UTC)

Travel topic on US colonies

I have read Wikivoyage:Travellers' pub/2022#Template for approval: Template:ColonialEmpires and realised why you should not create a list of empires in Wikivoyage in any form. However, I am wondering whether we should have an article on US colonies (or insular areas if more appropriate), under the name "Former colonies of the United States of America" or "Insular areas of the United States of America". Sbb1413 (he) (talk • contribs) 05:20, 19 October 2022 (UTC)

@Sbb1413: In theory, would make a good topic, but American colonialism was deleted last year because it had zero travel content in it. If you could find any travel-relevant sites, then I see merit in such an article, but an article with only history info is OOS. It's still a good idea in theory, though. SHB2000 (talk | contribs | meta) 06:51, 19 October 2022 (UTC)

Waypoint cities

I am wondering whether cities that are on a way to a destination should merit an article if the cities have other amenities but no attraction or activity. For instance, Rampurhat is a waypoint city to Tarapith (a temple town) in most cases and Rampurhat has hotels and restaurants but no attractions. These two cities along with Nalhati were merged to North Birbhum on the basis of "See" listing only. The same problem is observed in Kargil (a waypoint city to Leh), which has only one "See" listing. Sbb1413 (he) (talk • contribs) 08:32, 19 October 2022 (UTC)

I also like to point out that travelling is not for pleasurable or pilgrimage purposes only. After all, we have travel topics on various reasons to travel. Sbb1413 (he) (talk • contribs) 08:36, 19 October 2022 (UTC)

I recently wrote an article about New Italy earlier this month, which is a roadside town along a freeway. While it does contain a museum and an art gallery, it is only visited because it's a highway attraction. I think it would be fine creating such articles; I agree that travelling is not just for pleasure or the alike. SHB2000 (talk | contribs | meta) 09:08, 19 October 2022 (UTC)

I agree with SHB here. In some cases one-sight destinations are best covered in an itinerary, but they could also be mentioned in Get in and described in a Nearby section of the next town with article, or in some cases in the region article (if they are on an artery road of the region).

In this case Rampurhat and Tarapith are both handled in the rural area article of North Birbhum, which I think works well (although the article could be improved). Although the area is said to be "vast", there is just 20 km or so between the towns (that's nothing in Finland, but I understand distances in Bengal may feel longer). I don't understand the benefit of splitting it up if Rampurhat mostly is just a waypoint city of Tarapith. If the article becomes unwieldy, then one can reconsider.

See also Wikivoyage:Listings#Listings outside a destination and perhaps some of the long preceding discussion Wikivoyage talk:Listings#Listings outside of the destination, but

–LPfi (talk) 15:43, 19 October 2022 (UTC)

I want to split North Birbhum mainly to split Nalhati from Rampurhat and Tarapith, since Nalhati is a separate destination and may or may not be covered along with Tarapith. And I think Rampurhat can be best covered in Tarapith instead, since the distance between Rampurhat and Tarapith is about 8.8 km (5.5 mi) and can be covered in about 17 minutes. So I plunge forward and do the split. For Kargil, I will merge its nearby destinations to Kargil. Sbb1413 (he) (talk • contribs) 08:21, 21 October 2022 (UTC)

Yes. Do according to your best judgement. In this case your solution doesn't even conflict with the guidelines on the geographic hierarchy (if it would, one could rethink the division when trying to get some of them featured or up to star). –LPfi (talk) 10:11, 21 October 2022 (UTC)

UCoC EG Community review period closed

Dear Wikimedians,

Thank you for participating in the review of the Revised Enforcement Draft Guidelines for the Universal Code of Conduct (UCoC). The UCoC project team and the Revisions Committee appreciate you all taking the time to discuss the guidelines, suggest changes, and ask questions.

This community review period lasted from September 8 to October 8, 2022. Over the past four weeks, the UCoC project team has collected valuable community input from various channels, including three conversation hours sessions, where Wikimedians could get together to discuss the revised UCoC Enforcement Guidelines. The Revisions Committee will review community input when they reconvene in the second week of October 2022. The UCoC project team will support them in providing updates as they continue their work and will continue to inform the community about all important developments and milestones as the Committee prepares the final version of the UCoC Enforcement Guidelines that is currently scheduled for a community-wide vote in mid-January of 2023.

On behalf of the the UCoC project team,

Zuz (WMF) (talk) 11:39, 20 October 2022 (UTC)

Wikivoyage 10 planning

In a few months we have our anniversary, what could we organize to celebrate it?

I was thinking of making a meta page to set up a global campaign for our anniversary, apply for a rapid fund to organize a contest like the one we had five years ago, and maybe other activities that don't require funding.

What do you think? Galahad (sasageyo!)^(esvoy) 12:52, 21 October 2022 (UTC)