File talk:Screenshot Doom 20180603 143620.png

Bookkeeping issues when templating a redirect
For those who couldn't work out what I was saying (usually everybody), the result of my "research" is that we may be inconvenienced by edge cases, but not enough to create bureaucracy for.


 * If the template adds a maintenance category (as in this case), then it gets tracked. No problem.
 * If the template doesn't add a maintenance category and:
 * is added below the redirect command, the redirect works and also acquires any categories in the template. This is suboptimal but relatively harmless, since it only affects category display and many image categories are too large to be human-readable anyway.
 * is added above the redirect command, the redirect doesn't work and:
 * the template adds no categories at all, in which case the description page as a whole is uncategorized, and those are tracked.
 * the template adds other categories and:
 * the image is embedded somewhere, in which case the link gets broken, and those are tracked.
 * the image is unused, but since the file was physically moved at the OS layer to a new path/title when creating the redirect, the special page for unused files doesn't recognize it. This situation requires a maintenance script to identify; while maintenance scripts are always fail-safes for us, at least it's possible we'll get around to it.

In future MediaWiki versions, special pages should find more classes of dubious image links, due to this, this, and this.

Inaccessibility of old description page revisions was transient (worked again 2 hours later), and intentional. Redirects accrete considerable metadata, e.g. for speed and to hide them on special pages, so they can take much longer to process than category links.

Selfishly categorizing this talk page for future reference. Ryan W (living fossil) 14:04, 17 June 2018 (CDT)