User talk:BrownHairedGirl

click here to leave a new message for BrownHairedGirl
BrownHairedGirl's archives
+ Cumulative index

This talk page was last edited (diff) on 28 June 2022 at 05:01 by Jonesey95 (talk • contribs • logs)

Citation Bot data for Zotero

Here are the first copies. They are big. Note that fail could be for any reason and could be transient. I have bzipped them and added set number 2 of data.

https://citations.toolforge.org/ZoteroFailed.1.bz2

https://citations.toolforge.org/ZoteroWorked.1.bz2

https://citations.toolforge.org/ZoteroFailed.2.bz2

https://citations.toolforge.org/ZoteroWorked.2.bz2

AManWithNoPlan (talk) 11:55, 2 June 2022 (UTC)

Many thanks for taking the time to make these logs, @AManWithNoPlan. This should be very valuable data. @Rlink2 may also be interested.

I am just unzipping the 20220601 database dump, and processing that usually takes a few days. Then I will start analysing this data. BrownHairedGirl (talk) • (contribs) 12:10, 2 June 2022 (UTC)

PS @AManWithNoPlan: you will probably have noticed that for the last ten days I have bene driving Citation bot hard with bare URL jobs, using up a good chunk of the bot's enhanced capacity.

This is producing great results. My crude regex search for all untagged bare URLs gave a total of 98K pages on 20 May. Right now, it reports 86K.

That's a huge reduction, because it doesn't reflect the many pages that had multiple bare URLs, but where not not all of them have yet been cleared. I reckon that by the end of June, we will probably have got the total as low as can be achieved with any tool relying on the zotero servers. Then I hope that BareRefBot will be starting to make a big dent in the remainder.

This has all been made possible by your hard work on Citation bot. CB is not the tool I have been using, but it is the main one. Without CB, I'd never have been able to bring the total count of articles with bare URls down from ~470K at the start of May 2021 to the ~130K which I estimate to be the counts from the latest database dump. Thank you. BrownHairedGirl (talk) • (contribs) 12:27, 2 June 2022 (UTC)

Another batch. AManWithNoPlan (talk) 15:32, 9 June 2022 (UTC)

Thanks, @AManWithNoPlan. This is v helpful.

I have almost finished processing the 2022061 dump. Then it will be analysis time. BrownHairedGirl (talk) • (contribs) 15:43, 9 June 2022 (UTC)

https://citations.toolforge.org/ZoteroFailed.3.bz2

https://citations.toolforge.org/ZoteroWorked.3.bz2

https://citations.toolforge.org/ZoteroFailed.4.bz2

https://citations.toolforge.org/ZoteroWorked.4.bz2

https://citations.toolforge.org/ZoteroFailed.5.bz2

https://citations.toolforge.org/ZoteroWorked.5.bz2

Many thanks, @AManWithNoPlan. That latest batch is timely, 'cos I planned to the analysis today, before the 20220620 database dump becomes available tomorrow. I will include the latest sets in the analysis. --BrownHairedGirl (talk) • (contribs)

@AManWithNoPlan: Analysis underway.

Counting complete, now gotta work on the comparison.

• counting worked zotero requests: 3025169 requests, 228945 unique domains
• counting failed zotero requests: 5060471 requests, 336337 unique domains
• count total: 8085640 requests, 403206 unique domains

--BrownHairedGirl (talk) • (contribs) 20:50, 22 June 2022 (UTC)

I have turned off the logging. Here are the final files. This is ALL the log files combined into a single file. I sorted the data before compressing and that really helped the compressor shrink them more. I also used xz compression format and that makes the files much much smaller than bzip/zip/7zip etc. All the other files are now deleted to keep us under disk quotas. https://citations.toolforge.org/ZoteroFailed.xz https://citations.toolforge.org/ZoteroWorked.xz AManWithNoPlan (talk) 15:43, 24 June 2022 (UTC)

Many thanks, @AManWithNoPlan. I have downloaded both those files, so feel free to delete them if needed.

I think you are right to turn off the logging. A whole month's logs are enough for our purposes here.

I will re-run the collater with this all-in-one log. A single Perl script handles the whole task, so it's easy to do.

Thanks again for doing this logging. It has been very useful. BrownHairedGirl (talk) • (contribs) 15:51, 24 June 2022 (UTC)

June events from Women in Red

Women in Red June 2022, Vol 8, Issue 6, Nos 214, 217, 227, 231, 232, 233 Online events: New: LGBTQ+ women | Greenland and the Faroes | Women in music Contest (Apr/May/Jun): Translation contest (third and last month) Continuing: Climate (year-long initiative) | #1day1woman Other ways to participate: Join the conversations on our talkpage. Help us plan future events. Follow us on social media: Facebook | Instagram | Pinterest | Twitter

--Megalibrarygirl (talk) 09:19, 31 May 2022 (UTC) via MassMessaging

Category:Leisure activity vehicles has been nominated for deletion

Category:Leisure activity vehicles has been nominated for deletion. A discussion is taking place to decide whether this proposal complies with the categorization guidelines. If you would like to participate in the discussion, you are invited to add your comments at the category's entry on the categories for discussion page. Thank you. HumanBodyPiloter5 (talk) 07:10, 1 June 2022 (UTC)

Way to freeze archive dates?

In this edit you processed a bunch of archive.org links into {{cite web}} invocations, which did preserve the archive dates, but I am wondering if this will bring it in conflict with other scripts? For example, is there anything that will try to "auto-update" archive URLs to the most recent? If so, is there a way to "lock in" the current URLs and prevent such updating? The reason I ask is because the cited archive URLs are being used to cite statements about what was on the website during particular periods of time. jp×g 18:47, 1 June 2022 (UTC)

@JPxG: I think we are probably coming from a similar place. I absolutely share your desire to cite the version of the page which was consulted.

In my view, the only acceptable form of reference on Wikipedia should be a completely filled cite template where the primary form of any URL is an archived copy of the actual version of the webpage as consulted by the editor who added the ref. That is the only way in which the cite can be fully verifiable.

But instead of that, we tolerate vague waves at sources: bare URLs, non-specific URLs (example.com instead of example.com/articles/5a3wp901), cites of PDFs and books without page numbers, and refs to repeatedly-updated pages with no indication of which version was consulted.

This problem is so deeply embedded that we do not even have a mechanism within the cite templates for clearly indicating that the archived copy is there to allow verification of the version of the URL on which the cite is based. I raised this in June 2021 at Help talk:Citation Style 1/Archive 78#Current_version_of_page_no_longer_contains_cited_facts._url-status=? in respect of a URL where I needed to cite an old version of a politician's autobiog page, because it contained info which was (quite reasonably) no longer in the current version. The only way to do that is to use |url-status=dead, even tho the page is not dead.

So, for all that WP:Verifiability is a core policy, the actual practice of Wikipedia is that very few articles consistently use refs which actually allow verification of web sources by identifying the version consulted. The community's approach to verifiability is at best half-hearted. It's like Saint Augustine's prayer "Grant me chastity and continence, but not yet."(Augustine of Hippo, Confessions, 8:7.17).

That need to verify the actual version of the webpage as consulted by the editor who added the ref is so little understood that one experienced editor actually spent a lot of time removing[1] a large set of archive links which I added to an article I wrote which got promoted to Featured List status. In subsequent discussion, that editor claimed that they wanted a more "dynamic" relationship between citation and source, which is of course the precise opposite of the snapshot-in-time that is needed for verification.

So, back to your example. You did the right thing by citing a specific archived copy. However, you failed to fill the citations, leaving bare URLs. At best, that leaves a lot of work for some other editor(s) to add all the data which you had to hand when you added the refs; at worst, it leaves them guessing what your intent was, and possibly getting it wrong. Grrrrrrrr: please, please, use complete citations.

For the last year, my work has been focused almost exclusively on filling bare URLs, i.e. converting them to citation templates and filling out as many of the parameters as the tools allow. None of the tools do anywhere near a complete job, but they do make the citations less bad and/or more easily-completed.

The example you give is one of a large set of AWB edits which I do on an ongoing basis (v rough average ~1,000 per month), taking a bare URL ref to an archived copy, and formatting it in {{cite web}}. That's a clerical task which my AWB module can do with complete accuracy, avoiding the clerical errors which may occur when it is done manually. It still leaves the task of filling the |title= parameter etc, but some of the tedious work is done.

I am not aware of any tools or regular jobs which modify archive links. @InternetArchiveBot adds archive links, and cunningly uses the archived version most likely to have been that consulted when the ref was added (it appears to check the page history to find the ate of addition). The main case I can see is that there might be a task which removes or replaces archive-links which are dead, or where the archived copy is just an error page. (@GreenC and @Rlink2 do a lot of good work on archives, so may know more). And of course, this is a wiki, so any editor may do anything, which means that there always a risk of cases like my example of the editor who thought that it was a good idea to removed archived links.

Sorry that's a long reply, but I hope it helps. And please please please please please please do fill out any citations which you add: the more complete you make it, the less likely that anyone else will modify it. BrownHairedGirl (talk) • (contribs) 01:49, 2 June 2022 (UTC)

Talk page stalker here. I'm fairly certain, from testing, that setting |url-status=deviated also triggers the archive-url to become the live url. The documentation at {{cite web}} supports that by saying to use that parameter when the original URL is 'live' but no longer supports the article text Sideswipe9th (talk) 01:56, 2 June 2022 (UTC)

@Sideswipe9th: Sounds good, I'll try it out :) jp×g 02:22, 2 June 2022 (UTC)

Bless you, @Sideswipe9th. This is great news.

|url-status=deviated is just the sort of thing that I was looking for in that discussion in June 2021 which I mentioned above.

It was one of the ideas mentioned in that discussion, but I was not aware that it had been implemented. Thanks to you, I do now know that it is available. I wish I had known of it before, 'cos there are thousands of refs which I edited in the last year where I would used it if I had known. BrownHairedGirl (talk) • (contribs) 03:39, 2 June 2022 (UTC)

Ah, thank you very much for the reply! I was actually wondering this when I originally put those refs into the article -- I had initially tried to use citation templates, but I couldn't figure out how to do so in a way that protected the archive URLs from getting overwritten or messed up. I think I will give the deviated parameter a shot the next time this comes up. Hopefully, everything will become less completely fucked up in the future ;) jp×g 02:22, 2 June 2022 (UTC)

Maintaining archive links is WP:WAYBACKMEDIC. -- GreenC 02:29, 2 June 2022 (UTC)

Alphabetization

Hello, hello, hello! Do you have any idea why the number 1983 at this category page is not being put in alphabetical order with the other numbers? Cheers. Anythingyouwant (talk) 22:00, 1 June 2022 (UTC)

(talk page watcher) @Anythingyouwant: Because the 1983 article has a DEFAULTSORT of "United ... " which makes it file under "U", and the others don't. PamD 22:26, 1 June 2022 (UTC)

Is it okay if I get rid of the default sort, or should I just leave it as-is. I think it would be kinda nice if it got listed with all the other numbers. Anythingyouwant (talk) 22:30, 1 June 2022 (UTC)

@Anythingyouwant I've over-ridden the defaultsort for this one Category. Looking at other cats like Category:Crimes in Washington, D.C., filing by the word after the year seems more common. PamD 22:43, 1 June 2022 (UTC)

Thanks Pam, much appreciated. Anythingyouwant (talk) 01:15, 2 June 2022 (UTC)

Thanks, @PamD, for yet again giving a prompt and helpful reply while I was offline. It's v kind of you. --BrownHairedGirl (talk) • (contribs) 01:53, 2 June 2022 (UTC)

Administrators' newsletter – June 2022

News and updates for administrators from the past month (May 2022).

Administrator changes

Tamzin

Barek • Darkwind • Geometry guy • ProcseeBot • RoyBoy • Sean Whitton • Valereee • Visorstuff • WAvegetarian

Sn0wflake → VersedFenrir

CheckUser changes

Ivanvector

Guideline and policy news

• Several areas of improvement collated from community member votes have been identified in the Universal Code of Conduct Enforcement guidelines. The areas of improvement have been sent back for review and you are invited to provide input on these areas.

Technical news

• Administrators using the mobile web interface can now access Special:Block directly from user pages. (T307341)
• The IP Info feature has been deployed to all wikis as a Beta Feature. Any autoconfirmed user may enable the feature using the "IP info" checkbox under Preferences → Beta features. Autoconfirmed users will be able to access basic information about an IP address that includes the country and connection method. Those with advanced privileges (admin, bureaucrat, checkuser) will have access to extra information that includes the Internet Service Provider and more specific location.

Arbitration

• Remedy 2 of the Rachel Marsden case has been rescinded following a motion. The remedy previously authorised administrators to delete or reduce to a stub, together with their talk pages, articles related to Rachel Marsden when they violate Wikipedia's biographies of living persons policy.
• An arbitration case regarding WikiProject Tropical Cyclones has been closed.

---

• Discuss this newsletter
• Subscribe
• Archive

Sent by MediaWiki message delivery (talk) 17:55, 2 June 2022 (UTC)

A wiki page about my father

I want to know who you are and how you received all this information on my father most is public knowledge but some is not if you could email me at glitterandglam1522@gmail.com that would be great. 2600:1017:B020:A8C3:D0E2:7F61:56FD:2540 (talk) 02:44, 4 June 2022 (UTC)

I have no idea what article you are talking about, so I cannot comment.

I believe that discussions about Wikipedia should be on Wikipedia, where they are publicly visible. So I will not email you. BrownHairedGirl (talk) • (contribs) 02:49, 4 June 2022 (UTC)

Another template problem

Template:YYYY crimes in countryname category header is used on the likes of Category:1921 crimes in Turkey and populates Category:1921 in Turkey when it should be populating Category:1921 in the Ottoman Empire. My attempt to add the redirect resolve failed miserably. Are you able to sort out the template? Timrollpickering (talk) 10:55, 4 June 2022 (UTC)

@Timrollpickering: Surely the problem is that Category:1921 crimes in Turkey is misnamed? BrownHairedGirl (talk) • (contribs) 14:32, 4 June 2022 (UTC)

I'll try renaming them but given that the Ottoman Empire was often called Turkey it's a problem that could reoccur and more generally the templates need to be adaptable. Timrollpickering (talk) 18:09, 4 June 2022 (UTC)

@Timrollpickering: my general philosophy with those templates is to minimise adaptability, to allow simple (parameter-free) usage and to maintain consistency. Without the templates, most by-year categories were a hideous mishmash of inconsistent parenting.

In this case, I just spotted that Category:1921 in Turkey is a redirect. That made the problem easily solveable, by this edit to {{YYYY crimes in countryname category header/inner core}}, making it use {{Resolve category redirect}}. You may wish to reconsider your proposed speedy renaming of Category:1921 in Turkey: it is no longer needed to solve the parent cat problem, tho a merge may be helpful due to the small size of Category:1921 in Turkey.

In most cases like this, the template just needs to be upgraded to use {{Resolve category redirect}}. If that doesn't solve the problem, it is nearly always because some category is misnamed or a redirect has not been created. BrownHairedGirl (talk) • (contribs) 18:27, 4 June 2022 (UTC)

Mass tagging bare URLs

I noticed you thanked Special:Diff/1081759415. I just thought i'd mention here that I modified your Bare URL script at User:Qwerfjkl/.js so it can run on Bandersnatch (a userscript) so can easily be run on a list of pages for mass tagging. Happy editing! ― Qwerfjkltalk 20:05, 4 June 2022 (UTC)

Hi @Qwerfjkl

Sorry for a slow reply. I meant to take the time to explain some of the issues with this, but got distracted. Now I see that you are doing the mass-tagging.

Please will you stop? I will write the explanation now. BrownHairedGirl (talk) • (contribs) 01:09, 10 June 2022 (UTC)

The problem with mass inline-tagging is that not all the available tools support the inline tags. In particular, WP:REFLINKS won't fill any such refs.

This is a problem, because WP:REFLINKS has several virtues which make it the best tool for some purposes. See User:BrownHairedGirl/No-reflinks websites. BrownHairedGirl (talk) • (contribs) 01:49, 10 June 2022 (UTC)

Categorizing redirects

If only one section of a Wikipedia article is about a particular category, is it advisable to create a redirect pointing to that section, and then put the category at the bottom of that redirect, instead of at the bottom of the article? Anythingyouwant (talk) 15:10, 8 June 2022 (UTC)

Good question, @Anythingyouwant.

I guess that the answer is "it depends". Categorising redirects in content pages can be controversial; if possible, it's preferable to categorise the actual article.

Which article do you have in mind? BrownHairedGirl (talk) • (contribs) 15:13, 8 June 2022 (UTC)

It’s a moot point now, because I put some categories at redirects but got reverted and I don’t feel like quibbling about it. But I was curious about this for the next time the question might arise. The category in question was Category:Attacks on the United States Congress. I started the category a few days ago, and arranged its contents so that every subcat item listed in the category began with the year, and thus everything would be chronological, plus I made some of the redirects point to article sections instead of whole articles. But like I said, it’s moot now. Anythingyouwant (talk) 15:22, 8 June 2022 (UTC)

Oops! Sorry about that. I didn't notice that you had added those redirects. I was looking at the entries and noticed that many of them were redirects, and that just seemed wrong to me, so I proceeded to fix it. I had no idea about the background and am now curious about best practice. -- Valjean (talk) (PING me) 15:37, 8 June 2022 (UTC)

@Valjean: I can't really comment on the redirects without seeing examples of what redirects were categorised. BrownHairedGirl (talk) • (contribs) 19:32, 8 June 2022 (UTC)

Okay. I did this while using the contents of Category:Attacks on the United States Congress and made the edits in a short time period, leaving contents that were not redirects. Here are diffs:[2][3][4][5][6][7] Edit summary: "rmv category from redirect". I added the category to the actual target articles. -- Valjean (talk) (PING me) 23:07, 8 June 2022 (UTC)

Request to take a look at Flag of Minnesota

Dear BrownHairedGirl,

I noticed you are an administrator on Wikipedia and knowledgeable of Wikipedia polices. If possible, I would like to request that you review the article revision history for Flag of Minnesota. I have edited the article to attempt to include critical commentary from a newspaper op-ed written by a scholarly authority on a topic related to racism. The topic itself is related to white supremacy. Another user suggests that this source cannot be included. As someone without much Wikipedia experience, I am uncertain about whether this other user's removal is reasonable. After reviewing the policy here: https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources#News_organizations, I remain uncertain. I would greatly appreciate your time to review, whenever possible, either to re-include what was removed or to help me understand what would be appropriate to include (or not include) as I make edits for the future.

-Anonymous User — Preceding unsigned comment added by 2601:441:4C80:4EB0:C096:6590:ED3:3C82 (talk) 22:25, 9 June 2022 (UTC)

About Dense-in-itself

Hi. I see that you recently edited the topology article Dense-in-itself by editing one of the references. You added information about the authors of the article and the journal (Illinois Journal of Mathematics) it supposedly appeared in. But the researchgate version was pointing to Houston Journal of Mathematics instead, vol. 21 (year 1977) in particular. So I went to check their website: https://www.math.uh.edu/~hjm/Electronic-Editions.html#The%20Archive and I don't see any such article in the four links they have for vol 21. Do you? If you don't see it either, can you remove the reference to an incorrect journal? Maybe the authors were planning to publish it but never did. PatrickR2 (talk) 23:46, 9 June 2022 (UTC)

Just to make sure, I also checked the Illinois Journal of Mathematics for the year 1977 (which coincidentally is also vol 21), and I can't see this article anywhere: https://www.projecteuclid.org/journals/illinois-journal-of-mathematics/issues/1977 PatrickR2 (talk) 23:59, 9 June 2022 (UTC)

@PatrickR2: thanks for the headsup.

Here's my edit: [8]. I followed the link to https://www.researchgate.net/publication/228597275_a-Scattered_spaces_II/, and then used the "download citation" link to https://www.researchgate.net/publication/228597275_a-Scattered_spaces_II/citation/download. The latter one is the where I grabbed the data for the citation.

And now I see that the two pages give difft data.

I have been filling hundreds of bare URL refs to ResearchGate, and have concluded that the site is crap.

In this case, you evidently know a lot more about the topic than I do. May I leave it to you to do whatever is needed to sort this out? BrownHairedGirl (talk) • (contribs) 00:02, 10 June 2022 (UTC)

Sounds good. I'll remove the journal itself from the reference. ResearchGate indeed does not seem overly reliable. PatrickR2 (talk) 02:57, 10 June 2022 (UTC)

Merging "by period" and "by date" container categories, or not?

Please check this discussion. Marcocapelle (talk) 05:01, 11 June 2022 (UTC)

Deprecated tag fixing

Hey! Do you think you could edit or request an edit to your User talk:BrownHairedGirl/Archive/Archive 019 page? The page currently uses deprecated source tags. Replacing these tags with <syntaxhighlight> tags will fix any issues with it. The page is fully protected, and I've been advised to inform the archive owner of this instead of requesting an edit myself. Don't worry - the page will have no visible effect, this is just a maintenance thing. Thanks! Aidan9382 _(talk) 16:25, 11 June 2022 (UTC)

Hi @Aidan9382, and thanks for your msg.

Actually, I do mind. Not much, but as a general principle, I prefer not to have changes made to archive pages. That is why I protected them.

Why not simply change the software so that userpages with this markup are not categorised in the tracking cateory? BrownHairedGirl (talk) • (contribs) 16:33, 11 June 2022 (UTC)

I'm not too familiar with the background behind this, but I don't believe theres good reason to exclude categorisation on user pages specifically, as it's deprecated regardless of what page it's on. Don't worry about it - it's not like it's an urgent issue, it's just something im trying to cut the use of down as its deprecated. Aidan9382 _(talk) 16:39, 11 June 2022 (UTC)

@Aidan9382: it's not a big deal, but so far I don't see any need to edit these archives: to my mind, the problem isn't serious enough to justify rewriting the historical record. BrownHairedGirl (talk) • (contribs) 16:43, 11 June 2022 (UTC)

Sorry, I must not have been clear. I was trying to say in my previous message is that its fine to leave the archive untouched - as you said, its not serious. I was just commenting on your other comment about changing the software. Thanks for the quick replies! Aidan9382 _(talk) 16:45, 11 June 2022 (UTC)

Email

check your mail Rlink2 (talk) 10:39, 12 June 2022 (UTC)

@Rlink2: thanks. I am at it now. BrownHairedGirl (talk) • (contribs) 10:43, 12 June 2022 (UTC)

@Rlink2: You have mail. Sorry it took so long. BrownHairedGirl (talk) • (contribs) 16:47, 12 June 2022 (UTC)

Disambiguation link notification for June 13

An automated process has detected that when you recently edited Douglas Bruster, you added a link pointing to the disambiguation page To Be or Not to Be.

(Opt-out instructions.) --DPL bot (talk) 09:16, 13 June 2022 (UTC)

fixed[9]. BrownHairedGirl (talk) • (contribs) 09:21, 13 June 2022 (UTC)

Great to see you still editing

Hi BHG,

I remember your edits from back in 2004 when I started on Wikipedia. I don't edit much anymore but I was looking at the recent burst of edits on Running Up That Hill and saw your cleanup edits from April. You are still here, working away. Is your hair still brown, after all those edits!!

- 2A01:4B00:822B:EE00:31BB:580D:2138:9705 (talk) 15:44, 14 June 2022 (UTC). That was by me: - Rye 212 (talk) 15:46, 14 June 2022 (UTC). See, I even forgot to login.

Boushaki cosmological operator

Hello BrownHairedGirl.

This article relates to the research undertaken by Professor Mustapha Ishak Boushaki on the expansion of the universe, and it is listed in the scientific literature under the name Index of Inconsistency (IOI).

The professor's research team at the University of Texas at Dallas is working rigorously on this subject, which has captured the attention of astrophysicists and cosmologists.

If there are third parties or people who are bothered by the highlighting of these results that have been sponsored by NASA and other institutions, it is not acceptable to please and accept their request for deleted article which was noted as being of high importance for the development of scientific research in the United States and around the world.

Sincerely and warmly.--Authentise (talk) 09:26, 15 June 2022 (UTC)

@Authentise: I am sorry, but I am unable to understand what you want. In particular, your paragraph beginning If there are third parties or people makes no sense. You write it is not acceptable to please and accept ... which is so far from proper English grammar that I don't know what to make of it.

You mention deletion, so I checked the article's history. I see no sign that the article Boushaki cosmological operator (edit | talk | history | protect | delete | links | watch | logs | views) has ever been selected for any of Wikipedia's deletion processes.

I don't know why you are writing to me about this. Why do you think I have any interest in this?

Also I note that you have sent similar messages to other editors: Cullen328[10], Mako001[11], M.Bitton[12].

If there was a deletion discussion, this would be unacceptable WP:CANVASSING. But there is no deletion discussion ... so what are you trying to achieve? BrownHairedGirl (talk) • (contribs) 09:45, 15 June 2022 (UTC)

I could be mistaken, but I think they are referring to this request by Mishak1967 (who is obviously Mustapha_ishak, the editor who claims to be Mustapha Ishak Boushaki). I'm not really sure why they decided to complicate things further by creating a new account, when all they had to do is follow the instructions that were left on their main account's talk page. M.Bitton (talk) 13:23, 15 June 2022 (UTC)

O Lordie, @M.Bitton. So Authentise is broadcasting a request by a sock of a COI editor?

What a mess. I hope that some admin will sort this out. BrownHairedGirl (talk) • (contribs) 13:42, 15 June 2022 (UTC)

Yes, it's a mess. Hopefully, Cullen328 will sort it out. M.Bitton (talk) 13:51, 15 June 2022 (UTC)

I hope so, @M.Bitton. Cullen328 usually handles these things well. BrownHairedGirl (talk) • (contribs) 14:13, 15 June 2022 (UTC)

There are two threads on my talk page about this matter. If the topic is called "Index of Inconsistency" then why is the article titled "Boushaki cosmological operator"? It is a mystery. Cullen328 (talk) 18:35, 15 June 2022 (UTC)

All very odd, @Cullen328.

I am going to spare my brain the job of unravelling it all, and leave the remedies in your capable hands. BrownHairedGirl (talk) • (contribs) 18:40, 15 June 2022 (UTC)

Kamil Zayatte

Hello, this edit did not really achieve what I think was intended. I have now removed the spaces from the URL to get a valid link. You may want to revisit and tag with one of the bare link tags. Keith D (talk) 21:09, 15 June 2022 (UTC)

Many thanks, @Keith D.

The edit went as far as I dare go using AWB, which in this case was removing the space between the <ref> and the http ... because that space excludes the bare URL from my on-wiki searches for bare URLs in between database dumps, such as this search for all unbracketed bare URLs. In theory, I could of course include \s* before the http, but unfortunately that makes the searches time out.

As you spotted, that URL had been mangled by spaces, and thanks for fixing it. I am currently doing a wider cleanup of various malformed URLs, and continue to be amazed by the assortment of creative ways which some editors find to break URLs. BrownHairedGirl (talk) • (contribs) 21:21, 15 June 2022 (UTC)

No problem, I have the same trouble of creativity of editors over dates, but the error category is slowly diminishing! Keith D (talk) 21:28, 15 June 2022 (UTC)

Thanks, @Keith D. When I was working on some dates, I was very impressed by the ability of AWB's WP:GENFIXES to rescue some dates from extreme creativity.

I know that some exceed even that tool's ability, but I hope that you are trying AWB first, to reduce the effort in your good work. BrownHairedGirl (talk) • (contribs) 21:32, 15 June 2022 (UTC)

I am using some basic AWB functionality to handle the simple things that are wrong, one of BattyBot functions handles more AWB fixable things. I think that it is now mainly manual work, unless I come across an error that covers a number of articles and I can work out an ABW fix that does not screwup something else. Keith D (talk) 21:43, 15 June 2022 (UTC)

Period inside ref tags

FYI, this edit removed periods after a <ref> tag before an url. Looks like the period was misplaced, and should have been moved outside the tag. Not sure if AWB can be smarter in such cases. I glanced through a couple similar >.http => >http edits and only saw one other period that could have been moved instead of deleted. PaleAqua (talk) 23:59, 15 June 2022 (UTC)

Hi @PaleAqua

You are clearly looking at this from a different perspective to mine.

What I was doing was removing stray characters from the start of a bare URL, so that tools such as Citation bot or WP:REFLINKS can fill the ref. I did this with various characters: letters, digits, /, comma, dot, curly bracket. I took no notice whatsoever of anything outside the ref tags. BrownHairedGirl (talk) • (contribs) 00:07, 16 June 2022 (UTC)

CfD closing instructions

See Wikipedia:Village_pump_(idea_lab)#CfD_backlog_and_closing_instructions. Your input would be most appreciated, if only because I still have a few questions about the current text (as indicated in the proposal). I realize you are no longer closing CfD discussions, but in the past you have closed so many that you probably still know what is important or not. Marcocapelle (talk) 06:25, 18 June 2022 (UTC)

Expanding archive.today to long form

Some example edge cases you may encounter:

• https://archive.today/Fcxt/image (and https://archive.today/Fcxt/image/)
• https://archive.today/wip/Fcxt (and https://archive.today/wip/Fcxt/)
• URL has a #selection which jumps to that portion of the page

Remove #selection then re-add after expansion to long-form

https://archive.today/TJbuX#selection-10133.0-10133.31

Also recommend conversion of the 6 domains to archive.today and https to normalize the URL, if not already.

-- GreenC 04:47, 20 June 2022 (UTC)

Many thanks, @GreenC. I know that you have a lot of experience with archived URLs, so your input is much appreciated (especially after last night's horrible encounter with an editor who displayed high aggression and low comprehension).

There are many points here, so I hope that you will forgive me for a long reply.

Basically, I have approached this as a four-step job:

• A/ Make lists of articles with non-bookmark form inline refs to archive.today and its aliases, as part of my set of routine scans of the database dumps for bare URL-related issues. (I had actually been making these lists from each of the last 5–10 dumps, but only in the last week did I find time to start work on them). The three sets (shortcut URL in: i) bare URL inline refs, i) |url=, iii) |archive-url=) added up to just over 10,000 pages.
• B/ Scan all those articles using an AWB custom module to extract the URLs to a simple list file.
• C/ Use a Perl script to grab the long-form URL from each of the archive URLs in that list, using the <link rel="bookmark" href= in the page's headers. That script ran in the background for about three days (using a random sub-10-second delay between HTTP requests to avoid triggering bot protections), and left me with a bit over 23,000 expanded URLs, plus a few hundred failures to get a bookmark.
• D/ Use another AWB custom module to edit the wiki pages found in step A, replacing non-bookmark URLs with the expanded URLs which I have placed in a big C# Dictionary. (It is not the most efficient approach, but simple to implement, and hence reliable).
  That job is being done in two passes, with half of the URLs in each batch. The first pass is underway, about 40% done.

There will be some followup tasks, but those 4 steps A–D cover the vast bulk of it.

I have logged all of this extensively. If those logs are of any use to you, I will happily email copies.

Pls forgive the numbered para reply style to your points. It's a bit formal, but I think it may be clearer.

1. The /image will be ignored by my method, because image files don't contain the HTML header on which I rely. They are part of the failure list in step B above, and will show up as residue later on, when I will try to figure out what I can do with them. Do you have any thoughts?
2. the /wip/ work-in-progress URLs have all been dealt with, by an AWB run to simply remove the /wip/: (?<url>https?://archive\.)(today|is|md|ph|fo|li|vn)/wip(?=/) -> ${url}today.
   I have saved the AWB settings with the wiki-text regex search which I used to find them, and will re-run the job periodically.
3. I caught the #selection thing early on, in my initial test of a regex to just find the unexpanded URLs. Luckily it was easy to include that in the relevant regexes: (?<url>https?://archive\.(today|is|md|ph|fo|li|vn)/(?![12]\d{11,})[^/>< \|\[\]\}\{#]+)(?<anchor>(#[^#>< \|\[\]\}\{]*)?)
4. i) conversion to archive.today: The <link rel="bookmark" href= appears to always link to archive.today (rather than .is/.fo/.md/.ph etc), so the URLs which I am expanding include that conversion.
   I have not checked whether it is safe to assume that the domains are always fully interchangeable, so for now I have separate entries in my conversion table for the difft domains: e.g. archive.fo/aBcDe and archive.ph/aBcDe are treated as distinct cases. I was not aware of any exceptions to interchangeability, but when working on big sets I think it's best to be safe.
   If you feel confident to assure me that I can safely rely on 100% interchangeability, then I will incorporate that in future runs ... and when this run of the expansion is complete, I will do a further AWB run to canonicalise all the URLs to archive.today. But only if you feel sure.
5. ii) conversion to https. In the 23K cases I have listed in this round, the <link rel="bookmark" href= has always given an insecure "http" URL, so I have used that as found. If you can assure me that it's safe to always convert to https, then I will incorporate that immediately.

One thing I found along the way is that the short-form URLs are indeed being used to evade the WP:Spam blacklist edit filters, which get triggered when I try to save the expanded URL. So far I have just been skipping these cases, because they are hard to log, but as a later pass I will start logging and fixing.

With about 25% of URL uses processed so far, I guesstimate that about 50 pages have been skipped, suggesting that the total might be very roughly 200 articles out of the ~10,000 articles I found in the 20220601 database dump. Once the backlog is cleared, I have a hunch that the blacklist evasions will form a significant proportion of new cases. It would be nice to do the blacklist checking directly on my list of expanded URLs (from step C above), but I haven't figured out how to do that. Do you have any ideas?

Also, when I have finished work on the inline refs, what would you think of doing the same expansion process with other URLs in articles?

Thanks again. BrownHairedGirl (talk) • (contribs) 12:38, 20 June 2022 (UTC)

Re: 4 & 5, https://archive.today will always work. The owner of the site wants us to use the today domain, is different from the others, it's a redirect server that sends requests to one of the actual servers (domains) where the content is located. This gives him flexibility in case a domain is ever blocked or goes offline he can redirect somewhere else. Apparently he has problems like that sometimes temporarily due to blocks and other things.

Re: blacklist yes there is evasion. It's time consuming to deal with, you could log a list, maybe the community would go through them.

Not sure I understand articles with non-bookmark form inline refs to archive.today and its aliases means (CS1|2 templates only?), but you could process all archive.today and its aliases why not. I have a script to do this in a single pass and have been slowly building a system based on Streams detection for full-auto on all 300+ wikis on a regular basis, but it's been on the back burner for a while. Enwiki is probably 30-40%. -- GreenC 15:47, 20 June 2022 (UTC)

Thanks again, @GreenC.

That explanation re the site structure is helpful. So I tried including all 23K URLs in my AWB module, and to my surprise it all worked smoothly, even tho the module is 4MB. Having pre-parsed the list of articles, there are now 6,200 edits to do ... and all the URL expansions in this batch (and future batches) will use https://archive.today/. I will cleanup the residue at a later point.

Sorry that non-bookmark form inline refs to archive.today and its aliases was unclear. By bookmark I mean the form of URL used in the <link rel="bookmark" href= header, i.e. with the date as a single string of digits, e.g. https://archive.today/20030920142606/www.ryczace20.pl/onas_martinez.php

This is distinct from the "canonical URL" also provided in the headers. For https://archive.today/20030920142606/www.ryczace20.pl/onas_martinez.php, those headers are:

• <link rel="canonical" href="https://archive.ph/2003.09.20-142606/http://www.ryczace20.pl/onas_martinez.php"/>
• <link rel="bookmark" href="http://archive.today/20030920142606/www.ryczace20.pl/onas_martinez.php"/>

I have been using the "bookmark" URL, tho now modifying it to use https. BrownHairedGirl (talk) • (contribs) 18:20, 20 June 2022 (UTC)

Ah I wasn't aware of those, have always used <input id="SHARE_LONGLINK" style="width:600px" value="http://archive.today/2003.09.20-142606/http://www.ryczace20.pl/onas_martinez.php"/> (with https and no -.) .. the problem with boomark it looks like 20030920142606/www.ryczace20.pl the "http" is missing. This is not ideal, my bot detects and fixes those. Could you use canonical with . and - removed from the timestamp? - GreenC 18:56, 20 June 2022 (UTC)

@GreenC: I was not aware of id="SHARE_LONGLINK". So it seems that there are three expanded options, plus the shortcuts. We are spoilt for choice.

I don't see why you say that the http is missing. I just checked https://archive.today/20030920142606/www.ryczace20.pl/onas_martinez.php again, and both book mark and canonical are as I posted them above.

In the 23k pages I checked, I found no cases of malformed bookmark URL. BrownHairedGirl (talk) • (contribs) 19:07, 20 June 2022 (UTC)

Yes three and none exactly right but all workable. In the bookmark I wonder what else might be incorrect like maybe missing anchors or percent encoding not right, would need to verify.

Diff of missing http:

• http://archive.today/20030920142606/www.ryczace20.pl/onas_martinez.php
• http://archive.today/20030920142606/http://www.ryczace20.pl/onas_martinez.php GreenC 19:20, 20 June 2022 (UTC)

Ah, thanks, @GreenC. I see it now: it's the "http" or "https" after the archive date in the middle which is missing. Sorry I was a bit slow.

Damn. I will stop using the bookmark.

That means dumping all the URLs I have grabbed so far, because I can't reliably choose between http or https. So I will have to grab a new set from canonical, basically re-starting the whole process.

Oh well. My framework doesn't need all that much adaptation, but it will benefit from the rewrite. BrownHairedGirl (talk) • (contribs) 19:54, 20 June 2022 (UTC)

Oh that sucks, well thank you for restarting. The one's that are done, I can fix those. In the past 3 days, you made 3,030 edits with an edit summary containing "with more transparent URL" shouldn't take too long to process. -- GreenC 20:08, 20 June 2022 (UTC)

Bless you for that, @GreenC. If you can fix those already done, that would be great. But ... how will you determine whether to use http or https?

Also, how did you count my edits with that summary? That's a handy thing to be able to do.

Restarting isn't too big a deal. I had already identified ways in which my process could be more efficient, and this gives me a poke to do it better. It shouldn't be too much work for me, just a few days of sweat for my utility PC. BrownHairedGirl (talk) • (contribs) 20:32, 20 June 2022 (UTC)

Been looking at your edit history and it appears archive.today only eliminated the http when it's http, not https. You might want to double check but that should make things easier.

The edit history is a tool called wikiget, the command would be wikiget -u BrownHairedGirl -s 20220618 -e 20220620 -i "with more transparent URL" to list the 3,030 article names. -- GreenC 21:09, 20 June 2022 (UTC)

Thanks again, @GreenC. That tool looks very handy! Nice work. I will be using it a lot. BrownHairedGirl (talk) • (contribs) 21:50, 20 June 2022 (UTC)

While you're at it, maybe its possible to remove the "/wip/" part of the url, since anything with the wip prefix will just redirect to the archived page (without the prefix)?

Of course not required but it could be something to think about.

Thank you for all that you do BHG. Also don't forget to respond to my email. Rlink2 (talk) 23:41, 20 June 2022 (UTC)

Thanks, @Rlink2. See above: the backlog of /wip/ is gone, and I will do periodic further cleanups. BrownHairedGirl (talk) • (contribs) 00:41, 21 June 2022 (UTC)

Thank you, glad you might find use for it. I use wikiget often for many things couldn't get by without it. The -a option is best for searching for articles containing certain domain (not -x). For example to find all ryczace20.pl wikiget -a "insource:ryczace20.pl insource:/([.]|\/)ryczace20[.]pl/" -- GreenC 00:08, 21 June 2022 (UTC)

Finding false negatives, examples Bad Wolves & Bee Movie. -- GreenC 02:23, 21 June 2022 (UTC)

Another problem: Special:Diff/1087130959/1094085942 .. which required the fix Special:Diff/1094085942/1094272698 .. surprisingly in about 1/3 of the pages, or about 1,000 pages out of 3,300 so it's common people are adding archive URLs in the |url= field. I know you did work before to shuffle URLs around in this situation, maybe it can be included in this process, after the expansion. Similar: Special:Diff/1079153135/1094086052 -> Special:Diff/1094086052/1094272783 -- GreenC 17:32, 21 June 2022 (UTC)

@GreenC, you are psychic! That sort of thing is exactly what got me into expanding the short URLs.

For the last few months, I have been running a few archive-related tasks after each database dump: to extract the original URL from refs with |url=archive.today/|url=web.archive.org, and from bare URL refs to both sites.

However, there has been an annoyingly big chunk of a few thousand cases of |url=archive.today/shortlink, which provide no original URL to extract. Nearly 3,000 in all, as of the 20220601 database dump.

That has frustrated me, and after much pondering, this month I set about expanding them ... so that my original-URL-extractor could work on them. That is still my plan, when I have rebuilt and re-run my URL expander (incorporating all your very helpful advice, for which many thanks).

I prefer to keep separate the two processes of URL expansion and original-URL-extraction. My computing skills began by hacking a PDP-11 back in the days when the man from Plains still lived in a plain wee Irish-designed shack, and somewhere deep in me the Unix philosophy is hard-wired: simple, single-purpose tools, which can be combined in various ways. God be with the pipe!

I am still a bit headachey and dopey today after losing some sleep 2 days ago due to my nasty encounter at bed-time with the vicious know-nothing who was reverting the URL expansion. I need to unplug for a bit and catch up on rest, so once I have finished setting Citation bot to work on the bare URLs from the 2022620 dump, I am taking time away from my the screen, to overeat Kashmiri curries and fall asleep to requiem masses which ha ve been slaughtered by the hideously bombastic ex-Nazi.

But I hope that by the weekend I will be back on the case of the archive.today links.

Thanks again. BrownHairedGirl (talk) • (contribs) 18:11, 21 June 2022 (UTC)

Ah you were actually targeting those, that explains why there are so many, I knew they existed but not at that density. Well take it easy, I think everything should be fixed up within an hour or so. I didn't know you planed on a second round (which is a fine method) so didn't mean to take your fire, there will be plenty more of this kind of work, endless. Yeah I'm also a Unix/pipe geek don't know how anyone gets by without it. Some programmers often try and do everything within their favorite language (Python, PhP, JavaScript) but they are stuck in a boat, Unix is the ocean. -- GreenC 18:54, 21 June 2022 (UTC)

Thank you

Just a random person wanting to say thank you for your behind the scenes work. You are noticed and appreciated. 24.179.59.46 (talk) 04:07, 21 June 2022 (UTC) Masked X

Thank you! That is very kind, and much needed right now, 'cos I am feeling a bit tired and worn.

Rath Dé ort BrownHairedGirl (talk) • (contribs) 18:15, 21 June 2022 (UTC)

That's BS!

		The Tireless Contributor Barnstar
		Thanks for consistently—and tirelessly—doing the gnomish tasks that few will tackle, and even fewer seem to notice. That's rough work. Don't Let the Bastards Grind You Down. You are great! GenQuest "scribble" 06:48, 22 June 2022 (UTC)

archive.today question

Hello, BrownHairedGirl, I noticed your bot "replaced 5 archive.today URL(s) with more transparent URL from <link rel="bookmark" " on Bad Brains discography. I am still new to all things Wikipedia editing, but I think what happened was the bot changed my shortened archive URLs to URLs with more 'stuff.' In the future, should I instead use the long archived URLs and not the short ones? Any quick notes or insight on why the shortened URLs are not as good would help me understand the bigger picture as well. Thanks for your time and for everything you do here! CharlesTStokes (talk) 02:56, 21 June 2022 (UTC)

A barnstar for you!

	The Special Barnstar
	For all your dedication and diligence on Wikipedia to keep things in order and straight. Most people don't want to do your thankless job which we all need done!!! ... my heartfelt appreciation and thanks... Ngrewal1 (talk) 16:36, 23 June 2022 (UTC)

Westminster Bridges Race

BHG,

Thank you for updating the Westminster Bridge Handicap Race page.

I'm the current organiser of the race...and likely to be the last one too.

I've canvassed the 250+ runners on the latest circulation list and the response was poor, to say the least.

I'm fascinated to know how you discovered us.

I'll re-read the current page and get back to you with any 'corrections'.

Thank you,

Hmm, I do have a Wikipedia login name, it might be Winston127 Should I have logged in before I started this?

Richard Whiting [...now retired]

Midnight_Voice@Hotmail.Com

146.90.232.191 (talk) 20:19, 25 June 2022 (UTC)

Ah, apparently, I'm WinstonRoad!

BHG,

Thank you for updating the Westminster Bridge Handicap Race page.

I'm the current organiser of the race...and likely to be the last one too.

I've canvassed the 250+ runners on the latest circulation list and the response was poor, to say the least.

I'm fascinated to know how you discovered us.

I'll re-read the current page and get back to you with any 'corrections'.

Thank you,

Richard Whiting [...now retired]

Midnight_Voice@Hotmail.Com

WinstonRoad (talk) 20:24, 25 June 2022 (UTC)

Hi @WinstonRoad

You did not link to any article, so I had to search for it. The best fit seems to be the the article Bridges Handicap Race.

I did not "update" the article; I just made a single technical edit[13] to alter how dates are displayed. This was one of tens of thousands of articles to which I made similar semi-automated edits over a few days, whilst paying zero attention to the content of the article.

Sorry to disappoint, but I have zero interest in this topic. If you think that the article should be modified or updated, please be aware that Wikipedia has a policy on conflict of interest, which applies here: see Wikipedia:Plain and simple conflict of interest guide. In a nutshell: please do not edit the article yourself, but feel free to go to the article's talk page at Talk:Bridges Handicap Race, where you can propose changes.

Please note that Wikipedia articles are based on reliable sources, so please include with any proposal the third-party source which supports the change you propose.

Best wishes, BrownHairedGirl (talk) • (contribs) 07:41, 26 June 2022 (UTC)

The Signpost: 26 June 2022

• News and notes: WMF inks new rules on government-ordered takedowns, blasts Russian feds' censor demands, spends big bucks

• In the media: Editor given three-year sentence, big RfA makes news, Guy Standing takes it sitting down

• Special report: "Wikipedia's independence" or "Wikimedia's pile of dosh"?

• Discussion report: MoS rules on CCP name mulled, XRV axe plea nulled, mass drafting bid pulled

• Opinion: Picture of the Day – how Adam plans to ru(i)n it

• Featured content: Articles on Scots' clash, Yank's tux, Austrian's action flick deemed brilliant prose

• Essay: RfA trend line haruspicy: fact or fancy?

• Recent research: Wikipedia versus academia (again), tables' "immortality" probed

• Serendipity: Was she really a Swiss lesbian automobile racer?

• News from the WMF: Wikimedia Enterprise signs first deals

• Traffic report: Top view counts for shows, movies, and celeb lawsuit that keeps on giving

• Gallery: Celebration of summer, winter

• Humour: Shortcuts, screwballers, Simon & Garfunkel

* Read this Signpost in full * Single-page * Unsubscribe * MediaWiki message delivery (talk) 22:30, 26 June 2022 (UTC)

Women in Red in July 2022

Women in Red July 2022, Vol 8, Issue 7, Nos 214, 217, 234, 235 Online events: New: Alphabet Run: A to B | Baltic States Continuing: Climate (year-long initiative) | #1day1woman See also: Women in Green's Good Article Editathon: July 2022 – Women and the Environment Other ways to participate: Join the conversations on our talkpage. Help us plan future events. Follow us on social media: Facebook | Instagram | Pinterest | Twitter

--Lajmmoore (talk) 15:45, 27 June 2022 (UTC) via MassMessaging

Saints

Could you perform your clean-up magic at:

• Saint symbolism
• Saint symbolism: Saints (A-H)
• Saint symbolism: Saints (I-P)
• Saint symbolism: Saints (Q-Z)
• Animals in Christian art
• Plants in Christian iconography

--evrik ^(talk) 23:54, 27 June 2022 (UTC)

@Evrik are there any specific issues? Or just general tidyup? BrownHairedGirl (talk) • (contribs) 23:56, 27 June 2022 (UTC)

• General clean-up. Thanks. --evrik ^(talk) 00:20, 28 June 2022 (UTC)

  @Evrik done in these 6 edits. BrownHairedGirl (talk) • (contribs) 00:30, 28 June 2022 (UTC)

• Thank you. --evrik ^(talk) 00:39, 28 June 2022 (UTC)

  You're welcome. BrownHairedGirl (talk) • (contribs) 00:41, 28 June 2022 (UTC)

AWB cosmetic edit

Be careful out there, or maybe adjust your script? – Jonesey95 (talk) 05:01, 28 June 2022 (UTC)