Commons talk:Categories

Categorization by tiny background objects

Truck, yes, tiny cars in the background NO

A number of users insist on categorizing photos by tiny objects in the background. One user categorized the photo on the right by the two little cars lurking on the right, which to me is not what categories are for. No one who navigated to Category:Honda Freed (1st generation) would be in any way helped by this photo. Incidentally, I see thirteen other photos in that category that should not be there, for the same reason. See this one, for instance. Could we include a sentence or two about what is the subject and what merits inclusion in a category? mr.choppers (talk)^-en- 03:32, 12 February 2025 (UTC)

Generally agree, though if there was (for example) an equally small Ferrari in the background, I might feel differently. - Jmabel ! talk 04:18, 12 February 2025 (UTC)

Also generally agree, though for more rare subjects where there aren't many other good choices, it can make some sense. For some other cases, if a crop could be made which could serve as an effective illustration of that subject, I might also see it (high-resolution photos can have this aspect sometimes). For a category of say a particular individual plane, I could maybe see it -- it can show what the livery etc. was on a particular date. But if obscured or out of focus, probably not. If on the other hand it was our only photo of that particular plane, then maybe it could be of more interest. A photo like File:JFK and Marilyn Monroe 1962.jpg is not a particularly good photo of JFK or his brother, but is apparently the only (or one of few not confiscated) photo which has both them and Marilyn Monroe in it, so is pretty well-known and thus widely-used -- and as a result, people have identified people in the background and added their categories too. So particular famous photos may have background details scrutinized and be of interest. Not sure what the best wording should be on a guideline like that. I do see the other side though -- Category:Unidentified ships is overpopulated with many photos which only show the smudge of a ship in the background on the horizon and could never serve as a suitable illustration for it, yet people insist on adding that category. I do tend to agree that in many/most cases, the categories should be for the primary elements which the photo itself could be used as an illustration, but I can see exceptions for rarer subjects, or some other particular situations mentioned above or ones I haven't thought of. Another approach is making a subcategory such as Category:Corvus frugilegus (incidental), which is specifically for that type of image, taking them out of the main category. I do see a fair number of categories using that pattern out there. Carl Lindberg (talk) 05:10, 12 February 2025 (UTC)

Agree. This is also relevant to videos – see my proposal for time segment qualifiers for videos where something is only shown for some duration. Prototyperspective (talk) 15:45, 12 February 2025 (UTC)

I think that if something is rare enough and the quality is good enough to extract it, we would do so, and categorize that image. I did that here, and that remains the only freely licensed image of a Hino Briska.

But the question is what are categories for? Are they simply for identifying everything in a photo, or are they there to help users find images of stuff? To me it's decisively the latter (I also don't like it when people try to add every conceivable category there is for their photos; feels pushy and pointless), and for mere identification we can add notes instead. I, too, pride myself on being able to identify cars based on a blurry glimpse, and notes serve my purposes just fine! mr.choppers (talk)^-en- 02:27, 13 February 2025 (UTC)

• Agree nip this in the bud now before it destroys the usability of categories altogether.

Laurel Lodged (talk) 08:24, 13 February 2025 (UTC)

I think that if something is rare enough and the quality is good enough to extract it, we would do so, and categorize that image – sure, that’s the best solution. However, not everyone and every time can do that (lack of experience / time / suitable software, they’re editing from a smartphone, for example while travelling, etc.). Should they not tag the file as potentially useful for illustrating the topic? Maybe there could be a template to flag the file as suitable only after cropping, but I think the category should be added in addition to that, so that people looking for illustration can find it through the category tree (and of course both the template and the category removed once the crop is uploaded). —Tacsipacsi (talk) 19:46, 14 February 2025 (UTC)

Maybe there could be a template to flag the file as suitable only after cropping I like that idea, it's similar to what I proposed for videos linked above and the same method could be used which is something that is set like a setkey but instead of catname|sortkey it could be catname/minor for which the HotCat gadget could get a checkbox. This could for example be used to make these show up further down in the search results (which need improvements) as well as on the category page. Prototyperspective (talk) 00:12, 15 February 2025 (UTC)

I think categories are to show any photo of interest to the topic in question. There may be some topics which don't have better images, or maybe it's of interest for a subject to appear incidentally in a famous photo, or some other circumstances. Or if the photo is high-resolution enough that a good crop could be made, maybe. But for the most part, I'd say the categories are for what the image itself could be used to illustrate. You don't want to see a category cluttered with images of marginal relevance. It's certainly possible to add an image note for incidental details so identification effort is not lost, without adding the category. Carl Lindberg (talk) 23:30, 14 February 2025 (UTC)

If something is rare enough and the quality is good enough to extract it, then snip it from the larger image so that the rare thing is the dominant part of the snipped image. This assumes that the snipping does not result in excessive pixelation. Laurel Lodged (talk) 10:09, 6 June 2025 (UTC)

Agree that cropping and then only having the category on the extracted image would be the right way to go about this (if that's what you meant). However, the more difficult part is when the user doesn't want to do that (for now at least) but the thing in the background is valuable to have an image of. For example, it could be something of which Commons only has one or two low-quality photos so that despite it being in the background it would be useful. So it's not always so simple but generally I'd agree. Prototyperspective (talk) 10:28, 6 June 2025 (UTC)

copyright

i don’t know how to describe images i put its a quite a lot work so I got message about copyright but cant edit it. even log in in wikipedia can you help me this images are on the flemish art website made by government so i just needs to confirm there is no copyright issues i got this images for free for my work as artist. my painting i did by myself thank you andrej Babenko 2A02:A03F:67DE:B000:C108:1FE7:4111:C61A 07:04, 11 October 2025 (UTC)

Hi, Please log in, give an example of images (author, date, etc.) and move your question to the copyright board. Thanks, Yann (talk) 08:22, 11 October 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 17:23, 23 October 2025 (UTC)

How many categories?

How many categories are there on Commons? Prototyperspective (talk) 22:46, 14 October 2025 (UTC)

Machine translated category titles

Category titles are generally short and get translated accurately in ~99% of cases. Having machine translated category titles would be hugely beneficial for users and the project because:

• People searching for media or free media online in their own language would more often come across Commons
• It reduces the workload on volunteers translating things by hand via category descriptions albeit just very very few if any users are doing this frequently/extensively where even the large categories linked on the Commons frontpage have no or just very few translation (also this only affects the category description but not the category title and URL; other language redirects like Category:Tiere are just a random occasional barely found thing)
• If more people use and come across Commons, this increases the awareness and number of users and contributors of the project, making all our work, the platform, and free media overall be more useful and impactful
• It would make Commons more multilingual and more accessible to users of varying backgrounds and language skills and located worldwide

I created a wish about this in the Community Wishlist – it's now open for voting: W214: Add machine translated category titles on WMC.
Prototyperspective (talk) 17:31, 23 October 2025 (UTC)

Merging categories with identical scopes

A dispute has arisen over whether categories for the two Boeing aircraft construction number systems should be merged or left apart. For context, Boeing uses two separate construction number systems to designate their aircraft. As such, each Boeing airliner is given both a unique "manufacturer serial number" (msn) and "line number" (ln). Currently, there are separate categories for msn and ln (for example, Category:Boeing 747-8 (msn 37075) and Category:Boeing 747-8 (ln 1449) both refer to the same individual aircraft). Unlike an aircraft's registration, which can change multiple times throughout said aircraft's service life, an msn/ln pairing never changes from the moment it is built to the moment it is scrapped or otherwise destroyed. In a sense, an msn/ln pairing is the absolute identifier for an individual Boeing airliner. As such, an aircraft's "msn" and "ln" categories should always be populated the identical subcategories and pages with identical sorting. It is my understanding that this is a textbook example of COM:OVERCAT and should be merged. If I am mistaken, please let me know.

It should be noted that there are many thousands of "msn" and "ln" categories just like the above example, so if this is indeed OVERCAT, then it will be a huge effort to clean it up manually. Perhaps it could be a task for a bot.

Pinging Ardfern, who has been the other side of this dispute. - ZLEA _T\^C 03:16, 1 November 2025 (UTC)

I think it's fine the way it is, the existence of these additional categories does no harm. Perhaps it would be good to link with {{See also cat}} though. - Jmabel ! talk 20:55, 21 November 2025 (UTC)

Recommending populating categories at creation

Regarding how the creation of categories, this page currently has

To create a new category:
[…]
2. Find images (or a gallery or other pages) which should be put in the new category. Edit this page, and at the end insert the new category reference. e.g. . Save the edited page. The new category appears as a red link at the bottom of the page.

So a user adding just one image to a category and then creates it, leaving it near-empty like that would be perfectly following this policy.

Creating categories containing only one file or very few files when there are more (or a tiny fraction of files that belong into it) I think is not beneficial overall. Such categories give people – who open them via Commons search, Web search, file cats, or category-subcategory browsing – a wrong impression of what's on Commons relating to the subject, aren't useful, and are basically misleading.

Thus, I suggest that text is added to the section Creating a new category where it's recommended that people also do a thorough search to find and add files in the scope of the new category before or directly after creating the category. It could also be worth considering making some effort to populate a category a requirement to mitigate more of excessively incomplete categories being created and facilitate more users properly adding files to new categories.

Currently, if a category has not yet been created instead of created with just very few files, then another user who creates the category will usually do a thorough search to check whether files are missing. This is a much rarer practice for categories that already exist as people assume the person who created it and other visitors likely already did so (not always of course, just more often/usually).

The Creating a new category section could also inform about techniques on how to find relevant files such as using search term + deepcategory:"a parent category that contains relevant files" in the search and/or about the tools Cat-a-lot and HotCat which can make populating a category much easier, quicker, and accessible than the antique plain wikitext-editing for adding categories that's barely used anymore but described in this subsection. Ideas and suggestions for the text could be added to this thread here. Prototyperspective (talk) 17:37, 21 November 2025 (UTC)

I would agree that should be recommended, but it should be understood more as a "best practice" than as a command. I usually try to do that, but I can think of times I've skipped it, especially when introducing an intermediate category in the hierarchy to make sure a "leaf" category I'm adding gets an ancestor structure similar to other parallel categories. For example, if someone were introducing Category:John T. Williams memorial pedestrian crossing and Category:Howell Street, Seattle didn't already exist, so they had to create it, I wouldn't necessarily consider them obligated to see if they could further populate Category:Howell Street, Seattle. Great it they could do that, but far from required. - Jmabel ! talk 21:03, 21 November 2025 (UTC)

One could also add it like that and then maybe think about whether to phrase it less like a mere recommendation. One could also name exceptions or broad principles/types of categories where this doesn't make sense.

if someone were introducing Category:John T. Williams memorial pedestrian crossing and Category:Howell Street, Seattle didn't already exist, so they had to create it, I wouldn't necessarily consider them obligated to see if they could further populate Category:Howell Street, Seattle. the better course of action would be to just add the category as a redcat if they don't populate it and the closest existing category such as Category:Public art in Seattle. Somebody who sees the category due to the other categories set on it or otherwise, can create the category if they also populate it. If your goal is to create a certain category, there is no need and no justification for creating misleading incredibly incomplete intermediary categories just because they fit on the category one wanted to create. The effect here is not the user populating a street category but not creating the empty street category but leaving it e.g. to users motivated & skilled to do so or users who frequently or routinely create street categories and know what to do and how. Creating empty or very incomplete categories at least at this point is unconstructive.

Also, I'd like to add that the guidance in that section currently describes things as if the HotCat gadget was not a default-enabled gadget. Prototyperspective (talk) 15:42, 24 November 2025 (UTC)

@Prototyperspective: I'm having trouble following at least some of that response. the better course of action would be to just add the category as a redcat: not sure which category you mean. If Category:Howell Street, Seattle, I disagree. It's much more likely to get populated if it is visible when coming down the hierarchy from Category:Streets in Seattle. - Jmabel ! talk 19:53, 24 November 2025 (UTC)

Yes, Howell Street, Seattle which you said you didn't populate. I outlined earlier and multiple times why it's problematic if categories are heavily incomplete. I could expand on that but I'm not sure if it was unclear or if you have anything to address those things. Such categories would be more likely to get populated if you leave creating them to those that do substantially populate them at creation. There are lots of fine-resolution subcategories around all the relevant topics already. Maybe it would be more likely to get a file here and there but it's not much of a help if it has just 2 or 4% of files. The course of action proposed here is to also populate the new subcategory you think should be set on a category you're also creating. The second best option would be to just use the closest category and leave creating the category to somebody who will populate the new category. That small category already has

Pedestrian crossings in Seattle

Boren Avenue, Seattle

Deer in art

Public art in Seattle

Monuments and memorials in Seattle

Denny Triangle, Seattle, Washington

Decorated pedestrian crossings

White road markings in the United States

plus a good substitute of the category Howell Street, Seattle which is one (or multiple) of the parent categories now set on it. Again, all fine if you put a sizable fraction of the files that belong into it into it but if not how could people even tell that's a stub category with <1% of files? It's not useful and obstructs populating categories as such is usually done when creating a new category. Prototyperspective (talk) 23:25, 24 November 2025 (UTC)

No, I did not say I did not populate Category:Howell Street, Seattle. Please re-read my remark, which was in the subjunctive and referred to a hypothetical situation for a hypothetical user. - Jmabel ! talk 01:17, 25 November 2025 (UTC)

You're right on that, sorry. I'm addressing the hypothetical then which you argued by/for, not what was actually done. Prototyperspective (talk) 15:33, 25 November 2025 (UTC)

(In fact, we seem to have few pictures along that street; if we have more, there is no indication in their respective descriptions. I still think it is an appropriate parent for a crosswalk category, even if it makes for a barely-populated category.) - Jmabel ! talk 01:23, 25 November 2025 (UTC)

we seem to have few pictures along that street; if we have more, there is no indication in their respective descriptions In such cases it would be totally fine with what was proposed if it's put into stronger language than a mere loose recommendation.

• It's about some minimum level of checking whether there are files that belong into the cat and adding them (e.g. searching for name of category and then from these search results adding the relevant ones)
• / about the fraction of files that are added to the cat compared to all files on Commons that belong into it

not about the total number of files in the cat (see when there are more in the original post) Prototyperspective (talk) 15:37, 25 November 2025 (UTC)

In practice, I believe I usually do a fair job of populating categories I create, but I don't think that is incumbent on everyone who creates a category. - Jmabel ! talk 01:26, 25 November 2025 (UTC)