User talk:SD0001

Archives

Archive 1	Archive 2	Archive 3
Archive 4	Archive 5	Archive 6
Archive 7	Archive 8

This page has archives. Sections older than 60 days may be automatically archived by when more than 4 sections are present.

This user doesn't subscribe to mass messages. Instead they prefer to read them off other users' talk pages!

Question about GA bot statistics

Hi .. I have a small suggestion on how to improve wording of the report from the bot that computes GA/FA statistics. Someone said you manage that bot. If you have time, could you check out Wikipedia_talk:Good_article_nominations#GA_statistics_bot_"SDZeroBot"_..._wording_in_its_report_could_be_better. Thanks! Noleander (talk) 00:06, 10 May 2025 (UTC)[reply]

DYK helper still needs fixes

I see you're recently active, so any chance you can please look at User_talk:SD0001/Archive_8#DYK_helper_needs_fixes and User_talk:SD0001/DYK-helper#Edit_request_2, or at the least explain why you hadn't gotten to these requests before? ミラP@Miraclepine 22:15, 23 May 2025 (UTC)[reply]

Busy with other things. I can try to get to it next month. – SD0001 (talk) 07:44, 24 May 2025 (UTC)[reply]

Thanks for the info, though we may someday have to make it a community gadget in case of prolonged inactivity on the maintainer's part. ミラP@Miraclepine 15:35, 24 May 2025 (UTC)[reply]

A version of it already exists as a community-maintained script: MediaWiki:DYK-nomination-wizard.js which runs on WP:DYKSUBMIT. But that doesn't automatically mean people will have the interest + know-how to maintain it. Effectively, I'm still the only maintainer.

(Ideally, DYK-helper should be trimmed down to just create a menu item that links to WP:DYKSUBMIT so that I don't have to maintain two versions. But people didn't seem to like last time I proposed it.) – SD0001 (talk) 17:13, 24 May 2025 (UTC)[reply]

Hot articles bot not updating

I have noticed that at WP:WikiProject Insects/Hot articles, it says that it was last updated 2 years ago (5 June 2023), yet this page is listed as to be updated on your bot's user page. Can you fix this so that it actually updates? Element10101 AIW WPI TOLT ~ C 19:50, 3 June 2025 (UTC)[reply]

It's not being updated because Category: WikiProject Insects articles is too large. There's a limit of 100,000 articles beyond which updates are skipped. – SD0001 (talk) 10:57, 6 June 2025 (UTC)[reply]

Ah, ok. Element10101 AIW WPI TOLT ~ C 15:16, 6 June 2025 (UTC)[reply]

Wrong user

Wrong user. Pay attention next time or you will be permanently banned. This is your only warning! 185.85.154.216 (talk) 13:04, 6 June 2025 (UTC)[reply]

Looks like this is a response to User_talk:185.85.154.216#April_2021. You do realize that someone else was using the IP four years ago, right? – SD0001 (talk) 13:23, 6 June 2025 (UTC)[reply]

Election clerk

Quick question - you added @DreamRimmer to the election clerk group (log). The policy worked out was that only admins would be granted the right. What was the purpose of granting DreamRimmer the right, since they're not an admin? And could you revert your action? Thanks. —Ganesha811 (talk) 19:47, 10 June 2025 (UTC)[reply]

It was added temporarily for testing as DreamRimmer wrote the config changes (phab:T378287) and it ended up causing a production error (phab:T396483). They confirmed a couple of hours ago that it can be removed now. Done. – SD0001 (talk) 20:34, 10 June 2025 (UTC)[reply]

Sounds good, thanks. —Ganesha811 (talk) 20:35, 10 June 2025 (UTC)[reply]

Regarding Good article promotions #2

@SD0001::Hello and good night! Sorry for bothering you in case you are busy but i need to notify an issues regarding this page (https://sdzerobot.toolforge.org/gans?user=KGRAMR): the Cho Ren Sha 68K listing has an erroneous date (1970-01-01) instead of the date when it was approved by the reviewer (2025-06-23). If you can fix the issue in anyway i would be grateful but if not then no worries. Thanks and have a good day :) Roberth Martinez (talk) 11:30, 23 June 2025 (UTC)[reply]

Fixed. Thanks for reporting. – SD0001 (talk) 12:39, 23 June 2025 (UTC)[reply]

Draft:Internet brainrot

Hello, SD0001,

I delete a lot of stale drafts and I was looking at this one which is due to be deleted in about 6 or 7 hours. Last time it was eligible, you untagged the draft article so I thought I'd alert you in case you wanted to save this one again and do some work on it. Since you are an admin, you can always restore it if you see this note after its deletion.

I hope all is well with you! Liz ^{Read! Talk!} 03:57, 26 June 2025 (UTC)[reply]

Resource caching

Hi SD0001. I noticed a few minor things with the User:SD0001/Making user scripts load faster code:

You may want to add &rvslots=main to the query to avoid warnings in the response. Then, after const main = apiPage.revisions[0].slots.main;, you can access main.content and main.contentmodel.
These days, .textContent is preferred over .innerHTML for script injection.
I ended up switching to a different approach to "flush" the cache when needed. Adding &curtimestamp=token (booleans are pretty permissive) to each request allows refreshing resources when the token is updated. I tied it to a user option that toggles between 0 and a random number, so turning caching off and back on ensures everything is refreshed. (And a persistent option to turn off caching is also helpful sometimes.)
I made some other minor changes such as switching to .some() instead of .find(), regex tweaks, and adding return values for the wrappers if you are interested at Start.js (the other parts are a bit of a work-in-progress).

Daniel Quinlan (talk) 01:37, 30 June 2025 (UTC)[reply]

Hi, thanks for the note. Regarding points 3-4, User:SD0001/Making user scripts load faster is meant to load scripts as fast as possible, but without requiring any changes to the way users add or remove scripts - which is through importScript statements in their common.js. If we were to relax this constraint, it's certainly possible to speed up things up even further, as well provide precise cache clearance mechanisms along the lines of what you're exploring in Start.js.

The fastest approach I'd imagine would be to develop a toolforge service into which users can give a list of scripts, and the service would combine them and edit it (via OAuth) into their common.js page. No more http requests at all! (Except for the common.js itself, but that is already cached by ResourceLoader.) A drawback is that common.js must parse to be valid ES2017, a restriction that doesn't apply to importScript'd pages. Maybe the service could transpile down any unsupported syntax using esbuild. – SD0001 (talk) 15:56, 1 July 2025 (UTC)[reply]

For point 3, I found adding URL parameters to be somewhat cumbersome while using this on my phone so I wanted to share an alternative approach that has been working for me and should be compatible with your design (adding a user option and portlet link would make it longer, of course). For point 4, I was only suggesting several small tweaks (using .some() instead of .find(), the regex adjustments, and adding return values), things that were more minor than points 1 and 2 (updated the link above to make that clearer). Regards. Daniel Quinlan (talk) 13:15, 3 July 2025 (UTC)[reply]

A barnstar for you!

	The Technical Barnstar
	Very nice job with your recent deploy.js scripts (at both Twinkle and AFCH) and with https://gadget-deploy.toolforge.org/. Deploying complex gadgets now takes zero brainpower and is just a button click. Huge efficiency. Before the process was laborious. And any JS dev can now maintain the deploy scripts too. Thanks so much. –Novem Linguae (talk) 05:13, 2 July 2025 (UTC)[reply]

At some point I will probably do a burst of work on MediaWiki:Gadget-XFDcloser.js. Maybe we can get that one converted to this new deploy system at that time. The current work instruction for deploying that one is at User:Novem Linguae/Essays/Deployment notes#XFDcloser. It already had a node.js deploy script, but that one is tedious to deploy because there are lots of extra steps (version numbers, beta vs main). Maybe I'll strip all that out. –Novem Linguae (talk) 05:15, 2 July 2025 (UTC)[reply]

Thanks! We have instructions on adding new gadgets. XFDcloser should be straightforward with a few minor changes – the deploy script needs to accept OAuth tokens and perhaps have a -y flag to bypass the "press enter to start deploying" requirement.

By the way, the "sync your forked github to main github using github's web interface" step that appears in your guides seems skippable. I haven't synced my fork in eons. I just set the master branch of my local repo to track the original repo directly. – SD0001 (talk) 15:38, 2 July 2025 (UTC)[reply]

Wow, the readme documentation for your toolforge tool is really good. You really hit it out of the park with this project. Very impressive.

I've filed https://github.com/wikimedia-gadgets/xfdcloser/issues/101 for XFDcloser. –Novem Linguae (talk) 02:35, 3 July 2025 (UTC)[reply]

Haha, the documentation was mostly generated by Cursor's AI agent. All I had to do was to rewrite parts of it and cut down superfluous stuff. – SD0001 (talk) 09:23, 3 July 2025 (UTC)[reply]

Nice to see a dev that can properly use AI, and not just make slop and work for others with it like so many do. –Novem Linguae (talk) 14:04, 3 July 2025 (UTC)[reply]