Commons:Categories for discussion/2016/12

I don't see any clear difference between Category:Stereograms, Category:Stereographs, and Category:Stereo images. Given that en:Stereogram can have a variety of meanings, I would suggest it be converted into a disambiguation category. I'm fairly neutral on Category:Stereographs vs. Category:Stereo images (or perhaps Category:Stereoscopic images, the descriptive text currently in "stereo images") but unless I'm mistaken, we really only need one of these. Themightyquill (talk) 11:16, 1 December 2016 (UTC)[reply]

@Themightyquill: Wow, I agree, and can't believe this has no comments after 1.5 years. I created a subcat and then found them all. I was concerned there was some technical distinction; if not, it's a mess as it is now. Outriggr (talk) 04:57, 13 May 2018 (UTC)[reply]
Hm, I guess you're not including Category:Stereo cards? I'm not sure I see a basis for separating "cards" and "images", which is my biggest point of confusion. "Cards" is way more organized and extensive in its subcategories than "images". But the slight difference in final media format is not significant enough to have entirely different category trees that would prevent users from finding topically similar material. I made Category:Stereo images of Brooklyn and put a parent cat of Category:Stereo cards of New York City. I would rename everything to "stereo images", the more inclusive concept. Outriggr (talk) 07:23, 13 May 2018 (UTC)[reply]
Good point, Outriggr. I can't remember if I missed Category:Stereo cards or avoided it intentionally, but I've tagged it now in the hope for additional input. I see that category is a sub-category of Category:Parallel-view stereo images, and there's a peer category Category:Crosseye-view stereo images as well. I'm not sure how important that difference is. Perhaps the creator(s), Chowbok and/or ArnoldReinhold can help. --- Themightyquill (talk) 07:47, 13 May 2018 (UTC)[reply]

Stereo cards are cards that go into stereoscopes: each card has two images on it. Not all stereo images are on cards or need stereoscopes: some are meant to be looked at without the aid of any device. And while stereo cards include stereo images and therefore can be a subset of stereo images, stereo images should not be a subset of stereo cards. I would not like to lose the separate stereo card categories, because they have historical interest. --Auntof6 (talk) 18:24, 13 May 2018 (UTC)[reply]

My involvement with the two categories Category:Parallel-view stereo images, and Category:Crosseye-view stereo images was in changing their title to images from photos. The distinction is important as the two type are viewed differently. The difference is explained at w:Stereoscopy#Freeviewing, with links to the two categories. I think they are important to keep. I looked at Category:Stereograms and Category:Stereographs. The stereograms were mostly computer generated, I recategorized the few that were not. The Stereographs were mostly of two types, stereo cards from the Metropolitan Museum of Art and stereo cards from Flickr. I would suggest renaming Stereograms to Computer generated stereograms, and maybe recategorizing the MEt images, (they already have their own category) and renaming Stereographs as Stereo images from Flickr. The hard part is the big overlap between Stereo images and Stereo cards. I think it is important to keep the Stereo card category for the vast corpus of stereo cards for the 19th and early 20th century, when they were a very popular medium, and separate more modern stereo pair images, e.g. Category:Stereo images of plants.--agr (talk)
@Auntof6 and ArnoldReinhold: Thanks for your input. I certainly support Arnold's suggestion of moving Category:Stereographs, though perhaps to Category:Computer-generated stereo images. Adapting your suggestion, it might make sense to create Category:Stereo cards by source with Category:Stereo cards in the Metropolitan Museum of Art‎, Category:Stereo cards in the Swedish Performing Arts Agency‎ and Category:Stereo cards from Flickr as subcategories.
But surely, stereo cards are all stereo images, right? So how to we create the most efficient category tree? At least when categorizing by subject, anything at the sub-category card level should also exist at the parent category image level. e.g. it's a problem that we have Category:Stereo cards of animals but no Category:Stereo images of animals because the former now contains Category:Stereo images of cats‎ and File:COLLECTIE TROPENMUSEUM Schapen in weide te Priangan TMnr 10013358.jpg. I would suggest we upmerge all the "Stereo cards by subject" categories to "Stereo images by subject" categories. Everything that's a stereo card should definitely be categorized as such, but maybe it's enough if it's in Category:Stereo cards, or one of the sub-categories for publisher, photographer, or source? - Themightyquill (talk) 13:34, 14 May 2018 (UTC)[reply]
Category:Computer-generated stereo images works for me and Category:Stereo cards by source as well. (BTW, I've cleaned out the MET images from Category:Stereograms.) I agree that the overlap between Stereo cards and Stereo images is the thorniest aspect. Clearly stereo cards are a subset of stereo images. For starters, I agree that the category tree for stereo images by subject should be as rich as that for stereo cards by subject. I'm not exactly sure what you have in mind by "upmerge." I think I'd rather have Stereo cards of animals be a subcategory of Stereo images of animals, but I don't feel strongly about it. Category:Stereo images has 1367 files in it. Many, but not all are stereo cards. For starters, I'd suggest any files in this category that have another "stereo" category be removed from Stereo images. Finally, I think we need some top text be added to the Stereo cards and Stereo images categories explaining what goes where.--agr (talk) --agr (talk) 15:20, 14 May 2018 (UTC)[reply]
I just noticed we have Category:Stereo images by source, so I'm not sure we need a separate Stereo cards by source.--agr (talk) 16:25, 14 May 2018 (UTC)[reply]
@ArnoldReinhold: And I just noticed we also have Category:Stereoscopic 3D files including Category:Stereoscopic 3D files from Flickr‎. @とある白い猫: Would you, as creator of that tree, like to contribute to this discussion? - Themightyquill (talk) 13:34, 15 May 2018 (UTC)[reply]
Category:Stereograms has been moved to Category:Computer-generated stereo images. - Themightyquill (talk) 13:36, 15 May 2018 (UTC)`[reply]
I've just redirected Category:Stereographs to Category:Stereo images. - Themightyquill (talk) 21:11, 21 July 2018 (UTC)[reply]

Some more complications: There is a template:3D that among other categories can set the Category:Stereograms, along with an entire category tree that includes Category:Stereoscopic 3D files (side-by-side). Images in this category tree are to be set using the template, not the usual [[Category:... way. Also there is a Category:Anaglyphs which covers images that are viewed in 3D by colored glasses. We have been mostly discussing side-by-side stereo images. I think we need to invite editors involved with those projects to this discussion.--agr (talk) 15:38, 15 May 2018 (UTC)[reply]

I had been involved in creating the current version of Template:Stereoscopic 3D a few years ago. As it pertains to categorization, this template identifies two things:
  • Whether the tagged file "is" a 3D image/video/etc, or if it "contains"/"depicts" one.
  • What method of stereo imagery the aforementioned image/video/etc uses.
The categories it uses identify as "files" rather than "images" because the files it tags could be videos and animations as often as it could be a photograph or illustration. I'm not actually sure if there are any videos, and my attempt to find them failed due to deep search returning an error. But the template essentially tries to identify the "3D format" of the imagery, including whether this imagery is presented "for viewing" or not.
I'm not sure how this might best combine with the other categories. I would be tempted to put "3D files" within "stereo images" but for the above point; I was more comfortable with "stereograms" as the parent category because of its generality. Currently there is very little connection between the two. "Stereo images" also contains a lot of files which should be tagged with the template (which must be done manually, not by script).
Also, going too far into "by subject" might be undesirably more complicated than searching for "3D format" and "subject" category intersections.
If Template:Stereoscopic 3D can be improved to help resolve issues, let me know. I see a comment was posted a couple months ago asking to change the template now that Category:Stereograms has been changed to Category:Computer-generated stereo images. I'll change that to Category:Stereo images. It only places files not formatted "for viewing" and without an identified method into this, a total of two. djr13 (talk) 04:23, 20 July 2018 (UTC)[reply]
Also, worth noting, Category:Computer-generated stereo images still retains its "other languages" and description from when it was formerly Category:Stereograms. I don't think the description remains totally correct post-rename, and the other languages probably don't either. djr13 (talk) 04:56, 20 July 2018 (UTC)[reply]

We also need Category:Stereo photographs, into which relevant sub-categories should be moved, distinct from drawn stereo images. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:46, 17 December 2023 (UTC)[reply]

Perhaps I'm mistaken, but this seems redundant with Category:Prunus serrulata var. lannesiana? Themightyquill (talk) 11:25, 7 December 2016 (UTC)[reply]

too specific. Asked here: en:Wikipedia_talk:WikiProject_Plants/Archive70#Prunus_lannesiana_and_Prunus_serrulata_var._lannesiana --Estopedist1 (talk) 12:02, 11 April 2020 (UTC)[reply]
POWO has it as Prunus ×lannesiana. Neither POWO nor IPNI gives the parentage, and I failed to find a statement elsewhere. POWO splits the Prunus serrulata complex, so it could be a hybrid within the complex (serrulata × jamasakura?), but it could also be a hybrid between the complex and another species. Flora of China lumps the complex, with the 3 taxa as varieties. Anyway Prunus lannesiana and Prunus serrulata var. lannesiana (and Cerasus lannesiana) are the same thing, but what would be the correct taxonomy is not a trivial question to answer. (A 2007 paper lumps the complex, but complicates things by proposing that Prunus lannesiana f. albida lies outside the complex.) 87.75.46.187 18:51, 12 April 2020 (UTC)[reply]
@Themightyquill: I think Commons is not the place to discuss such specific taxonomy about a species. Most easy is to follow enwiki, hence to be redirected to Category:Prunus serrulata. After that this CFD can be closed--Estopedist1 (talk) 18:39, 21 November 2021 (UTC)[reply]
Commons has a much better set of taxonomic categories than English wikipedia does. I see no reason to follow their lead. Moreover, this is definitely either a particular variant of Category:Prunus serrulata (Category:Prunus serrulata var. lannesiana) or an alternative species (Category:Prunus lannesiana), so merging to Category:Prunus serrulata is not helpful. - Themightyquill (talk) 07:48, 22 November 2021 (UTC)[reply]
Category names

A long time ago when I had been asked to write FIAV1 I was told that the preferable sequence to define first the matals silver-gold and then the other codes in alphabetical order, i.e. a|A|o|b|B|c|C|g|p|s|t|v. As a matter of fact, currently some tincture categories follow this rule, but most don't and their sequence sorts "Or" alphabetically between g and p. Some have not such a rule at all, e.g. the new {{C}Category:Argent, azure, carnation, céleste, or, sable in heraldry}} sorts to the long names instead of the codes, a/b/c/B/o/s instead of a/b/B/c/o/s.

I am not so sure whether all the tincture categories are really helpful, or not. Due to mathematics with 12 colors, 3974 combinations are possible; because some combinations as a|A, b|B or c|C are unlikely not all categories are used, and if more than six colors come together as Multi-colored heraldic shields we need less categories - but IMHO still much more than useful!
If the community decides to keep the Color combinations of heraldic shields there are two possibilities:

  • either we let the category names as they are now and let the workaround of the automatic categorization as it is, and expand it when needed,
e.g. a|A|g|…|o|…, or another one, an need forever the Tincture/cat0 workaround template
  • or we move the categories to the names corresponding to one rule for all - namely the mentioned rule a|A|o|…, and don't need any more the workaround template.

There are a lot of files using color combinations without a category defined; for some rare combinations only one single file corresponds to a category. Such almost empty categories will not be very helpful? -- sarang사랑 08:45, 15 December 2016 (UTC)[reply]

  • @Sarang: Well, sorry to be the first person to respond in almost a year but I also don't see how these are particularly helpful. I am against excessive categorization for color combos and think it should not go past three colors at most. I'm not even sure HOW people use these general categories just for colors. I can see the use when it is specific (ie, chequy azure and or) but can't see how "azure and or in heraldry" really helps anyone find what they are looking for. — ʷiḳỉℳẚṅ₫¡₳ (talk) 03:48, 9 November 2017 (UTC)[reply]
The current situation is not at all satisfying - but it seems that an alteration is not so urgent. -- sarang사랑 07:23, 2 August 2018 (UTC)[reply]

This category should be merged into Category:Stair handrails, because all stair railings are for holding onto. (The images under the two categories look like the same thing.) The subcats should also be merged into their similarly-named handrail categories, or renamed to use the term "handrail". The old cat names should be left as redirects, because they're likely to be used again. Auntof6 (talk) 17:24, 17 December 2016 (UTC)[reply]

This whole category tree is weird. Guardrails says that it's synonymous with railings but might include crash barriers, yet it's a sub-category of both Category:Railings and Category:Crash barriers rather than a parent category of both. It should look like this
Thanks - Themightyquill (talk) 15:13, 19 December 2016 (UTC)[reply]
My comments:
So how about this:
Note that Category:Guardrails appears twice. --Auntof6 (talk) 16:38, 19 December 2016 (UTC)[reply]

@Auntof6: Perhaps you misunderstood my bullet list. Crash barriers and Railings are listed as peers - both are examples of guard rails. I don't understand how you see a guardrail (something that's designed for people or for cars, according to the category description) as a type of railing (something that's designed exclusively for people, no?). To me, the relationship is the opposite. - Themightyquill (talk)

I guess I was going by dictionary definitions, not the definitions on the categories. Specifically (according to Wiktionary, with italics added by me):
  • Guardrail: "A rail placed alongside a dangerous place in order to improve safety." Here we have specific form (rails) and general function (improving safety).
  • Railing: "A fence or barrier consisting of one or more horizontal rails and vertical supports." Here we have specific form (rails) and general function (fence/barrier = separation, but could be separating anything).
  • Crash barrier: "A barrier on the side of a road, to keep vehicles on the road." Here we have specific function (keeping vehicles on the road) but nothing about form. Here's a crash barrier that has rails. Here are some that don't.
I think the Wiktionary definitions are better than the definitions on the categories. Since crash barriers aren't required to have rails, I don't think they belong under a railing category. --Auntof6 (talk) 06:48, 20 December 2016 (UTC)[reply]
Yep, your logic is better. I'm not sure how to set the relationship between Category:Crash barriers and Category:Guardrails. Not all guard rails are crash barriers, and not all crash barriers have guard rails. - Themightyquill (talk) 05:23, 21 December 2016 (UTC)[reply]
Then maybe they shouldn't have a relationship. Maybe guardrails should be under railings, but not under crash barriers. Some files might be in both, but the categories wouldn't be over/under each other. --Auntof6 (talk) 06:28, 21 December 2016 (UTC)[reply]
That works for me. - Themightyquill (talk) 16:21, 21 December 2016 (UTC)[reply]

Hi, most of the category definitions in the barrier category tree are from the Getty Art & Architecture Thesaurus [1] which I think is in architectural matters a more reliable source than Wiktionary. Crash barrier is BE, guardrail is AE. See barriers and barrier elements. Some other dictionaries on my playground may be useful. --Bohème (talk) 04:36, 11 January 2017 (UTC)[reply]

Maybe Category:Crash barrier guardrails could be used to store those guardrails which are actually crash barriers as well? Many of the road guardrails are crash barriers, while others are merely functional or decorative, but are not intended to effectively stop a car from passing through them.-- Darwin Ahoy! 20:28, 9 September 2017 (UTC)[reply]

Thanks for restarting this discussion, DarwIn. My understanding of your suggestion is this:

That works for me. @Bohème and Auntof6: Thoughts? Let's see if we can close this. - Themightyquill (talk) 08:05, 11 September 2017 (UTC)[reply]

My comments:
  • Not all concrete barriers are crash barriers. Examples of some that are not: File:Ornamental concrete balcony railing.jpg, File:Military Roadblock & Snow (11354646143).jpg. Concrete is just a material: it doesn't imply anything about purpose. Maybe "concrete barriers" belongs outside of this hierarchy, although "concrete crash barriers" would fit.
  • When I see the term "Crash barriers guardrails", to me it sounds like it focuses on the guardrail part of crash barriers. Maybe "crash barriers with rails" is more descriptive.
--Auntof6 (talk) 08:54, 11 September 2017 (UTC)[reply]

I don't see what's wrong with this category and why you mix up railings with such different things as crash barriers (british english) and guardrails (american english).
The cat definition in Category:Railings is quite clear.
Railings (banisters, balustrades) are structures (parent Category:Barriers) - not rails - destinated to keep people or objects - not vehicles - from falling down. Components of railings:

  1. supporting structure
    1. footing,
    2. railing posts,
    3. vertical railing shafts or balusters between the railing posts; they may be replaced by horizontal bars, by ornamental elements, wood panels, glass or concrete elements (parapets), etc ... and all these forms are still railings (still nothing to do with rails)
  2. handrails; stair railings are usually (not always) topped by handrails (grasp bars)

Stair railings are topped by stair handrails, but: stair handrails may also be simple grasp bars supported by railing posts (often in the middle of stair ramps), or grasp bars fixed on a wall.

Just keep the Category:Guardrails out of the Category:Railings, change the imho erroneous category definition in cat:guardrail (somtimes referred to as railing doesn't mean that the choice of this word is correct. Guardrail is (imho) not synonymous with railing) and open another discussion under Category:Crash barriers (british english) or the synonymous Category:Guardrails (american english). --Bohème (talk) 18:25, 11 October 2017 (UTC)[reply]

N.B.: Exceptional case: Bridge railings are for people and vehicles = railings and crash barriers. --Bohème (talk) 11:47, 12 October 2017 (UTC)[reply]

This category needs a disambiguation page (see: en:Guardrail (disambiguation) but this is not the right place to discuss the cat tree of roadside barriers/Crash barriers.
Concrete barriers aren't necessarily crash barriers. They shouldn't be in Category:Crash barriers but only in Category:Barriers.
Concrete crash-barriers with guardrails: should be in both -> Category:Concrete crash barriers and Category:Guardrails.
Please move the category discussion to roadside barriers or crash barriers. Thx. --Bohème (talk) 11:47, 12 October 2017 (UTC)[reply]

This request is for Category:Nuit debout by date and all its subcategories. This category is supposedly "by date", but most of the subcats don't represent valid dates. I suggest either renaming the subcats so that they make sense, or moving all the files up to Category:Nuit debout and deleting this cat and the subcats. Auntof6 (talk) 02:36, 20 December 2016 (UTC)[reply]

Together there are over 600 images here, so I think sub-categorizing them is a good idea. Maybe these are all sub-categorized in other ways already, but unless you want to go through each one to check, I'd suggest renaming the "by date" sub-cats so that they use proper dates. - Themightyquill (talk) 13:05, 22 February 2017 (UTC)[reply]

Stale discussion. @Auntof6 and Themightyquill: en:Nuit debout lasts from 31 March 2016 to June 2016. The correct naming is not easy. Should we use style:

--Estopedist1 (talk) 20:39, 21 November 2021 (UTC)[reply]

Sounds reasonable. -- Auntof6 (talk) 19:02, 22 November 2021 (UTC)[reply]

Issue 1: There has to be a better name for this category. The subcats aren't groups of the same kind of things by day; they are for individual dates (year-month-day). Maybe something like "Individual dates"?

Issue 2: Many of the individual date categories here contain only one category, that being for a person who either was born or died on the date. For example, Category:1431-02-20 contains only Category:Martinus V: he died on 20 February 1431. To understand why a person category is there, you have to look in that category to see that the date matches their year of birth or death. Wikipedia and Wikidata have info about people's exact dates of birth and death; I don't think Commons needs to categorize people by those exact dates. Auntof6 (talk) 03:58, 20 December 2016 (UTC)[reply]

I definitely support a move. Category:Individual dates doesn't sound great, but I can't think of anything better. It's much better than Category:Days by day anyway. Leave this open for a while and maybe someone will come up with something better.
As for Category:1431-02-20 you never know, maybe someday this category will be filled with images of people that died on 20 February 1431. ;) Seriously though, it doesn't make much sense to have that category is only populated by Category:Martinus V but going through all these individual date categories would be a lot of work. If you want to do it, go ahead, but I suppose they aren't causing much harm. - Themightyquill (talk) 16:26, 21 December 2016 (UTC)[reply]
  Oppose The today situation is OK for me. I dont see why to change. --Tangopaso (talk) 14:08, 4 January 2017 (UTC)[reply]
It sounds very strange in English, and its meaning isn't obvious. "Jours par jour" sounds equally strange in French, does it not? Category:Individual dates isn't great, but it's much clearer. - Themightyquill (talk) 12:08, 15 January 2017 (UTC)[reply]
  Comment: how about "Category:Days by date"? also: if you move forward to the 19th, 20th, & 21st centuries, you will see increasing amounts of stuff for each day. especially photographs; many from the world wars, the donated archive-collections, & from the start of WMC to the present. these categories serve as the framework for the "photographs taken on xxxx-xx-xx(-date)" categories. Lx 121 (talk) 04:43, 30 March 2018 (UTC)[reply]
@Lx 121: Firstly, "Days by date" is not any better. This is not a category of days (Monday-Sunday) organized by date (xxxx-xx-xx), it's just a category of specific dates. Second, no one disagrees with the principle of using specific dates to categorize material when there is plenty and room for more, such as contemporary dates or dates likely to have a lot of content (such as your example of wartime). The question is whether it's actually valuable to do so when there is very little content and very little chance of more content being added in the future (such as Category:1431-02-20). - Themightyquill (talk) 21:46, 20 June 2018 (UTC)[reply]
What about calling this category just Category:Dates (time)? --Auntof6 (talk) 03:13, 21 June 2018 (UTC)[reply]
I guess that's better than Category:Individual dates as it's obviously not for something like File:Hadrawi-Date.jpg. - Themightyquill (talk) 08:04, 22 June 2018 (UTC)[reply]
Any reasoned opposition to Category:Dates (time) ? - Themightyquill (talk) 00:09, 3 January 2019 (UTC)[reply]
Leave it as it is. Evrik (talk) 20:02, 14 March 2019 (UTC)[reply]

  Oppose Originally, I thought this was for individual days of the year, like January 1 or December 17. I think that would be a better use of this category. Evrik (talk) 15:00, 14 March 2019 (UTC)[reply]

Comment - We do have categorisation for that, starting @ category:Years. This one is meant for organising the chronology of (& by) actual calendar dates (yyyy-mm-dd). I am open to better suggestions for naming it. Lx 121 (talk) 07:14, 17 June 2019 (UTC)[reply]
  •   Comment It seems like there's a consensus not to change this. Although looking over it 99% of these categories contain either a single subcategory or file. So I'm tempted to just go through and delete a lot of them as overly granular and pointless. I think doing that would be in alignment with the outcomes of CfD for similar categories. Does anyone have any objections to that or thoughts on it? --Adamant1 (talk) 02:27, 11 September 2024 (UTC)[reply]

There should be a consensus on the capitalisation in the name of subcats of this category. See that categories in Category:Books in PDF by year have in their name "PDF" in capitals but djvu in Category:Books DJVU files have "djvu" and not "DJVU". Even more "confusion in the capitalisation is that the category itself is in Category:DjVu files. --Wesalius (talk) 10:45, 21 December 2016 (UTC)[reply]

The English wikipedia article is at en:DjVu, so I'd say that's the way we should go. I have various other problems with this whole category tree, including the idea that we shouldn't be mixing content categories with format categories, but at very least this category should be changed to Category:DjVu books or Category:Books in DjVu or something that's grammatically correct. - Themightyquill (talk) 16:16, 21 December 2016 (UTC)[reply]
Or Category:DjVu files of books? - Themightyquill (talk) 00:47, 3 January 2019 (UTC)[reply]
for simplicity and the system, all categories' names consisting of file extension maybe to write fully capitalized. Eg PDF, SVG, DJVU, WEBM (we have category:WebM videos). Also strong move to the future: more file extensions are definitely coming--Estopedist1 (talk) 07:16, 25 January 2020 (UTC)[reply]
"DjVu" isn't primarily the filename extension, it's the name of the file format. i.e. it is equivalent to "Portable Document Format" not ".PDF"; and unlike PDF it never appears mono-capitalized. But "PDF" is in this context an initialism of the full file format name and not a filename extension (they just share the same derivation). Filename extensions as such would be a very strange basis for category names, especially given each file format can have multiple recognised file name extensions (and some bear little relation to the file format name).
The mixing of content and format is a little weird, but I think it may be at least partially necessary due to semantic ambiguity. "Book" alone in a category would be used for scans of whole books, of individual pages from a book, and for images extracted from a book (which can be both, say, a photo of a famous person that strictly speaking exists independently of the book; or an illustration or flourish that is inseparably linked to that book). By specifying "Books DjVu files" and "Books PDF files" it is clear(er) that these are digital representations of whole books we're talking about.
But I'm not sure the specific file format as such needs to be specified here if a semantically unambiguous alternative can be found that people will actually relate to. Things like the enWP push to replace "Paintings of …" and "Plays about …" categories with "Cultural depictions of …" are, IMO, badly misguided: what the devil is a "cultural depiction" and when last did you hear that term used down at the local? That argues against constructs like "Digital representations of books", but there may exist better ways to convey the same idea.
In any case, I think the original rationale (from 2016!) is flawed: the capitalization in the examples ("PDF" and "DjVu") is correct as given. But a lot of the related and subcats use inconsistent capitalization by, e.g., lower-casing "djvu" (see e.g. Category:1895 books djvu files). Whatever the top-level cats end using, the subcats should consistently use that too. --Xover (talk) 09:07, 14 July 2021 (UTC)[reply]