Wikipedia:Village pump (miscellaneous)

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
 Policy Technical Proposals Idea lab WMF Miscellaneous 
The miscellaneous section of the village pump is used to post messages that do not fit into any other category. Please post on the policy, technical, or proposals sections when appropriate, or at the help desk for assistance. For general knowledge questions, please use the reference desk.

Discussions are automatically archived after remaining inactive for a week.

« Archives, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71

Discord ban[edit]

I got banned from the Wikipedia Discord with no reason, my username is h moment#9731 UnnamedWasTaken (talk) 18:07, 11 August 2022 (UTC)Reply[reply]

That's run by different people. See Wikipedia:Discord#How is Wikimedia Community Discord related to Wikipedia?. If you're asking to be unbanned, you need to address that to the people who run the Discord server. -- RoySmith (talk) 18:15, 11 August 2022 (UTC)Reply[reply]
But there is no dicussion board there, if you have no answer, don't give an reply. UnnamedWasTaken (talk) 18:33, 11 August 2022 (UTC)Reply[reply]
User was banned for trolling immediately after joining Discord. Nothing further to add. Ponyo has blocked on-wiki. -- ferret (talk) 22:40, 11 August 2022 (UTC)Reply[reply]

New Upload Tool - Sunflower[edit]

Sunflower app icon large.png

Hey folks, I recently created a new upload tool for Commons called Sunflower. If you have a Mac, I'd greatly appreciate it if you could try it out and share your feedback. Thanks! -FASTILY 08:27, 12 August 2022 (UTC)Reply[reply]

@Fastily, have you talked to the GLAM folks about this? Batch upload tools are usually interesting to them. Whatamidoing (WMF) (talk) 18:54, 15 August 2022 (UTC)Reply[reply]
And have you listed it at m:Toolhub? Whatamidoing (WMF) (talk) 18:55, 15 August 2022 (UTC)Reply[reply]
Thanks for the suggestions! I've listed the tool on Toolhub. Do you have any recommendations on how to go about talking to GLAM folks? Is it the mailing list? Thanks, FASTILY 04:05, 16 August 2022 (UTC)Reply[reply]

Input needed[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Please comment in the RfC about the first sentence in Jimmy Savile sexual abuse scandal. Cheers! Thinker78 (talk) 23:54, 14 August 2022 (UTC)Reply[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Look at your list of created articles with the Xtools Page API[edit]

I've created a new tool which gives insights about your list of created articles using xtools page prise API : https://observablehq.com/@pac02/look-at-your-list-of-created-articles-with-the-xtools-page-ap. It provides statistics about the actual number of words, references and sections in each article you've created.

Your feedback would be greatly appreciated.

Do you know if there is some page in Wikipedia where we could list this kind of tools? PAC2 (talk) 05:19, 15 August 2022 (UTC)Reply[reply]

There's Wikipedia:Tools ... Graham87 11:02, 15 August 2022 (UTC)Reply[reply]
Thanks --PAC2 (talk) 05:56, 16 August 2022 (UTC)Reply[reply]

Wikimedia Foundation English fundraising campaign - further pre-test updates[edit]

Hi everyone,

As previously mentioned here, I will continuously inform you of pre-tests on English Wikipedia as the Wikimedia Foundation prepares for the English fundraising campaign later this year. As part of the English campaign we test our infrastructure on a regular basis throughout the next few months and you might see banners every now and then on Wikipedia if you are not logged in.

The next scheduled dates are:

  • The 17th of August - a 100% traffic three hour test
  • The 22nd to the 29th of August - a low level week long test (During the test, a banner will only be shown to users 5% of the time until the maximum of 10 impressions (1 big and 9 small banners) is reached.)
  • The 1st of September - a 100% traffic three hour test
  • The 8th of September - a 100% traffic three hour test
  • The 16th to the 18th of September - a 10% traffic weekend test — Preceding unsigned comment added by JBrungs (WMF) (talkcontribs) 06:38, 16 August 2022 (UTC)Reply[reply]
  • The 22nd of September - a 100% traffic three hour test

Generally, before and during the campaign, you can contact us:

Please let me know if you have any questions.

Thanks you and regards, JBrungs (WMF) (talk) 07:35, 15 August 2022 (UTC)Reply[reply]

Thanks. Please note there is also a community review of the Wikimedia Foundation's English fundraising emails ongoing at Wikipedia:Village_pump_(proposals)#Review_of_English_Wikimedia_fundraising_emails. This has the complete wording of the sample emails provided by the WMF to date. These emails go out to millions of existing donors, widely shaping perceptions of Wikipedia and our financial situation. Please have a look and comment. (The email campaign will kick off soon; it is scheduled to run from 6th of September to 20th of November.) Best, --Andreas JN466 10:05, 15 August 2022 (UTC)Reply[reply]

Mass addition of Cleanup bare URLs template[edit]

The task of encyclopaedia cultivation generates vast amounts of paperwork that, if left unaddressed by volunteers, accumulate into enormous backlogs.

{{Cleanup bare URLs}}

The community will never keep-up with this mass spamming (63,051 pages)....sometimes 2000 are added a day. .this banner has zero benefits for readers at the top of articles.....perhaps add this to the top of the "References" section for editors. Is there going to be any effort to actually fix the problem .....that in many cases is just a few sources? Moxy-Maple Leaf (Pantone).svg 16:53, 15 August 2022 (UTC)Reply[reply]

First off, you seem to have made no attempt to notify the person who is doing it. Second, Is there going to be any effort to actually fix the problem -> yes, she's personally fixed tens of thousands of bare URLs. Third, 63,051 pages is a massive overestimate, as {{cleanup bare URLs}} is only transcluded on 17K pages * Pppery * it has begun... 17:04, 15 August 2022 (UTC)Reply[reply]
Yup many have raised concerns....only one person has done all this? Is the bot approved?Moxy-Maple Leaf (Pantone).svg 17:07, 15 August 2022 (UTC)Reply[reply]
See also the cross-post at Template talk:Cleanup bare URLs#Mass spamming - you shouldn't start discussions in multiple places * Pppery * it has begun... 17:07, 15 August 2022 (UTC)Reply[reply]
No reply to last few post...moved here now......lets assume we are trying to start a good talk. Any reply to the proposal made? Again is there a plan to go back and fix the articles now tagged?Moxy-Maple Leaf (Pantone).svg 17:08, 15 August 2022 (UTC)Reply[reply]
Most likely yes, but does it matter? These tags will likely succeed in turning the task of fixing the longstanding backlog of bare URLs into something other than an near-Herculean effort by one editor. Why is this a problem, and why should the existence of bare URLs be swept under the rug? * Pppery * it has begun... 17:27, 15 August 2022 (UTC)Reply[reply]
We are getting banners added to the top of article all over..for just a few bare urls....these deter readers...as we know most only scroll one time. Why not add it to the ref section? Should be doing what is best for readers ...not editors. Moxy-Maple Leaf (Pantone).svg 17:30, 15 August 2022 (UTC)Reply[reply]
I think putting the banner in the ref section is an excellent idea. That narrowly targets it to the type of reader/editor most likely to be inclined to act on it. EEng 19:11, 15 August 2022 (UTC)Reply[reply]
@Moxy's conduct here is very poor: they opened in two places a discussion about my edits, without making any attempt to notify me about either discussion. No ping, no mg on my talk, no email. Nada.
But despite this, Moxy complains No reply to last few post.
WTAF??? How on earth does Moxy expect a reply when then chose to not notify the editor who they know is doing most of these edits? Is this a display of cluelessness, or some sort of game?
Note that Moxy has bad history on this issue of bare URLs. Back in March, Moxy objected to me adding the inline tag {{Bare URL PDF}} to thousands of articles; but they did so by sniping in edit summaries rather than starting a discussion. So I started a discussion on Moxy's talk, but Moxy was not interested in anything I had to say. Instead, they deleted[1] the discussion with the edit summary "back to content", so our unfruitful exchange is available only in the page history: https://en.wikipedia.org/w/index.php?title=User_talk:Moxy&diff=1077213739&oldid=1077213451
So I am sadly unsurprised to find the deplorable antics displayed here: no notification, and a WP:ABF prejudicial heading which describes WP:V-related cleanup as {{spamming}}. BrownHairedGirl (talk) • (contribs) 21:52, 15 August 2022 (UTC)Reply[reply]
Anyway you can adrdress the proposal raised here. As per your post on my page and a few others.....people have some concerns about the editor's adding these all over.... or more specifically their placement. looking for more fruitful talk than my talk page where I'm told what to do .Moxy-Maple Leaf (Pantone).svg 22:18, 15 August 2022 (UTC)Reply[reply]
A decent, civil editor would have taken this opportunity to apologise for the lack of notification, for the prejudicial WP:ABF heading, and for deleting a discussion.
But no, @Moxy does none of those. Quelle surprise. BrownHairedGirl (talk) • (contribs) 22:30, 15 August 2022 (UTC)Reply[reply]
We will simply have to move forward without your input on this point. Moxy-Maple Leaf (Pantone).svg 22:43, 15 August 2022 (UTC)Reply[reply]
@Moxy: thank you for clarifying that your failure to notify was an intentional attempt to exclude me from a discussion about my work.
And no, you will not proceed without my input. (I see no "we"; just you with that attitude). I have added my substantive comments below, but judging by our previous discussions and your misconduct here, I expect that you will not be interested in anything I have to say. BrownHairedGirl (talk) • (contribs) 22:53, 15 August 2022 (UTC)Reply[reply]
What do you think about moving the banner? Moxy-Maple Leaf (Pantone).svg 23:06, 15 August 2022 (UTC)Reply[reply]
@Moxy: I oppose moving it.
And you should already know that I oppose it, because you have already replied to the discussion following my comment opposing it. So what game are you playing by asking me? BrownHairedGirl (talk) • (contribs) 23:13, 15 August 2022 (UTC)Reply[reply]

I raised moving this template to the "References" section on the talk page of the template. It's great that cleanup work is being done, and I don't mind tracking this. However, as I brought up on the talk page, this isn't appropriate for the top of the article. Cleanup banners are meant for readers first and foremost (as a warning), with the fact that they encourage editors a happy byproduct. This template is 100% editor-focused, and furthermore, only on a subset of editors. Readers don't care if citations are properly formatted. Readers might care if the citations are "bad", but that isn't what this template is about: it's entirely possible for a bare URL to be an accurate and sufficient reference for the content. Sticking it in References will ensure editors notice, but don't trouble readers who both don't care and can't fix the problem. (And more generally, as anyone who has gone to edit-a-thons aimed at attracting new editors can tell you, stuff like "how to format your references" is the absolute last priority when teaching someone how to Wikipedia - it's not what we expect most newbie editors to do, and "use a bare URL or text, someone else will fix it later" is fine.)

As for the comments by *Pppery* above on "why is this a problem", the problem is banner blindness. A bunch of irrelevant-to-readers banners teaches them to ignore the content warning templates more than they already do. Even worse, a reader who gets a vague sense of distrust of articles when seeing cleanup banners (but doesn't closely read / understand this one to realize it's no big deal) might conclude that the banner means the article is unreliable, when in fact an article could well be featured-article quality but have one random bare URL added 6 months ago. This is definitely bad. For example, if a citation template has an error, there'll be a warning to editors in "preview" mode, but it won't show in normal display after saving, because regular readers do not and should not care if somebody misspelled a parameter in their citation template or whatever, while editors capable of fixing the problem can be casually warned at the next opportunity.

Do we need an RFC for this, or can we just convince BHG & others to move this template to References? It seems like an obvious win-win that leaves each side happy. SnowFire (talk) 19:31, 15 August 2022 (UTC)Reply[reply]

EEng: I am concerned about that phrase the type of reader/editor most likely to be inclined to act on it
WP:V is a core policy of Wikipedia, and high-quality references are the core of what we do here. Bare URLs are bad for readers, because they make it hard to identify and assess the source without opening the links, and because they are prone to WP:Linkrot.
As I have worked my way through the backlog of over 470,000 articles with bare URL which we had in May 2021 (now down to ~100,000, with a much higher proportionate reduction in the total number of individual bare URLs), I have been heartbroken to find how many refs were dead and irretrievable, and now effectively useless. The URL alone often gives little or no clue as to the actual content of the web page, and many webpages are not archived the Wayback Machine and other tools. As a result, many older articles are in large part unverifiable, because the sources used are unavailable. If we were really serious about WP:V, we'd be systematically ripping out all the content which can no longer be verified, unless we can find another sources; and we be flagging up with much greater prominence the article text which is not verifiable.
This is a huge problem. We are serving up to our readers content which fails our core policies. Our readers rely on us to assert facts which they can verify, and by tolerating bare URLs we deprive them of that chance ... because most URLs eventually rot and die.
After huge progress in the last year, there are now two issues with bare URLs:
  • The backlog of old bare URLs; there are about 150,000 individual bare URLs on about 100,000 articles
  • The flood of new bare URL refs, added at a rate of over 300 per day. Using various tool, about 80% of those are filled within a month, but tool-filing of refs is in most cases mediocre, and that leaves about 2,000 articles every month getting new bare URLs.
This is time-critical work. The longer a URL is left unfilled, the more likely it is to have rotted and become unfillable, or to have changed its content. Some URLs, such as those based on news agency reports, are systematically removed by their publishers after a fixed time period (usually a few months, sometimes much less); some because the website retains only fresh content; others are lost because websites die or are restructured.
That's why a prominent notice is valuable: because unless a ref is filled soon, it may not be fillable.
So, yes, it would be possible to add the banner to the references section. But I think that doing so would be a very bad idea, because it would give the false impression that crap referencing is not important enough to flag up prominently. I strongly oppose @SnowFire's view that bare URLs are no big deal. WP:V is very clear: good referencing is not just a big deal; it is the absolute core of what we all do here. --BrownHairedGirl (talk) • (contribs) 21:37, 15 August 2022 (UTC)Reply[reply]
I'd like to see some actual statistics on the kinds of URLs typically found being used as article references. I suspect a substantial proportion of them are Googlebooks, Jstor, and similar links not reasonably subject to rot. If a particular article's bare URLs are entirely of that kind, then cleaning up that article is due much lower priority, and maybe doesn't call for the banner -- perhaps such articles should just go in a category. I wouldn't be suprised if this cuts the banner-ing substantially. EEng 14:46, 16 August 2022 (UTC)Reply[reply]
That may have been true originally, but in the specific case of JSTOR and Google Books, Citation bot has likely handled the bare URLs to those websites months ago. See the comment about the 80/20 rule below. * Pppery * it has begun... 16:12, 16 August 2022 (UTC)Reply[reply]
@EEng: @Pppery is right about progress. e.g. All new JSTOR refs are filled every day, because I use them in the daily set of ~100 searches which I use to make worklists for @Citation bot.
As to the wider sets: about a month ago, I made a list of all the then extant bare URLs, and then turned that into a spreadsheet listing the number by domain.
The results surprised me: much less clustered than I expected. The biggest set at the time was WaPo (washingtonpost.com), with just over 900 entries. I was expecting that, 'cos @Citation bot doesn't handle WaPo, so I wrote and deployed a tool to automatically fill (most) WaPO refs.
AFAICS, that lack of clustering makes analysis-by-quality of website near-impossible; it would take far too much work, and the effort would be much better placed into filling/tagging-dead/removing/replacing the bare URLs. However, if you (or anyone else) would like a copy of my data, pls just send me an email with the subject line "bare URL website distribution spreadsheet". BrownHairedGirl (talk) • (contribs) 18:50, 17 August 2022 (UTC)Reply[reply]
I've seen these coming up on multiple watchlisted articles and have been going along behind and fixing. For me these are helpful. Valereee (talk) 21:55, 15 August 2022 (UTC)Reply[reply]
That's great, but you'd have seen it on your watchlist if it was added to the "References" section too, right? SnowFire (talk) 21:59, 15 August 2022 (UTC)Reply[reply]
I have also been fixing these as they come across my watchlist. Most take a minute or two of work. Often the tag signifies a permanently dead link, meaning that a new source must be found. I don't see this as materially different from a "more sources needed" tag, which would always go at the top of the page. BD2412 T 22:32, 15 August 2022 (UTC)Reply[reply]
Thanks, @BD2412. That's how I view it too.
Straightforward dead URLs are not too hard to deal with: a HTTP 404 or 410 response can be detected by tools and tagged wit {{dead link}}. In February & March this year I added that tag to bare URLs on about 80K articles.
At this stage, a high proportion of the remaining bare URLs are various forms of "dead": soft 404s, site usurped by one of the domain-reseller parasites, or requests time out, or DNS fails. It's very difficult to reliably detect many of those with tools, so most of them need manual attention ... which is why a prominent tag is so helpful, to encourage more editors to take that minute or two. BrownHairedGirl (talk) • (contribs) 22:49, 15 August 2022 (UTC)Reply[reply]
Re BHG: To be clear, let me state again that it's great you're doing this clean-up work. I don't think fixing citations is bad. I don't think adding this template is bad when they can't be fixed. However, there exist many problems which are important but only solvable by a very small subset of people - and further, we'd only even really want that small subset to do it. We don't post nuclear reactor safety procedures on highway billboards, because there is simply no expectation random passerby drivers will decide to drop everything and become atomic technicians. Learning the intricacies of the Wikipedia citation system is simply not something we expect most people to know - I would wager most editors (by number, not edit count) don't know it (the people who post on Village Pump are the hardest of the hardcore, we're not a good sample set here). Basically, even if we accept for a moment that this is of towering importance, merely being important doesn't have anything to do with the proper way to flag the problem, in the same way that important software bugs need to be filed against the devs who can do something about it, not to random readers. I will again my raise my example of errors in citation templates from misspelled parameters and the like. Serious question - if you were emperor of Wikipedia for a day, would you make it so that a bad citation template caused a warning seen by everyone, rather than just editors in preview mode? Because it seems like the exact same argument could be used to highlight this kind of problem. But it simply isn't important for readers, and editors can notice and fix it on their time.
On my earlier comment, let me be precise: when I say that bare URLs are no big deal, I mean that an edit that adds content with a bare URL is no big deal. Obviously, for Wikipedia-as-a-whole, it'd be good to fix it. But an individual contributor can contribute how they like or is convenient for them, and they shouldn't be shamed for it. The important thing is that it is an accurate reference as far as content - a simple URL or piece of text that's helpful is great, and a perfectly formatted citation that does not really reflect the source is a big problem. This edit added an extraordinarily vague text reference... but it was enough for me to find it, and confirm it was real, and format it all nicely (diff). The original edit that added this absolutely helped Wikipedia. It wasn't a "problem" or a big deal. That's what I'm saying. SnowFire (talk) 21:59, 15 August 2022 (UTC)Reply[reply]
@SnowFire: Thanks for your kind words. They are v much appreciated, because this year of bare URL filling an tagging has been lonely work, with far more angry outbursts directed at me than thanks or encouragement.
But we still disagree radically, over your comment there exist many problems which are important but only solvable by a very small subset of people.
I really really really hope that you are completely wrong about that, because adding decent refs is the core task of any content editor. If that really is the preserve of a tiny minority, we should all just give up pretending that this is an encyclopedia. BrownHairedGirl (talk) • (contribs) 22:37, 15 August 2022 (UTC)Reply[reply]

Searches by Guarapiranga[edit]

Funny, I got here searching for mentions of {{Cleanup bare URLs}} at WP:VPT (I don't usually come to WP:VPM), and didn't expect to find such a debacle about it. I'm one that takes great satisfaction in calling ref fix tools on pages that BrownHairedGirl tags for ref cleanup. I like first running BrandonXLF's fast and easy ReferenceExpander for basic expansion, then WP:REFILL, which is particularly good at eliminating duplicate refs, and finally WP:Citation bot for the finishing touches. I'm indifferent as to whether the tag should be up top or at the reference section; the important thing is that the article be included in the Category:All articles with bare URLs for citations. But the actual reason I came here is bc I think +63K pages is nowhere near enough (let alone 17K!)—I find over 657K articles with bare url refs—and wanted to go about mass tagging them all. — Guarapiranga  07:25, 16 August 2022 (UTC)Reply[reply]

I think that BHG is right when it comes to verifiability. If we call this effort useless just because some don't like it, it brings into question other policies. I agree the average Wikipedia reader might not care for it - so maybe make it so only editors can see the banner. But the general idea of bringing it to peoples attention is abosuletly necessary. Rlink2 (talk) 23:06, 16 August 2022 (UTC)Reply[reply]
  • For a year now, I have been working every day with regexes to identify bare URLs. It's a bit wearing to find someone coming to a discussion like this and repeatedly posting as fact nonsense data which they clearly have not even tested.[1]
    No need to get twisted about it, BrownHairedGirl; just best me. Care to share your estimates and regexes? I'm still getting over half a million untagged articles with bare url refs (regex times out).
  • Your revised search is still broken, because it is far too simplistic.
    For examples, your search will not recognise inline tagged bare URLs: <ref>http:/foobar.com/foo {{Bare URL inline|date=June 2022}}<ref>.[1]

    Right. How about 196 then?
  — Guarapiranga  04:31, 18 August 2022 (UTC)Reply[reply]
@Guarapiranga: the reason that I am annoyed is that three times you disrupted the discussion by asserting as fact figures which are wholly wrong, because they are based on crude assumptions which you did not test. That false data misleads other editors, and thereby disrupts consensus formation.
You could and should have struck out the false numbers, but you have chosen not to do so. Face-sad.svg
The reality is that any regex which matches all bare URLs will time out when run through the web interface. I get my definitive numbers from scanning the twice-monthly WP:Database downloads, but the most recent of those was 17 days ago, on 20220801. Since then, huge progress has been made (>15,000 articles which then had untagged bare URLs no longer meet that criterion), so those numbers are way out of date.
Explaining this in full is quite involved, and it would take me about 30 minutes to write it up. Instead, I will give you a few quick pointers.
  • Regex search to match all bare URL refs: insource:/\<ref( [^\>]*)?\> *\[? *https?:\/\/[^ \<\>\{\}]+ *\]? *(\{\{bare *url[^\}]*\}\} *)?\<\/ref/i
    Note: it will timeout
  • Simplified regex search to match all untagged, unbracketed bare URL refs: insource:/\<ref( [^\>]*)?\>https?:\/\/[^ \<\>\{\}]+ *\<\/ref/i
    That will run, and currently gives 55,094 untagged, unbracketed bare URL refs (note that it includes commented-out bare URL refs, of which there are a few hundred). I use that regex many times per day to track progress.
  • Articles with inline-tagged bare URL refs: a Petscan search gives 51729 results
However, the two sets overlap significantly. Based on experience of the database scan, I estimate that the combined set of unique entries will be about 90,000 articles, +/- 5,000. I will have more accurate data when I have analysed the forthcoming 20220820 database dump; I should have generated numbers by 20220822.
But that estimate of ~95K remaining articles with one or more bare URLs is down from ~470K when I started work on this in May 2021. That's 80% fewer articles, and about 95% fewer bare URLs (because many articles had multiple bare URLs, but remain on the list until all bare URLs are removed).
Note that all these sets are rapidly changing, because:
  • New bare URLs are added at a rate of over 300 per day
  • Citation bot is filling bare URLs every day, and a new extra-thorough bare-URLs-only-mode has massively increased its productivity. In the last 24 hours alone, it has filled a few thousand bare URL refs.
  • My inline-tagging processes (e.g. User:BrownHairedGirl/No-reflinks websites) apply inline bare URL tags at a rate of over a hundred per day.
  • I personally fill or tag a few hundred bare URLs every day. Other editors also do great work on bare URLs.
As a result of all that ongoing work, my daily removal of redundant {{Cleanup bare URLs}} banners this morning (based on an overnight scan) removed 241 "Cleanup bare URLs" banners.
See also the history of User:BrownHairedGirl/Articles with new bare URL refs, which explains some of the regexes and numbers. The current version shows the progress on the 20220801 database dump. BrownHairedGirl (talk) • (contribs) 10:14, 18 August 2022 (UTC)Reply[reply]
@Guarapiranga, I clicked your regex search link, which you say finds 657K articles. I opened the first ten search results. Seven of them contained no bare URLs at all. (Also, it only found 488K for me.) But I want you to look at the results that you're finding: Psychology#cite note-18, Jews#cite note-105, and Renaissance#cite note-75. The refs say:
  • T.L. Brink. (2008) Psychology: A Student Friendly Approach. "Unit One: The Definition and History of Psychology." pp 9 [1] Archived 24 July 2012 at the Wayback Machine.
  • The people and the faith of the Bible by André Chouraqui, Univ of Massachusetts Press, 1975, p. 43 [1]
  • "Scientific Revolution" in Encarta. 2007. [1]
Do you know what those [1] links are? They are not bare URLs. From the first sentence of Wikipedia:Bare URLs: "A bare URL is a URL cited as a reference for some information in an article without any accompanying information about the linked page" (emphasis in the original). When the ref includes "accompanying information" like the author's name, the publication date, the publisher, etc. "about the linked page", that is not a bare URL. That's just a WP:CITEVAR situation, not a bare URL.
I mention this because I think you should either drop this entirely, or spend a while validating your claims. You started off claiming that 10% of all Wikipedia articles ("over 657K" out of our current total of 6.571 million articles) have bare URLs, but when people told you that you were wrong, you don't seem to have tried to check your estimates. For example, you could have clicked on Special:Random 10 or 20 times to see whether your results made any sense. You could have checked the pages in your search results, like I just did. You claimed 10% of articles might contain bare URLs; I'm telling you that 0% of the ones I checked in your list actually contain bare URLs, and only 30% of them even contained something that could have been mistaken for a bare URL. I can't tell you how to get a complete and accurate list, but I can tell join the chorus of people telling you that your original method is producing wildly inaccurate results. If you don't want to just wash your hands of the whole mess, then maybe ask for help at Wikipedia:Village pump (technical) or at Wikipedia:Request a query. WhatamIdoing (talk) 19:05, 18 August 2022 (UTC)Reply[reply]
  • When the ref includes "accompanying information" like the author's name, the publication date, the publisher, etc. "about the linked page", that is not a bare URL. That's just a WP:CITEVAR situation, not a bare URL.
    Right, I see. Indeed I was searching for refs without citation templates.
  • I clicked your regex search link, which you say finds 657K articles. I opened the first ten search results. Seven of them contained no bare URLs at all. (Also, it only found 488K for me.) But I want you to look at the results that you're finding
    So, tbh, I only looked at what the search function showed as detail under each result; I didn't verify each article (and the regex times out; it throws different numbers each time I run it, but they're all in the hundreds of thousands).
I still find +250K untagged articles with bare url refs, even after making some of the corrections BrownHairedGirl suggested above):
  • Islamic State [[Misogyny]]<ref>[https://www.theatlantic.com/international/archive/2017/09/isis-female-suicide-bomber/539172/ The Myth of the ISIS Female Suicide Bomber]</ref><ref>[https://www 299 KB (24,648 words) - 07:43, 11 August 2022
  • Taiwan Coordinates: 24°N 121°E / 24°N 121°E / 24; 121 Taiwan, officially the Republic of China (ROC), is a country in East Asia, at the junction of the East 294 KB (30,919 words) - 03:24, 16 August 2022
  • Napoleon little besides this untruth about him.<ref>[https://www.britannica.com/story/was-napoleon-short Was Napoleon Short?]</ref> At {{convert|5|ft|2|in|m|order=flip}} 226 KB (24,856 words) - 08:07, 17 August 2022
  • Brazil Coordinates: 10°S 52°W / 10°S 52°W / -10; -52 Brazil (Portuguese: Brasil; Brazilian Portuguese: [bɾaˈziw]), officially the Federative Republic of Brazil 258 KB (23,699 words) - 02:47, 16 August 2022
  • Panama Papers and Josh Baazov.<ref>[https://joshbaazov.ca/how-josh-baazov-made-of-david-a-criminal-jonah/ The Criminal Story Of Josh Baazov | AMF]</ref> While offshore 157 KB (14,246 words) - 10:13, 17 August 2022
  • Colombia [[beef]] and [[chicken meat]]. <ref>[http://www.fao.org/faostat/en/#data/QCL/ Agriculture and Livestock in Colombia, by FAO]</ref><ref>[https://revistacafeicultura 243 KB (20,507 words) - 12:20, 10 August 2022
  • Wales 1981.<ref name=":03">[http://www.statistics.gov.uk/CCI/nugget.asp?ID=445 Results of the 2001 Census: Country of birth (www.statistics.gov.uk)]</ref> The 213 KB (21,290 words) - 11:55, 17 August 2022
  • Amazon Prime Video Amazon Prime Video, or simply Prime Video, is an American subscription video on-demand over-the-top streaming and rental service of Amazon offered as a 46 KB (4,001 words) - 17:05, 4 August 2022
  • Lyndon B. Johnson Lyndon Baines Johnson (/ˈlɪndən ˈbeɪnz/; August 27, 1908 – January 22, 1973), often referred to by his initials LBJ, was an American politician who served 197 KB (23,239 words) - 14:05, 15 August 2022
  • Papua New Guinea infrastructure.<ref>[http://www.inapng.com/pdf_files/Private%20Sector%20Report%20Final%2012Feb.pdf] Institute of National Affairs (2013)</ref> === Land tenure 115 KB (11,697 words) - 10:52, 12 August 2022
  • Genghis Khan Mongols.<ref name="guide">[http://www.travelchinaguide.com/intro/history/yuan/index.htm Yuan Dynasty: Ancient China Dynasties, paragraph 3.]</ref>{{failed 111 KB (12,814 words) - 18:23, 13 August 2022
  • Gibraltar --number only--> | HDI_ref = <ref>[https://en.populationdata.net/rankings/hdi/] Rankings – Human Development Index (HDI)</ref> | HDI_rank = 3rd | currency 119 KB (11,430 words) - 10:05, 14 August 2022
  • Assumption of Mary up to heaven.<ref>[http://www.ewtn.com/faith/teachings/maryc3c.htm] ''More on the Assumption of Mary'' by Fr. William Saunders, EWTN</ref>}} ==History== 46 KB (4,970 words) - 07:55, 17 August 2022
  • Zeus Hecalesius and [[Hecale]].<ref>[https://www.perseus.tufts.edu/hopper/text?doc=Perseus:text:2008.01.0067:chapter=14 Plutarch, Theseus, 14]</ref> *'''Hetareios''' 162 KB (14,263 words) - 05:14, 15 August 2022
  • Irish people | ref9 = <ref>[http://www.europeanirish.com/germany/an estimated 35,000-more than 1 million enjoy Irish culture]</ref> | region10 93 KB (9,555 words) - 13:24, 14 August 2022
  • Shopping mall A shopping mall (or simply mall) is a North American term for a large indoor shopping center, usually anchored by department stores. The term "mall" originally 83 KB (5,791 words) - 08:03, 13 August 2022
  • Ashkenazi Jews Ashkenazi Jews (/ˌɑːʃkəˈnɑːzi, ˌæʃ-/ AHSH-kə-NAH-zee, ASH-; Hebrew: יְהוּדֵי אַשְׁכְּנַז, romanized: Yehudei Ashkenaz, lit. 'Jews of Germania'; Yiddish: 145 KB (17,056 words) - 06:02, 17 August 2022
  • Economy of India global supply of generics by volume.<ref name=":0">https://www.ibef.org/download/pharmaceuticals-jan-2019.pdf<br /></ref> The Indian pharmaceutical sector 251 KB (22,764 words) - 16:37, 14 August 2022
  • Java = 407| isbn = 9792624996}}</ref><ref>[https://books.google.ch/books?id=VNgUAAAAIAAJ&pg=PA237 Modern Times, p.237]</ref> According to Chinese record ''[[History 59 KB (6,179 words) - 03:56, 12 August 2022
  • Charles Dickens Charles John Huffam Dickens FRSA (/ˈdɪkɪnz/; 7 February 1812 – 9 June 1870) was an English writer and social critic. He created some of the world's best-known 171 KB (18,259 words) - 01:02, 18 August 2022
Are these not bare url refs either?
  • I don't understand the litigious and disputatious tone here. Quite WP:UNCIVIL. Yes, I know you and BrownHairedGirl work relentlessly at tagging and removing bare url refs. As I said above, I'm one that takes great satisfaction in calling ref fix tools on pages that BrownHairedGirl tags for ref cleanup. Including your WP:Citation bot! WP:AGF, pls. I didn't intend to make any claims; just reporting what I'm finding. I'm just trying to help (but it sounds like you gals don't want any; WP:OWN much?).
Guarapiranga  01:44, 19 August 2022 (UTC)Reply[reply]
@Guarapiranga: if you want to help, then the first step would be to check whether any figures you assert are accurate.
You failed repeatedly to do that, and you have still not struck your false assertions, leaving them live to mislead other editors. Striking falsehoods would be a good way of demonstrating your good faith, which would be advisable before you throw accusations of incivility at others.
But instead you post yet another set of bogus numbers, from yet another broken search. Sigh. BrownHairedGirl (talk) • (contribs) 01:55, 19 August 2022 (UTC)Reply[reply]
  1. figures you assert are accurate.
    I didn't; it's just what I found. You corrected me, and I stand corrected.
  2. You failed repeatedly to do that
    Sure, trial and error. Isn't that the wp:cycle of life?
  3. you have still not struck your false assertions, leaving them live to mislead other editors.
    Editors following this discussion can see how we refined our estimates in the conversation.
  4. Striking falsehoods would be a good way of demonstrating your good faith
    I don't have to. If you believe I'm acting in bad faith, it is you have to demonstrate it. That's what WP:AGF means.
  5. you throw accusations of incivility at others.
    It's not an accusation; I'm not throwing anything; I'm simply asking to return to a wp:civil tone.
  6. But instead you post yet another set of bogus numbers, from yet another broken search.
    Happy to be corrected. And where's that? All this energy on wp:behavioural issues, and very little on the actual issue at hand (bare url refs). This time: none.
I sigh too. — Guarapiranga  04:19, 19 August 2022 (UTC)Reply[reply]
Based on the extracts in the produced table, the following do not appear to have bare URLs: Islamic State, Panama Papers, Wales, Papua New Guinea, Genghis Khan, Gibraltar, Assumption of Mary, Zeus, Irish people, Java. That is not to say that these are particularly good reference tags though, as several look like they need significant cleanup.
The following appear to have bare URLs; Napoleon, Economy of India
Additionally the following extracts appear to have no URLs or ref tags; Taiwan, Brazil, Amazon Prime Video, Lyndon B. Johnson, Shopping mall, Ashkenazi Jews, Charles Dickens.
That is not to rule out that any or all of these articles may have bare URLs within their citations, I am merely commenting on the extracts provided in the table. However if those articles do not have any bare URLs within, then based on those extracts, your search parameters appear to be faulty on multiple levels and are returning a lot of false positives. Sideswipe9th (talk) 02:13, 19 August 2022 (UTC)Reply[reply]
the following do not appear to have bare URLs: Islamic State, ...
Isn't that a bare url ref?
<ref>[https://www.theatlantic.com/international/archive/2017/09/isis-female-suicide-bomber/539172/ The Myth of the ISIS Female Suicide Bomber]</ref>
I just ran BrandonXLF's ReferenceExpander on that article, and it seemed to think it was, bc it expanded it. — Guarapiranga  03:56, 19 August 2022 (UTC)Reply[reply]
Same with
<ref>[https://joshbaazov.ca/how-josh-baazov-made-of-david-a-criminal-jonah/  The Criminal Story Of Josh Baazov | AMF]</ref>
in Panama Papers, which ReferenceExpander just expanded as well. — Guarapiranga  04:08, 19 August 2022 (UTC)Reply[reply]
Nope, as was previously explained by Whatamidoing per Wikipedia:Bare URLs these are not bare URLs, because they include accompanying information about the linked page. In this case, the accompany information is the article title. What ReferenceExpander has done is convert it from one WP:CITEVAR to a Citation Style 1 template. Bare URLs are citations like <ref>http://www.example.com</ref> or <ref>[http://www.example.com]</ref>, which contain a URL with no accompanying information.
These examples are insufficient citations, but that is for reasons other than a potential bare URL issue. Sideswipe9th (talk) 04:12, 19 August 2022 (UTC)Reply[reply]
(edit conflict) A bare URL is a URL cited as a reference for some information in an article without any accompanying information about the linked page - Wikipedia:Bare URLs. The fact that some tool runs on things that aren't bare URLs does not make them bare URLs. * Pppery * it has begun... 04:12, 19 August 2022 (UTC)Reply[reply]
One of the examples of bare url there is:
Some text [http://support.nikontech.com/app/answers/detail/a_id/14083 Nikon] more text
Isn't that the same? Or are you saying that by simply including <ref> tags, it is no longer bare? — Guarapiranga  04:31, 19 August 2022 (UTC)Reply[reply]
That example is explained in the page you quoted it from: the "text" provides only the name of the company, which is already present in the domain name of the URL itself.
I had a quick look at the first 10 in your list. Brazil#cite note-44 and Papua New Guinea#cite note-92 are IMO lousy, but I found no actual bare URLs in any of the 10 articles that I looked at.
Looking at your excerpts, I think the point that you're missing is that a link that contains the title of the source is not a bare URL.
This is checkY good enough: [https://www.example.com Title of Article]
This is ☒N a bare URL: [https://www.example.com]
If you were trying to identify the difference between the "good enough to not count as a bare URL" version and "it has a label but the label is just the website's name", you'd need to set up a regex that finds [https://www.example.com Example] and subsets such as [https://www.example.com Exam] and [https://www.example.com Exam Ple] but not [https://www.example.com Any other string]or [https://www.example.com Any other string plus Exam or Example or Exam Ple].
You might try to focus on just one type of absolutely unambiguous, completely indisputable bare URL. Start with the easier stuff, and get that right first. WhatamIdoing (talk) 05:27, 19 August 2022 (UTC)Reply[reply]

Analysis of new articles[edit]

I looked at the last 10 articles in Special:NewPagesFeed (an easy way to get a random sampling of articles by random editors):

  1. Krapopolis has properly formatted refs
  2. Shelley, Victoria has no refs at all
  3. Draft:Killing of Christian Obumseli has non-bare, but incompletely filled, refs
  4. Karambalangan has properly formatted refs
  5. 2022–23 Xavier Musketeers men's basketball team has non-bare, but incompletely filled, refs
  6. Alternative Mitte has properly formatted refs, although it also has a bunch of "Cite error: reference named X was invoked but never defined".
  7. Club Leoncio Prado has a non-bare, but incompletely filled, ref.
  8. Mamma, 'k wil 'n man hê has no refs at all
  9. List of countries by net reproduction rate has properly formatted refs.
  10. Justin Garza High School has properly formatted refs.

So, overall, 5 articles with properly formatted refs, two with none at all, and three with incompletely filled refs (and no bare URLs, although I certainly have seen bare URLs at New Page Patrol elsewhere). Each of these was created by a different editor. I'd say that refutes SnowFire's claim.

While I was composing this comment, Anne-Sophie Lavoine was created with bare URLs. But it's still the case that from that sample that most editors can fill refs properly. * Pppery * it has begun... 22:50, 15 August 2022 (UTC)Reply[reply]

Re * Pppery * and "this refutes SnowFire's claim": first off, let's not get distracted on a side matter. The exact proportion isn't really that important and it doesn't solve the other issues I brought up, most pertinently that of the reader experience (e.g. articles with no active editors whatsoever, but that has readers who are warned that 1 of the 20 references is a bare URL). But if we're going to discuss it - no, it doesn't refute it. You're saying that 3/8 of the articles with references don't have properly formatted citations. That is a huge amount. Even if a larger sample size shows it's less, say 20%, that is still a gigantic amount! Remember, we are hypothetically talking about informing editors who A) view a page, but B) don't have this page already watchlisted. Many of these will be people who edit very rarely and don't show up in new page patrol anyway, because IP editors can't create new articles directly. So we're talking about the least active of active editors (in the sense of people, not accounts). Surely, surely you've run into such editors who clearly aren't that familiar with Wikipedia and stop by for the occasional edit. These editors are unlikely to fix a bare URLs cleanup request, whether they're 20% or 50% or some other amount of the total editor base. The editors who will fix it are hardcore editors who have the article on their watchlist, and they'll see the notification regardless of where it's placed, on top, in references, even if it was placed on the talk page. SnowFire (talk) 00:20, 16 August 2022 (UTC)Reply[reply]
@SnowFire, I don't agree with your analysis of incidence, but let's set the numbers aside for mo.
It seems to me that you are asking for those editors who are unaware of a problem with their edits to be shielded from notices which show them that bare URLs are a problem.
And that seems to me to be the precise opposite of that we should be doing. Obviously, we should not be rude or hostile, but a polite and non-personal notice warning of a problem on a page attributes no blame and is no way the "shaming" which you referred to above. BrownHairedGirl (talk) • (contribs) 00:29, 16 August 2022 (UTC)Reply[reply]

You consider the addition of bare URLs a problem, BrownHairedGirl. I consider their addition a valuable contribution. The encyclopedia has survived very long without so severely increasing the visibility of bare URLs. Nothing in your work requires a topside banner. All in all, I think your chosen approach is overly confrontative. CapnZapp (talk) 17:47, 16 August 2022 (UTC)Reply[reply]

Conduct allegations[edit]

So to the point at hand about this good work. Should we move the non reader warning out of the lead and to the ref section. Not one person here has claim this work is a problem.....but accessibility and reader retention is the concerned raised about Banner placement. Wonderful to see the work being done.....just the approach could have some amendment to it .Moxy-Maple Leaf (Pantone).svg 22:55, 15 August 2022 (UTC)Reply[reply]
Sigh. That is a bare-faced lie by @Moxy, in their assertion that not one person here has claim this work is a problem.
On the contrary, Moxy opened[2] this discussion with a headline complaint that it is Mass spamming, and used that same phrase in the first para.
And in their discussion on their talk, Moxy called tagging mass bare URLs simply crazy.
I don't see why we should tolerate having any discussion polluted by an editor who brazenly lies about their conduct.
If Moxy has changed their mind and recognised the value of this work, then they should says so. BrownHairedGirl (talk) • (contribs) 23:10, 15 August 2022 (UTC)Reply[reply]
It is crazy to add thousands of these to the top of articles like a bot. Working of fixing refs is great....but banner spam is a problem....as outlined by a few here. Moxy-Maple Leaf (Pantone).svg 23:16, 15 August 2022 (UTC)Reply[reply]
Yet again, @Moxy's reply is simply to insult my work as crazy, instead of explaining in civil terms why they think that it is a problem.
And of course, Moxy makes no effort to retract their lies. Instead they try to limit their use of the word crazy to the top of articles. But in March, on their talk, Moxy used the phrase simply crazy to describe my addition of the inline tag {{Bare URL PDF}}.
Other editors are discussing this with reasoned civility, and without denying their own stance. Please, Moxy, either stop lying and stop insulting ... or leave this discussion. BrownHairedGirl (talk) • (contribs) 23:27, 15 August 2022 (UTC)Reply[reply]
Never said anything personal about you here. More then willing to leave the talk to others as its clear you can't communicate normally with me.... it's a long standing problem with me and others. Good luck..... hoping that we favor reader retention and accessibility as the outcome over this. Moxy-Maple Leaf (Pantone).svg 23:37, 15 August 2022 (UTC)Reply[reply]
@Moxy: you have lied repeatedly, and now you lie again, by denying that calling an editor's work crazy is a personal attack.
If you regard that sort of conduct as normal, then god help us. BrownHairedGirl (talk) • (contribs) 00:04, 16 August 2022 (UTC)Reply[reply]
Jesus have you seen the above. 204.237.48.146 (talk) 01:40, 17 August 2022 (UTC)Reply[reply]

Bot request process[edit]

One thing that's clear is if this is being added in a bot-like manner, this is covered by WP:MEATBOT. If the mass addition of bare URL banners are considered desirable, the community should consider having an actual bot handle things and have all the benefits this entails. Headbomb {t · c · p · b} 23:41, 15 August 2022 (UTC)Reply[reply]

@Headbomb: a bot might be desirable in theory, but it is unlikely in practice, since WP:BRFA is so massively dysfunctional.
My last BRFA was for a bot to remove {{Cleanup Bare URLs}} banner when it was no longer needed. That BRFA derailed by your extreme aggression, abuses of process and repeated counter-factual assertions. It was a hideous, horrible experience, and after that I decided not to open a BRFA again. Instead, I took the code that I had written, modified it slightly, and have been running it repeatedly for 8 months without a single objection from anyone.
If BRFA can be reformed to be more responsive (it's horribly laggy) and to exclude your appalling conduct, then I will consider a BRFA for this task. But I have had two very unpleasant experiences in which BAG members have just piled on to endorse your aggressive misjudgements. BrownHairedGirl (talk) • (contribs) 00:01, 16 August 2022 (UTC)Reply[reply]
Funny how everyone is wrong and that you get no single issues except multiple comments on your talk page and elsewhere asking you to stop, and the community asking for alternatives to what you're doing. There was no abuse of process, you just decided not to comply with the requirement for bots because you didn't agree with them. You had your review, which concluded with

The discussion seems to be going round in circles a bit. To summarise: 5 BAG members have now reviewed the situation, along with other community members, and those opining on the issue overall seem to support the declining BAG member's rationale. Feedback has been provided on how a future bot request could be modified to address the concerns and gain approval. BHG's 14:56, 23 December 2021 comment indicates to me she understands what these steps are, even if she doesn't agree with them. Alternatively, an editor can put the question to the community via RFC. If the community decides the bot task is acceptable as-is, without any modifications, then the bot request can be looked at again. ProcrastinatingReader (talk) 20:47, 23 December 2021 (UTC)

If you don't want to code such a bot for whatever reason, then you can always make a WP:BOTREQ and let someone else handle it.
Headbomb {t · c · p · b} 00:08, 16 August 2022 (UTC)Reply[reply]
On the contrary, @Headbomb, the problem was simply that you read the bot's purpose literally, and missed the key point that the purpose of the bot was to remove the {{Cleanup Bare URLs}} banner from pages where it was no longer needed.
You throw a massive wobbly over the code ignoring refs which have already been tagged as inappropriate, as if there was some purpose in retaining a big banner asking editors to fill refs where the required action is to remove or replace them. And the rest of BAG weighed in behind you, which looks like a very unfortunate episode of groupthink.
And yes, there was abuse of process. After I had asked for input from other BAG members, you kept on piling on, and you made counterfactual assertions which you failed to retract, and then you closed the BRFA before other BAG members could offer input. That, my friend, is multiple abuses of process.
And the aftermath is that in the last 8 months I have made well over 10,000 edits using a slightly-modified version of that code, with lots and lots of thanks notifications from editors, and not a singe complaint. So no, I will not take that back for another hazing at BRFA.
If you want to open an RFC, then feel free to do so. But I think that 8 months of objection-free removal of redundant {{Cleanup Bare URLs}} banners is good evidence that the community does not endorse your view. BrownHairedGirl (talk) • (contribs) 00:22, 16 August 2022 (UTC)Reply[reply]
"that the purpose of the bot was to remove the {{Cleanup Bare URLs}} banner from pages where it was no longer needed"
Indeed. And your bot would have removed the tag from pages where it was still needed (i.e. pages with bare urls remaining), and therefore was declined because it failed to behave in line with its purpose. You may disagree with it, but you haven't shown that the behaviour you're seeking (the removal of cleanup tags from pages with bare URLs tagged with other cleanup issues) has consensus, and so the bot remained unapproved.
As mentioned several times, you could at any time have made an RFC demonstrating consensus for your bot's proposed behaviour, or modify the bot to behave as one would expect. You haven't, so here we are. Headbomb {t · c · p · b} 00:30, 16 August 2022 (UTC)Reply[reply]
And where we are is that after 8 months of use and over 10,000 edits there has bot been a single objection to my AWB job.
Nobody at all, not even one person, has commented to me that we should retain at the top of an article a big banner about filling bare URLs which should actually be replaced or removed. Nobody. Nada. Zilch.
And even after 8 months, it seems that you still do not comprehend that simple issue. Which is one of the reasons why I am bot going back to BAG to face more such absurdities. BrownHairedGirl (talk) • (contribs) 00:38, 16 August 2022 (UTC)Reply[reply]
PS just to clarify: I don't want to code such a bot for the simple reason that it would be superfluous to the AWB job which I have been running for 8 months since my BOTREQ was hazed out, with zero objections.
And I also do not want to make a BOTREQ, because I see no purpose in your vision of a hobbled bot doing a subset of tasks which are already in hand. BrownHairedGirl (talk) • (contribs) 00:33, 16 August 2022 (UTC)Reply[reply]
PS @Headbomb: if you still cling to your view, then please you go open that RFC you talk of.
The RFC question is simple: "Should we retain at the top of an article a big banner about filling bare URL refs which have already been tagged as unsuitable, and which should therefore be replaced or removed".
Lemme know how you get on. BrownHairedGirl (talk) • (contribs) 00:45, 16 August 2022 (UTC)Reply[reply]
Fine, you want an RFC, I'll give you an RFC. Headbomb {t · c · p · b} 00:59, 16 August 2022 (UTC)Reply[reply]
But not on the topic where I challenged you. The TFC below looks time very much like you playing games out of revenge, because you lack the confidence to ask for community input input on the stance which I did suggest you hold an RFC.
Instead, you open another RFC with a loaded question in which you don't even acknowledge the reason why I have not opened an RFC for adding the banner tags. Very poor conduct, Headbomb, BrownHairedGirl (talk) • (contribs) 01:07, 16 August 2022 (UTC)Reply[reply]
I agree an RfC on "Where should the Cleanup bare URLs template be placed? 1. At the top of the page (current practice) 2. At the top of the references" would be better than the offerings below. If people want we can have a "3. Template should be depreciated" but I don't see anyone advocating for that in this discussion. Best, Barkeep49 (talk) 01:10, 16 August 2022 (UTC)Reply[reply]
@Barkeep49: such an RFC might have some merit, but it's going to cause overload if this page also contains Headbomb's two disruptive revenge-RFCs. BrownHairedGirl (talk) • (contribs) 01:26, 16 August 2022 (UTC)Reply[reply]
There is a reason I suggested it instead of the two RfCs below. It's a question in one of the RfCs but I'm not sure how much actionable feedback we'll get for a close. Best, Barkeep49 (talk) 02:01, 16 August 2022 (UTC)Reply[reply]

Alternate technical solution possibilities? Requesting input[edit]

Alternate technical solution possibilities? Requesting input @ Wikipedia:Village pump (technical)#Color differentiation in reference numbering

Thanks

Bookku, 'Encyclopedias = expanding information & knowledge' (talk) 04:18, 16 August 2022 (UTC)Reply[reply]

@Bookku: this an accessibility issue. See MOS:COLOR: "Ensure that color is not the only method used to communicate important information".
So the use of color in problematic refs may be an a helpful addition (if technically possible; I can see some difficulties), but it cannot replace textual notifications. BrownHairedGirl (talk) • (contribs) 04:57, 16 August 2022 (UTC)Reply[reply]

RFC: Should the mass ADDITION of Cleanup bare URLs be done by bots or meatbots?[edit]

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Speedy close Upon reviewing this RfC, the related one below, and the related talk sections above, it seems unlikely that there could be any valid consensus outcome based on the question asked. That is not to say of course that consensus could not be found around a different question, and further discussion is encouraged along those lines.


I realise that this is a controversial speedy close, and I gladly welcome any comments, challenges, or requests for clarification at my talk page as a result. (non-admin closure) Sideswipe9th (talk) 03:50, 18 August 2022 (UTC)Reply[reply]


There are two questions.

  1. Should the mass ADDITION of {{Cleanup bare URLs}} be done by bots or meatbots?
  2. At what location in articles should these be added? At the top of the page, or in the reference section?

Headbomb {t · c · p · b} 01:01, 16 August 2022 (UTC)Reply[reply]

Discussion (mass addition of Cleanup bare URLs)[edit]

  1. It would be highly preferable to do this by bot IMO. Additionally, these should be at the top of the page since you can have bare URLS in many place other than reference sections. These bare URLs could be in a further reading section, external links section, in the main text, or anywhere else. Headbomb {t · c · p · b} 01:14, 16 August 2022 (UTC)Reply[reply]
  • Speedy close this blatantly bad faith RFC. This is a deliberately disruptive exercise, opened as revenge for the fact that I explained above to Headbomb how his objection to removal had no support, and how his aggressively process-abusing closure of WP:BHGbot 9 had not prevented me from removing redundant banners from over ten thousand articles over the last 8 months, without a single objection from anyone. --BrownHairedGirl (talk) • (contribs) 01:24, 16 August 2022 (UTC)Reply[reply]
    I rather tire of these WP:ABF accusations. You wanted an RFC, I gave you one. There is no 'revenge'. The wording is neutral, and covers all relevant issues. Headbomb {t · c · p · b} 01:26, 16 August 2022 (UTC)Reply[reply]
    @Headbomb: your bad faith is as plain as a very plain thing.
    This is just an exercise in wasting my time, motivated by revenge. BrownHairedGirl (talk) • (contribs) 01:29, 16 August 2022 (UTC)Reply[reply]
    Listen to yourself for a second. Revenge? For what? For doing cleanup work? For wanting clear guidance on an issue where there is disagreement? For wanting a productive path forward? Again, read what you wrote in light of WP:AGF. Headbomb {t · c · p · b} 01:32, 16 August 2022 (UTC)Reply[reply]
    No, you listen to yourself.
    This is transparent revenge for the fact I explained to you how your tantrums and process abuse at BRFA did not prevent me from doing valuable and uncontroversial cleanup work by ignoring your absurdist demands. BrownHairedGirl (talk) • (contribs) 01:38, 16 August 2022 (UTC)Reply[reply]
  • Note that I suggested to Headbomb that they open an RFC on the substantive issue in his dispute with me: "Should we retain at the top of an article a big banner about filling bare URL refs which have already been tagged as unsuitable, and which should therefore be replaced or removed".
    Sadly, Headbomb has chosen not to ask this question, and also makes no attempt to explain tye reasominh for his demand that editors should be faced with a big banner asking them to fill a bare URL ref which actually be removed or replaced.
    This reminds me of the Kerryman joke about the Kerryman who wrote a book which was so bad that the publisher rewrote it before binning it. Except that in this case, Headbomb is not joking: he genuinely wants editors to waste their time filling refs to unreliable sources ... which will then be removed.
    Why on earth would anyone demand that? ---BrownHairedGirl (talk) • (contribs) 01:50, 16 August 2022 (UTC)Reply[reply]
  • Already had a bot at Template:Cleanup_bare_URLs/bot which had BRFA approval. It was made for this reason: there are so many pages with bare URLs, adding banners automatically is too disruptive. So we came up with this tagbot solution. It worked well. However once the banners started being added at a mass rate, it broke the model. Tagbot will only run if there are less than 5 or so existing banners, they need to be fixed before new ones are added. That was the idea. Fix em before you add em. But with 60k+ unresolved banners, the tagbot model is rendered useless. -- GreenC 02:07, 16 August 2022 (UTC)Reply[reply]
    ... and the tagbot model didn't work. Template:Cleanup_bare_URLs/bot has 407 revisions, half of which are the bot setting the page to STOP and the other half of which are a human requesting a run. That means around 200 * 5 = 1000 pages with bare URLs have been tagged by GreenC bot. For comparison, BrownHairedGirl has filled thousands of pages with bare URLs in a matter of days or weeks. * Pppery * it has begun... 02:23, 16 August 2022 (UTC)Reply[reply]
    Probably because you can't run it if there are > 5 in the tracking cat so once things got too large no one could use it. -- GreenC 03:09, 16 August 2022 (UTC)Reply[reply]
    Not true. Tagbot ran from May 2019 to May 2021, which is about 2 years. It's been less than 2 years since tagbot last ran, so if BrownHairedGirl had not done bare URLs one can extrapolate and say tagbot would have run on at most another 1000 pages. That would not change my conclusion meaningfully. * Pppery * it has begun... 03:15, 16 August 2022 (UTC)Reply[reply]
    @GreenC, you are missing @Pppery's point. In all the months that Tagbot ran, before it was displaced by wider tagging, it identified only 1,000 bare URLs in need of filling.
    As Pppery has noted, I fill more than that on many individual days, and much more than that every week. And the wider tagging allows many more editors to see that an article's URLs need filling.
    As I wrote below, tagbot was an honourable effort done in good faith, but the whole concept of only ever tagging a tiny subset of the problem was misguided. BrownHairedGirl (talk) • (contribs) 03:17, 16 August 2022 (UTC)Reply[reply]
    Ok ok followed up below. (Tagbot was only as useful as people willing to use it, which was largely one person occasionally.) -- GreenC 03:35, 16 August 2022 (UTC)Reply[reply]
    Yes @GreenC, that's it. And if I had listened to that one person's sniping at me, the last year's progress on bare URLs would never have happened.
    Thankfully, because this place is not a bureaucracy, I was able to find other ways to get most of the job done. That's why I am annoyed by Headbomb's vengeful attempts here to tie me up in bureaucracy about issues which he doesn't understand, and which I have learnt over the last year are rarely understood by editors who have not actually worked on these issues at scale. BrownHairedGirl (talk) • (contribs) 03:54, 16 August 2022 (UTC)Reply[reply]
    @GreenC: there are not 60,000 banners. After my latest addition of a batch of 14,700 banners in thye last few days, there are about 18,000 banners. The other articles in Category:All articles with bare URLs for citations are there because of inline tags, e.g, {{Bare URL inline}} and {{Bare URL PDF}}
    Tagbot was made for a very different purpose, in a very different context.
    When Tagbot last ran, there were about 470,000 articles with bare URLs. Now, after a year of intensive cleanup by me, there are about ~100K. Many of the remaining articles with bare URLs have had one more URLs either filled or tagged as dead, so the actual progress is much greater than the article count implies.
    Tagbot was an honourable idea, but it was fundamentally flawed. It was designed to serve the needs of a small group of editors who worked slowly to fill a few bare URLs per day, and basically it just used tags to give that wee group a job list. Their work was of course valuable, but it was on far too small a scale to even keep up with the flood of new bare URLs, let alone dent the backlog. The problem was steadily getting worse. Evert day, new bare URLs were being added about ten times faster than others were filled.
    That is why I set about a different approach. After some trial and error, the method I developed was fourfold:
    1. Feed endless streams of huge lists to Citation bot to fill as many refs as possible
    2. apply inline tags where they would not impede other tool: i.e. non-HTML pages, and those which cannot be filled by WP:ReFill (see User:BrownHairedGirl/No-reflinks_websites)
    3. Develop other tools to identify dead links, and tag them with {{dead link}}.
    4. Identify sets of URLs which I could easily fill manually, and work on them.
    After a year of this. my approach has been a proven success. We now have ~90% fewer bare URLs than a year ago, and the widespread inline tagging of bare URLs helps any editors to identify bare URLs in articles within their interest. The small group of pioneers can still do their work, but now far more editors can find articles with bare URLs.
    Until the start of August 2022, I refrained fro systematically adding the {{Cleanup bare URLs}} banner, because some editors find it too intrusive. However, by this month the reduced bare URL count a massive increase in the capacity of Citation bot allowed me to do multiple passes of lists each month. Until May, I could not in any one month get Citation bot to process the full list of articles with HTML-format bare URLs, but after the upgrade I made a lot more progress and was able to process not just the whole set, but to do multiple passes on big lists.
    In July, I took my list of new bare URLs and processed the set 10 times (see User:BrownHairedGirl/Articles with new bare URL refs), until Citation bot could do no more. After some thought, I reckoned that we are now into the mopping-up phase of bare URLs, where manual input is needed: so I then applied the {{Cleanup Bare URLs}} banner to the articles in that set which still had one or more untagged bare URL refs (there were about 1150 articles remaining from July's two database dumps). I did not use the {{Bare URL inline}} tag, because that would prevent the use of WP:REFILL.
    Then I did the same thing with the new bare URLs from the 20220801 database dump. And when that was done, I made a list of 20,000 randomly-selected articles with bare URLs, and I got Citation bot to process that whole set 7 times.
    After those 7 passes by Citation bot (plus any other work on the set), that left 14,700 articles in the set which still had one or ore bare URLs. That's the set which I have just finished tagging.
    Please please let's not go back to the bad old days when most bare URLs were untagged and uncategorised, and where bare URL cleanup was the preserve of a small and formal group as the problem grew bigger and bigger.
    And please please, don't tie my work down in bureaucracy. WP:NOTBURO, and my approach is delivering results. Headbomb has twice abused BRFA as a hazing process against me, and I don't want my work to again be impeded by bureaucracy. BrownHairedGirl (talk) • (contribs) 03:02, 16 August 2022 (UTC)Reply[reply]
    Sounds right, the volume of incoming bare URLs was larger than tagbot users were willing or able to keep up with. Maybe tagbot could be done a different way, would have to think about it. Your method of breaking the problem down into steps using various tools seems to be working for you. At some point you got all the low+medium hanging fruit and whatever left is a hard problem. The 80/20 Rule, I guess somewhere around 20% remaining? Generally Wikipedia follows the 80/20 Rule. The last 20% is harder than the first 80%. So we banner the 20%. I think that's important to understand this is the final step representing the hard cases. -- GreenC 03:31, 16 August 2022 (UTC)Reply[reply]
    Thanks, @GreenC. I think we are on the same page now. Face-smile.svg
    Depending on whether we count bare URLs or articles with bare URLs, we either 95% done or 80% done. But either way, we are at the hard cases stage, where Citation bot's efforts now consist mostly of long waits for HTTP requests which timeout after a 45 second limit. (See User_talk:BrownHairedGirl#Zotero_only, where I talk to @AManWithNoPlan about his wonderful work in developing a bare-URLs-only mode which I suggested for Citation bot. That man's work is brilliant, and he deserves heaps more praise than he gets!)
    So yes, this is tagging the hard cases. BrownHairedGirl (talk) • (contribs) 03:45, 16 August 2022 (UTC)Reply[reply]
    Headbomb has twice abused BRFA as a hazing process against me
    This is an utterly ridiculous and incorrect claim, and I would ask that you stop making it. There was unanimous agreement in the review that my closure was correct. Headbomb {t · c · p · b} 08:03, 16 August 2022 (UTC)Reply[reply]
  1. Yes, absolutely. I find over +640K articles with bare url refs without the tag.
  2. Top, but only to editors, not readers. There's a lot of things that shouldn't be shown to readers; redlinks for a start (but I digress).
Guarapiranga  08:08, 16 August 2022 (UTC)Reply[reply]
Utter nonsense, @Guarapiranga. There are not 640K articles with bare URLs, and AFAIK there never has been.
You got that nonsense number because your search is broken: it wrongly assumes that bare URLs (and only bare URLs) are wrapped in square brackets, e.g. [http://example.com/foo].
Neither assumption is true: almost zero bare URL refs use square brackets; and most refs which do use square brackets are filled, e.g. [http://examplew.com/balagan Balagan Today]
You might have spotted your error if you had checked your search results. For example, the first result in your broken search is [[Midfielder], which has no bare URL refs. BrownHairedGirl (talk) • (contribs) 11:20, 16 August 2022 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RFC: Should the mass REMOVAL of Cleanup bare URLs be done by bots or meatbots?[edit]

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Speedy close Upon reviewing this RfC, the related one above, and the related talk sections above, it seems unlikely that there could be any valid consensus outcome based on the question asked. That is not to say of course that consensus could not be found around a different question, and further discussion is encouraged along those lines.


I realise that this is a controversial speedy close, and I gladly welcome any comments, challenges, or requests for clarification at my talk page as a result. (non-admin closure) Sideswipe9th (talk) 03:50, 18 August 2022 (UTC)Reply[reply]


There are two questions.

  1. Should the mass REMOVAL of {{Cleanup bare URLs}} be done by bots or meatbots?
  2. Should bare URLs tagged with issues, like <ref>https://example.com {{deadlink}}</ref> be ignored in this mass removal? Meaning that the {{Cleanup bare URLs}} tag would be removed in those cases.

Headbomb {t · c · p · b} 01:04, 16 August 2022 (UTC)Reply[reply]

Discussion (mass removal of Cleanup bare URLs)[edit]

  1. It would be highly preferable to do this by bot IMO. I don't have any real objection to having this done semi-automatically, but in all cases the removal should only be done when all bare URLs have been taken care off. Headbomb {t · c · p · b} 01:15, 16 August 2022 (UTC)Reply[reply]
(edit conflict × 3)
  1. I have, in one case (List of Polish mathematicians), seen {{cleanup bare URLs}} from an article that did in fact contain bare URLs. But some sort of automated process should do this anyway, since (a) bare URLs are often filled in using bots/scripts (b) confirming an article does in fact contain bare URLs is tedious work when done manually. (c) I'm not seeing any real harm this bot task causes. I don't really care whether this is a bot or a meatbot.
  2. Yes at least in the case of {{dead link}}, as the dead link tag effectively supersedes the bare URL tag since as one cannot fill in a dead link any further. For other maintenance tags such as {{user-generated source}}, the case is less clear, and I have no strong position.
* Pppery * it has begun... 01:17, 16 August 2022 (UTC)Reply[reply]
as the dead link tag effectively supersedes the bare URL tag since as one cannot fill in a dead link any further You can certainly fill dead links further. I do so routinely. For example
can be fixed to
  • Torres, Ricardo (December 11, 2002). "Panzer Dragoon Orta Preview". GameSpot. Archived from the original on 2022-05-05. Retrieved May 22, 2022.
This also would apply to non-dead links like
Headbomb {t · c · p · b} 01:23, 16 August 2022 (UTC)Reply[reply]
This is absurdist nonsense:
  1. A dead link cannot be filled. How hard is that to understand?
  2. A dead link may be rescued by a link to an archive. If that archive link is bare, the ref can be filled ... but until and until it is rescued, it cannot be filled.
  3. For the love of al that is highly, what on earth is the pint of retaining at the top of an article a big banner asking editors to fill a ref to a URL which has already been identified as unreliable source?
Why is my work being disrupted by such utter folly? BrownHairedGirl (talk) • (contribs) 01:34, 16 August 2022 (UTC)Reply[reply]
A dead link cannot be filled.
See above for how it can be filled. See also below for why bots cannot assume that links tagged by maintenance tags need to be removed. Headbomb {t · c · p · b} 08:04, 16 August 2022 (UTC)Reply[reply]
Yet again, @Headbomb, your stubbornness blinds you the details. So you are wrong, and yet again you are doubling down on your wrongness.
Those details have already been explained to you, but I will repeat:
  1. A dead link bare URL ref cannot be filled, because no info is available with which to fill it
  2. If an archived copy is found, that archived copy is not dead and cannot be filled.
So, the response to a dead link bare URL is to try to find that archived copy. Unless and until that archived copy is found, it is pointless asking editors to fill the ref. The {{Dead link}} tag is sufficient. BrownHairedGirl (talk) • (contribs) 11:13, 16 August 2022 (UTC)Reply[reply]
A dead link bare URL ref cannot be filled, because no info is available with which to fill it
Which is demonstrably wrong, as evidenced above. Headbomb {t · c · p · b} 12:01, 16 August 2022 (UTC)Reply[reply]
No, @Headbomb. I am right, and you are wrong again
This is very very simple.
A dead link cannot be filled.
An archived copy of a dead link can be filled.
You are unable or unwilling to understand that crucial distinction, and your stubbornness is turning into disruptive timewastasting. BrownHairedGirl (talk) • (contribs) 12:20, 16 August 2022 (UTC)Reply[reply]
It can sometimes be filled, but it's a two-stage process. Sometimes organisations will restructure their website so that all the old links either take you to the website's main page, to a generic landing page, or fail entirely. Stage 1 is to identify where the page has gone to; as an example, consider http://curvebank.calstatela.edu/newmath/newmath.htm - clicking that link actually takes you to http://web.calstatela.edu/curvebank/ - a landing page. Acting on the advice there, and using the search facility at nationalcurvebank.org, yields http://old.nationalcurvebank.org/newmath/newmath.htm with which I was able to make this edit. If that dead URL had been inside ref tags, stage 2 would have been to fill it in with title, author, date etc. --Redrose64 🌹 (talk) 14:32, 16 August 2022 (UTC)Reply[reply]
  • Speedy close this blatantly bad faith RFC. This is a deliberately disruptive exercise, opened as revenge for the fact that I explained above to Headbomb how his objection to removal had no support, and how his aggressively process-abusing closure of WP:BHGbot 9 had not prevented me from removing redundant banners from over ten thousand articles over the last 8 months, without a single objection from anyone. --BrownHairedGirl (talk) • (contribs) 01:23, 16 August 2022 (UTC)Reply[reply]
    Same as above. Headbomb {t · c · p · b} 01:27, 16 August 2022 (UTC)Reply[reply]
    @Headbomb: your bad faith is as plain as a very plain thing.
    This is just an exercise in wasting my time, motivated by revenge. BrownHairedGirl (talk) • (contribs) 01:29, 16 August 2022 (UTC)Reply[reply]
  • Note that I suggested to Headbomb that they open an RFC on the substantive issue in his dispute with me: "Should we retain at the top of an article a big banner about filling bare URL refs which have already been tagged as unsuitable, and which should therefore be replaced or removed".
    Sadly, Headbomb has chosen not to ask this question, and also makes no attempt to explain tye reasominh for his demand that editors should be faced with a big banner asking them to fill a bare URL ref which actually be removed or replaced.
    This reminds me of the Kerryman joke about the Kerryman who wrote a book which was so bad that the publisher rewrote it before binning it. Except that in this case, Headbomb is not joking: he genuinely wants editors to waste their time filling refs to unreliable sources ... which will then be removed.
    Why on earth would anyone demand that? --BrownHairedGirl (talk) • (contribs) 01:52, 16 August 2022 (UTC)Reply[reply]
    Because bots are dumb, and cannot determine if a source is reliable or not, nor if it should be removed or not. This is something that requires human review. If there are bare URLs remaining, the bare URL tag should remain. That's a rather simple thing to understand. Headbomb {t · c · p · b} 02:44, 16 August 2022 (UTC)Reply[reply]
    @Headbomb: it seems that not only bots are dumb.
    Bots do not determine whether a source is reliable or not. Those tags are added manually by humans.
    My approach to those tags is to respect the judgement made by those human editors. The Headbomb approach is to disregard those judgements, and to ask human editors to devote some of their limited time on this earth to filling a ref which another human has assessed as unreliable, and to fill the ref even if they agree that it is unreliable. That is a spectacularly dumb stance, and it is a sad reflection of BAG's tendency to herd-like groupthink that several other BAG members supported this spectacularly dumb stance. BrownHairedGirl (talk) • (contribs) 03:09, 16 August 2022 (UTC)Reply[reply]
    "Those tags are added manually by humans." And humans can be wrong for a plethora of reason. Some random person can add, in good faith, [unreliable source?] to anything. That doesn't make the source reliable, or even improperly cited. Bots cannot determine that context, and cannot assume that just because there is some sort of maintenance tag, that the correct outcome is the removal of the source. Headbomb {t · c · p · b} 08:00, 16 August 2022 (UTC)Reply[reply]
    Again, @Headbomb, your binary logic and refusal to listen blinds you to the simple explanations offered by an editor who has worked on this stuff every day for a year.
    Consider these two examples:
    1. Article1 has one bare ref: a ref to a flaky blog tagged as unreliable.
      My AWB job removes the {{Cleanup bare URLs}} banner, correctly
    2. Article1 has one bare ref: a ref to a highly-cited academic journal which some IP vandal has tagged as unreliable.
      My AWB job removes the {{Cleanup bare URLs}} banner, correctly.
      However, when someone else spots the bogus tag and remove the unreliable tag, my other job will add the banner back again.
    So there is no need to retain the banner just on the outside chance that a ref has been wrongly tagged.
    Note too, that you have contradicted yourself. Here you say that Bots cannot determine that context ... but up above, you wrote Feedback has been provided on how a future bot request could be modified to address the concerns and gain approval.
    You are facing both ways, and the only consistency in your antics is your transparent determination to impede my work. BrownHairedGirl (talk) • (contribs) 11:08, 16 August 2022 (UTC)Reply[reply]
    In both cases the removals are inappropriate because bare URLs remain. It really is that simple. Headbomb {t · c · p · b} 12:02, 16 August 2022 (UTC)Reply[reply]
    Again, @Headbomb, after 8 months you still stubbornly refuse to acknowledge the core purpose of {{Cleanup bare URLs}} banner.
    It is not some sort of linnean classification system.
    It is a request to editors to fill one or more bare URL refs.
    And I repeat: it is absurd to ask editors to fill a ref which has been identified as being unsuitable, an which should be removed or replaced.
    Your conduct is like the dumb as a brick tag which you rudely applied to my code in BhGbot9: you completely refuse to grasp the simple point that the purpose {{Cleanup Bare URLs}} is to ask editors to fill a ref. What is so hard to understand? BrownHairedGirl (talk) • (contribs) 12:28, 16 August 2022 (UTC)Reply[reply]
  1. Yes, absolutely. I find +13K articles with the tag without bare url refs. Not sure what reliability has to do with it.
  2. No, leave them, and let editors remove them manually, along with the dead refs.
Guarapiranga  07:59, 16 August 2022 (UTC)Reply[reply]
@Guarapiranga: your number of 13k+ is utter nonsense.
You got that nonsense number because your search is broken: it wrongly assumes that bare URLs (and only bare URLs) are wrapped in square brackets, e.g. [http://example.com/foo].
Neither assumption is true: almost zero bare URL refs use square brackets; and most refs which do use square brackets are filled, e.g. [http://examplew.com/balagan Balagan Today]
See e.g. the first article in your search results: Manchester Airport, which has three inline-tagged bare URLs.
Before you make snarky comments about reliability, please check your own data. BrownHairedGirl (talk) • (contribs) 10:54, 16 August 2022 (UTC)Reply[reply]
  1. No need to be wp:uncivil, BrownHairedGirl. I didn't mean to be snarky; I genuinely did not understand what reliability has to do with any of this. It seems to me a completely separate issue; there are perfectly formatted refs that are unreliable, and bare url refs that are at the top of wp:reliability.
  2. You're right; correcting the search to exclude articles with refs without braces (instead of refs with brackets), yields 455 tagged articles without bare url refs.
  — Guarapiranga  02:52, 18 August 2022 (UTC)Reply[reply]
@Guarapiranga: your comment about reliability was in a sentence about numbers, so I read it as being about the reliability of the numbers. Please do not call me uncivil for responding to what you actually wrote, instead of whatever you actualy meant.
Your revised search is still broken, because it is far too simplistic.
For examples, your search will not recognise inline tagged bare URLs : <ref>http:/foobar.com/foo {{Bare URL inline|date=June 2022}}.
There are articles with multiple inline-tagged bare URLs, and a {{Cleanup bare URLs}} banner. I don;t remove the banner unless the total number of bare tagged URLs is less than three.
For a year now, I have been working every day with regexes to identify bare URLs. It's a bit wearing to find someone coming to a discussion like this and repeatedly posting as fact nonsense data which they clearly have not even tested. BrownHairedGirl (talk) • (contribs) 03:22, 18 August 2022 (UTC)Reply[reply]
  • Speedily close per BHG and others. Rlink2 (talk) 22:58, 16 August 2022 (UTC)Reply[reply]
  • Leave no reason to remove, unless the problem has been fixed, which should be done by the person doing the fix. As per other tags which remain in place until the problem is deamed fixed. Keith D (talk) 17:32, 17 August 2022 (UTC)Reply[reply]
    @Keith D: the fixes may be done manually, or by a tool, or by a bot such as @Citation bot.
    For example,
    • an editor may fill the ref manually, or may use a tool such as WP:ReFill or WP:Reflinks
    • the ref may be filled by Citation bot
    • the ref may be tagged as a {{dead link}} (and hence unfillable)
    • the ref may be tagged with {{Bare URL inline}} by my regular AWB job User:BrownHairedGirl/No-reflinks_websites, making the banner redundant in some cases
    • the ref may be converted by InternetArchiveBot to the "Archived copy" format using {{cite web}}, and hence be no longer bare. (Those cases are automatically tracked in Category:CS1 maint: archived copy as title; we don't need the banner as well)
    • the ref may be tagged with of the many inline tags which mark it as unsuitable: unreliable, nonspecific, user-generated, self-published, circular ref, primary source etc. In such cases, the banner is no longer needed, because the remedy with those refs is not to fil them: it is to remove or replace them.
    Note that only the first of those six scenarios necessarily involves an actual human, and humans do not always know when to remove a banner. See e.g. User talk:BrownHairedGirl#Michael,_Row_the_Boat_Ashore (permalink), where an editor does a great job of filling cite templates, but doesn't know whether to remove the banner, and misses one bare URL.
    So if we leave it to humans to remove the banners, we will retain a lot of un-needed banners, and have some inappropriate removals. In the last 8 months, I have used my AWB Custom Module to remove well over 10,000 redundant {{Cleanup bare URLs}} banners, without a single objection from anyone at all. This semi-automated removal is working. BrownHairedGirl (talk) • (contribs) 18:32, 17 August 2022 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Moving the template to the references section[edit]

This worthy suggestion has all but drowned in all the discussion (and sniping) going on above.

EEng was one editor suggesting it, BrownedHairGirl opposed it. Then discussion veered elsewhere.

Lets get back on track: I agree tucking the banner away from the article header is a really good thing, and placing it in the references section is as good as any suggestion. CapnZapp (talk) 17:40, 16 August 2022 (UTC)Reply[reply]

It's not, because the bare links could be anywhere in the article: references, external links, body of the article, footnotes, bibliography section, etc... The only sure way to have it apply correctly is to have it at the top. Headbomb {t · c · p · b} 00:27, 17 August 2022 (UTC)Reply[reply]
In some of the cases under discussion (bare URLs tagged with some additional cleanup template) we have a big problem (say, "user generated source" or "dead link") that is shown only with a tiny inline template while the comparatively small "bare URL" problem gets extra attention by a top-of-the-article banner. This seems a bit backwards. —Kusma (talk) 09:59, 19 August 2022 (UTC)Reply[reply]

I think it should stay at the head of the article, where it is more likely to provoke action on clearing the problem. - Donald Albury 18:12, 16 August 2022 (UTC)Reply[reply]

How about we just put this energy into fixing the URLs, rendering the tag obsolete? BD2412 T 23:05, 16 August 2022 (UTC)Reply[reply]
A) This logic could be used to stick every issue ever as a cleanup issue on top of the article. Yet we don't highlight many similar maintenance tasks and instead track them in-line, or with maintenance categories, or with talk page notifications. There needs to be an affirmative case for how sticking this on top helps compared to the other options - that it's really attracting random passerby to fix the issues. B) BD2412, even in the unlikely scenario of fixing all of the bare URLs on Wikipedia, new ones will get added. So this is an on-going policy concern as to how to handle this kind of a problem. C) As I've mentioned before, even if we grant for a moment bare URLs are catastrophic (I don't), cleanup templates on top of a page are generally reader focused, not editor focused. And bare URLs aren't really a concern for readers. ("Bad sourcing" tags might be, but that's a separate issue, and such cleanup templates already exist.) This template has been added to the top of perfectly valid, well-sourced articles that happen to have a single bare URL in them somewhere. Now, if an editor fixes that, great, but if no such fix happens, why are we marking the article as a whole unreliable to readers? SnowFire (talk) 05:35, 17 August 2022 (UTC)Reply[reply]
Thumbs up icon CapnZapp (talk) 12:17, 17 August 2022 (UTC)Reply[reply]
@SnowFire, I am still horrified that you place such a low priority on good citations. This is an encyclopedia, not a collective blog, and good quality references are the absolute core of why were are here.
There are two parts to that concept of "good quality references":
  1. that the source itself should be of a high-quality: reliable, scholarly, and supporting the assertions in the articles.
  2. that the citation should identify that source in a clear and informative and consistent way, in accordance with the citation style in use.
A bare URL ref may meet the first criterion, but if it fails the second test, or clear presentation, then it is much harder for a reader to assess whether it meets the first criterion, i.e. of being a suitable source.
So I am horrified that you say bare URLs aren't really a concern for readers. The reality is entirely the opposite: references are the way by which our readers can verify what we publish, and bare URLs make it harder for them to do that. BrownHairedGirl (talk) • (contribs) 16:42, 17 August 2022 (UTC)Reply[reply]
@SnowFire: Two of the issues you raise are technical points, which I reckon are better separated from the issues of principle.
The first is your assertion that we don't highlight many similar maintenance tasks and instead track them in-line. In principle, I partly agree: where possible, single instances should be tagged inline. However, there is a technical problem with that: WP:REFLINKS does not support the {{Bare URL inline}}, and it is in my experience the best tool (or rather the east worst) for filling bare URLs. A I discovered painfully at the end of June 2021, mass adding {{Bare URL inline}} has the undesired effect of being a barrier to actually filling the refs. Yes, ideally the tool would be fixed; but it is unmaintained.
So that is why I apply the inline tags only to refs which I know that RefLinks cannot fill: see User:BrownHairedGirl/No-reflinks_websites. For the other refs, banners are all that is available.
If WP:Reflinks supported inline tags, then I would add the banner only to articles with three or more bare URLs. But I see no chance of an upgrade for Reflinks. BrownHairedGirl (talk) • (contribs) 17:00, 17 August 2022 (UTC)Reply[reply]
@SnowFire: another separate reply, for ease of threaded discussion.
You write: even in the unlikely scenario of fixing all of the bare URLs on Wikipedia, new ones will get added. So this is an on-going policy concern as to how to handle this kind of a problem.
So what would that scenario look like? Actually, after 13 months of work on this, I have already collected and published good data sets which allow me to describe quite accurately what that situation would look like.
  • new bare URLs are added every day to an average of about 300 articles. (the daily number can fluctuate wildly, and there are some glitches in the counting, but 300/day is a fairly stable long-term average) I call these "Articles With Bare URLs" (ABURs), so we are looking at about 9,000 "New ABURs" per month.
  • About 20% of those New ABUR have all their bare URLs filled with in a week or so by normal editing processes.
  • Currently, I am using various methods to track New ABURs on a daily basis, and filing about 30% of them using @Citation bot. That is labour-intensive work, and I am won't be able to sustain it for long.
  • The remaining 50% (and the 30% currently tackled on a daily basis, whenever I stop doing that) are picked up in my scans of the twice-monthly WP:Database downloads.
    Those new ABURs from each database dump are repeatedly-processed by me through Citation bot until progress stalls. This has all been documented publicly for 9 months, in the hundreds of revisions of User:BrownHairedGirl/Articles with new bare URL refs. See for example the results from July, which left only 1,069 new ABURs (excluding any which are inline-tagged):
    1. 8 passes of the New ABURs from the 20220801 database dump: 2,675 new ABURs, 443 remaining.
    2. 7 passes of the New ABURs from the 20220720 database dump: 2,671 new ABURs, 626 remaining.
  • While writing this post, I just re-scanned those 1,069 new ABURs from July, and found that only 677 of those 1,069 New ABURs still have untagged bare URLs.
However, @AManWithNoPlan's diligent development work on Citation bot has just in the last few days increased the bot's cleanup rate. I will feed these remaining 677 New ABURs from July to the bot, and report back on the results. BrownHairedGirl (talk) • (contribs) 17:50, 17 August 2022 (UTC)Reply[reply]
BHG, you would likely not experience so much blow-back had you not come across as ultimately uncompromising. What made you start this crusade against bare URLs I will never know. At the very least, please consider all the voices telling you you're making a mountain of a molehill - might it be that your stance is not the only reasonable to take? Why not take a moment to ask yourself WHY you are horrified when so many of your fellow editors aren't? CapnZapp (talk) 18:46, 17 August 2022 (UTC)Reply[reply]
@CapnZapp: I do indeed believe your assertion that what made you start this crusade against bare URLs I will never know. In this and in two other venues, you have made it abundantly clear (at great length) that you have no interest in or understanding of the importance of referencing techniques, and that you are actively hostile to efforts to improve refs.
Luckily, most editors do not support your disdain for good citations, and you wholly misrepresent the discussion: you are in fact the only editor here to make a stand in favour of bare URLs. Otherwise the disagreement is imply about how and where to tag the remaining bare URLs after over 90% of them have been resolved.
There seems no possibility that you will desist from opposing good referencing, but other editors can find plenty of established guidance on why it matters: see e.g. WP:HOWTOCITE and WP:Bare URLs. BrownHairedGirl (talk) • (contribs) 19:04, 17 August 2022 (UTC)Reply[reply]
You believe yourself a good neutral cool-headed editor, but in reality you are trying to crush your way through. If you were cool and levelheaded you'd realize this is blown out of all proportions, just look at this page! It's a full on wikipedia war, and YOU are the instigator. Please stop and reconsider your relentless barrage. You're in full-on defensive move where nothing anyone tells you gets through. If you only could realize everybody likes your actual work, just not the way you insist on billboarding your every move. If you could just drop the idea every single bare URL must be announced to the world as if somehow it turns its article into shit. Articles with bare URLs are fine, just not perfect. There is zero reason to suggest otherwise to readers. CapnZapp (talk) 21:15, 17 August 2022 (UTC)Reply[reply]
@CapnZapp: nobody else on this page agrees with your view that Articles with bare URLs are fine. Nobody.
So I will go back to ignoring you and your nasty personalised commentary, and your bogus allegations of "war". BrownHairedGirl (talk) • (contribs) 21:22, 17 August 2022 (UTC)Reply[reply]
You take everything personal, @BrownHairedGirl. Didn't you see me writing everybody considers your work valuable - the point of contention is instead making it so damn visible! You might ignore me (because I was one of the first editors to object to your "overly visible" approach?), but editors whose opinions I hope you consider valid have all objected to the way you lash yourself at the mast combining A) valuable cleanup work and B) broadcasting this to the world. Do you also ignore @EEng, @SnowFire, @Pppery and possibly more level-headed editors? Why not stop to listen? Everytime somebody says "topside banners are too much for this issue" you deflect by the nonconstructive "I'm personally attacked", and sure, behavior like Moxy's doesn't help. Why not entertain the thought you would gain much more praise for your efforts if you showed some compromise on the topside banner issue? You blowing your top each time somebody disagrees with you overshadows your contribution! If you only could accept someone like me has no beef with A) even though we think B) is much too much! CapnZapp (talk) 09:11, 18 August 2022 (UTC)Reply[reply]
What evidence do you have that BrownHairedGirl is ignoring me? * Pppery * it has begun... 14:03, 18 August 2022 (UTC)Reply[reply]
Also, note that far from ignoring @EEng and @SnowFire, I have replied at length to all of them. BrownHairedGirl (talk) • (contribs) 14:13, 18 August 2022 (UTC)Reply[reply]
  • As a Twinkle programmer, I'd be inclined to keep all maintenance tags together at the top. This is easier programatically, and also allows the use of the {{Multiple issues}} template. It also follows the principle of least astonishment, since almost every other full article maintenance tag goes there. The only exceptions are {{Uncategorized}} and {{Improve categories}}, which go second from the bottom. Those two exceptions have been a pain and required an RFC over at MOS:ORDER to sort out. The lesson I learned from that is that when we have a standard place for things, it is usually best to use the standard place, rather than making a bunch of exceptions. Just my two cents though, don't take it too seriously :) –Novem Linguae (talk) 05:57, 17 August 2022 (UTC)Reply[reply]
  • I suggested keeping it up top, but only to editors, not to readers. This, in fact, could be applied to various notifications (not all, but some, or even many). Is that possible? I tried finding a template or trick to identify whether the user was logged in or not, but failed. I'm sure someone smarter (or more tech savvy) than me has a way. — Guarapiranga  04:55, 18 August 2022 (UTC)Reply[reply]
    Everyone is an editor even when not logged in. Only blocked IPs or other special situations can not edit. I'm not aware of a way to communicate the log-in status to a template, never seen that. User-specific info is usually guarded for privacy reasons. -- GreenC 05:11, 18 August 2022 (UTC)Reply[reply]
    I don't think it'd be practical. I think you'd have to place two templates per page. I also don't see a getUsername() or mw.config.get('wgUserName') or isLoggedIn() function in Lua, but perhaps I am missing it. It would probably be on this page somewhere. –Novem Linguae (talk) 07:19, 18 August 2022 (UTC)Reply[reply]
    I can confirm that no way of branching based on username in Lua exists, although you can use the user-show CSS class to only show content to logged in users. * Pppery * it has begun... 14:03, 18 August 2022 (UTC)Reply[reply]
  • I am for banner up top. It's cleaner and more likely to work. Banners in-article are sometimes useful ie. <bannername-section> but I think they carry a higher interference factor. Also when you go down the road of mid-article it could go in the ref section, the section it's located, the external link section etc.. and programming and tracking and maintaining that is difficult. -- GreenC 05:06, 18 August 2022 (UTC)Reply[reply]
  • Keep at top as per above. This seems like the both visually, spatially and logically cleanest option. And I think it's best we try to see our way through to winding down this rather needlessly contentious discussion.--🌈WaltCip-(talk) 11:45, 18 August 2022 (UTC)Reply[reply]
  • I am of the mind that maintenance banners at the top of the page should serve our readers, while Wikimedia editors can have other ways of learning about issues. Our readers should know that the article has unreliable information, needs proofreading, and the like. I think there is a case, but a much weaker one than the examples I gave, that our readers need to know about bareurls. Perhaps this should be converted to an in-line use like Template:According to whom where the tag is attached next to the bareurl that needs fixing so that the reader understand exactly what information is at risk and needs fixing (as do editors who need to fix it). Best, Barkeep49 (talk) 13:36, 18 August 2022 (UTC)Reply[reply]
    {{bare URL inline}} already exists, and BrownHairedGirl mentioned why she didn't use it earlier in this section: WP:REFLINKS does not support the {{Bare URL inline}}, and it is in my experience the best tool (or rather the east worst) for filling bare URLs. A I discovered painfully at the end of June 2021, mass adding {{Bare URL inline}} has the undesired effect of being a barrier to actually filling the refs. Yes, ideally the tool would be fixed; but it is unmaintained * Pppery * it has begun... 14:03, 18 August 2022 (UTC)Reply[reply]
    Thanks for re-posting that, @Pppery.
    @Barkeep49: I agree that inline tagging is usually preferable, but flawed tools mean that in this case its use has to be restricted. I use {{Bare URL inline}} where I can. It currently has 10,790 transclusions. Nearly all of those have been added by me: mostly by my big and regular AWB job User:BrownHairedGirl/No-reflinks websites, and most of the rest by a javascript which I run on individual pages if WP:Reflinks fails to fill all the bare URLs. I put in many dozens of hours of work making these tools, to maximise use of {{Bare URL inline}} without impeding WP:Reflinks.
    In addition to {{Bare URL inline}}, there are several other inline templates for bare URLs devoted to various types of non-HTML content: {{Bare URL PDF}}, {{Bare URL image}}, {{Bare URL DOC}}, {{Bare URL spreadsheet}}, {{Bare URL plain text}}, and {{Bare URL AV media}}.
    {{Bare URL PDF}} was created by the wonderful @Rlink2; the others were created by me. In all cases, nearly all uses of the inline tags were added were by me, mostly from lists made by scanning the WP:Database dumps, and from some Perls scripts which I wrote to check HTTP content types for each of what were then about 400K unique bare URLs.
    The reason for having these specific tags is that a) no tools can fill bare URLs to non-HTML content, so using a different tag prevents @Citation bot etc from wasting time on them; b) some of them may be best be filled with specific types of cite template, and differentiating them by content type helps any editor who wants a batch of e.g. video files.
    Between them, these 6 inline templates for non-HTML content are used on a total of 40,198 pages (see https://petscan.wmflabs.org/?psid=22666654). That is about 45% of all the remaining articles with bare URLs.
    The overwhelming bulk of these non-HTML inline tags are {{Bare URL PDF}}, which has 29523 transclusions.
    In all, 51,704 articles have an inline bare URL tag: see https://petscan.wmflabs.org/?psid=22666660. That's about 55% of all remaining articles with bare URLs.
    I don't add the {{Cleanup bare URLs}} banner to articles where all the bare URLs are tagged, unless there are at least 5 bare URLs on the page.
    Hope this helps. BrownHairedGirl (talk) • (contribs) 14:46, 18 August 2022 (UTC)Reply[reply]
    This is all logical. But there are a lot of judgements of values - including why for Twinkle reasons putting it in references are hard- leading to decisions in that analysis. I'm not sure I share all of those judgements, but also I'm not sure that I don't. I am sure that I don't like the idea of putting editor useful, rather than reader and editor, useful banenrs at the top of the page. If the judgements above are correct - and here I'm going to reiterate I haven't thought about this deeply enough to have an opinion either way other than they're reasonable judgements - then that could be enough to be an exception to the rule for me. But that's a very conditional statement. Best, Barkeep49 (talk) 16:42, 18 August 2022 (UTC)Reply[reply]
    Thanks for that thoughtful reply, @Barkeep49.
    I don't agree that this is just editor-useful. Readers who check refs will find it helpful to be warned that this this page includes unhelpfully-styled refs.
    Personally, I find the dates on cleanup banners esp useful when reading. A banner which has remained there for long is a good indicator that the article is neglected.
    And philosophically, I strongly favour placing cleanup banners in a prominent position. Where a work-in-progress has unresolved issues, I favour being upfront about those issues. BrownHairedGirl (talk) • (contribs) 16:54, 18 August 2022 (UTC)Reply[reply]
    @Pppery pointed out that there is a user-show class that can allow us to easily hide templates from readers and not editors. Perhaps a discussion should be started somewhere about applying this class to certain maintenance tags. If consensus develops, it'd be super easy to add. Just need to confirm that there is a consensus, and pick our maintenance tags. –Novem Linguae (talk) 19:59, 18 August 2022 (UTC)Reply[reply]
    @Novem Linguae, I think that would be a great idea for certain templates. I'd consider Template:Uncategorized, Template:Infobox requested, and maybe instances of Template:Cleanup that don't have a |reason= parameter as potential candidates. These are problems that logged-out editors are not necessarily likely to be able to solve. WhatamIdoing (talk) 21:27, 18 August 2022 (UTC)Reply[reply]

Examples of addition and removal of the Cleanup bare URLs banner[edit]

For transparency, here are my most recent contribs lists for addition and removal of the {{Cleanup bare URLs}} banner.

Both examples are from today, after using WP:AWB in pre-parse mode to scan some huge lists.

  • Addition of the {{Cleanup bare URLs}} banner to 966 "List of foo" articles. The set had been processed by @Citation bot 7 times in the last 3 days. After that was done, I added the {{Cleanup bare URLs}} banner to the articles in the list which still have untagged bare URLs.
  • Removal of redundant {{Cleanup bare URLs}} banners this morning from 241 articles, after an overnight scan of the ~18,000 articles which transclude the banner. Note that in each case, the edit summary explains why the banner was removed: no bare URLs, or all bare URLs inline-tagged.

Hope this helps. --BrownHairedGirl (talk) • (contribs) 15:03, 18 August 2022 (UTC)Reply[reply]

Evidently not, since [3] removed {{Cleanup bare URLs}}, despite two bare URLs remaining. One tagged as a dead link, the other as user-generated source. This fixed the bare URLs and should have been done before removing the tag. This is why your script/bot needs adjustment. Headbomb {t · c · p · b} 21:09, 18 August 2022 (UTC)Reply[reply]
Yes, it's clear you and BrownHairedGirl disagree on the matter. Both of you seem to be commenting in nearly every section to restate the same disagreement, which is not helpful. * Pppery * it has begun... 21:23, 18 August 2022 (UTC)Reply[reply]
Compare the lengths and number the comments, and you'll see this is a false balance situation. I got one or two comments per section at most (save for the RFC). BHG has like zillions. Headbomb {t · c · p · b} 21:35, 18 August 2022 (UTC)Reply[reply]
For goodness sake, man. It is MY work which is being discussed. BrownHairedGirl (talk) • (contribs) 22:12, 18 August 2022 (UTC)Reply[reply]
Sigh. As I have explained to @Headbomb a zillion times, this is exactly what my tool is designed to do.
  1. A dead link cannot be filled. The required action is try to rescue it, and if it is rescued, the archived copy may be filed. But that relies on other tools and other work flows
  2. The user-generated source should have been replaced with an independent reliable source. You took the wrong action, Headbomb.
Give it a rest, Headbomb. You are not doing any of this work, and are simply trying to disrupt those of us who actually do the work. BrownHairedGirl (talk) • (contribs) 22:11, 18 August 2022 (UTC)Reply[reply]
"But that relies on other tools and other work flows" Indeed it does. Which is why we have the saying 'when all you have is a hammer, everything looks like a nail'. Except here a hammer is the wrong solution, and the banner needs to be left in place so people with screwdrivers can fix things. Headbomb {t · c · p · b} 01:06, 19 August 2022 (UTC)Reply[reply]

About Wikipedia:Changing username/Usurpations[edit]

Hello, I have a question regrading Wikipedia:Changing username/Usurpations. I have found that there is a local page for usurpation. However, all the other languages listed (d:Q4615956) are closed or inactive. Moreover, like Global locks, users are globally renamed. As a result, I would like to ask why Wikipedia:Changing username/Usurpations is currently still available on making requests and would it be possible to merge the requests to the the same page on metawiki (i.e. Stop allowing making requests in enwiki). 132.234.112.11 (talk) 04:11, 16 August 2022 (UTC)Reply[reply]

Makes sense. We now have single unified login and follow the global usurpation rule anyway. CX Zoom[he/him] (let's talk • {CX}) 04:46, 16 August 2022 (UTC)Reply[reply]
Because we are huge and host many only-one-wiki users; this allows for a quicker process when only enwiki is involved (1 week vs 1 month). — xaosflux Talk 14:09, 16 August 2022 (UTC)Reply[reply]

phabricator requested I report this[edit]

Report it in a support forum of English WP. If this isn't the right place (I'm not the most knowledgeable WP-editor), I assume/hope somebody here will send it to the right place. You can read the problem here:
https://phabricator.wikimedia.org/T314837 Dutchy45 (talk) 07:51, 16 August 2022 (UTC)Reply[reply]

Resolved
CapnZapp (talk) 18:48, 17 August 2022 (UTC)Reply[reply]

#WPWP[edit]

It looks as if someone is running a campaign to add images to enwp articles with edit summaries containing #WPWP or #‎WPWPNG. This also occurred in August 2021, with the good-faith addition of many images, some of which were inappropriate. Does anyone know who is behind this campaign? Are there any opinions as to whether it's useful and what, if anything, we should do about it? Certes (talk) 00:58, 18 August 2022 (UTC)Reply[reply]

WP:Administrators' noticeboard/Archive344#WPWP query. —Cryptic 01:10, 18 August 2022 (UTC)Reply[reply]
@Certes: any diffs or links or other ways to see what's happening? BrownHairedGirl (talk) • (contribs) 01:59, 18 August 2022 (UTC)Reply[reply]
https://hashtags.wmcloud.org/?query=WPWP&project=en.wikipedia.org. The most recent edit as of now (other than this discussion) is typical. —Cryptic 02:12, 18 August 2022 (UTC)Reply[reply]
Thanks for the clues. A little more digging brings up m:Wikipedia Pages Wanting Photos 2022. It seems I'm late to the party and it's already been discussed at AN. Cryptic's examples contain #WPWPRW, and I saw NG (ISO code for Nigeria), so there may be a particular drive to improve our African articles. Contest ends 31 August. Certes (talk) 08:38, 18 August 2022 (UTC)Reply[reply]
There's a CentralNotice banner running in Albania, Belgium, Benin, Cameroon, Ghana, India, Italy, Nigeria, North Macedonia, Philippines, Sudan, Switzerland, and Turkey. [4] What the logic is behind those country choices, I have no idea. In any case it does seem less disruptive than last year, though worth keeping an eye on. The banner is due to end on 31 August. the wub "?!" 09:14, 18 August 2022 (UTC)Reply[reply]
I hadn't noticed this was happening again, so that's a good sign. I ended up writing a standard talkpage message last year, in case anyone encounters a new user needing guidance. CMD (talk) 17:35, 18 August 2022 (UTC)Reply[reply]
In case it's of any use to anyone reading this, Special:AbuseFilter/1073 is currently tagging these edits, see [5] for a realtime list of edits. 86.23.109.101 (talk) 22:03, 18 August 2022 (UTC)Reply[reply]

Help for grammer check[edit]

Hey all, can any native speaker of English check this articles: Muhyi al-Din Faris, Idris Jamma'. I will learn from your reforms, and i will not repeat requesting this kind of my own problems. Thank you. Ruwaym (talk) 22:23, 18 August 2022 (UTC)Reply[reply]

Just for your information: you can consider asking for writing assistance on the talk page for Wikipedia:WikiProject Guild of Copy Editors. isaacl (talk) 22:39, 18 August 2022 (UTC)Reply[reply]
@Isaacl Oh, thank One who laughs. Ruwaym (talk) 12:59, 19 August 2022 (UTC)Reply[reply]

Invitation to join the Movement Strategy Forum[edit]

The Movement Strategy Forum (MS Forum) is a multilingual collaborative space for all conversations about Movement Strategy implementation. We are inviting all Movement participants to collaborate on the MS Forum. The goal of the forum is to build community collaboration using an inclusive multilingual platform.

The Movement Strategy is a collaborative effort to imagine and build the future of the Wikimedia Movement. Anyone can contribute to the Movement Strategy, from a comment to a full-time project.

Join this forum with your Wikimedia account, engage in conversations, and ask questions in your language.

The Movement Strategy and Governance team launched the proposal for this MS Forum in May. After a 2-month review period, we have just published the Community Review Report. It includes a summary of the discussions, metrics, and information about the next steps.

We look forward to seeing you at the MS Forum! Qgil-WMF (talk) 11:47, 19 August 2022 (UTC)Reply[reply]