User:Wilfredor/commons-subcat-overlap
| Description | Which files in a category are also in a category below it |
|---|---|
| Author | Wilfredor |
| Status | Maintained |
| Updated | 2026-09-04 |
| Source | User:Wilfredor/commons-subcat-overlap.js |
Overview
[edit]commons-subcat-overlap answers one question on a category page: which files sitting directly in this category are also in a category below it, and through what path?
A category page lists the files it holds and, separately, the subcategories under it. It never shows the overlap between the two, and finding it by hand means opening every subcategory and comparing lists.
What it adds
[edit]- Nothing to press. The page reads itself as it opens and the marks are there when you arrive. A category with more than a hundred subcategories waits instead, with the reading behind a word in the line, since the cost rises with the width of the tree.
window.commonsSubcatOverlapAuto = falseputs every category behind that word. - One line immediately above the files, under the Media in category heading, with a bar that walks while it reads. It looks one level down, which is where nearly all the overlap sits;
window.commonsSubcatOverlapDepth = 2goes deeper. - It reads the files the page is showing. A category of nine thousand comes in pages of two hundred, and each page reads itself as it is opened, so every finding is in front of you rather than on a page you are not on.
- The line says how many files were read, how many are also below and how many of those nothing explains. Everything else is on the thumbnails.
- The answer written on the category page's own thumbnails. Whether a photograph belongs in both categories depends on what it shows, so the finding has to reach you where the picture is. A marked thumbnail says what it is also in, one subcategory named outright or a count that opens into the list, and why it was read the way it was. There is no list of results anywhere, because a list beside the thumbnails is the same findings twice with a scroll between them.
- A tag on the groups whose subcategory carries {{Non-diffusing subcategory}}, which says outright that its content is in the parent as well, and a tag on the groups that hold a single file.
- How many places each file is below in, on the file itself. A photograph in five subcategories is almost always a general view, a street with five buildings on it or a group with five people in it, while a photograph in exactly one is where the parent may have nothing left to say.
What it does not do
[edit]It never edits anything. No page is written, no maintenance category is added, no backlog page is built and nothing is queued for anybody else. The result lives in the browser tab and goes when the tab goes.
That is deliberate. A file being in a category and below it is a description of the tree, not a fault: a photograph can belong both in a street and in a building on that street, and a group photograph can belong both in a category for the group and in the category of one person in it. Whether a particular file is redundant depends on what it shows, which is not in the category tree.
Why it groups
[edit]Measured on Category:Second Avenue, Seattle: 617 files, 81 subcategories, 252 files also below, through 55 relationships. File by file that is 252 things to read. By relationship it is 55 lines, the top of which are whole buildings on that street, which is a street-and-building structure rather than 76 mistakes. Seven relationships held a single file, and those are the ones worth a human's attention.
Category:Members of the Seattle City Council, the other case raised in the proposal: 71 files, 60 subcategories, 13 files also below, through 10 relationships, 4 of them holding a single file.
What it can and cannot tell you
[edit]The category tree can say that a file is in a category and below it. It cannot say whether that is right, because that depends on what the photograph shows. What the tool does instead is separate the findings that something explains from the ones that nothing explains yet, and say which is which.
Two readings are cheap and come with the run. A file that is below in several places at once is almost always a general view, a street with five buildings on it or a group with five people in it. A file whose own name carries the subject of this category is a file about this category, and on Category:Second Avenue, Seattle that is how most of them read. Of the 252 findings there, 109 are below in several places, 73 name the avenue in their own file name, and 70 are left to look at. On Category:Members of the Seattle City Council, 9 of 13 are below in several places and 4 are left.
One reading is expensive, one request per file, so it runs over the files that are left rather than over all of them, and only offers itself instead when there are more than twenty five. It reads their edit summaries and asks whether this category was added in the same edit as the one below it, added afterwards, or was here first while the file was filed below later. Only the last of those looks like something forgotten, and it is the one that gets a border of its own. A file somebody decided goes quiet, a file whose history says nothing keeps the border it had. Measured on 22 of the ones left in that street category, 8 were the same edit, 4 were added afterwards, 1 had the shape of an oversight and 9 said nothing.
The borders are the whole of it. Pale means something explains this file, amber means nothing does yet, red means this category was here first and the file was filed below afterwards. Hovering says which in words.
Categories marked with {{User category}} are exempt from over-categorisation by the rule itself, and the panel says so instead of listing findings.
Nothing here is a verdict. Every mark carries the reason it was read that way, and where nothing explains a file the tool says nothing rather than calling it wrong.
How it reads
[edit]The crawl keeps a visited set, so a category is walked once and a cycle in the tree ends instead of running for ever. It stops at 300 categories and 5000 files, and says so in the panel when it does: a truncated answer that looks complete is worse than no answer.
Each batch of files is asked only about the categories the crawl found, which keeps the answers small and exact. Batches are bounded by URL length rather than by count, because fifty long Commons file names plus fifty category names exceed what a GET request is allowed to carry. Measured on Second Avenue, Seattle: 49 requests.
Proposed and discussed at Commons:Village pump, 27 August 2026.
Installation
[edit]Add this line to Special:MyPage/common.js and reload with Ctrl+⇧ Shift+R:
importScript('User:Wilfredor/commons-subcat-overlap.js');