This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
"The category structure is the primary way to organize and find files on the Commons" - Wikidata's items can be such way (and not only on the Commons): example 1, example 2 (by "Current location", "Artist", "Title", etc)? --Fractaler (talk) 13:29, 19 February 2018 (UTC)[reply]
Yes. We have one part of the world model, hence the description of this part should be one, and not so, that according to one point this is so, for the second point it is so, for the third one somehow. Primary model said: "Ghent Altarpiece -> Religious paintings by Jan van Eyck;Renaissance panel paintings;Early Netherlandish paintings;Paintings in Sint-Baafskathedraal (Gent);Sept merveilles de Belgique;Visitor attractions in Ghent;15th-century paintings of Adam and Eve;15th-century religious paintings in Belgium;1432 paintings;15th-century paintings of Virgin Mary". Then Wikidata should say exactly the same: "Ghent Altarpiece -> Religious paintings by Jan van Eyck;Renaissance panel paintings;Early Netherlandish paintings;Paintings in Sint-Baafskathedraal (Gent);Sept merveilles de Belgique;Visitor attractions in Ghent;15th-century paintings of Adam and Eve;15th-century religious paintings in Belgium;1432 paintings;15th-century paintings of Virgin Mary". Ie, there must be a standard. One (1) standart, for all. Changed the model in the primary model (руку), the model automatically changed in the Wikidata. Fractaler (talk) 08:33, 20 February 2018 (UTC)[reply]
Now Category:Ghent Altarpiece has supercategories: Religious paintings by Jan van Eyck;Renaissance panel paintings;Early Netherlandish paintings;Paintings in Sint-Baafskathedraal (Gent);Sept merveilles de Belgique;Visitor attractions in Ghent;15th-century paintings of Adam and Eve;15th-century religious paintings in Belgium;1432 paintings;15th-century paintings of Virgin Mary. Wikidata does not have this. Ie, Wikidata has own "primary way to organize". Is it correct? Or commons way to organize is primary? Why does the Wikidata not repeat this primary way? --Fractaler (talk) 11:25, 20 February 2018 (UTC)[reply]
Wikidata and Wikimedia Commons are independent projects. This page is about how categories are used on Wikimedia Commons. How Wikidata is structured is a topic for another page (and another project). —LX (talk, contribs)11:56, 20 February 2018 (UTC)[reply]
My guess is, some day the Wikidata structure will become as important to Commons as the current category structure. That is when we should drop the word "primary" but it won't happen soon. Perhaps sometime in the 2020s. Probably even later, but we can wait several years to begin worrying. Jim.henderson (talk) 05:00, 22 February 2018 (UTC)[reply]
Wikipedia, Commons and Wikidata try to classify (to model) the same world/universe. Wikipedia can no longer be considered (emphasis only on human readability and the suppression there of machine-readableness makes Wikipedia uncompetitive). Commons has nothing but categories (galleries are local, not global classification, they are not considered), so it remains to classify using categories (eventually we get a graph like a tree). If the categories are considered as sets (set theory, "subset -> set -> superset"), then, for example, inductively-deductive methods, transitivity testing, etc. can be applied to them. Wikidata models with Q* (also allows to get a graph like a tree, by Template:Item documentation) and P*. P*-approvals (local, relative classification) can be replaced with Q*-approvals (global, absolute classification), so P* can be queued to Occam with his razor. Commons has the advantage of having machine-readable format about subcategories (subcategories do not need to be specially written, since they appear automatically). The tools of the Wikidata do not have such automation, we can not immediately know about subsets, elements of the set of the set in question (they are written manually). But with the help of the Wikidata tool for the classification of world/universe objects, the language barrier is removed: Wikidata uses the universal identifier of the world object (Q*), which is not tied to a specific language. In the same way as, for example, the language of music, mathematics, etc. Hence the conclusion: a project should appear that will combine both advantages: 1) the visibility of subcategories, 2) the global, standart, universal ID of objects that have the corresponding language labels (for use not only by machines, but also by humans). --Fractaler (talk) 08:16, 22 February 2018 (UTC)[reply]
What should the order of category names in a file be?
The question is, which order should the categories be in, if, for example, a photo contains multiple items. In this example file of backs of buses in Tallinn, Estonia, the categories are currently in this order at the bottom of the file.
As people start reading from left to right, the date/year/time and location categories first help establish context for people who are from outside Estonia, and then would move on to the details, as they keep on reading:
July 2007 in Estonia
2007 in Tallinn
Buses in Estonia photographed in 2007
Tallinna Autobussikoondis
TAK buses in green and white livery
Articulated buses in Estonia
Volvo buses in Estonia
Volvo B10MA
Aabenraa buses in Estonia
Buses built in 1984
1984 Volvo buses
Ajokki buses in Estonia
Ajokki City N
Buses built in 1985
1985 Volvo buses
Scania buses in Estonia
Scania CN113ALB
1990 Scania buses
There appears to be no exact policy with regard to the order in which categories are placed in a file. Some categories don't have much order, because they are added/moved with automated or semi-automated tools, which I have also made good use of.
Neither does policy define the order of category names in a file, but current instructions are shown in such way, that gives preference to main objects, but not the overall context, that I think should be discoverable first.
There is no preference to the order. Some people prefer a thematic structure, some prefer alphabetical. Others (the vast majority) just use the somewhat random order you get from the automated tools. You wouldn't have the "upper hand" over an IP, and that dispute should be handled like any other content dispute - through discussion and consensus building. If edit warring occurs, it might need admin intervention. But IMO its not worth fighting over.--Nilfanion (talk) 19:22, 5 April 2018 (UTC)[reply]
I agree that it generally isn't worth arguing as there isn't a paricular order. However, I don't think that it doesn't matter at all since readers actually do use categories to browse similar images, categories aren't used only for queries and such. Generally, key feature of an image is its subject (what it depicts), at least on a project like Commons, where images are supposed to have educational value rather than artistic value, and as per this page this is the first priority when choosing categories for an image. This allows an assumption that readers are also most interested in subject when they are looking for similar images, and these categories should be the easiest to find, somewhere at the top or at least in the first half of the list of categories. So, if particular user systematically puts most important categories at the latter part of long category lists, like here, and also fills first half with categories like "date in some location" that didn't even exist until recently (probably because they are least useful), then this really doesn't seem constructive.
I don't quite get it what do "details" mean above, or if there is something that could be considered a non-detail if the main subject is considered a "detail". There also seems to be some confusion about the purpose of categories if someone tries to use them to "establish context", rather than simply tying similar images. I doubt if any reader would work out that category list is place where context lies. Generally, description is used for this purpose. If anything, and if description is insufficent, then categories may occasionally reveal what the subject is. 90.191.81.6509:26, 7 April 2018 (UTC)[reply]
"about the purpose of categories": can categories have a purpose? A person can have a goal and uses tools (such as, for example, taxonomy) to achieve his goals. machine-readable data (in this case) means that the reader can get any order of categories that he needs: alphabetically, by the date of adding categories, by the number of supercategories of supercategories, by the length of the name, in order according to some user, by the least path to the root, etc. Ie, wars for the order in which the categories should go, become meaningless. --Fractaler (talk) 12:59, 7 April 2018 (UTC)[reply]
Well, we categorize images rather than leave them uncategorized. Why so, I'd say, is the purpose of categories. This page, to some extent, covers the purpose too. As said, I understand categories can be used for queries and other stuff that relates to machine-readabilty, but people also make use of category list at the footer of file page. This list to date is fixed to order given in syntax of given page. That said, even though we generally don't expect certain order in this list, and we necessarily can't avoid random order, then we still can avoid notably peculiar order introduced by particular user.
So far, there are aspects of browsing the site which often make users add categories in order which isn't entirely random, they find some order more useful than other. So category order isn't meaningless, and I find it inevitable that category order should be discussed sometimes, hopefully rather seldom than often, but still. Though, I concur, category order should become meaningless. Hopefully it becomes more so when structured data comes to Commons. So that perhaps certain categorizing schemes could be dropped, especially everything related to dates which combined into categories is technically just silly. 90.191.81.6514:05, 7 April 2018 (UTC)[reply]
"Hopefully it becomes more so when structured data comes to Commons": yes, and it looks like everything is coming to this. --Fractaler (talk) 17:09, 7 April 2018 (UTC)[reply]
Whatever is most useful to the reader. So place those at the front which the reader of this object might wish to navigate to. Either because they're an eponymous category and this is a gallery page, Wikipedia lead article or similar. Or else those which are primary defining categories for the object. The categories of "Tuesdays in Bohemia" and "Taken with a camera phone" should be low down, if present at all. Andy Dingley (talk) 16:30, 7 April 2018 (UTC)[reply]
This meta category has amassed 77,326 subcategories and needs diffusion. Part of the problem is that for quite some time there have been several subcategories in Category:Aircraft by registration by type following the scheme of "Boeing 747 by registration" and the like, but people still keep adding both Category:Aircraft by registration and "Category:<Aircraft type> by registration" to the main categories where individual aircraft by registration are gathered. E.g. Category:EC-MLD (aircraft) is categorised both in "Category:Aircraft by registration" and "Category:Airbus A321 by registration". Contrary to COM:OVERCAT this seems to be the rule at aircraft categories rather than the exception. I am presenting this issue here because Ardfern suggested that it be discussed with Commons:WikiProject Aviation only. However, I don't think that local consensus can trump a Commons-wide policy, so exceptions need to be approved here. De728631 (talk) 16:45, 2 April 2018 (UTC)[reply]
Why does a function (set) with 2 parameters - "Aircraft (by registration, by type)" have a superfunction (superset) with 1 parameter - "Aircraft (by registration)"?
That is how Wikimedia categories work. We define more specific categories the further we go down the category tree, and that means that more parameters come into play while the definition set out in a simple top category still remains valid for all elements further down the hierarchy. "Aircraft by registration" is for images where just the registration number is known. "Aircraft by registration by type" is a container for aircraft categories where the registration and the type is known, and "Category:Kawasaki C-1 by registration" and the like would be the next level. The problem, however, is that subcategories should only be part of one category level further up the direct line, and not be sorted into two related parent categories. De728631 (talk) 21:07, 3 April 2018 (UTC)[reply]
First, what is a "category tree"? If it is a taxonomy , then we have: ROOT <- 1) SUBROOT1 (by A); 2) SUBROOT2 (by B); 3) SUBROOT3 (by A, by B). Examples: "Aircraft by parameters" <- 1) "Aircraft by registration"; 2) "Aircraft by type"; 3) "Aircraft by registration by type" --Fractaler (talk) 08:28, 4 April 2018 (UTC)[reply]
Don't place an item into a category and its parent. For example, a black and white photo of the Eiffel Tower should be placed in Black and white photographs of the Eiffel Tower. It should not be placed in both that category and the Paris category at the same time.
Maybe I didn't make it clear enough when I started this discussion, but my main concern is not so much the way we may want to diffuse this category in the future but a massive case of overcategorisation right now. Contrary to the Commons policy on categories, there are probably hundreds of subcategories that are placed into a category and its parent. So my approach is to remove all those subcategories from Category:Aircraft by registration that have already been sorted into a category "by registration by type". This is the commonly accepted standard to solve the issue, but it has been challenged in this case and needs discussion. De728631 (talk) 09:50, 4 April 2018 (UTC)[reply]
Category:Aircraft by registration, however, may very well contain registration categories like "Category:D-ECAB" if the aircraft type is unknown. Once the type becomes known, the registration category should be placed into "<Aircraft type> by registration" instead. De728631 (talk) 12:15, 4 April 2018 (UTC)[reply]
I'm going to ignore the application of set theory above (IMO it isn't an appropriate model for Commons), as abstract theory is unlikely to be informative to a specific problem.
I will stick to practical concerns. Say I have a photo of the plane with registration G-BOAC. I don't have a clue what sort of plane that is, but if I create its category I can place it in Category:Aircraft by registration based on what I do know. Alternatively, imagine I am seeking images of G-BOAC. I know its registration, so its reasonable to use Category:Aircraft by registration to try to locate it. If its directly in that category, I can find it. If its buried in a "by type" subcategory I cannot find it, as I do not have that information. In both cases, having the individual plane's category in Category:Aircraft by registration is helpful. Removing it from that category is harmful.
To put this a different way, "I want a plane with registration G-BOAC" is not sensibly narrowed down by instead saying "I want a Concorde with registration G-BOAC". In contrast "I want a Concorde" is sensibly refined with "I want a Concorde with registration G-BOAC". That suggests Category:Aircraft by registration by type should be a subcat of "by type" but not "by registration".--Nilfanion (talk) 20:39, 4 April 2018 (UTC)[reply]
If you're looking for a specific category G-BOAC, your first start should be the search field anyway. It will guide you directly to the desired category without you having to browse the category tree. It is the fastest solution for "I want a plane with registration G-BOAC", so a direct entry in Category:Aircraft by registration is therefore not even necessary. Also, Category:Aircraft by registration by type includes the "registration" element, so the question would still arise why it is not linked back to Category:Aircraft by registration. Per our category policy, "each category should itself be in more general categories, forming a hierarchical structure." The hierarchical structure would be broken if Category:Aircraft by registration was not involved. Pinging @Joshbaumgartner: who created "by registration by type" as he might want to comment here too. De728631 (talk) 23:24, 4 April 2018 (UTC)[reply]
PS: What I'm trying to demonstrate is that navigation in the category realm works both ways, not just top-down. So if I want to browse back from G-BOAC via "Concorde by registration" and further up the tree, I should be able to arrive at "Aircraft by registration" as well. De728631 (talk) 23:31, 4 April 2018 (UTC)[reply]
With bottom-up navigation, you can get to Aircraft by registration by some obvious logical route, no matter how its categorised. That is not true for top-down navigation unless it is directly in by registration. Breaking registrations down by type is simply NOT helpful for navigation. Outright deletion of by registration by type is preferable to have it messing up the utility of the by regisration category.--Nilfanion (talk) 16:39, 5 April 2018 (UTC)[reply]
Now you are contradicting yourself. A few paragraphs further up, you suggested that "Category:Aircraft by registration by type should be a subcat of 'by type'" rather than by registration while you are now outright opposed to "Breaking registrations down by type"? De728631 (talk) 18:30, 5 April 2018 (UTC)[reply]
Uhh.. '"by registration by type" should be a subcat of "by type" rather than "by registration"' is consistent with 'don't break registrations down by type'? The latter statement is stronger, but doesn't contradict the former. If you already know the registration, adding in the type of aircraft doesn't narrow things down further, you already have a unique plane. (As an aside, to me "aircraft type" implies things like "helicopter" or "wide-body airliner" not "Boeing 777"). What benefit is there to any user in removing categories like Category:G-BOAC (aircraft) from Category:Aircraft by registration? IMO the only logical subcats for aircraft by registration are for the countries of registration. That would link all G registered planes together, and would allow G-BOAC to have a sortkey starting with B instead of G - making it slightly easier to find in the still huge list.--Nilfanion (talk) 19:16, 5 April 2018 (UTC)[reply]
We do have country-specific categories. Category:Aircraft registered in the United Kingdom is a parent for all G- registration categories, and there are lots of other such categories for more or less any registration prefix. And "type" is the official ICAO designation for what may otherwise be called an aircraft model. Using "model" for general aircraft categories is problematic though, because it should only be used for categories of scale models. Hence the "by type" wording of the subcategories that was rightfully introduced by Uli Elch. De728631 (talk) 19:47, 5 April 2018 (UTC)[reply]
And those are the only ones that logically belong under by registration. As they are aspects of aircraft registration, not an otherwise unrelated aspect of aircraft.--Nilfanion (talk) 20:06, 5 April 2018 (UTC)[reply]
Are you sure?
Aircraft by registration
`-- Aircraft registered in the United Kingdom
`-- Aircraft registered in France
`---G-BOAC
`---F-IBEX
That way you would empty "Aircraft by registration" of all registration categories, because per COM:OVERCAT they would have to be sorted into the relevant country-specific subcategories, leaving you again with no direct search options. At the moment, "Aircraft by registration" and "Aircraft by registration country" are at the same level in Category:Aircraft registrations and that is a good structure. De728631 (talk) 20:37, 5 April 2018 (UTC)[reply]
And I agree with that structure. My point there is if we don't want to merge those two related concepts (the registration code and the registration country), why would we want to link two entirely unrelated categories?--Nilfanion (talk) 21:23, 5 April 2018 (UTC)[reply]
Specific as in actually discussing the particular concern raised. Not discussing general points which could equally apply to any category. The application of set theory to Commons categories is the problematic case. Its based on the assumption that subategories must be subsets. That's clearly not true in many cases.--Nilfanion (talk) 19:16, 5 April 2018 (UTC)[reply]
Erm, if a subcategory is not a subset of its parent categories, where is the navigational benefit? Categories in a category tree shall "reflect a hierarchy of concepts, from the most generic one down to the very specific". De728631 (talk) 19:47, 5 April 2018 (UTC)[reply]
See this discussion. The navigational benefit is from linking two related concepts, but that relationship is not necessarily that between a set and its subset. The photos of a building in a city are a subset of the photos of the city. The photos of a building built by an architect are not a subset of the photos of the architect.--Nilfanion (talk) 20:06, 5 April 2018 (UTC)[reply]
"See this discussion." TLDR, and too much set theory. Still, there is a relationship between the architect and his buildings, so the photos of buildings are a subset of images related to the architect. De728631 (talk) 20:37, 5 April 2018 (UTC)[reply]
The short version is that the real issues start to appear at the 2nd order. The building could easily be a subcat of an entirely different city (the birthplace of the architect). That relationship is tenuous, but the two steps to get there are perfectly valid. Its conceivable that someone would place a photo of the building directly in the architect's category; its implausible that they would place it in their birthplace's category. That relationship is clearly not a strict subset-of-subset relationship, in contrast to building-city-country which would be.--Nilfanion (talk) 21:23, 5 April 2018 (UTC)[reply]
We should retain current use of Category:Aircraft by registration. It is an index of all aircraft registrations, regardless of further sub-categorization that can occur. Sub-categorization can be done by type, by country of registration, or by any number of other criteria. It is best if a registration is accurately categorized by all relevant methods, not just one. However, none of that changes the fact that it is both valuable and without harm to have an index that retains a link to all registrations. Since it does no harm and provides value, the current structure and method of using Category:Aircraft by registration should be retained. Josh (talk) 21:33, 8 April 2018 (UTC)[reply]
This meta category has amassed 77,326 subcategories and needs diffusion. Part of the problem is that for quite some time there have been several subcategories in Category:Aircraft by registration by type following the scheme of "Boeing 747 by registration" and the like, but people still keep adding both Category:Aircraft by registration and "Category:<Aircraft type> by registration" to the main categories where individual aircraft by registration are gathered. E.g. Category:EC-MLD (aircraft) is categorised both in "Category:Aircraft by registration" and "Category:Airbus A321 by registration". Contrary to COM:OVERCAT this seems to be the rule at aircraft categories rather than the exception. I am presenting this issue here because Ardfern suggested that it be discussed with Commons:WikiProject Aviation only. However, I don't think that local consensus can trump a Commons-wide policy, so exceptions need to be approved here. De728631 (talk) 16:45, 2 April 2018 (UTC)[reply]
Why does a function (set) with 2 parameters - "Aircraft (by registration, by type)" have a superfunction (superset) with 1 parameter - "Aircraft (by registration)"?
That is how Wikimedia categories work. We define more specific categories the further we go down the category tree, and that means that more parameters come into play while the definition set out in a simple top category still remains valid for all elements further down the hierarchy. "Aircraft by registration" is for images where just the registration number is known. "Aircraft by registration by type" is a container for aircraft categories where the registration and the type is known, and "Category:Kawasaki C-1 by registration" and the like would be the next level. The problem, however, is that subcategories should only be part of one category level further up the direct line, and not be sorted into two related parent categories. De728631 (talk) 21:07, 3 April 2018 (UTC)[reply]
First, what is a "category tree"? If it is a taxonomy , then we have: ROOT <- 1) SUBROOT1 (by A); 2) SUBROOT2 (by B); 3) SUBROOT3 (by A, by B). Examples: "Aircraft by parameters" <- 1) "Aircraft by registration"; 2) "Aircraft by type"; 3) "Aircraft by registration by type" --Fractaler (talk) 08:28, 4 April 2018 (UTC)[reply]
Don't place an item into a category and its parent. For example, a black and white photo of the Eiffel Tower should be placed in Black and white photographs of the Eiffel Tower. It should not be placed in both that category and the Paris category at the same time.
Maybe I didn't make it clear enough when I started this discussion, but my main concern is not so much the way we may want to diffuse this category in the future but a massive case of overcategorisation right now. Contrary to the Commons policy on categories, there are probably hundreds of subcategories that are placed into a category and its parent. So my approach is to remove all those subcategories from Category:Aircraft by registration that have already been sorted into a category "by registration by type". This is the commonly accepted standard to solve the issue, but it has been challenged in this case and needs discussion. De728631 (talk) 09:50, 4 April 2018 (UTC)[reply]
Category:Aircraft by registration, however, may very well contain registration categories like "Category:D-ECAB" if the aircraft type is unknown. Once the type becomes known, the registration category should be placed into "<Aircraft type> by registration" instead. De728631 (talk) 12:15, 4 April 2018 (UTC)[reply]
I'm going to ignore the application of set theory above (IMO it isn't an appropriate model for Commons), as abstract theory is unlikely to be informative to a specific problem.
I will stick to practical concerns. Say I have a photo of the plane with registration G-BOAC. I don't have a clue what sort of plane that is, but if I create its category I can place it in Category:Aircraft by registration based on what I do know. Alternatively, imagine I am seeking images of G-BOAC. I know its registration, so its reasonable to use Category:Aircraft by registration to try to locate it. If its directly in that category, I can find it. If its buried in a "by type" subcategory I cannot find it, as I do not have that information. In both cases, having the individual plane's category in Category:Aircraft by registration is helpful. Removing it from that category is harmful.
To put this a different way, "I want a plane with registration G-BOAC" is not sensibly narrowed down by instead saying "I want a Concorde with registration G-BOAC". In contrast "I want a Concorde" is sensibly refined with "I want a Concorde with registration G-BOAC". That suggests Category:Aircraft by registration by type should be a subcat of "by type" but not "by registration".--Nilfanion (talk) 20:39, 4 April 2018 (UTC)[reply]
If you're looking for a specific category G-BOAC, your first start should be the search field anyway. It will guide you directly to the desired category without you having to browse the category tree. It is the fastest solution for "I want a plane with registration G-BOAC", so a direct entry in Category:Aircraft by registration is therefore not even necessary. Also, Category:Aircraft by registration by type includes the "registration" element, so the question would still arise why it is not linked back to Category:Aircraft by registration. Per our category policy, "each category should itself be in more general categories, forming a hierarchical structure." The hierarchical structure would be broken if Category:Aircraft by registration was not involved. Pinging @Joshbaumgartner: who created "by registration by type" as he might want to comment here too. De728631 (talk) 23:24, 4 April 2018 (UTC)[reply]
PS: What I'm trying to demonstrate is that navigation in the category realm works both ways, not just top-down. So if I want to browse back from G-BOAC via "Concorde by registration" and further up the tree, I should be able to arrive at "Aircraft by registration" as well. De728631 (talk) 23:31, 4 April 2018 (UTC)[reply]
With bottom-up navigation, you can get to Aircraft by registration by some obvious logical route, no matter how its categorised. That is not true for top-down navigation unless it is directly in by registration. Breaking registrations down by type is simply NOT helpful for navigation. Outright deletion of by registration by type is preferable to have it messing up the utility of the by regisration category.--Nilfanion (talk) 16:39, 5 April 2018 (UTC)[reply]
Now you are contradicting yourself. A few paragraphs further up, you suggested that "Category:Aircraft by registration by type should be a subcat of 'by type'" rather than by registration while you are now outright opposed to "Breaking registrations down by type"? De728631 (talk) 18:30, 5 April 2018 (UTC)[reply]
Uhh.. '"by registration by type" should be a subcat of "by type" rather than "by registration"' is consistent with 'don't break registrations down by type'? The latter statement is stronger, but doesn't contradict the former. If you already know the registration, adding in the type of aircraft doesn't narrow things down further, you already have a unique plane. (As an aside, to me "aircraft type" implies things like "helicopter" or "wide-body airliner" not "Boeing 777"). What benefit is there to any user in removing categories like Category:G-BOAC (aircraft) from Category:Aircraft by registration? IMO the only logical subcats for aircraft by registration are for the countries of registration. That would link all G registered planes together, and would allow G-BOAC to have a sortkey starting with B instead of G - making it slightly easier to find in the still huge list.--Nilfanion (talk) 19:16, 5 April 2018 (UTC)[reply]
We do have country-specific categories. Category:Aircraft registered in the United Kingdom is a parent for all G- registration categories, and there are lots of other such categories for more or less any registration prefix. And "type" is the official ICAO designation for what may otherwise be called an aircraft model. Using "model" for general aircraft categories is problematic though, because it should only be used for categories of scale models. Hence the "by type" wording of the subcategories that was rightfully introduced by Uli Elch. De728631 (talk) 19:47, 5 April 2018 (UTC)[reply]
And those are the only ones that logically belong under by registration. As they are aspects of aircraft registration, not an otherwise unrelated aspect of aircraft.--Nilfanion (talk) 20:06, 5 April 2018 (UTC)[reply]
Are you sure?
Aircraft by registration
`-- Aircraft registered in the United Kingdom
`-- Aircraft registered in France
`---G-BOAC
`---F-IBEX
That way you would empty "Aircraft by registration" of all registration categories, because per COM:OVERCAT they would have to be sorted into the relevant country-specific subcategories, leaving you again with no direct search options. At the moment, "Aircraft by registration" and "Aircraft by registration country" are at the same level in Category:Aircraft registrations and that is a good structure. De728631 (talk) 20:37, 5 April 2018 (UTC)[reply]
And I agree with that structure. My point there is if we don't want to merge those two related concepts (the registration code and the registration country), why would we want to link two entirely unrelated categories?--Nilfanion (talk) 21:23, 5 April 2018 (UTC)[reply]
Specific as in actually discussing the particular concern raised. Not discussing general points which could equally apply to any category. The application of set theory to Commons categories is the problematic case. Its based on the assumption that subategories must be subsets. That's clearly not true in many cases.--Nilfanion (talk) 19:16, 5 April 2018 (UTC)[reply]
Erm, if a subcategory is not a subset of its parent categories, where is the navigational benefit? Categories in a category tree shall "reflect a hierarchy of concepts, from the most generic one down to the very specific". De728631 (talk) 19:47, 5 April 2018 (UTC)[reply]
See this discussion. The navigational benefit is from linking two related concepts, but that relationship is not necessarily that between a set and its subset. The photos of a building in a city are a subset of the photos of the city. The photos of a building built by an architect are not a subset of the photos of the architect.--Nilfanion (talk) 20:06, 5 April 2018 (UTC)[reply]
"See this discussion." TLDR, and too much set theory. Still, there is a relationship between the architect and his buildings, so the photos of buildings are a subset of images related to the architect. De728631 (talk) 20:37, 5 April 2018 (UTC)[reply]
The short version is that the real issues start to appear at the 2nd order. The building could easily be a subcat of an entirely different city (the birthplace of the architect). That relationship is tenuous, but the two steps to get there are perfectly valid. Its conceivable that someone would place a photo of the building directly in the architect's category; its implausible that they would place it in their birthplace's category. That relationship is clearly not a strict subset-of-subset relationship, in contrast to building-city-country which would be.--Nilfanion (talk) 21:23, 5 April 2018 (UTC)[reply]
We should retain current use of Category:Aircraft by registration. It is an index of all aircraft registrations, regardless of further sub-categorization that can occur. Sub-categorization can be done by type, by country of registration, or by any number of other criteria. It is best if a registration is accurately categorized by all relevant methods, not just one. However, none of that changes the fact that it is both valuable and without harm to have an index that retains a link to all registrations. Since it does no harm and provides value, the current structure and method of using Category:Aircraft by registration should be retained. Josh (talk) 21:33, 8 April 2018 (UTC)[reply]
There is no problem with having all single-aircraft registration categories in the main "Aircraft by registration" acting as a super-category. This is not uncommon practice. A standardisation of the "by type" subcategories is always a good thing, of course. — Huntster (t@c)19:25, 9 April 2018 (UTC)[reply]
There are some valid reasons to rethink exactly how Category:Aircraft registrations is structured. Never mind the hashing about whether or not a guideline is being obeyed or whether we are properly applying set theory, none of that is terribly valuable. The category does however beg some more clarity and streamlining. There are a couple issues which we can deal with in pieces, or as a whole. Josh (talk) 23:22, 9 April 2018 (UTC)[reply]
1 - xxxx (aircraft) categories are aircraft registrations, not aircraft. However, they are often treated as aircraft, especially since they say 'aircraft' parenthetically. This is not a problem for most common usage, but is exposed in corner cases and when analyzing the category structure. Keep in mind an aircraft may be assigned several registrations over its life, and some registrations may be assigned to different aircraft over time. Specific sub-categories of an aircraft registration category can be created to show its application to different aircraft (e.g. Category:N305FA (aircraft) into Category:N305FA (Boeing 737) and Category:N305FA (MD-83)). Proper names should be 'Aircraft registration N305FA' with sub-cats 'Aircraft registration N305FA assigned to Boeing 737 c/n 28662' and 'Aircraft registration N305FA assigned to MD-83 c/n 49398'. I am not proposing renaming these categories, unless someone is up for moving 75,000+ categories. The current abbreviated names are fine, but we should have a better description of what exactly those categories cover.
2 - Category:Aircraft by registration is named incorrectly. As noted above, the sub-cats are aircraft registrations, not aircraft, so the correct title should be Category:Aircraft registrations (flat list) or some other such appropriate title to indicate it is an index of all aircraft registrations ordered alpha-numerically. As it is, the current name adds to the confusion referred to in note 1 above. It may be appropriate to make this category a hidden cat while we are at it. Once this is done, sub and meta cats can be moved directly under Category:Aircraft registrations.
3 - Military identification numbers are not consistently treated. These are sometimes treated as aircraft registrations and other times as serial numbers or some other unrelated tree. Category:Aircraft registrations should cover all individual aircraft identifications assigned by authorities, military or civil. Sub-categorization can break down between assigning authorities for those that it is helpful for, but not all users will know what the issuing authority is for a particular identifier. No rename is needed, but a better description is required to make it clear what the category covers.
4 - Category:Aircraft by registration country is named incorrectly. As above, a more clear and concise name should be used, such as Category:Aircraft registrations by country of issue, to make it clear that the items within are aircraft registrations and that they are ordered by the country which issued the registration. It should be listed directly under Category:Aircraft registrations and not under Category:Aircraft by registration/Category:Aircraft registrations (flat list). Category:Aircraft by registration continent should get similar treatment, though 'continents' do not issue registrations, countries do.
Some tweaks like these would allow the continued use of aircraft registration categories essentially as they have been used for the 75,000+ registrations in place, while at the same time adding clarity and cleaning up the structure of the category quite a bit. They will hopefully go some way to satisfying concerns over COM:OVERCAT and the set theory issues raised by De728631 (talk·contribs) and Fractaler (talk·contribs). Josh (talk) 23:22, 9 April 2018 (UTC)[reply]
I don't think we need to differentiate between xxxx (aircraft) and xxxx (aircraft registration) and all subsequent namings. Apart from Category:Temporary aircraft registrations that are used for test and transfer flights, registrations are seldom changed over the life of an aircraft frame and the registration is therefore often synonymous with the single airframe it got assigned to. We already have Category:Re-used aircraft registrations and its appropriate sub-categories as you showed above.
@De728631: You are incorrect that registrations are seldom changed; it is common practice to change a commercial aircraft registration several times during its life, especially when it changes ownership. I would not advise eliminating the existing sub-categorization of xxxx (aircraft) into xxxx (specific aircraft) categories. Assuming synonymy between an aircraft and its registration is a mistake. As stated, I am not proposing that these categories be renamed, but merely that we have better definition of them as being specifically related to that aircraft registration. Josh (talk) 16:46, 10 April 2018 (UTC)[reply]
Well, you wrote "Category:Aircraft by registration is named incorrectly. ... the correct title should be Category:Aircraft registrations (flat list) or some other such appropriate title", or "Category:Aircraft by registration by manufacturer and type are incorrect. They should be renamed Category:Aircraft registrations by aircraft assigned". Isn't that renaming? Apart from Category:Aircraft registrations (flat list), I think this is unnecessary, and imho Category:Aircraft registrations by aircraft assigned would be outright confusing. Btw, you created the two latter categories (by registration by manufacturer / by registration by type [model]) last year, so how come you changed your mind now? As I see it, the focus is already on the registration numbers now – even with names like "xxxx (aircraft)". If it's really that common for commercial registrations to be changed, Category:Re-used aircraft registrations with xxxx (specific aircraft) subcategories should become more populated though. Different aircraft should not be lumped into a single registration category. De728631 (talk)
My apologies for not being clear. I don't propose changing the xxxx (aircraft) naming scheme. I do however, think that the meta cats they are in should be renamed per my suggestions above. You are right that some of them are ones I created myself under flawed names. I named them as I did in order to keep with the naming of Category:Aircraft by registration, but I wasn't thrilled by it at the time, and I am even less so now. I'm not sure what you are concerned about with lumping. As it stands now, if a registration is applied to multiple aircraft (which is less common than one aircraft having multiple registrations), then it should be broken down (see Category:N305FA (aircraft)). The main registration category should be also categorized in Category:Re-used aircraft registrations. That is current practice, and I don't think anyone is suggesting changing it. Josh (talk) 21:19, 10 April 2018 (UTC)[reply]
Military ID numbers are a problem though. Apparently there are in fact two major approaches among the armed forces of how to apply such registrations, namely using an aircraft's generic serial number (e.g. US Air Force, Italy) or issuing an unrelated ID (Germany, UK, Netherlands, etc.) Sometimes like in Italy or Spain, there are even two parallel schemes of markings on a single aircraft, such as an internal squadron ID (e.g. 41-12) and a permanent serial number. This has already led to inconsistent category schemes as in Category:Military aircraft registered in Spain or Category:Military aircraft registered in Italy (see the MM##### serials). So these need some consistency. De728631 (talk) 09:54, 10 April 2018 (UTC)[reply]
The US is no different than Germany or the UK: none use a 'generic' serial number, but instead assign their own numbers per whatever system they have established at the time. Some of these systems adopt the serials already assigned by other agencies or the manufacturer, but again, the sytems are set by each individual issuing authority. What is fundamentally different are identifiers that are assigned for the service life of an aircraft (such as the US Navy's BuNo) vs. those that are assigned to indicate organizational assignment and may be changed throughout its service life (such as the US Navy's tactical codes). However, in all cases, just as with civil registrations, the categories are for the identifier, not the airframe, and thus they should all be handled within the same consistent structure regardless of local differences in how such numbers are devised. Josh (talk) 16:46, 10 April 2018 (UTC)[reply]
Thanks for clarifying the service-life ID vs tactical code schemes. It is essentially what I tried to write above but maybe it didn't come through. I agree that in the future we should not use any tactical codes for "registration" categories but stick to BuNos, serials and other such official "top-level" IDs. Where applicable, we should redirect existing "tactical" categories to categories with the official registration number, e.g. Category:43-28 (aircraft) → Category:UD.13-28 (aircraft). De728631 (talk) 20:48, 10 April 2018 (UTC)[reply]
I totally agree with you that the 'tactical codes' and the like should not be necessarily considered aircraft registrations, while 'serial numbers' like BuNos, etc. should be under aircraft registrations. I also agree that it is curently not consistent and has been hard to know exactly how to proceed with those kinds of categories. We can have 'tactical code' categories, but they should be kept in their own category. The difficulty will be that many users may not be aware of the differences. Josh (talk) 21:19, 10 April 2018 (UTC)[reply]
For 'tactical codes' I assume you mean Squadron Codes and yes users may not be aware of the differences. Even aircraft enthusiasts get it wrong. A Chilean aircraft at the Farnborough Airshow was widely quoted in reports as having a serial which later turned out to be a squadron code. Seperate categories for these could be useful? eg Aircraft of 32 Squatron for example. SkymasterUK (talk) 10:06, 13 June 2018 (UTC)[reply]
Now on the page Category:B-6140 (aircraft) we can see such static information: Airbus A380-841, cn/serial number: 120, *China Southern Airlines 2013 to date as B-6140. No "is an 'aircraft registration'" on the page. And the pages from the examples have definitions on their pages ("China Southern Airlines is an airline based in Guangzhou in the Guangdong province of the People's Republic of China (PRC)", etc.). --Fractaler (talk) 06:26, 12 April 2018 (UTC)[reply]
Or, for example, Wikidata's definitions:
Categories/Archive 4
<nowiki>matrícula de aeronaves; 飛機註冊編號; lajstromjel; matrícula de l'aeronau; Luftfahrzeugkennzeichen; فهرست پیشوندهای ثبتی هواپیما; 航空器註冊編號; Nationale kendingsbogstaver; ہوائی جہاز رجسٹریشن; 機体記号; Luftfartygsregister; רישום כלי טיס; 航空器註冊編號; Ilma-alusrekisteri; registra numero de aviadilo; imatrikulace; registracija zrakoplova; marche d'immatricolazione; আকাশযান নিবন্ধীকরণ; immatriculation des aéronefs; registracija zrakoplova; לופטמאשין רעגיסטראציע; prefixo aeronáutico; Prefixo aeronáutico; Luftfohrtüüchkennteken; регистрација ваздухоплова; Registracija zrakoplova; 항공기 등록부호; orlaivių registracija; 航空器註冊編號; registrasi pesawat; międzynarodowy kod samolotowy; nasjonale kjennetegn på fly; vliegtuigregistratienummer; ہوائی جہاز رجسٹریشن; регистрация воздушных судов; Самолетазул хъвай-хъвагӀай; Uçak tescili; aircraft registration; تسجيل طائرة; 航空器注册编号; реєстрація повітряних суден; serie alfanumérica que distingue a una aeronave; 航空機の機体ごとに割り当てられている記号及び番号; egy repülőgépet azonosító, betűkből és számokból álló jel; registersystem för civila luftfartyg; międzynarodowy system znakowania statków powietrznych; individuelt registreringsnummer for fly og andre registreringspliktige luftfartøy; registratie waaronder het vliegtuig bekend is bij de nationale autoriteit; קאד וואס אידענטיפיצירט א לופטמאשין; Code, der ein Luftfahrzeug eindeutig identifiziert; জাতীয় বিমান কর্তৃপক্ষ কর্তৃক একটি পৃথক বিমানের জন্য নির্ধারিত নিবন্ধীকরণ এবং শনাক্তকরণ; registration and identification assigned to an individual aircraft by national aviation authorities; matricola alfanumerica che identifica un aeromobile; registrační značka letadla přidělená příslušným úřadem; string alfanumerik pesawat terbang; código de matriculación de aeronaves OACI; código de registro de aeronaves; matrícula aeronáutica; matricula de aeronaves; codigo de matriculacion de aeronaves OACI; codigo de registro de aeronaves; matricula aeronautica; 機体登録記号; 機体登録番号; 登録記号; 機体登録; 機体番号; 機番; レジ; レジ番; Immatriculations aéronautiques; Immatriculations aéraunautiques; marche; codice velivolo; codice di registrazione degli aeromobili; matricola degli aeromobili; matricola aeromobili; marche di immatricolazione; marche aeromobile; matricola aeromobile; numero di coda; nomor pendaftaran pesawat; kod samolotowy; halenummer; Vliegtuigregistratie; Staartnummer; Бортовой номер самолета; Регистрационный номер воздушного судна; Регистрационный номер самолёта; Бортовой номер самолёта; 機尾編號; 機身編號; 飛機註冊編號; 飞机注册编号; 注册号; Flugzeugkennzeichen; Flugzeug-Kennung; Luftfahrzeugkennung; Flugzeugkennung; Flugzeugkennungen; Kennzeichen von Luftfahrzeugen; Flugleistungsklasse; Luftfahrzeug-Kennung; 항공기 등록번호; 항공기 등록기호; aircraft registration code; tail number; aircraft marks; registration marks; تسجيل طائره; تسجيل الطائرة; registrační značky letadel; imatrikulace letadla; registrační značka letadla; Internationale kendingsbogstaver</nowiki>
aircraft registration
registration and identification assigned to an individual aircraft by national aviation authorities
<nowiki>Airbus A380; Airbus A380; Airbus A380; Airbus A380; Airbus A380; Еърбъс А380; ایئربس اے380; ایئربس اے380; Airbus A380; Airbus A380; Аеробус A380; Airbus A380; 空中巴士A380; Airbus A380; Airbus A380; Airbus A380; Airbus A380; Airbus A380; Ербас А380; Airbus A380; Airbus A380; এয়ারবাস এ৩৮০; Airbus A380; Airbus A380; Airbus A380; 空中客车A380; ערבוס A380; एअरबस ए३८०; Airbus A380; Airbus A380; Airbus A380; Ербас А380; Airbus A380; Airbus A380; Airbus A380; Airbus A380; Airbus A380; Airbus A380; Airbus A380; 空中客车A380; Airbus A380; 空中巴士A380; ئێرباس ئەی٣٨٠; Airbus A380; إيرباص إيه 380; Airbus A380; Airbas A380; အဲယားဘတ်စ် A380; 空中巴士 A380; Airbus A380; એરબસ એ ૩૮૦; Airbus A380; Airbus A380; ایرباس آ-۳۸۰; Airbus A380; Airbus A380; Airbus A380; Airbus A380; Airbus A380; Airbus A380; Airbus A380; 空中客车A380; Airbus A380; Airbus A380; エアバスA380; Airbus A380; Airbus A380; Airbus A380; Airbus A380; Airbus A380; Airbus A380; Airbus A380; एयरबस ए३८०; 空中客车A380; Airbus A380; Airbus A380; Airbus A380; Airbus A380; ஏர்பஸ் ஏ380; Airbus A380; แอร์บัส เอ380; Airbus A380; එයාර් බස් A380; Airbus A380; Аэробус A380; ఎయిర్బస్ A380; 空中客车A380; 空中巴士A380; Airbus A380; Airbus A380; Erbas A380; Airbus A380; Airbus A380; Ербас А380; Airbus A380; Airbus A380; Airbus A380; Airbus A380; Airbus A380; Airbus A380; Airbus A380; എയർബസ് എ380; 空中巴士A380; Airbus A380; איירבוס A380; Airbus A380; Airbus A380; Airbus A380; 空中客车A380; Airbus A380; 에어버스 A380; avión quatrimotor de fuselaje ancho y doble piso, actualmente el avión de pasajeros más grande del mundo; breiðþota; Pesawat berbadan lebar, dua dek, empat enjin, kini merupakan pesawat penumpang terbesar di dunia; Wide-body, double-deck, four-engine aircraft, currently the largest passenger aircraft in the world; Широкофюзелажен, двупалубен, четиримоторен самолет, в момента най-големият пътнически самолет в света; avion de pasageri; ایئربس کا تیارکردہ دو منزلہ طیارہ; Fiaramanidina midadasika, avo roa heny, misy maotera efatra, amin'izao fotoana izao no fiaramanidina mpandeha lehibe indrindra eran-tany; dopravné lietadlo; двохпалубний широкофюзеляжний пасажирський літак, створений Airbus; 四发涡轮风扇大容积远程客机; Airbus에서 제작 한 더블 데크 항공기; Кең шанақты, екі палубалы, төрт қозғалтқышты ұшақ, қазіргі уақытта әлемдегі ең үлкен жолаушы ұшағы; největší dopravní letoun světa; Širokotrupni avion sa dva sprata sa četiri motora, trenutno najveći putnički avion na svetu; ওয়াইড-বডি, ডাবল-ডেক, চার ইঞ্জিনের বিমান, বর্তমানে বিশ্বের বৃহত্তম যাত্রীবাহী বিমান; plus gros avion civil du monde, produit par Airbus de 2007 à 2021; Wide-body, dobel-deck, pesawat papat mesin, saiki pesawat penumpang paling gedhe ing donya; Širokotrupni, dvopalubni, četveromotorni zrakoplov, trenutno najveći putnički zrakoplov na svijetu; वाइड-बॉडी, डबल-डेक, चार इंजिन असलेले विमान, सध्या जगातील सर्वात मोठे प्रवासी विमान आहे; Dòng máy bay thân rộng 2 tầng bốn động cơ do Airbus phát triển; Plata korpusa, divstāvu, četru dzinēju lidmašīna, šobrīd lielākā pasažieru lidmašīna pasaulē; dubbel-dek vliegtuig vervaardig deur Airbus; Широкотрупни, двоспратни, четворомоторни авион, тренутно највећи путнички авион на свету; Plèana le corp farsaing, deic dhùbailte, ceithir-einnsean, an-dràsta an itealan luchd-siubhail as motha san t-saoghal; Breet-Kierper, duebel-Deck, véier-Moteur Fliger, de Moment de gréisste Passagéierfliger vun der Welt; langdistanse passasjerfly; Geniş gövdəli, ikiqat göyərtəli, dörd mühərrikli təyyarə, hazırda dünyanın ən böyük sərnişin təyyarəsidir; wide-body, double-deck, four-engine aircraft, currently the largest passenger aircraft in the world; طائرة ذات طابقين تصنعها إيرباص; négyhajtóműves, széles törzsű, óriás utasszállító repülőgép; વાઈડ-બોડી, ડબલ-ડેક, ફોર એન્જિન એરક્રાફ્ટ, હાલમાં વિશ્વનું સૌથી મોટું પેસેન્જર એરક્રાફ્ટ; Gorputz zabaleko, solairu biko eta lau motorreko hegazkinak, gaur egun munduko bidaiarien hegazkin handiena; avión de doble puente fabricáu por Airbus; Двухпалубный пассажирский самолёт; Awyren pedwar injan corff llydan, dec dwbl, yr awyren fwyaf yn y byd i deithwyr ar hyn o bryd; بزرگترین هواپیمای مسافربری جهان; 四發動機中長程雙層客機; Wide-body, dobbeltdækket, firemotors fly, i øjeblikket det største passagerfly i verden; ფართო ტანის, ორსართულიანი, ოთხძრავიანი თვითმფრინავი, ამჟამად ყველაზე დიდი სამგზავრო თვითმფრინავია მსოფლიოში; エアバス製の総二階建て4発ジェット旅客機; מטוס נוסעים רחב-גוף דו-קומתי; Киң гәүдәле, ике катлы, дүрт двигательле самолет, хәзерге вакытта дөньядагы иң зур пассажир самолеты; वाइड-बॉडी, डबल-डेक, चार इंजन वाला विमान, वर्तमान में दुनिया का सबसे बड़ा यात्री विमान है; వైడ్-బాడీ, డబుల్ డెక్, ఫోర్-ఇంజిన్ ఎయిర్క్రాఫ్ట్, ప్రస్తుతం ప్రపంచంలోనే అతిపెద్ద ప్యాసింజర్ ఎయిర్క్రాఫ్ట్; maailman suurin matkustajalentokone; Wide-body, double-deck, four-engine aircraft, currently the largest passenger aircraft in the world; பரந்த உடல், இரட்டை அடுக்கு, நான்கு எஞ்சின் விமானம், தற்போது உலகின் மிகப்பெரிய பயணிகள் விமானம்; modello di aeromobile a doppio ponte; Laia kerega kahekorruseline neljamootoriline lennuk, hetkel suurim reisilennuk maailmas; 四发涡轮风扇大容积远程客机; පුළුල් ශරීර, ද්විත්ව තට්ටු, එන්ජින් හතරේ ගුවන් යානා, දැනට ලෝකයේ විශාලතම මගී ගුවන් යානය; Dünyanın en büyük yolcu uçağı; Corpus latum, duplex deck, quattuor machinae aircraft, nunc maxima viatoribus aircraft in mundo; aeronave quadrimotor a jato para transporte de passageiros; อากาศยานไอพ่นลำตัวกว้างสองชั้น; europeiskt fyrmotorigt jetflygplan för långdistansflygning; avion de linha civil fòrça gròs-portaire long-corrièr quadrireactor de doble pont produit per Airbus; Plataus korpuso, dviejų aukštų, keturių variklių lėktuvas, šiuo metu didžiausias keleivinis lėktuvas pasaulyje; Širokotrupno, dvonivojsko, štirimotorno letalo, trenutno največje potniško letalo na svetu; एयरबस द्वारा डबल-डेक विमानको निर्माण; passagiersvliegtuig; silnik Airbus'a A380Samolot pasażerski; pesawat dek ganda berbadan lebar; Ndege yenye mwili mpana, yenye sitaha, yenye injini nne, ambayo kwa sasa ni ndege kubwa zaidi ya abiria duniani; വൈഡ് ബോഡി, ഡബിൾ ഡെക്ക്, ഫോർ എഞ്ചിൻ എയർക്രാഫ്റ്റ്, നിലവിൽ ലോകത്തിലെ ഏറ്റവും വലിയ യാത്രാ വിമാനം; 搭載4台引擎的空中巴士巨無霸客機; vierstrahliges Großraumflugzeug; Авион со широк каросерија, двокатни, четири мотори, моментално најголемиот патнички авион во светот; Լայն թափքով, երկհարկանի, չորս շարժիչով ինքնաթիռ, ներկայումս աշխարհի ամենամեծ մարդատար ինքնաթիռը; Keng korpusli, ikki qavatli, to'rt dvigatelli samolyot, hozirgi vaqtda dunyodagi eng katta yo'lovchi samolyoti; avión de pasaxeiros; Өргөн биетэй, хоёр тавцантай, дөрвөн хөдөлгүүртэй онгоц нь одоогоор дэлхийн хамгийн том зорчигч тээврийн онгоц юм; τύπος αεροσκάφους της Airbus; avió civil fabricat per Airbus; A380; Airbus A3XX; A380; A380; A380; 空中巴士A380; 空客A380; A380; A380; A380; 空巴A380; 空巴巨無霸客機; A380; Airbus Jumbo Jet; A380 Jumbo Jet; ए३८०; Superjumbo; A380; A380; A380 Jumbo Jet; Airbus Jumbo Jet; A380 Jumbo Jet; A380; A٣٨٠; أيرباص ٣٨٠; إيرباص A٣٨٠; إيرباص آي ٣٨٠; إيرباص آي٣٨٠; إيرباص إيه ٣٨٠; إيرباص إيه٣٨٠; إيرباص ٣٨٠; إيه ٣٨٠; اير باص ايه-٣٨٠; ايرباص A٣٨٠; ايرباص ايه ٣٨٠; ايرباص٣٨٠; ايرباص ايه 380; إيرباص A380; إيرباص إيه380; ايرباص A380; إيرباص آي380; اير باص ايه-380; إيرباص 380; ايرباص380; أيرباص 380; A380; إيه 380; إيرباص آي 380; سوبر جامبو; Airbus A380 (dopravní letadlo); A380</nowiki>
Airbus A380
wide-body, double-deck, four-engine aircraft, currently the largest passenger aircraft in the world
Those infoboxes are well suited to gallery pages, but not so much for categories. Wikidata doesn't have items for individual aircraft registrations as far as I am aware. I just looked it up and there are no items with instance of: Q838849 (aircraft registration) Josh (talk) 21:17, 12 April 2018 (UTC)[reply]
Do you mean these items? About definition: in order to be able to display the definition (by version of WD, if there is no version of Commons) on a category page, I'm now trying to make a template {{DescriptionWD}} (using Module:Wikidata description). For example, "aircraft registration": registration and identification assigned to an individual aircraft by national aviation authorities --Fractaler (talk) 07:59, 13 April 2018 (UTC)[reply]
@De728631, Fractaler, Nilfanion, Auntof6, and Huntster:
Can we possibly close this out? There was a lot of discussion but not much in the way of specific proposals or consensus of said proposals. The OP (de728631) was correct that this category violates COM:OVERCAT when sub cats such as Category:Airbus A320 by registration are included. There is no reason it should, so I propose we fix this by simply restricting this category to actual categories which include the registration in their name (e.g. Category:B-6140 (aircraft)) and not other metacats and such. For the purposs of this category, the term 'registration' includes all officially assigned aircraft IDs, and thus includes civil aircraft registrations issued by national aviation authorities as well as military aircraft serial numbers assigned for the aircraft's service life. Is it possible that we can agree on this simple tweak to come into compliance with COM:OVERCAT and then tackle the other issues raised above in their own conversations? Josh (talk) 22:05, 22 August 2018 (UTC)[reply]
I've previously expressed my opinion that keeping this a super-category for all registrations is not an issue and is a reasonable exception (as with Category:Ships by name and others). There is the very real potential for a flat-list to be useful to end users. — Huntster (t@c)23:07, 22 August 2018 (UTC)[reply]
Yes, I think this should be a flat category containing all registrations. I understand the concerns about overcategorization, but I think categories containing all individual entries are useful. Maybe this cat should be renamed to indicate that it's a flat category. --Auntof6 (talk) 01:39, 23 August 2018 (UTC)[reply]
I think that would make sense. That way we'd have a cat with a subcat for each registration ID, and we could also have categories that group the IDs by whatever criteria are useful. --Auntof6 (talk) 10:04, 12 October 2018 (UTC)[reply]
I am interested in adding some text to this page (which is really confusing in a number of places!). At the bottom of the section with the heading "For more appropriate categorization" it currently reads, "This does not mean that an image only belongs in one category; it just means that images should not be in redundant or non-specific categories. For instance, an image of a Polar Bear being rescued from an iceberg by a helicopter should be in Category:Ursus maritimus, Category:Icebergs and Category:Rescue helicopters. It should not, however, be in Category:Ursidae, Category:Sea ice or Category:Aircraft."
I think it might be helpful for it to read, "This does not mean that an image only belongs in one category; it just means that images should not be in redundant or non-specific categories. For instance, an image of a polar bear being rescued from an iceberg by a helicopter should be in Category:Ursus maritimus, Category:Icebergs and Category:Rescue helicopters. It should not, however, be in Category:Ursidae (unless the species of that bear is actually indeterminate, but you are certain it is a bear), Category:Sea ice (unless you are unsure if it is actually an iceberg or maybe some other form of floating ice in the sea), or Category:Aircraft (unless you are unsure if it is a helicopter or maybe some other form of hovering craft; though if you are certain that the helicopter is an HH-60G Pave Hawk and not a Eurocopter EC145, then use Category:HH-60G Pave Hawk and do not use Category:Rescue helicopters). It is important to be specific, but it is just as important that you not attempt to "guess" at a specific subcategory when you are unsure which subcategory is correct. It is relatively easy for other editors to move your file into the most correct subcategories for it, but much more difficult to notice and correct a file's overly-specific and incorrect categorization. When in doubt, and although greater specificity is always desirable, greater generality may be better than taking a shot at an incorrect and more specific subcategory."
Parts of the arguments are untrue. For example, if looking for a generic image of man, you'd look into "Drawings of Men" or "Illustration of Men", not "Men". It is expected by anyone that category "Men" is crowded, because indeed it is a very generic category.
The more information someone has about an entity to look for, it is the more likely that he/she will not use generic, high-level categories, but a specific one. And vice versa: If one does not know anything more about the entity than it being a man, it is expected to find media in category Men and not in some ultra-specific deep-down category with attributes we do not know at the time searching.
I understand that there may be technical or software limitations and that commons may not want to fill up a generic category with millions of items. In this case, the arguments given to fight a not well defined 'over-categorization' situation need to reflect this circumstance, instead of giving false reasons. The current arguments contradict non-commons category use, but iirc commons is not to define new (or redefine) categories, but mirroring/borrowing from the ones used in day to day language, or those found in referenced literature.
To iterate, commons tries to mimic category concepts found in culture and society on a day-to-day basis. If it deviates from that for technical reasons, it should say so clearly, instead of trying to rewrite that cultural code and convention. If we give untrue ("made up/fake") reasons just to live up to a limiting technical factor, this may let learners make false assumptions based on what they learn/read on commons _and_ hinder people that may be able to solve the technical issue, because it is not rightfully portrayed as such.
If users are guided to understand sub-level-categories as being auto-included in top-level-categories, and use media categorization in the most specific cat for the sake of maximum convenience, then commons should provide a mode to flatten a given category: I.e. temporarily show all media of subcategories in the toplevel category and hide the subcategory title/navigation. This way, commons could keep up with real-life usage of a category (mimic it more closely).
I don't want to push anyone into this complex subject, but the current state the documentation is not satisfying (to use polite words). --91.55.165.7219:34, 28 January 2019 (UTC)[reply]
Cemeteries in Alpes-de-Haute-Provence
In the Category "Cemeteries in Alpes-de-Haute-Provece" the sub category "Cemetery in Forcalquier" appears to be listed under 'C' for Cemetery rather than 'F' for Forcalquier. Compo (talk) 17:32, 3 February 2019 (UTC)[reply]
Otto van Veen.
Why does it state on your web site that Otto van Veen died in Brussels, Belgium, while Belgium did not even exist back than? Brussels was (and is) in the Province of Vlaams Brabant, which was than part of the 17 Provincien der Republiek der Nederlanden. Belgium is not even 200 yrs old today? I'm wondering if you care to correct this mis info?
I dont know if this has been discussed before. Is it a good practice to create categories, even if it only has one file? This usually happens to people from the 19th century and early 20th century, or sometimes vanished buildings/places too. Only one photo has been found. I find it better to create such categories because 1. the cat can be linked to wikidata but the standalone photo cannot; 2. {{Wikidata infobox}} provides some automatic categorisation; 3. The parent cats look neater with a list of subcats rather than a gallery of images, which is sorted according to random filenames.
If there is concensus to encourage one-file categories for people and locations, maybe it could be added to the policy as a suggestive guideline.--Roy17 (talk) 22:04, 8 July 2019 (UTC)[reply]
It depends on the structure of the category in question. If it is routine for a topic to be categorized into some kind of grouping scheme, for example Category:Aircraft by registration, and therefore the expectation is that each registration will have its own category, it is okay to have single-item categories, as that facilitates users finding it easily and is consistent with the rest of that scheme. On the other hand, where that is not the expectation and the parent single-item category is really just a more generically-named duplicate of the child (particularly where this child is also a category) ten it is not really useful to have it and an upmerge is warranted. It would be good to come up with some way to add something like this to the guidelines. Josh (talk) 01:14, 11 July 2019 (UTC)[reply]
Categories for individual Chinese book
I would like to propose creating categories in Chinese name for Chinese books. They should be in their orignal Chinese characters (traditional Han for ancient books and Taiwanese and Hongkongese books.), rather than in English. The categories themselves will be in the category category:Chinese book categories to help English speakers to understand the propose of the categories. There are three benefits from doing this.
Easier discovery of the books. Some ancient books are bundled together in one scan file because they were printed together. Therefore, making standalone categories would make them being easier noticed.
Categorize different volumes of large books in a category.
Categorize different versions of a book. China has a long history. A common situation is, many different versions of a single book are created and survived. Creating book categories by name can help users navigating different versions of a book.
Partial Oppose: our category naming policy clearly says to use English where possible and if not, it should at the very least be romanized (i.e. use pinyin or something similar instead of hanzi). --HyperGaruda (talk) 06:15, 19 August 2019 (UTC)[reply]
@HyperGaruda: I see no benefits of romanization. It will not let those who don't understand Chinese understand the title and it will make it harder for Chinese speakers to understand and looking for the title. So I think the current rule of English title should not be clear-cut and should allow exceptions.--維基小霸王 (talk) 12:29, 21 August 2019 (UTC)[reply]
I am only proposing to use it for managing book scan files. It is understood that only the most famous books are known to foreigners. However, ancient Chinese books is so vast that the few known to the Western world seems very tiny. In the case you mentioned, it should be kept in English while pdf files for many different versions of the book will be categorized as 西遊記.
Storing scan files mainly serve the need of Wikisource. The multi language oldwikisource: requires title in original language, and I think this should be a rule commons should follow in some cases.
Suppose we want to transliterate 上海城市文化, I can think of the following transliteration:
Shanghaichengshiwenhua
Shanghai chengshi wenhua
Shang hai cheng shi wen hua
Shanghai Chengshi Wenhua
Shang Hai Cheng Shi Wen Hua
That is, we need to consider a few questions:
Should we separate the pinyin?
If #1 is yes, should we divide by words, or by characters?
Should we capitalise each single separate word?
I am no archivist or librarian, but I prefer #3 Shang hai cheng shi wen hua. Yes we should separate them. However, dividing Chinese words can be quite tricky at times, so I'd rather separate the titles by characters. Capitalisation also brings trouble as to whether all should be capitalised, or if only proper nouns should, blah blah blah... so let's not capitalise at all.
This proposed rule would be the last resort. It is overruled by any other widely accepted translated or transliterated names.
Yes, Chinese is not legible or typeable to most other users. But pinyin is also not understandable for most other users as well, and it make them even less possible for other language users to try to translate them. If you use google to translate 中國新海軍插圖, you can get the correct translation. [1] But if you translate its pinyin, you can get nothing. [2]
Therefore, using the original characters not only makes it more understandable for Chinese users, but also easier for non-Chinese users to machine translate them.
Since the categories for Chinese books scans themselves will be categorised as such in English, Englsh language user will understand what they are.
Also, I see no point for other language users to type pinyin. If a user can't type Chinese and want to refer to a category, the user can copy and paste the Chinese tile anyway.
Wikimedia Commons is a multi-language project, I think it should not has a strictly-English naming policy for foreign language book category titles. --維基小霸王 (talk) 00:46, 26 August 2019 (UTC)[reply]
Support As I recall from discussion in the early days of Commons, there was supposed to be more of this sort of thing for categories where the majority of active contributors would be participating with non-Latin characters; the only proviso being that there should be redirects &/or transliteration hat-notes for the benefit of users participating on Latin-character only keyboards. English was to be default for most global parent categories (other than taxonomic binomial nomenclature and Roman Catholic Popes, which would be Latin). National and local subcategories were supposed to have more flexibility to reflect usage by the people who actually live there and would be expected to be the primary participants in using such categories. I think that the imposition of English on local subcategories for non-English-speaking parts of the world has done much to discourage participation in Wikimedia Commons otherwise very useful categorization system. -- Infrogmation of New Orleans (talk) 02:25, 8 November 2019 (UTC)[reply]
Clarification about non-Latin alphabets
The policy on category names currently states: " Latin alphabets are used in original form including diacritics and derived letters, non-Latin alphabets are transcribed to the English Latin script." (Ignoring the fact that this is a run-on sentence…) Am I to understand that this would prevent the creation of, say, Category:Russian letter Б, because the final letter is in a non-Latin script? I assume so, since that category doesn't currently exist but Category:Russian letter B (that's a Latin capital B standing in for the Russian Б) and Category:Russian letter V (a Latin V standing in for the Russian В [Cyrillic В]) do exist. To be frank, I think this is pretty dumb. See also the subcats under Category:Greek letters by letter and Category:Arabic letters (say). These are perhaps more "debatable" instances, since the "English names" of the letters cannot be confused with English letters. But to try to do the same thing with Russian letters is, to say the least, highly problematic. - dcljr (talk) 23:12, 5 October 2019 (UTC)[reply]
@Dcljr: I agree, as is probably clear from my proposal re:Category:Russian letter Б. I do understand and agree with the policy in general, but it does not seem that the case of individual letters when the language-specific letter is the subject of the category was taken into account when the policy was written. Thus it would follow that the policy should not be automatically extended to this use case, but instead it is fair to craft a policy for this condition that is more appropriate for its specifics. In lieu of a policy that actually reasonably applies to the case of individual letters, reasonable consensus in category discussions is sufficient to direct the naming of those categories unless and until a policy applicable to the case is agreed upon and published. Josh (talk) 19:41, 23 October 2019 (UTC)[reply]
This policy does not seem to cover over-diffusion of categories It has been discusses at the Village Pump, See Commons:Village pump/Archive/2018/08#Overdiffused categories which went into the subject at length. This is a terrible blight on the project. I have seen many times one image made into a category and then nested in as many as 4 preceding empty cats. Or small villages with 20 images, diffused into as many as 16+ categories. All the images hidden away from sight... Surely this needs to be addressed? Broichmore (talk) 11:46, 6 August 2019 (UTC)[reply]
It doesn't appear that that discussion reached consensus. It's not up to the proposer to decide if/when things have been decided, and it's especially not appropriate for the proposer to say that the arguments of others were not rational. It would also have been good to put note here and on the countries category when the discussion started so that people who watch those pages could have seen it. --Auntof6 (talk) 20:39, 8 February 2020 (UTC)[reply]
Notes, links were left on 4 pages, and plenty of time had passed, with a large majority in favour of the proposal. I allowed plenty of time, a concensus was reached, and as no one else closed it, I did it myself. Better than being in limbo. As far as I know, this is the correct way - please send me a link to any rules to the contrary, if they exist. Many thanks. Llywelyn2000 (talk) 09:30, 9 February 2020 (UTC)[reply]
Illustration for HIDDENCAT
This picture has the hidden category "Taken with Olympus C-750UZ".
I suggest illustrating the HIDDENCAT section with this picture.
Naval ships often have a prefix in their name, as long as they have a militairy commander. E.G.: Hr.Ms. De Ruyter, HMS Endurance, USS Bainbridge, ARA Spiro and so on. Often is the name of the category in Wikimedia Commons followed by their pennant number. No problem at all, when the user can read the article of the ship in their Wikipedia by language. But not-specialist users, looking for images of the vessel, find more ships with the same name.
My suggestion is to start the name of the category with the pennant number, followed by the name and the year of first commisioning. Only if naval ships don't have a prefix: the name with "ship" and the year of first commisioning between brackets, as all other ships have the year of completion.
with a DEFAULTSORT to Shipname (ship, year of first commisioning) to integrate her with the other ships in Category:Ships by name (flat list)
Advantage: It places the ship immediately in her time. What not-specialist users see in publications or in a harbour is the pennant number, in large characters painted on the ship. Categorising this way can finding images of the ship make easyer.--Stunteltje (talk) 07:45, 30 June 2020 (UTC)[reply]
I made the category for the current name the parent, and linked it with the Wikidata item, and made the category for the previous name a subcategory. --ghouston (talk) 03:17, 1 July 2020 (UTC)[reply]
Hrm. The current naming convention for USS, HMS, etc. ships matches many other websites. Changing it would be a bit unexpected for most/all users, especially U.S. ships which are basically always referred to starting with "USS" (and I think British ships with "HMS", Australian with HMAS, etc.). They would also stop matching the wikipedia names (which templates like {{USS}} and {{HMS}} assume). Many countries do not use such prefixes, and our naming probably tries to follow "normal" usage for a navy, which can admittedly be inconsistent patterns, but may make the most sense overall. Also for non-naval ships, the year is the year of completion. It can be a bit harder to identify that for military ships, as some are not commissioned immediately upon being built (especially true of very old ships). I'm pretty sure I've seen a number of naval ships not use the year of commissioning, though I would imagine most of the time it would be the same. Secondly, if you are changing the DEFAULTSORT, then it doesn't matter as much (as a finding aid) what the actual name of the category is, since categories will be sorted by that. I don't think it has all that big an advantage, really. We have Category:Ships by pennant number, which can be helpful when trying to find a ship by those numbers. Also, you would need to name it "DD-246 USS Bainbridge", even though the visible number is just 246, which wouldn't be as much help as a finding aid (the U.S. can have the same numbers but with different ship types; kind of odd to have the number but not the type). Another point is that sort of naming convention is used with fishing ships (putting the license number first), and you'd probably get military ships mixed up in those search results. Lastly, some countries (e.g. Russia) seem to change those numbers quite frequently. They seem to re-number all their vessels at once, and can also re-use the same numbers on different ships (of the same class even) when they do, meaning those numbers really aren't associated with a ship for a long time. So they are not a cure-all as an identification aid (speaking from some recent experience), though they surely help. Carl Lindberg (talk) 00:25, 1 July 2020 (UTC)[reply]
As for related non-IMO and non-ENI ships, I thought I remember reading guidance somewhere to have the most recent ship name be the parent category, with older names as subcats. Not always a great solution, but it somewhat works. But I can't find where I saw that.
I tend to agree that naval ship naming is inconsistent for many countries. I would not mind putting the build year in the DEFAULTSORT, though it would have to include "(ship, <year>)" if you really wanted those to order correctly with non-naval ships. But I don't really see enough advantage in this change to support it. Carl Lindberg (talk) 00:25, 1 July 2020 (UTC)[reply]
Thanks for the comment. But please realise that lokal Wikipedia's have their own way of categorising articles. No problem at all. In the Dutch Wikipedia naval ships are named, starting with Zr.Ms. But Commons is for international use, where users have to find images as easy as possible. The find function of Commons delivers - when a user looks for a number starting with a character - gives fishing ships only in very few cases. Not-specialist users don't know the type of the vessels and not the right characters in the prefix. Many USS naval ships don't have the type in the prefix. For the a Bainbridge the proposed system results in:
Bainbridge (ship, 1908)
USS Bainbridge (1842)
1 USS Bainbridge (1901)
246 USS Bainbridge (1920)
25 USS Bainbridge (1961)
96 USS Bainbridge (2004)
The DEFAULTSORT is intended to find the ship by name in Category:Ships by name (flat list). The USS Bainbridge via Bainbridge (ship, year of first commissioning). For ships that change their prefix in the name, new categories have to be made, as the prefix is in the name for naval ships. --Stunteltje (talk) 07:14, 2 July 2020 (UTC)[reply]
That does looks rather odd, frankly. And that only helps searching by number -- it makes searching by name in the same manner no longer work. If you know the name but not the number, currently you can type in "uss Bainbridge" and see all ships with that name, but that would no longer work if the names start with the prefixes. Sure seems to me most non-specialist users would search by the ship name, when they are looking for pictures of ships. And while you can use "intitle:xxx" in the search box, you can do that too with the numbers ("intitle:246 bainbridge"). For countries like Russia which reshuffle those numbers relatively frequently, we would need to rename all the categories too (and documentation on those number changes is often hard/impossible to come by so you would need to be able to name the category when you don't know the number). It may make identifying ships in a photo a bit easier, but I think it would harm a lot of other use cases, such has finding photos of a ship when you know the name. I don't think the identification case is important enough to change the category name -- I typically search in the Ships by pennant number categories if I'm trying to figure out a ship by its number. Each navy might have certain conventions or practices which may make some different naming styles make sense -- not sure we really have to standardize. If we do though, I would absolutely not put the prefix number first. In the U.S. case, it seems really odd without the ship type which is part of that identifier -- it's not immediately clear what it is. Carl Lindberg (talk) 03:13, 4 July 2020 (UTC)[reply]
I assumed that not-specialist users just see an image of a naval ship somewhere and in that case only a pennant number is visible. If they read an article, in most cases the name of the vessel is used. I was not aware of "you can use "intitle:xxx" in the search box", did not find that instruction before. I was a professional standardiser in my working life, I prefer standardising in an encyclopedia. I did the suggestion for USS ships because in many cases ships have more functions in due time and more abbriviations in the pennant number. In my opinion that asks more categories for the same ship. Also for Russian ships. Unfortunately we cannot use an IMO-number to couple these categories, as we can do for civil ships with different names. --Stunteltje (talk) 19:47, 4 July 2020 (UTC)[reply]
Sometimes you can only read the name in a photo, and want to figure out which one, as well. I think more people use the search box because they want to find pictures of a particular ship, too, and I think this naming scheme would hurt those usages. It's not a naming style that most people would expect, so I suspect it could cause more issues than it solves. For those of us trying to categorize and identify ships it could help a bit, but I think there are enough other avenues for power-categorizers -- I typically just search in the ships by pennant number categories for those, and/or the intitle: stuff (or other things documented in Help:Searching like "incategory:").
If we were going to standardize naval ship titles, I suppose we could follow the naming rules in Category:Ships more closely, with perhaps the exception of using a prefix if that is common practice for a navy like USS or HMS, and omitting the pennant numbers completely. So maybe "USS Bainbridge (ship, 2005)". But I'm not sure that is worth it. Build years and commissioning years are not always the same (especially with age of sail ships, which could sit uncommissioned for a while after completion, and be decommissioned/recommissioned many times). I may prefer to just standardize on a scheme for each navy, though that may take someone more versed in that navy to pick a good pattern. For example, Category:Naval ships of Brazil has different styles depending on which ship type or class category you go into. That seems suboptimal to me, but I don't know enough about their navy to know how their ships are most typically referred to.
As for IMO numbers... some recent naval ships might have them (see Category:IMO 9752060), but yeah it's not common yet. They don't get renamed all that often these days, but it does happen. Similar problems happen with old ships which never got an IMO number but got renamed a lot. Carl Lindberg (talk) 20:35, 4 July 2020 (UTC)[reply]
IMO categories seem the worst of all to me, because they are cryptic. The main category for a ship can be its current/last name, and where it's worth having separate categories for former names, they can be subcategories. Perhaps last name is not as useful when they ship was only renamed once, shortly before being taken out of service. --ghouston (talk) 02:47, 5 July 2020 (UTC)[reply]
Yeah, categories full of IMO numbers aren't terribly useful to dig through. Plus, they only start with digits 5 through 9, and modern ships all start with 9, meaning they aren't broken down in any helpful way inside a category. Logically it makes complete sense to have "built at XXX shipyard" type categories at the IMO level, since it applies to all the names the ship has (and doing it by name can sort of inflate the apparent production of a shipyard if ships happened to be renamed a lot). Random practice seems to have those categories, plus "ships scrapped at", at the IMO level, but "ships built in <year>" and "ships scrapped in <year>" at the name level, for whatever reason. I've been reluctant to move anything more up to the IMO level for the reasons you mention, though. It's highly unsatisfying to see a list of numbers to make that a meaningful search. If there was an "expand all one level" that would help, but I don't know of anything like that. You can't index them either.
The "most recent name" can be problematic for situations like you mention -- a ship is well known for one thing, then gets sold for a year at the end of its life with a different name. And ships are often renamed / reflagged just for the trip to the breakers. The "most famous name" is another way, but sometimes ships have signifiant career segments with different names. Another issue is that a subcat then becomes "members" of any categories the parent cat was. Say a warship gets converted to a cargo ship after a war, and has a significant career in the latter capacity (there were many examples of WWII ships that happened to) -- if the warship name is a subcat, then it's (by virtue of the parent cat) a member of various "cargo ship" categories, and if done the other way around, the cargo ship is a member of "navy of XXX country" categories. The IMO/ENI categories solve those issues, but then create the ones you mention. I really don't know the best way to go, honestly. Usually though naval ships don't have those issues anymore, but sometimes can be sold to other navies and have significant second careers under a different name. Carl Lindberg (talk) 18:14, 5 July 2020 (UTC)[reply]
Ships changing usage completely may be rare, but it does happen, e.g., en:Yas_(yacht). Although when the change is that large, it's seems like basically a new ship that recycles some ship parts. --ghouston (talk) 02:17, 6 July 2020 (UTC)[reply]
A single name is needed in any case for the Wikidata labels, and I doubt that many would want to use an IMO number. I think using the same name for the main Commons category and the English Wikidata label would be logical: why come up with two naming conventions when one is enough. Likewise, the English Wikipedia article names. --ghouston (talk) 04:34, 6 July 2020 (UTC)[reply]
@Ghouston, if you cannot bear the heat, stay out of the kitchen. The IMO and ENI categories have the function to couple schipnames. Nobody wil start looking for an IMO number by going through the pages in the category. I categorised thausands and thausands of ships and it is a very important tool for that work. Not to discuss here, we discuss shipnames. Please realise that Wikimedia Commons is not an extension of the English Wikipedia, but for international use. E.G. The English Wikipedia uses the year of launching, in Commons the year of completion or first commissioning. Many captured and or bought ships into the navy have no known launch or build dates, so it's convenient. --Stunteltje (talk) 06:46, 6 July 2020 (UTC)[reply]
Wikidata now has a way to have the main item be linked to the Commons IMO category, and subitems for specific ship names. The title of the main item can be whatever -- doesn't need to be an IMO, but that can always be edited to be the "most recognizable" or "latest" or whatever. Typically it is a ship name though, not the number. Ships changing function do happen actually, especially with cargo ships. Those per-ship-name categories also have things like "Ships registered in Monrovia", or recently I've seen things like "blue and white ships", and those change much more frequently. Carl Lindberg (talk) 17:33, 6 July 2020 (UTC)[reply]
Re, Your proposal: to start the name of the category with the pennant number, followed by the name and the year of first commissioning. Only if naval ships don't have a prefix: the name with "ship" and the year of first commissioning between brackets, as all other ships have the year of completion.
It may be no surprise to you that I disagree.
Firstly start the name of the category with the pennant number, these numbers on a naval ship can change multiple times throughout it's lifetime. In the old days that's why they were on flags, so they could change. Later they were painted on hulls, and could be overpainted. Most ships have changed their number once and some multiple times. Example HMAS Derwent F22/DE22/DE49. There is no need for overcomplicating names with pennant numbers. This would be a duplication of Category:Ships by pennant number. Ships names change too, so this proposal is only going to over complicate an already complicated subject. Also Pennant numbers are not always sequential, either for the vessel or for the period. They mean nothing to the casual reader. They're confusing, even in WW1 the RN changed numbers to confuse the enemy!!! Year dates give an immediate fix on (period) recognition, and that's the major importance here.
Secondly You propose follow the name and the year of first commissioning. Your confusing ships with boats and barges. Ships have launch dates. There is a proliferation of build dates to choose from. A sign of a non-notable ships is they have no launch date. Non notable ships are notable only by exception, I.E. disaster. Commissioning dates are more difficult to ascertain on the web. Launch is unique, just like a human birthday. The main reference bodies for ships, Example : the National Maritime Museum and more importantly the en:wikipedia use launch dates. The en:wikipedia site is the goto website for initial reading on a ship or any other watercraft. That will become only more true as it swallows up every competing shipping site around it. Commons is a secondary source for deep research by comparison. I feel we should be compatible with English Wikipedia, after all we use its disambiguation pages in order to recognise one ship from another. We should be debating this topic and how we do things at Wikipedia talk:WikiProject Ships where this kind of issue can be aired by the widest amount of expert witness and opinion; including ours.
Thirdly, your overall schema for catalog naming is difficult on the eyes and brain. These pennant numbers are awful, they only look good and mean anything to retired USN seaman to wear on their navy ball caps, where very often the number identifies a particular generation of crew. Again, pennant numbers may be useful for identification on the sea during radio silence, but for casual human understanding their useless. They really do nothing for ready identification here.
The other major problem we have is our labelling any type of watercraft a ship, a real problem when it's a yacht (ignoring steam-yachts for now), of which we have huge amounts of unidentifiable clutter.
We need to keep the system simpler not over complicate it.
Proposal to add user categories as an exemption for OVERCAT
Hello, I've a discussion with User:Elkost about what he believes is a violation of OVERCAT and I believe is my good right as Commons user and image uploader. User categories are hidden and are so not visible to most viewers of Commons, these categories are there as a tool to administrate the stuff Commoners have on Commons. More precisely, I have the following 3 categories in an image: "Images by User:Poco a poco", "Images by User:Poco a poco taken in 2018" and "Images of Spain by User:Poco a poco", and I would like to keep it like that (many other photographers do the same) without having to leave it to the odds that the category "Images by User:Poco a poco" is removed by other users who believe that the removal is the right thing to with per OVERCAT. I use the "mother" category "Images by User:Poco a poco" for example to track the amount of pictures I've uploaded to the project, to add the figure in userboxes or to run stats with tools like Glamorous or Unused Images.
My concrete proposal is to add an additional note to the section "Exception for images with more categorized subjects" like this "Also user categories are exempted as those are not visible to most viewers and project users should have no restriction for their use". Any other opinions on that? Poco a poco (talk) 10:02, 31 May 2020 (UTC)[reply]
I think what you are asking is reasonable. 2 remarks:
Thank you Jmabel for your answer and your remark. I sometimes (after have agreed it upon the author) upload variants of existing images to improve them or to show and issue, but those are derivative works of images from other Commoners, so not really my images. The same apply to others who upload derivative works of my images, so a clear rule is not really possible. That's why I do appreciate the flexibility of user categories (paying the price os some administrative work).
Hello, I hope to get an advice though I have no clue if anyone is still watching this page at all.
My question is simple: There is a certain user who permanently violates COM:OVERCAT, both in files' and in the category namespace.
Any attempts of mine to fix, revert, and/or talk to them ended up in an unbelievable aggression from their side, so that it is useless to explain, why there should not be redundant categories.
On Administrators' noticeboards, it is useless to report the user, as hardly an admin shows any interest for category-related topics.
So in short, my question: what to do? If you say "just ignore", then maybe we should abolish all rules such as COM:OVERCAT, because it has no point anymore in maintaining it?
Sorry if the question may sound dismissive, but did you detect any concrete harmful consequence of the categorisation you describe, or is yours merely a general concern?
Sometimes, when I see some parts of our rules about categories appear to go unenforced in certain areas of Commons, I suspect users let it be because that portion of the category tree is perceived to work sufficiently fine for those who use it. Nemo21:30, 1 July 2020 (UTC)[reply]
I'm afraid I don't get your question. The situation is, that we have here a clear guideline named COM:OVERCAT which -- I suppose -- was thought to avoid an overflow of generic categories such as Category:Forests and to increase usability of more specific categories too. And now there is a user who is violating this rule en masse, and any attempts to explain the rule have failed.
So, if you wish, my question is: why do we still have these guidelines, if it is no longer possible to enforce them? All users are equal, but certain ones are more equal than the others? Thanks. --A.Savin22:02, 1 July 2020 (UTC)[reply]
Examples? Otherwise this comes over as just whining, and more about an editor you dislike than about content.
OVERCAT is a very simplistic policy, justified on a narrow basis. In many cases it's entirely right to ignore it.
The basis for OVERCAT is that if membership of one category entirely implies another category, then there is no need to state the second category. That is a stronger requirement than merely being a member of the first category. As Mediawiki categories are far from rigorously defining, there are many, many cases where their members are not all implicitly members of a supercategory, simply because the two categories are related. Andy Dingley (talk) 08:52, 5 July 2020 (UTC)[reply]
The first priority for me -- believe it or not -- is the quality of the content, so yeah, if an editor does poor edits en masse to damage the content, there is no reason for me to like this user. Apart from that, we are not on Admin's noticeboard and that's why I abstained from calling them by name and provide difflinks and the like. And I don't feel like doing it, as long as I have the impression that no one here is really willing to help me. --A.Savin12:08, 5 July 2020 (UTC)[reply]
@A.Savin: That building is a part of the History of Wellington. How is this file to be found and used if it is buried away in a category of 1, in any one of 148 Wellington by year categories? What is the purpose in taking files and hiding them from view like this? Is this a case of the act of filing being an end in itself?
Maybe some users simply do not understand our "simple" system. Since yesterday a user has not been able to come to terms with that system, although I gave the info in various revert summaries and using the words "simple" and "easy". If I had any button, I would send a "strong" warning to users like that. BTW I do not use our templates like "last warning" because if later they continue and nobody does anything, these templates do not serve anything other than ridiculing the applier. (Maybe we should make those last warning templates another admin privilege.) See here. Thanks. E4024 (talk) 17:45, 15 December 2020 (UTC)[reply]
I had put several warnings on their talk page, not to mention all other comments; this resulted in an ANU against me and two admin colleagues having badly bullied me there (with one of them even having blocked me, which fortunately has been recognized as abuse and ended up in their desysop). --A.Savin18:08, 15 December 2020 (UTC)[reply]
Umh! I mostly do categorization work and did not search that much. I simply thought a newbie confusing our categorization system with social media tagging. Then this is not that innocent as I thought... --E4024 (talk) 18:15, 15 December 2020 (UTC)[reply]
@A.Savin: I see you've not answered my last question.
Perhaps the problem is over diffusion of subject matter by making too many categories. When there are under 100 images in a category there is no justification for diffusing them out of sight into yet more sub categories. The human eye knows the difference between a coin, a monument, an image of a battle.
Perhaps it would be better to sponsor the notion that 100 or more images are required before splitting further down into two or more categories?
We are obsessively hiding images away by making too many small categories, like 1841 in Foo when we only have a few Foo images, or devaluing important images illustrating battles or ancient things by carelessly throwing them into an art catalog.
Take Category:Carl Locher an artist of limited vision with 9 categories (Using a dubious schema) covering less than 100 images, where multiple clicks (at least 18) are required to get any kind of overview. Some images are 4 clicks away from parent category. Broichmore (talk) 17:21, 17 December 2020 (UTC)[reply]
The issue here is "respecting our categorization", making cats smaller or larger is something to talk about and decide. We (people who categorize) "suffer" when people go out of the scheme. There is no problem in opening discussions about "detail" cats and "eliminating" (removing/deleting) them. I am a supporter of that. With 10 images inside or with 1001 images inside we do not need cats like "nude or partially nude women smiling while making pee (soles apparent)" or "nude or partially nude women smiling while making pee (soles covered)". When you have the cats, you have to obey them. Cheers. --E4024 (talk) 18:06, 17 December 2020 (UTC)[reply]
@E4024: I admit I'm not a perfect user but I have over 460,000 edits on the Commons and I've created hundreds and hundreds of categories all over the world, including Category:Çukurhisar that I see you just used, so I'm not clueless but not sophisticated technically.A.Savin is the only admin who has threatened to block me. He has given me 6 block warnings this year (the only ones I've ever received and I've been editing here since 2015) and a Final warning, for violating COM:OVERCAT I guess. (He doesn't explain to me.) He said I reminded him of a certain banned user(?). The admins said my edits weren't "vandalism" and decided A.Savin was too involved to block me.A.Savin has deleted all my posts on his page that were attempts at discussion. Now on December 30, 2020 he has twice threatened me with blocks again. I'll add that he's done many things I've had to fix, change or recreate, so I'm not the only one who makes mistakes. Krok6kola (talk) 21:53, 7 January 2021 (UTC)[reply]
You may like my work or not, but please stop spreading obvious lies and slander Krok6kola. In these last three sentences, not a single claim is true. a) "A.Savin has deleted all my posts on his page that were attempts at discussion" -> this is a lie, you can find all these threads in the 2020 archive. Archiving old discussion is normal and not the same as deletion (not to mention that even deleting them w/o archiving is not prohibited on Commons). b) "Now on December 30, 2020 he has twice threatened me with blocks again" -> this is a lie, because I didn't threaten you even once. All I did was placing a warning on your talk page (which by the way was after this, this, this and this), but who says this means that I was going to block you after that, instead of, for example, complaining at COM:ANU, which hopefully I have every right to do? And c) "[A.Savin] done many things I've had to fix, change or recreate" -> this is again a lie, because there really were not "many" such things, if at all. In about 95% of the cases, it's exactly the other way around -- I have to fix the mess you are producing. And from time to time this happens every single day in a period. So, again -- stop deeming me and fellow users stupid, stop spreading lies. --A.Savin22:19, 7 January 2021 (UTC)[reply]
[3] (Undo revision 423177730 by Krok6kola(talk) --here we go again, COM:OVERCAT?)12:12, June 1, 2020 (I had to redo this because of A.Savin (A))*[4] (attempt to discuss by me a category I had to create for wrongfully categorized files by A.Savin (A)) 16:22, June 3, 2020 *[5] Me to A.Savin (A) (You have combined two different mosque categories with different Pakistan cultural heritage numbers. Why didn't you notify me that you were wiping out the category I was working on and substituting yours?) So I had to untangle the files and recreate the mosque category. 20:22, 3 June 2020 (UTC)[reply]*[6] "This is your last warning. The next time you vandalize a page, you will be blocked from editing Commons. A.Savin (A) 20:46, 6 June 2020 (UTC)"[reply] Dispite on May 9, 2020 an admin told A.Savin my edits were not vandalism.*After A.Savin was found too involved to block me per admins, he wiped out all messages on his page [7] (Blanked the page) and the posts on them. A.Savin09:29, June 9, 2020. A.Savin (A), are you referring to me above when you ask what to do about a user?: "There is a certain user who permanently violates COM:OVERCAT, both in files' and in the category namespace etc ...? And "Nowhere close to a newbie. It's much more like a mix of total helplessness with total discussion's resistance." And "Any attempts of mine to fix, revert, and/or talk to them ended up in an unbelievable aggression from their side, so that it is useless to explain, why there should not be redundant categories." I'm the only user you have threatened this way. What's the deal? (Yes, I created Category:Demonstrations and protests against the Gaza flotilla raid held in Belfast per advice to do so from the Village Pump. And yes I made categories for all the parades in Belfast. And yes I made Category:Beaches of Karachi and others you complain about.) Krok6kola (talk) 02:59, 8 January 2021 (UTC)[reply]
@Krok6kola: As long as you fail to provide relevant difflinks or any other evidence for your above three claims ("A. Savin deleted all posts by Krok6kola from his talk page without putting them to an archive" + "A.Savin has twice threatened to block Krok6kola in December 2020" + "A.Savin systematically makes poor edits that Krok6kola has to fix afterards"), all your other justifications are null and void, and you are a liar. --A.Savin08:26, 8 January 2021 (UTC)[reply]
Although I know what COM:OVERCAT says, it is only experience that teaches if admins don't explain or discuss with me what I am doing wrong. Please understand that I am open to any explanations and criticisms on my talk page. Thank you, Krok6kola (talk) 21:58, 7 January 2021 (UTC)[reply]
I'd agree that a demonstration or protest is not necessarily a "parade". The "parade" category should be added to individual photos as relevant, not to Category:Demonstrations and protests in Belfast. Even if it happens that all photos in the category at a given time might be parades, it is not inherent in the category.
However, @A.Savin: this doesn't come even close to "vandalism" and, yes, I would say any accusation by an admin that an experienced user here is "vandalizing" constitutes a threat to block that user. If you are overreacting (in my view) to this extent perhaps you should recuse yourself from giving warnings like this to experienced users with whom you are in dispute and instead should bring it to COM:AN/U to see if other admins agree with your assessment. I do the latter at times on a lot less basis than this.
In any case, that particular matter had nothing to do with OVERCAT, so let me get back to OVERCAT. There are times when it is entirely appropriate to include both a category and its immediate parent (and the argument is even stronger when they are at a few removes). For example, a building might be in its architect's category, but if we had a picture of the architect in front of the building we would certainly want both categories, and I think there is a strong consensus to that effect (strong enough that it probably should be overt at COM:OVERCAT. Slightly less clear, but I would certainly use both categories: if I have a picture that looks straight up an arterial street in a city, and we have categories for both that street and for a building in the foreground, I'm going to use both of those categories even if the street category is parent to the building category. - Jmabel ! talk01:27, 8 January 2021 (UTC)[reply]
@Jmabel: Probably you will be surprised, but I'm very well aware of this kind of OVERCAT exemption, and in my own uploads you'll also find a couple of examples (such as this one). And now please do me a favor and show me a single one difflink, where you would say that I had reverted a meaningful (over-)categorization by Kalbbes/Krok6kola. --A.Savin12:19, 8 January 2021 (UTC)[reply]
As I've said before, I'm not wading into the details of who is right or wrong about a particular image. What I'm saying is mainly: don't use your admin privileges when you are in an honest content dispute. Bring it to AN or AN/U as if you were not an admin yourself, and let someone else handle the admin role. Accusations of "vandalism" over what is, at worst, possibly edit-warring are completely unwarranted, and the fact that you would make that accusation suggests to me that you are too emotionally involved in this to be playing an admin role. I've been there, probably on average every 3-4 months. Occasionally the other admins even decided I was wrong, which is fine, my inability to judge objectively once I'm embroiled in a dispute is exactly why I wanted someone else to handle the matter. - Jmabel ! talk22:13, 8 January 2021 (UTC)[reply]
As far as I know, using Template:Test2 is allowed both for admins and for non-admins. But the discussion here is not about this template. Could you please answer my previous comment? Thanks. --A.Savin22:18, 8 January 2021 (UTC)[reply]
Anyone can use a vandalism template for actual vandalism. Are you sticking to your claim that Krok6kola is a vandal, not someone who may have been mistaken but was acting in good faith?
OK, so your statement is that I am not allowed to use template "Vandalism is not appreciated", but instead am allowed to use template "Mistaken edits done in good faith are not appreciated". Thanks for the idea, I'll think about that.
But seriously, I am deeply disappointed about your current attitude. It's getting more and more obvious that you are not neutral and not judging based on contentual evaluation. Because you still do not have the answer to the question, whose edits actually were poor. Who systematically does over-categorization and refuses all possible arguments and discussions. You are definitely advocating the wrong one. Not the one for whom the quality of Commons' content has the highest value above all, but the one who does not give a shit about anything on Commons except his own edit-count. I'd like to add that, of course, you are perfectly free anytime to say "I have neither time nor desire to look into your edits / your history / whatever". OK, but then you should be really neutral, or simply keep silent and find better things to do, for example taking and uploading pictures. Actually, basic etiquette for a sysop, especially a long-term one... --A.Savin22:51, 8 January 2021 (UTC)[reply]
So now my etiquette is bad? As a fellow admin, I've been trying to suggest what I think you could do better without my becoming party to the dispute in question. You are simultaneously asserting that your judgment remains steady even when someone disagrees with you, and going on the attack over what I think is reasonably mild criticism, gently (though publicly) given. But feel more than free to take your complaint about my "etiquette" to AN/U, and I'll promise not to even comment in the discussion, as long as you agree to link the present section. And, no, I do not need to examine the content of this dispute further than I casually have to say that Krok6kola's edits were not vandalism, and that you should refrain from calling similar edits vandalism in the future, or threatening to block a genuine contributor over a dispute to which you are a party. And if you think you didn't do the latter, fine, but I'm telling you that any accusation of vandalism against a long-time user looks from the outside like escalation toward a block. - Jmabel ! talk23:02, 8 January 2021 (UTC)[reply]
Over time I have created a few categories. A couple of times I've been told, "Your category was not attached to the category database." Why? I don't know what that means. The category works -- when you search for it it's there and images that use it are there. -- Jim Evans (talk) 14:19, 29 December 2020 (UTC)[reply]
Example(s)? I suspect those comments may have referred to categories that you created and which were themselves uncategorized, i.e. not part of another category. Such categories can not be found, unless one knows their name. -- Michael Bednarek (talk) 00:45, 30 December 2020 (UTC)[reply]
Thanks for your reply. Sounds logical. When I need a category, I give it an appropriate name (IMO) and simply save it as a category. I wouldn't know how to "associate" it with another category. For example, if I have a picture of Alfort Dam and need a category for it, I search for Category:Alfort Dam. If the search doesn't find one it offers for me to create the category. I do, and that's it!. -- Jim Evans (talk) 03:24, 30 December 2020 (UTC)[reply]
1. I think it's better to start somewhere—very general being better than nothing.
2. When in doubt, go to the higher cat. For example, I see a pic of a tree. Is it a pine, spruce, yew, or juniper? Lest I mis-categorize, I put it into something like Category:Pinales.
3. I have some intention of more specifically categorizing files I supercatted earlier.
However, I might be missing some points something in doing this.
Category:Ursidae has 36 sub-cats, and those in turn have about 190.
I doubt Wikicommons expects me to go through all 226 of such and maybe many more sub-sub-cats.
Therefore,
While I might, after several, or a few 10s, of minutes find, say Category:Ursus maritimus, Andöyane, Liefdefjorden, for which an image fits perfectly, maybe there's features of the image I'm neglecting that could fit into a few of the the +36 subcats, or their sub-sub cats, or sub-sub-sub cats. Hence I might put it Category:Ursidae for a while. Indeed I might overcat and use both cats.
Is this wrong and if so, why?
or maybe I should just suck it up and spend a few hours checking out all the sub-cats, sub-sub-cats, sub-sub-sub-cats, etc. to get every possible relevant cat for the image even though I'm not an expert and I have little interest in spending such time.
I'm afraid you're correct: giving very general cats looks like a simple solution but is actually wrong in many cases. It is at best vague, as you rightly say; at worst, misleading. No cats is better than wrong cats. Chiswick Chap (talk) 08:28, 7 January 2021 (UTC)[reply]
I agree that no cats is better than wrong cats, but I don't think that was the question. I think the questions was whether no cats is better than cats that aren't as specific as they could be. For example, is it better to leave something uncategorized if all you can tell about an image is that it's an automobile -- not what kind, or where it is, or the color, or the make, just that it's an automobile. I would think that people who are interested in automobiles could find it under the automobile category and improve the categorization from there. --Auntof6 (talk) 09:50, 7 January 2021 (UTC)[reply]
Exactly my point, Auntof6; and that's happened. I know little about cars. What if I see an image of car that's black, green, and white, but I recognize nothing else about it?
Do I:
1. put it in Category:Black, green, white automobiles. It currently has one file and sub-cat; and to those wanting to make articles or like about cars, be it WP or elsewhere, my sub-sub-catting would help little, and might even hinder the process if the car is notable.
2. put it in Category:Automobiles in apparent violation of WC policy, but a Commonist who's also a grease monkey/motorhead/mechanic-going-on-for-decades/call-them-what-you-will, maybe someone like Marisa Tomei's character Mona Lisa Vito in w:My Cousin Vinnie, who could in seconds tell make, model, year, and other characteristics, and might put into such categories, making the image far more useful.
3. risk violating WC policy even more by putting it in both categories, and thus overcat, because while it might be months before an expert comes along, go to Category:Automobiles, see a few 10s of images of automobiles he/she'd would find easy to put into great subcats, while at the same time I already have it in a sub-sub-cat, and doing my little bit.
or
4. leave the uncatted image be, and wait for the expert to go to the uncat categories and look for images of automobiles in the 10 000s, maybe 100 000s, of other images, in files that might not have the words "car" or "automobile" in them, maybe not seeing a car in a cat page of 200 images—maybe 20 of such pages to see 20 cars—or not—i.e. not bother with such a process at all—and let that image stay unused, perhaps for years.
At the risk of singling out Chiswick Chap, which is not my intention as he edited files I edited and greatly improved them, I'm ignorant about yoga. Let's say in a few days of mad-catting of several hundred images, I come across several of people doing yoga poses, or what I think is yoga—it could be something else—not everyone sitting in the lotus position or something like it is doing yoga.
Do I:
1. put into Category:Yoga, and risk ticking off a 1%er (i.e. someone who has given a fair amount of time to WC and disproportionately help make it the great wiki it is)?
2. spend an hour, likely more, reading about yoga so I get, IMO, hip enough about it to try to put into sub-cats and risk mis-catting?—and do similar with every image I'd otherwise put into general categories?
or
3. leave well enough alone and let the yoga expert go through 100s, maybe 1000s files, in Category:People, or again 10 000, or maybe 100 000s files in uncat cats, looking for people doing yoga—as if they haven't better and/or more fun uses of their time.
and for Chaswick, I reiterate Auntof6's point, I put in general cats to indeed avoid mis-catting.
I know this could lead to cats being cluttered up, though I figure better this than leaving them in the uncat cats, and my intention is to go back to files I catted.
Files I put into general cats months or longer earlier, if they haven't already been put into better cats by others, I'll sub-cat, even if such might be somewhat lame. e.g. Category:People into, say, Category:Men with moustaches.
What objections are there to me continuing such process: again keeping in mind that this account of mine in slightly over 3 years has catted fewer than 20 000 files—i.e. I can manage them manually in a similar amount of time.
Ideally of course they would go into the most specific cats possible. Some cats are not supposed to have images, but that really means that someone should figure out a more appropriate subcat and move it there. Putting it up higher might mean more work for someone else, but at least it's moving a file in the right direction. This is a collaborative project, so putting images into generic cats, for other more knowledgeable people on that subject to further move around, seems fine to me. If someone is doing the work to move files out of being uncategorized, that seems like a good thing which there shouldn't be many roadblocks for -- should not be necessary for them to be an expert on most topics. If there are categories like Category:Unidentified trees that might work just as well (or better) than just Trees, though. Obviously it's a much more helpful edit the more specific you can get, but to me something is better than nothing. Carl Lindberg (talk) 21:25, 7 January 2021 (UTC)[reply]
IMHO, the point here is not the addition of categorisation (as a means of describing what content represents), but rather the loss of useful workflow categorisation (categories that describe the state of content).
Your edit does two things, not just one. It adds "People" or "Cars" - but it also removes "items in need of further work". The first is a negligible improvement, as the targets are so broad and so numerously filled as to add little. But mostly it removes the item from worklists, such as "items needing catgeorization". That leaves them in limbo: having neither a useful categorisation, nor obviously highlighted as needing to have one added.
If you added the items to "Unidentified steam locomotives" etc. (we have many such categories, where a non-expert can recognise the broad group, but it needs a subject expert to go further) then that would be fr more useful. Adding them to "Cars" is neither useful as is, nor indicative of needing further work. It's particularly useful to go to the more detailed "workflow" categories, because that puts them under the spotlight for the right subject experts.
I can't object to you adding "Cars", although I think it's largely pointless. I would encourage you to use "Cars needing further categorisation" (or similar) instead. Please don't remove workflow cats at all, unless they're no longer needed. Andy Dingley (talk) 13:08, 9 January 2021 (UTC)[reply]
While the Unidentified categories are fine, many of these top-level cats are marked with {{Categorise}}, which puts them into Category:Categories requiring permanent diffusion, which sort of makes them work queues themselves -- i.e. the files are not meant to stay there, but need to move more. Category:Automobiles is not marked that way, but there are clearly people looking for files there and moving them on, since there is only one file directly in that category at the moment while there are hundreds in Category:Unidentified automobiles. So adding them to Automobiles would seem to get them noticed by people who can more appropriately categorize them, instead of being stuck in uncategorized -- the combination of the two editors would seem to get them effectively moved from uncategorized into proper places, the end goal. If there are top-level cats with hundreds/thousands of files (i.e. they are not moving further), perhaps a bit more research could be done to get them at least a level or two lower. Carl Lindberg (talk) 15:13, 9 January 2021 (UTC)[reply]
I have problems with the infobox at this category, here. How does one edit the infobox or is it generated elsewhere?
Problems:
Birth year
D.O.B
Middle name
The English language version of Tones and I does not provide any of this as there are no reliable sources for the information. The information breaches WP:BLPPRIVACY and should be removed immediately.Shaidar cuebiyar (talk) 05:43, 30 April 2021 (UTC)[reply]
Добрый день. Подскажите, пожалуйста, как я могу принять участие в фотоконкурсе Вики любит землю 2021 Беларусь, где необычно загружать фотографии? Svetlana Besp (talk) 11:12, 22 June 2021 (UTC)[reply]
Category organization help
Hi there, Category:Association football kit evolution by club has had a large scale expansion recently and needs re-organising. I know that someone did at some point because we have "AC Milan" in the M section, not the A section. Which is where the pages are automatically put when they are added to the category. I simply cannot figure out how to do it myself and need someone to either deal with it themselves or show me how to do it for myself. Otherwise I'm going to be popping up here every few months! :). REDMAN 2019 (talk) 16:28, 26 July 2021 (UTC)[reply]
@REDMAN 2019: It’s [[Category:Association football kit evolution by club|Milan]] in the wiki code. You can append the pipe and the sort key in HotCat as well (there without the square brackets, of course). —Tacsipacsi (talk) 21:26, 26 July 2021 (UTC)[reply]
I created a new category, Cathartes aura roosting, here and instead of it being categorized alphabetically with all the other subcategories, it was included under the letter “C” along with another un-alphabetized category. What went wrong? Raquel Baranow (talk) 17:17, 20 September 2021 (UTC)[reply]
There are no "subcategories" in a strong sense, merely child categories that are members of a parent. They're sorted, by default, by the category name. You can modify this with a piped link, but it's manual. We often prefix this piped cat sort with a single space, to put them at the head of a long list of categories. Andy Dingley (talk) 17:28, 20 September 2021 (UTC)[reply]
Hi Andy, I’m confused as to why the child category I created wasn’t alphabetized with the others, why was it listed separately under the letter “C”? Now it’s under the letter “R”. Also note, the category you created yesterday, “Roosting,” is red linked. Raquel Baranow (talk) 17:34, 20 September 2021 (UTC)[reply]
You created a child category spelled with a C, so it was sorted under C. Same as Cathartes aura in Canada. Now some other categories aren't sorted under C, but that's because they had cat sorts set on them by piping, e.g. Cathartes aura eggs is a child of Cathartes aura| eggs, so it sorts as " e".
The Roosting cat wasn't me. It ought to be fixed, but I can't see where our "roosting" bird ethology cat is hiding – I presume we already have one, so I haven't created one. Andy Dingley (talk) 17:46, 20 September 2021 (UTC)[reply]
So sorry of falsely accusing you of creating the red linked cat! (No idea why I made that mistake, brain malfunction, lol!) Why isn’t “Cathartes aura eggs” piped so it alphabetizes under “E”? Why aren’t all categories alphabetized under a letter? The page looks funny with only “Roosting” and “Canada” under a letter. I suppose maybe when there are many categories they should be alphabetized? I’m going to try and figure out how to alphabetize all the child categories. Raquel Baranow (talk) 01:50, 21 September 2021 (UTC)[reply]
I see now, adding a space after the pipe stops the child cat from being alphabetized under a letter on the parent page. I added the space so now I’m happy with the way it looks on the parent page. Kind of makes sense that “Canada” is under a letter. Thanks for your help! Raquel Baranow (talk) 02:07, 21 September 2021 (UTC)[reply]
Remove reference to failed policy
We should remove the text "There is also a related failed proposal." from the Category names section. It seems to be a very bad practice for a policy page to reference a failed proposal in the normal text as if it was somehow additional information that a user needs to know to understand the policy. It does say 'failed' but still it is misleading--it is a mystery what relevance a failed proposal could have to the actual policy. We can have a link to that proposal in the 'see also' section at the bottom of the page, but it's current position is fundamentally tricky and can lead to confusion among readers. Policies should be unambiguous about what is and is not policy. Josh (talk) 12:22, 31 March 2022 (UTC)[reply]
Let's say a user has uploaded 200 images,
and now gets to work adding better descriptions to each one.
Well, he would like to create the hidden category "Norfowitz done" to the ones he has already finished fixing, to help him keep better track of what still needs fixing.
So please mention if it is OK to do so.
Also, he knows in the future he will likely upload another batch, so this category needs to be permanent.
Maybe there needs to be a new type of category only he can see.
No, he is not good at databases, or other tracking software, to help him keep his own list on his own computers.
Photo shows two adjacent but different businesses. Any reason I can't add categories for more than one of them?
After more than a dozen years of being active on Commons, I thought I had a general idea of how categories work. @Allforrous: apparently has different ideas and thinks I'm wrong. I'm trying to avoid an edit war, so I want feedback from others. Here's one of the photos in contention: File:MagazineIgnatiusHoHoDec07.jpg It shows a building with housing a restaurant on one half and a clothing shop in the other half. I had categories for both businesses - That seemed appropriate to me, and I'm unaware of any rule prohibiting doing so. Allforrous removed category for the shop. At first I thought Allforrous mistakenly thought the shop category referred to the restaurant, so I pointed out that it did not, then restored the category, but Allforrous removed the category again, siteing OVERCAT. As far as I can determine, "OVERCAT" does nothing to prohibit more than one category on an image if each category refers to a specific different thing seen in the image. Discussion started at User_talk:Allforrous#Unexplained_category_removal. I have not gotten further response there recently, so I'm bring the question here for others to see and give guidance. Thank you for your attention, -- Infrogmation of New Orleans (talk) 18:30, 18 November 2021 (UTC)[reply]
I'm not an expert but I'm contributor since a number of years. I'm inclined to agree with you. Suppose I upload a photo showing two adjacent buildings, one housing a bike shop and the other a library. Far-fetched? No. Just image yourself standing at geolocation 52.232837,4.831553. I think the correct categorization would be both "Bike shops in North Holland" and "Libraries in North Holland".
Or imagine yourself on a platform of Arnhem railway station, and your photo shows EMU's to Utrecht, Nijmegen and Zwolle, and DMU's to Winterswijk. The correct categories would be "Electric multiple units, motor coaches and railcars of the Netherlands" and "Diesel multiple units, motor coaches and railcars of the Netherlands". If you wanted to be more specific you could change them to "DD-IRM" and "Breng GTW". Doing so and not removing the two more general categories, would constitute overcategorization, as I understand the concept of overcategorization.
Or take a look at this file, showing several types of trains at this station. From back to front: Stadler GTW DMU's used by Arriva, Stadler GTW DMU's used by Breng, a 1600 class locomotive (in 2013 probably still used by NS Goederen) and an ICM EMU used by NS reizigers. I think that would require four categories.
Should a long-established and stable name in one variant of English be renamed without discussion to a US variant spelling, to be "Consistent with other such categories with American spelling."?
There is no COM:LANGVAR although I believe en:WP:LANGVAR would be relevant and illuminating. The intention there is to reduce "churn" in language-variant naming, and avoid edit-warring. There is also no reason that category names have to be consistent with each other: their membership is defined explicitly, not implied through names. Navigation between categories is primarily done by following links. If a reader is typing category names, they're more likely to be doing so in a local variant, not on the assumption "Everyone uses American spelling".
IIRC, early discussion was to prefer UK spelling/terms in UK related categories and US spelling/terms in US related cats. "Consistency" should not be used as an excuse to rename things contrary to what locals call them. -- Infrogmation of New Orleans (talk) 22:45, 22 December 2021 (UTC)[reply]
I know this is the case in English Wikipedia, as I found it written in its style guide. However, I couldn't find the same thing in Commons and tried to give categories a consistent American spelling. --Soumya-8974 (he) (talk • contribs) 05:33, 23 December 2021 (UTC)[reply]
Obviously, but why would you do that? Just to land-grab for America? Some of us do find that pretty offensive, and even if (yet again) Commons doesn't have an explicit policy, why do you choose to act so inconsistently with Wikipedia, and then justify that as "for great consistency"? Andy Dingley (talk) 14:30, 23 December 2021 (UTC)[reply]
My point is that the nearest we have to a style guide is that from en:WP. Which is very strong on "don't make pointless changes" to avoid this problem, rather than the false claim that we need "consistency" to make categorization work. Commons already goes too far for consistency, such that we have "(ship)" in every category name for marine vessels, even for barges, boats, floating cranes and a whole slew of things that definitely aren't ships. Andy Dingley (talk) 16:55, 23 December 2021 (UTC)[reply]
Wikipedia guidelines are not in effect here, but the reasoning in and about them can be enlightening. Unilaterally changing category names should also not usually be done.
The consistency becomes obviously problematic in categories that combine aspects: American spelling might have been consistent for space programmes, but a seriously doubt it would be consistent in the part "European" of Category:European space programmes, which this concerned. Any category can ultimately be subcategory of a category in a different scheme, so when aiming for consistency, one cannot decide based only on one aspect, but should have a discussion with a broad audience. At some point the consistent names will clash badly with e.g. the principle of most commonly used name.
When creating a new category, the following principles apply to determining the correct variant of English to use in the category name in certain cases:
Proper names of organizations, works, etc. should use the spelling of the subject in their category name, regardless of variant.
Regional topics should use a variety of English predominant in the topic's region in their category name.
Industries and academic/scientific fields with internationally-recognized standard naming conventions should reflect these standards in category names.
In all other cases, there is no automatic preference as to which variant of English should be used. Category names should not be changed solely in an attempt to standardize on a particular variety of English. It is acceptable to have sub-categories with names in a different variety of English than their parent category in cases where the parent is a general category while the child category is region-specific (e.g. Category:Gas stations in the United States being under Category:Petrol stations by country).
Identical items should have identical names for all countries and at all levels of categorization. Categorization structure should be as systematical and unified as possible, local dialects and terminology should be supressed in favour of universality if possiblethough regional sub-categories may be named in accordance with the appropriate regional English variant. Analogic categorization branches should have analogic structure.
Reason: There is no policy (currently) on COM:CAT or COM:LP that gives any guidance as to which form of English to use. In general, I have found that most discussion support is for the enwiki-ish approach of using the predominant dialect for the given region or topic if applicable. Don't get hung up on exact wording, I'm happy to change that based on discussion. Hopefully this will give some basic guidance to users without being too prescriptive, while also defusing some attempts to 'convert' all categories over to anyone's particular preferred variant of English. It is particularly important to revamp the text under the universality principle, as the current policy does appear to strictly forbid regional names, though it is current common practice to permit such. Josh (talk) 12:02, 31 March 2022 (UTC)[reply]
There are problem with not being consistent. One problem is that guessing category names becomes difficult. The names need to be guessed e.g. in the Upload Wizard, Hotcat and Cat-a-lot, unless you open a parent category in another tab and start exploring, slowing you down radically. When uploading a batch of files, one doesn't want to use many seconds on adding categories to individual images, in addition to those common for the batch. This is aggravated for non-native English speakers, who don't necessarily recognise the local words. It is hard enough for me to decide whether something is a sledge or sleight (especially when it is something not often discussed in English). If which one it is depends on the region, that'd be real confusion. –LPfi (talk) 16:04, 31 March 2022 (UTC)[reply]
Nothing wrong with having category redirects from variants. Agree that categories are in some cases needlessly difficult for non-native English speakers, and that should be kept in mind. (For example, I don't see the reason in constructing date categories with names like "October 2021" rather than "2021-10", but that is perhaps a discussion for another day.) -- Infrogmation of New Orleans (talk) 17:27, 31 March 2022 (UTC)[reply]
Oppose the policy changes presented in the two boxes above ... sorry but the Commons:Categories#Universality principle is more useful than right to your dialect. As about UK-vs-US, the choice should not be based on ideological reasoning ("US is bigger and better than UK"), but practical usefulness:
"flat" or "apartment" ? "apartment" is better, because the word "flat" has 17'000 meanings whereas "apartment" has only one
"proctor" or "invigilator" ? "examination supervisor" is most universal and understandable
Dates should be of course YYYY-MM-DD (details can be discussed), consistent with HH:MM:SS, for practical reasons. The messed-up US system is simply not useful.
"Universality" as opposed to "right to your dialect"? Were there such a thing as standardized international English, I'd likely agree to implement it on Commons, but at present there is no such thing. There is nothing but "dialects". For global parent categories where there are significant differences, yes, we need to pick one, but for country specific subcategories I think using country specific language is reasonable (eg Indian English for "in India" categories, similarly US etc) - otherwise we risk using names for common objects that are completely unfamiliar to hundreds of millions of people, the people most likely to be contributing and categorizing media related to that topic. -- Infrogmation of New Orleans (talk) 00:52, 1 April 2022 (UTC)[reply]
Is there any work being done on making categories multilingual? We have been asked to keep them English only to avoid creating a mess, difficult to sort out once the good technical solutions is implemented. That sounds reasonable, but I have been waiting for 10+ years, and not heard about any work being done on it. While Indian English may seem reasonable for Indian categories, why aren't Chinese names reasonable for Chinese categories? I think a mechanism for translation cannot be postponed much longer. –LPfi (talk) 12:18, 1 April 2022 (UTC)[reply]
@LPfi: As far as I am aware, there has been no real progress on this goal over recent years. I agree that I would love nothing more than to have a system such as Wikidata uses, which would be identifying each category with a 'behind-the-curtain' ID number and presenting the user with a label (and description) from a list by language based on their region or user settings. This would also simultaneously solve a lot of DAB issues by eliminating the need for such labels to be unique. However, as great as that sounds, I do not have any reason to believe it is close or even on its way. I laud anyone with the tech skills to lend their support to such an effort. In the meantime, we are stuck with the real limitations of the current system with no end in site. Avoiding parallel categories for different languages isn't just to make such a future solution easier to implement, but also to allow our current category scheme to work in the meantime. Maintaining parallel categories would be an absolute nightmare, and inevitably would go against the most basic objective of categories: to get all 'images of X' in one organized place. However, to your point of 'Chinese for China', I actually agree. The argument that it would make it difficult for Latin-script language speakers to access, understand, or maintain such categories also, in my opinion, means that as a matter of logic, the English/Latin-script naming rules also exclude anyone who does not read Latin-script languages from participating in the project. However, this is my personal position and I do not see it having much support project-wide (but would love to see it discussed), and changing that is beyond this particular proposal. Josh (talk) 10:38, 3 April 2022 (UTC)[reply]
Support A personal opinion. "Streetcars" where I live were all changed to "trams", a word not used in my locality, a place very proud of its "streetcars". In fact, no where I have lived in the U.S. (several places with streetcars) have they been called "trams" including San Francisco (see San Francisco cable car system. I don't categorize images in my current location anymore because building and such have been give names not used locally or by tourists. For whom is categorization "consistency" aimed? Krok6kola (talk) 12:39, 3 April 2022 (UTC)[reply]
Having a policy hinder people from using their best judgement is not good. Like Taylor 49 writes above, it is good to choose the least ambiguous name (and perhaps the most widely understood), regardless of variant. This is especially important for the main category – and I think the main category (and any main X by Y category) also should have a description (and a rationale in many cases), and should be linked for that description from all subcategories. –LPfi (talk) 05:50, 3 April 2022 (UTC)[reply]
@LPfi and Taylor 49: That is exactly what current policy does -- hinders people from using their best judgement. According the current wording, the category Category:Gas stations in the United States must be renamed to Category:Petrol stations in the United States due to the name of its main and sibling categories being 'petrol stations'. Of course calling a gas station a petrol station in the US is as silly as calling a petrol station a gas station in the UK. This of course does not make sense, and so we often just ignore the actual wording of the Universality Principle during CfDs. One of the main points of my proposal is to better fit the policy to what we are actually doing in practice. It actually gives more flexibility by allowing regionalization that makes sense versus the current policy's top down rigidity, and lays the groundwork for going farther in the future to allow broader language localizations (per your 'Chinese for China' suggestion above). Josh (talk) 10:48, 3 April 2022 (UTC)[reply]
It'd make sense to have category redirects either from the common names or from the local ones. I don't know which one would be better. Having such redirects also involves risks: Are the redirects fixed on category moves? Will there be clashes between the synonyms (such as LNG gas stations in the UK in a Category:Gas stations in UK)? The latter risk increases with the number of languages. I think we need to figure out how internationalisation of category names should be done properly. I assume the WMF thinks structured data will solve the issue, but as they haven't really worked with the community I have no hope it will be anything but a big mess in the foreseeable future. –LPfi (talk) 07:13, 4 April 2022 (UTC)[reply]
@LPfi: I am a big fan of redirects in general. While they can at times become a maintenance headache, the majority of the time I believe that the help they offer outweighs the possible overhead issues that go with them. As for using structured data, users can already link WD items in the structured data section, and this theoretically allows categories to be automatically populated based on the classification scheme in WD. However, there are a couple of big problems here. First, this requires a massive amount of work to attach such links to existing and new media, but as you mention, they have not done much to get buy-in from the Commons community to embrace this work, so few files actually have such structured data added. Second, the development of the categorization tools is nowhere to be seen and will take a lot of development time to be ready for reliable employment. Thus in the end, I don't think we can count on WD and the WMF to solve the problem for us anytime in the foreseeable future. Thus it is on us in the now to figure out how to do things right. The reason I see a need for evolving our policy is that I see a continual stream of CfDs continually re-litigating what should be covered by guidelines. This not only consumes significant time and breeds antagonism as discussions devolve into argument over which language is better, but results in a patchwork of approaches depending on which users happen to be active and participate in any given discussion. I think one of the first policy questions that we need to answer is: Should sub-category names have to be an exact match with their parents (as per current Universal Principle), or should subs be allowed to be named differently to conform to local variation as appropriate for a given region (as is often the consensus in real CfDs)? Josh (talk) 23:40, 4 April 2022 (UTC)[reply]
.jpg)
.jpg)
Oppose: our category naming policy clearly says to use English where possible and if not, it should at the very least be romanized (i.e. use pinyin or something similar instead of hanzi). --HyperGaruda (talk) 06:15, 19 August 2019 (UTC)
Support As I recall from discussion in the early days of Commons, there was supposed to be more of this sort of thing for categories where the majority of active contributors would be participating with non-Latin characters; the only proviso being that there should be redirects &/or transliteration hat-notes for the benefit of users participating on Latin-character only keyboards. English was to be default for most global parent categories (other than taxonomic binomial nomenclature and Roman Catholic Popes, which would be Latin). National and local subcategories were supposed to have more flexibility to reflect usage by the people who actually live there and would be expected to be the primary participants in using such categories. I think that the imposition of English on local subcategories for non-English-speaking parts of the world has done much to discourage participation in Wikimedia Commons otherwise very useful categorization system. -- Infrogmation of New Orleans (talk) 02:25, 8 November 2019 (UTC)
1.jpg)
2.jpg)
Done Josh (talk) 01:11, 20 April 2022 (UTC)
,_participates_in_the_Navy%27s_Caps_for_Kids_program_at_the_Los_Angeles_Children%27s_Hospital.jpg){kind=link}
