An editors note: in many articles about Finland and Sweden, "few" is used instead of the intended "a few", probably either because Finnish editors have problems with articles (the Finnish language doesn't even have definite and indefinite forms), or because it is confused with other words, especially Swedish några ("a few"). The mistake seems to be common enough that I think copy editors should be watching for it in these articles. –LPfi (talk) 08:13, 21 September 2021 (UTC)Reply

Thanks for the notice. I'll try and keep a look for this. SHB2000 (talk | contribs | meta.wikimedia) 08:20, 21 September 2021 (UTC)Reply

That's also an ongoing issue in articles about the Indian Subcontinent. Evidently, in Indian (Pakistani, etc.) English, "few" does mean what "a few" means in other dialects (the difference being that "few" means "almost none" while "a few" means "several", so the connotation of "a few" is positive, emphasizing more than two, and the connotation of "few" is negative, emphasizing close to zero). Ikan Kekek (talk) 20:51, 30 September 2021 (UTC)Reply

Isn't that how that word works in every variety of English? Both are found in Shakespeare: "We few, we happy few, we band of brothers" and "You few that loved me/And dare be bold to weep for Buckingham" for the one meaning, and "Love all, trust a few, do wrong to none" and "Here are a few of the unpleasant'st words that ever blotted paper!" for the other. WhatamIdoing (talk) 14:26, 1 October 2021 (UTC)Reply

Shakespeare isn't in Indian English, and I've seen enough edits in articles about India to know that they use "few" the way other English dialects use "a few". Ikan Kekek (talk) 00:11, 2 October 2021 (UTC)Reply

/ Apologies for writing in English. It would be great if you could help translate this message. /

Hello! Here is more news from the focus area “Make working with templates easier” by Wikimedia Germany’s Technical Wishes project:

Your wiki will soon receive an overall improved interface for editing templates in VisualEditor and in the new wikitext mode (beta feature). This includes several improvements:

• general redesign (more spacing, bigger window for better usability),
• a better overview of parameters that are available for a template,
• an easier way to add parameters via checkboxes and search filters,
• better visibility of important information,
• added links to documentation and help pages.

More in-depth information can be found on the project page on Meta. The planned deployment date for these changes is October 6.

Please note: The official VisualEditor help page on mediawiki.org will only be changed later this year, when all wikis have received the feature. If you have a local help page about the feature, you can update it based on information on this page, which we will fill with content in late September.

We would be very happy to hear what you think of these changes. Please let us know on this talk page. -- Johanna Strodt (WMDE) (talk) 14:09, 22 September 2021 (UTC)Reply

Hello again! Unfortunately, this deployment will be postponed a bit:

• Our team is currently still working on a few optimizations for mobile and for screen readers, so we’re planning to deploy the feature to your wiki in late October/beginning of November.
• That also means that the texts on this subpage are not finished yet. We’ll give you an update here on your village pump once the texts are done. Then you can update your help page accordingly.
• For those who are curious what to expect, here are two videos: One shows the current interface on English Wikipedia, the other one shows the improved interface which you’ll get soon (currently on betawiki):

• Current view on English Wikipedia
• Coming soon: Improved version

Sorry for the inconvenience! – Johanna for the Technical Wishes team, Johanna Strodt (WMDE) (talk) 10:45, 6 October 2021 (UTC)Reply

Does anyone know why it randomly appeared around 09:00 today (AEST: UTC+10)? I checked Special:Preferences#mw-prefsection-betafeatures and I haven't enabled the tool. Is there a way to opt out of the reply tool or am I stuck with it forever? SHB2000 (talk | contribs | meta.wikimedia) 04:49, 1 October 2021 (UTC)Reply

You can disable it in Special:Preferences#mw-prefsection-editing-discussion. This was announced in m:Tech/News for the last two weeks. I see that the latest copy is still on your talk page at User talk:SHB2000#Tech News: 2021-39. It's the last item. WhatamIdoing (talk) 14:30, 1 October 2021 (UTC)Reply

Oh. Haven't read my tech news this week, but thanks for pointing it out. SHB2000 (talk | contribs | meta.wikimedia) 14:40, 1 October 2021 (UTC)Reply

I'm not particularly keen on this, but the crucial factor to watch will be new user participation via comments, and whether it improves. If so it will justify keeping this tool. --Comment by Selfie City (talk | contributions) 21:33, 1 October 2021 (UTC)Reply

Sorry for being late to this conversation but as a fairly new user I much prefer using reply over the visual editor. Tai123.123 (talk) 01:08, 2 November 2021 (UTC)Reply

We are currently adding listings directly to articles. However, my idea is to list attractions in their own pages in a new namespace, and transclude them instead. There are several advantages to doing this:

1. Permanently closed attractions are usually removed from articles. Because it's a lot harder to find something within page revisions, this makes it hard for anyone who wants to look up a former attraction for reference. If each listing had its own page, then the listing templates could easily be adjusted to prevent transclusion if the attraction is marked as closed.
2. Some listings may appear in more than one place. For example, Kitt Peak National Observatory is listed on both Astronomy and South Central Arizona. Putting a listing into its own page would allow us to update the listing for all places at once.
3. It would be easier to find information for lesser-known attractions via Wikidata.
4. If an article has many listings, then editors don't have to scroll through a bunch of text if manually editing the code. This would also reduce edit conflicts for heavily-edited articles.
5. It's generally considered a best practice to modularize data.

What are everyone's thoughts? --Ixfd64 (talk) 07:18, 1 October 2021 (UTC)Reply

I would generally oppose this change. Transcluding them can be done, but only via a different namespace as far as I know although that is part of your proposal. We do transclude certain things like Template:Canadian national park passes into all Canadian parks, so it's easier to keep things updated about Canadian Parks passes, but it doesn't really work that way for listings.

This also means that it can sometimes make things harder for those who don't know how transclusions work, and even for those who basically are familiar with transclusions, like me where my userpage is full of transclusions and templates, it's also a lot more time consuming. I'll take an example of what I once did recently in Ķemeri National Park recently. Went to their park and tourism website, and added them as I went. Didn't require too much effort nor time and it was pretty convenient.

I'll also share my experience on a wiki where this is done. On Wikispecies, this is done quite frequently, but given how time consuming it is through transcluding things, it has basically driven me away. On the other hand, I did see a duplicate word used on many pages, and instead of going on every single page where that text is used, all I needed to fix was that one template.

And finally then we have the touts who all they want is to promote their business. I can only imagine how easy it is for them to promote their business, and non-admins trying to have to delete that transclusion (although it's mostly Ikan Kekek who handles touts, and they're a 'crat here) and given that we don't have an eliminator group here.

Transclusions are a good thing, but not for listings. OTOH, templates are good, but those are also basically transclusions. It is a good concept, but the cons outweigh the pros to this. SHB2000 (talk | contribs | meta.wikimedia) 07:33, 1 October 2021 (UTC)Reply

Building on what SHB says about the experience of other wikis, the English Wikipedia tried this for some citations (which get re-used there far more often than we re-use any listings there), and it was not a good thing in the end. It was confusing even for experienced editors. WhatamIdoing (talk) 14:33, 1 October 2021 (UTC)Reply

I must admit I wasn't aware this was tried on the English Wikipedia. Guess we learn something new every day! --Ixfd64 (talk) 18:11, 1 October 2021 (UTC)Reply

It was mostly done for medical journal articles, so if you don't play in that area, you might not have run across them. I think they were officially deprecated more than five years ago. WhatamIdoing (talk) 20:56, 1 October 2021 (UTC)Reply

Oppose. I think it would make adding a listing more complicated to an average contributor. --FredTC (talk) 08:35, 1 October 2021 (UTC)Reply

• Comment I am open about this proposal. Diffs are weird when a listing has been added, removed or moved, and being able to transclude a listing both in the destination article and in an itinerary would be nice. However, if editing a number of listings in an article (in wikitext mode) involves copying and pasting the listing name into the search box, right clicking the match, and clicking the edit tab – for each of the listings – that won't fly. Another problem is how to avoid cluttering the new namespace (we'd have many "Joe's bar" and "Sandy beach") and still make creating, finding and recognising the listings easy. Have such problems been considered and feasible solutions outlined? –LPfi (talk) 09:43, 1 October 2021 (UTC)Reply

I wasn't thinking about places with the same name and do agree it's an issue. For example, Burger King has almost 40,000 locations worldwide. Even a disambiguation page could become impractical in this case! --Ixfd64 (talk) 17:34, 1 October 2021 (UTC)Reply

• Strongly oppose. In general, this would overhaul the entire system that Wikivoyage is built upon, and the way I look at it, the disadvantages outweigh the advantages and sheer effort of materialising this proposal. Just going point by point on your listed advantages:
  1. Sounds great, but in practise this will leave you with a transclusion in an article that will print an error once a listing is removed, so this makes a single edit per page where the listing is mentioned into a N+1 amount of edits (N= amount of articles with this listing). You don't just remove the listing, you also remove every transclusion in an article. Furthermore, you cannot reasonably generalise descriptions for listings, seen as how as a result of the policy of listing listings in the most bottom-level article, each use case will be specific.
  2. As a direct continuation of the previous argument: If a restaurant appears in multiple articles, it should be different locations of the same branch, thus having different phone numbers, lat/longs and addresses. If an attraction appears in multiple articles, it can be more specific depending on the article. A heritage railway, for example, could see specific details about rolling stock added to a "Rail travel in X" article, whereas the article for "X" would contain more general information. Using your own example, Astronomy is a more specialised article and therefore can and should go into further depth than the listing in South Central Arizona. I know little about astronomy, but I would expect to hear why Kitt Peak is such a notable observatory and what makes it stand out in Astronomy, while a brief overview is plenty for South Central Arizona, as observatories aren't for everyone and some might want to just gloss over it.
  3. Please explain how you think this would be easier. If you want to avoid having seventy-nine listings of "Joe's Bar" as LPfi suggests, you'd index these by a serial number, so a drink listing could be DR(ink)563154 instead of simply "Joe's Bar". Index numbers aren't insightful to mere mortal people though. How many Wikidata item IDs can you name from the top of your head? You would have to look them up each and every time. Sure, you could offload a lot of the major attractions to Wikidata, but we already do this. Wikidata integration in listings has been up and running for a good few years.
  4. Are edit conflicts really a frequent issue to the point that this argument is valid? Generally, data stays valid for a good while. If a listing really requires updating, it won't be likely that a dozen editors immediately edit the same article. Furthermore, editing via the Listing Editor should avoid edit conflicts from forming, and when they do, it's because someone edited the same listing as you were editing it, which, again, I don't think is a frequent occurrence. The only edit conflicts I have ever encountered over ~5100 edits were in the Pub, never in an article.
  5. Modularising is only worth it if the data lends itself to modularisation. Sure, the information we list can be modularised, but as mentioned, both the names for listings and their description in each use case/article varies and is best left to be filled in by the editor adding said listing. Let's also not forget that sometimes, listings come as simple markers. Versatility in what elements would be transcluded from a template-ified listing would break great articles such as Alkmaar that don't hold true to the generic bulleted list concept we've all stuck to over time. I would even argue that articles such as Alkmaar are nicer to read because of them not following bulleted lists, and this edit would be likely to break that, destroying great articles in its wake.

Sure, modularising listings might seem like a rational idea, but it goes a few steps too far from being a practical change if you'd ask me. Not even to mention that you would be making listings less tangible if it's buried deep down in a different namespace than the one the reader generally interacts with. So no, this would add too many hurdles, have too many specific use-cases to adapt to to be a logical change, and would furthermore overhaul the website as whole with no real benefit to anyone in particular while also removing or seriously overhauling the process that many editors here are comfortable and well-versed in. If anything, such an overhaul would break the flow of more editors than it would improve. It's definitely a strong no from me, but feel free to write a practical concept of this idea that would be easy to use on a site-wide scale. I doubt it will change my mind, but there's a small chance that this might pass if the concept is more tangible than a mere proposal.
-- Wauteurz (talk) 10:44, 1 October 2021 (UTC)Reply

Thanks for the well thought out response. For the first case, there wouldn't necessarily be any errors. It should be possible to configure the listing templates to simply not display anything if the attraction is marked as closed. Something like adding a closed parameter and putting the listing inside noinclude tags should be doable.

I do agree that that having multiple places that share the same name would be an issue. For example, Burger King has almost 40,000 locations worldwide. Even a disambiguation page could become impractical in this case!

Perhaps we can look at similar ideas in the event that Wikivoyage becomes as popular as Wikipedia is now. --Ixfd64 (talk) 18:10, 1 October 2021 (UTC)Reply

I think this has been considered before on another travel website. The proposed form here might be more "community-palatable" than a prior suggestion, and I'm inclined to see its merits, but it would require massive changes to the structure of WV, and therefore I don't think it would be appropriate at the present time. At Special:RecentChanges we're fortunate to get an edit per minute, and with only a few dozen regular contributors (at most), this would put a massive burden on the community. As it is, we are slowly but steadily improving our article coverage, and many countries have achieved usable status across all or almost all destinations. Continuing this process appears to be a best path forward while our contributor base is limited. --Comment by Selfie City (talk | contributions) 21:26, 1 October 2021 (UTC)Reply

Definitely for fast food chains. There's no questioning McDonalds (but we don't list maccas per wv:boring), but others like KFC, Hungry Jacks (as you mentioned above) or even donut stores like Dunkin's Donuts can have up to tens of thousands of listings. SHB2000 (talk | contribs | meta.wikimedia) 01:16, 2 October 2021 (UTC)Reply

oppose, mostly. Afaik there was an initiative to move some attributes into wikidata (e.g. phone numbers of hotels) - data that could be shared between multiple languages and wiki pages. I think :de:wv tried it. In any case that's about how far I'd go. I see your point and in a non-wiki database, it'd be an obvious thing to do. But unless you significantly improve the page/listing editor to make this mostly transparent to the users, it is hardly acceptable. -- andree 19:23, 4 October 2021 (UTC)Reply

Centralized information is always a great idea, that's why Wikidata has been created and why we use (only partially at the moment) the wikidata "link" in every listing. But I oppose to the idea of transclude the listings because on top on all the cons already mentioned above, there's another one: when we edit and save a listing in an article, we'll land in the page of the transcluded listing instead of the main article. I can't imagine anything more annoying than this, especially when you need to update a dozen of listings. Ah let me add another technical point: listing editor would stop working as it is, and shall be at least partially modified. --Andyrom75 (talk) 10:51, 8 October 2021 (UTC)Reply

Finally got around to reading this week's tech news, and:

iOS 15 has a new function called Private Relay (Apple website). This can hide the user's IP when they use Safari browser. This is like using a VPN in that we see another IP address instead. It is opt-in and only for those who pay extra for iCloud. It will come to Safari users on OSX later. There is a technical discussion about what this means for the Wikimedia wikis.

There's a full discussion at phab:T289795, but in short, this tool will essentially, with this tool, instead of using your own IP address, where instead of the actual IP address used, it will instead be an IP used on Apple's servers.

Given this, I'm presuming we're going to have to treat Apple IPs similar to how we treat VPNs and Open Proxies, and block them, and give users who have a genuine need to use this IP hiding tool IPBE just like VPNs.

There is already a discussion on the English Wikipedia and the Phricator about this. No harm in planning on what we should do about this, but it would be good to start to plan on our open proxies policy. SHB2000 (talk | contribs | meta.wikimedia) 13:11, 2 October 2021 (UTC)Reply

Is Apple providing privacy or is this a Trojan horse allowing Apple to spy on premium customers? Anyway, if we block the IP addresses concerned, we will be blocking those who use iCloud+ and Safari, the default browser on Apple smartphones. The WMF techs assume about 30% of Safari users will be affected, if trying to edit without logging in. Percentage of Safari edits among the anonymous edits vary from 0 to 50% between languages (on Wikipedia).

People won't know the consequences of enabling the service, so many will do it out of pure naïvety, and won't be able to disable it for editing Wikivoyage. At the moment, there is no specific message, so they won't know they are blocked because of iCloud+. The block affects also logged-in editors, as proxies are usually blocked with such settings.

–̃LPfi (talk)

Judging from LPfi's comment, it sounds like we shouldn't do those blocks. This explains why some of the recent IP range blocks have affected me only on Windows devices. --Comment by Selfie City (talk | contributions) 15:51, 2 October 2021 (UTC)Reply

I think proxy blocking is done centrally. The WMF technical folks are thinking hard about how this could be handled. –LPfi (talk) 16:03, 2 October 2021 (UTC)Reply

Oh, okay. Good to know they're aware of things such as this. --Comment by Selfie City (talk | contributions) 16:13, 2 October 2021 (UTC)Reply

@Jon Kolbert put global blocks on (nearly?) all of these IP addresses at the end of August. People hit by these blocks are not able to create an account, which will cost us some new registered editors in addition to good-faith edits. The linked FAQ page at m:WikiProject on open proxies/Help:blocked provides no advice to existing registered editors affected by this. In this particular situation, your options are:

• Turn off Apple's privacy features (seems like a bad idea, and against the movement's values?)
• Switch to another web browser (I hear that others are planning to do similar things in the next year or so, though, so this isn't a long-term solution)
• Request the "IPBE" userright at m:Global permissions#Requests for global IP block exemption

If you use Safari regularly (especially if you know that you/your network is a paying iCloud+ subscriber), it might not be a bad idea to request IPBE now. This is currently affecting some mobile editors, and it will start affecting some desktop users in a couple of weeks.

I'm not entirely sure that these should have been blocked. They're not really open proxies ("a proxy that anyone can use freely" – when you have to pay for the service, it's a closed proxy, not an open one). I suspect that this was blocked because it's like a large VPN. WhatamIdoing (talk) 16:23, 2 October 2021 (UTC)Reply

There's a couple of other stewards who've been putting g blocks on these IP addresses as well, but yeah, mostly Jon Kolbert. SHB2000 (talk | contribs | meta.wikimedia) 23:20, 2 October 2021 (UTC)Reply

@LPFi, if it's a regular VPN and not some deeper hack inside Safari, they can't spy too much - since most of the traffic nowadays is encrypted by https. They will just see you are going to wv, YouTube or whatever, but not any details.... -- andree 05:47, 3 October 2021 (UTC)Reply

It is not a regular VPN, but anyway, seeing where you go tells plenty, if you go to places like greenpeace.org, whiteforce.example, havingakid.example or findajob.example. –LPfi (talk) 08:03, 3 October 2021 (UTC)Reply

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 October 12th, 16:00 UTC on Zoom. It will last an hour. Click here to join.

Agenda

• Update on the recent developments
• Sticky header - presentation of the demo version
• Questions and answers, discussion

Format

The meeting will not be recorded or streamed. Notes will be taken in a Google Docs file. The presentation part (first two points in the agenda) will be given in English.

We can answer questions asked in English, French, Polish, and Spanish. If you would like to ask questions in advance, add them on the talk page or send them to [email protected].

Olga Vasileva (the team manager) will be hosting this meeting.

Invitation link

• Join online
• Meeting ID: 829 3670 1376
• Dial by your location

We hope to see you! SGrabarczuk (WMF) 15:09, 4 October 2021 (UTC)Reply

Hello everyone,

This is just a reminder that the Universal Code of Conduct Draft Enforcement Guidelines are open for review and comment. The Drafting Committee will start working on revisions and improvement in less than two weeks (October 17), so it is important that you give them your ideas and opinions soon!

There is now a short, simple version of the Draft Guidelines here to make your review easier. If possible, also help translate the short version into more languages!

We will also hold one last conversation hour on October 15, 2021 03:00 and 14:00 UTC.

On behalf of the Drafting Committee, much thanks to everyone who has given ideas so far. We hope to hear from more of you - the Guidelines will be much stronger if more opinions are included.

Best, Zuz (WMF) (talk) 10:49, 6 October 2021 (UTC)Reply

I've received a long email of the blocked user in the subject with a request of unblock. Since I have no idea of who is the user and why he was blocked (I have no time to look for the history), I was wondering if any or maybe all the en:voy admin have received such email. However, I suggest to anyone that can be interested on this case, to discuss here before taking any autonomous action.

(out of chrono) Please Tony1 stop sending me emails. I've started this topic because from one side it's fair and I'm fine with the fact that you want to rediscuss your block in one single wiki (not a global block) after several years, but from the other side I would avoid that an admin would remove a block without a public discussion. My personal suggestion to you is to wait the en:voy community will discuss about it and, after a reasonable time, if you want to add something, feel free to write it on your talk page of your main wiki (i.e. en:w) pinging anyone involved on this discussion and anyone you think may be interested (pings works from/to any wiki). Thanks for your understanding. --Andyrom75 (talk) 08:29, 8 October 2021 (UTC)Reply

@Andyrom75: It seems @Andre Carrotflower: blocked them per NOTHERE, but personally, I would Oppose an unblock. They're also blocked on frwiki as well for being disruptive as well. SHB2000 (talk | contribs | meta.wikimedia) 09:52, 8 October 2021 (UTC)Reply

This guy sent me an email too. I'm not going to fully out the email, but one of the reasons in his appeal was "The block prevented me from voting in the recent election of WMF board members.". Uhm, nope. I still would not trust someone who broke community trust, which gave him consequences globally. SHB2000 (talk | contribs | meta.wikimedia) 10:10, 8 October 2021 (UTC)Reply

This user did ask me to paste their reasons here, so here it is:

• The block prevents me from accessing the Wikipedia Library of non-free academic journals to provide sources for articles at en.WP I edit.
• The block prevented me from voting in the recent election of WMF board members.
• Crucially, I do not expect to edit Wikivoyage again.

Still no for me. And I'm confused on the first reason. SHB2000 (talk | contribs | meta.wikimedia) 10:19, 8 October 2021 (UTC)Reply

And I’m confused on the third reason. If he does not want to edit Wikivoyage, why ask us for an unlock request? --Comment by Selfie City (talk | contributions) 10:35, 8 October 2021 (UTC)Reply

I presume it's because of reason 2: "The block prevented me from voting in the recent election of WMF board members." Personally, if he abused the trust of the community, that's too bad he can't vote in the WMF board members election. SHB2000 (talk | contribs | meta.wikimedia) 10:39, 8 October 2021 (UTC)Reply

In my opinion he should be unblocked. It was not a community ban. The 2019 ban did not go through Wikivoyage:User ban nominations. The only ban nom was one from 8 years ago that resulted in a 3 day block. In 2019 Andre accidently pinged Tony (which he regretted), got into a brief argument with him, then unilaterally banned him. He should be unblocked and in the unlikely event that he starts problematic editing it can go through User ban nominations. Nurg (talk) 11:22, 8 October 2021 (UTC)Reply

It'd be an ideal solution, but I'm also concerned about his behaviour on frwiki. This person seems to have cross wiki issues as well. SHB2000 (talk | contribs | meta.wikimedia) 11:26, 8 October 2021 (UTC)Reply

I took a quick look at discussions I found on his contribution page and I certainly got the impression he was a problem user. I did not look carefully enough to see whether this was his fault or whether he had been badly treated, and I did not look through his contributions. Anyway, on one hand problem users are not given the privilege of being able to vote on the WMF board or of having literature access financed through the WMF, and being banned (on several projects?) is seen as a measure on being a problem user. Having seen those discussions I am not too eager to give him these privileges.

On the other hand, if he was banned against our policy, I don't see how we can keep him banned, and I don't see it worthwhile to now have several users evaluate his edits, which might still not be a reason to ban him, as none of them is recent. If denying him privileges depend on us, then the system is broken, and fixing it is not our responsibility.

–LPfi (talk) 13:23, 8 October 2021 (UTC)Reply

SHB2000 - If by pinging me you're soliciting my opinion, I'd echo other commenters in saying that voting for WMF board members is a privilege, not a right, and it's a privilege that is rightly denied to those who edit disruptively on any wiki. It is also correct to say that the problems with Tony1 aren't confined to his behavior at Wikivoyage; I don't have time to link diffs right now as I'm away from my office and editing on mobile, but a search through pages that link to his English Wikipedia userpage ought to be enlightening for anyone who's curious. And I'll also add with respect to Nurg's remarks that it's especially disappointing and shameful to see my actions as an admin, which were not against Wikivoyage policy and which had the broad support of the community at the time, being impugned and dismissed years after the fact by a user who was only marginally active in Wikivoyage affairs at the time the drama went down. -- Andre Carrotflower (talk) 16:02, 8 October 2021 (UTC)Reply

I apologise to Andre – I didn't word my comments as carefully as I would have liked. Andre banned Tony1 with this comment, "Per exceptions list at Wikivoyage:How to handle unwanted edits#User ban; user obviously is not here to help build a travel guide". Neither I nor anyone else (AFAIK) who was aware of the ban commented on it. In that sense, there was silent consensus. Accordingly one could say it was a community ban by silent consensus. No-one who was aware of the action said that explicit consensus needed to be gained through Wikivoyage:User ban nominations. I have not said, then or now, that Andre did anything wrong. And, until this present request from Tony, I had not said that the ban should be lifted. I apologise to Andre for any implication that his actions were wrong, as I had not intended that. Nurg (talk) 22:20, 14 October 2021 (UTC)Reply

Not to mention the fact that, if I'm reading this correctly, being blocked on any wiki is grounds for being denied the opportunity to vote for WMF board members? If that's the case, then unblocking him here wouldn't make a difference anyway; fr.wp would have to unblock him as well, and we have no control over that. -- Andre Carrotflower (talk) 17:43, 8 October 2021 (UTC)Reply

If there was consensus at the time, or him not contributing positively was evident, then I don't think he needs to be unblocked (above I was too rule fixated, which is not the wiki way). The policy on not banning users is for contributors who might have a bad temper and get in conflict with individual admins; we do not need to protect users who don't intend to contribute. –LPfi (talk) 19:18, 8 October 2021 (UTC)Reply

@Andre Carrotflower: Yeah just wanted to get your opinion as you were the one who blocked this user. But regardless, even if all this didn't happen, I would still oppose an unblock for spamming my email (+Andyrom's as well).

But as both of you said, if he doesn't want to contribute, then we don't need to defend him into having the privilege of voting at the WMF board elections. OTOH, if we wasn't banned on frwiki for his behaviour, it's a different case, but I'm still not convinced that unblocking him is a good idea here. SHB2000 (talk | contribs | meta.wikimedia) 23:11, 8 October 2021 (UTC)Reply

I'd say unblock, for approximately the reasons Nurg gives above. Pashley (talk) 22:31, 8 October 2021 (UTC)Reply

I don't support unblocking this user. Tony was nominated by Andre for a user ban back in 2013, and the latter commented at Wikivoyage:User ban nominations/Archive#User:Tony1, "This user has been a thorn in our side almost from Day 1. His interactions with the community have been almost uniformly combative, unconstructive, and insulting. He has no evident interest in advancing our project; on the contrary, he seems to openly resent the existence of Wikivoyage as a WMF project, and has even gone so far as to gleefully predict this site's demise on a frequent basis." After discussion, a three-day block was applied, but Tony was again nominated for a ban only a month later, which was met with a mixed response but ultimately, failed to gain consensus to block.

Since this incident WV's admins have tried to be patient with some new users, and found that despite apologies and requests for a clean start following troubled editing patterns, the same M.O. of each problem user has re-appeared and resulted in another block. WP has experienced this as well, but as a smaller site, we don't have Wikipedia's resources to support the rehabilitation and unblocking of banned users only to re-block them. WP's administrative body is dedicated to this, and I'd guess some of their administrators enjoy the administrative side of their project, but I think most of our administrators are more interested in writing travel content than administering bans or fighting vandalism, and do these activities only out of duty to the project.

In the last couple years since we took a stricter stance on contributor's M.O.'s, WV has become a more peaceful and enjoyable place to contribute, but re-instating this user wouldn't help us achieve this. It's clear that Tony was opposed to our goals when he contributed, and I don't see why unblocking him would benefit this wiki, even if he doesn't intend to edit here. --Comment by Selfie City (talk | contributions) 15:03, 9 October 2021 (UTC)Reply

• Oppose. This issue is new to me — 2013 is before my time here. I've read through the various discussions, and I have no concern about continuing this block. He was disruptive, combative, and generally a problem for those who were trying to build a travel guide. If there wasn't consensus then, I think there would be now because of our less patient mood, as noted by SelfieCity. This change in mood has resulted from spending too much time giving the kid-glove treatment to people like Tony1 who are not here to build a travel guide, as Andre Carrotflower pointed out. Someone as angry and disruptive as Tony1 has proven himself to be isn't going to make a constructive contribution to WMF elections. Ground Zero (talk) 16:24, 9 October 2021 (UTC)Reply

  I can't think of a good reason to revisit this all these years later. If he wants to appeal to the Wikimedia Foundation for permission to vote in board elections or whatever, that's up to him, not us. Ikan Kekek (talk) 17:08, 9 October 2021 (UTC)Reply

• I support unblocking him. I don't see any need to maintain the block. For those that don't know, The Wikipedia Library offers free access to a variety of reliable sources, mainly useful for verifying content in Wikipedia articles. Being blocked anywhere means you can't use it. Tony's made a couple hundred thousand edits at the English Wikipedia, and he has been highly active in the Featured Article process. I don't think that we need to prevent that. Also, it seems a bit strange to jump from a three-day block in 2013 to an indef block six years later. I'm also not impressed with the excuse for the 2019 block. Basically, Andre pinged Tony1, in a comment in which Andre insults an opinion piece that Tony1 wrote on a different site as "a horribly one-sided hack job". Tony1 hadn't edited here for more than five years. Then Andre blocks Tony1 because he's apparently shocked, shocked to discover that authors feel angry when you insult their writing. See the discussion and Andre's edit summary here, in which Andre takes responsibility for triggering the angry exchange while removing Tony's replies (but not Andre's original insulting remarks). I wouldn't necessarily say that blame is equally divided here, but I don't think that a multi-year block is either a necessary or a proportional response to this situation. "Sorry, neither of us should be insulting anyone in public" would IMO have been a more proportional response. WhatamIdoing (talk) 22:54, 9 October 2021 (UTC)Reply

  I still think that him being able to access the Wikipedia Library was a privilege that he lost. Even if we unblock him, he's blocked on the French Wikipedia as well, and frwiki is known to be very harsh with blocks (they blocked a user (will not get into names) who was blocked only because they made a grammatical error). Even if, I was thinking to remove his email access for spamming our inboxes.

  Meanwhile, we have the same issue with the English Wikipedia. Unfortunately, some admins there think that the English Wikipedia is the only WMF project (most of them who think that have almost zero edits outside enwiki and Commons + 1 edit on their meta userpage), and so if a user gets blocked on the English Wikipedia and its preventing them from doing something on another wiki, then they would remain blocked. If the English Wikipedia as a community wants to lose editors from other projects, then too bad. It's too bad that the community that Tony1 is a part has their actions backfire.

  And I think he should still be blocked per NOTHERE and agree with everyone who opposed an unblock. SHB2000 (talk | contribs | meta.wikimedia) 23:28, 9 October 2021 (UTC)Reply

  I’m confused. I just went to this library, and I can find links to databases such as JSTOR, but JSTOR isn’t part of WP and can be accessed without using WP if you have an account with the third party. And while we are Wikimedia, we aren’t Wikipedia, so I don’t understand why a block on a different wiki would block access to a Wikipedia source. To me the fundamental question here is more why WV-blocked users can’t access a part of WP, rather than whether Tony should be unblocked. --Comment by Selfie City (talk | contributions) 00:29, 10 October 2021 (UTC)Reply

I would also say that I can't think of a good reason why Wikipedia would prevent someone from accessing their library because they're blocked on another Wiki project. Ikan Kekek (talk) 00:59, 10 October 2021 (UTC)Reply

I'm not sure whether its his voy based block, or is it his French Wikipedia block that's preventing him from accessing the library. SHB2000 (talk | contribs | meta.wikimedia) 01:00, 10 October 2021 (UTC)Reply

A French Wikipedia block seems the more likely explanation, I agree. In that case, does he need to be unblocked on WV at all? Or is this a matter solely for French Wikipedia? --Comment by Selfie City (talk | contributions) 01:40, 10 October 2021 (UTC)Reply

I don't think so. Wikivoyage doesn't follow Wikipedia's standard offer (which ArticCynda claims is valid on WY), but in this case, Tony having 200k edits on Wikipedia is not a "get out of jail free card". He's never been constructive here, and by him spamming our emails, it's another sign of him not wanting to build a travel guide. SHB2000 (talk | contribs | meta.wikimedia) 01:49, 10 October 2021 (UTC)Reply

I went into a deeper look, and all it says was no active blocks. These seem to be the ToS:

• At their last login, did this user meet the criteria set forth in the terms of use?
• Satisfies minimum account age?
• Satisfies minimum edit count? (I don't what is the threshold for this)
• Is not blocked on any project?

So it does appear that it's a block on any WMF site. Regardless, I'm still not convinced that they should be unblocked. Even if we wanted him to use this library, he lost the privilege of voting in the WMF board elections. This isn't really a Georgian Wikipedia block (I say this in risk of getting blocked on kawiki, but over there, if you criticise the behaviour of admins on kawiki, you get blocked for "personal attacks") SHB2000 (talk | contribs | meta.wikimedia) 02:36, 10 October 2021 (UTC)Reply

I also don't think we can let him unblocked when he makes comments and edit summaries like this or disruptive comments like this or this towards non-English Wikipedia projects. Other disruptive comments by this user:

• This thread beggars belief. It is symptomatic of a sick, isolationist, xenophobic culture that cannot tolerate criticism. How did WV get this way, or has it always been like this? [- on UBN]
• Rschen, yes, you're the one who spat all over me a while ago. Not the kind of behaviour I'd expect from someone like you. [- also on UBN]
• How more skewed and ego-centric could you get? [- User talk:Tony1]

This one is more ridiculous

• I've not been uncivil to anyone [- on UBN]
• You will condemn the site to failure if you hound out people who make systemic criticisms, since those criticisms are one way of thinking through solutions. [- on UBN]

For more matters, I don't feel comfortable unblocking someone who for the most part is disruptive, and makes personal attacks and harsh accusations against other editors. SHB2000 (talk | contribs | meta.wikimedia) 04:32, 10 October 2021 (UTC)Reply

What does "[- on UBN]" mean? Pashley (talk) 06:12, 10 October 2021 (UTC)Reply

On User ban nominations. What's in the square brackets is just where he mentioned it. SHB2000 (talk | contribs | meta.wikimedia) 06:44, 10 October 2021 (UTC)Reply

I am not going to plough through archives to be able to judge whether the ban was justified at the time, but it is evident that he is a problem user. There are productive and valuable problem users, and he might be one of those at Wikipedia, but he isn't one over here. If the Wikipedia community feels he is valuable, they can ask us to unblock him; I'd be glad to consent. –LPfi (talk) 07:45, 10 October 2021 (UTC)Reply

He's also a problem on the English Wikinews as well, so I guess we're not alone in having to deal with Tony1 SHB2000 (talk | contribs | meta.wikimedia) 07:49, 10 October 2021 (UTC)Reply

If the unblock reason is mainly because he can't vote in the WMF election or access the Wikipedia Library because of the current blocks, he should be making a discussion at their respective talk pages, not asking the projects to overturn the blocks. Personally, I find that disqualifying someone from voting by having just a single block (whether for a certain length while the election is happening or indefinitely) in any project quite problematic and leads to the spectre of disenfranchisement. So for that reason, I oppose the unblock request but I am sympathetic to his situation. OhanaUnited^{Talk page} 22:33, 11 October 2021 (UTC)Reply

I'm uncomfortable with focusing on comments people made eight and nine years ago. SHB, I know your account is only eight months old, but imagine what it would be like. Do you want someone, eight or nine years from now, to come back to you and say "Yeah, well, I remember you edit warring with a Steward on Meta-Wiki, with you changing a line in a template that said right there next to the words you were changing, back in August 2021, and in October 2021, you were edit-warring with one of the official Wiki Loves organizers over how to organize the project pages [Also: multiple reverts in less than an hour, while insisting the the organizers were required to explain themselves to you? Really?], so you're obviously NOTHERE and need to be blocked forever". Would you feel a little dismayed to have years-old mistakes thrown up at you, as if you couldn't possibly have learned from those and would certainly make the same mistakes again if you were given the ability to edit?

I don't see a problem with an edit summary of "My prediction is that WV is going to fade over the next few years, and then die". What's the charge: "Failure to be sufficiently enthusiastic"? It feels like we're holding a permanent grudge because someone hurt our feelings (and by "our", I mean "people who were editing here in 2012", which does not include several of us in this discussion). The way to address a prediction of failure is to succeed, not to block people who were skeptical. Rejecting people because they're not enthusiastic about your hobby is something you expect from children. WhatamIdoing (talk) 04:17, 12 October 2021 (UTC)Reply

At least, for the most part, when Tony spammed our emails, he could have explained what got him blocked, just like what you need to do when you appeal a Wikipedia block (or really, a block anywhere). In those cases, the three reasons he gave in his appeal:

• The block prevents me from accessing the Wikipedia Library of non-free academic journals to provide sources for articles at en.WP I edit.
• The block prevented me from voting in the recent election of WMF board members.
• Crucially, I do not expect to edit Wikivoyage again.

None of those reasons explain why he got blocked, and what benefit the project will get if you unblock him. What more, he never apologised to Andre and Rschen after this personal attacks directed at him.

Regarding "My prediction is that WV is going to fade over the next few years, and then die", that's a matter of opinion on how you interpret it. In my opinion, that could have been a little more acceptable if he had a good record here, but as Andre mentioned "This user has been a thorn in our side almost from Day 1". If you take cross wiki issues out, and a brand newbie comes and all they do is bicker on how Wikivoyage is going to fail, or negatively distract the community from project goals, then literally, it's easy to assume that they're not here to build a travel guide. Now Tony1 is a little different case since he has 200k edits on the English Wikipedia. But he's not just been an issue here, he's also a problem on frwiki as well, and unblocking him here will do little to benefit us. Given the fact that he has zero good contributions here, I'm not convinced he should get unblocked. SHB2000 (talk | contribs | meta.wikimedia) 04:40, 12 October 2021 (UTC)Reply

Why would we expect anyone to follow the unblocking rules from another project?

(The enwiki rules are not perfect, and I would not recommend adopting them. The most common complaint is that they expect editors who were wrongly blocked to grovel about how wrong they were to do something that they thought, and still think, was reasonable. If you've got friends among the admins, you can usually get around this, but when the real problem is "hot-headed admin over-reacted instead of asking for a second opinion", most blocked editors are expected to say that they agree with the admin that it is harmful to Wikipedia to have editors who hold a different viewpoint, and that they'll never do that again.) WhatamIdoing (talk) 16:21, 12 October 2021 (UTC)Reply

Agree with the enwiki things. An IP who has now retired from editing Wikivoyage (82.3.185.12), was blocked there for trouting another user per "not here", which is a little silly IMO (Tony is different though, as he's made a tireless amount of personal attacks against Andre). SHB2000 (talk | contribs | meta.wikimedia) 10:37, 13 October 2021 (UTC)Reply

The Wikipedia Signpost piece detailing what a piece of shit the English Wikvoyage is (and that other languages do not exist at all) is a dealbreaker for me. I oppose an unblock.--Ymblanter (talk) 10:16, 13 October 2021 (UTC)Reply

To be clear, I think people have a right to write criticisms if our site if they want, but if they do, they can’t realistically expect us to accept those people as part of the Wikivoyage community — they don’t support our goal to be a travel guide. --Comment by Selfie City (talk | contributions) 11:21, 13 October 2021 (UTC)Reply

130% agree. But even then, their personal attacks against Andre Carrotflower and Rschen7754 in my opinion, was unacceptable. SHB2000 (talk | contribs | meta.wikimedia) 11:26, 13 October 2021 (UTC)Reply

Oppose unblock. Sucks that Tony is unable to do some stuff he wants to do now because of earlier misconduct, but who knew that actions had consequences? --ThunderingTyphoons! (talk) 13:01, 13 October 2021 (UTC)Reply

Other than COVID and the anxieties that come along with it, and other than just plain being busy with other stuff, comments like those from WhatamIdoing are a good example of a reason I've yet to resume active Wikivoyage editing. Here is someone who, out of one side of their mouth, has waxed rhapsodic about the friendly editing environment here and how much more pleasant it is than Wikipedia, yet on the other hand, seems to be doing everything they can to degrade that friendly environment through a longstanding pattern of making veiled personal attacks on myself and other editors, performatively opposing popular proposals for nonsensical reasons and seemingly only for the sake of fomenting confrontation and obstruction, and rolling out the welcome mat for users whose conduct is uniformly disruptive and abhorrent. I have tried hard to stay patient and continue assuming good faith, largely for the sake of said friendly editing environment, but now it appears the disparagements, which were annoying enough when I was here and active, continue behind my back even in my absence. So now that I'm in a period of inactivity with no defined endpoint, the stakes are lower for me, and I can be more open about the fact that this conduct is hypocritical, bad-faith, and unbecoming a user who has the (WMF) suffix on their [alternate] account. -- Andre Carrotflower (talk) 15:26, 13 October 2021 (UTC)Reply

Yes, as TT says, actions have consequences, and Tony should have thought about his actions in the first place. I must say, I'm not a fan of the WP practice of, as some have identified it, groveling to admins in order to be unblocked. The requests for apology haven't worked on WV and I think in future we shouldn't be as willing to give opportunities for apologies. When someone like Tony does what he does, we need to say enough is enough when the harm is done, and not leave the door half-open for these users to continue to cause us problems in the future. --Comment by Selfie City (talk | contributions) 17:51, 13 October 2021 (UTC)Reply

I've had run-ins with Tony1 on multiple projects (mostly English Wikipedia), some positive, some unfortunately negative. He has a lot of skill when it comes to professional writing and citations which is unparalleled and which is largely why he has not been blocked from the project where he has the most edits, English Wikipedia. Unfortunately, he has also made personal attacks as well as attacks on the English Wikivoyage (namely, the Signpost article mentioned earlier). Personally I think that an indefinite block was excessive and I would suggest unblocking him, but warning him that future disruptive conduct would lead to a block (possibly indefinite) being quickly reinstated. But, that is not an opinion that I hold strongly and would defer to the active community on that question. (And as far as the global consequences, he would have to get unblocked on French Wikipedia too in order to be reinstated in the areas he mentions). --Rschen7754 18:10, 13 October 2021 (UTC)Reply

As far as the question of legitimate criticism, I as a former steward really do question the legitimacy of a few Wikimedia projects, and sometimes openly discuss those criticisms, but then I don't go around writing one-sided articles in venues like the Signpost. --Rschen7754 18:14, 13 October 2021 (UTC)Reply

From an envoy perspective, I wouldn't like the precedent that would be set if Tony was unblocked. Other recurring banned editors like AC and LM may also try to seek forgiveness after 8 or 9 years and it will open a can of worms here. From a WMF perspective, I do agree that it's unfair that a block/ban on a WMF wiki prevents a user from accessing the Wikipedia Library of non-free academic journals but that's an issue that should be resolved at the WMF level. There are likely to be other editors who were disruptive and net negatives in one project but net benefits to others and are stuck in a similar position to Tony1. A solution should be sought that will help all editors in the same boat as Tony1 and not just him. Gizza ^(roam) 01:25, 14 October 2021 (UTC)Reply

AC tried to appeal his ban a couple of days ago as well, so if we do unblock this guy and leave AC blocked, AC will accuse us of discrimination, since he got banned for a similar behaviour. SHB2000 (talk | contribs | meta.wikimedia) 01:31, 14 October 2021 (UTC)Reply

If it would help, I would be willing to advocate access to the Wikipedia Library for all Wikipedia users in good standing (i.e., not blocked there), in the appropriate forum. Since he doesn't plan to make any edits here, his petition for reinstatement shouldn't be relevant. I don't agree that AC was banned for similar behavior. He made edits to destination articles here that were inaccurate, on the basis of bigotry. Tony1 was banned for these two posts, though with the previous baggage of this userban thread and this one, neither of which resulted in bans. It's unpleasant to relitigate this, but my feeling is, he went out of his way to defame the site and was openly hostile to the admins, not simply disagreeing with decisions but going much further than that. In no way do I think we would tolerate that kind of hostile behavior now, the way we did then. All that said, I sincerely wish him well and repeat my offer to speak up on his behalf elsewhere, but not here. Ikan Kekek (talk) 01:43, 14 October 2021 (UTC)Reply

When I meant "AC was banned for similar behaviour", I was talking in the sense he was disruptive and not what he actually did (both Tony and AC were disruptive, and so both got banned but AC was banned for bigotry, while Tony was banned for personal attacks which are both disruptive). SHB2000 (talk | contribs | meta.wikimedia) 01:49, 14 October 2021 (UTC)Reply

Yeah, but to be honest, I don't care what AC or his anti-Wikivoyage allies think of us. It's pretty rich coming from AC to accuse us of discrimination, so that doesn't concern me. I agree with the comments above that we ought to remove this restriction from the Wikipedia Library, which doesn't make sense. If someone is accessing Wikipedia Library who shouldn't, the response is for Wikipedia to block that person. Wikivoyage blocks shouldn't be affecting other websites; that's equivalent to someone being banned from Gmail and consequently not being able to use Google Search. --Comment by Selfie City (talk | contributions) 02:17, 14 October 2021 (UTC)Reply

Forgetting about AC, and back to Tony, but even if we manage to remove this restriction from the Wikipedia Library, he needs to get his French Wikipedia block sorted out. And being blocked on the French Wikipedia is a good reason to prevent someone accessing the library given that they are actually Wikipedia, not a sister project. SHB2000 (talk | contribs | meta.wikimedia) 02:22, 14 October 2021 (UTC)Reply

Agreed. Do we know if he's contacted French Wikipedia yet? --Comment by Selfie City (talk | contributions) 02:36, 14 October 2021 (UTC)Reply

Last edit by him on the French Wikipedia was in 2011, and checking "WhatLinksHere", the only links about him were seen on ANI were in 2009. SHB2000 (talk | contribs | meta.wikimedia) 02:41, 14 October 2021 (UTC)Reply

Hi all - just a quick note here that Tony emailed us and we have whitelisted his account for access to the library, so that needn't be a concern for you here with respect to his block status. Samwalton9 (WMF) (talk) 08:32, 14 October 2021 (UTC)Reply

Thanks for letting us know. I'm glad you did that. Ikan Kekek (talk) 08:41, 14 October 2021 (UTC)Reply

Thanks :-). So the only concern of Tony's was not being able to vote in the board elections, but... as Andre Carrotflower mentioned, that's a privilege, not a right. SHB2000 (talk | contribs | meta.wikimedia) 08:51, 14 October 2021 (UTC)Reply

Another new template, and that is {{PartOfPhrasebook}}. In short, it works similar to how we categorise topics with {{PartOfTopic}} such as Wine Regions of Ontario is basically categorised into Category:Topics in Canada, the same way it's categorised into Category:Alcoholic beverages. Similarly, this template should also basically do something similar, the only thing is it does not change our breadcrumb structure, only our category structure. Currently, Category:Phrasebooks is somewhat an unfriendly long list, so this template does do a good job in breaking it up. The only article where this is currently used, at the time of writing this is the French phrasebook. On top of all this, this template also eliminates the need to use {{phrasebookguide}} as all the main purposes of that template is basically integrated into this. On how that template works, see the documentation page.

Some questions answered here:

• How much more difficult would this template be for newbies?

Well, it's just as easy to use as {{PartOfTopic}}, {{IsPartOf}}, or {{PartOfItinerary}}. If those templates are too hard to use, uhm, I don't know what to say.

• Regarding on how difficult to use this template for languages spoken across two continents.

It should be just as easy to use this template as {{PartOfTopic}}. But this shouldn't be too big of a problem as there's only about 10 languages spoken in more than 2 continents, and meaning that the chance of a newbie having to use any more than the first parameter is almost zero.

• What are the chances of needing to create a new category?

Zero, because there is already six categories there, and as silly as it sounds, only if a new continent arises.

But in short, this template is no different to how other the two already existing templates of {{PartOfTopic}} and {{PartOfItinerary}} would work

Feel free to ask me any questions re this template. SHB2000 (talk | contribs | meta.wikimedia) 10:45, 9 October 2021 (UTC)Reply

Since these categories are not breadcrumbs, how would users find them? Ikan Kekek (talk) 17:02, 9 October 2021 (UTC)Reply

On Wikivoyage, categories aren't meant to be found by users, they are for maintenance purposes only. I don't think it is much easier to find a phrasebook among 120 Asian phrasebooks, than it is to find it among the total of 260 phrasebooks. And there is already a break-up in Phrasebooks. If you use some automatic means to check that all phrasebooks are indeed listed at that page, subcategories force you to go through all of them instead of being able to compare single flat lists. So what is the use case? –LPfi (talk) 17:56, 9 October 2021 (UTC)Reply

Well, this is already how we treat itineraries, so if this structure seems like a problem, then we also have a problem with itineraries (the breadcrumb structure for itineraries also changed with no consensus a couple of years ago by Traveler100).

re LPfi's concern, this template does not remove the page from Category:Phrasebooks, it only adds the page to the additional category, just like we do for itineraries (except the {{PartOfItinerary}} template is not capable of handling itineraries in two or more continents). SHB2000 (talk | contribs | meta.wikimedia) 23:03, 9 October 2021 (UTC)Reply

I'm not seeing the point. What's the point of these new categories? Ikan Kekek (talk) 00:58, 10 October 2021 (UTC)Reply

Organisation. Keeps things much more cleaner SHB2000 (talk | contribs | meta.wikimedia) 00:59, 10 October 2021 (UTC)Reply

Who would look at them? Ikan Kekek (talk) 03:06, 10 October 2021 (UTC)Reply

People like me who do some maintenance work. SHB2000 (talk | contribs | meta.wikimedia) 03:24, 10 October 2021 (UTC)Reply

It does also help with expeditions as well, particularly continent expeditions such as WV:Africa Expedition or a future Wikivoyage:Oceania Expedition that I may propose in the future. SHB2000 (talk | contribs | meta.wikimedia) 06:46, 10 October 2021 (UTC)Reply

For other expeditions, such as the Nigerian, you'll need a break-up on country level. I feel there might be no end on what structures we might need for different purposes. And adding a group of categories isn't making things cleaner, unless there was some problem to begin with, and I can see none in this case. When there is real work to be done, repeat your suggestion. Perhaps somebody can propose a solution which does not require adding more infrastructure. The itinerary case is different, as the itineraries are split over continental pages. –LPfi (talk) 07:58, 10 October 2021 (UTC)Reply

I expanded the scope to country level. So something like Category:Australia language phrasebooks is useful for the Wikivoyage:Australia Expedition. Might be a good way to incorporate phrasebooks into country expeditions. SHB2000 (talk | contribs | meta.wikimedia) 08:35, 10 October 2021 (UTC)Reply

That'd mean 200+ categories. And then you'd have to add French into how many of them? And Russian? –LPfi (talk) 10:00, 10 October 2021 (UTC)Reply

Well, the sole purposes of country categories is for expedition purposes, and since not every country has its expedition. (so countries such as Finland or Norway won't have its own category since its part of the Wikivoyage:Nordic countries Expedition). Otherwise, they should all be sorted out by continent. SHB2000 (talk | contribs | meta.wikimedia) 10:06, 10 October 2021 (UTC)Reply

And then you'd need a continental section category for the Nordic phrasebooks, or country categories for the union to be used at the expedition page. Having categories for some countries but not for others is not a clean solution. Then you'd rather have a category tree of Categories by expedition or somesuch. But let's solve the problems at hand, not build solutions for possible future problems. Which means, explain the problem at a project page and let's discuss possible solutions together. –LPfi (talk) 10:24, 10 October 2021 (UTC)Reply

But even with country expeditions, not all of them will need a category. For example, the Portugal Expedition won't ever need its own category since Portuguese is the only language spoken in Portugal. But for countries like the Philippines or India where there's a whole heap of languages used, it would be particularly useful, even if both of them don't have individual expeditions. SHB2000 (talk | contribs | meta.wikimedia) 10:31, 10 October 2021 (UTC)Reply

Heh-hem. w:Mirandese language --Nelson Ricardo (talk) 23:39, 10 October 2021 (UTC)Reply

Interesting. Never know Portugal had two three well spoken languages, including English SHB2000 (talk | contribs | meta.wikimedia) 23:41, 10 October 2021 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘The itineraries were split into continents because the main Itineraries page became unwieldy to navigate. This diff shows how it looked just before the split. On the other hand, Phrasebooks is easy to navigate on both mobile and desktop. There are less phrasebooks than itineraries as of now and it's easier to present all of them on one page because the links are generally shorter in length. I don't see a pressing need to restructure phrasebooks yet. Gizza ^(roam) 10:37, 10 October 2021 (UTC)Reply

To reemphasise, this template does not place itineraries into new continent pages, it only adds an extra layer of categories. So this template will not change the hierarchy structure, it only adds to the unreadable category structure, and is meant to be a mere aid in an attempt to also bring phrasebooks to geographical expeditions as well as for better organisation within categories. SHB2000 (talk | contribs | meta.wikimedia) 10:45, 10 October 2021 (UTC)Reply

(Edit conflict) Also, there was consensus to redo the itineraries page and create the corresponding categories. See Talk:Itineraries#Long_lists. Six editors were involved in the discussion. Gizza ^(roam) 10:47, 10 October 2021 (UTC)Reply

There was consensus to redo the itineraries, but there was no consensus to use {{PartOfItinerary}} (which replaced {{Itinerary}}). SHB2000 (talk | contribs | meta.wikimedia) 10:58, 10 October 2021 (UTC)Reply

Voting for the election of the members for the Movement Charter drafting committee is now open. In total, 70 Wikimedians from around the world are running for 7 seats in this election.

Voting is open from October 12 to October 24, 2021.

The Movement Charter committee will consist of 15 members in total: The online communities will vote for 7 members, 6 members will be selected by the Wikimedia affiliates through a parallel process, and 2 members will be appointed by the Wikimedia Foundation. The plan is to assemble the committee by November 1, 2021.

You can learn more about each candidate to inform your vote here

You can also learn more about the Drafting Committee here

We are piloting a voting advice application for this election. Click through the tool and you will see which candidate is closest to you! To try out this tool, visit: App

Go vote at SecurePoll: Vote

Read the full announcement: here

Best,Zuz (WMF) (talk) 17:44, 13 October 2021 (UTC)Reply

I miss the Auto-number headings option in the Advanced options section of the Appearence tab of Preferences. Why did it disappear? --FredTC (talk) 07:48, 14 October 2021 (UTC)Reply

I'm not too sure either. SHB2000 (talk | contribs | meta.wikimedia) 07:52, 14 October 2021 (UTC)Reply

Apparently, the answer is cache fragmentation and other serious server-side performance problems.

It is theoretically possible for a technically inclined editor to write a user script that does the same thing. I haven't heard of anyone doing this (yet). WhatamIdoing (talk) 22:21, 14 October 2021 (UTC)Reply

Yesterday the option was still available for Wikipedia; now it has disappeared there as well. Without the numbering you need to browse the whole wiki source code, to check correctness of the hierarchy of the headings. That is why I'm missing the option. I don't understand the remark about "cache fragmentation ..."; I don't see the relation to a simple numbering function. --FredTC (talk) 08:00, 15 October 2021 (UTC)Reply

The auto-number headings preference option was removed (announced on m:Tech/News/2021/26). If necessary, this former core function can be replaced by a Javascript snipped as demonstrated in mw:Snippets/Auto-number headings. --RolandUnger (talk) 13:35, 15 October 2021 (UTC)Reply

Thank you for the explanation. I'm not happy with the change, but I guess it was necessary. --FredTC (talk) 09:48, 17 October 2021 (UTC)Reply

Would the javascript solution work for you? I haven't tried it, but I am sure somebody can try to help you to get it work, if it doesn't out of the box. –LPfi (talk) 15:57, 19 October 2021 (UTC)Reply

Came to mind, but given my mass load of deletions for itineraries recently, I've noticed some "keep" votes, even if there is little content. But I was wondering if we should bring a new page into projectspace (something like Wikivoyage:Itineraries that need TLC) where these itineraries are kept, and if someone wants to work on them, it can. Reasons for this:

1. Often we don't want to delete the content some contributors have put into these articles
2. If someone thinks working on it years later seems a viable option, it's there
3. Often itineraries that were nominated on vfd were worked on for about 1 week

On the other hand:

1. It still gives the creator incentive to make the article usable, and keep this in mainspace. Otherwise projectspace ≠ mainspace, for readers to view
2. This page should only be for pages that are more than a useless stub (so a page like Erlian Grassland Tour Loop or Rama's journeys don't go into this page, and should just be deleted)

If the incentive thing doesn't work, I personally feel like if no one touches the article in this new storage page after a certain amount of time (let's say, 3 years?), it can be deleted without a nom.

Does that work better and a better alternative to deleting? SHB2000 (talk | contribs | meta.wikimedia) 09:24, 16 October 2021 (UTC)Reply

What is TLC? LPfi (talk) 20:26, 16 October 2021 (UTC)Reply

Tender loving care. Ikan Kekek (talk) 20:29, 16 October 2021 (UTC)Reply

I think that SHB2000's clean-up of dormant itineraries has been a good project, and has resulted in a number of itineraries being improved. Moving new outline itineraries into project space is a good idea. If a contributor starts an itinerary in the hope that someone else will make it usable, we should be able to figure that out pretty quickly. One year in project space should be enough time to determine whether there is interest in working on them or not. Ground Zero (talk) 20:39, 16 October 2021 (UTC)Reply

I think our response to a new outline article being created should be encouragement and help in turning it into a detailed, high-quality article, not immediately relegating it to somewhere in project space where it is unlikely to be seen. —Granger (talk · contribs) 10:35, 17 October 2021 (UTC)Reply

I'm happy when someone creates a new article with the intent of developing it, although that is better done in User space. Unfortunately what we see mostly is people creating articles for "someone else" to develop. We have hundreds and thousands of stub articles for regular contributors to work on (and I have been adding content to a lot of stub articles), we don't need more added to that list. For example, Kohoku and Miyaki, which were created in 2007 with no content at all, and nothing was done with them for 14 years. These articles don't benefit readers, and stub articles don't make Wikivoyage look like a useful resource. Ground Zero (talk) 12:22, 17 October 2021 (UTC)Reply

I will admit that I myself have created some of these itineraries, although I've worked on them, and nearly all of them are usable. The only one I've created recently that remains outline (Alpine Way), was created as one of my redirects on Khancoban seemed controversial, and every time I went back to the Alpine Way page, I seemed to get emotional (it was the last place I was, before going into a 108 day lockdown, and every time I even saw a link of "Alpine Way", it seemed to give me pre lockdown memories). I do have plans to merge that page though. SHB2000 (talk | contribs | meta.wikimedia) 13:01, 17 October 2021 (UTC)Reply

If this thing does go ahead, would this proposal be a good rough draft on how long things should go where:

• Outline itineraries that are not famously marked trails (i.e. something like Easy Rider or even Tanami Track) go here after six months, without a redirect. If there's no edits for six additional months, it can be nominated for deletion via vfd (similar what we already do).
• Outline itineraries that are famously marked trails such as the newly created stub national historic trails go here after 18 months (I would prefer 12 or 15, but I don't think everyone would be happy with that) of no edits without a redirect, and if it remains an outline itinerary after 48 months, it gets deleted via vfd (that is more than enough for anyone to work on it, and the work doesn't get left to Someone else.
• Once an article becomes usable in this project space, it immediately get's moved out
• By definition of "no edits", it means actual actual edits about the itinerary, so things like reverting spam/vandalism, fixing typos, simple copyedits, or formatting fixes don't count

This is far lenient, and gives years to work on it. And I feel that our "don't delete famously marked trails" is somewhat used as an excuse to a) not delete the itinerary, but b) also leave the work to Someone else. So basically, it doesn't get moved here immediately and so it does give time to work on it, but at the same time, it forces the creator to make it usable and out into mainspace. SHB2000 (talk | contribs | meta.wikimedia) 10:30, 22 October 2021 (UTC)Reply

I suppose that after 18 months, the original creator has forgotten about it, and it being moved out of mainspace doesn't provide any discouragement. Any one who wanted to work on the itinerary has had plenty of time, but often we want a new user turning up to find and work on that itinerary. Will they find it in project space? By what mechanism? I still believe that the odd outline has a higher probability to be developed than a non-linked trail (this is different from stub travel topics, where the scope and structure is given by the author, not by our guidelines), and that the odd outline does not discourage readers.

One way to make projects space outlines findable would be to leave redlinks in the summary articles (such as United States National Trails System), and give a link to the project space article for users following that redlink (I suppose it could be done with some mediawiki-space magic). That would require the redirect to be deleted.

–LPfi (talk) 11:15, 22 October 2021 (UTC)Reply

I wonder what the goal is. Is it closer to "get pages improved" or "hide embarrassingly incomplete pages"? WhatamIdoing (talk) 18:17, 22 October 2021 (UTC)Reply

When it comes to itinerary and topic articles, we should not be encouraging article creation by people who aren't willing to make the articles usable. Itinerary and topic articles can bring colour and depth to a travel guide, but they are not the core of a travel guide. Dedicated editors are better off spending time improving destination articles than on itinerary and topic articles that are started and abandoned. Saying that such pages are not part of the guide is sensible if people are uncomfortable with deleting them. Ground Zero (talk) 18:43, 22 October 2021 (UTC)Reply

If that's the reasoning, then why not outright delete them? Because we don't have the courage to do that? I don't like that line of thought. Moving the articles to project space signals that this is something the insiders should take care of – but you say we shan't use our energy on that. Then move them to the creators user space. But is this the way to go also for sufficiently famous marked routes? I assumed we wanted those to be written, i.e. have people spend time on them. –LPfi (talk) 18:57, 22 October 2021 (UTC)Reply

I think it is because some people think that someone else will work on these articles some day, so it is worth saving whatever text there is. Insiders can work on whatever they want without regard to what I think. For my part, I think that crappy articles put readers off Wikivoyage, so I work on improving the articles we have. But there are so many articles that need improvement to be useful. I think it is a bad idea to have people creating more articles to be improved by "other people". We don't have enough regular contributors to need passers-by to ge creating more clean-up/article improvement work for us.

This stub article sat for 16 years without any useful content being added. This one sat for 15 years waiting for "Someone Else", as did this one. Ground Zero (talk) 19:14, 22 October 2021 (UTC)Reply

Agree. And sadly that was the case for much of these. While some were actually worked on well, such as Nidaros Path (even to the point where LPfi made a mapline, which is time consuming but makes it usable), a lot of articles such as Mountains to Sound Greenway have remained an outline (although that has been taken care of) end up in the same state as they were before vfd.

To LPfi's "But is this the way to go also for sufficiently famous marked routes?", and under these proposed proposal, it also includes famously marked routes, so cases like National Historic trails don't get away, as they [some newly created ones] are just as useless since it has no travel info. SHB2000 (talk | contribs | meta.wikimedia) 05:25, 23 October 2021 (UTC)Reply

The issue is a long standing one. I personally feel the "notable itinerary" thing is being heavily misused to keep articles, and at the same time, leave it to Someone Else. This is not just for itineraries, but destination articles as well. When I upgraded about 400 articles from outline to usable, almost about 150 of them were stubs that were near useless that it may have been better to not have the article in the first place. I probably improved about 100 of them to bare usable, and redirected the other 50 or so. Such include Houtman Abrolhos, a set of uninhabited islands.

To be fair, I wouldn't normally quote someone who has made a ton of personal attacks, but in this case, KevRobbAU/SCO (since retired) has time and time said that it's better to get articles usable from the very start. And I think we can all agree on that – but sadly that's not the case. SHB2000 (talk | contribs | meta.wikimedia) 21:38, 22 October 2021 (UTC)Reply

I agree that we have too many weak outlines and that new ones shouldn't be created. I prefer redlinks in most cases where an article would be nice to have. Then, when there is some information not easy to reproduce, deletion is a shame (and redirects problematic). Ideally the proportion of weak outlines would be low enough not to give a bad impression, and we could then keep the few that don't get to usable to be worked on later.

If we disregard the historic baggage of existing stubs, I'd hope we could each avoid creating these outlines, and then we wouldn't have to discuss deleting them. Even if one can create an article with some info, the same work put into improving another article will usually be much more valuable and create no frustration in the community or among readers.

There may be exceptions, such as if you travel through part of an itinerary and thus have unique information on it that you want to save in a findable place, but things that can easily be researched on the net should either be put into a usable itinerary or restricted to a Do listing or Do subsection.

–LPfi (talk) 10:09, 23 October 2021 (UTC)Reply

Let me explain why I'm asking what the goal is. We generally agree on these things:

• Some pages (itineraries and other articles) are in poor condition.
• There is more work to be done than volunteers doing it.
• Pages that aren't in the mainspace normally aren't seen by readers or by anyone else, for that matter. Someone else is more likely to clean up a page in the mainspace than to clean up a page outside the mainspace.
• Some pages (and some types of edits) are more valuable to readers than others.
• Volunteers should spend their time making whatever (constructive) contributions they want, even if another volunteer thinks that's a low-value use of time.

There are also things that reasonable people could reasonably hold different opinions about. These things include (but are not limited to) the classic questions of eventualism and immediatism:

• Is it better to look good or to look like this is a wiki that really needs you to plunge forward and contribute to it? Looking "good" might improve people's subjective opinions of the project, but looking "finished" decreases the motivation for newcomers to contribute.
• Is it better to have a page (even if it's an unusable outline) or to have only better-quality pages? Having a page, even if it's mostly empty, might improve search engine traffic (compared to no page) and it provides some information (however tiny that amount might be), but having a high proportion of pages with dramatically less content than other travel sites might decrease people's interest in clicking on links to the project when they see them.

We also have a fairly limited number of options for an incomplete page:

1. We can ignore it (most common action).
2. We can improve it.
3. We can merge it to a bigger page.
4. We can delete it.
5. We can move it to a different namespace.

Option #1 is the default; it provides minimal information to readers and irritates our immediatists and other reputation-minded contributors. Option #2 is highly desirable but not realistic in most cases. Option #3 can be good but is also unrealistic on a large scale. Option #4 increases the value of the median page that a reader will see, but it provides less total information (because readers see fewer pages), and it irritates our eventualists and similarly minded contributors.

Option #5 is IMO the worst of all options. In this option, we aren't offering whatever minimal value the page had to readers; we aren't getting rid of the poor-quality pages; we aren't improving them – in fact, we are doing something that is proven to ensure that the page doesn't get improved. Someone else might only rarely improve articles, but Someone else never improves "draftified" pages. Then, in a couple of years, we'll all pretend that we are shocked, shocked to discover that these hidden pages weren't improved, and the people who would prefer to just delete them now will be able to delete them then without needing to bother with formalities like nominating them for deletion and seeing whether others agree. (Also, we may get disputes about who is allowed to move the pages back to the main namespace under which circumstances.)

So if your goal is:

• providing some information to readers, even if it's not much about any specific subject: You want option #1.
• driving traffic to the site/good SEO (even if people don't stick around because there isn't much information): You want option #1.
• encouraging newcomers by letting them see how much needs to be done: You want option #1.
• having pages that we can be proud of: You want option #4.
• having readers stick around (once they get here, which will happen less often): You want option #4.

The only goal that fits with option #5 is: Eventually being able to delete these pages without so many other editors noticing and possibly objecting. (If that honestly feels like a goal, then the real problem is likely in the deletion policy/process, not in these pages.) WhatamIdoing (talk) 21:19, 23 October 2021 (UTC)Reply

There is zero chance if Wikivoyage ever "looking finished". I encourage you to pick half a dozen articles at random and review them. Even if articles were to start to look somewhat filled-in, the nature of a travel guide is that it needs constant updating. Let's not waste time on nonsense arguments.

I do not think there is any basis to say that "Someone else never improves "draftified" pages". There is a small possibility that a regular contributor will improve a project page, albeit smaller than they will improve an article, so we should not dismiss project pages altogether. I am indifferent between projectifying or deleting outline itineraries.

There are lots of websites out there that encourage readers to contribute. The websites that bring me back are those that offer information instead of an invitation to "be the first" to write a review. I don't think I am alone in that. Ground Zero (talk) 22:17, 23 October 2021 (UTC)Reply

To WhatamIdoing's question, I get the same sentiments as GZ. Infact, I never even wanted to start this thing, but given that the "well marked itinerary" reason is being misused, I sadly had to do this.

The whole purpose of this is to motivate the page creator to make it usable before a certain amount of time. If it doesn't, ideally it'd be deleted in 12 months time, but the "famously marked trail" is being heavily misused to keep stubby itineraries that drive our reader base away. But regardless, IMO, they shouldn't be in the mainspace, driving our reader base away. SHB2000 (talk | contribs | meta.wikimedia) 22:29, 23 October 2021 (UTC)Reply

WhatamIdoing, I appreciate your points, but keep in mind that pages on people's userspaces are not nominated for deletion. Ikan Kekek (talk) 22:35, 23 October 2021 (UTC)Reply

There was a time in May 2020 when a bunch of fictional destinations in LibMod's userspace was deleted, but that's a different case since he's banned and globally locked. SHB2000 (talk | contribs | meta.wikimedia) 22:40, 23 October 2021 (UTC)Reply

And they were fictional. Also, another thing is that draft articles on people's userspaces do sometimes receive substantial collaboration if the host user is OK with that, but usually when they're new. Ikan Kekek (talk) 00:37, 24 October 2021 (UTC)Reply

Generally, I'm one of those who would want people to edit draft articles in my userspace (examples such as Australian cuisine). Ideally if there were a draft namespace, I'd do that, but we don't have that on voy so userspace is the only option. SHB2000 (talk | contribs | meta.wikimedia) 00:41, 24 October 2021 (UTC)Reply

SHB, what is your evidence that incomplete articles are "driving our reader base away"? WhatamIdoing (talk) 21:14, 24 October 2021 (UTC)Reply

@Ground Zero, my basis for saying that other editors do not contribute to draftied articles is some research led by w:en:Aaron Halfaker a couple of years ago. You can read the paper at http://jodischneider.com/pubs/opensym2014.pdf Look for the section titled "AfC hides drafts from potential collaborators" and words like "drafts see a decreased level of collaboration". WhatamIdoing (talk) 21:12, 24 October 2021 (UTC)Reply

@WhatamIdoing: thank you for that article. I didn't read the whole thing, but it seems to support that view that "There is a small possibility that a regular contributor will improve a project page, albeit smaller than they will improve an article", rather than that they will never contribute to a project page.

Wikipedia's AfC is not the process that is being proposed here since that throws up walls at the beginning of an editor's contributions. What is being proposed here is a way of dealing with projects that have been abandoned by the original author, and not taken up by others. So the concerns the paper raises about discouraging new editors don't apply here, in my opinion. Ground Zero (talk) 22:33, 24 October 2021 (UTC)Reply

This research shows that Wikipedia's AfC process is more effective at getting other editors to edit sub-par pages than doing nothing (i.e., what we have here).

This research shows that hiding those pages in another space is less likely to result in improvements than leaving them where they are.

This suggests to me that the sensible options are:

• leave them alone, or
• delete them now.

The proposal to shuffle them into another namespace, keep track of which one(s) were moved when, and remember to come back years later to delete them all is a whole lot of time and effort wasted to produce the same end result. If you want to get rid of them, then just do that.

OTOH, if you feel that you can't justify deleting them, then leave them alone, because leaving them right where they are gives them the best (albeit very small) chance of being improved.

What I don't want to see is us claiming that we are encouraging improvements to these pages while we are actively doing one of the few things that's been definitely proven to reduce the (already small) chance of improvements. If we're ready to give up on them, then let's use the delete button. If we're not, then let's give them the best chance possible, which means leaving them where they are now. WhatamIdoing (talk) 23:59, 24 October 2021 (UTC)Reply

Wikivoyage and Wikipedia are very different communities, largely because one is quite small and the other is very very big, so the lessons learned from one community are often not applicable to the other. What we do know, though, is that we have a really large pile of stubs started up to 18 years ago that have had no substantive edits since they were started. Giving stub articles "the best chance possible" means greeting a lot of first-time visitors with useless pages that give them no reason to want to spend more time here. For my part, I am happy to delete articles that no-one wants to improve after a reasonable time. I think that SHB2000's proposal is aimed at assuaging those community members who still see a glimmer of hope the Someone Else will rescue these articles someday. I am not one of those people. Ground Zero (talk) 01:04, 25 October 2021 (UTC)Reply

I agree with WhatamIdoing that doing something just to assuage the opposition is suboptimal, and I think the reasoning behind "never delete real places" is flawed. At the start, the site did want to get a reasonable coverage, and at that point one couldn't be too choosy about what articles to "approve". Wikipedia had a similar infancy. Now, when large parts of our coverage is well-developed, a pile of stubs somewhere gives a bad impression that we can avoid. Still, I think the project page solutions has merits, if implemented well.

The problem with piles of stubs is mostly about mass created city articles and regions without content. For itineraries I don't see the same problem. We have 186 outline itineraries, which is about half of the itineraries and few enough that a single editor could improve them all (although this would be less efficient use of resources). A list where half the entries are usable or better is not a disaster.

Most outline itineraries have sensible names, suggesting they are worth writing. Thus I don't think personal itineraries are an issue any more. Some, such as Markha Valley Trek, have a reasonable Understand, which will not frustrate readers, unless they have high expectations. Those should remain as linked itineraries in mainspace, in the hope on them being improved at some time. Others, such as Congo Nile Trail, doesn't give enough information to be useful at all, and is the kind we are discussing (the author of this one left when some links were removed as touting). Then we have the lists, such as the US trails and Long distance walking in Europe, enticing passers-by to contribute as best they can.

I think the most important step is to nip in the bud: get consensus on that creating stubs isn't making Wikivoyage better (other than in special cases), and avoid having lures in the form of lists of redlinks (give an external link instead, if warranted, such as with the American and European trail systems. We might reinsert the redlinks at a point where we do want passer-by contributions and have enough content that a few weak outlines are no problem.

Then we have existing or newly created weak outlines. Some could be redirected to a Do or Go next listing (the latter not according to current guidelines), based either on the outline or on new research, which would give enough hints for a reader to find information on their own. The redirect name could be saved as a comment in the listing, perhaps as a hidden template field (outline_at=).

Then we have itineraries we cannot usefully link to or include in the articles, as they would be frustrating if linked directly and info for a listing is too hard to find. Those shouldn't be exposed to readers. Those without any usable info could be deleted, but I don't think moving them to the user space of the author does any harm. We could have a page Wikivoyage:Suggested itineraries linking to a category page for weak outlines moved to user or project space (such as subpages of Suggested itineraries).

Although few of the suggested itineraries will grove, I think some might, and this would be a low-cost solution to avoid long discussions on borderline cases, and in cases where somebody gets inspired by a "suggested itinerary" it makes a real contribution.

–LPfi (talk) 09:01, 25 October 2021 (UTC)Reply

I still think it should be the rule that real places of any significance shouldn't be deleted, but a lot of merging is reasonable. Itineraries aren't places, so this doesn't apply to them. Ikan Kekek (talk) 09:33, 25 October 2021 (UTC)Reply

I would generally tend to half agree with "real places of any significance" with the key word being significance. Unfortunately, I've had to recently merge articles because someone created it because of one roadhouse or one hotel. SHB2000 (talk | contribs | meta.wikimedia) 10:11, 25 October 2021 (UTC)Reply

Yes, because if that content is merged, the attribution needs to be kept intact. Ikan Kekek (talk) 10:56, 25 October 2021 (UTC)Reply

It is possible to merge the article, and then not have a page under the name such as moving it to a different name space, without a redirect, and then fully protecting that page or less favourable, listing all the authors on the relevant talk page (that is not advised as it doesn't tell who wrote what). It's a similar reason to why we can't delete Template:RegionStats/depreciated since the new modified template is based on that template. SHB2000 (talk | contribs | meta.wikimedia) 10:59, 25 October 2021 (UTC)Reply

There are lots of things that are possible, but they mess up the attribution. Ikan Kekek (talk) 11:08, 25 October 2021 (UTC)Reply

And the risk of someone turning a redirected page back into a separate page is so low that such maneuvers seem like a waste of effort. WhatamIdoing (talk) 15:36, 25 October 2021 (UTC)Reply

I feel like redirects being turned back into separate articles hasn't been quite so rare here as you'd think. And sometimes it's been done very well. Ikan Kekek (talk) 19:29, 25 October 2021 (UTC)Reply

I have recently been trying to turn back redirects back into articles using Category:Redirects connected to a Wikidata item as a starting point. Not every redirect in that category is suitable to be turned back but most are. But I agree that new editors in particular, who are not aware that this category exists won't be turning redirects into articles and are much more likely to expand a stub if the stub exists because it's easier to find. Gizza ^(roam) 01:18, 26 October 2021 (UTC)Reply

Today I noticed that there is an extra envelope at an email address in a listing: the one front of the email address and also one after it. Didn't I notice this second one before, or is it new?

• email example, [email protected]. 

--FredTC (talk) 09:59, 17 October 2021 (UTC)Reply

@FredTC: noticed this on Tavares as well. Strange. SHB2000 (talk | contribs | meta.wikimedia) 21:41, 17 October 2021 (UTC)