User talk:DragonflySixtyseven/Maintenance stuff

Why do these matter?

2, 5, and 8 should be self-evident.

Lead/Led

Would -linksto:Lead help here by eliminating the metal, e.g. The heaviest stable atom is lead-208 (from Atom)? Certes (talk) 11:08, 22 February 2019 (UTC)[reply]

It should, yes. I'll incorporate that, thank you. DS (talk) 13:28, 22 February 2019 (UTC)[reply]

I've looked through this section and fixed about 300 errors. I've not marked false positives because many are in phrases like the houses have lead roofs or Anna Daptor and Mike Stand were lead guitarists with Garageband, where sic feels inappropriate. If anyone does want to mark them then that job should now be easier. Have/has/had/having were much more likely to be wrong than being/been/are/is (and be, which I added). I looked at which lead and that lead but made no edits. Each occurs thousands of times but the samples I studied had 95% false positives.

This task did require human intervention but we can probably automate a subset such as be/being/is/was/were lead by/to/into (the team was lead by the captain, etc.). These cases were universally wrong, apart from a handful of quotes which preserved typos in their sources. Certes (talk) 17:20, 23 February 2019 (UTC)[reply]

@Certes: "which eventually lead", "which subsequently lead", "which soon lead", etc. DS (talk) 00:01, 24 February 2019 (UTC)[reply]

Good spot. A few (e.g. Dolores Claiborne) are present-tense narrative but most look like errors. Certes (talk) 00:51, 24 February 2019 (UTC)[reply]

Filenames

My principle on filenames: is it plausible that someone would upload a completely different image for a completely different purpose, and give it this exact name? (True, the system warns you when you're about to do this - but far too many people just click through warnings without reading them.) If yes, then the name should be changed. Short names are far more likely to be re-used; thus, the ShortNames tool.

Dangling referrer tags

Reasons to get rid of referrer tags:

they bloat the code. Not by much for an individual page viewed once, but scaled up to the size of Wikipedia's database, millions of times per day? Based on almost no data, I estimate that this consumes as much as 1% of our daily bandwidth. Also, if you added a URL to an article and it includes a referrer tag, that can provide information about you — information that you might rather not have it provide. Also they screw with the archive bots (which means that sometimes, sigh, you do have to leave them in, because somehow archive.org grabbed a copy of the page with the referrer tags in its URL but not without them, so make sure the URL is still valid even without the tags!). DS (talk) 03:34, 6 June 2019 (UTC)[reply]

Agreed, though I would prioritise privacy over bandwidth. Removing the tags may also prompt archive sites to index the page under the tag-free URL, which helps future readers seeking the page from other Wikipedia pages or directly. Ideally the archive sites would remove those tags themselves, both when choosing pages to store and when retrieving them, but their resources may not allow handling numerous changeable site-specific formats. Certes (talk) 08:42, 6 June 2019 (UTC)[reply]

Refnames

This is an issue of human usability. The machine-generated minimalist names ":0", ":1", ":2", etc, are fine for a write-once-edit-never context, but the instant a second edit is made, they become a hindrance. When other references are introduced in the middle of the text (or when paragraphs are rearranged), the numbers in the reflist automatically update themselves, but numbers in refnames do not, and thus ":2" can be the 7th reference, etc.