Wikivoyage:Travellers' pub

Welcome to the Pub Shortcuts: WV:Pub WV:TP The Travellers' Pub is 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 ask a new question

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.

Abolishing the "don't delete real places" policy

While we have had this rule of "don't delete real places", I think it is time to abolish that rule. To be honest, I had never understood the purpose of that policy in the first place, and even more so with the deletion requests. At the moment, the only reason that we've been using to delete real places is because of a copyright violation, but with the recent Nigeria Expedition, many articles have also been deleted because they are just barebone skeletons or because they are copied from another article or Wikipedia without attribution, also making it a copyright violation but fixable. Then there has also been the Lake Como stub creating IP who also had many of their articles deleted.

Oba Akoko is a good example. As of Special:PermaLink/4348076, it has nothing but section headers, and the only reason that we have to not delete it is because of the "don't delete real places" rule. Otherwise, it's stubby, it does not serve travelers and a new user is much more likely to start a fresh new article than convert a redirect into an existing article owing to the preloaded skeletons that pop up when starting a new page.

And then we have the user who has created a bunch of Lake Como stubs, most of which are copyvios, but even if they weren't, they were stubby and they do not help at all. IMO, the traveler should come first, not new users.

Therefore, I propose to just abolish the policy that real places cannot be deleted and they can still go through the process through vfd should they be deleted (except in cases of page creation vandalism by the one Australian user who we all know). --SHB2000 (talk | contribs | meta.wikimedia) 22:52, 18 March 2022 (UTC)

It sounds like you prefer m:Immediatism to m:Eventualism. WhatamIdoing (talk) 23:16, 18 March 2022 (UTC)

I think what we should have is exceptions to the policy, not its abolition. Ikan Kekek (talk) 03:37, 19 March 2022 (UTC)

I definitely leans towards eventualism than immediatism but of the two choices (deletion vs redirecting) I prefer deletion because when you link to that article and it's red, it becomes clear that we don't have content on it, unlike a redirect where you see blue and are more likely to assume there is content when there is none. It's particularly apparent on project pages like Wikivoyage:World cities, Wikivoyage:Requested articles and some of the expedition pages where we list out cities that are both blue and redlinks and the reds are meant to signal articles that should eventual be created.

I still however, prefer keeping real places over both deleting and redirecting because it is much easier to expand an article with a skeleton than start from scratch. When I recreate an article that was deleted because it was too short, I use the latest deletion version as a base, which I can view only because I'm an admin. Similarly, I find articles to expand in Category:Redirects connected to a Wikidata item, if the article prior to being redirected was connected to Wikidata, as is most often the case. But these methods are either not possible or well known for most editors, which is why I believe both deleting and redirecting stunt the long-term growth of Wikivoyage, though redirecting is worse. Gizza ^(roam) 05:29, 19 March 2022 (UTC)

There are three things we can do with stubs and skeleton articles:

A. Leave it alone for future growth,

B. Redirect to a nearby city or the region immediately above, or

C. Delete.

Having stubs and empty skeletons (A) does not put the reader first, it puts the project first. A reader who clicks on a blue link should get some information, and not a stub or a skeleton. Stubs and skeletons decrease the value of Wikivoyage to readers because of the annoyance factor. With the article skeletons, it is very easy to create a new article.

Not annoying readers is in the long-term interest of Wikivoyage because the more returning readers we get, the more editors we will have.

I know that some editors feel that redirecting to a nearby place or a region (B) also annoys readers if the articles don't say anything about the place the reader was hoping to find out about by clicking a blue link.

That really leaves deletion (C) as the best option for us. Readers navigating by using links won't be irritated by false promises. Those readers using Search to navigate will be disappointed by finding no results, but readers know that getting no results from a search is always a possibility. Ground Zero (talk) 11:36, 19 March 2022 (UTC)

I don't feel like an extremely short article puts the project first. The median amount of time a reader spends on a page in less than a few seconds. This is true on basically all the wikis; readers often want just the most basic information (where's that again?). Also, by having a stub, we're enabling the Page Previews to provide that information even when people don't click all the way through. Having two sentences and a link to something else actually is helpful to these readers.

(I don't feel the same about a that has no content beyond the section headings.) WhatamIdoing (talk) 15:23, 19 March 2022 (UTC)

If it is just a line or two, it is more convenient for the reader to have that in a region article without a link. Ground Zero (talk) 16:42, 19 March 2022 (UTC)

If it's only in one article, and if that line or two won't interrupt the flow of the article, then you might be right. But would you want to have multiple articles each include a line or two, thus duplicating content across all of those articles?

And what if it would disrupt the article you're writing? You might want to write something "To find lower-cost accommodations during the music festival, look for options as far away as Boondocks to the north and Big City to the east". You probably don't want to double the length of that sentence by cramming "(a rural area in the North County on the side of the Big Mountain that is increasingly popular for cross-country skiing during the winter)" into the middle of it. WhatamIdoing (talk) 01:11, 20 March 2022 (UTC)

If someone is just searching a place up to see where it is, aren't they more likely to use Wikipedia rather than a travel guide? Tai123.123 (talk) 19:06, 19 March 2022 (UTC)

I agree. It doesn't even have to be in a region article – it can be in a topic article (such as the redirect for Savage River National Park) (ps to Tai123.123, if someone is looking for a place just to see where it is, wouldn't they be using something like Google Maps or OpenStreetMap rather than Wikipedia?) SHB2000 (talk | contribs | meta.wikimedia) 23:08, 19 March 2022 (UTC)

When you are already on this site, why would you want to switch to another site? And if you did, you might wonder whether the location you found was actually the relevant one. There are more than 1,000 places in the world named San Jose. If you see one of the many San Joses mentioned in an article here, and you want to know where it is, then following the link should provide certainty. The traveler is actually served by the existence of San Jose (Palawan), even though it is not usable in its current state, and the traveler would not be better served by having a red link at Palawan#Cities. WhatamIdoing (talk) 01:18, 20 March 2022 (UTC)

I said Wikipedia as it’s affiliated with Wikimedia and when one simply plugs a city name into a search engine it will be one of the first results (it will also have other basic information). Tai123.123 (talk) 01:36, 20 March 2022 (UTC)

Makes sense. SHB2000 (talk | contribs | meta.wikimedia) 09:21, 20 March 2022 (UTC)

Tai, "plugging a city name into the search engine" is never as quick and easy as "clicking the correct link". Also, if you do that for my example, you'll end up at w:en:San José, which lists 139 different articles, 138 of which are guaranteed to be the wrong one. Expecting people to do extra work (searching) and giving them a mostly-wrong and always-confusing answer (how confident are you that you could always guess which one of these places was mentioned at Wikivoyage?) is not really helping the traveler. WhatamIdoing (talk) 16:14, 20 March 2022 (UTC)

Keep the policy, possibly with some exceptions made specific, e.g. copyvio articles. There is a lot of previous discussion at Wikivoyage_talk:Deletion_policy/Archive_2014-2019#Deleting_NEW_empty_articles and the following sections. —The preceding comment was added by Pashley (talk • contribs) 13:25, 19 March 2022 (UTC)

• I've been in support of permitting the deletion of real places for a while. We've had discussions about redirecting vs leaving articles a handful of times before with no resolve (this proposal being the latest proof of that). I think allowing a deletion option might help to end those debates. I believe last time this was discussed, someone mentioned possibly giving users a time limit to add enough content to prevent deletion. The idea seemed to have some tepid support as I recall, but we never implemented or tested it. ChubbyWimbus (talk) 15:44, 19 March 2022 (UTC)
• I'd like to point out that there's another solution for " redirecting to a nearby place or a region also annoys readers if the articles don't say anything about the place the reader was hoping to find out": Saying something about that place as part of the redirection. Ikan Kekek (talk) 19:45, 19 March 2022 (UTC)

Creating new content is always an ideal solution. But when we are addressing situations where dozens or scores of articles have been created with no travel information, it's not a realistic one. Ground Zero (talk) 01:45, 20 March 2022 (UTC)

As an example, see the thousands of Puerto Rican skeletons currently nominated at vfd#Puerto Rico skeletons with a byte count lower than 600 created by Ligocsicnarf89 (talk · contribs). Our policy does not permit the deletion of those. As I mentioned, this is to allow real places to be nominated at vfd because as GZ mentions, it's not realistic. SHB2000 (talk | contribs | meta.wikimedia) 01:59, 20 March 2022 (UTC)

There are of course alternatives. The guidelines actually suggests we leave the articles alone, but enough editors are/have been dissatisfied with that to make it a non-solution. Editors could also add enough content to the articles to make them minimally viable articles and I believe Ground Zero has said that he tried to do that before making redirects, but this is not always possible and is unfair to expect of editors who may not know or care about the destination stubs created by others. This is also the issue with the redirects. If you do not have enough knowledge to make the article minimally viable, it is unlikely that you will have enough knowledge to provide meaningful information in the redirected article either, and just saying "This article also covers..." when it doesn't isn't enough. The deletion option just seems better than the other options. ChubbyWimbus (talk) 05:19, 20 March 2022 (UTC)

Wikivoyage does permit deletions of page-creation vandalism. Allowing deletions of masses of pages with essentially no content that the article-starter hasn't gotten back to in months is not a stretch and I don't think it requires us to do anything other than make such situations exceptions to the existing policy. Ikan Kekek (talk) 05:27, 20 March 2022 (UTC)

• Some batches of useless near-empty outlines are created in good faith, so applying "page creation vandalism" is an insult to the user. A slight rewording might suffice, but the rule was created for vandalism. I think batches of outline created for a project, where the participants (or the single user) disappeared or lost interest before adding content, could be deleted through VFD, if that seems what is best for the traveller.
• An individual bare outline is not too frustrating for the reader (such things happen on wikis), but when a region contains many bare or weak outlines, they are frustrating, and likewise, if a user coming to the site mostly meets weak articles, they might not return. We need to keep the project and region wide proportion of useless articles low enough. We could discuss the outlines of a region at VFD.
• Redirecting would make sense if people wouldn't otherwise find what we have to tell about the place, but people come there by a search, which would turn up the mention in the region article, or by links from other articles, which could go directly to the region, if that's what makes sense. Redirects do make sense in some cases, but not as general solution.
• A link to the redirect from the redirect target (often the region) is confusing, and turning a redirect into an article requires some expertise. The existing workarounds are suboptimal.
• If there is something salvageable in a to-be-deleted outline, it can be moved to the region article or the talk page. There are other possible solutions to this. Of course, if there is enough salvageable material, the outline should probably be kept or properly merged.

–LPfi (talk) 09:26, 20 March 2022 (UTC)

"if a user coming to the site mostly meets weak articles, they might not return": This sounds plausible, but most of our traffic is via search engines, and I doubt that people spend a lot of time remembering which site they used in the past when the search engine's snippet looks promising. WhatamIdoing (talk) 16:17, 20 March 2022 (UTC)

I for one remember bad sites if I encounter them often. I might click the link, but click "back" as soon as I recognise the layout. –LPfi (talk) 16:49, 20 March 2022 (UTC)

We could also fall into the trap if a user looks at a terrible empty page on the museum piece and then thinks this may be the same site, but this really isn't the place for that and it's off topic to what this original thread was about so I'll stop it there.

However, it is worth noting that I have never seen an outline skeleton pop up in my search results. I won't comment any further on that though, as it's off topic, but I think the point is clear. SHB2000 (talk | contribs | meta.wikimedia) 10:08, 22 March 2022 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ In light of a recent discussion and to prevent this discussion from dying, I propose we change the policy to the following:

When possible, we try and redirect real places into neighbouring or nearby destinations when possible. However, when that is not possible, or if it is not in the best interests of the traveller, deletion may be discussed at votes for deletion. Exceptions of when real places can be speedily deleted include copyvios, if the page was created in bad faith, vandalism or when most of the article violates wv:outside.

Does that seem like a suitable compromise? That way, deletions of real places can be discussed at vfd because the current policy does not permit so. Pinging participants of this discussion: @LPfi, WhatamIdoing, Ikan Kekek, Ground Zero, DaGizza, ChubbyWimbus, Pashley, Tai123.123:. Before I finish off my comment, here's a quick list of who's in favour and against the proposal:

In favour of deleting real places:

• SHB2000 (myself)
• Ground Zero
• ChubbyWimbus

Against deleting real places and in favour of redirecting:

• Pashley
• WhatamIdoing

Can't tell or don't fall into either of the above two categories:

• Ikan Kekek – which I'm judging based on their comments, is to keep the policy, but all the real places discussed at vfd are made as exceptions.
• Tai123.123 – made two comments that were not enough to judge which side they were taking.
• Gizza – against deleting, but also against redirecting. In favour of keeping.
• LPfi – who seems to be taking a stance either side.

To those that oppose deleting and favour redirecting, I would like for you to reconsider your opinion. Just because real places can be nominated for deletion, it doesn't mean they have to. It is not like we're going to nominate every single damn article which looks stubby to us, and the only reasons why there's a lot of real places currently nominated for vfd right now is because there's a lot of Nigeria articles that do not serve the traveller. This new amended policy discourages nominating regular articles, unless there's good reason to so after these Nigeria articles have been cleaned up, it is unlikely we'll be seeing any real places nominated for deletion, and maybe a maximum of maybe five pages (if we don't have any sort of major projects or expeditions like this).

--SHB2000 (talk | contribs | meta.wikimedia) 13:15, 21 April 2022 (UTC)

Most readers have no idea what "wv:outside" refers to (I didn't), and by "violating" it, you mean including only listings of places out of town, so let's please be clear. It seems to me, we are still talking about exceptions to policy. This would be my proposed language:

Articles for real places that cannot support an article are normally redirected to articles for nearby destinations. However, when that is not possible, or if it is deemed not to be in the best interests of the traveller, they may be nominated for deletion at votes for deletion. In cases of copyright violation or large-scale page-creation vandalism, cases in which all of the information is about places outside the destination, or persistent lack of information on the order of including only the text "[Destination name] is in Region name", speedy deletion may be necessary and appropriate. In some such cases, especially deletions due to copyright violation, good-faith recreation of the deleted article in a way that solves the problem is welcome.

Ikan Kekek (talk) 13:46, 21 April 2022 (UTC)

Support – your version seems clearer to me and also addresses on whether recreating an article is permitted or not. Only thing I'd suggest is replacing "[City name]" with "[Destination name]" as parks, city districts and rural areas are also included. Not sure about dive guides. SHB2000 (talk | contribs | meta.wikimedia) 14:02, 21 April 2022 (UTC)

• Support I think this addresses all of the concerns and may help alleviate the redirect discussions by providing a deletion option without completely abandoning our "don't delete real places" policy which is mostly good. ChubbyWimbus (talk) 14:08, 21 April 2022 (UTC)

SHB2000, I substituted your term. Ikan Kekek (talk) 14:21, 21 April 2022 (UTC)

Support, The new version is worded in a less ambiguous manner and strikes a balance between both the redirecting and the deleting sides. Tai123.123 (talk) 14:53, 21 April 2022 (UTC)

Support. What isn't said in that paragraph can be sorted out at VFD, and language can be added later as appropriate, such as if some class of articles is brought up there too often. –LPfi (talk) 17:07, 21 April 2022 (UTC)

I think it will be important to move this discussion to Wikivoyage talk:Votes for deletion, as that's the intuitive place to find it in the future. Ikan Kekek (talk) 22:04, 21 April 2022 (UTC)

or Wikivoyage talk:Deletion policy. SHB2000 (talk | contribs | meta.wikimedia) 23:25, 21 April 2022 (UTC)

Support We clearly need something like this. I think that most cases should be VFD, not speedy. (We also should consider what the rules will be for any future competitions to avoid mass creation of articles with little useful content.) AlasdairW (talk) 23:04, 21 April 2022 (UTC)

I agree. I'd note that the VfD thread on the multiple articles about Puerto Rico helped facilitate a great editing project, whereas speedily deleting everything would have been less useful. Ikan Kekek (talk) 23:29, 21 April 2022 (UTC)

I think that, for competitions, it might be useful to recommend that page creation not 'count' unless at least three useful listings, including one place to sleep, get added. We can't force contest organizers to adopt a recommendation, just like we can't force contest organizers to tell us about their contest plans in advance, but I suspect that most of them would be happy to follow our advice. (This proposal sounds fine to me, too.) WhatamIdoing (talk) 16:28, 22 April 2022 (UTC)

Template:If mobile

Do we have an equivalent on Wikivoyage to en:Wikipedia's w:Template:If mobile? Cheers, • • • Peter (Southwood) ^(talk): 17:37, 22 March 2022 (UTC)

@Pbsouthwood: You can check the associated Wikidata item to see that we do not (yet). —Justin (koavf)❤T☮C☺M☯ 17:41, 22 March 2022 (UTC)

@Koavf:, Thanks, was not aware I could do that. • • • Peter (Southwood) ^(talk): 06:52, 23 March 2022 (UTC)

No problem. On (most) any piece of content from (most) any WMF project, if you press Ctrl+Alt+G, you will be taken to the associated Wikidata item (if it exists, which it usually does). If you need a template reproduced here, admins can import it via Special:Import. —Justin (koavf)❤T☮C☺M☯ 06:56, 23 March 2022 (UTC)

@Koavf:, Useful to know, hope I remember when I next need it. Do you know if it would run in voy? I am not familiar with the code, and I have had trouble with templates from WP needing supporting software before.• • • Peter (Southwood) ^(talk): 07:03, 23 March 2022 (UTC)

Great question. Probably not very easily, as it relies on a couple dozen modules and templates and those rely on others, etc. This is why I am very hesitant to import on any wiki where I'm an admin: it's almost always more trouble than it's worth. Maybe if/when global templates come into existence, maybe this will all go away, but until then... :/ —Justin (koavf)❤T☮C☺M☯ 07:16, 23 March 2022 (UTC)

@Evad37:, could you advise on potential complications? • • • Peter (Southwood) ^(talk): 07:37, 23 March 2022 (UTC)

We also need to import w:Template:If mobile/styles.css and I'm pretty sure it will need an interface admin to do it. @Andyrom75:, by any chance, can you import it? SHB2000 (talk | contribs | meta.wikimedia) 08:08, 23 March 2022 (UTC)

Before importing something, may I understand which is the specific need here in en:voy? I'd like to check first if there's any alternative. --Andyrom75 (talk) 09:00, 23 March 2022 (UTC)

This kind of convoluted templates may have all kinds of odd side effects unless well implemented, and may not do what one supposes them to do. Perhaps one can trust this to be well implemented (I don't know), and the documentation is clear: "detects whether it is being used on the mobile version of Wikipedia (en.m.wikipedia.org)". The rationale is odd, though, at it seems to deal with tweaks on wordings, not functional differences. Of course, the latter might be handled by the software.

This template does not know what kind of device the user is using. I don't know how much tweaking the software does when the ordinary site is used by smartphone users or the other way round (hopefully very little). Anyway, to add functionality inside this kind of template to get around bugs in the normal handling of mobile devices requires quite deep knowledge on what those bugs are and why they haven't been fixed for the general case.

The original need, I think, was to provide mobile users with a smaller file than desktop users. The desktop user may however be on a mobile net, using their smartphone as router, or may otherwise have restricted resources. My Firefox has deficient zooming facilities, so the smartphone version would be good for me, avoiding my having to open the map in a separate image viewing application (which shouldn't be a big deal, but still).

–LPfi (talk) 09:31, 23 March 2022 (UTC)

The template provides alternative content depending on whether one is viewing the desktop rendering or the mobile rendering. As we are probably all aware, the mobile rendering is less than optimal with some relatively complicated formatting, and there is no way of knowing when or if it will be fixed. I have been trying to implement some good suggestions for a star nomination, and ran into some of these issues. If I can use this function I can provide the best version for desktop, and the best version for mobile, depending on which the user chooses to use. I got the impression that the template does not know what device is in use, it just sends content based on which site is being used (mobile or default) From what little I understand of it, it chooses css based on the site and just suppresses the content of the unwanted/unsuitable part, but what I know about css is extremely little, maybe just enough to be confusing, which is why I was hoping for comment from Evad37, who created the template and would probably know how simple or complex it would be to import. I seldom use my smartphone for browsing, really only to check rendering of Wikipedia and Wikivoyage articles, but I use a tablet a lot – in desktop mode, because mobile frustrates the hell out of me. However, almost all of the people I know who use the dive site articles do it on their phones on mobile, often on a boat at sea, so falling back to a laptop or desktop is not an option. Cheers, • • • Peter (Southwood) ^(talk): 11:52, 23 March 2022 (UTC)

Andyrom75, it is in connection with a problem familiar to you, The issue of map toggling between static and dynamic which does not happen on mobile, and the alternative image cannot be linked from the map caption either, so I end up with two maps to get it to work. Not a total train-smash, but it would be nice to use the more elegant solution. Cheers, • • • Peter (Southwood) ^(talk): 12:05, 23 March 2022 (UTC)

Just to make a long story short: the content can be formatted according to the used view (mobile/desktop) or according to the actual size of the screen, changing the project Mediawiki pages or the templatestyles of a specific template/module.

Pbsouthwood, that said, if the issue we want to solve is just the map, I can figure out a specific tweak for that; keeping in mind that toggling effect (a Javascript feature) can be solved only server side by WMF, not client side by us. So what I need to know is exactly "which is the specific problem". --Andyrom75 (talk) 14:34, 23 March 2022 (UTC)

@Johanna Strodt (WMDE), do you want to hear about this kind of map problem in your survey? WhatamIdoing (talk) 16:11, 23 March 2022 (UTC)

Johanna Strodt (WMDE), WhatamIdoing, we were talking about phabricator:T111565 that is not related to map, but if you could fix it, you would have our endless gratitude :-P --Andyrom75 (talk) 17:04, 23 March 2022 (UTC)

Andyrom75, If it is going to be a specific tweak for a specific page, it makes sense to to take that discussion to the talk page of the article. I will ping you from there for your convenience. Cheers, • • • Peter (Southwood) ^(talk): 16:58, 23 March 2022 (UTC)

If it works as desired I will eventually want to use the tweak for a couple of hundred other dive sites, but if necessary I can copy and paste my way through. • • • Peter (Southwood) ^(talk): 17:25, 23 March 2022 (UTC)

Andyrom75 I pinged you from Talk:Diving the Cape Peninsula and False Bay/Whittle Rock#The map. I don't know if you got the notification. • • • Peter (Southwood) ^(talk): 08:01, 25 March 2022 (UTC)

@Andyrom75@WhatamIdoing: Thanks for the pointer. Yes, we'd appreciate this input in the survey. Thank you to everyone who is taking part, and to you, @WhatamIdoing, for creating some buzz around it! -- Johanna Strodt (WMDE) (talk) 08:11, 25 March 2022 (UTC)

Sorry that I'm getting back to this later, but I think the solution is that users specifically click on "Mobile view" at the bottom of every page or just type in "https://m.en.wikivoyage.org/wiki/foo". —Justin (koavf)❤T☮C☺M☯ 18:35, 23 March 2022 (UTC)

Solution to what? I for one only do that if I want to see what a mobile user will see to check that the page is rendering usefully and without too many surprises. If using a mobile phone, which is what most of the readers of my dive site articles do, most of them don't even know there is a choice, and desktop view is debatably even worse on such a small screen. Cheers, • • • Peter (Southwood) ^(talk): 09:25, 24 March 2022 (UTC)

Oh, sorry, I misunderstood how it worked. You can freely ignore me. —Justin (koavf)❤T☮C☺M☯ 15:48, 24 March 2022 (UTC)

Template:Regionlist

After discussed with Peter (Southwood), the first step to solve the above issue is to modify the template in the subject to adapt its output to the used skin (the WM skin is associated to the view mode hence to the device: mobile/desktop).

An example of how work the modified version can be seen at Diving the Cape Peninsula and False Bay/Whittle Rock.

If approved, I'll copy the sandbox in the official template to apply this behavior to all the articles (some test are required by anyone to be sure that everything is fine). --Andyrom75 (talk) 10:05, 31 March 2022 (UTC)

The current difference (as of writing) seems to be adding "nomobile" to the classes of two sections and adding a new "mf-mobile-only" section, to be shown instead of those sections. If I guess at the effect correctly, it seems to be a sensible way to code it. I cannot judge whether it works as intended. Do I understand correctly, that the smaller resolution map is shown for everybody? Then to get to the print-size one, one would have to click through to Commons and check the "other versions" field in the description. –LPfi (talk) 11:09, 31 March 2022 (UTC)

(The result of a diff between two pages is more than a little confusing if you try to check the context. Don't worry. –LPfi (talk) 11:12, 31 March 2022 (UTC))

[ec] I will describe my experience, Andyrom75, please check that this is what you get too.

• As far as I can tell, the same static map is displayed on both desktop and mobile, at the widths specified in pixels as parameters in the template. They can be the same width or different, if I remember correctly, default is 350px. This is following the original template quite closely.

• In desktop, if you click on the static map it opens, at the specified width, and if you click again it opens in full resolution. This is adequate, intuitive, and there are no surprises. If you click on the message in the caption the dynamic map opens, The parameters allow centering and zoom of the dynamic map. It shows the markers defined on the page. I do not know if you can select classes of marker to show or not show, like listing, see, do, etc as I have not needed to try.

• In mobile, only the static map is displayed, at the width specified for mobile at low resolution. I think this is normal. The caption does not offer the option of clicking to toggle with the dynamic map, as mobile does not support toggling. The compromise is reasonable and accepts current reality. Maybe one day it can work better, but that appears to need a Mediawiki fix, and for now this seems the reasonably practicable option. If you click on the static map it opens a larger thumbnail which can be zoomed in the normal way, but clicking on it again appears to do nothing, and does not open a larger file. To get to the highest resolution it is necessary to go to commons via the "Details" button, select the higher resolution you want, and open it in commons. In some cases, maybe most cases, the larger thumbnail will be big enough to zoom in to the details one needs, and when this is the case the modification seems to be an adequate improvement and fit for use. There are edge cases when the full resolution is needed, and Andyrom75 has offered to draft a separate template for those cases once this version is settled. This proposed template will be useful for dive site maps, where a lot of detail may be included in the static map, which therefore needs to be opened at high resolution to make the text legible, but some of the other features of Template:Regionlist are not needed.

• Where the limitation on mobile image size is acceptable, the sandbox version seems to be a good compromise, but I have not tested all the optional functionality, which does not apply to my use case, and which is one of the reasons for opening this discussion. More eyes may identify other bugs, or confirm that the sandbox template is fit for general use. Cheers, • • • Peter (Southwood) ^(talk): 12:08, 31 March 2022 (UTC)

Peter (Southwood), your resume is correct. Up to the end of April I will have very limited time, so, if there's no objection I can "put in production" the sandbox, but I won't be able to monitor how it works nor to quickly fix any potential issue.

Let's be sure that someone else can act on my behalf or revert this template change. That's said, let me know (pinging me) if I can proceed. --Andyrom75 (talk) 10:35, 8 April 2022 (UTC)

Andyrom75 It should be simple enough to revert if there is any problem. I could do that if necessary, as could several others. I don't know if we will get any more feedback, and in view of ease of revert maybe you should just go ahead if there is no further comment within 24 hours. Cheers, • • • Peter (Southwood) ^(talk): 14:38, 8 April 2022 (UTC)

Peter (Southwood) Done. --Andyrom75 (talk) 11:23, 9 April 2022 (UTC)

Importante message from WikiSP

Important Message

---

Help us!

---

We, Wikimedia Small Projects in Spanish, as an official affiliate of the Wikimedia Foundation watch over all the small projects of the movement and carry out initiatives for the communities to benefit. Today we have made a request for general support to fund our annual action plan.

What will we do?

• DataVoyage in Commons: An editing workshop on how to collaborate with Wikidata, Wikivoyage and Commons (eswikivoyage only),
• Wikivoyage 10: A contest celebrating Wikivoyage's ten years as part of the Wikimedia family (all communities),
• Wikivoyage Asian Month: A contest in which you can write guides related to Asia (all communities),
• Wikivoyage mobile app: A prototype that will allow mobile access to Wikivoyages
• Small Projects Conference: A conference where we talk about all the small projects of the Wikimedia movement, as well as agreements and ideas to implement in the future.
  
  

What can you do?

• Start a discussion among yourselves to come up with other initiatives that will further benefit the communities and notify Wikimedia Small Projects so that they can be implemented next year.
• Support the request' by placing your signature in the discussion: Grants talk:Programs/Wikimedia Community Fund/Wikimedia Small Projects 2022-2023#Communities support
• Volunteer in one of our initiatives: Are you interested in collaborating directly in our initiatives? Let us know!

We are here to change course and it is only possible with your support!

Learn more

---

21:28, 23 March 2022 (UTC)

Wikivoyage's 10th anniversary is already coming up?! It feels like the 5th was just a little while ago. WhatamIdoing (talk) 18:41, 24 March 2022 (UTC)

I wasn't here back in 2018, but time really has flown since then. It seems that the museum piece (aka The Other Site) is only getting worse day by day based on a weekly check I do. --SHB2000 (talk | contribs | meta.wikimedia) 20:52, 24 March 2022 (UTC)

This is what I can do for the upcoming 10-year anniversary of Wikivoyage. A video to put on the YouTube channel. Video- https://drive.google.com/file/d/1b4EJKWyB9bZDibAEmDgGQ0wfPsYCsw-q/view . It took about 2 hours. Suggest some changes or correction and feel free to criticize Cheers! :) 2006nishan178713^t@lk 19:41, 25 March 2022 (UTC)

@2006nishan178713 Nice video – don't think there's anything criticise, even if you go extra nitpicky ;-). The only thing I'd say is that the 31000 could become 32000 soon (we currently have 32,940, and if we manage to create a little over 700, it may become 32000 soon). SHB2000 (talk | contribs | meta.wikimedia) 12:14, 27 March 2022 (UTC)

Yes! 2006nishan178713^t@lk 12:44, 27 March 2022 (UTC)

And, of course, it's been around since 2003, but was only adopted later. It was a very early MediaWiki wiki. —Justin (koavf)❤T☮C☺M☯ 22:08, 24 March 2022 (UTC)

If we count since the first wikivoyage was migrated would be Sep 23. If we count since the first wikivoyage accepted, Jan 07 (eswikivoyage). But our birthday is Jan 15! Galahad (sasageyo!)^(esvoy) 23:50, 24 March 2022 (UTC)

I remember @GVarnum-WMF saying something about trying to make a list of the birthdays-as-celebrated a while ago. I assume that the Wikivoyages are on the list for January 15th. WhatamIdoing (talk) 16:01, 25 March 2022 (UTC)

Hi @WhatamIdoing, have you seen this List of Wikimedia Birthdays? MPourzaki (WMF) (talk) 20:16, 30 March 2022 (UTC)

Thanks for the link, @MPourzaki (WMF). It looks like all of the Wikivoyages are on the "needs verification" list, and only English and German are listed separately. @RolandUnger and DerFussi, can you check the German "birthday" on that page? English is correct, as far as I know. WhatamIdoing (talk) 00:23, 31 March 2022 (UTC)

@WhatamIdoing: There are two Wikivoyage birthdays: On Dec. 10, 2006, Wikivoyage went online in Germany as a new project forked from Wikitravel (so Wikivoyage is now 15 years old). On Jan. 15, 2013, Wikivoyage officially became a Wikimedia project. On this day, the Wikipedia turned 12. On Nov. 9, 2012 Wikivoyage was available from Wikimedia servers. On Sep. 23, 2012 the English Wikivoyage was started, in October, 2012 the Netherlandish, French, Swedish and Russian ones followed. In the list mentioned above I added the Italian Wikivoyage which was started on the 1st Wikivoyage birthday. --RolandUnger (talk) 05:09, 31 March 2022 (UTC)

English Wikivoyage at the Wayback Machine. --RolandUnger (talk) 05:34, 31 March 2022 (UTC)

I understand it's inconvenient, as the original name has changed hands, but shouldn't we also keep in mind the date when the project was started as a private initiative on a private server? I think that for the early contributors the unfortunate things that happened in-between is a parenthesis that doesn't mean the origins are to be forgotten. –LPfi (talk) 06:46, 31 March 2022 (UTC)

I think this particular list is only for "official birthdays", which may or may not have much relationship to first edits. Whatever date each Wikivoyage (or other) community prefers to count as their anniversary is the one that belongs in this list. WhatamIdoing (talk) 15:01, 31 March 2022 (UTC)

I think it's a good idea to write down the history, but that would belong on another page. WhatamIdoing (talk) 15:02, 31 March 2022 (UTC)

(Aside) Has anyone tried to make 'travel' video content? I am thinking more in the viewn of the Holiday shows the BBC used to have as opposed to "Since the dawn, Time-Life has been presenting it's majestic hyperbole across screens globally. Seldom have the eyes..." type travelouge. 88.97.96.89 14:35, 27 March 2022 (UTC)

m:VideoWiki lets you make a sort of narrated slideshow. You can include both video and still images. The machine-generated voice option is not impressive, but recording a real voice means that you can't change the text later. WhatamIdoing (talk) 15:46, 27 March 2022 (UTC)

Marker template doesn't render Wikidata link

Hi:

I'm doing my first maps in ENwv. My case is not so trivial so I need to use Marker templates instead of the standard others to group poi's as I need. But I'm finding the Wikidata links (or other related) are not render. My mockup is at my user space.

My markers are like:

 {{marker
 | name = Castillo de los Marqueses de Los Vélez
 | type = other
 | wikidata =Q922097
 | group= vélezblanco
 }} 

Of course the final article will be in English. I'm just learning to use the templates.

What I'm doing wrong? Olea (talk) 12:35, 28 March 2022 (UTC)

@Olea Try removing the spacing and enter {{marker| name=Castillo de los Marqueses de Los Vélez| type=other| wikidata=Q922097| group=vélezblanco}} . It should produce 1 Castillo de los Marqueses de Los Vélez . Ping me if it doesn't. Cheers, SHB2000 (talk | contribs | meta.wikimedia) 12:38, 28 March 2022 (UTC)

That shouldn't be needed. Your code above renders as 2 Castillo de los Marqueses de Los Vélez , identical to that by SHB2000 what I can see. It also renders at the linked "mockup". Are you worried because the Wikidata icon doesn't appear? It doesn't at markers, I think. –LPfi (talk) 13:28, 28 March 2022 (UTC)

@LPfi I would really like to link to Wikidata because many of these places have pictures in Commons but not any wiki article. I tried not to use Marker but Listing, but seems Mapframe template can't filter listing entries groups:

Mapframe filters by «paisaje»

{{Mapframe | align = center | name = Paisajes de la ruta de interés cultural de la provincia de Almería | height=300|width=800 | group=paisaje }}

but when using Listing instead of of Marker:

{{Listing | name = Castillo de los Marqueses de Los Vélez | type = other | wikidata =Q922097 | group= vélezblanco }}

Am i missing something obvious? Olea (talk) 18:03, 28 March 2022 (UTC)

Group isn't mentioned on Template:Mapframe/doc. Have you tried using layer=paisaje (instead or in addition to group). It is mentioned, although hidden further down the page. There is also "show". I don't know how these three differ and what they are intended for. The documentation would need to be improved. But some of them might work (layer did in a quick test). –LPfi (talk) 19:04, 28 March 2022 (UTC)

Maybe group is not mentioned in Template:Mapframe/doc but it works with Template:Marker. Don't ask me why :-) Olea (talk) 21:40, 28 March 2022 (UTC)

The group parameter works for both Listings and Markers, but to show them on a map you need to define that group with the show-parameter within the Mapframe. So, in the example you listed above using {{Mapframe}}, replace |group=paisaje with |show=paisaje, and all should be working as expected.
-- Wauteurz (talk) 21:47, 28 March 2022 (UTC)

The |show=paisaje works like a charm, but only with Markers. Template:Listing/doc instead explicitly states template doesn't pass the group parameter to Marker: The "zoom" and "group" parameters for the {{Marker}} are not currently supported or passed through by {{Listing}}..

In this test the doc seems to be right: User:Olea/Workshop2. Olea (talk) 09:28, 29 March 2022 (UTC)

I was looking at the problem mentioned by Olea, and found something strange. This marker: {{marker | name = Fortín 12 | type = other | wikidata=Q97286349|...}} has NA for "lat=" and "long=". Removing the NA resulted in the following error message: Lua error in Module:Marker at line 64: attempt to index field 'datavalue' (a nil value). Next step was replacing Q97286349 by Q1071 (Geography), a Wikidata item that has no location, after which the error message disappeared. So something must be wrong with the Wikidata item, but also with the Marker software, because the error message should not occur for just missing the NA value for lat/long. --FredTC (talk) 12:58, 29 March 2022 (UTC)

@FredTC: Q97286349 has its coordinate location set to "Unknown value", which is likely what causes the problem there.

@Olea: It does indeed look like the support for grouping isn't built into {{Listing}} at all. I don't remember that being the case, but looking at where I used listings and markers together in Dutch Empire, there are only few listings, all used in the same section of the article, so it never posed a problem there. I don't know whether it's possible for someone to add the support for grouping into Listing, but if so, it would be very helpful for not just you. For what it's worth, it seems you'd have to convert all listings to Markers if you want to add one of them to a group until a fix is made.
-- Wauteurz (talk) 13:13, 29 March 2022 (UTC)

I finally moved to markers only. But I really miss the links to other projects, specially Commons, as it can be made in ESwv (like this example, check for «Despoblado de Los Millares).

I really thank you all :-) Olea (talk) 16:06, 29 March 2022 (UTC)

@Olea: I changed the markers to listings and show/group lines to layer in User:Olea/Workshop1#Paisaje de Vélez Blanco. Isn't this how you want it? –LPfi (talk) 17:36, 29 March 2022 (UTC)

Only that Paisaje de Tahal (where I now did the same change) shows the same markers as Paisaje de Vélez Blanco. Did I do some simple mistake or what is this about? –LPfi (talk) 17:48, 29 March 2022 (UTC)

Yes. the maps of Tahal and Velez Blanco are the same, combining the elements of each one, which is not the expected result ː-/ Anyway, I can't see the layer attribute described at Template:Listing/doc, but... who knows ː-) Olea (talk) 18:02, 29 March 2022 (UTC)

Leadership Development Working Group: Reminder to apply by 10 April 2022

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

More languages • Please help translate to your language

Hello everyone,

The Community Development team at the Wikimedia Foundation is supporting the creation of a global, community-driven Leadership Development Working Group. The purpose of the working group is to advise leadership development work. Feedback was collected in February 2022 and a summary of the feedback is on Meta-wiki. The application period to join the Working Group is now open and is closing soon on April 10, 2022. Please review the information about the working group, share with community members who might be interested, and apply if you are interested.

Thank you,

From the Community Development team

Best, Zuz (WMF) (talk) 13:40, 28 March 2022 (UTC)

Wikidata Template Sync doesn't check for references for statements overwritten

Is it a known issue that when you sync coordinates or other data from the Wikivoyage editor for templates that corresponding statements are 1. being removed when they should be deprecated 2. not creating a new statement in Wikidata where an existing statement value should not be changed due to the reference being different. For instance a Wikidata Q may have geocoordinates that are off of the building which Wikivoyage may have more accurate coordinates. The wikidata statement has a reference sourced from GNIS or other database. Syncing Wikivoyage to Wikidata replaces the coors for the GNIS or other database, but leaves the database as the source and does not indicate Wikivoyage was the source of the new coords thus incorrectly leaving a conflated statement in Wikidata that cannot be traced to Wikivoyage and and incorrect statement that the database provided a value which may be inconsistent with the database's stored value. Wolfgang8741 (talk) 14:52, 30 March 2022 (UTC)

Example data sync issue of the coord from Wikivoyage to Wikidata resulting in overwriting the value, but not changing the reference for the value with corresponding edit. Wolfgang8741 (talk) 16:19, 30 March 2022 (UTC)

If so, this is very problematic. We can be pragmatic, but when people on Wikipedias check statements on Wikidata, they should not differ from what is said in the cited source. The simplest solution is to never sync to Wikidata when there already is a non-deprecated value with a reference. To be able to sync even then, we'd need to provide a reason for deprecating the existing value or a modifier saying how our value is different from it. I assume it is very difficult to implement sensibly in the general case and probably not worth the trouble.

It would be nice to be able to deprecate or remove the former coordinates when they are erroneous, or add our owns (with a modifier) but perhaps it is better to just fail and provide a link: "Wikidata coordinates have a reference. Go to Wikidata for checking and correcting as appropriate (instructions)". The instructions would explain the difference between Wikidata and Wikivoyage coordinates, things to check before changing, and common modifiers and reasons for deprecating.

–LPfi (talk) 07:09, 31 March 2022 (UTC)

The never syncing to Wikidata for non-deprecated values should only be a stop gap measure and ideally the Listing editor could be corrected to include the proper logic to handle existing statements. There are many coordinates on Wikivoyage which are more precise to the location of the object than those from the database. I am bringing this to the community's attention so corrective action can be taken to mitigate further damage and remediate the changes that have overwritten Wikidata values with references. I only recently found the tool's name after posting the initial inquiry above. Relying on people reading instructions would help, but not prevent the root of the issue which is the tool lacks necessary checks to prevent introducing issues on a large scale (and should be fool proof once fixed).

1. Get a fix to stop any further perpetuation this issue by the Wikivoyage:Listing editor as soon as possible.

2. Start to identify what sync actions have affected Wikidata coordinates.

3. Revert wikidata edits for coordinates synced from Wikivoyage to the original referenced values. A challenge to this is the lack of a "tool tag" on edits to Wikidata to identify changes made by the Listing Editor's sync action or a consistent change comments that would identify the listing editor as being the source. One or both of these approaches should be added to the Listing Editor when syncing to help with identifying edits by this tool.

I would lean to adding a new statement with Wikivoyage value and reference and deprecating the existing statement and offer in the listing editor confirmation box a set of reasons from typical reasons for depreciation. This would allow others relying on Wikidata to detect and make a decision on how to handle the value change. Wolfgang8741 (talk) 13:30, 31 March 2022 (UTC)

I mostly agree with these points. However, making the tool handle deprecating or replacing values on Wikidata properly is difficult.

1. We want inexperienced editors to easily use the tool. Thus we cannot require reading instructions (unless we offer different features to different groups).
2. Wikidata uses properties differently from e.g. Wikipedias. If we overwrite coordinates for the source and mouth of a river with a point where you conveniently can get down to it, people at Wikipedias will be furious. Changing midpoint to entry point is not hat bad, but still contentious.
3. Replacing a value with reference with one without reference is a degradation. Wikipedia in Swedish generally does not show such values in infoboxes.
4. I considered suggesting a list of reasons for deprecating, containing at least "erroneous". The problem is that the user interface isn't well versed for seeing whether the coordinates (or any other properties) really are wrong. If the coordinates are for the office, not for a park itself, how can the tool show that they make sense after all? It does not show the extent of the listed object, nor does it show enough of other context. I ended up thinking that to judge the case properly, you have to check the item proper at Wikidata. Thus we should provide that link, and a link to instructions, including common reasons to deprecate etc.

A separate property for Wikivoyage coordinates would solve the conflict. We wouldn't need a reference and wouldn't get into conflict with the Wikipedias or other third parties.

–LPfi (talk) 15:45, 31 March 2022 (UTC)

Lets focus on preventing continued data corruption and remediate what has been done then look to a solution to how to fix the Listing editor.

I don't recommend going the new property route as it doesn't solve the root of the issue and I doubt a WikiVoyage specific coord property would be accepted since the issue can be solved with a precise and formatted statement in the existing coordinate property. Either with a new property or existing property the coordinates from Wikivoyage would still require a reference else the Wikivoyage value should not be transferred to Wikidata as a statement is unreliable without a source.

The Listing editor would be better off to make sure the statement is correctly added without overwriting existing data if the values do not match and reference Wikivoyage while marking the Wikivoyage as preferred rank with the qualifier as more precise and not touch existing statements or at most mark a preferred statement as normal if not deprecated. An additional qualifier might be warranted if a specific part of a location should be the coordinate value rather than center of a building as is handled for the dual coordinates of head and mouth, main entrance to a building, etc. The editor would need to load all normal and preferred coordinates and qualifiers associated to make an informed decision to sync to Wikidata or not. Wolfgang8741 (talk) 20:13, 31 March 2022 (UTC)

Sorry if I missed some of your points in my previous response, but I agree with much of what you are saying. I'm not suggesting to implement a good UI and set of controls for a corrected function would be easy. I've been studying issues in design as part of my degrees for some time now. Can we agree to pin the "fix" discussion and focus on preventing further corruption and identifying the scope of the issue? Wolfgang8741 (talk) 20:27, 31 March 2022 (UTC)

I agree. I assume adding an edit summary to the Wikidata edits would be an easy first fix, allowing us to later fix any breakage we cause. The next step, I think, is to fail if a Wikidata item with reference would be overwritten; a crude version first, special cases can be added later. Then a discussion on what cases we should allow and what to do about them. –LPfi (talk) 16:06, 1 April 2022 (UTC)

Looking at the Wikivoyage edit you linked above, it seems we do have edit summaries our side: "→‎Connect: Updated listing for Troy-Miami County Public Library - link to wikidata and sync". We could check for all edits on Wikidata with matching user and timestamp. But first the two first steps. –LPfi (talk) 16:11, 1 April 2022 (UTC)

Yes, failing if a reference exists will stop further corruption and effective first step. Do you know how to do this? If not, who and how do we get that implemented? The identification and cleanup is going to be more complicated and probably needs coding to go over Wikidata and Wikivoyage histories.

The "link to wikidata and sync" is what I write on Wikivoyage, it is not generated by the tool and the problem is looking at the change comment on Wikidata which only includes "Set a claim value: coordinate location (P625): 40°2'30"N, 84°12'26"W" and looks like a manual edit without a comment. I write these comments to help track when I'm syncing, any other user sync action isn't noted and is hidden.

Tracking down all possible errors for as long as this issue has existed in the Listing editor will require a systematic programmatic approach as there is a significant burden to correlate edits that may be syncing. We have to look at which WikiVoyage listings currently have or previously had coordinates on all pages. Look at the corresponding Wikidata item linked or ever linked since the bug began and check all Wikidata items that had a coordinate value with reference since the bug originated. If a change ever occurred to the coordinate on Wikidata when a reference was present a comparison would be needed to any coordinate combination for the listing item(s) that are associated if that value ever matched Wikivoyage at the same time. This would give an probable source that we could have humans review or just revert to the value of the reference Wolfgang8741 (talk) 01:39, 2 April 2022 (UTC)

OK. The edit summary looked like it could have been from the script. I think it does create edit summaries if you don't provide any, which would be the case for most edits by non-regulars. The page to edit is probably MediaWiki:Gadget-ListingEditor.js and the most recent editor is Andyrom75, who might be able to tweak it as needed. I haven't coded javascript or anything for the Wikidata API myself. I will take a look for possible obvious tweaks, but I'm afraid there needs to be non-trivial functionality added. –LPfi (talk) 14:31, 2 April 2022 (UTC)

Wikidata usually supports multiple values, so instead of failing to sync, it might be possible to keep the old (ref'd) data value and add a second (unref'd, from Wikivoyage) value. RolandUnger and Ryan know the code and might be able to help when they're around. Alternatively, there are tech-savvy folks at WMDE and Wikidata who might be willing to help us out. WhatamIdoing (talk) 16:30, 2 April 2022 (UTC)

Multiple values are possible, but they should not have the same rank, unless there are qualifiers making them distinct. The added value should have a suitable qualifier for it to be chosen for Wikivoyage use, and there probably isn't any that fits. Otherwise there are two conflicting values, being randomly chosen for Wikivoyage and Wikipedias (except those that check references etc. like sv-wp does). I don't think fixing this properly is much more difficult than fixing it as a hack that causes problems. Overwriting values without reference is no big deal, they shouldn't be there in the first place, but if there is a properly sourced one already, we should have a rationale for adding ours at the same (non-deprecated) rank. That can be done with a qualifier, if we find suitable ones to choose from, in cases where the former value doesn't have it. In most cases it must be done manually, after having studied the item. –LPfi (talk) 18:58, 2 April 2022 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I am wondering that this issue is discussed only now. And I know that I will draw ire presenting my proposal: You should remove the sync tool. This quick-and-dirty tool is useless. On the one hand, it is not necessary to make a sync into the wiki: this can be done by the listing script itself (or the author can overwrite it). And the sync into Wikidata causes many difficulties which cannot be solved easily by a/the current script. In most cases the tool cannot make a well-founded decision. That's why such a tool was not implemented at the German Wikivoyage (by the way, German Wikivoyage analyses about 50 Wikidata properties, not only five)! I am sure that there will be no programmer doing this job, at least neither Ryan nor me. Doing that takes a lot of time which should be spent for more important tasks.

Of course you can add a second value to a property in Wikidata but this is senseless because nobody will use it. Why sync? We will upset the people of the Wikidata community who has to clean up the entries. Of cause we need a better in-wiki integration of Wikidata but this should be done by Wikidata programmers. And by the way, maybe a lot of inexperienced authors will not understand why to sync.

Maybe you should think about the future of the listing template, too. In the current state it is really outdated going back to Wikitravel times or prehistoric digital age without Instagram and booking.com. There are so many data stored at Wikidata -- but they aren't used in English Wikivoyage. --RolandUnger (talk) 06:51, 3 April 2022 (UTC)

• Secondary values, if I am not mistaken from assisting on a cyclone template years ago (Wikipedia); these are used in tracking cyclones, hurricanes positions over a period of time already... Not sure if same property -- Matroc (talk) 03:41, 5 April 2022 (UTC)
  • I suppose those coordinates have a date qualifier. The same would apply to a business that has moved, and it should be easy to use only values valid for the current date. Without qualifiers, there should be only one value at the highest rank; for duplicates there is no way for the listing to know which one is relevant to Wikivoyage. –LPfi (talk) 07:48, 8 April 2022 (UTC)

On syncing in general: I think it makes sense for an editor to check values fetched from Wikidata, so a manual sync to Wikivoyage makes sense. The other way around, perhaps naïvely, I don't see why syncing is a bad thing – in cases where the values are lacking at Wikidata, given that the Wikidata item is the right one in the first place. If we add a reference to the article on Wikivoyage, any Wikidata editor or third party (such as Wikipedia editors) can judge whether it is trustworthy enough for their purposes. –LPfi (talk) 07:59, 8 April 2022 (UTC)

Given that I personally only update the wikidata coords if it's really broken, would it make sense to always store reference:WV to the updated data? WD editors can always revert it, if it turns out to be incorrect for some reason. -- andree 08:21, 10 April 2022 (UTC)

It would be a great improvement. The question is what property to use for that reference. A reference to the edited page, preferable with a permanent link, would make that even better.

The issue on how to treat a previous value remains. If it is kept, then we have duplicate values. If it is replaced by the listing editor, the question is how to make sure the editing user has made sure the previous values really were erroneous (and they should properly be deprecated with that very reason, if they have a reference or source).

–LPfi (talk) 08:55, 11 April 2022 (UTC)

Results from the Universal Code of Conduct Enforcement guidelines ratification vote published

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

More languages • Please help translate to your language

The Trust and Safety Policy team published the results of the Universal Code of Conduct Enforcement guidelines ratification vote. The vote ended 21 March 2022. See the results and read more on Meta-wiki.

Best, Zuz (WMF) (talk) 11:45, 6 April 2022 (UTC)

"eg"

I got 423 results for a site search for "eg". Some of the results are OK, but many of them are for the abbreviation for the Latin phrase, "ex gregis." I edited them out of London Stansted Airport, but there were like five of them. To my knowledge, the standard abbreviation is "e.g.", which makes perfect sense. Before I consider changing the rest of them, please tell me whether a different abbreviation (such as "eg" or "eg.") is actually standard and preferred in any part of the English-speaking world. I hope not, but let me know. (By the way, "i.e." is a similar situation: the abbreviation is for "id est".) Ikan Kekek (talk) 04:51, 7 April 2022 (UTC)

I have seen eg and eg. fairly often, and I believe it is always wrong. It should be e.g. plus a comma if you would have added a comma in the same situation if you had instead typed for example instead of e.g.. Also, as a non-English term, IMO it ought to be italicized. WhatamIdoing (talk) 16:03, 7 April 2022 (UTC)

wv:abbreviations doesn't opine on the issue, but Wikipedia sets out e.g. and i.e. as its style. We have a lot of readers for whom English is a second language, so clarity that these are acronyms should take precedence over "local style". Of course, "for example", and "that is" are even clearer. Ground Zero (talk) 16:13, 7 April 2022 (UTC)

I agree with GZ. If I'm not mistaken, adding periods or full stops in the acronym also helps screen readers pronounce the term which increases accessibility, but ultimately "for example" and "that is" is a much better alternative. SHB2000 (talk | contribs | meta.wikimedia) 21:34, 7 April 2022 (UTC)

I wouldn't italicize it. Ikan Kekek (talk) 21:45, 7 April 2022 (UTC)

More importantly, thank you for your replies! Do you think we need to mention these matters of style somewhere? I also agree that "for example" and "that is" are better alternatives. Ikan Kekek (talk) 23:39, 7 April 2022 (UTC)

I think "eg" is just laziness, for which style guides do not help. And I think e.g. is so well-established that italics would be more confusing than clarifying, and I haven't seen people italicising it here. But ex gregis? Wiktionary says "exempli gratia", which is what I have learnt. Neither Wiktionary nor my English dead-wood dictionary knows "(ex) gregis". –LPfi (talk) 06:08, 8 April 2022 (UTC)

You're right. "Ex gregis" is the phrase that "egregious" comes from, so it means "out of the group" but is used in a negative sense. Ikan Kekek (talk) 06:19, 8 April 2022 (UTC)

Thanks @Ikan Kekek for this interesting thread. I am curious to see how one goes about making hundreds/thousands of tedious changes to existing content and will try to follow your edits. I am asking because I am facing something kind of similar on another wiki. Cheers, Ottawahitech (talk) 01:00, 12 April 2022 (UTC)

I don't know if I'll do it. Ikan Kekek (talk) 02:04, 12 April 2022 (UTC)

For this kind of changes it is useful to have some external tools. The Wikipedia:AutoWikiBrowser is probably the most commonly used one, available for Windows (and Wine on Linux) and not requiring coding proficiency. For more advanced tasks there is the Wikipedia:Pywikibot, which requires some Python programming. In doing semi-automated editing it is important to note that you are still responsible for every edit, that bulk stylistic changes are often frowned upon, and that there are a number of pitfalls, such as quotes and odd uses of a phrase that otherwise should be corrected. –LPfi (talk) 08:20, 12 April 2022 (UTC)

Review request and permission to get into main namespace

Hiː

We are working in a set of new itineraries in Spain and the first is, supposedly, done. Hereby I'm asking for a review and authorization to recreate the article in the main space. It's our first contribution in ENVoy and want to be sure we are doing fine. The first itinerary is User:Olea/Workshop1. We'll be happy to attend any recomendation. Thanks in advance. Olea (talk) 17:34, 12 April 2022 (UTC)

I think there is no reason not to move this itinerary to mainspace. There are a few issues, such as the links to Wikidata, which may be confusing, but these can be sorted out later. You say "recreate", is there some reason not to just move the page to mainspace? To what name? Route of the Landscapes of Cultural Interest in Almería? Is there some commonly used shorthand? –LPfi (talk) 17:48, 12 April 2022 (UTC)

@LPfi thanksǃ

We chose to recreate because the original text is full of tries and tests which are not meaningful but about our inexperience in Wikivoyage. Also, for better IP traceability as this is a paid work for a government agency. The itinerary is now at Route of the Landscapes of Cultural Interest in Almería created by UserːIAPH.

About the Wikidata links, what the problem is? We understood they could be more suitable than to the external link. Olea (talk) 09:32, 13 April 2022 (UTC)

Also, we would like to now how to improve the quality status to reach, if possible, the star status. Any tip? Should propose at a particular place? Olea (talk) 09:35, 13 April 2022 (UTC)

I have not taken a thorough look now, but I think there should be some copy editing by a native English speaker. There may also be some style issues (I spotted a "we", which we don't use), I'll return to them at some point.

The Wikidata links are quite confusing for a reader not acquainted with that project. Landscapes of Cultural Interest in Andalusia could be a Wikivoyage travel topic, in turn linked to Wikidata by links at Wikidata. Our policy is not to link "external" pages, other than the official ones. Wikimedia sites are listed via Wikidata or by our listing templates. Exceptions can be made, but they should be clearly useful for the traveller. In many cases it is enough to find those links e.g. via related Wikipedia articles.

–LPfi (talk) 09:59, 13 April 2022 (UTC)

We have done a new review and removed all Wikidata/Wiki links. We are now applying the same changes to the other two new itineraries. Olea (talk) 08:49, 19 April 2022 (UTC)

Wow, that's quite a professional use of many of our templates. I wish I knew how to use all of those tricks.

I'd suggest linking it from the relevant articles (e.g., Almería (province), Europe itineraries, etc) so it can be accessed by the interested viewers. Currently the article isn't linked from anywhere in the mainspace. Vidimian (talk) 16:54, 21 April 2022 (UTC)

@Vidimian thanks for your kind words, we really appreciated them :-) I've added internal links as suggested. Olea (talk) 12:36, 25 April 2022 (UTC)

Great. However, as far as I understand, the route is completely within Almería Province, so it's better listed at Almería (province)#Do than the "Go next" section. Consider viewing wv:wycsi for the relevant guideline. Vidimian (talk) 12:43, 25 April 2022 (UTC)

Done with the three routes. Thanks! Olea (talk) 13:14, 25 April 2022 (UTC)

Movement Strategy and Governance News – Issue 6

Movement Strategy and Governance News
Issue 6, April 2022Read the full newsletter

---

Welcome to the sixth issue of Movement Strategy and Governance News! This revamped newsletter distributes relevant news and events about the Movement Charter, Universal Code of Conduct, Movement Strategy Implementation grants, Board of trustees elections and other relevant MSG topics.

This Newsletter will be distributed quarterly, while the more frequent Updates will also be delivered weekly. Please remember to subscribe here if you would like to receive future issues of this newsletter.

• Leadership Development - A Working Group is Forming! - The application to join the Leadership Development Working Group closed on April 10th, 2022, and up to 12 community members will be selected to participate in the working group. (continue reading)
• Universal Code of Conduct Ratification Results are out! - The global decision process on the enforcement of the UCoC via SecurePoll was held from 7 to 21 March. Over 2,300 eligible voters from at least 128 different home projects submitted their opinions and comments. (continue reading)
• Movement Discussions on Hubs - The Global Conversation event on Regional and Thematic Hubs was held on Saturday, March 12, and was attended by 84 diverse Wikimedians from across the movement. (continue reading)
• Movement Strategy Grants Remain Open! - Since the start of the year, six proposals with a total value of about $80,000 USD have been approved. Do you have a movement strategy project idea? Reach out to us! (continue reading)
• The Movement Charter Drafting Committee is All Set! - The Committee of fifteen members which was elected in October 2021, has agreed on the essential values and methods for its work, and has started to create the outline of the Movement Charter draft. (continue reading)
• Introducing Movement Strategy Weekly - Contribute and Subscribe! - The MSG team have just launched the updates portal, which is connected to the various Movement Strategy pages on Meta-wiki. Subscriber to get up-to-date news about the various ongoing projects. (continue reading)
• Diff Blogs - Check out the most recent publications about Movement Strategy on Wikimedia Diff. (continue reading)

Zuz (WMF) (talk) 10:27, 13 April 2022 (UTC)

LintErrors

Thanks to some efforts earlier, I am reasonably satisfied that the 'content' side of English Wikivoyage has been de-linted as far as I am able to without additional expertise.

What remains unlinted is User pages, and what are essentially Talk and discussion namespaces, but a consensus has emerged that these should not be adjusted (even in good faith.)

Congratulations. It only took 4 years to de-lint English Wikivoayge :).

ShakespeareFan00 (talk) 15:54, 13 April 2022 (UTC)

Where's the discussion about delinting user pages? Ikan Kekek (talk) 16:00, 13 April 2022 (UTC)

I don't have the specfic discussion to hand, but it was what I had been advised off wiki by a number of contributors (not necessarily directly on Wikivoyage though). In any event non account-holder changes to userspace pages are now generally considered bad practice I've been told. ShakespeareFan00 (talk) 16:29, 13 April 2022 (UTC)

If you have admin/custodian status and want to resolve the few remaining LintErrors in User and various talk namespaces (most likely signatures that were accepted under previous versions of Mediawiki/HTML/CSS etc.) , I can't stop you obviously. ShakespeareFan00 (talk) 16:31, 13 April 2022 (UTC)

I don't care about this kind of stuff, but I was asking because I didn't remember seeing a discussion on this topic. Ikan Kekek (talk) 16:57, 13 April 2022 (UTC)

Also, some consensus on another Wiki does not apply to Wikivoyage. So if you really want to know what people on Wikivoyage think, you have to actually ask them... Ikan Kekek (talk) 17:03, 13 April 2022 (UTC)

Sure, but what we care about and what we should care about are not necessarily the same thing. —Justin (koavf)❤T☮C☺M☯ 21:08, 13 April 2022 (UTC)

I think the work in mainspace was good, as broken syntax may result in broken pages for some readers. For user space, more discussion would be needed. For some users it is no problem – many like other contributors fixing things on their user pages – for others it may be problematic, especially if the fix breaks something else and they aren't here to revert or complain. –LPfi (talk) 07:36, 14 April 2022 (UTC)

There is a table of the lint errors at fireflytools. For things such as the obsolete font tags, if those were to be fixed by updating them to span tags, then I think that should be done by via a bot account. -- WOSlinker (talk) 11:17, 14 April 2022 (UTC)

See also Special:LintErrors. The "high priority" items are generally things that have the potential to make a page look visibly broken. Ideally there would be none of those in any namespace, though obviously many people will decide that it is not worth their own time and efforts to fix problems in low-traffic user pages. I wouldn't be inclined to stop anyone from fixing errors anywhere. WhatamIdoing (talk) 16:01, 14 April 2022 (UTC)

I notice that a dive site template has "bogus file parameters" of (NNNpx). This seems to be explanatory text in examples. How do we normally handle that? –LPfi (talk) 17:16, 21 April 2022 (UTC)

Join the Wikimedia Foundation Annual Plan conversations with Maryana Iskander

More languages • Please help translate to your language

Hello,

The Movement Communications and Movement Strategy and Governance teams invite you to discuss the 2022-23 Wikimedia Foundation Annual Plan, a plan of record for the Wikimedia Foundation's work.

These conversations continue Maryana Iskander's Wikimedia Foundation Chief Executive Officer listening tour.

The conversations are about these questions:

• The 2030 Wikimedia Movement Strategy sets a direction toward "knowledge as a service" and "knowledge equity". The Wikimedia Foundation wants to plan according to these two goals. How do you think the Wikimedia Foundation should apply them to our work?

• The Wikimedia Foundation continues to explore better ways of working at a regional level. We have increased our regional focus in areas like grants, new features, and community conversations. What is working well? How can we improve?
• Anyone can contribute to the Movement Strategy process. Let's collect your activities, ideas, requests, and lessons learned. How can the Wikimedia Foundation better support the volunteers and affiliates working in Movement Strategy activities?

You can find the schedule of calls on Meta-wiki.

The information will be available in multiple languages. Each call will be open to anyone to attend. Live interpretation will be available in some calls.

Best regards,

Zuz (WMF) (talk) 09:49, 15 April 2022 (UTC)

Review request for two new itineraries

Helloː

Here it is a new request for review two new itineraries. Both are a paid work of the Spanish government cultural agency IAPH (talk · contribs) made by Urci dream (talk · contribs) and Olea (talk · contribs). Content is a derived and authorized work of IAPH originals. The new itineraries areː

• Route of the Landscapes of Cultural Interest in Jaén
• Route of the Landscapes of Cultural Interest in the province of Huelva

Thanks a lot! Olea (talk) 21:07, 19 April 2022 (UTC)

I'd suggest shorter titles, just Landscapes of Cultural Interest in Jaén & Landscapes of Cultural Interest in Huelva Pashley (talk) 00:28, 20 April 2022 (UTC)

Does this article pass wiaa

I created Fort Lytton National Park last night, which is a 0.13 km² (0.050 sq mi) national* park in Brisbane. Our policy permits the creation of national and most state/provincial parks, but doesn't for small city parks, and Fort Lytton National Park falls into both categories. Would like other opinions. --SHB2000 (talk | contribs | meta.wikimedia) 00:15, 20 April 2022 (UTC)

I'd say merge the see and do section into Brisbane and redirect the page there as it seems to be a city park. For example Gateway Arch National Park is a redirect to St. Louis as its a city park despite holding national status. Tai123.123 (talk) 00:19, 20 April 2022 (UTC)

Though we do have other articles that are city parks managed by the state government such as Malabar Headland National Park, Sydney Harbour National Park, Lane Cove National Park, or Belair National Park, but they are all in Australia. SHB2000 (talk | contribs | meta.wikimedia) 00:27, 20 April 2022 (UTC)

I feel that fort lytton is different than the articles listed above as it seems more like a historic site than a natural area making it more like a city listing than a standalone park. additionally the other parks listed are big enough to have their own page while fort lytton only has three listings and could be a subsection of a city page. Tai123.123 (talk) 00:47, 20 April 2022 (UTC)

The Malabar Headland is only 1.7 km² (0.66 sq mi), and that also has nothing more than a walk and a lookout point though. But I do get your point though about the others being much larger. SHB2000 (talk | contribs | meta.wikimedia) 04:18, 20 April 2022 (UTC)

It doesn't matter whether or not a park is formally designated as a "national park". If it's so large, complex, and/or remote as to be a destination of its own, then it likely makes sense for it to have its own article. If its size, attractions, and location are similar to a city park, it should be covered in a listing in a city article (or, rarely, a district article in the case of a particularly large and complex city park). It looks to me like Fort Lytton National Park should be covered in Brisbane. —Granger (talk · contribs) 10:20, 20 April 2022 (UTC)

I think it isn't the status as national parks that make parks worth their own articles, but whether they are complex or different enough not to fit as a city Do or See listing of at most a few paragraphs, and whether they are large enough that many visitors would stay overnight (the sleep test). –LPfi (talk) 11:11, 20 April 2022 (UTC)

"Article" on colonialism

I wonder if we should create this as just a landing page, so we can list all the articles we have about the various colonial empires. Because of the complexity of this, the "article" will inevitably be a stub, but we could also use this to list tourist attractions connected to say, American, German or Italian colonialism, which we currently don't have articles for on Wikivoyage. The dog2 (talk) 16:22, 22 April 2022 (UTC)

Colonialism dates back to at least the Phoenicians, so if we want to be reasonably comprehensive, we should cover cities that started as Phoenician colonies, Hellenistic Greek colonies and ancient Roman colonies as well as colonies of European countries (and Japan, etc.) in the 15th century ff. Ikan Kekek (talk) 16:34, 22 April 2022 (UTC)

Kind of a "history of the whole world" article. Maybe that's the sort of overly ambitious, sprawling, hard-to-contain article that will be contentious and soak up a lot of volunteer time to provide something that is not much related to travel. Ground Zero (talk) 16:46, 22 April 2022 (UTC)

Would it be useful to have this as a landing page though? In that way we can list all the articles we have about the various colonial empires, and people can then click on the article of the specific colonial empire they wish to dive deeper into. The dog2 (talk) 20:35, 22 April 2022 (UTC)

I'd say it's useful, yes. There are currently a dozen "Empire" articles in Category:Historical travel, excluding actual colonies and domains like British Raj and German East Africa. I can see a larger "World history" article being useful, but I'm not sure it's needed. RE @Ikan Kekek's point about possible ambiguity about colonialism, there can always be distinguished between modern colonialism, which most of our Empire articles fall under, as well as premodern colonialism, which includes the Phoenicians, Greeks and Romans amongst others.
-- Wauteurz (talk) 22:40, 22 April 2022 (UTC)

I could see such an article being useful as a way of gathering the articles we have about colonial empires. I think that an article trying to cover the history of colonialism back to the Phoenicians would be better as a Wikipedia article. Ground Zero (talk) 01:33, 23 April> 2022 (UTC)

I'll push back against that. Phoenician, Greek and Roman colonies have a lasting interest to travelers. Ikan Kekek (talk) 01:47, 23 April 2022 (UTC)

It would be great to see travel articles that list archaeological sites and museums that would help travellers explore Phoenician, Greek and Roman colonial sites. And those would be good to include in the article that The dog2 suggests. But if it's going to be a history article without references written from one or two writers' own recollections and points of view, I don't see how that serves travellers. Ground Zero (talk) 02:22, 23 April 2022 (UTC)

Comment: We don't have an American colonialism article, not because no-one was interested, but because it was deleted two years after being a Wikiversity article on a travel guide. Unless it can be assured that an article on colonialism won't be like the American colonialism one, I remain pretty unconvinced that we need one. The only positive side for the timebeing is that we have a better breadcrumb structure for colonialism articles, and that's about it. SHB2000 (talk | contribs | meta.wikimedia) 02:53, 23 April 2022 (UTC)

I cannot see that this would be much use & it could certainly provoke plenty of controversy. Marx defined "imperialism" as "the export of capital", & by that definition recent Chinese & Russian expansions are arguably not imperialist. Elsewhere, "Custer died for your sins." Pashley (talk) 01:58, 23 April 2022 (UTC)

The Russian Empire certainly was an imperialist one. They did the same thing to China that the French, British, German and other empires did. I think any fair-minded person will agree that the foreign "concessions" in China were really just colonies in all but name. The dog2 (talk) 02:13, 23 April 2022 (UTC)

So was the U.S. and Canada, but unless we focus on utterly uncontroversial examples with a focus squarely on travellers' interests in the results of colonial history that can be seen or otherwise concretely experienced, this article will be a bad idea. My opinion is yes to the concessions, to different degrees (Macau is obvious, but how obvious is Tianjin?) but I don't think so to Russian Empire. Anyway, aren't empires imperialist by definition? Is imperialism the same as colonialism when we're literally talking about an empire? Then do you want to include China, in its behavior toward Tibet, Xinjiang, Inner Mongolia, etc.? This is not the place for those kinds of discussions. This is a travel guide. Ikan Kekek (talk) 02:25, 23 April 2022 (UTC)

I couldn't agree more with this remark by Ground Zero above: "But if it's going to be a history article without references written from one or two writers' own recollections and points of view, I don't see how that serves travellers." We've been through this kind of thing before. Right, The dog2? Ikan Kekek (talk) 03:13, 23 April 2022 (UTC)

In this case, I was thinking of things from an organizational perspective because it could be convenient to have a page to list all the articles on the various colonial empires. But certainly I acknowledge that it will be difficult to write a politically uncontroversial article about the topic if we want to turn this into a full-fledged article. The dog2 (talk) 03:22, 23 April 2022 (UTC)

Do you mean something like Concerns or Cultural attractions? That could be uncontroversial – as long as it is just about Imperiums. For Colonialism we don't have any articles to list; you'd need to list articles borderline in scope, and then you end up with the problems of American colonialism. If you aim at something like Historical travel, then there is a big risk for several problematic scenarios. Well-written with a well thought-out scope, it could be valuable, but I don't see anybody willing to put in the time and thought needed. –LPfi (talk) 07:25, 23 April 2022 (UTC)

For the latter approach, I think it would need to be worked on in user space, and not be moved out from there until at least worth guide status. –LPfi (talk) 07:31, 23 April 2022 (UTC)

Replacing Go next links in Kolkata and Kolkata districts

Yesterday a user replaced links to Baranagar by links to Sundarbans National Park. I don't see any discussion about Baranagar being an unwanted destination. So, I wonder why this is done. If there is no reason for this, should we revert those edits? --FredTC (talk) 08:28, 23 April 2022 (UTC)

You linked all their contributions. If it was this edit only (on Kolkata/Maidan) you could have linked it directly to avoid having everybody check many of their contributions to find it.

In Kolkata/Maidan there was this sole go next entry, and now there is this other one alone. I don't see any reason not to have several. I also don't know Kolkata, and neither the former nor the current entry explains why it is relevant. I'd readd the former and leave the current, but I think it is odd that the park is linked from at least six of Kolkata's districts. Is it really that relevant to all of them?

–LPfi (talk) 12:11, 23 April 2022 (UTC)

I'm sorry for the inconvenience. I did it this way because the action was repeated so many times. You are right that having Baranagar in so many Go next lists is strange, just as having Sundarbans National Park now in all those Go next lists. I think having Baranagar in only 1 or 2 Go next lists would be OK. And Sundarbans National Park could be in the main Kolkata article only. --FredTC (talk) 14:03, 23 April 2022 (UTC)

Template for approval: Template:Blue Mountains WHS

I thought this template was an approved template, until I went to do a slight adjustment. Works similar to Template:EuropeanCuisines or Template:Asian cuisines and it's been in use for just a bit under six months without any issues. --SHB2000 (talk | contribs | meta.wikimedia) 14:24, 25 April 2022 (UTC)

Seems OK. Ikan Kekek (talk) 18:30, 25 April 2022 (UTC)

This new style of template represents what the English Wikipedia calls "navboxes". They are just lists of links, very popular with editors who like to organize and cluster articles but of doubtful utility to travelers. They are useless to people using a print-out. Having the articles be useful for someone who printed out the article is one of the project's goals. I'm not sure that navboxes are compatible with that goal, as they provide no information except that there's an article online that you can't read because you printed out the page (or didn't download the other articles). That's particularly true for the "cuisine" articles. Perhaps if you are inside the Blue Mountains, you would want a bare list of all the parks there, but why would anyone in a particular country want a list of the kind of food they could be eating in a different country? WhatamIdoing (talk) 15:09, 26 April 2022 (UTC)

@WhatamIdoing Maybe it's worth asking Yvwv who created the cuisine navboxes. I quite like them, as it makes it convenient to read similar articles to that subject or location, but maybe that's just me (because I find these convenient on Wikipedia). We do also have these on some of our US history articles too, like Mexican-American history or Presidents of the United States. SHB2000 (talk | contribs | meta.wikimedia) 09:54, 27 April 2022 (UTC)

For print-outs it should be easy to remove them by a device specification in CSS. For online use, I think they are aesthetically problematic. They could probably be redesigned to look nicer, and integrate better in the places where they are used. For usefulness: isn't this just what categories are for? Once upon the time there was a decision not to use categories in the normal user interface, but I think the situation now is quite different from then, as Wikipedia now is ubiquitous. I don't know how many Wikipedia readers are acquainted with them, though. –LPfi (talk) 10:14, 27 April 2022 (UTC)

While navboxes are mostly used for what to read next, at the end of articles, ours are at the beginning, to provide context. I am not convinced that they are optimal for that purpose, at least in their current shape. –LPfi (talk) 10:16, 27 April 2022 (UTC)

At least at the English Wikipedia, logged-out people view the category pages more often than logged-in people. (I had someone pull the page view numbers a couple of years, because I was curious.) The difference was great enough to suggest that categories were not only/primarily used by editors.

I believe that regular in-text links are the simplest and best way to help people navigate between articles. WhatamIdoing (talk) 12:55, 27 April 2022 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ It could be done. If the size of this specific box is too big, then I suppose it could be condensed and look something like this:

I don't think this new one affects mobile view much (and it doesn't on mine), but I do realise it looks weird when printing. --SHB2000 (talk | contribs | meta.wikimedia) 13:05, 27 April 2022 (UTC)

Why use this, and not add a plain old sentence to each article that says "There are eight national parks in the Greater Blue Mountains Area: Blue Mountains, Gardens of Stone, Kanangra-Boyd, Nattai, Thirlmere Lakes, Wollemi, Yengo, and Jenolan Caves." or (when you are writing the article about, e.g, Gardens of Stone, "There are seven other national parks in the Greater Blue Mountains Area: Blue Mountains, Kanangra-Boyd, Nattai, Thirlmere Lakes, Wollemi, Yengo, and Jenolan Caves." ? WhatamIdoing (talk) 13:18, 27 April 2022 (UTC)

If the Greater Blue Mountains Area is a region that makes sense to visitors, should it replace Blue Mountains? /Yvwv (talk) 12:40, 28 April 2022 (UTC)

I earlier too thought that the Blue Mountains and Greater Blue Mountains Area were the same, but upon further research that I did a few months ago, some of the parks like Nattai or Thirlmere Lakes are in the Southern Highlands (though arguably no-one talks about these parks so information is very limited, and most people who live in NSW have no idea about these parks.) while Yengo NP is in the Hunter. The state government categorises Nattai National Park as "Sydney and surrounds" which is not very helpful and the same with Thirlmere Lakes.

However, strangely, the Greater Blue Mountains does not include the mountain towns in the Blue Mountains, which to me sounds strange, but I think it was deliberately chosen as the name for the world-heritage area to prevent confusion with the Blue Mountains. I think we should just keep the Blue Mountains article for the region, while keeping the Greater Blue Mountains Area article as an extraregion to describe the world-heritage area. SHB2000 (talk | contribs | meta.wikimedia) 13:05, 28 April 2022 (UTC)

Let's talk about the Desktop Improvements

Hello!

Have you noticed that some wikis have a different desktop interface? Are you curious about the next steps? Maybe you have questions or ideas regarding the design or technical matters?

Join an online meeting with the team working on the Desktop Improvements! It will take place on 29 April 2022 at 13:00 UTC and 18:00 UTC on Zoom. Click here to join. Meeting ID: 88045453898. Dial by your location.

Agenda

• Update on the recent developments
• Questions and answers, discussion

Format

The meeting will not be recorded or streamed. Notes will be taken in a Google Docs file. Olga Vasileva (the Product Manager) will be hosting this meeting. The presentation part will be given in English.

We can answer questions asked in English, French, Italian, and Polish. If you would like to ask questions in advance, add them on the talk page or send them to sgrabarczuk@wikimedia.org.

At this meeting, both Friendly space policy and the Code of Conduct for Wikimedia technical spaces apply. Zoom is not subject to the WMF Privacy Policy.

We hope to see you! SGrabarczuk (WMF) (talk) 00:35, 26 April 2022 (UTC)

Is this about Vector 2022? I won't be at the meeting, but I certainly don't like the development. Luckily, Monobook is still there for me. I made a comment at their feedback page, but last I checked (long after I made the comment) nobody had answered. My primary concern is that the layout is miserable unless you have a wide enough browser window (I like narrow ones), and that many important links are hidden to have a "cleaner" look (mostly in a drop-down menu; I even cannot just type in an article name, I have to either maximise the window first, or go to the search page, or just edit the URL in the browser's address field). –LPfi (talk) 10:01, 26 April 2022 (UTC)

Pinging @SGrabarczuk (WMF). LP, it sounds like your screen is narrower than the header, with the result that the search box (which AIUI is meant to be both bigger and centered than in the 2010 version of Vector) is missing/collapsed/unusable. Is that right? WhatamIdoing (talk) 15:11, 26 April 2022 (UTC)

If anyone wants to see the options, click these links:

• https://en.wikivoyage.org/wiki/Wikivoyage:Travellers'_pub?useskin=monobook
• https://en.wikivoyage.org/wiki/Wikivoyage:Travellers'_pub?useskin=vector
• https://en.wikivoyage.org/wiki/Wikivoyage:Travellers'_pub?useskin=vector-2022
• https://en.wikivoyage.org/wiki/Wikivoyage:Travellers'_pub?useskin=minerva (mobile site, which works on desktop devices, too – some readers, but not many editors, prefer this)

These links won't change your preferences. They'll only load the skin for this one page/one time. WhatamIdoing (talk) 15:14, 26 April 2022 (UTC)

Yes. My browser window is narrower than the header. Not my screen though, but I use several windows, e.g. to see a Wikipedia page and a map while I am editing a Wikivoyage guide. I have yet to understand why people keep to the one-application-at-the-time style from before windowing systems were introduced. The alt-tab function helps a bit, but that I used (shift-control-^, if memory serves) already with the VT220 text terminals of the 1980s. Thanks for the skin links. –LPfi (talk) 16:31, 26 April 2022 (UTC)

And it's not only the header. The left-margin menu pushes down the content, so that I have to scroll down every time I load a new page. Very frustrating. –LPfi (talk) 16:34, 26 April 2022 (UTC)

Hey @LPfi, I'm sorry for not answering! Let me answer your questions here.

• As for the left-margin menu, if you collapse it, it should stay collapsed and not push down the content.
• Regarding the question you asked on the project talk page ("does the empty space to the right of the margin menu really give the best possible experience") we are still building the new interface, one feature improvement at a time. The empty space you have referred to is temporary. Now, we're working on page tools which will make a clear distinction between wiki-wide links (like Recent changes) and page-related links (like Related changes) and bring balance to the space on both sides of the content area.
• The narrow screen... I'll talk about that with the team. Generally, we are aiming to make the interface usable on narrow screens or vertical screens (although not mobile). We're trying to keep the minimal threshold of the default experience as narrow as possible.
• In this context, that thing with the left-margin menu and other things... I think it'd fit to the last phase of the project when we'll be working on aesthetic refinements to the entire interface (as opposed to improving individual features).

SGrabarczuk (WMF) (talk) 16:50, 26 April 2022 (UTC)

• Thanks for the tips on collapsing the menu. I didn't notice that possibility. However, when I tested it now, I had to collapse it separately on any new page when following links.
• Nice that you'll get rid of the empty space. When I tried the skin, I did not find any discussion on unsolved problems or on which deficiencies were about yet unimplemented aspects and which were intended features. I might not have looked deep enough. Separation between page tools and other links seems a good goal; I hope the links will still be easily available to users like me, who know the links and can disregard those not needed at the moment (a need you seem to acknowledge).
• Really nice. As of now I got some of the problems with my default window width, while others surfaced with width I use only occasionally. It is important though, to be able to get a narrow window in certain situations, and being able to get rid of the left margin is then an immense help. I hope the suggested new placement of the table of contents won't infer with this.
  (I think it is important to make the distinction between window and screen size explicit in any design discussion, as common or realistic widths of the former aren't restricted to those of the latter, and I have seen web pages that adjust to the latter, more or less ignoring the former, which should be the relevant one.)
• OK, you know better when and how to do those things, they just should be fixed before general roll-out.

–LPfi (talk) 09:02, 27 April 2022 (UTC)

Ah! Now the collapsing worked. I hadn't enabled Javascript for the Mediawiki site, and enabling it did not have immediate effect. Hm. I have enabled Javascript for all Wikimedia projects I visit regularly, but I am a regular contributor. Is the casual visitor with Javascript disabled (for all or some of the domains) a use case you take into consideration? –LPfi (talk) 09:07, 27 April 2022 (UTC)

2022 Board of Trustees Call for Candidates

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

More languages • Please help translate to your language

The Board of Trustees seeks candidates for the 2022 Board of Trustees election. Read more on Meta-wiki.

The 2022 Board of Trustees election is here! Please consider submitting your candidacy to serve on the Board of Trustees.

The Wikimedia Foundation Board of Trustees oversees the Wikimedia Foundation's operations. Community-and-affiliate selected trustees and Board-appointed trustees make up the Board of Trustees. Each trustee serves a three year term. The Wikimedia community has the opportunity to vote for community-and-affiliate selected trustees.

The Wikimedia community will vote to fill two seats on the Board in 2022. This is an opportunity to improve the representation, diversity, and expertise of the Board as a team.

Who are potential candidates? Are you a potential candidate? Find out more on the Apply to be a Candidate page.

Thank you for your support,

Movement Strategy and Governance on behalf of the Elections Committee and the Board of Trustees

Zuz (WMF) (talk) 12:53, 26 April 2022 (UTC)

"Cultural landscapes"

Hi, everyone. There are a series of new itinerary articles that include "the landscapes of cultural interest" or "cultural landscapes" in their titles. We are discussing the title of one of them at Talk:Route of the Landscapes of Cultural Interest in Almería#Title, with the idea that when we come to consensus on that article's title, we can change all the others analogously. Will you please help us come up with an idiomatic English phrasing that is not lengthy and can achieve a consensus? Ikan Kekek (talk) 17:51, 26 April 2022 (UTC)

Next steps: Universal Code of Conduct (UCoC) and UCoC Enforcement Guidelines

The Community Affairs Committee of the Wikimedia Foundation Board of Trustees would like to thank everyone who participated in the recently concluded community vote on the Enforcement Guidelines for the Universal Code of Conduct (UCoC).

While the Enforcement Guidelines did reach a threshold of support necessary for the Board to review, we encouraged voters, regardless of which way they were voting, to provide feedback on the elements of the enforcement guidelines that they felt needed to be changed or fixed, as well as why, in case it seemed advisable to launch a further round of edits that would address community concerns.

Foundation staff who have been reviewing comments have advised us of some of the emerging themes, and as a result we have decided as Community Affairs Committee to ask the Foundation to reconvene the drafting committee and to undertake another community engagement to refine the enforcement guidelines based on the community feedback received from the recently concluded vote.

Further, we are aware of the concerns with the note 3.1 in the Universal Code of Conduct Policy. We are directing the Foundation to facilitate a review of this language to ensure that the Policy meets its intended purposes of supporting a safe and inclusive community, without waiting for the planned review of the entire Policy at the end of year.

Please visit here to read the full announcement.

Best, Zuz (WMF) (talk) 11:53, 28 April 2022 (UTC)

Make working with templates easier: One more improvement coming soon.

Hello, one more change from WMDE’s focus area “Templates” is coming to your wiki soon: In syntax highlighting (CodeMirror extension), you’ll be able to activate a colorblind-friendly color scheme with a user setting. (project page)

Deployment is planned for May 10. This is the last set of improvements from WMDE’s focus area “Templates”. We would love to hear your feedback.

Thanks for being one of the first wikis to get the improvements from our project, and for giving valuable feedback! – Johanna Strodt (WMDE) (talk) 09:55, 29 April 2022 (UTC)

FYI: Relevant social network/app

https://travelfacets.com/ —Justin (koavf)❤T☮C☺M☯ 20:33, 1 May 2022 (UTC)

Move Sulphur Springs (Texas) to Sulphur Springs

Would an admin please move Sulphur Springs (Texas) to Sulphur Springs? The move destination is a redirect, so I can't move it. Hanif Al Husaini (talk) 21:26, 1 May 2022 (UTC)

Done. Does anyone know, if you are a patroller, can you move an article while deleting another? Ikan Kekek (talk) 21:32, 1 May 2022 (UTC)

I in fact, did try to move it and could not as an autopatroller, if that helps. —Justin (koavf)❤T☮C☺M☯ 21:36, 1 May 2022 (UTC)

Right, but that wasn't the question. Hanif is also an autopatroller. Ikan Kekek (talk) 21:47, 1 May 2022 (UTC)

It was because it had a page history of 20 revisions in it until it was redirected. If I'm not mistaken, autoconfirmed users can only delete the page if it only had one revision in it, and that has to be a redirect. SHB2000 (talk | contribs | meta.wikimedia) 07:04, 2 May 2022 (UTC)

Odd that an article with 20 edits has just one listing (without details), coords, and routebox. Still, when you delete the version to be replaced, always check whether there might be something worthwhile in it. Sometimes the new version was created by copy-and-paste from it, or parts of the old version merged later at some point. Here the absence of routebox in the new article broke the routebox chain (I assume it was broken since the original redirect). If the article histories overlap, they shouldn't be merged (so there'll be some pondering about what to do), but here the old article hadn't been touched since new article was created. The problems about handling history aren't something we trust patrollers to get right, that's why only administrators have the delete powers. –LPfi (talk) 10:42, 2 May 2022 (UTC)

I'm sorry if I did something wrong. Ikan Kekek (talk) 02:10, 3 May 2022 (UTC)

Easy to fix as long as it is just a deletion, so no problem (mistaken history merges, on the other hand, are often messy). However, when an admin is needed to move a page, one should always check the history. –LPfi (talk) 08:45, 3 May 2022 (UTC)

Bikesharing, food apps, and other multinational services

I added Donkey Republic to Urban cycling. Now there is discussion about the To Good To Go budget food app. Earlier there has been discussion on the Finnish taxi call centres and electric kick scooters. With apps and web services getting ubiquitous and multinational, like the associated physical services, we face a new situation. According to policy, a business should be mentioned in just one place, but these chains are useful and often the only option, and there is no obvious place where travellers would find them. The net result might be that travellers just use what Google Maps and similar link to, making independent chains invisible.

I think it is clear that we have to mention these "chains" in a way that travellers to a city where they are a main option can find them. I don't know how to do that sensibly, without spamming a lot of pages, or getting long lists on the global pages, such as Urban cycling or Smartphone apps for travellers. Donkey Republic has a presence in the USA as well as in Europe, probably in a few dozen cities, so it doesn't fit the regional break-down. I assume many chains have the same problem.

So: what should be do?

–LPfi (talk) 11:06, 2 May 2022 (UTC)

Long lists on global pages, if they are necessary, may be the least bad solution. Ikan Kekek (talk) 02:09, 3 May 2022 (UTC)

Editing news 2022 #1

Read this in another language • Subscription list for this multilingual newsletter

New editors were more successful with this new tool.

The New topic tool helps editors create new ==Sections== on discussion pages. New editors are more successful with this new tool. You can read the report. Soon, the Editing team will offer this to all editors at the 20 Wikipedias that participated in the test. You will be able to turn it off at Special:Preferences#mw-prefsection-editing-discussion.

Whatamidoing (WMF) 18:55, 2 May 2022 (UTC)

New competition on English Wikipedia and related SiteNotice request

A popular article writing competition CEE Spring (about Central and Eastern Europe; now with special subcategory about Esperanto) is happening on the English Wikipedia until the 31st May 2022. I warmly invite you to participate, write some article and win a valuable prize! If you have question, I will happily answer it on the competition page talk.

Also, for more wide outreach, I have just asked for a CentralNotice, which should appear also in this project. If you have a comment on the request, you are welcome to write it on the request page. --KuboF Hromoslav (talk) 18:30, 3 May 2022 (UTC)