Commons talk:Categories/Archive 5

Archive 1

←

Archive 3

Archive 4

Archive 5

Archive 6

Abbreviations

Is there some kind of rule for when it is OK or not to abbreviate something when creating a category, for instance "Company" versus "Co."? Thanks. --Adamant1 (talk) 00:10, 3 February 2022 (UTC)

@Adamant1: It is strongly preferred to avoid abbreviations in category names. However, this is not an absolute rule. For certain proper names where the abbreviation is almost always the normal usage of the name for the subject (e.g. Category:IBM), it can be okay. This is a high bar though, and abbreviations that are merely 'very common', but where the spelled out version is reasonably common to see as well, are probably better in spelled-out form (e.g. Category:United States). Since this is a gray zone, borderline cases should be discussed in a CfD before changes are made. If you are making a new category, feel free to use your best judgement but be okay with discussing it later should another user raise a CfD on it. Happy categorization! Josh (talk) 09:51, 31 March 2022 (UTC)

Many plural category names not matching the policies

Hello, I think the policies for Category names should be updated because it is not matching anymore with the common practice on the commons. Or we need a widespread renovation of the commons.

A discussion is started here → Commons : Village pump # Many plural category names not matching the policies.

W like wiki ^{good to know} 21:21, 8 August 2022 (UTC)

Metacategories

Is the concept of a metacategory fleshed out somewhere else? I'm not at all sure this page is the place to add any of this, but I do think it belongs somewhere. At the very least we presumably want to say something like the following.

As already noted, metacategories contain only other categories, not individual images. Typically, a metacategory contains categories that all have the same relation to its parent category. Good examples of metacategories are:

• Category:Horses by country
• Category:Art by genre

A metacategory may also contain other metacategories, and (as with members of regular categories) these do not necessarily have a parallel relation to the parent metacategory. For example Category:Art by genre contains:

• Category:Art by country by genre
• Category:Dance by genre
• Category:Children in art by genre

Jmabel ! talk 21:19, 12 August 2022 (UTC)

@Jmabel: There's Commons:Meta category. There are some differently-named metacats, though, such ask Category:Centuries in Sikhism and other centuries-in subcats of Category:Religion by century. I also think I've seen some other alternate naming of metacats, but I don't remember exactly what they were right now.

I do think we need to be careful not to say that any category that has "by <something>" in the name is a metacat. There are several types of such categories that are not metacats. Examples are:

• Category:Books by Charles Dickens
• Category:People by name (Some by-name categories are metacats, but some are not.)
• Category:Aircraft by registration
• Category:Bentleys by serial number
• Category:Paintings by Franz Marc by title
• Category:Virgin Mary by title (although Category:Paintings of Virgin Mary by title is a metacat because it groups by title of Virgin Mary, not by title of painting)

There may be other exceptions, but these are the kind I remember seeing a lot. -- Auntof6 (talk) 21:39, 12 August 2022 (UTC)

@Jmabel: A further thought: I have seen some categories whose contents look like the content of a metacat, but whose titles do not indicate any sort criterion. In some cases I removed the metacat template, and in some of those cases I got pushback about it. I can't think of a specific one right now, but I think some of them were taxon-related. To me, the name of a metacat should indicate the sort criterion. -- Auntof6 (talk) 21:43, 12 August 2022 (UTC)

@Auntof6: One tricky case I've seen is when an image really is about the topic of a metacat: e.g. Category:Coal industry by country (quite underpoplulated) would be the obvious home for a map showing the amount of coal produced in each country of the world in a particular year. Do we enforce the "metacategory" concept against including those? - Jmabel ! talk 22:50, 12 August 2022 (UTC)

@Jmabel: That is a tricky one. I think I've handled those in different ways in the past. You could leave it in the metacat, but I don't think that's what metacats are for. You could put it in the category/ies for each country shown. You could also put it in the parent category, or a category for statistics (in this case, coal industry statistics) if there is one. -- Auntof6 (talk) 00:24, 13 August 2022 (UTC)

"Not the primary subject"

Is that a valid reason to remove categories from image? Most categories people add to files aren't about a single subject found on pictures. Enhancing999 (talk) 07:33, 17 August 2022 (UTC)

@Enhancing999: Sort of. Really depends on context. E.g. I wouldn't remove Category:1993 in Chicago on that basis, but I might remove (and certainly would have no problem with someone else removing) Category:Stop signs from an urban scene that very incidentally has a stop sign in it. - Jmabel ! talk 14:48, 17 August 2022 (UTC)

Is there an explanation on this page that would justify that users delete anything but categories about a primary subject? Enhancing999 (talk) 17:17, 17 August 2022 (UTC)

Do you have specific examples of users doing so in mind? -- Infrogmation of New Orleans (talk) 17:26, 17 August 2022 (UTC)

I do, but they don't really matter, as the opposite seems fairly common. It's a general question about this page. Enhancing999 (talk) 17:33, 17 August 2022 (UTC)

If the categories are redundant (what the main page calls "overcategorization" but is actual redundant categorization, eg including a general category in addition to the more specific subcategory), then I'd say the removal is appropriate. If they are removing significant secondary topics, like my example below, I'd say the removal was not appropriate. If the categories are for minor details that are not shown in a manner that would reasonably be useful to reusers or researches, I'd say the removal was appropriate. No doubt there can be cases somewhere between the second and third where things might be more a matter of personal judgement or up for discussion. -- Infrogmation of New Orleans (talk) 17:46, 17 August 2022 (UTC)

If the page currently doesn't cover the point, we should add something.

Otherwise it may not be clear to users that what they are doing isn't helpful. Enhancing999 (talk) 17:54, 17 August 2022 (UTC)

I'd say the focus should be if the categories show a potentially useful example of something to someone interested in the topic. IMO properly categorized secondary subjects can be very useful in research and historic topics, and sometimes an unexpected delight. Hypothetically, say there were a photo of US President Harry Truman in Chicago in 1950. The photo clearly shows he is seated in an automobile (which someone familiar with old cars can identify as a particular model of 1950 Chevrolet) and is wearing a straw boater style hat; the background streetscape can be seen to be Michigan Avenue. While President Harry Truman would be the "primary subject" of the photo, categories for the other things mentioned can be useful to reusers or researchers, and should not be removed. Certainly there can be overcategorization when things only slightly visible or so common that adding categories for them is not useful. Again, I'd say the criteria should be "if someone is interested in a topic, is this an example that they could reasonably find useful?" If the answer is yes, I'd say there is nothing wrong with categorizing accordingly. -- Infrogmation of New Orleans (talk) 17:25, 17 August 2022 (UTC)

• Any suggestions of rewording of policies per discussion above? I'm not the first to note that the attention given to what is called "overcategorization" is actually *redundant* categorization, although that may not be clear to newer users. I'd say the usefulness of in many cases including more than a single category for some media has been well demonstrated in practice for more than a dozen years on Commons, and should not be confused with what the policy page calls "overcategorization". - Infrogmation of New Orleans (talk) 00:07, 18 August 2022 (UTC)

• • I'm not sure, though the guidance does mention what or whom does the file show? What is the main subject? What are the noteworthy features of the image? So it is concentrating on the main subject, and other noteworthy features as you mention. So I guess the current guidance is more "noteworthy features", not necessarily "primary subject". There are of course other possible categories for location, time, author, and other aspects. I'm in general agreement with your guidance above, that not every little thing which happens to appear in the image needs a category -- particularly if common, or blurry or otherwise not a very good representation of the subject. A bad or partial picture of a particularly rare subject may be still be fine, though. "Noteworthy features" seems a pretty good way to put it, but your example of would re-users or researchers find the image useful to the category's topic might be a way to expand on that. Carl Lindberg (talk) 00:54, 18 August 2022 (UTC)

I concur completely with what Infrogmation and (especially) Carl have said here. - Jmabel ! talk 02:01, 18 August 2022 (UTC)

Cannot remove category from image - why?

File:Sign at Guatemala Mexico border.svg is in Category:Guatemala - unneeded, since it is more specific subcategory. However Category:Guatemala does not display when I try to edit the image page, and I see no way to remove the category. What's happening here? -- Infrogmation of New Orleans (talk) 22:34, 12 September 2022 (UTC)

• OK, I figured it out: {{PD-Guatemala-exempt}} was forcing Category:Guatemala on to all images so tagged. I removed that from the template. -- Infrogmation of New Orleans (talk) 17:25, 13 September 2022 (UTC)

Permission to add "(disambiguation)" to DAB categories to help preventing them to be used

I would like to be able to rename some disambiguation categories (DAB categories), adding "(disambiguation)" to the category name, even when there is no category with the same name that is a primary topic. As I understand, Commons does not have a policy regarding "(disambiguation)" in category names, but uptill now follows W:WP:DABNAME (according to Crouch, Swale on Commons:Categories for discussion/2022/06/Category:Decoration).

• The problem: DAB categories are not recognizable as such when you add a file or another category to one. And you do not get a notification in all cases when you add a file or category to a DAB. (See Commons:Village pump/Archive/2022/10#How to make a structural solution for not empty disambigious pages?, item 2, for the discussion about this problem.)
• One of the proposed solutions is to allow "(disambiguation)" in the category name, even when there is no category with the same name that is the primary topic. Then at least people will see that the chosen category is not the right one. The original category should be deleted to avoid misunderstanding.

So my question is: Would it be allowed to rename DAB categories, adding "(disambiguation)" to the category name, even when there is no category with the same name that is a primary topic? JopkeB (talk) 05:58, 21 October 2022 (UTC)

• No when you add a category via Hotcat and its a DAB you get a list of entries on the DAB, for example Category:Mercury you are offered things like Category:Mercury (element) while if Category:Mercury redirected to Category:Mercury (disambiguation) you would just get Category:Mercury (disambiguation) automatically added. Crouch, Swale (talk) 06:44, 21 October 2022 (UTC)

The problem is that in this case too many people still choose "Category:Mercury" instead of one of the others. I do not want a redirect from "Category:Mercury" to "Category:Mercury (disambiguation)" because that indeed would cause a lot of trouble. I'd rather have "Category:Mercury" be deleted. --JopkeB (talk) 09:53, 21 October 2022 (UTC)

• Oppose. I don't know if it would be allowed, but it would be a bad idea. My viewpoint is that here on Commons no dab categories should have "(disambiguation)" on them, and we shouldn't be looking at anything here as being a primary topic. A primary topic situation works for Wikipedia, because they are text-based and their dab pages are in article space; you can tell by reading an article whether it's about the thing you're interested in.

On Commons, where things are media-based and our dab pages are in category space (except for some gallery dabs that I think serve no purpose), it's different. You can't always tell which thing a file belongs to by looking at it (or watching, listening to, etc.). Let's say someone is uploading an image of something nondescript in Paris, Texas. It could be a generic street scene, an image of children playing, or whatever. Different things could go wrong:

• An automated process categorizes based on individual keywords it sees in the file description. It sees "Paris" and puts it in Category:Paris, which is for the French city.
• A person who doesn't understand how to categorize here uses HotCat to categorize the file. They enter "Paris" and choose the first category suggested which, again, is the one for the French city.
• The file is now incorrectly categorized. How will anyone notice that? With many images, there's nothing to indicate what continent it's in, much less what country or city. Many pages have been renamed to avoid the unqualified title being for a "primary topic" because so many incorrect things got categorized there. (One I can think of is Category:Choir, Mongolia, but I know there have been others.)

And that's only taking into account use of only English when categorizing. Not everyone knows that category names here are supposed to be in English, so we get wrong things categorized under English terms that have other meanings in other languages. An example of this is Category:Lagos. Because we don't use that for a primary topic, when people put images of lakes in it (because lagos means lakes in Spanish), we can recognize that and fix it. If that category were for, say, the city in Nigeria, how would someone looking at the category know that those lakes weren't in that city? --Auntof6 (talk) 09:25, 21 October 2022 (UTC)

Dear Auntof6, Your viewpoint is that no dab categories should have "(disambiguation)" on them. What do you think would be a solution for the problems you describe after your viewpoint? How could it be prevented that files for Paris, Texas end up wrongly in Category:Paris (capital of France)? Or files about Spanish lakes end up in the DAB Category:Lagos? --JopkeB (talk) 09:53, 21 October 2022 (UTC)

@JopkeB: The solution would be for categories like Category:Paris to be dab categories, and for the category for the French city to be qualified -- Category:Paris, France or Category:Paris (France) or some such. This has been discussed before, sometimes rather heatedly.

As for the lakes, the best way to prevent that wrong categorization is to make sure people and processes that assign categories understand how to categorize correctly. However, that's probably not 100% feasible, especially in the case of automated processes, and the second best solution is what we currently have: the "Lagos" category is a dab cat. And it's not only Spanish lakes that show up in the Lagos category; it's potentially any file for any lake when being categorized by a Spanish-speaking person. -- Auntof6 (talk) 10:14, 21 October 2022 (UTC)

Why may a category not have "(disambiguation)" in the name, why is this a bad idea? What would go wrong? Uptill now I see no valid arguments, only opinions. --JopkeB (talk) 02:31, 23 October 2022 (UTC)

It could be worth a try. The problem would be clear to all users. Unless we redirect existing disambiguation categories, people may reuse them and the problem starts all over. Enhancing999 (talk) 10:57, 23 October 2022 (UTC)

This has been discussed many times on Wikipedia but the problems I mentioned above would be an additional reason not to. Commons categories just like Wikipedia articles should generally use just the page's name rather than add additional information to the title and the same applies to disambiguation categories for example we use Category:Hagmore Green not Category:Hagmore Green, Suffolk. One user namely User:SmokeyJoe has advocated this on Wikipedia over the years but has never gained consensus and I doubt it would here for the additional reasons I mentioned. See also the essay at w:User:Born2cycle/Unnecessary disambiguation. Crouch, Swale (talk) 14:09, 23 October 2022 (UTC)

Perhaps there is a misunderstanding. With a "disambiguation category" I mean a referral page. In my opinion such a category is not a real category, but it gives a list of categories whith a similar name. See for instance Category:Cars (disambiguation) (which has, by the way, "(disambiguation)" in the name, which is what I here propose for other problematic disambiguation categories/referral pages to make possible). It is not my intention at all to rename existing normal categories that do not offer such a list. JopkeB (talk) 14:26, 23 October 2022 (UTC)

(English) Wikipedia may have other uses, likely not directly relevant to Commons image categorization. Commons categorization is done on every upload, by all users, multiple times for thousands of new images per day.

As an example: I'm fine with using Category:York (disambiguation) as the list of categories with a redirect from Category:York. Enhancing999 (talk) 14:48, 23 October 2022 (UTC)

Thanks, Enhancing999, your example is exactly what I mean. My proposal would be to reactivate categories like Category:York (disambiguation) or make new ones for problematic ones if they do not exist yet, and remove Category:York and the like.

And yes, I learned many times on Commons that Commons is not (EN-)Wikipedia, here we have and make our own rules. And for this subject Commons differs very much from a Wikipedia, as you pointed out. JopkeB (talk) 05:34, 24 October 2022 (UTC)

@JopkeB: Removing categories like Category:York would not stop things from being categorized there. It should at least be a redirect so that anything there gets moved to the disambiguation category. I know you're trying to avoid having anything in dab cats, but I don't think having things categorized in non-existent categories is better. -- Auntof6 (talk) 05:39, 24 October 2022 (UTC)

Yes, perhaps you are right, I indeed am trying to avoid having anything in dab cats, at least as little as possible; and perhaps that is not realistic. But if we keep categories like Category:York with a redirect to a dab category, then it is useless to have categories like Category:York (disambiguation); then the situation might stay just as well as it is now. JopkeB (talk) 04:42, 25 October 2022 (UTC)

Thanks Crouch, Swale, Auntof6, Enhancing999, for your contributions to this discussion. --JopkeB (talk) 10:28, 12 December 2022 (UTC)

---

Conclusions about "(disambiguation)"

No, the majority of the reactions say: it is not a good idea and not allowed to rename DAB categories (= referral pages) adding "(disambiguation)" to the category name, because then:

• people may still add Category:X (if it still exists) via Hotcat to files, and that would redirect to Category:X (Disambiguation), so the problem would not have been solved at all
• automated processes still would add wrong categories to files
• we do not easily see that files have wrong categories with a similar name, while now we can recognize that in the DAB category and fix it.

Auntof6 thinks it is better to keep DAB categories as they are and correct the files (and subcategories) that wrongly are put in those categories.
--JopkeB (talk) 10:28, 12 December 2022 (UTC)

An additional advantage of using "(disambiguation)" could be that it could fit as a parent category to anything listed there. Enhancing999 (talk) 09:36, 22 January 2023 (UTC)

You mean like categorizing Category:Mercury (planet) under Category:Mercury? We should definitely not do that. The disambiguation categories should be empty as much as possible, containing only things that we don't know which item they belong in. -- Auntof6 (talk) 10:42, 22 January 2023 (UTC)

No, Category:Mercury (planet) under Category:Mercury (disambiguation). There would still be no files. Enhancing999 (talk) 10:45, 22 January 2023 (UTC)

I was using the current name of the disambiguation category, but whichever name it ends up with, it should not contain the disambiguating entries. A disambiguation category should normally be empty. It would have text listing the possible things it refers to, but it should have no files and no subcategories. -- Auntof6 (talk) 11:15, 22 January 2023 (UTC)

I got that, but without "(disambiguation)", it seems to me it would be rather confusing.

What downside do you see, except that "it should [not]"? Enhancing999 (talk) 11:19, 22 January 2023 (UTC)

That's just it: Disambiguation categories are for things that are confusing (that is, words/phrases that have multiple possible meanings).

As for the downsides I see, I explained them above. Some users (and probably all automated processes) that assign categories don't do so correctly. Things will get categorized in the categories with unqualified names, whether they are disambiguation categories or not. It's better for those categories to be disambiguation cats so that things that get categorized there don't get lost in incorrect categories. -- Auntof6 (talk) 12:43, 22 January 2023 (UTC)

These seem to arguments about the use of "(disambiguation)" in general, not specific to my suggestion above. Enhancing999 (talk) 12:47, 22 January 2023 (UTC)

Edits to "guidance by topic"

i integrated rather outdated guides from special:permalink/703743320, and rewrote it to cover any kinds of structures instead of only bridges: special:diff/707887756. RZuo (talk) 13:11, 19 November 2022 (UTC)

Category scheme for people

In 2010, a reference was added from this page to Commons:Suggested category scheme for people which is stated to be "under construction" and not formally a policy. I don't know if here or VP is best but I think we should have a discussion if any of the suggested scheme should be policy because I don't think it's policy to refer to not-even guidelines. Ricky81682 (talk) 08:56, 22 January 2023 (UTC)

There is some good material here, and some problematic material. I think some of these ideas may be ready to discuss porting them over to actual COM:CAT policy, but probably not that document as a whole. Josh (talk) 03:58, 8 February 2023 (UTC)

Adding a caption makes page unfit to add categories until refresh

Fill in the Caption box of a file. Now at the top, add some categories with the "+". Result: warning that you are editing an old version. Must remember to manually refresh the page in the browser first. Or, first add the category, then the caption. Jidanni (talk) 01:11, 27 February 2023 (UTC)

Add idea sender link

The "Categories (++):" tool should have in its corner, a link to where to send ideas. Jidanni (talk) 06:40, 27 February 2023 (UTC)

Moving tens of thousands of files en masse

Tudor Collins was a photographer. We have about 21,460 of his photos at Category:Tudor Washington Collins. We also have a cat for his photos, at Category:Photographs by Tudor Washington Collins, but it contains only a dozen. I think we should move all the files in Category:Tudor Washington Collins to Category:Photographs by Tudor Washington Collins. Then we can manually move or copy the tiny percentage of them that have Collins as a subject back to Category:Tudor Washington Collins. I know I can move 200 files at a time with Cat-a-lot. Is there a way to move the thousands at once? Thanks. Nurg (talk) 07:57, 26 February 2023 (UTC)

@Nurg Commons:Bots/Work requests. RZuo (talk) 08:38, 26 February 2023 (UTC)

• That's easy enough (done now, although any to move back still need doing)

As a side issue, a lot of these seem to be duplicates? The negative (glass plate?) seems to have been scanned twice and we have one positive image, correct way round, but also a negative that's horizontally flipped. Should we delete those? Put them somewhere else? Andy Dingley (talk) 11:55, 26 February 2023 (UTC)

@Andy thanks very much. Your question about the negatives was the next question looming large in my mind. I wondered whether there is any standard Commons practice with regards to negatives for which we also have the positive. I am not very familiar with Commons deletion policy & practice. Personally I can't think of any use for these negatives, and at present I'm leaning towards deleting them. Separating them out is the other option, as you suggest, if there is a reason to not delete them. I certainly think we should do something with them, to declutter the main cats. Nurg (talk) 20:58, 26 February 2023 (UTC)

• I'd support deletion. I've not seen them anywhere else before and can think of no useful purpose for them here. The idea of moving them to another category is really just for some QC checking before deletion. I've found one already where the naming doesn't hold up – the positive was uploaded singly some time earlier File:1939 Plymouth rolling chassis.jpg Andy Dingley (talk) 23:51, 26 February 2023 (UTC)

• See Category:Photographs by Tudor Washington Collins (negatives for deletion) Andy Dingley (talk) 00:47, 27 February 2023 (UTC)

• I've listed these for deletion Commons:Deletion requests/Photographs by Tudor Washington Collins (negatives for deletion) Andy Dingley (talk) 11:25, 13 March 2023 (UTC)

  That failed. Someone should create the category since it's alive now. Ricky81682 (talk) 19:47, 18 April 2023 (UTC)

  The negatives often have wider crops, so while odd they may still be useful in some situations. Maybe they could be moved into a category like Category:TIFF images with categorized JPGs, which are for TIFF/JPG pairs (where the lossless one can be used for future editing efforts, but the JPG being a better crop or more convenient file format or size). For those, the JPG gets categorized so there are fewer visual duplicates in the categories. Most of those have a visual link in the JPG file to the corresponding TIFF though, so it's obvious when looking at the JPG that the other one exists. But something along those lines may make sense if we don't want to see (and categorize) each pair of images. Carl Lindberg (talk) 20:01, 18 April 2023 (UTC)

Also we should think about any useful ways to sub-categorise these by subject. 20k files is too unwieldy to be much use for anything. Andy Dingley (talk) 13:23, 26 February 2023 (UTC)

Category chooser wizard should appear even on categories that don't exists yet

Visit e.g., Category:Some category that doesn't exist yet. Well, there we can put another category's name in the box below. But wouldn't it be great if the same "+" "-" category chooser appeared near the top of this not-yet existing category too, to help us along? Jidanni (talk) 23:44, 26 February 2023 (UTC)

@Jidanni There's a work-around for that: The link to Category:Some category that doesn't exist yet will actually lead you to https://commons.wikimedia.org/w/index.php?title=Category:Some_category_that_doesn%27t_exist_yet&action=edit&redlink=1 - which is the page in edit mode. Go to your browser's address bar, delete the &action=edit&redlink=1 at the end of the URL and hit Enter. HotCat will be there. El Grafo (talk) 12:47, 13 March 2023 (UTC)

Don't offer redirects in match list

The Categories (++) tool should not offer redirects in its lists of matches. Jidanni (talk) 06:41, 27 February 2023 (UTC)

@Jidanni You mean HotCat? What exactly is the problem with redirects there? I think it's doing a pretty good job at resolving them automatically ... --El Grafo (talk) 12:37, 13 March 2023 (UTC)

Delete "Universality Principle"

I propose to delete this section.

It was added, undiscussed, by one single editor in a massive change of policies here. That seems to have been to try and justify some specific category discussions here: Category talk:Navigation consoles of watercraft (and others) that were being resisted by a number of editors. It has been cited again here: Commons:Categories for_discussion/2021/11/Category:Tracht. A massive change involving it came up more recently here: Commons:Categories for discussion/2020/01/Category:Gray and as that was (unsurprisingly) such a surprise, it then generated pushback here: User talk:JopkeB#Grey or gray?

There are two problems with this section. They are fundamental and cannot be addressed simply by editing the wording.

• It is contrary to all other WP policy and practice.
• It seems only to be used to introduce neologisms. Which are themselves against WP policy and practice, and they also reduce usability for readers by phrasing things with invented terms that are equally unfamiliar to all.

Commons is not Wikipedia and does not inherit Wikipedia's policies. Few have been explicitly copied across, most were thought to not be necessary. However it's still worth looking at them, and especially at the backstory for how they came to be. In particular en:WP:ENGVAR: because language differences are inevitable, and editor loyalties will lie with their own tradition, then there is no hope of ever finding a "best" solution. In the interim though, we need to avoid concrete problems, such as edit-warring and needless churn between versions. If a narrow use of a term does have an evident national link (such as Category:Grey road vehicles in London), and where the alternative with "gray" would be a wiki-invented aberrance, then of course it can be tied to that.

There is no reason at all why MediaWiki categories need to have consistent naming across their children. I am tired of people claiming this as some justification for this "Universality". MediaWiki works by tagging both "Grey vehicles in London" and "Gray aliens in Area 51" and "Things that are an iridescent rainbow and aren't monochromatic at all" with membership in the Gray category, then they're done. The parent category just doesn't care what the children are called. Nor do our readers: the names themselves, in relation to their content, is much more important than a false and contrived consistency imposed between them.

Neologisms are a real problem on both Wikipedia and Commons, but Wikipedia has policies that they mustn't be invented, Commons (this policy) says that they must! We should resist this. No-one is well-served by inventing nonsensical names for things, even if that makes them "consistent". We do not need any more attempts to invent Category:Driving stands of watercraft.

"Universality" does not work as a naming principle here. WP recognises that and long abandoned it, in favour of accepting stability and recognising national ties. We should do the same on Commons. Andy Dingley (talk) 17:43, 10 April 2023 (UTC)

• Agree strongly. "local dialects and terminology should be supressed in favour of universality if possible." No. - this would create huge amounts of local categories contrary to what locals actually call things. There have been several category discussions over the years where sentiment went the other way. We allow both "pubs" and "bars" rather than trying to pretend that every example worldwide is either one or the other despite what people who live there call it - etc. -- Infrogmation of New Orleans (talk) 23:48, 10 April 2023 (UTC)

  If there is no counter argument over this point, I suggest deleting that segment. -- Infrogmation of New Orleans (talk) 00:37, 18 April 2023 (UTC)

  that convention dates back to 2007. you cannot change commons conventions without at least an rfc. RZuo (talk) 08:39, 18 April 2023 (UTC)

  Thank you, so I guess starting an rfc is in order. -- Infrogmation of New Orleans (talk) 15:15, 18 April 2023 (UTC)

• @Andy Dingley: Has an rfc been started? If not I suggest you start one, as you seem articulate on the issue. Thanks, -- Infrogmation of New Orleans (talk) 19:00, 1 May 2023 (UTC)

 Comment I do not know if an RfC has been made elsewhere on this matter, but if so, it should merely direct participation to this existing conversation, there is no need to forum shop. I do strongly encourage posts on VP and other relevant pages to solicit comment here.

 Oppose I strongly oppose simply deleting the Universality Principle. It is one of the key principles that have guided building and maintaining the Commons category structure. It is absolutely important to permit a standard approach to category management and ensure a consistent presentation of cateories to users. It helps to avoid provincialism and local kingdoms. Given that Commons is a multilingual resource, but lacks at this time a proper internationalization process for category names, it was decided that category names would be in English (other than proper names without a recognized English style) as a general rule. Universality is fundamental to implementing this basic principle.

While Commons has selected English as the language for category names, it does not favor UK, US, or any other flavor of English over the other. Back and forth battles over spelling differences are counter-productive to the mission of categorization. Whether the name of a category is spelled "colour" or "color", "gray" or "gray", etc., is not as important as it being named consistently through the topic tree.

Keep in mind that Commons category names are NOT Wikipedia article titles or any other such thing. They are not prescriptive. The name is not there to tell people how to spell, and not even to say 'things in this category are called 'name' '. Category names are just names for a category, not some attempt to define a name for things beyond the category itself.

Calling a category Butcher's shops in Mexico is not some attempt to say they are called 'butcher's shops' in Mexico, that would be silly, they are called carnicerias there, and renaming it Carnicerias en Mexico would be destructive to the categorization system. Go to Japanese topics and the problem would become even more acute. The Universality Principle is the key principle which encourages the former name instead of the regionally accurate name.

Another flaw with regional naming is that access to Commons media is international, not regional, and international users cannot be expected to learn all local varieties to access our files. Consistent category names are particularly helpful to non-English speakers as asking them to also have to understand regional English differences on top of working in a foreign language is just one more hurdle in the way of international, multilingual access.

Exceptions have been allowed from time to time for certain topics. This is true for many policies and guidelines...exceptions can be made when discussed, there is a good reason for them, and the consensus is to do so. Using that as the basis for flinging the flood gates open and encouraging a mess of category naming by simply removing a guideline without a suitable replacement to prevent unintended consequences is foolhardy, and I can't agree with it.

There are several further reasons why the Universality Principle has been a good thing, and why it should be kept, but here are a few of the key ones:

1. Consistent names make it easier to maintain the hierarchical category system in accordance with the Hierarchical Principle.
2. Encourages discussions to happen at the main category level with maximum broad participation in the naming discussion.
3. Discourages fights over regional variations from continuing 'down the tree' to ever more local (usually lower-traffic) levels.
4. Simplifies template design and implementation, thus improving consistent look and feel for users throughout the topic tree.
5. Improves access for non-English speakers (the majority of the world).

Now I like others would love for an internationalization solution (such as WD's labels) to be implemented by Wikimedia, but until that elusive day, UP is key to keeping categories functioning as best possible. Encouraging provincialism and anti-standardization is going to be destructive and thus I strongly oppose simple deletion of the Universality Principle as proposed. Josh (talk) 23:09, 9 July 2023 (UTC)

 Keep I agree with Josh. Most important for me is, that I can search easily for subcategories and parent categories: just type Category:XXX in YYY or Category:XXX by zzz in the search field and you usually get what you want, without having to try variants or to go all the way up or down the category tree. JopkeB (talk) 04:26, 10 July 2023 (UTC)

In, From, Of

The common English language words "In" "From" and "Of" have distinct meanings familiar to native and advanced speakers. Perhaps they are not clear to some second/third etc English language speakers. Possibly some users have chosen to deliberately disregarded the meanings in a quest for some sort of uniformity in category names. Whatever the case, we seem to have a number of examples where the terms are misused. "In" refers to location and time. The location where a photo is taken is "in" that place. "From" refers to origin, for example the place a person is native of, or where an object was manufactured. "Of" is more general, and can refer to either or both "in" and "of"; it states a general but significant connection. (For example, if a Nerf herder native to Tatooine moved to Alderaan and had their photo taken in Alderaan, the photo could accurately be categorized in "Nerf herders from Tatooine" and/or "Nerf herders in Alderaan", but it would be a falsehood to categorize it as "Nerf herders in Tatooine" or "Nerf herders from Alderaan".) Is there agreement that these three small words should be used accurately in Commons categorization - and if there is not, what is the counterargument? Wondering -- Infrogmation of New Orleans (talk) 18:58, 1 May 2023 (UTC)

I think people often use the first word that pops up their mind. Sometimes they choose the word according to their intention with the category, without realising that the limitation imposed by the choice would require a parallell category tree with mostly the same content. Often the only thing you know is "in", as your motif is in that place when you take the photo. For celebrities "of" makes more sense, as you usually know where the person lives, but not necessarily where they are from (and that may be irrelevant, cf "Presidents from France").

There is also a true problem: you might want to include both presidents and nurses in People in/from/of X by occupation. Do you need three such categories for each country (or city, or whatever)? If you settle for just one (as we normally do), you probably don't want visiting presidents included, so you should say "of" (you really don't want "from"). So to avoid the visiting presidents you choose "of", and still include Nurses in X, and thus also those in the country for Médecins Sans Frontières, or on a workplace retreat across the border.

–LPfi (talk) 20:13, 1 May 2023 (UTC)

Along which lines this recent move by User:Trade seems a bit odd. We can easily know these people are in the United States, but the change to of seems to raise questions about our knowledge of the particular people in each photo. - Jmabel ! talk 01:03, 2 May 2023 (UTC)

It makes no sense for one set of age groups to use "of" and another set of age groups to use "in". I choose the former as that seemed to be the norm with men, women, children, boys and girls. Trade (talk) 18:55, 2 May 2023 (UTC)

I assume none of them is served by using "of". It is probably inherited from "People of", which includes authors, politicians and other celebrities. The age group categories are mainly for random people who might not be locals – that's at least my impression – and should thus use "in". –LPfi (talk) 20:17, 2 May 2023 (UTC)

I have no strong opinion as to which construction is better in this particular case. I only note that the three words have different connotations, and movement of any media from one to the other should always be done with awareness for every single file, making sure no inaccuracies are introduced. I do feel very strongly that "consistency" should never be used as an excuse for falsehoods in categorization. -- Infrogmation of New Orleans (talk) 20:56, 2 May 2023 (UTC)

• The cases where there is a practical need for more than one construction may be unusual, but certainly can exist. One of the few I've noticed is separate Category:People in New York City and Category:People of New York City, which seems entirely appropriate as they mean different things and there are many media in both categories which would not be appropriate for the other. -- Infrogmation of New Orleans (talk) 21:01, 2 May 2023 (UTC)

Of, from, in, and other prepositions should be used consistently, however in practice this needs some work. LPfi is correct that generally it seems people use what seems logical at the time of naming, or what sounds right to them. This is because while English speakers usually know what they mean when they use prepositions, there are also a lot of different relationships that can be defined by a given preposition and multiple prepositions that can be applied to some relationships. As an experienced English speaker, this may not pose much of a challenge to sort through most of the time based on context and such. However, for a less-experience English speaker, or especially one relying on translation tools to navigate English-named categories, this is more of a problem. Thus for Commons categories, there is a more simplified preposition employment that seems to work well while being relatively simple:

• Of is the broadest preposition and thus can serve well in cases where only one relationship is categorized (as noted this is most topics). Alternatively, in cases where there are various prepositional relationships for the same two topics, 'of' works as the parent 'catch-all' with others as sub-categories. Essentially, an 'of' category means essentially "'Topic A' related to 'Topic B'".
• In is more specific: "'Topic A' located within 'Topic B'". This is usually geographic, but can be other spatial situations, and is usually indexed in a 'by location' index.
• From has to do with origin: "'Topic A' with an origin of 'Topic B'". Exactly what this means can differ based on the topics, but is usually indexed in a 'by origin' index.
• With indicates setting or composition with other subjects: "'Topic A' depicted with 'Topic B'" or "'Topic A' with component 'Topic B'".
• By is generally reserved in the topical tree to incdicate "sorted by" in indices where is it is "'Topic A' by 'sort criterion'" and in the media by source tree to indicate the creator of the topic: "'Topic A' created by 'Topic B'".

These are just the basics but cover the vast majority of actual use cases. Unfortunately, there are a lot of topics which use other interpretations of the above prepositions, so we are a long way from standardization across Commons. In any case where it might not be clear, more specific prepositional phrases can be used ('born in', 'in service with', etc.) as it makes sense. An example where several are used is Aircraft.

Applying the case above (Teenagers in the United States), "in" is the more specifically correct to indicate that the category is for pictures of teenagers actively located in the United States, regardless of origin or such. "Of" could include Canadian teenagers visiting the United States (they are 'in' the US), or Americans visiting Canada (they are 'from' the US). "Of" does have some connotations of ownership or belonging to, and so if indeed both of the listed cases exist and are deemed worthy of a category, the Canadian visiting the US should be in Teenagers in the United States and the American visiting Canada should be in Teenagers from the United States. Both of these categories can then be grouped in Teenagers of the United States. Josh (talk) 23:54, 9 July 2023 (UTC)

Museum exhibits and "November 2012 in Strasbourg"

See Category:November 2012 in Strasbourg and @Edelseider:

Should images be categorized to these narrow date/place categories solely on the basis that this is when a passing Commons photographer happened to press the shutter? I am thinking here (as this category is filled with) of museum exhibits which happen to be displayed in Strasbourg and were accessible on that date to be photographed, no more than that. The focus of the subject has no inherent link to either place or date.

Most of these images have nothing to do with Strasbourg in 2012, except for the coincidence of their photography. They are not of Strasbourg as a subject, by an artist connected to Strasbourg, of a subject of that date or even part of a temporary exhibition on that date. All of those would be justifiable reasons to categorize them.

The metadata here is about the image, not anything to do with the subject. We also record that they were taken with a Nikon P900, but we wouldn't invent "Category:Photographs by a Nikon P900 in Strasbourg".

All this does is that it dilutes the content that really does depend on "November 2012 in Strasbourg". Even when that's a relatively broad link, such as "the 500 year old church in Strasbourg, with people of 2012 wearing the fashions of that era walking past". Such a link does still have some temporal relevance, but a museum gallery is deliberately timeless and isolated. Andy Dingley (talk) 09:32, 12 July 2023 (UTC)

@Andy Dingley: I can see your point, but you've missed the bigger picture. These November 2012 photographs happen to have been taken during an exhibition ([1]), which is a special occasion and a specific event in time. Most of the artworks were on loan from abroad, this photo for instance shows a painting usually displayed in the National Maritime Museum in London. --Edelseider (talk) 09:44, 12 July 2023 (UTC)

Also, artworks tend to change over time - they darken, cracks appear or become larger, or they are restored and suddenly look brighter and fresher. Commons is full of photographs of artworks in a state before restoration and a state after restoration. --Edelseider (talk) 09:48, 12 July 2023 (UTC)

The exhibition aspect is far from clear though. If that's the case, then I'd suggest creating a category for that exhibition, placing the images into that, and placing that exhibition category into the place/time category. This would make it much more visible.

As an example, why is File:Loutherbourg-L'Abbaye de Tintern, sur la rivière Wye.jpg here? It's part of a well-known series of paintings connected with SW England / Wales and still in SW England. There's nothing here evident to connect it to Strasbourg, so the categorization is never more than confusing.

If the history of the artwork is so important (and almost never place related), then categorize that on the artwork. An obvious example is Rembrandt's Night Watch and the several restorations that has had. Andy Dingley (talk) 10:17, 12 July 2023 (UTC)

Short answer: a time in place category is always welcome. Slightly longer answer 1: the more we try to decide that this is relevant for some photos and not for others, the less likely people are to add them. I'd really like to have everyone add this as a near-reflex on uploading. Slightly longer answer 2: yes, a category for an exhibition is also great, but exhibitions are usually longer than a month, while our usual time in place categories for recent history of cities are a single month. - Jmabel ! talk 13:58, 12 July 2023 (UTC)

Why do we bother with categorization? It's not to give a definition of the content (and can't), it's navigational, in order that relevant content can be found by those searching for it.

An artwork categorized with time and place adds nothing, unless that association has meaning. What if I photograph the same artwork fifty times, and put it in a different cat each time, because it's been hanging on the same museum wall for years. That's of no use to anyone.

The exhibition context has value, but only if it's identifiable. The Tintern painting gains nothing from being in Strasbourg in 2012, because nothing else tells me that it was there for a specific event (and I know that normally it's not even in the country). If the exhibition has a category, then I'm fine if that's no more specific than 2012, because that's how I'll be looking for it (over-sliced Commons cats are also a problem from those who don't know SPARQL and have a working query endpoint). Andy Dingley (talk) 16:08, 12 July 2023 (UTC)

Very much agree, especially with dilutes the content that really does depend on [some category name like "November 2012 in Strasbourg"].

It not only dilutes but there are further issues such as not being relevant, not being what the user looks for there and being distracting. One of the reasons why I don't think the image that will come to your attention first at Category:Wooden ladders in Russia is appropriate in that specific category, albeit there are more problematic cases. Prototyperspective (talk) 17:03, 12 July 2023 (UTC)

Exey Panteleev is a problem all of their own Andy Dingley (talk) 11:10, 13 July 2023 (UTC)

It's useful for someone who wants (years later) a sense of what was in that time and place. I wish I had clarity of like this on a ton of third-party images we have from Seattle over the course of more than a century. - Jmabel ! talk 17:30, 12 July 2023 (UTC)

Agree in principle. And partly precisely because of that (the usefulness and relevance you described), such images should not be in this cat.

...or at least only in a subcat of it to which a user likely navigates through other routes or means (cats are not only 'navigational') than via for example a cat "November 2012 in Strasbourg". Prototyperspective (talk) 22:55, 12 July 2023 (UTC)

"a sense of what was in that time and place" Yes, very much so. So a photo of a group of people in mini skirts in the Rijksmuseum in Amsterdam in 1970 shows us something of museum visitors of that era and place. But a simple reproduction of a Rembrandt on the wall there has been there much the same for a hundred years beforehand, and likely hundreds to come. The intersection of photographer / time alone is too trivial to record by category (we have the metadata otherwise).

But what's worse in this case is that there is some relevance, but that the blunt categorization to month rather than to exhibition doesn't show that. Andy Dingley (talk) 11:10, 13 July 2023 (UTC)

New line in Commons:Categories#Selectivity principle

The outcome of Commons:Village pump/Archive/2023/08#How independent is Commons in deciding which categories are appropriate? was an extra line in Commons:Categories#Selectivity principle: "There should be one category per topic; multi-subject categories should be avoided." I just did that. Could an experienced user please look whether that is OK so, or should still a translate tag be added? JopkeB (talk) 14:28, 20 August 2023 (UTC)

@JopkeB That looks fine to me. Josh (talk) 23:20, 21 January 2024 (UTC)

Category naming purpose

As has been noted in recent CfDs, the section on category names does not clearly enough convey the role of category names and has led to confusion with some users. The section on this page give a reasonable amount of technical detail about naming specifics, but little on the actual purpose of choosing a specific name for a category. It would be good to offer a bit more of an introduction to naming so users can more easily see the principles of why specific names and naming formats are appropriate and what role category names play in categorization and Commons at large. To that end, a simple starter paragraph in the "category names" section would be helpful, along the line of:

Category names serve to give users a quick idea of what topic is depicted by the contents of the category and make the contents of the category easily discoverable by users seeking them. They are generally to be concise, unique labels in common-usage English which are descriptive of the concepts depicted in their contents (i.e. they encompass the topic). They should be specific enough to give users a clear picture of the intended scope of the category. However, they are not a comprehensive definition of the contents; additional details on what should or should not be contained in a category should be provided in a hat note.

While this all may seem obvious to some experienced editors, and some of it may reinforce points made elsewhere in the article, a clear introduction in the category names section may help some users who are not as familiar with this article in its entirety or categorization practices in general. Josh (talk) 01:41, 22 January 2024 (UTC)

 Agree Thanks for starting this proposal. I would like to make some sentences somewhat shorter and splitting them to make it easier to read, and changed some words which are more clear for non-native English speakers. In my proposal I have changed the bold parts. Please adjust them if it is not proper English.

Category names serve to give users a quick idea of what topic is depicted in(?) the contents, it is all about: What is this category about? Users seeking such content should also be able to find easily the category by searching for its category name. Therefor category names are generally to be concise, unique labels in common-usage English that encompass the subject of the category. They should be specific enough to give users a clear picture of the intended scope of the category. However, category names are not a comprehensive definition of the contents; additional details about what should or should not be included in a category, can be provided in a short note.

Please let me know whether this is indeed an improvement. JopkeB (talk) 16:16, 22 January 2024 (UTC)

@JopkeB Thanks for the feedback. I will update what I have above to consider yours and any other suggestions in a few days when I can give this another good look. Josh (talk) 17:06, 22 January 2024 (UTC)

I think "find" and "easily" need to swapped but I'd prefer "discoverable" (which would be very good to include there), "Therefor" should be "Therefore", and I think "descriptive of the concepts depicted in their contents". "(i.e. they encompass the topic)" could be replaced with something like " – they name the subject of the category".

One could replace "short note" with "short note at the top" and one could also add " and should be short" after "…of the contents".

Moreover, one of the many code proposals I intend to submit sooner or later (now there is too little work even on far more important issues) is that when entering a category name or something close to it (like a category name but singular such as "Map" where cat "Maps" exists), it shows a link-box at the top of the search results with A category of this name exists: [link to cat] where something similar is already implemented with the "Did you mean" (light-bulb icon) boxes of which I don't have an example right now. Prototyperspective (talk) 10:34, 28 January 2024 (UTC)

Definitely can rather than should be provided in a short note on the category page. The majority of categories don't need a note. - Jmabel ! talk 21:42, 22 January 2024 (UTC)

Edit mode link

Hello @Jmabel: regarding your edit comment the little bit strange edit mode link Category:PD NASA in edit mode was already in the page, it wasn't me. Feel free to change that. With the rest of my edit pointing out the difference between using the __HIDDENCAT__ or {{Hiddencat}} I hope you agree!? And I see it was even there before my edits in November 2022 on this page. Regards --W like wiki ^{good to know} 02:21, 8 February 2024 (UTC)

@W like wiki Sorry, I didn't look closely enough at the diff to see which part was new. - Jmabel ! talk 02:37, 8 February 2024 (UTC)

@Jmabel: ok! --W like wiki ^{good to know} 02:44, 8 February 2024 (UTC)

Sortkey recommendations

Regarding this:

The special sortkey τ (lowercase Greek letter Tau) is used to sort templates at the end of the related Commons-category, see for example Category:Transport templates sorted in Category:Transport. (Sorting in Commons is not case sensitive so only uppercase Τ (Tau) is shown.)

I wonder whether this is a good recommendation. I tried it for a few categories and I found it quite confusing because the uppercase Tau is, in practice, visually indistinguible from the latin letter T. I see a lot of template categories with a sortkey of ~ and would actually consider that a very good idea because it's sorted after Z, it's visually recognizable, and it's a character which you probably can find on way more keyboards than the Tau.

On a side note, I would expect using three different dashes as sortkeys to create a lot of confusion, and for many people it will be hard to understand the difference between them. So I would also suggest to remove any mention of the emdash and the endash here.

Thanks -- Reinhard Müller (talk) 15:35, 16 February 2024 (UTC)

agreed. i think common practice is using ~ for anything commons-, or more broadly, wikimedia-related stuff.

the dashes were added by https://commons.wikimedia.org/w/index.php?title=Commons%3ACategories&diff=prev&oldid=703824439 . RZuo (talk) 15:40, 16 February 2024 (UTC)

@W like wiki: any input from your side? --Reinhard Müller (talk) 15:53, 22 February 2024 (UTC)

Grüß Dich @Reinhard Müller: Yes, I agree. I can't remember on which Commons page I read this recommondation with the Greek Tau before including it here, but I had always the same problems, need to copy paste it from here or even made a copy of this on my user page. And also about the equal look to normal "T" I was not so happy, but when I wrote this chapter I can not create a new rule. But when we do this now I appreciate!

Same with the dashes. Maybe some have an idea if they are useful, but also here I would apreciate a changing, deletion in this case. Best Regards -- W like wiki  ^{Please ping me! • Postive1 • Postive2}  16:25, 22 February 2024 (UTC)

Thanks to everybody who commented! I updated the page and hope that I didn't mess up anything regarding the translation. --Reinhard Müller (talk) 18:15, 22 February 2024 (UTC)

Controversial categories

Hi, I'd like to get feedback regarding categories that can be seen as controversial. On en-wiki, there is a rule that

Categorizations should generally be uncontroversial; if the category's topic is likely to spark controversy, then a list article (which can be annotated and referenced) is probably more appropriate.

As far as I can see there is no such policy on Wikicommons. Is there some other policy which deals with this issue? What is the community consensus?

To provide a concrete example, this edit added back the category Territories under occupation by Russia to the category Abkhazia. This is controversial, since while the overwhelming majority of countries consider Abkhazia to be a part of Georgia, only a minority explicitly said that it's occupied by Russia (see Wikipedia:Russian-occupied_territories_in_Georgia#International_position).

I believe that this category isn't helpful since the category name cannot explain all these nuances. It would be better to create a page/gallery with the related media. I'm pinging User:Laurel_Lodged who has added this category. Alaexis (talk) 09:21, 28 May 2024 (UTC)

I agree that some such policy is needed in Commons. I agree that "Categorizations should generally be uncontroversial". But one editor's uncontroversial is another editor's hot potato. Unlike Wiki, Commons does not lend itself to list article creation. So the likely solution is a case-by-case evaluation and an agreement to adhere to community consensus. By the way, regarding Abkhazia, Wiki itself says, "On 23 October 2008, the Parliament of Georgia declared Abkhazia a Russian-occupied territory, a position shared by most United Nations member states. So it's not just me. Laurel Lodged (talk) 15:05, 28 May 2024 (UTC) Laurel Lodged (talk) 15:05, 28 May 2024 (UTC)

Ehh, where do you see that in the source? I've tagged it on en-wiki. If I'm missing something and the source does say it, then indeed it wouldn't be controversial and I would not object to placing Abkhazia in this category. Alaexis (talk) 20:23, 28 May 2024 (UTC)

"Georgia asserted that the territories of South Ossetia and Abkhazia, including the upper Kodori Valley, were occupied by Russian forces. On 23 October, the Parliament of Georgia adopted a law declaring Abkhazia and South Ossetia “occupied territories” and the Russian Federation a “military occupier.” This claim was reiterated […] In describing the “current occupation” Georgia also stated: “the western part of the former ‘buffer zone’ (the village of Perevi in the Sachkhere District) remains under Russian occupation." If Wiki is making claims not supported by sources, then Wiki is the place to make those edits. Laurel Lodged (talk) 10:30, 30 May 2024 (UTC)

Yes, absolutely. But there is a difference between *Georgia* considering it an occupied territory and "most UN members" sharing this position. I never argued with the former. Alaexis (talk) 08:42, 1 June 2024 (UTC)

 Question @Alaexis, @Laurel Lodged It is hard to tell if this is really a question about general policy or if it is really a discussion about a particular case. In the case of the latter, this should really be had as a CfD over Category:Abkhazia. If there is a change to policy that you think would help improve things, that should be discussed here, and you can certainly refer to this case as reference. Josh (talk) 20:15, 18 July 2024 (UTC)

References

FYI: Moved historical page, redirected that target to this page

"Commons:Naming categories" now redirects to this commons: ns page. It was problematic for the number of links (internal and from WD), and the confusion being caused with the pre-existing arrangement.

The page that was at that space is now at Commons:Naming categories (historical). The number of links to its detail are minimal, and it should not be problematic for functional management of this site having it moved.  — billinghurst sDrewth 00:02, 31 May 2024 (UTC)

@Billinghurst Thank you for doing that, it is a big help to avoid confusion for folks. Josh (talk) 20:02, 18 July 2024 (UTC)

Sortkey recommendations

a question that bounced around in my mind a few times is what are the purposes of each of the symbolic sortkeys? the most commons ones I see are '(space)', '*', '+' and '~'. what are their roles?

So far, that's not clearly defined, and different people use completely different sortkey prefixes for the same purpose.

I have collected a few ideas about what could be seen as "best practice". I don't know whether we actually want to come up with a policy or at least a recommendation, but if, then this list might serve as a base for that. Thanks --Reinhard Müller (talk) 07:02, 9 July 2024 (UTC)

another thing while discussing sorting is a common thing that I see in category pages with accent marks in the titles: they use {{DEFAULTSORT:}} to exclude remove the accents. simple example is 'café' which is turned into {{DEFAULTSORT:cafe}}. if this is something that should be encouraged in the wiki, please feel free to add it to the policy! Juwan (talk) 10:11, 8 July 2024 (UTC)

@Reinhard Müller, thank you for sharing some ideas on ways to use a variety of sort keys to sub-sort by type of sub-topic. I am often frustrated by the willy-nilly use of special characters by users, especially to '+1' their preferred topics to the top of the list. I readily use a few established special characters for sorting non-topical categories, such as a space for index categories, # for numbers, ? for 'unidentified' (maintenance) categories, and ~ for some other types of maintenance categories. For topical non-number categories however, I do not see the attraction of using special character sorting, as it requires a few things at a minimum:

1. The user must already be familiar with the sort key special character system.
2. The user must parse the topic they are seeking, in order to figure out which special character they should look under.
3. The system has to be consistently-enough employed that once a user has passed hurdles 1 and 2, they can have some confidence they will actually find what they are looking for.

Currently, none of these are true for a lot of the special characters, and so I generally resist using them for topical categories, and while I think your list is well thought-out, I don't think in the end that it provides any real additional value over using the alphabetical sort system that categories are fundamentally based on.

As for using sort-keys for normal alphabetical sorting (e.g. using sortkey 'buildings' to sort Category:Science buildings in Category:Science), that is extremely useful and I use it a lot. I do think some additional guidelines right here on COM:CAT to help users quickly grasp common practices is a good idea. Josh (talk) 19:56, 18 July 2024 (UTC)

it is certainly a very nice scheme. the only issue in my case is what you've raised. is this perhaps going too far? as in, is it too complex for someone to understand, especially without necessarily having to read the policy? Juwan (talk) 20:21, 18 July 2024 (UTC)

@JnpoJuwan I always try and keep accessibility front and center in my mind when considering categorization. For someone like me who's been on the project since its inception (or close enough anyway), I am able to take the time to learn and apply various elegant schemes for organization, but for especially newer or irregular users, that really isn't practical. Even as a veteran, I am routinely frustrated when I look for something and don't find it (such as buildings under b) but instead have to then figure if a) the sub even exists, and b) what special character did someone come up to sort it under. Having a standardized key list and implementing it consistently might help that for me since I spend a lot of time in categories and can learn and keep fresh that knowledge (I even kind of like the scheme), but I still don't think it helps the bulk of less-regular users just looking to sort their contributions or find images for their projects. For this reason, I think it falls down on the accessibility question. Josh (talk) 20:59, 18 July 2024 (UTC)

@JnpoJuwan As far as accent marks (or their suppression) in sort keys is concerned, I have seen some discussion on whether the current sort algorithm handles accents and other diacritics as it should. It is certainly not consistent about how search handles them. I don't know if we really should be suppressing them though, and I generally don't in the few cases I've had them to worry about. My native language doesn't use diacritics (except for borrow words) so I probably don't have the best intuitive feel on which way to go on this question. Josh (talk) 20:01, 18 July 2024 (UTC)

to give you some perspective, in my native language Portuguese at least, we tend to ignore accent marks when sorting, so an algorithm would sort it like so: aa áb ac. I haven't seen how other languages manage their sorting schema (speakers of, for example, Spanish, German, Swedish would probably want diacritics kept), I need more opinions on that side. Juwan (talk) 20:18, 18 July 2024 (UTC)

@JnpoJuwan Thank you for that insight, it is always fascinating how different languages have such different perspectives on the world. As a mono-lingual project with a multi-lingual audience, that remains a big challenge for Commons to grapple with. Josh (talk) 21:01, 18 July 2024 (UTC)

Spanish considers ñ a distinct letter between n and o; accented vowels are treated as if the accent weren't there, except if words are otherwise identically spelled (e.g. que and qué), in which case the unaccented one comes first. Historically they treated ch as a single latter sorting after c and ll as a single letter sorting after l, but in the last few decades that has largely disappeared.

German normally sorts ä, ö, and ü as ae, oe, and ue; the difference is considered a typographic convention. Ditto for ß and ss.

Romanian sorts ș after s and ț after t and considers them distinct letters. Similarly a, ă, â are considered distinct letters (in that order), and the same for i and î.

Those are the only languages other than English where I know enough to speak confidently. Inconveniently, as far as I can tell, mediawiki doesn't readily support correctly sorting ñ, ș, or ț, nor the three non-standard Romanian vowels. - Jmabel ! talk 21:43, 18 July 2024 (UTC)

In my native language Hungarian, ö (and ő) is sorted after o (and ó), the same goes for u/ú and ü/ű (other diacritic differences – including those between o and ó, between ö and ő etc. – count only if there’s no other difference, but di- and trigraphs have their own places – if they really di- or trigraphs, and not only those letters next to each other; a rule nearly impossible to create an algorithm for). This means that according to the Hungarian rules, Olaszliszka goes before Öcsöd – however, according the German rules, it’s just the other way round, Oecsoed being before Olaszliszka! This demonstrates that a Commons-wide default cannot fulfill all languages’ needs, so I think the only sensible default other than the current one is completely disregarding accents, i.e. treating ñ and ň the same as n; ö, ő and ô the same as o; ș, ş and š the same as s, and so on. —Tacsipacsi (talk) 22:21, 18 July 2024 (UTC)

in short, is what {{DEFAULTSORT:}} tries to achieve is a way to bypass MediaWiki's (current) technical restrictions? Juwan (talk) 22:53, 18 July 2024 (UTC)

@JnpoJuwan: not really. Even with {{DEFAULTSORT:}} we have to live with most of those restrictions. But (besides the issues that started this discussion about handling incommensurate subcats separately) {{DEFAULTSORT:}} lets us

• sort people "last name first" (though increasingly this happens implicitly as a side effect of Wikidata Infoboxes)
• sort numbers sanely (by default they'd sort alphabetically) so we can force a sequence 1, 2, 3, ... 9, 10, 11, ... 20, ... instead of 1, 10, 11, ... 2, 20, ... 3, ... 9
• do things like in a language where every public square is going to begin with "Plaza", sort a list of public squares by the part of the name that actually matters, so not everything is just lumped under "P"

As noted above, some other uses are more controversial. - Jmabel ! talk 05:04, 19 July 2024 (UTC)

sorry, I didn't specify that I mean in this context. these are all perfectly fine uses that I am aware of and have used before. Juwan (talk) 23:46, 21 July 2024 (UTC)

Use of English varieties in category names

There was a discussion at Commons talk:Categories/Archive 4#LANGVAR in category names ?, and many users had expressed support to implement local dialectal names for categories. However, there was no consensus on the proposal by Joshbaumgartner, which would implement it. So I have modified the proposal and drafted it at User:Sbb1413/ENGVAR proposal. It is not intended to be a separate policy. Rather, it is intended to be additions and modifications of the existing policy at COM:CAT to accommodate local dialectal terms. The main changes of this proposal include the avoidance of ambiguous dialectal terms. Sbb1413 (he) (talk • contribs • uploads) 14:02, 18 July 2024 (UTC)

I have formally withdrawn the original proposal. See the "New proposal" section below for further discussions. --Sbb1413 (he) (talk • contribs • uploads) 18:27, 11 August 2024 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

• Assuming we leave base topic categories like Category:Car parks rather than matching the Wikipedia article w:Parking lot should we:

  A, say that (due to requiring English) when there is no national variant we leave all sub categories at the title created and thus can't move Category:Parking lots in Austria to Category:Car parks in Austria to match Category:Car parks.

  B, say that when there is no national variant we match the base topic category so use Category:Car parks in Austria not Category:Parking lots in Austria and if Category:Parking lots in Austria is created its acceptable to move to Category:Car parks in Austria. When there is a national variant like Category:Parking lots in Vermont we use that and not Category:Car parks in Vermont.

  C, say that we always match the base category thus Category:Parking lots in Vermont should be renamed to Category:Car Parks in Vermont. Crouch, Swale (talk) 14:09, 18 July 2024 (UTC)

  I would support the option B. Obviously, if you don't have any national variants, then you should apply the first sentence of the Universality Principle (the second sentence is being altered per my proposal) and rename "parking lots" to "car parks". However, if most (or all) of the subcats are named "parking lots", the parent should be renamed to "parking lots" instead of the other way around. This is normal for topics without national dialectal terms. My proposal is aimed to topics that have different terms in different countries. Sbb1413 (he) (talk • contribs • uploads) 14:17, 18 July 2024 (UTC)

  I hate to be pedantic about it since it's sort of tangential but "parking lots" and "car parks" aren't usually the same thing. Although there is some overlap there. Generally though parking lots can be any place where you park a car regardless of size. Whereas car parks are usually much larger parking "instillations" (for lack of a better way to put it). So it's possible that the difference in categories names is just because the images in said categories are for different types of parking areas. Not necessarily differences in a local dialect or whatever. Which I think is relevant to this. As it's kind of hard to determine as a random bystander what's a local term for something versus just different type of that thing. Like personally as someone who lives in the United States I'd say we have both "car parks" and "parking lots." Again, depending on the size of the parking area and if it has on site facilities or not. It's not really a regional dialect thing though. --Adamant1 (talk) 14:43, 18 July 2024 (UTC)

  I support option B as well. Category:Controlled-access highways might be a better example where in British English we use "motorway" and in American English "Freeway" but "Controlled-access highway" is a COMMUNALITY title. Category:Petrol stations should probably be renamed Category:Filling stations per COMMUNALITY. Crouch, Swale (talk) 15:00, 18 July 2024 (UTC)

  Category:Petrol stations should probably be renamed Category:Filling stations per COMMUNALITY [sic].

  Category:Filling stations redirects to Category:Fueling stations, which includes several types of fueling stations other than the conventional fuel stations for motor vehicles (petrol/gas stations). So Category:Petrol stations will remain as it is. Since we already have the universal term Category:Controlled-access highways, it might be unnecessary to have dialectal terms for each country. So I will add another exception to my proposal. Sbb1413 (he) (talk • contribs • uploads) 15:07, 18 July 2024 (UTC)

  • Even in U.S. usage, not all controlled-access highways are freeways. There are also turnpikes (a.k.a. tollways) and parkways (more systematically landscaped; mostly in the Northeastern U.S.). (There are also the terms "throughway" and "expressway", but I don't believe there is any special meaning there, they are either freeways or turnpikes). Just to confuse things more, there are a fair number of roads with "turnpike" in their name that are no longer toll roads, so "tollway", while less common than "turnpike", might be the better choice; also, some parkways have tolls. There might even be some other terms I'm not thinking of. - Jmabel ! talk 16:55, 18 July 2024 (UTC)

@Sbb1413 Thank you for raising this for some further discussion. This represents a potentially significant redirection in our category naming approach and as such you are completely correct to frame it as a change/addition to current Commons category policies as opposed to a new stand-alone policy. I think this is a good approach, as it necessarily requires us to consider any impacts on existing comcat and adjust them at the same time to rectify any inconsistencies that might be exposed were this merely to be put forward as an unrelated new policy. I unfortunately have some other priorities at the moment, but I want to give this due thought and provide a comprehensive input, though it may be a week or so before I can do that properly. In the meantime, I would like to get clarity on a couple of items just to understand the starting point here as accurately as possible:

1. Would the intent be to have an official list of approved language variations for specific topics with due process required for additions or changes, or is each topic to simply be up to the normal wrangling among users over which term is right in their given locale?
2. Would the intent be to retroactively apply this policy to existing topics, or to stick with the policy of needing more than just langvar reasons to change an existing category?
3. What ultimate authority, if any, would we be relying on to determine correct langvar?

I'm sure there will be more to follow. Josh (talk) 19:39, 18 July 2024 (UTC)

@Joshbaumgartner My answers:

1. The intent is to have a consensus-based list of accepted language variations for certain topics. The list will be inserted at the top of a topic category. For small categories, additions and changes would be done boldly, while larger categories would require agreements with some other users.
2. This policy will be retroactively applied to existing topics.
3. The ultimate authority to determine the correct ENGVAR is of course consensus.

Sbb1413 (he) (talk • contribs • uploads) 11:27, 19 July 2024 (UTC)

I have created a rough draft of a templated list of consensus-based English dialectal terms at User:Sbb1413/ENGVAR template. This can be a standalone template or a part of {{Topic by country}} and {{Country category}} templates. China and Russia are included for their own English terms for "astronaut". Sbb1413 (he) (talk • contribs • uploads) 12:03, 19 July 2024 (UTC)

@Sbb1413 Thanks, those are more or less along the lines of what I would have guessed. I think the right way to do the {{Topic by country}}, etc. templates would be to build in a langvar switch of some sort, ideally without requiring manual activation, with the approved variations added into the data templates. However, I wouldn't really worry too much about exactly how to do the templates at this stage. I would simply remark that converting templates to support this will be its own effort for a team to develop and implement once the new policy is enacted. This discussion should focus on what the right policy is and getting the language (no pun) correct for COM:CAT. Templates and other tools will have to follow suit. Josh (talk) 12:43, 19 July 2024 (UTC)

One of the things that strikes me as I think about this direction, is that all of the logic for saying that Australia categories should be given Australian English names instead of the universal English topic name, or Canada, the US, etc., is the same logic that would say France should use French or Mexico should have Mexican Spanish variations of a topic name. Obviously, we are starting this discussion limited to English variants, but realistically, I'm not sure that is anything more than a purely arbitrary line we are drawing. Just a thought. Josh (talk) 12:52, 19 July 2024 (UTC)

@Joshbaumgartner We can use the same English term for all countries if it is used by all the major dialects. If such term doesn't exist, some countries will use their own regional terms while others will use the "universal English topic name". Since our core naming policy is to use English in category names as much as possible, we obviously shouldn't extend this proposal to other languages. Although gallery names can use local languages, the dialects of other languages (except Portuguese) don't really differ by spelling or vocabulary. Sbb1413 (he) (talk • contribs • uploads) 13:07, 19 July 2024 (UTC)

Well our core policy is also to apply the Universality Principle, and this proposal is considering upending that. In fact, from a legal theory perspective, I would posit that the universality principle is the primary supporting principle of the English-only naming policy, or at least it is the key reflection of the policy's intent, i.e. if the UP goes (or is neutered), then what real basis is there for the English-only policy? I totally understand that we don't necessarily want to extend this proposal to other languages, as that would be a much bigger fish to fry and may bring in some vocal opposition, but I'm not sure if maintaining English-only is still tenable if the UP is eroded. I don't think this is a point for or against this effort, just a consideration of potential future ramifications. Also, this is a fundamental policy change being considered, so I would not consider anything obvious. As for variations in other languages, I know Spanish spoken in Mexico has plenty of variation vis-a-vis Spain or even other parts of Latin America. That is my only personal practical experience with a non-English language, so I'm 2-for-2 so far on language variations being a thing. However, even if a language is completely homogenous across its usage, it doesn't change the point that localization is localization, whether we are talking variants or entirely different languages. Josh (talk) 13:32, 19 July 2024 (UTC)

 Oppose Can we have some compassion with people on Commons who do not have English as their native language? It is OK to have English as the main language for categories, I agree with that. But let's not allow all kind of local variations of English within a category string.

• Not only for myself (Dutch, wich is a language in the same (German) language family as English, and so relatively close to English), but I also think of all people at the other end of the language spectrum, who are even used to another script than Latin (a lot of Asian languages + Cyrillic + Greece and I might forget some).
• I do not only search along the line of a category string, but also via the search box. If I know that the main category is "Gray", I expect that I can search for Gray houses in Norfolk, England‎ as well, and not have to know that is then "Grey". And if the main category is "Flower shops", I do not want to have to search with "Florist shops" for Leeds.

Let's keep it simple, and let everybody has to adjust; in comparison with non native English speakers to me it looks a little sacrifice for the people who are used to local vatiants of English. --JopkeB (talk) 10:19, 22 July 2024 (UTC)

@JopkeB, this is one of my primary concerns. Requiring that users have some ability to work in English (possibly through 3rd party software) seems at the moment unavoidable given the technical limitations of the basic software. However, this is a multi-lingual project, and conceivably should permit full utility for users regardless of their particular language skills. Universality seems to be the best solution for this that I am aware of since at least once a term or phrase is known, it can be relied on going forward, per your 'gray/grey' example. As a native English speaker (are are probably the plurality of Commons users), I have no problem at all reading 'flower shops' and 'florist shops' or 'gasoline stations' and 'filling stations' and instantly understanding what is being said, but even then, I share the frustration of having to try several searches for a sub-category, even when I know the parent category name, not sure whether the sub-category just doesn't exist or if I should try another different term or format. I can only imagine that frustration is multiplied for those without native or even substantial English knowledge. Any proposal to deviate from Universality would need to clearly show that it will not add any additional hurdles for non-English users (the majority of the planet) for me to support it. Josh (talk) 20:24, 22 July 2024 (UTC)

•  Oppose Per JopkeB and Joshbaumgartner. You can get into some pretty sketchy and pedantic territory when you allow for local variations. Even with English, which would seem to only have a few, but actually have quit a lot. See California English for one example outside of British and American English. There's also Scottish English, Irish English, Etc. Etc. We shouldn't have to figure out which variation to go with every time we want to search for a category per the Universality Prenciple and just because it would be a major pain the ass. It makes sense to use American English as the standard though because it's most widely used form of English in the world. No offense to British people, but British English is only spoken in Britain and a few former colonies and there's no reason to over turn the University Principle (which as Josh points out is at the core of Commons policy) just to adopt a niche form of English. That doesn't even get into variations of other languages either. --Adamant1 (talk) 03:03, 27 July 2024 (UTC)
  • The mention of "California English" is really an overstatement. The linked article is mainly about regional pronunciation variants in three different regions of California. About the only thing here that would be different in writing is that Californians commonly use "the" with a highway route number ("the 5" instead of "Interstate 5" or "I-5"). - Jmabel ! talk 17:02, 27 July 2024 (UTC)

  Take it or leave it. It was just the first example that came to mind. Of course I'm not a linguist. Nor am I saying the idea of local variations should be rejected purely (or even at all) because of California English. Or really anything else. I'm just pointing out that the idea that there is only two variations of English in existence, American and British, is overly simplistic. --Adamant1 (talk) 00:16, 28 July 2024 (UTC)

  Agree: "We should have to figure out which variation to go with every time ...".

  Not agree: "use American English as the standard", because British English is NOT only spoken in Britain; we in the Netherlands learn British English at school and I guess there are other countries where British English is teached. So it is not only the countries where English is the main language you have to take into account. JopkeB (talk) 04:09, 27 July 2024 (UTC)

  Likewise I do not agree with adopting any specific variant of English as standard, but instead I think the status quo is correct. So long as the term is mutually intelligible and accurately conveys the topic, it should not be changed just to align with one or the other variant. Whether it is gray or grey, any English speaker can easily understand what is being covered, even if they may smirk at what they consider a misspelling, so no real reason to go with one over the other, so long as what we go with is consistently used throughout Commons. I can only imagine the howls of protest if we start trying to rename everything to match UK, US, etc. spelling/vocabulary--probably only slightly less than the ruckus that will happen if every locality is fair game to argue about what local term is most common there. Josh (talk) 05:07, 27 July 2024 (UTC)

  I'm not neccessarily advocting for adopting any specific variant of English as a standard. But its juat a fact that American English is the standard due to how widely its used compared to other ones and universality. I'm sure there's edge cases where that's not the case though, which is fine. I don't think its something can realistically enforce one or another. Although adopting this clearly wouldn't be beneficial even if people are already using local variations without it. --Adamant1 (talk) 06:19, 27 July 2024 (UTC)

  @Adamant1: Can you prove that "its just a fact that American English is the standard ..."? How is it measured? JopkeB (talk) 04:53, 28 July 2024 (UTC)

  @JopkeB: I mentioned it below this, but from what I remember when I looked into it a year or two ago the top countries that contributors come from on here are the United States and Germany. German's usually (if not exclusively) speak American English. Regardless, it largely depends on the numbers from there, but if people from the United States and Germany make up the largest amount of total English speaking users on here then American English is just naturally going to be the standard. That's assuming my memory is correct and that nothing has changed about the user base since then. --Adamant1 (talk) 05:13, 28 July 2024 (UTC)

• Option B since some level of consistency is better than none. Laurel Lodged (talk) 07:36, 27 July 2024 (UTC)
• Option B Best of these options. One could at a later point think about machine translated category titles where the things are mostly addressed that way which is when option A & C become more reasonable. --Prototyperspective (talk) 10:13, 27 July 2024 (UTC)
• Option A because the discussion of "national variants" doesn't help the universality. Living in Europe and not being a native English speaker, I learned a British English and found this in most contacts on the continent. And if sbb1413 says that "Although gallery names can use local languages, the dialects of other languages (except Portuguese) don't really differ by spelling or vocabulary" it only shows a lack of knowledge about other languages. I speak a German dialect that is not normally written but even our written language has so many words that are different from the words used in Germany that misunderstandings are possible. Unless a really universal English can be defined, it is better to accept "regional varieties" and help users with good category trees. I would be happy to find the gray houses in the grey houses main category, rather than knowing I must search for gray (or v/v). We can only continue peacefully if the existing varieties of English are accepted and not one be declared universal. And I clearly contradict the above statement " British English is only spoken in Britain and a few former colonies". Please accept variety. It will help universality more than putting regional English varieties down. And watch the category trees!-- Gürbetaler (talk) 22:00, 27 July 2024 (UTC)

British English can be extended to a few other places besides former Crown Colonies. It still doesn't disprove my point that American English has vastly more usage then British English globally. Not like it matters though since know where have I said I think we should former with the later, or visa versa. Both can coexist depending on the situation perfectly fine. Although there's still the practical issue of universality which that is inconsistant with regardless. --Adamant1 (talk) 00:03, 28 July 2024 (UTC)

@Adamant1: do you have any basis for the claim that American English is far more widely used globally? Not particularly what I have observed. For example, educated people from India who speak English speak an English far more related to British English than American English, and I'd guess right there we are talking about a population in the hundred-million range. It is in some ways distinct, but in every way that British and American English differ from one another, it is more like the British. - Jmabel ! talk 01:38, 28 July 2024 (UTC)

@Jmabel: I don't remember the exact numbers but speaking purely in relation to Commons I think the top two countries contributors come from is Germany and the United States and I'm pretty sure they mainly (if not exclusively) speak American English in Germany. I don't remember where India is on that list, but it really doesn't matter how many people from India speak British English if they only make up like 5% of contributors to begin with. Outside of that this website has a map at the top showing the usage of both globally. Assuming it's accurate sure British English takes up more land mass globally but so what? Cool that British English is more popular in Siberia by land mass. Those people are either not on Commons to begin with or mainly (if not exclusively) create categories in Russian. I'd say look at what variation of English the people from like the top 5 countries (or top 1 or 2 depending on the numbers) for editors is on here and go with that. Otherwise I think your just losing the point in universality. --Adamant1 (talk) 02:27, 28 July 2024 (UTC)

I don't remember where India is on that list, but it really doesn't matter how many people from India speak British English if they only make up like 5% of contributors to begin with.

@Adamant1 Indians are 5% if you consider all the contributors. However, if you consider only the anglophone contributors, the percentage should be at double digits. Besides contributors, there are also significant viewers from India who watch our images via Wikipedia.

Assuming it's accurate sure British English takes up more land mass globally but so what? Cool that British English is more popular in Siberia by land mass. Those people are either not on Commons to begin with or mainly (if not exclusively) create categories in Russian.

I don't believe in this prejudice since I strongly believe in the "all men are created equal" principle. Besides, Serbians have their own language, which use both Latin and Cyrillic scripts. Sbb1413 (he) (talk • contribs • uploads) 05:23, 28 July 2024 (UTC)

there are also significant viewers from India who watch our images via Wikipedia. @Sbb1413: Sure, but from what I understand most viewers of media on Commons don't do it by way of categories. Let alone do they regularly interact with them in any meaningful way. So viewers don't really matter here.

I don't believe in this prejudice since I strongly believe in the "all men are created equal" I believe "all men are created equal" to, but not all men speak the same language and that's what we're talking about here. Not the inherent value of humans or whatever. To that end this Wikipedia article says that only 5% of people in Russia speak English to begin with. Change that to Siberia and the number of English speakers there is essentially non-exiting. The point being, you could take that map I linked to say British English must be the popular variation purely based on landmass, but then large areas of that land have almost no English speakers to begin with anyway. Like sure China is huge landmass and population wise, but conversely less then 1% of the population there speaks english to begin with. So the fact that British English is more popular then American in China is statistically and (more importantly) practically meaningless. --Adamant1 (talk) 05:38, 28 July 2024 (UTC)

@Adamant1: Do I understand you well: to decide what kind of English should be the standard, you only look at the contributors to Commons? Not to the whole world?

• If I understand the Commons scope well, the category structure we make is not only for contributors, but for everybody who wants to find media with educational content, like Wikipedians and people contributing to other Wikimedia projects, scholars, school children and business people (and many more) looking for illustrations for their papers and presentations, from all over the world. So our target group is much broader than just Commons contributors. And I think we should include and consider the whole world to decide what kind of English should be the standard on Commons.
• Categories do matter to viewers, because I think the search engine includes category names in search results (the Commons search engine as well as Google Image). And Wikidata is to make sure that spelling variants are included. And if not: I hope they do or going to do so.
• But I wonder whether we should want to have one variant of English as the standard at all on Commons. So: why is this part of the discussion even necessary? I like the current situation better in which we choose one variant per concept and use that variant throughout the category structure.

JopkeB (talk) 05:50, 28 July 2024 (UTC)

I think that's essentially my position. Like I said in the comment your responding to, less then 1% of people in China speaks English to begin with. Realistically the amount of people who view media from Commons is pretty low. Then if you consider people from China who use or interact with categories on a regular basis it's even lower then that. So I have no problem with considering the whole world to decide what kind of English should be the standard on Commons. That's literally what I'm doing here and the fact is that if you look at how many people actually speak English to begin with in places where British English is the predominant language it's to small to be meaningful.

That doesn't even account the percentage of computer users versus cell phone users globally either. 66% of the world's population has access to the internet, but then only 40% of that percentage use a computer and most people don't use or interact with folders on mobile. So I think we should be realistic about what we're actually talking about here. Instead of just acting like we should base this purely on inclusivity or whatever. There's nothing wrong with that, but there's no point in being inclusive when it comes to groups of people that clearly don't even exist on here in the first place. --Adamant1 (talk) 06:06, 28 July 2024 (UTC)

@Jmabel and Adamant1: Yes, India (largely) follows British English due to its colonial legacy. On one hand, I have seen some news media imposing British spellings in many organization names (like "Johnson Space Centre", "World Health Organisation"). On the other hand, I have seen some media using -ize and mdy format. The mdy format was introduced by the British, who formerly used it. The -ize spelling is either an instance of Americanization or is based on the OED spelling conventions. I generally use British English with OED and IUPAC spelling conventions except when naming Indian categories, where I would use hardline British spellings. Sbb1413 (he) (talk • contribs • uploads) 04:48, 28 July 2024 (UTC)

@Sbb1413: Interesting. Am I correct to assume it largely depends on the situation? Like I assume someone who works at a call center for a company in the United States would probably prefer American English. Otherwise they would use British. Or am I wrong about that? --Adamant1 (talk) 05:07, 28 July 2024 (UTC)

• JopkeB, I don't see this as such a big problem. We have not had much of a problem thus far with the setup of new categories. Subcategories can follow their parent or siblings as a precedent, those setting up specific new categories with a language distinction are likely to understand that. Or, we can fix anything that comes up later on. Explanation of categories can be done with header text and that easily supports multiple languages.

Where we have a problem is with renames. Particularly those deliberately enforcing language changes 'for consistency'. If we make it clear that we just don't do that then we should be good. This is especially the case for non-natives changing another language. If you don't have the knowledge, then don't edit it. Andy Dingley (talk) 20:32, 3 August 2024 (UTC)

---

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

New proposal

 Question How do we go on with this discussion? How can we close it? Because I see:

1. there is no consensus about the initial proposal by Sbb1413 with three/four options (including variant D = leave it as it is now, no alterations or/and additions to the Universality Principle).
2. someone started a discussion about one standard variant of English on Commons, without even posing the question whether we want such a thing; and there is no consensus about one pervailing variant of English either.

--JopkeB (talk) 06:30, 28 July 2024 (UTC)

@JopkeB It is a terrible decision, but there are several pros and cons of using different English variants:

• Consistent with local usage.
• Consistent with English Wikipedia category names.
• Inconsistent with the spirit of the Universality Principle.
• Problems identifying which variant is used in countries whose official/primary language is not English.
• Problems with navigation templates like {{Countries of the Americas}} and {{Topic by country}}.

Similarly, there are several pros and cons of using a single English variant for a specific topic:

• Consistent with the spirit of the Universality Principle.
• No problems with navigation templates like {{Countries of the Americas}} and {{Topic by country}}.
• No problems identifying which variant is used in countries whose official/primary language is not English.
• Inconsistent with local usage.
• Inconsistent with English Wikipedia category names.

This is why my proposal is to use English variants for countries whose official/primary language is English. Other countries will follow the English variant used in the main topic category. Note that the Commonwealth of Nations (excluding some members who use different variants) and the European Union are treated as single countries for the purpose of this proposal. Both organizations officially use British English, so there are possibilities that the members (except some Commonwealth members) would follow that variant. The Netherlands is a member of the EU, so it can freely use the British variant. Sbb1413 (he) (talk • contribs • uploads) 03:53, 2 August 2024 (UTC)

In fact, using multiple variant categories for one topic and single variant categories for another is a huge mess. In light of technical reasons, we can use a single English variant throughout a topic, with other variants as descriptions. For example, the description of Category:Organizations of the United Kingdom would be read as:

British English: Organisations of the United Kingdom

This is much better than renaming category names in consistent with the local English variant. Sbb1413 (he) (talk • contribs • uploads) 04:06, 2 August 2024 (UTC)

Also, in the domain of space exploration, the description of Category:Astronauts from Russia would be read as:

English: Russian cosmonauts

Similarly, Category:Astronauts from China would be read as:

English: Chinese astronauts, also known as taikonauts.

--Sbb1413 (he) (talk • contribs • uploads) 04:16, 2 August 2024 (UTC)

Thanks for the overview. I would like to add to "pros and cons of using a single English variant for a specific topic":

• Not only "No problems with navigation templates" but "No problems with navigation in general", for all users, no matter what English variant is preferred by the searcher, just because of the consistency throughout a topic.

 Support I think your latest addition might be the key for a solution: using a single English variant throughout a topic, with other variants as descriptions.

--JopkeB (talk) 04:28, 2 August 2024 (UTC)

@Crouch, Swale, Laurel Lodged, Prototyperspective, and Gürbetaler: Those who had supported my proposal, what do you think of my newer proposal of using single English variant throughout a topic, with other variants as descriptions? Sbb1413 (he) (talk • contribs • uploads) 05:02, 2 August 2024 (UTC)

More examples of ENGVAR descriptions are found at Category:Aluminium, Category:Apartment buildings, Category:Caesium, Category:Eggplant, Category:Sulfur etc. Sbb1413 (he) (talk • contribs • uploads) 05:50, 2 August 2024 (UTC)

I think it's also fine. The issue that there need to be machine translated category titles depending on the set uselang. For such short phrases the latest MT tech is nearly always accurate even for smaller languages and one could try this first with some of the best-working languages like Spanish. This may also allow many more people to find the WMC pages if the search the Web in their own language and indexing works well. Prototyperspective (talk) 10:43, 2 August 2024 (UTC)

The issue that there need to be machine translated category titles depending on the set uselang. For such short phrases the latest MT tech is nearly always accurate even for smaller languages and one could try this first with some of the best-working languages like Spanish. This may also allow many more people to find the WMC pages if the search the Web in their own language and indexing works well.

I don't understand how it is related to the ENGVAR issue in Commons. A machine translator can translate any English text to another language, regardless of variant. Sbb1413 (he) (talk • contribs • uploads) 11:31, 2 August 2024 (UTC)

I was just saying we're discussing the wrong thing basically, it doesn't matter which variant is used or if there is a standard naming because it can be easily machine translated. I support your proposal partly because the variant indeed doesn't matter and that's also why I don't care much about which of your proposals is implemented, it would be good to standardize/specify it and I think this translatability needs to be kept in mind when thinking about which option would be best and can also solve potential Cons like "people looking for the term in their own language may not find the category as well if another language variant is used". Prototyperspective (talk) 11:46, 2 August 2024 (UTC)

I've put this here, it's a bit tangential to this discussion: meta:Community Wishlist/Wishes/Add machine translated category titles on WMC. Prototyperspective (talk) 17:06, 4 August 2024 (UTC)

• This proposal seems to suggest the (apparently) current rule of the UP (which has been disputed). I can see the pros and cons but I'd slightly support following national variants. Crouch, Swale (talk) 14:27, 2 August 2024 (UTC)

  @Crouch, Swale As per my new proposal, the "topic by country" category names won't use the corresponding national variant, but the English descriptions may use national variants. Descriptions are easier to deal with compared to category names. Plus we don't have to add extra lines of code in navigation templates to deal with national variants. Currently, English Wikipedia don't use any such navigation templates, so it can happily follow ENGVAR in category names. So there will be no changes in the Universality Principle, apart from the text itself being modified to follow a consistent spelling norm. Sbb1413 (he) (talk • contribs • uploads) 14:46, 2 August 2024 (UTC)

  Thanks, I understand now but I still favour the national variants proposal. Crouch, Swale (talk) 14:47, 2 August 2024 (UTC)

  I understand your sentiments in favour of national variants. While the category names will follow a consistent variant throughout the topic, you can still add descriptions using national variants. There are already templates that can give descriptions in different national variants:

  • {{En-au}} for Australian English
  • {{En-ca}} for Canadian English
  • {{En-gb}} for British English
  • {{En-in}} for Indian English
  • {{En-us}} for American English

  Sbb1413 (he) (talk • contribs • uploads) 14:54, 2 August 2024 (UTC)

  I support User:Crouch, Swale. Gürbetaler (talk) 19:27, 3 August 2024 (UTC)

• An inherent problem with the "Universality principle" is that it seems to assume that there is some sort of "standard" terminology used everywhere. There is not. Whatever variety of English is used, there are occasional terms that are different in different countries or regions, to the point that if we try to impose some version globally it can be a term that is not only not used but is completely unfamiliar to millions of people. Uniformity is a worthy goal as a general rule, but refusing to acknowledge occasional exceptions can create problems greater than any potential superficial appearance of benefit. -- Infrogmation of New Orleans (talk) 21:33, 3 August 2024 (UTC)

  "Standard terminology" has at least two meanings:

  1. Terminology used as a standard within a (geographic or cultural) community. Example: spelling of English words in different parts of the world.
  2. Terminology used as a standard within a system. In a system it does not matter how words are spelled, as long as the same concept is spelled the same way throughout that system. You can even give them codes instead of real words (like in Wikidata), as long as you add good descriptions in languages that are understandable by people. For me the category structure in Commons is such a system. And though I was not involved at all in the creating process of the principles, I think the Universality Principle was established for this reason. In Commons this principle is at least necessary to have "No problems with navigation". but also for communicating with other systems and for technical solutions (like templates), current and future ones. I guess this is the reason why Sbb1413 proposed to (In light of technical reasons, we can) "use a single English variant throughout a topic, with other variants as descriptions", which I support.

  That "a term that is not only not used but is completely unfamiliar to millions of people" is not relevant in a system, it is only relevant within a community. I (not a native English speaker) consider myself as one of those millions people (should perhaps be "billions") and I do not mind having to look up English terms used in Commons on a daily basis. I do not see why it is a problem for native English speakers to look up a word only now and then. JopkeB (talk) 05:30, 4 August 2024 (UTC)

  Yes, organization on Commons has become massively more US/England English centric than I thought the intention was in the early months of the project. Even the use of standard Latin names for plants and animals, one of the few non-English standards initially agreed to at the start, is widely disregarded by native English speakers refusing to look up a word only now and then. -- 17:23, 5 August 2024 (UTC) — Preceding unsigned comment added by Infrogmation (talk • contribs) ‎ (UTC)

  @Infrogmation: , you are not correct. The Universality Principle does NOT assume any sort of 'standard' terminology used anywhere outside of Commons. It merely determines that a common terminology is to be used within Commons. Whatever term is used, it is known that it will be unfamiliar to not only millions, but billions of people, since there are at least 6 billion people who do not speak English. It does not matter whether we use universal terminology or localized terminology--either way most people will not have a native understanding of the term. The only question is whether users only have to familiarize themselves with a single term for a topic usable across all of Commons, or they have to learn multiple different terms for the same topic to be able to navigate across Commons. Josh (talk) 19:28, 9 August 2024 (UTC)

One of the fundamental problems I have with the localized system is that it presumes that the audience for a topic by region is only from that region and thus the name of the topic should be catered to that specific population. However, topics are there for all people to access, and the audience for every topic is global. For local audiences, 'trucks in Texas', 'lorries in England', and 'camiones en Mexico' all may be the more readily understood terminology for most people living in those regions, and if that were the only users these categories were intended for, I might agree with localized naming. However, they are not--they are intended to be accessible by all users regardless of where they live. Thus the UP was developed to promote access by all users to all content without prejudice. Josh (talk) 22:59, 9 August 2024 (UTC)

@Joshbaumgartner I have agreed to use a consistent English variety for a given topic, regardless of country. If we want to add national English variants in a country category, we can do so using specialized description templates (like {{En-gb}}, {{En-us}}). The plain {{En}} template can also assume the local dialect, like Category:Astronauts from the Soviet Union. Sbb1413 (he) (talk • contribs • uploads) 03:49, 10 August 2024 (UTC)

@Sbb1413 I agree 100% that language and language-variant specific descriptions are a great thing to add to any category. The best way is through WD, but for categories without {{Wikidata infobox}}, the templates you mentioned are very good to use. I support their use completely! Of course I would most love if we could fix category names so they were handled like WD labels, and everyone can search for and have displayed their language of choice as the category name, but that is a technical solution that we have failed to achieve in more than a decade, so I'm not holding my breath. Universality Principle is how we make do in the meantime. Josh (talk) 01:40, 11 August 2024 (UTC)

Now we'll wait for another two weeks for more inputs. After that, we can close this discussion and tackle with the categories potentially violating the Universality Principle. Sbb1413 (he) (talk • contribs • uploads) 18:15, 11 August 2024 (UTC)

The categories potentially violating the Universality Principle include the subnational categories of Category:Organizations, and the national and subnational categories of Category:Train stations. According to my proposal, they all should follow consistent naming throughout the topic, and descriptions should be added to those categories to indicate the local dialects. This will allow the category name "Train stations in West Bengal" with Indian English description "Railway stations in West Bengal". Sbb1413 (he) (talk • contribs • uploads) 18:20, 11 August 2024 (UTC)

I have also formally withdrawn my original proposal, since the proposal isn't feasible and it may go against the spirit of COM:LANG. --Sbb1413 (he) (talk • contribs • uploads) 18:27, 11 August 2024 (UTC)

@Sbb1413 I actually would like to see the multilingual descriptions (including multi-variant) on more than just the specific region. I think it is good that on a Mexican topic, there is a Latin American Spanish description available, but I'd frankly like to see Spanish descriptions on Mongolian topics too. That is why I like using WD as it does a good job of maintaining multi-lingual labels and descriptions and making them easy to deploy on pages. Of course, all of that requires doing by people familiar with the languages in question. I agree with implementing in organizations and train stations, though for large topics with a strong variety of terminology use throughout them, they may warrant a topic-specific CfD to determine which of the various terms really should be adopted by Commons as the topic name. Josh (talk) 19:10, 11 August 2024 (UTC)

@Joshbaumgartner, Infrogmation, and Prototyperspective: Since most users have agreed with my new proposal, it might be best to move on. It is not a policy change, but a mere suggestion to address the ENGVAR issues in Commons. So far, only Crouch, Swale has problems following this proposal, as they have wished that the category names should follow national variants, like in Wikipedia. But unlike Wikipedia, which focuses mostly on articles, Commons focuses mostly on categories and files. So following a consistent variant across the entire topic hierarchy makes sense, with descriptions in national variants. Laurel Lodged has made no comments regarding the new proposal, but supported the original proposal. Sbb1413 (he) (talk • contribs • uploads) 03:13, 13 August 2024 (UTC)

@Crouch, Swale and Laurel Lodged: Do you still support my original proposal of using English variants in category names? I believe my new proposal will address the issues of English variant issues with category names. TL;DR: my current proposal is to use description templates of different English variants instead of having category names of different variants. This is more in line with the Universality Principle, which is one of the actual policies of Commons categories. w:WP:C2C is applicable for English Wikipedia categories, since we don't have criteria for speedy renaming of categories. Commons categories and English Wikipedia categories are different in many aspects, despite sharing the same "Category" namespace. Sbb1413 (he) (talk • contribs • uploads) 10:00, 3 September 2024 (UTC)

Yes. Crouch, Swale (talk) 10:01, 3 September 2024 (UTC)

Yes. Laurel Lodged (talk) 16:50, 3 September 2024 (UTC)

@Sbb1413, after nominating Category:Organisations of Australia for renaming to use US spelling, I faced strong resistance and withdrawn my nomination. After reading this wall of text of a discussion, I am still confused. We have Category:Organizations of the United Kingdom which uses the US spelling and Australian one which uses the UK spelling, so I started another discussion. Is there a consensus on this matter? Deltaspace42 (talk) 18:00, 13 January 2026 (UTC)

When to {{Categorise}}?

Following this reversion correcting my misuse of {{Categorise}} I need help to interpret its ideal usage. Given that this template warns that «This is a main category requiring frequent diffusion and maybe maintenance. As many pictures and media files as possible should be moved into appropriate subcategories», how is it correct to use it to tag fairly obscure categories with very few elements (files and subcats) in them? -- Tuválkin ✉ ✇ 14:07, 18 August 2024 (UTC)

I'm not sure I agree with Verdy p here, but I see what he's after: its hard to imagine an image that legitimately belongs directly in that category. - Jmabel ! talk 16:50, 18 August 2024 (UTC)

There’s {{Catcat}} for that or {{Metacat}}, if warranted. Since the template explanation says «This is a main category» one thinks it is rather meant for those cats where thousands of files are dumped into every day, like Category:Paris, which need a brigade of editors dissiminating them around constantly. Not for something so obscure like Category:SI unit symbols (and the others where User:Verdy p has been adding {{Categorise}} to in recent weeks). -- Tuválkin ✉ ✇ 10:35, 20 August 2024 (UTC)

This is not just images but any medias and any relevant categories containing them. The "diffusion" criteria is important there, as well as its "permanence", not the criteria of "frequent" maintenance, which remains permanent, and this is what is really tracked there by the associated category. And this applies to "as many as possible" contents (which should be properly categorised (avoiding also double categorisation in a parent category when its more relevant and more precise child category is enough: this also avoids maintenance on media files as well to recategorize them and helps media uploaders). verdy_p (talk) 16:52, 18 August 2024 (UTC)

Oh, you have a reason for it, after all? You should have put it in the edit summary when I asked, several times, instead of just reverting. If your goal is to annoy me, then mission accomplished — although you have been doing so since 2005, across multiple online projects. Maybe avoid me, Philippe, instead of seeking my proximity as you did recently at {{Lettercombo}}. I find your whole demenour oddly disquieting and Commons should be large enough for us two not to bump elbows ever. -- Tuválkin ✉ ✇ 11:16, 20 August 2024 (UTC)

Exceptions to the Selectivity Principle

While the Selectivity Principle prevents us from creating categories that combine multiple topics, there are some cases where we should ignore this rule: Oceans vs. Seas, and Hills vs. Mountains. Although oceans and seas are distinct topics, there are many aspects that are equally applicable to both, so I had created Category:Oceans and seas for them. For hills vs. mountains, the distinction is mostly arbitrary and subjective (e.g. the elevations of Hills of Darjeeling district are similar to other Himalayan mountains), so I will create Category:Hills and mountains once there's a consensus for making exceptions to this principle. Sbb1413 (he) (talk • contribs • uploads) 16:23, 31 August 2024 (UTC)

Although the above reasoning may seem to go against COM:Intersectional categories, the topics mentioned are not really distinct. While oceans are extremely large compared to seas, they have many features common to both, like coasts (including sea beaches), marine biology, etc. On the other hand, although both hills and mountains are Slope landforms, we have also categorized Plains under this category, so Category:Slope landforms is not suitable to group hills and mountains. Category:Highlands is also not suitable, since it can cover multiple mountain ranges and plateaus, as opposed to individual mountains/hills. Sbb1413 (he) (talk • contribs • uploads) 16:31, 31 August 2024 (UTC)

So what would the exception exactly be? How would you describe it in general? JopkeB (talk) 03:43, 1 September 2024 (UTC)

I think the exception is where there is a quite clear concept, but English doesn't happen to have a single term. Sometimes we fudge this a different way: e.g. "rivers" categories often also include things too small to be properly considered a "river", and might more properly be called "rivers, creeks, and streams", but we just say "rivers" in the cat name. - Jmabel ! talk 15:35, 1 September 2024 (UTC)

@Jmabel: This is what I want to say. However, for the case of rivers, we already have Category:Watercourses, which can cover rivers, streams, creeks, and canals together. Sbb1413 (he) (talk • contribs • uploads) 15:39, 1 September 2024 (UTC)

And is an obscure word probably not known to even the average native-speaking college graduate, certainly not to the average native speaker without a "higher" education. (In fact, I just ran that by my girlfriend to see if she agreed, and it turned out that she didn't know the word herself!) - Jmabel ! talk 15:49, 1 September 2024 (UTC)

I'm not sure I agree with this. Oceans and seas have differences. For size, location, and depth. Although I agree its hardish to make that distinction on our end it still exists and is worth having two seperate categories for. I feel like this would lead to a lot of bickering and edit waring over what's a legitimate exception or not to. Its hard enough to have standards and consistancy on here as it is. That's not even getting into instances where there's more then two terms. Category:Streams, creeks, rivers, watercourses, and waterways would be totally ridiculous but also allowable by this. And sure, its a bit of strawman but there's clear line between a stream and a creek, or a creek and a river, or a watercourse or a waterway and all of them be both, none, some, Etc. Etc. So it really makes the whole thing not worth doing. If anything the Selectivity Principle should be made stronger, not weaker. --Adamant1 (talk) 10:16, 9 September 2024 (UTC)

@Adamant1 So what about the subcats of Category:Marine? They belong to both oceans and seas, if I'm not wrong. There are Category:Mountain roads along lower hills too, for example Ajodhya Pahar Pathway at Purulia.jpg. Streams, creeks, rivers, and waterways are all Category:Watercourses, so there's no need for a general category covering all of these. Sbb1413 (he) (talk • contribs • uploads) 10:27, 9 September 2024 (UTC)

I'm not sure what you mean by "they." Regardless, the whole thing seems kind of half backed and pointless. Per the description "This category is for things related to the sea." So how is that any different then Category:Seas? Then you have things like Category:Marine energy, which is a child of Category:Water power. Anyway the category contains sub-categories like Category:Tidal power and Category:Wave power. Why shouldn't those categories just be in Category:Water power though? What's specifically does either of those have to do with "marines" or whatever? Category:Marine structures, none of the categories in there have anything what-so-ever to do with "marines." So I guess my answer would be to up-merge and delete the subcats in Category:Marine as necessary and call it good.

There are Category:Mountain roads along lower hills too. Sure, "mountain roads" is kind of a colloquial term though. If it we're me I'd just stick to actual designations for roads and skip things like that completely. There's also backcountry roads. But so what? I don't think either one is a useful or clear way to organize things. Maybe this is a trick question, but where does a backcountry road end and a mountain road begin or visa versa (or for that matter even a country road)? --Adamant1 (talk) 10:59, 9 September 2024 (UTC)

I really want to remind people generally: unlike "instance" and "subclass" in Wikidata, categorization is not primarily about ontology. It is about helping people find things. As a general rule is good to avoid obscure words and very subtle distinctions. - Jmabel ! talk 04:15, 10 September 2024 (UTC)

@Jmabel That's a good point to keep in mind. The ontology of a topic is valuable to consider, but the ultimate goal is for users to be able to easily browse our contents and find images for use in other projects. Josh (talk) 13:02, 29 October 2024 (UTC)

"seek bar"

T.vanschaik recently added some text that refers to a "seek bar." As far as I know, that term has never before arisen in any Commons documentation, and I don't know what it means in this context. Admittedly, I don't use the Upload Wizard (which is the context in which it is named) but I'm guessing that if that were the correct name for some element of the wizard it would appear somewhere in some prior Commons documentation. - Jmabel ! talk 02:45, 1 November 2024 (UTC)

Thanks for noting my wrong translation. I am not a native speaker of English and I used the term to describe that part of the screen in which to write the expression one is looking for. Obviously it is not the correct term. I am looking forward to the right word. T.vanschaik (talk) 08:28, 1 November 2024 (UTC)

This relates to Special:Diff/951509399. Prototyperspective (talk) 11:18, 1 November 2024 (UTC)

Again, I don't use the Upload Wizard; possibly "search bar," which is a pretty common term? But if this is specific to categories, it might have a more specific name, like "category search bar," or I suppose it could be something else entirely. Anyway, whatever it is called elsewhere in the documentation is what we should call it here. - Jmabel ! talk 06:26, 2 November 2024 (UTC)

Well I didn't know one can enter category:search term into the search bar at the top right to jump to the category search directly. Probably that would be good to add somewhere here and elsewhere as it's handy to use this to jump directly to the category search. Prototyperspective (talk) 22:58, 2 November 2024 (UTC)