Commons:Village pump

Shortcut: COM:VP

• Community portal
  • introduction
• Help desk
• Village pump
  • copyright
  • proposals
  • technical
• Administrators' noticeboard
  • vandalism
  • user problems
  • blocks and protections

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓

COMMONS DISCUSSION PAGES Commons Help desk Village pump (general discussion) Copyright Proposals Technical Graphics and photography discussion Photography critiques Image improvement Illustration workshop Map workshop Photography workshop Video and sound workshop Categories for discussion Undeletion requests Deletion requests Volunteer Response Team/Noticeboard Translators' noticeboard Work requests for bots Contact administrators Vandalism User problems (Dispute resolution) Blocks and protections Bureaucrats' noticeboard CheckUser requests Oversight requests Telegram IRC webchat Commons mailing list (archive) Commons' bugs on Phabricator Welcome to the Village pump This page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Archive/2024/09. Please note: If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias. Have you read our FAQ? For changing the name of a file, see Commons:File renaming. Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer). Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam. Purposes which do not meet the scope of this page: Please do not make deletion requests here: use the relevant process for it instead. For technical support and graphics talks (PNG, SVG, GIF, etc.), please post on the Graphics village pump. To ask for image improvement, see: Graphic Lab/Photography workshop for photographs. Graphic Lab/Map workshop for maps. Graphic Lab/Illustration workshop for other illustrations. To ask for video or audio improvement, see Commons:Graphic Lab/Video and sound workshop. For translation requests, please post at Commons:Requests for translation. For media requests, please post at Commons:File requests. Search archives:     Start a new discussion

Legend
In the last hour
In the last day
In the last week
In the last month
More than one month
Manual settings
When exceptions occur, please check the setting first.

Thatched water pump at Aylsham, Norfolk [add]

Centralized discussion See also: Village pump/Proposals   ■ Archive Third-party images published by the National Weather Service (26 August 2024) Commons:Requests for comment/Hosting of free fonts in Commons (18 July 2024) How do we organize categories by date (14 May 2024) Should PD-CQ Roll Call be used for recent images? (5 January 2024) Technical needs survey (17 December 2023) When does PDART apply to textile works? (15 November 2023) Does this image contain "love hearts"? (17 August 2023) Overhaul of categories by period (5 December 2022) Version of Saudi flag to use (11 July 2022) Concern regarding revocability of KOGL licenses (22 December 2021) Should deleting content from your own talk page be forbidden? (11 November 2021) Revise the COM:FOP Sweden section (1 February 2021) Change technical name of LRs to license-reviewer from image-reviewer(2 November 2023) Template: View   ■ Discuss    ■ Edit   ■ Watch

	SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days.

August 22

Is renaming categories with an English name to local language names a good idea?

Category:Heroes' Cemetery in the Philippines has been renamed to Category:Libingan ng mga Bayani, to "match Wikipedia and Wikidata", see history of this category. Though there are exceptions for English category names: "some proper names, ... and names for which the non-English name is most commonly used in the English language" (see Commons:Categories#Category names), I wonder whether such an exception applies to this category and whether this would be a good development for other category names that are now in English but might have other names in Wikipedia and Wikidata. Because I can understand the English name without a translation program, but not the name in Philippine (or the majority of other languages). @Seav: Can you give your opinion as well? JopkeB (talk) 05:43, 22 August 2024 (UTC)

If there is a Category Redirect, I see no problem. There is a problem with English names that are meaningless to local people. Like Our Lady of the Forsaken, that is a very common thing to find around my place, that means absolutely nothing to the Valencian local people, who are enterly familiar with either la Virgen de los Desamparados or la Mare de Déu dels Desemparats. I do use English category names, but I have to explain my wife once and again what is Our Lady of Good Health (la Virgen de la Salud) or Saint Anthony the Great (Sant Antoni del Porquet).
I think a more multilingual approach is required. B25es (talk) 05:55, 22 August 2024 (UTC)

Then I would prefer to have the redirect the other way around: let the English name be the category name and let the local name have the redirect. JopkeB (talk) 06:11, 22 August 2024 (UTC)

That's perfectly fine for us B25es (talk) 16:32, 23 August 2024 (UTC)

Hi! Thank you for bringing this topic up. I think the relevant policy is Commons:Language policy, which defers to a section: Commons:Categories#Category names. As you have stated, the important passage is:

Category names should generally be in English (see Commons:Language policy). However, there are exceptions such as some proper names, biological taxa and names for which the non-English name is most commonly used in the English language (or there is no evidence of usage of an English-language version).

I think my rename follows the "proper names [...] for which the non-English name is most commonly used in the English language". The English Wikipedia article title, Libingan ng mga Bayani, had been discussed and renamed a few times since 2009 between the English-translated name and the official native-language name (see the header on Talk:Libingan ng mga Bayani), with the latest move request in 2020 resolving to the native-language title. There is plenty of evidence that the native-language name is used in English-language sources (albeit sources in the Philippines, but then again, English is an official language of the country). Some examples of English reliable sources within the past year that use the native-language name: [1][2][3][4].

I consider this situation similar to categories like Category:Taoisigh which could be reasonably be actually named Category:Prime ministers of Ireland, but we're using the Irish name here in Commons (so far without any argument, I think?) and also in the English Wikipedia (w:Taoiseach). —seav (talk) 06:14, 22 August 2024 (UTC)

"Taoisigh" is apparently not a proper name of a person, like Mary Johnson, but the name of a function, in the rest of the world known as "Prime minister". So this is not part of the exception. AND it is clearly not conform the Universiality principle, which says that "Identical items should have identical names for all countries and at all levels of categorization." So, please make the redirect the other way around. JopkeB (talk) 08:43, 22 August 2024 (UTC)

"Taoisigh" seems a bit odd to me, I don't recall seeing that spelling (or hearing a pronunciation that matches that spelling), but as a native English-speaker, I'd consider "Taoiseach" entirely appropriate. The BBC, for example, pretty consistently use "Taoiseach". FWIW, Google gives 239,000 results for "Taoisigh", 5,820,000 for "Taoiseach", 545,000 for the phrase "prime minister of Ireland" and 419,000 for "Irish prime minister", which seems to confirm my instinct. - Jmabel ! talk 18:41, 22 August 2024 (UTC)

The plural of taoiseach is taoisigh, according to Wikipedia. --Geohakkeri (talk) 19:00, 22 August 2024 (UTC)

Interesting, I guess I'd never heard it in the plural, and certainly have no idea how to form Gaelic plurals. - Jmabel ! talk 04:06, 23 August 2024 (UTC)

So it is also OK to rename Category:Prime ministers of France to Category:Premiers ministres? And for all other countries alike? Then we might delete the Universiality principle as well. I am not a native English-speaker and I consider "Taoisigh" not appropriate because I have never heard it before, I am familiar with the name "Prime ministers" and I guess the same applies to the best part of non-native English-speakers. Why would there be an exception for Gaelic? JopkeB (talk) 04:30, 24 August 2024 (UTC)

Because in English when we talk about this person/office, we use the word "Taoiseach". Similar issue to Category:Tsars of Russia.- Jmabel ! talk 17:40, 24 August 2024 (UTC)

Is that true for other English-speaking countries as well, like the USA, Canada, Australia, New Zealand? And the word "tsar" is well known, also in other languages, and is about heads of state, not prime ministers. So I think this is not a good comparison. JopkeB (talk) 04:08, 25 August 2024 (UTC)

Definitely true for UK; for U.S. I've usually heard radio news reporters first use the word "Taoiseach", then define it once (e.g. "equivalent of a prime minister"), then use "Taoiseach". Again, I think that Google count speaks volumes: over ten times as many hits for "Taoiseach" as for "prime minister of Ireland". - Jmabel ! talk 04:51, 25 August 2024 (UTC)

"Chancellor" is also used for the German head of state. And "Teno" for the Japanese "king". Nakonana (talk) 11:48, 25 August 2024 (UTC)

So, it looks a little bit like a mess, for Germany even more than for Ireland (for Ireland there is at least a redirect, for Germany you have to figure out yourself what the category for federal prime ministers is). But luckily prime ministers of Japan‎ are still in Category:Prime ministers of Japan‎ (I could not find teno and japanese "king"). My concern are about (1) non-native English (and German) speakers AND (2) creators of templates and other technical solutions. Both groups need clear category names, with the same category name throughout the category tree. I think the Universiality principle is made for both groups. How can we apply this principle to categories for prime ministers of Ireland and the federal state of Germany (and perhaps other countries?)? JopkeB (talk) 16:27, 25 August 2024 (UTC)

I typed it wrong, of course, Tenno is a redirect. Maybe "Head of State" would work? Nakonana (talk) 17:16, 25 August 2024 (UTC)

Head of state is not the same as prime minister. Germany and Ireland both have a president as well as a prime minister of the (federal) government. JopkeB (talk) 05:02, 26 August 2024 (UTC)

Agreed that a prime minister is normally "head of government" but not "head of state". I can't think of a country with a prime ministerial system where the prime minister is considered head of state. - Jmabel ! talk 00:25, 27 August 2024 (UTC)

 Oppose Changing the name to the "native-language" for two reasons

• 1. The idea that it's in the "native-language" now is totally ridiculous to begin with. According to Google 22.5 million people in the Philippines speak Tagalog. While 39.4 million speak English. Further the place being discussed here is a national cemetery within Fort Bonifacio. The national headquarters of the Philippine Army. So it's just more likely due to how many speak English then Tagalog nationally that they will speak English. Meaning the change will clearly reduce the number of people who will be able to find the category. I don't think it's simply enough to simply have a redirect in this case either. Otherwise you could justify renaming every category to the "native language" simply because redirects exists. That's not their purpose. Per the guidelines we have to go with the name whatever language has the most chance of being searched for and it's pretty clear that's English in this case.
• 2. There's been multiple CfDs having to do with this exact issue in the last couple years and there was clearly no consensus from them to change the names of the categories to the "native-language" at the time. I highly doubt if Seav had pf started a CfD for this before changing the name that it would have gone anywhere. That's what they should have done instead of just unliterally changing the name based purely on how the place is named on Wikipedia. Regardless, it's pretty clear that there is no consensus to use "native-language" names for categories in cases like this one. I'm not sure what the circumstances around Category:Taoisigh versus Category:Prime ministers of Ireland, but "other stuff" isn't really a valid reason to make the change. Again, especially considering the outcome of prior CfDs, guideline, and fact that clearly more people speak English in the Philippines then Tagalog and this is the national headquarters of Philippine Army. It would be ridiculous to say that shouldn't matter "because Wikipedia article." --Adamant1 (talk) 06:37, 22 August 2024 (UTC)

To be fair, your first argument only works for this special case of a country where a lot of people speak English. It doesn't work for other categories. For example, sometimes I go through the Category:Media needing categories (Cyrillic names), and there I find a decent number of files that actually are properly categorized, except that all the categories are written in Russian. The Russian community has a bot that addresses the issue to some degree but automatically searching and replacing Russian-language categories for their English counterparts, but the process is not perfect and you still find a lot of "uncategorized" Russian media. The other issue with translated categories is that there are various ways to translate one and the same thing, and it's a pain to figure out what the English name of an already existing category is. Oftentimes I go to Ru Wiki, find the subject there, follow the link to the Wikidata item from the article, and then look up the Commons category on Wikidata. There are just too many ways to "translate" even something as simple as "площадь мира" (transc.: ploshad mira, lit.: square [of] peace). You can go by Category:Peace square, Kazan or Category:Peace Square, Krasnoyarsk with a capital S, or Category:Mira Square (Kaluga)‎ (like Google does), or Category:Mir Square (the word "peace" = "mir" without the genetive suffix "-a"; Mira Square is actually equivalent to "Peace's Square", and if you want to have "Peace Square", you need to drop the genetive in Russian too "Mir Square"*), or you could translate it as Category:Square of Peace, or you use the Russian word order Category:Square Mira, which is a construction that you can find in translations of "проспект мира" (prospekt mira / Peace Avenue), such as Category:Prospekt Mira (Kaliningrad)‎ — why even bother translating when you can transcribe instead? (Now we only have to agree whether it's prospekt or prospect — k vs. c, see Category:Prospect Mira in Lipetsk‎.) Or you can just translate it like in Category:Peace Avenue, Krasnoyarsk, or you can be like Moscow and create a grammatical language monster by keeping the Russian words while using English word order: Category:Mira Prospekt in Moscow — this one raises eye brows in English speakers and Russian speakers alike.

* This is done with "площадь Ленина" (transc.: ploshad Lenina, lit.: square [of] Lenin). While the suffixed "-a" is kept in "Mir-a" for some reason, it is dropped in case of "Lenin-a": Category:Lenin Square (Ufa)‎ instead of "Lenina Square". However if it's a street (улица Ленина / ulitsa Lenina), then Lenin can keep his suffixed "-a": Category:Lenina street (Irkutsk)‎... or not Category:Lenin Street (Gdov). Nakonana (talk) 20:51, 22 August 2024 (UTC)

* typo: "It doesn't work for other countries." Nakonana (talk) 20:54, 22 August 2024 (UTC)

It is a fine balance line between translating native names into English ones or keeping them in the original language (or as a transcription for languages that have other scripts than Latin). For me names of streets and squares may be kept in the original language, except perhaps for very well known ones, like Red Square in Moscow. So the same rule as for place names (where only names known in English should be in English in Commons categories). JopkeB (talk) 09:22, 24 August 2024 (UTC)

Do we have a reference for the English name or is it just a literal translation? File:2551Taguig City Landmarks 17.jpg is in English. Enhancing999 (talk) 06:43, 22 August 2024 (UTC)

In English the name literally translates to "Cemetery of (the) Heroes" (libingan = cemetery; mga bayani = heroes). I've seen that translation (with or without the definite article) and I've seen the variation "Heroes' Cemetery" as well. A couple more points: the official website of the cemetery is [5], which is in English but still uses the native-language name, and the law that established the cemetery is Proclamation No. 208, s. 1967, also in English, but the name is again the native-language name. —seav (talk) 07:03, 22 August 2024 (UTC)

 Oppose renaming but see meta:Community Wishlist/Wishes/Add machine translated category titles on WMC. Prototyperspective (talk) 09:19, 22 August 2024 (UTC)

I think in this case the Tagalog name is appropriate, with soft redirects from the maybe two most likely English-language names.

I'd also add: in practice, this varies a lot from country to country, and sometimes by region within a country. For example, for Catalonia, we pretty consistently favor Catalan names; for Romania, I've seen English-language names for things that it is hard to imagine anyone referring to that way, e.g. "Roman Square" for Piața Romană; it's like a Spanish-speaker calling New York's Times Square "La Plaza del Tiempo" or (even worse) "La Plaza de los Tiempos". - Jmabel ! talk 18:50, 22 August 2024 (UTC)

One example of that is how they call pizza "pie" in the New York City area. I'd prefer keeping Category:Pies for images of actual pies though. --Adamant1 (talk) 15:04, 25 August 2024 (UTC)

•  Oppose I think it is a bad idea in most cases. It is categorized in Category:Military cemeteries in the Philippines. Should that also be renamed to Category:Mga sementeryo ng militar sa Pilipinas? And Category:Sydney Opera House was designed by a Danish guy so should it be named in Danish? I think local names should be reserved for when there is no English name. --MGA73 (talk) 15:17, 23 August 2024 (UTC)

  @MGA73 how about Category:Cristo Redentor (Rio de Janeiro)? Should it be moved also? It has been under Portuguese name since the creation of the category. JWilz12345 (Talk|Contrib's.) 22:45, 23 August 2024 (UTC)

  • There is zero possibility that category name should be changed to something fully English. I'm a native English-speaker; I've been aware of that statue for over 60 years, and literally never heard it referred to in a fully translated mode (usually just "the Cristo" or if context is unclear "the Cristo in Rio", but of course "Cristo Redentor" is more correct). You would as well translate "Rio de Janeiro" to "January River" (or "Las Vegas, Nevada" to "the low places, snowy"). - Jmabel ! talk 04:02, 24 August 2024 (UTC)

I think in English the name is w:Rio de Janeiro so it would not make sense to translate the name of the city. I do not know if there is an official or established name in English for this statue but Category:Statue of the Little Mermaid (Copenhagen) is in English and so is Category:Eiffel Tower. And Category:Denmark and Category:Brazil are also English. Should that be changed to local names too? I think the rule on Wikipedia is that articles is named by the most used name. So I think it would make sense to do the same on Commons. Just like it is Category:Bill Clinton and not William Jefferson Clinton. --MGA73 (talk) 07:08, 24 August 2024 (UTC)

@MGA73 the statue is "Christ the Redeemer", many know that. Unsure if using English language as the precedence will lead to the category being moved to "Category:Christ the Redeemer (Rio de Janeiro)". JWilz12345 (Talk|Contrib's.) 07:39, 24 August 2024 (UTC)

JWilz12345 I think that if there is no clear name for something then just leave the name as it is and make some redirects if needed. I would just hate to see if someone get the idea to rename hundreds of thousands of categories just to use local names in categories. --MGA73 (talk) 07:52, 24 August 2024 (UTC)

"Rio de Janeiro" also has a literal translation to English. Enhancing999 (talk) 07:55, 24 August 2024 (UTC)

@Enhancing999@MGA73 we are talking about the statue's name in English. Everyone in English-speaking world calls it "Christ the Redeemer". Little to none use "Cristo Redentor". It is understood, but I am surprised about claims here that there is no clear name of the statue in English. It is crystal clear: Christ the Redeemer. Of course, English-speaking world calls the city "Rio de Janeiro"! So: "Category:Christ the Redeemer (Rio de Janeiro)" is the most-fitting name. JWilz12345 (Talk|Contrib's.) 09:04, 24 August 2024 (UTC)

The concern is not so much this statue, but that people use the equivalent of "River of January" as it occasionally happens. Enhancing999 (talk) 09:09, 24 August 2024 (UTC)

Should that also be renamed to Category:Mga sementeryo ng militar sa Pilipinas? I think this is a strawman argument. That category name is not the official name or proper name of an actual entity unlike "Libingan ng mga Bayani" and so would run afoul of Commons:Language policy. —seav (talk) 08:47, 24 August 2024 (UTC)

The argument from MGA73 seems strange, but it's true that "Heroes' Cemetery in the Philippines" could suggest that it isn't a specific cemetery, but a class.

"in the Philippines" as a disambiguator is unusual, possibly incorrect. Enhancing999 (talk) 08:55, 24 August 2024 (UTC)

The question was "Is renaming categories with an English name to local language names a good idea?" And I think not. I think in general it is best to use English names if there is one. For example "Denmark" not "Danmark" and "Statue of the Little Mermaid (Copenhagen)" not "Statuen af Den Lille Havfrue (København)". You can always find cases where the name can be discussed and in these cases just leave the name the creator have chosen. --MGA73 (talk) 09:14, 24 August 2024 (UTC)

(1) The problem was the sample didn't quite match the question. If there is an actual name that can be referenced and that is in use, not a "river of january"-thing. (2) Your argument is about classes of objects, not specific objects. (3) there are casses where we don't use English names even for classes: Category:Betula pendula etc. Enhancing999 (talk) 09:23, 24 August 2024 (UTC)

•  Oppose The default language for Commons is English for good reasons, some of them well outlined by others here. The best idea, is to put alternative names, in however many languages into Wikidata. Broichmore (talk) 11:07, 24 August 2024 (UTC)
•  Oppose There are many situations where the "local language" may not reflect the majority of people talking about it. Take Category:Vatican City for instance. We could call it Category:Città del Vaticano or Category:Civitas Vaticana but the problem is that the Vatican city is a location with many international visitors and discussion. This would add a lot to confusion without adding much. We don't need to translate the name, but in more international locations this could cause major issues. Immanuelle ❤️💚💙 (please tag me) 16:38, 25 August 2024 (UTC)

Conclusions + proposals + questions

• The question is: Is it allowed to rename categories with an English name to local language names?
• Answers:
  • Local language names are OK for category names if:
    • there is no English name, or
    • there is a redirect from the local language name to the English name or
    • it meets the criteria of Commons:Categories#Category names (names for which the non-English name is most commonly used in the English language).
  • Categories with local language names are doubtful if:
    • it is not about a proper name, but about something else, like a function: Category:Taoisigh (prime ministers of Ireland) and Category:Chancellors of Germany (prime ministers of Germany) are in the rest of the world known as prime ministers. Though these local words may be well known in the UK, they are not in most of the rest of the world and they certainly do not meet the Universiality principle, which says that "Identical items should have identical names for all countries and at all levels of categorization."
    • names are hard to translate into English (then they should at least be transcribed to Latin script).
  • It is not OK if:
    • there was no CfD for (there was no CfD for this case)
    • the name is not in the language that has the most chance of being searched for (in this case that is English)
    • the name is not in Latin script.
  • Another solution is to put alternative names, in however many languages, into Wikidata.
• Category:Heroes' Cemetery in the Philippines should not have been renamed to Category:Libingan ng mga Bayani.

Proposals

1. Revert the renaming of Category:Heroes' Cemetery in the Philippines and let the local category have a redirect to the English one.
2. Try to include the conclusions of this discussion in Commons:Categories.

@B25es, Seav, Geohakkeri, Jmabel, Nakonana, Adamant1, Enhancing999, Prototyperspective, MGA73, JWilz12345, Broichmore, and Immanuelle:

• Do you agree with the conclusions?
• Do you agree with the proposals?

--JopkeB (talk) 15:29, 30 August 2024 (UTC)

I thought we don't want "River of January" type of translations (easy to do)? The question for a reference for the past name of the category seems still unanswered. We do have it for the current category name (even in the category). We do seem to agree the "Category:Cemeteries in the Philippines"-category should remain in English.
 ∞∞ Enhancing999 (talk) 15:35, 30 August 2024 (UTC)

• I think there is a big difference between "allowed" to rename and "a good idea" to rename. I understand "a good idea" as "we should" rename. I'm from Denmark and we have Category:Copenhagen and I think it should be left alone because there are more readers that know the city as Copenhagen than København. But if someone had named the category "Buy a harbour" then I would ofcourse agree that the original name was better just like I think "River of January" should be renamed.

I think both the conclusions and the proposals are fine. But I also live happily with the new name. Just don't start a mass rename of thousands and thousands of categories just to get local names. --MGA73 (talk) 16:01, 30 August 2024 (UTC)

• Both conclusions and proposals make sense.
  Some understanding has to be used regarding those of us that not being proficient enough in English ignore how to say some things in English. Some categories written the best we can will pop up.
  Also when things may have an English name but it is not widely known even among native English speakers themselves, category names may be not as perfect as desired.
  I do appreciate when categories I have created are properly Anglisized, but category redirects from other languages are of great help.
  A long term plan/idea/intention to have something like Wikidata's Qs, where somebody writes iron, my wife reads hierro, and someone in Dodoma reads chuma, would be great. B25es (talk) 17:25, 30 August 2024 (UTC)

I agree Immanuelle ❤️💚💙 (please tag me) 10:22, 5 September 2024 (UTC)

I certainly disagree with the conclusion that we should call the Chancellor of Germany the "prime minister of Germany". The term "Chancellor" dates back at least to the 1870s (and may have been used in Prussia before that, I'm not sure). It is simply the correct word in English (the German being Kanzler). The Germans do not use the word Kanzler to refer to comparable positions in other countries (e.g. they would not refer to the Prime Minister of the UK as a Kanzler, they would use Premierminister. It is simply not the same title, even if the role is similar. - 19:11, 30 August 2024 (UTC) — Preceding unsigned comment added by Jmabel (talk • contribs) ‎‎ (UTC)

Maybe chancellor would be an appropriate term for historical figures who traditionally called that, but I don't anyone outside of Germany uses the term these days. Like I know Hitler was called a Chancellor in Germany during World War 2 but if I do a search for him Google there's plenty of sources, including Google's information panel that calls him a Prime Minister. But then conversely the Wikipedia article for the role is called "Chancellor of Germany." So...There should be some standard and at least IMO Prime Minister makes more sense for our purposes if for no other reason then universality. I don't think it would make sense or work if he had diifferent terms for political appointees based purely what they are called locally regardless of if there's a universally recognized term for the role or not. Categories mainly (if not completely) exist as a way to organize images and naming them based on universality is clearly the best to do that regardless of if its 100% acccurate in every single instance. --Adamant1 (talk) 20:41, 30 August 2024 (UTC)

"Chancellor Angela Merkel" (in quotes) gets 1,880,000 Google hits. "Prime Minister Angela Merkel" gets a mere 5,940. Rather more recent than Adolph Hitler (also held the office rather longer), I'd say a 30:1 ratio suggests that the term is quite current. And since both "Chancellor" and "Prime minister" are specifically English-language, this should be specific to English. - Jmabel ! talk 21:59, 30 August 2024 (UTC)

@Jmabel: With Hitler it's 60,600 results for "Chancellor Hitler" versus 6,550,000 for "Prime Minister Hitler" and as I've already said that's even with him being called Chancellor in Germany at the time. So it clearly depends. You'd have to agree it would be pointless to argue about which term should be used used based on who the particular head of state was at the time. "Well, my German head of state has 6 million results on Google for Chancellor and yours only has 60 thousand for Prime Minister. So clearly the category should be named 'Chancellor'!" Not to say you'd do that, but I do think it's a case where it would just be better to go with the university principle instead of trying to determine how to name the category based on a game of one upmanship over who's favorite term for a head of state gets more results on Google Search. --Adamant1 (talk) 22:47, 30 August 2024 (UTC)

@Adamant1: I'm pretty sure you didn't use the quotation marks in doing that Google search. Obviously, Hitler would often be mentioned on the same page as some prime minister. But with quotation marks I get and 59,700 for "Chancellor Hitler" and only 9,440 for "prime minister Hitler", and even the latter include some more-or-less false positives: right near the top I see things like, "To the British Prime Minister, Hitler complained…" or "On May 13, 1940, Churchill gave his first speech as. Prime Minister. Hitler invaded France…" - Jmabel ! talk 23:23, 30 August 2024 (UTC)

@Jmabel: Weird. I thought I had. It looks like I probably left out the leading quotation mark though. My bad. --Adamant1 (talk) 23:26, 30 August 2024 (UTC)

(Reaction to the disagreement of Jmabel, 19:11, 30 August 2024) The point is not "that we should call the Chancellor of Germany the "prime minister of Germany""; of coarse you may call anyone the way you or the other person likes it. Nor whether what has more hits in Google or any other search machine. The point is: how do we name (sub)categories in a structural and consistent way. The real question here may be: What is more important: the consistancy of the category structure (like the Universality principle prescribes) or the titles of the prime ministers of Germany and Ireland? And if you choose the latter: what other exceptions exist to the Universality principle? --JopkeB (talk) 09:12, 9 September 2024 (UTC)

@JopkeB: as long as there are appropriate redirects and appropriate descriptions on the category page, ultimately I can deal with it. In the specific case of German chancellors, though, perhaps then we want a generic Category:Prime ministers of Germany that exists only to be a parent category of Category:Chancellors of Germany, much as Category:Monarchs of France includes (directly) the Kings of France and has subcategories for the emperors, the monarchs of areas within present-day France, etc.? - Jmabel ! talk 06:20, 10 September 2024 (UTC)

@Jmabel: I would like that Category:Chancellors of Germany only has a redirect to Category:Prime ministers of Germany and that the latter becomes the main category. Only then the Universality principle principle will be done justice. The current subcategories of Category:Prime ministers of Germany should get a parent like Category:Prime ministers of states of Germany. JopkeB (talk) 04:27, 11 September 2024 (UTC)

Wouldn't it be better the other way around? Have Category:Prime ministers of Germany redirect to Category:Chancellors of Germany? The former category, to ensure that templates and categories like "Prime ministers of Europe" will work, and the latter, for the actual name. Nakonana (talk) 15:14, 11 September 2024 (UTC)

If we are insisting that we use strict English for the cemetery in question (despite the Tagalog name being extensively used in English sources [see above]), then there is still the question of which English translation should be used. Should it be the original "Heroes' Cemetery", or "Cemetery of Heroes" or "Cemetery of the Heroes"? All three are acceptable English translations of the official name, but I prefer any of the two latter names as these more closely resemble the official name (this is like preferring "River of January" instead of "January River" for Rio de Janeiro). As for disambiguation, do we append "in the Philippines" as with the original category name, or use a parenthetical "(Philippines)" which seems to be the convention? —seav (talk) 22:32, 30 August 2024 (UTC)

At least in regards to the first part of your message, probably the best way forward at this point would be to revert the edit that changed the name and then someone can open a CfD to figure out what the best option is from there. It's pretty clear from this that the name shouldn't have been changed without there being a CfD first though and at least IMO figuring out what is to go with instead is probably out of scope of this conversation. --Adamant1 (talk) 22:55, 30 August 2024 (UTC)

I agree with Adamant1 about reverting. And, @seav, I intended "River of January" as a reductio ad absurdum, not a serious proposal. In English, the city in question is universally called either "Rio de Janeiro" or just "Rio". This is never turned into English words. - Jmabel ! talk 23:29, 30 August 2024 (UTC)

Yes, I know that "River of January" wasn't a serious suggestion, but I simply used it as an example of which of several possible English translations ought to be used if we are translating a name. — seav (talk) 00:39, 31 August 2024 (UTC)

I don't think anybody tried to do a literal translation of "Rio do J.", but occasionally I come across similar ones, where it's likely that Commons is the sole source for that name. I could name one or the other, but I don't want to embarrass the user who did try to do so. If you find a bad translation of mine, feel free to cite is as a negative example.

Obviously, I don't think there is an issue to provide a literal translations in the description.

For the cemetery, I agree we should have a proper discussion on CfD, especially as the previous name was the result of one.
 ∞∞ Enhancing999 (talk) 11:51, 31 August 2024 (UTC)

In the UK, the German prime minister is always referred to as the chancellor, as is his Irish equivalent the Taoiseach. Broichmore (talk) 13:18, 31 August 2024 (UTC)

In passing, I've just looked at Category:General Wali Kothi, who would believe this is actually a building aka Star house, Tara Khothe, Tara Khothee, andd Lucknow Observatory. There will be other names and spellings too. Never mind the Hindi variants, and counting. You can bet your bottom dollar, that the locals call it Star House, or the old Observatory, terms not officially used since 1947.

Almost every Indian category suffers from the same malaise, and exemplify reasons why, English is the standard here. Broichmore (talk) 13:26, 31 August 2024 (UTC)

•  Comment, personally, I think that the solution is really simple, we need to reform the way category redirects and title displays work on a technical level. We simply change Wikidata's notability guidelines to include any and all Wikimedia Commons categories, then integrate each and every Commonswiki category with Structured Data on Wikimedia Commons (SDC), then have a robot automatically create redirects based on alternative names in different languages based on what is listed in Wikidata, then make title display names based on the settings of the viewer. Congratulations, now the Wikimedia Commons is truly a multilingual project rather than an Anglocentric one.

How do we prevent vandals from deliberately adding wrong terms and / or insulting words and phrases in translations? Simple, we limit who can add these translations, it's a special but very easily acquired new right at Wikidata that any administrator could bestow upon someone based on either a local (at Wikidata) or Commonswiki endorsement.

How do we integrate this at every level? Simply upgrade the MediaWiki Upload Wizard to properly integrate category redirects like Cat-a-lot already does, this way redirects become useful and someone can theoretically only ever contribute using French or Japanese without ever seeing a single word in English and not even notice that the Wikimedia Commons is in a language that they don't understand.

These changes would solve a lot of issues overnight, all we need is for Wikidata to slightly adjust its notability guidelines (something user "Mike Peel" and I have been advocating for for years), then the rest can be 90% (ninety percent) done by robots, and humans can simply do quality checks and focus on more important things like finding educational content and checking if that educational content is licensed in a free way. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 07:40, 5 September 2024 (UTC)

This is probably a hot take but I've been a fan of how people use redirects for essentially everything on here. There's a point where it just kind of defeats their purpose and usefulness if everything is redirected multiple times and with multiple different variations of the word, concept, or whatever. Like create a redirect for something that clearly needs one, but do we really need redirects for every random misspelling of a name or redirects for every name in every niche language on the planet? Probably not. --Adamant1 (talk) 07:58, 5 September 2024 (UTC)

Every misspelling rather not, but "reasonable" alternative yes. That would definitely solve most category issues with "Lenin Street", "Lenina Street", "Ulitsa Lenina" and "улица Ленина". Wikidata entries don't usually have all that many alternative spellings listed. Even if we would just use an English category name and one native language name for a category, that would already help a lot. Nakonana (talk) 18:47, 5 September 2024 (UTC)

Insofar as additional spellings are valid, adding them to Wikidata is helpful all around. - Jmabel ! talk 18:55, 5 September 2024 (UTC)

Where do I sign? Nakonana (talk) 18:48, 5 September 2024 (UTC)

Donald Trung: That looks like a fine solution and proposal. Would you please add it to the Community Wishlist? JopkeB (talk) 08:48, 9 September 2024 (UTC)

Overall conclusions

We agree on:

1. The renaming of Category:Heroes' Cemetery in the Philippines to Category:Libingan ng mga Bayani should be reverted.  Action JopkeB  Done
2. After the reverting, whoever wants a different name for this category can start a CfD (discussion).
3. (For future cases:) Whoever wants to rename an English category name to a local name should start a CfD before the renaming.
4. The proposal of Donald Trung to solve the problem with category names in different languages with a technical solution, like in Wikidata.  Action Donald Trung (to bring it to the Community Wishlist)

We do not agree on: Whether it is allowed to have exceptions to the Universality principle, for example: Should category names of the German and Irish prime ministers (now in German and Irish) be renamed to the general (English) name for categories about prime ministers? I suggest to move this discussion to Commons talk:Categories. If you agree:  Action (perhaps Jmabel?)
--JopkeB (talk) 09:44, 9 September 2024 (UTC)

Why should we start a category discussion to fix "River of January" problems?
 ∞∞ Enhancing999 (talk) 09:55, 9 September 2024 (UTC)

Because there are cases that might be obvious for you and some others, but not for everyone. JopkeB (talk) 10:18, 9 September 2024 (UTC)

Well, that's just your POV. I think everybody agreed we shouldn't have "River of January".
 ∞∞ Enhancing999 (talk) 10:20, 9 September 2024 (UTC)

Started the discussion now for "Cristo Redentor" (which the English world has a fitting name: "Statue of Christ the Redeemer"). Commons:Categories for discussion/2024/09/Category:Cristo Redentor (Rio de Janeiro). JWilz12345 (Talk|Contrib's.) 11:20, 9 September 2024 (UTC)

I would differentiate between category names for object classes and for individual objects. Class names, descriptive names and categories for universal concepts should always be in English. Category names for specific things (persons, official titles, places, institutions, etc.), on the other hand, should be permitted in the local language. There may be exceptions where the English names are well established and immediately understood in the language area concerned, but as a rule, arbitrary translations bring few advantages for international users and significant disadvantages not only for local users: For example, unambiguity is often lost in the case of political parties or parliamentary names; in the case of buildings the alphabetical sorting may change; in the case of squares, streets or churches, the assignment in the city map becomes a guessing game. And the systematic information is provided in English by the parent categories anyway, so this does not need to be repeated in the individual object category. Rudolph Buch (talk) 16:27, 9 September 2024 (UTC)

August 27

Massive backlogs are now the norm

Looking at Commons:Deletion requests, there are currently nearly three thousand deletion discussions that are past due for closure. Commons is teetering on being a failed project due in part to the lack of administrators. There simply is too much work for the available pool of administrators. This problem isn't getting better. It's getting worse.

So, why are we allowing new uploads to the project from anyone which just exacerbates this problem? The status quo is failing. --Hammersoft (talk) 14:03, 27 August 2024 (UTC)

Category:Items with disputed copyright information is another example of backlogs. And it's hard to tell how well new uploads are reviewed. --EugeneZelenko (talk) 15:14, 27 August 2024 (UTC)

This is a real problem. Aside from more administrators, what do you propose? What should be done to limit bad uploads (for copyrights or other reasons)? JopkeB (talk) 15:37, 27 August 2024 (UTC)

Maybe more agressive and pro-active use of CheckUser? Trade (talk) 17:18, 27 August 2024 (UTC)

I forgot where I read it, but I think CheckUser has to be extremely rare because of the nature of the thing. --Adamant1 (talk) 18:03, 27 August 2024 (UTC)

Then almost every other Wikiproject should have the same high rejection rate. Except they dont. Its just Commons Trade (talk) 20:44, 27 August 2024 (UTC)

I haven't participated in Wikipedia for at least a few years but from what I remember they have pretty high standards to. But then they also have way more users and bad actors because of that. Plus it's just seems easier to come up with evidence of socking on there. So it just makes sense that they would have a higher CheckUser rate. I know from my own experience that there's been at least a couple of times where I wanted to file a CheckUser report on here but ended up not doing one because there just wasn't enough of a paper trail in both cases to justify it. I feel like there probably would have been if it had happened on Wikipedia either time though. --Adamant1 (talk) 20:50, 27 August 2024 (UTC)

The larger Wikipedia projects are in my experience much more strict in almost all areas compared to Commons. ReneeWrites (talk) 18:12, 3 September 2024 (UTC)

There's been at least a couple of discussions lately about expanding and/or improving the criteria for speedy deletion. It seemed like none of them went anywhere at the time, but I think that would a lot with the backlog. As would making it easier for people to nominate images for speedy deletion to begin. As I guess its not an option on the side panel right now outside of clear copyright violations when it really should be. We could also use more admins, but I the standards are currently to high and I doubt they would work in that area anyway. Really you could argue current admins not dealing with deletion request is as much of or more of an issue then us just not having enough of them. There's no point in having more admins if they aren't going to work in the areas where they are most needed to begin with though. --Adamant1 (talk) 15:54, 27 August 2024 (UTC)

The backlog was much lager some month ago. If we need an urgent action we should block IP edits to prevent their spam and get time to work on deletion requests. GPSLeo (talk) 15:56, 27 August 2024 (UTC)

I had thought about that but it doesn't seem like there's any support to block IP edits on here. I totally agree that they should be blocked though. IP editors are a massive time suck in general. --Adamant1 (talk) 16:23, 27 August 2024 (UTC)

How exactly is blocking IP's supposed to help in any way? The issue is with people uploading copyvio. IP's obviously cannot upload anything in the first place Trade (talk) 17:16, 27 August 2024 (UTC)

But if we need 6 admin hours per day to check and clean up IP edits we can not use these 6 hours to handle deletion requests. It is simply a question of admin time availability. GPSLeo (talk) 17:50, 27 August 2024 (UTC)

Aside from what GPSLeo says I work in the area a lot and IP editors tend to either create a lot of meritless deletion requests or troll DR discussions. Obviously it would be a lot easier to deal with the back log if there weren't as many clearly pointless deletion requests being created to begin with. --Adamant1 (talk) 17:53, 27 August 2024 (UTC)

It's a bit odd for random IPs new to Commons to be so familiar with the DR procedure Trade (talk) 20:46, 27 August 2024 (UTC)

Most of the time their comments amount to something along the lines of "not own work?" Otherwise I'd agree with you. There are some times where there's clearly socking involved or the IP editor is probably a previously blocked user though. Both of which is all the more reason to block them IMO. It's purely conjecture on my part, but I highly doubt most IP editors on here are participating in the project that way for legitimate reasons. --Adamant1 (talk) 21:13, 27 August 2024 (UTC)

Agree with Adamant1. I also see too often violation and other non-constructive contributions by IP adresses, also in discussions. It takes a lot of time to fix them. Why do IP's have nearly the same rights on Commons as accounts have? My proposal: Restrict their rights. They should just be allowed to read things on Commons and have no possibility for violation. They are already excluded from uploading, why not from editing as well? If they want to start or join discussions, nominate files for deletion and so on, then they should use an account, like the rest of us. JopkeB (talk) 06:36, 28 August 2024 (UTC)

The deletion requests would be much easier to close if more people participated. Trade (talk) 17:19, 27 August 2024 (UTC)

Less than 3.000? Good job then, just a few years ago it used to be over 6.000. --Rosenzweig τ 15:59, 27 August 2024 (UTC)

3000 sounds like what @Yann does in a blink. ;) Thanks btw.
 ∞∞ Enhancing999 (talk) 20:48, 27 August 2024 (UTC)

Is the problem really getting worse? As in, are the various backlogs growing faster than they're shrinking? This argument came up on enwiki with regard to unsourced articles recently and it turns out that though there are an enormous number of those, they are being taken care of faster than new ones are being created.

I suspect something similar is going on here, especially since there is over a decade's worth of files to go through. To use another backlog as a comparison point, there are roughly 128,000 uncategorized files uploaded in 2024. Which is bad, but more than 128,000 files have been removed from the uncategorized backlog from 2021 and 2023 alone. Gnomingstuff (talk) 00:24, 28 August 2024 (UTC)

" Commons is teetering on being a failed project" if backlogs mean a project is teetering on the edge of failure, the virtually all Wikimedia projects have been teetering on the edge of failure since their inception. Yes, it would be good to do better. No, this is not a crisis, let alone a death knell.

• I opened this CFD 1,983 days ago. Just sayin'. Just Step Sideways (talk) 19:45, 27 August 2024 (UTC)

Do not forget you need a native English speaker who is at the same time a railway fan (not necessarily a railway expert, but has knowledge above the average) to close this discussion. I just looked at it and I can not close it. I can not say a difference between "close" and "closed" in this case. Ymblanter (talk) 21:02, 27 August 2024 (UTC)

More admins would help, the issue is really active admins. Among the 183 admins, only 129 have done any admin action during the last month, and only 64 have done more than 20 admin actions during the same period. Yann (talk) 21:10, 27 August 2024 (UTC)

A CFD is not a Deletion request, so I think it is out of scope of this discussion. CFD's cannot be closed just by administrators, but every experienced editor can do so. JopkeB (talk) 06:07, 28 August 2024 (UTC)

When deletion discussions remain open essentially forever, when backlogs remain in the thousands across a number of types, when copyright violations are allowed to sit on the project indefinitely, then yes I would call this a failed project. We are not able to effectively police ourselves, and the incoming level of problematic files overwhelms existing ability to deal with it. --Hammersoft (talk) 17:36, 1 September 2024 (UTC)

maybe you can become a com:sysop and help? would you accept a nomination? RZuo (talk) 18:55, 1 September 2024 (UTC)

Frankly, I'm not active enough. I've seen various requests here, and noted concerns about activity levels. I doubt I'd meet expectations. Regardless, adding another administrator to the mix, especially at my activity levels, isn't going to help. I have other reasons as well, but this is really getting out of the scope of this discussion. --Hammersoft (talk) 19:18, 1 September 2024 (UTC)

I don't think we're teetering on anything, but we should all be able to agree the backlog is too big. Here's another reason it exists: DRs are often hard. Most admins aren't IP lawyers in one country, let alone every country, and there are a lot of really rough calls. Scope-based and people-based debates are also often hotly contested and difficult to assess. Beyond that, AfD on enwp is contentious and results in a lot of grief for closers, especially from newer users who don't understand the process. On commons, even many of the experienced users (or experienced users from other projects) routinely misunderstand the basics and make life sadder for commons admins. Back to the main point, however, there are definitely a lot of DRs that aren't that complicated which wait a long time to be closed, too, so more admins would help, at least. — Rhododendrites ^talk |  17:59, 1 September 2024 (UTC)

The same thing applies to CfDs. It just took me 2 days to deal with 4 of them because they all involved moving thousands of files and deleting hundreds of categories. Then there's ones that are extremely simple and can be closed in a couple of minutes. But its near impossible to deal with the later to any meaningful degree because of the time it takes deal with the former. Then there's a bunch that are clearly just complex to deal with for whatever reason. But its such a big mishmosh. Anyway, these things don't really scale. For them to be managable you'd need to have everyone on here participate and inforce clear time limits on how long the discussions can be open for. As well as cnsistantly keep the back logs down to a week or two. Otherwise its just going to be an unworkable mess. Its hard to say something should be closed a certain way after a week or two when it has a low turn out and an unclear outcome though. Sometimes it takes years just for someone to comment. So I don't know. There really is no single, easy solution. --Adamant1 (talk) 20:46, 1 September 2024 (UTC)

Just adding an example to go with my "DRs are often hard" comment above. I started looking through the oldest DRs and saw Commons:Deletion requests/Files in public domain featuring various Indian film artists post-1945. Taking action on that DR would involve a few dozen images and an understanding not just Indian copyright or US copyright but the interplay between the two. Even if we get more admins, the number of people who would feel confident weighing in on something like that are very few. Let's not have a discussion here about the correct outcome, though -- I'm just highlighting that these are hard, and while the act of closing a discussion may not take much time, attaining the level of understanding required to parse such a case would be very time consuming. It's no wonder nobody wants to do it. I wonder if there's a potential project for the WMF to undertake that would effectively create charts like COM:HIRTLE for media published outside the US and uploaded to Commons. Maybe even an interactive tool. — Rhododendrites ^talk |  20:56, 1 September 2024 (UTC)

I think for reusers and uploaders the open request signals there is a complex issue. Highly problematic uploads get nuked within hours.
 ∞∞ Enhancing999 (talk) 22:15, 1 September 2024 (UTC)

• I'll again bring up my suggestion that first uploads by new users should not be publicly visible until reviewed. -- Infrogmation of New Orleans (talk) 02:26, 9 September 2024 (UTC)
  • Maybe, but wouldn't that create a different kind of backlog? — Rhododendrites ^talk |  12:29, 12 September 2024 (UTC)

August 28

Uncategorized categories, except infobox

Report Special:UncategorizedCategories provides additional information to Special:UncategorizedCategories. Ideally it would be updated daily. Regular updates seem to make it easier to maintain it.

Report UncategorizedCategories with infobox has categories that don't appear there as they are in Category:Uses_of_Wikidata_Infobox_with_no_item, meaning, there is only an empty {{Wikidata Infobox}} on the category, but no other parent categories. Eventually the two reports might be merged.

For both Intro Special:UncategorizedCategories lists ways to take care of these categories.
 ∞∞ Enhancing999 (talk) 11:28, 28 August 2024 (UTC)

Awesome! This is very useful. It implements one part of the two I requested here. Could you also create a report for categories with only redcategories? Then all categories practically without categorization would show up on some report. A next step thereafter I think would be to have some bot identify cats missing cats and making e.g. Suggested Edits category suggestions, for example using data of the corresponding WP article in a way that makes these suggestions constructive. Such bots would be especially useful for experienced users adding categories to the categories on these reports and greatly reduce the time required for that and the backlog size.

Some change proposals:

• could you rename "top users" to something like "users creating most uncategorized categories"? (this feature also ties in somewhat with the gamification-like feedback mechanisms discussed here)
• it would be good to link to these reports from here and other places where Special:UncategorizedCategories is linked from
• it would be good to link to these reports from Special:UncategorizedCategories itself

Prototyperspective (talk) 12:46, 28 August 2024 (UTC)

Thanks for the input. Feel free to link the reports from places you think it's useful. I made an edit request to add it to Special:UncategorizedCategories at MediaWiki talk:Uncategorizedcategories-summary.

For actual implementation of additional reports, you might want to use Commons:Bots/Work_requests. Special:WantedCategories exists and seems to be long (5000 categories wanted 14 and more times). It also has the advantage that it gets updated when a category is created.

Maybe Category:Pages with coordinates also includes categories that aren't categorized otherwise. Possibly a few other categories are similarly suboptimal.
 ∞∞ Enhancing999 (talk) 13:01, 28 August 2024 (UTC)

Briefly, as for Special:WantedCategories those only show the redcats but not categories with only redcats. This is very different and doesn't really address the same problem but if it did then in a very different way. For example, many of these cats only have a nonexisting category that is used only once (namely in that category) while this shows the top XYZ by number of use and currently only shows categories with at least 14 items. Prototyperspective (talk) 13:14, 28 August 2024 (UTC)

Oh, something like this (except that 4 of 13 exist).
 ∞∞ Enhancing999 (talk) 13:21, 28 August 2024 (UTC)

That's a separate subject and not necessarily a problem. Prototyperspective (talk) 13:24, 28 August 2024 (UTC)

If it's something else, do you have a sample?
 ∞∞ Enhancing999 (talk) 13:26, 28 August 2024 (UTC)

It's categories that have nothing but nonexisting categories. I don't have an example now but could add one if I find one but I'd suggest simply categorizing a category missing categories in such a way for a test-case. There's many of these. Also note that categories having nothing but nonexisting categories and Wikidata infobox meta categories should also show up in some report. The two examples I listed here (this and this) apparently are not included in your report so I think it still needs further work so it also includes these. Prototyperspective (talk) 13:34, 28 August 2024 (UTC)

Oh, it seems with "nonexisting categories" you mean categories that have the "hidden category" attribute set (visible on the second line). Generally all categories that are not topical categories. Category:Sinauli has four such categories (Uses of Wikidata Infobox, Uses of Wikidata Infobox with no image, Uses of Wikidata Infobox with maps, Pages with coordinates). The infobox sets 3 of them, MediaWiki the last one.
 ∞∞ Enhancing999 (talk) 13:40, 28 August 2024 (UTC)

No I don't!
The categories it has are all just meta categories set by the Wikidata Infobox and I thought that's what your report is about. Prototyperspective (talk) 13:43, 28 August 2024 (UTC)

The second report is about empty infoboxes only.
 ∞∞ Enhancing999 (talk) 13:47, 28 August 2024 (UTC)

Thanks for the info, all the samples I looked at didn't have any normal categories so can this report also be used for that and if not the title of the report is flawed and doesn't match what the report is about. It could be named "Report UncategorizedCategories with empty infobox" but I'd suggest changing it so it also shows items with non-empty infoboxes or creating and additional report "Report UncategorizedCategories with non-empty infobox". Prototyperspective (talk) 13:54, 28 August 2024 (UTC)

The intro defines the exact scope. For your request, maybe the infobox itself can determine if there are any other categories available. It's conceivable that a category with an infobox is correctly only in "hidden cats", so checking those isn't sufficient.
 ∞∞ Enhancing999 (talk) 14:00, 28 August 2024 (UTC)

What do you mean with "isn't sufficient"? There simply are many cases like the two examples that are practically without categories / missing categories but don't show up in reports because they have a few meta-categories set by the Wikidata Infobox. If there are cases where this is fine these are very rare and one could think about what to there once there are some examples of that where one can see how such can occur and maybe how they could be excluded from the report. The infobox itself can't determine that, it can at most add or suggest a few more categories but that's basically a separate subject and doesn't solve anything. Prototyperspective (talk) 22:37, 28 August 2024 (UTC)

BTW the "last user who edited the category" may not be the one who created it. Also, for the second report, it may have been disconnected from Wikidata since the last edit.

The default sort is by page_id, meaning newer categories appear first. The categories can be sorted by last edit date.
 ∞∞ Enhancing999 (talk) 13:14, 28 August 2024 (UTC)

I'd say that the report is quite useful. Few (if any) false positives, so pretty much anything that shows up there needs some work. - Jmabel ! talk 18:48, 29 August 2024 (UTC)

Thanks. Updates are a bit complicated as infoboxes don't necessarily update when a category is connected to an item.

Commons:Report Special:UncategorizedCategories is now down to reasonable length (469 categories):

• only 52 categories with 10 files or more (cat_size>9)
• only recent empty categories (cat_size=0)
• most users with many creations on the list have been made aware of the issue

∞∞ Enhancing999 (talk) 10:03, 31 August 2024 (UTC)

Special:UncategorizedCategories is now at 8, including 5 categories that can be deleted once all files in it are (likely) deleted. Interestingly, it gets new entries every day. either by people who omit parent categories, people who don't know how to request speedy deletion or people who create categories that need (English) descriptions to be of any use to a more general public.

Commons:Report_UncategorizedCategories_with_infobox has progressed as well. Few larger categories (cat size >9) remainin, all empty ones cleared.
 ∞∞ Enhancing999 (talk) 11:33, 7 September 2024 (UTC)

Good news: Commons:Report_UncategorizedCategories_with_infobox approaches 150.
 ∞∞ Enhancing999 (talk) 21:01, 11 September 2024 (UTC)

It's now shorter than the other list 80 (compared to 90)! Eventually, I will try to merge the two lists.
 ∞∞ Enhancing999 (talk) 18:47, 12 September 2024 (UTC)

August 29

Category descriptions

I'd like to establish some community consensus on what constitutes an appropriate amount/use of category descriptions. Categories that have to do with North Brabant often have large, self-referential descriptions with all manner of interwiki linking and use of external linkage that is not appropriate, for example Category:Geertruidenberg or Category:Heusden, North Brabant, or any of the places linked in the template above. Compare that to famous cities like Category:London or Category:Chicago, which have minimal descriptions by comparison.

Then there's subcategories. Category:Van Goghkerkje mentions it's at the Vincent van Goghplein 1, 4881 DG Zundert in the municipality of Zundert in the province of North Brabant in the south of the Netherlands. This information is then repeated in almost every single subcategory, including the metacat Category:Van Goghkerkje by year.

Category:Streets in Geertruidenberg mentions in the category description that this subcategory is for pictures of streets in the municipality Geertruidenberg in the province of North Brabant in the south of in the Netherlands. Category:Nature of Bergen op Zoom mentions in the category description that this subcategory is for pictures of nature and nature reserves in and around Bergen op Zoom in the province of North Brabant in the south of in the Netherlands. The category Category:Geography of Moerdijk mentions in the category description that this subcategory is for pictures of the geography in de gemeente Moerdijk in the province of North Brabant in the south of in the Netherlands.

Thousands of categories are like this, almost exclusively those in North Brabant. I'd like to start cleaning these up, but before I do I want to establish community consensus on where the line is drawn when something turns excessive so I know what to trim and what to keep.

My opinion is this:

• No repeating of information that can be found in the category name ("The category "Streets of Geertruidenberg" is for pictures of streets of the municipality of Geertruidenberg...")
• No repeating of information that can be found in an infobox
• No repeating of information that can be found in a parent category
• No external linking to personal websites, or other sites that would not be considered reliable sources on other Wikiprojects

ReneeWrites (talk) 07:36, 29 August 2024 (UTC)

I guess most categories where the description would be relevant have {{Wikidata Infobox}}, which has all necessary information. Ymblanter (talk) 09:11, 29 August 2024 (UTC)

Maybe we miss something, but both Category:London and Category:Chicago currently have tons of category description, most can be found elsewhere, compared to Category:Van Goghkerkje. The later mentions an essential point that seems odd to mention without including a basic description before including stating the category name in the description itself.

Not sure how Category:Geography of Moerdijk can be compared negatively to Category:Chicago except when there is some bias involved. Stating the topic in local language(s) is fairly important.

Category:Chicago seems relatively bad as it has a large seal image in the center. It mentions "largest city in Illinois," which is marginally helpful.

A nice thing about Category:London is that it has that collapsed list that helps sorting. I find such Commons specific pointers fairly important.
 ∞∞ Enhancing999 (talk) 12:02, 29 August 2024 (UTC)

I was comparing the categories of Geertruidenberg and Heusden with those of London and Chicago, the latter of which have very succinct descriptions. London's is just one line of text. This is not about the navigation templates.

My critique of Category:Van Goghkerkje is that this information is repeated in most subcategories like Category:Van Goghkerkje by year and Category:Van Goghkerkje in 1969, etc.

And I was not comparing Category:Geography of Moerdijk to any of the above categories. I was making a stand-alone critique (that applies to Category:Streets in Geertruidenberg and others) that the category description just says what's in the category name, and that this is superfluous. ReneeWrites (talk) 12:26, 29 August 2024 (UTC)

Sorry about that then. Contentwise Category:Geertruidenberg or Category:Heusden, North Brabant don't compare that badly, though I don't think there should be two descriptions in Dutch and English.

If there are Wikipedia articles on the topic, references would generally not be needed. There was some discussion about this at Commons:Categories_for_discussion/2024/07/Category:Harp_Guitar_Form_3a.

The repetition at Category:Van Goghkerkje by year seems suboptimal, but that applies to the entire "by year" tree as well.
 ∞∞ Enhancing999 (talk) 12:52, 29 August 2024 (UTC)

There seem to be two types of descriptions (maybe one more popular than others), for a sample Category: "ABC":

• 1. "ABC" is a ..
• 2. This category is about media/photos/images related to/about "ABC", a ..

Personally, I prefer (1.), but 2. is not uncommon.

Content-wise, there are three types of descriptions about "ABC":

• 1. no description
• 2. Just repeat the title literally ("ABC")
• 3. State something about ABC

Personally, I prefer 1 or 3.
 ∞∞ Enhancing999 (talk) 12:38, 29 August 2024 (UTC)

I agree with Ymblanter, wikidata supplies this info.

In the case, of all things North Brabant wikidata may be insufficient. I more than suspect, what you have here is an editor set in their ways since 2008, who finds Wikidata impenetrable, or even superfluous and persists without it. The cats are cluttered, I agree, and few (if any), will use these links. However, there’s no harm done here.

After all, this is supposed to be a project that anyone can edit.

I've beaten this drum about over complication, before, and I contribute to Wikidata (4000 edits), and it falls on deaf ears.

There's too much of high tech people here, making subject matter complicated and difficult to edit. I'm still waiting for Category:Gartenlaube (Magazine)'s open architecture to be restored. All new uploads there, are incompatible with the established closed off format.

Even today I discovered a source template for a major library that is no longer viable, because the library changed its catalog system rendering our source template into a link to an enormous pile of link rot. I fail to understand how people, make templates or such, then not put in place the mechanisms for continuous maintenance, or just walk away from them. Broichmore (talk) 13:21, 29 August 2024 (UTC)

I think I disagree with some premises here. Respectively, to the bullet list of opinions given by User:ReneeWrites:

1. Don't forget the multilingual aspect of this. Repeating the category name in other languages can be very useful.
2. I get what you say about the infobox, but sometimes a tight piece of prose is easier to skim quickly.
3. Not everyone will be navigating down the hierarchy. I think it would be ridiculous, for example, for someone navigating up from a village to have to navigate many, many layers up the hierarchy to find out what country it is in.
4. I could perfectly well accept the last point, with one possible exception: on topics where there is a serious limitation on commercially available material, it can be useful to have a link to a trove of NC content on (for example) Flickr. Not sure whether that is even an exception, maybe more of a clarification.

I'd also add: I think somewhat longer than usual descriptions are often useful for topics not likely to get a Wikipedia article. Example: Category:Court in the Square.

Further: the main problem with the subcats of Category:Van Goghkerkje is that there are this big batch of "by year" categories, mostly with one or two photos, and with little or no differences from year to year to suggest that is a useful way to subcat this. - Jmabel ! talk 14:03, 29 August 2024 (UTC)

Re. "the multilingual aspect" - surely that should be handled by Wikidata? Wikidata already has extensive support for multilingual desriptions of entities, and those descriptions should get pulled in by the Wikidata infobox. Writing those descriptions locally on Commons shouldn't be necessary. Omphalographer (talk) 19:16, 29 August 2024 (UTC)

Maybe you could explain how it should be happening for the samples where Renee writes that [Dutch] is super-flous.
 ∞∞ Enhancing999 (talk) 19:25, 29 August 2024 (UTC)

Regarding 4, I think this is a good point and a good way to add nuance to the topic. I'm not against removing all external links, though I didn't really clarify what I meant with "personal websites", and I think the exception you mention is reasonable. The website in particular I was thinking of was https://breda-en-omgeving.nl/ which you can find linked numerous times in the categories above (6 times in Geertruidenberg, 7 times in Heusden, as well as many other categories linked in the navigation template at the top). I'll also ping @Prototyperspective: because this is relevant to a thread below. ReneeWrites (talk) 11:45, 30 August 2024 (UTC)

•  Support ReneeWrites opinion about it. Although I think Jmabel makes some good points, but I don't see them as mutually exclusive or applicable in every situation. Just to give an example from Jmabel's comment, don't forget the multilingual aspect of this, I'd say it depends on the topic of the category and what level down it is. For instance if we're talking about shoes and the person is browsing through Category:Shoes to find images of them then I don't think it's necessary or helpful to have the word "shoes" translated into every single language possible just because this is a multilingual project or whatever. It's a pretty good bet that most users know what a shoe looks like and has heard the word in English before. So there's zero reason to translate it or to have a description, in English or any other language. "Shoes are things you wear on your feet." No really? We don't need that in English, let alone 10 other languages.

Maybe you'll say that's a bad example since the category for shoes doesn't have a description to begin with though. But there's plenty of categories for extremely obvious universally known subjects out there that have totally pointless descriptions in multiple languages. So essentially I agree with ReneeWrites opinion about it. Although I think Jmabel makes a few good points, but multilingual thing shouldn't be a free pass to create descriptions that are otherwise totally pointless for whatever reason. --Adamant1 (talk) 17:22, 29 August 2024 (UTC)

@Adamant1: Again, though, you are assuming they got there by following the category tree from a more abstract category. They could just as easily have arrived from a category on an individual photo. - Jmabel ! talk 18:51, 29 August 2024 (UTC)

@Jmabel: Sure, but if someone gets to Category:Shoes from an individual photo of something that's not a shoe then there's other problems involved that categories having descriptions or not has nothing to do with. The only way to deal with people confused about where they are in the category structure at any given time is to categorize images properly. You can't make up for or fix that by putting "chaussure" at the top of a category. --Adamant1 (talk) 18:59, 29 August 2024 (UTC)

@Adamant1: "other problems involved" Well, yes. And if they are, for example, a Chinese-speaking editor, it would be useful if they don't have to to running way up the category hierarchy to work out that it was an error.

Some of this can be solved if there is a corresponding Wikidata item, but the more narrow the category, the less likely to have a Wikidata item, so the more important mere translation of the category name may be. - Jmabel ! talk 19:53, 29 August 2024 (UTC)

@Jmabel: I don't even disagree with that, which is why the used an extremely general topic like shoes as an exmple. It's certainly a different thing altogether the further down in the categories some goes. I'm not sure what the solution to that is but I still think ReneeWrites' proposal still makes sense with broader topics. Maybe there could be a cavit to it about how to handle categories for more obscure topics though. --Adamant1 (talk) 20:00, 29 August 2024 (UTC)

•  Support what ReneeWrites wrote. In the vast majority of cases, categories either have a Wikidata infobox that makes the subject clear (and can support multiple languages far more cleanly than Commons), or the subject is obvious from the category name. Descriptions should be reserved for categories where additional clarification is useful (eg Category:Granby station and Category:Trolley Brook Trail) and where descriptions provide important context for subjects without Wikidata items (eg Category:Central Subway shuttle trains and Category:South Ashburnham switchback). Pi.1415926535 (talk) 19:13, 29 August 2024 (UTC)

 Comment Generally agree except for the point 4. For example a link to a github repo may not be a reliable source at WP but still relevant and useful in a category about the software without a Wikidata infobox. Another problem is that several links in the Wikidata item don't show up in the infobox and something should be done about it there instead of adding a link also to official website (example: links to mediawiki.org in the "Multilingual sites"). Another caveat is that I don't know how Web search engine indexing works and that "No repeating of information that can be found in a parent category" is ambiguous – if you mean useful info that is not self-explanatory should be excluded in a category just because it's already in the parent category then I disagree (e.g. people may have gone directly to that cat from search results or a file instead of having seen the parent cat earlier). Prototyperspective (talk) 19:46, 29 August 2024 (UTC)

I don't think Github is a very good example. A Github page isn't a personal website, and it's perfectly acceptable to use as a source on Wikipedia (there's even a template for it: Template:GitHub). Github can't be used as a source to establish notability however. ReneeWrites (talk) 08:03, 30 August 2024 (UTC)

I think it's a good example because it illustrates well how websites considered nonreliable can be very appropriate and useful to have there. You agree that it can be appropriate so it's evidently a good example. That Wikipedia template is about external links, not references. I think it's used sometimes as a reference when the article subject is the software but it's not generally considered reliable. There are more possible examples like a category about some small organization linking to the organization's website and so on. There are many more cases where some website that would be considered unreliable would be very useful so at a minimum one would need to change that part, especially be considered reliable sources on other Wikiprojects, but I think it may be best if this point was removed or turned into a recommendation about what is usually (instead of always) the case. I'm still unsure what is meant with repeating info already in parent cat. However, I haven't seen any cases of such anyway but it doesn't seem like a good requirement. Prototyperspective (talk) 10:22, 30 August 2024 (UTC)

 Support Most of what has been said before. Thanks for starting this discussion. Maybe the four points of ReneeWrites just need some nuance. My remarks:

• This does not concern only categories about the province of North Brabant, but for many location categories of the Netherlands. I have seen many of those descriptions elsewhere too.
• For me they are redundant and annoying, but I am not the target group: perhaps to occasional visitors they might give useful information, especially if they are foreigners.
• To limit obvious redundant information: No repeating of information that can be found in an infobox. But then there should be a Wikidata infobox. For subcategories like "in" categories (for countries, "streets in" and so on) and years, there usually are no, and should not be either (except for when there is a Wikipedia article).
• I prefer "ABC" is a .. as well. The shorter, the better.
• I agree with Jmabel: Repeating the category name in other languages can be very useful. Ever since I discovered in an English discussion about a Dutch subject that a Dutch participant had trouble discussing in English, I translate categories about the Netherlands into Dutch (unless there is a Wikidata item or it is a "by" category). And sometimes there is more explaning to do because the English word has no equivalent in Dutch (see for instance Category:Estates in the Netherlands) or the English word looks like a Dutch one, but means something else.

So in general:

1. Every topic category should have either a Wikidata item or a description. Exceptions: if the category name is about a universally known subject (like "shoes"). In case of doubt: add a description in English, other languages are allowed too.
2. No repeating of information that can be found in a corresponding Wikidata infobox.
3. If there is no Wikidata item: Add descriptions to categories for countries that are not native-English speaking countries, preferably in their native language.
4. Keep descriptions as short as possible. Add a link to the corresponding Wikipedia article in the native language if that is appropriate (especially in case of country categories). You may add links to other relevant websites that you trust if there is no Wikidata item and the website is within the scope of Commons (no avertising, and so on).
5. Repeating of information that can be found in the category name ("The category "Streets of Geertruidenberg" is for pictures of streets of the municipality of Geertruidenberg...") should be avoided as much as possible. But sometimes it can be useful, even in this case: Geertruidenberg is a municipality AND a populated place. It is good to know for which one the category is (though it would be better to have it in the category name).

--JopkeB (talk) 07:41, 30 August 2024 (UTC)

What do you think of the samples Chicago and London?
 ∞∞ Enhancing999 (talk) 10:21, 30 August 2024 (UTC)

BTW, if anyone wants to see a good example of major overkill when it comes to a category description check out Category:Louvre Museum - Room 185 and scroll down past the infobox. I assume everyone here would agree that something like that is way to excessive. --Adamant1 (talk) 05:49, 31 August 2024 (UTC)

Not only is that wildly excessive, it seems like an unreliable basis for categorization. The museum can reorganize their collection; Commons shouldn't have to shuffle a bunch of categories around (or argue about what objects used to be where) when that happens. Omphalographer (talk) 06:15, 31 August 2024 (UTC)

Category instructions

There are descriptions, but sometimes instructions are also usefull. Examples: Category:Rail vehicle doors: Please place images of closed train doors only if they are prominent. All passenger trains photografed from the side have train doors. There are subcategories for open doors. Other example: Category:Rail vehicle sliding-plug doors: The door slides outside the vehicle by closing is pulled in at the last moment inside (plug). There is no supporting structure outside the dooropening and a closed door is flush with the vehicle surface. animation and rail door systems. This category is sorted by country. (Spain and Sweden under the letter 'S'). Train material door types can be determined as soon as there are enough good examples of 'open' doors to classify. In the Commons the definition of train doors is broader than in the NL article nl:Treindeur. Outside doors not used by passengers are excluded (for example drivers or loading doors) or aisle doors.Smiley.toerist (talk) 13:45, 6 September 2024 (UTC)

I just want to add one aspect or make it clear as it is already contained in No repeating of information that can be found in an infobox. Object coordinates should not be added to categories / should be consolidated and removed, if any. --Herzi Pinki (talk) 22:32, 6 September 2024 (UTC)

@Herzi Pinki: can you point me to anywhere that was decided as policy? Last I remember this being discussed (a few years ago) the opposite conclusion was reached: that it was useful to have Commons and Wikidata both contain location information, because the duplication was very useful in identifying possible vandalism, since a bot would notice the discrepancy, allowing for easy review. There could well have been a change, but if so I missed it. - Jmabel ! talk 14:04, 7 September 2024 (UTC)

No, nothing has changed. We don't trust. But I just wanted to point out that as a consequence of the above No repeating of information that can be found in an infobox, this will also affect the policy on coordinates. best --Herzi Pinki (talk) 14:40, 7 September 2024 (UTC)

The above is discussion is a bit odd, because it says that and people agree that including samples that do exactly the opposite. Go figure. Except when it's translated into Dutch. So local languages are ok, except Dutch.

Actually, it's a mistaken assumption about coordinates that the infobox offers the same. Some users might find some parts of it, most don't that see that. I think we discussed it before. Obviously, we could integrate coordinates better in the interface.
 ∞∞ Enhancing999 (talk) 20:03, 7 September 2024 (UTC)

Family trees (see below )

There is a discussion below if family trees should cover up the category pages or not, see #Familytree.
 ∞∞ Enhancing999 (talk) 20:03, 7 September 2024 (UTC)

Example images for subcategories

I would appreciate a typical sample image for each subcategory to ease correct assignment to subcategories. Of course not for standard subcategories like 'Views of', 'Nature of', 'Buildings in', etc. This should be done by marking an image of the subcategory in a suitable way (by a dedicated cat, by QI?) and done automatically when generating the category pages. best --Herzi Pinki (talk) 18:13, 9 September 2024 (UTC)

Maybe there could be a gadget that shows an image when hovering the subcat (for longer than 0.2 s). However, I think showing four images instead of just one would be best. For categories that are linked to a Wikidata item, selecting a typical representative fairly high-quality is simple: the one(s) that are set in the image property of the item. However there are many categories without Wikidata item (or with item but no image set there). In regards to your use-case however, the category title should be fairly self-explanatory so I think the use of that would be quite limited (but this and other potential usecases could still be useful enough for having some gadget that enables that). Prototyperspective (talk) 20:25, 9 September 2024 (UTC)

Don't take this the wrong way, but what's the ultimate end game here and how exactly does it relate to the topic of the discussion, "category descriptions"? Because I really fail to see the connection between that and your suggestion for a gadget that shows an image when hovering the subcat. I don't think anything ReneeWrites said in their original comment would be negated or effected by your idea. --Adamant1 (talk) 00:58, 10 September 2024 (UTC)

Could be interesting. Ideally without too much need for configuration.
 ∞∞ Enhancing999 (talk) 03:08, 13 September 2024 (UTC)

Creator template

At Category:Alexander Hamilton, there is the Creator:Alexander Hamilton in addition to the Wikidata infobox. Is this needed? I suggest we remove or collapse them on categories with an infobox filled from Wikidata.
 ∞∞ Enhancing999 (talk) 03:08, 13 September 2024 (UTC)

When questioning "own work"

I see images tagged with {{No permission since}} when clearly the issue is "I don't believe this is 'own work'." Shouldn't we have a distinct tag for that? - Jmabel ! talk 21:51, 29 August 2024 (UTC)

+1 I've noticed this as well. It is currently the closest to correct tag that we have, but it's still not really correct. -- King of ♥ ♦ ♣ ♠ 21:58, 29 August 2024 (UTC)

How about {{No source since}}? An obviously invalid claim of own work fits the description of "...appears to have an invalid source listed". I agree that a more specific template would be helpful, though - something along the lines of "please update with the correct source/license, or send permission to VRT if it's really your own work". Omphalographer (talk) 01:03, 30 August 2024 (UTC)

I view {{No source since}} as having more or less the same problem (though per the phrase you cite, a bit less so). I still think a more specific template would be better, since this particular situation comes up so often. - Jmabel ! talk 04:52, 30 August 2024 (UTC)

Perhaps some template like "dubious source" could be even better, since there could also be misattributed files to other sources (source present in the file page, but it isn't the true source), not only for own works. MGeog2022 (talk) 12:24, 31 August 2024 (UTC)

I'd be OK with that; no reason for the template to be specific to "own work". - Jmabel ! talk 17:04, 31 August 2024 (UTC)

That sounds good -- DaxServer (talk) 17:57, 31 August 2024 (UTC)

The semi-speedy deletion templates should only be used for obvious cases that are recent uploads. For the "I don't believe this is 'own work'.", a regular deletion request should be used. Multichill (talk) 12:03, 1 September 2024 (UTC)

@Multichill: you are probably right, which makes my original proposal moot. So do you think the answer is simply that {{No permission since}} should never be used this way if "own work" is claimed? Presumably it can still be a speedy if you actually have the original source to reference (or we'd be bogged down enormously), but lacking that, if you doubt "own work" you should always need a DR. Is that correctly understood? - Jmabel ! talk 14:08, 7 September 2024 (UTC)

@Jmabel: Not much space between {{No permission since}} and obvious {{Copyvio}} I guess? Because if someone just rips an image of the internet and tags it as own work, we'll just use {{Copyvio}}, right?

All the semi-speedy deletion templates are things that can either be fixed by the uploader or just end up being deleted. These are not suitable at all for cases where discussion might happen. I would be conservative. Multichill (talk) 18:45, 8 September 2024 (UTC)

September 01

Abusefilter to prevent uncategorised pages？

are all pages in main and category namespaces supposed to be categorised? if so then perhaps an abusefilter can be created to prevent creation of such pages without any "Category" or "{{" in source? (pages are categorised either directly or by transcluding a template.) RZuo (talk) 11:12, 1 September 2024 (UTC)

The ones on Commons:Report UncategorizedCategories with infobox all have "{{".

To update the list I have to purge recent creations to ensure those connected to Wikidata, but without edits since don't end up there.

For files, everything just ends up in Category:All_media_needing_categories_as_of_2024. Do users still get notified when they don't categorize?
 ∞∞ Enhancing999 (talk) 11:38, 1 September 2024 (UTC)

My experience is that especially some bulk bot uploads from external sources (like flickr) are not properly categorized or not categorized at all. While inexperienced users fail to categorize quite often, they do not upload such huge numbers of media to commons. So coping with lacking categories by inexperienced users is manageable. But bulk uploaders can work around such an abusefilter by adding some not helpful category like Category:Files from xxxx stream on flickr needing categories and not taking care for proper categorization. Even if bulk uploaders do proper categorization, they will do this in a second step after uploading - an abusefilter will just disable their usual procedures.

for the cat mentioned above, https://wikimap.toolforge.org/?cat=All_media_needing_categories_as_of_2024 will show (after a while) images on the map and then it is easy to care for your area of interest. best --Herzi Pinki (talk) 21:54, 6 September 2024 (UTC)

"pages in main and category namespaces". not files. RZuo (talk) 09:29, 9 September 2024 (UTC)

Yes, but the approach used for files could be applied to categories as well. There already is a (mostly empty) Category:Uncategorized categories.
 ∞∞ Enhancing999 (talk) 09:35, 9 September 2024 (UTC)

Category:Uncategorized categories is "mostly empty" at the moment, but only because it was recently winnowed down from over 1500 categories. A year ago, it had ballooned to about 8000, and those past 5000 in alphabetical order couldn't even be seen in the list. - Jmabel ! talk 06:27, 10 September 2024 (UTC)

You mean Special:UncategorizedCategories, not Category:Uncategorized categories, isn't it?
 ∞∞ Enhancing999 (talk) 06:42, 10 September 2024 (UTC)

@Enhancing999: Oops, you are correct, I should have clicked before assuming I knew what you meant. - Jmabel ! talk 21:30, 13 September 2024 (UTC)

September 05

Familytree

@Enhancing999: See: Category:Byington Ford A change was just made to collapse the family tree function in categories as the default. Now it isn't obvious that the navigation device is there. What are people's preferences? Which is the most useful? RAN (talk) 13:14, 5 September 2024 (UTC)

I don't recall ever seeing this before and don't see the purpose of it here. If I want to know genealogical information, Wikidata and Wikipedia are appropriate for that. I guess that it's useful for navigating within the same family, but that is pretty niche and probably not something I would ever use. That said, I generally don't like auto-collapsing any actual content and the default should be for these to be uncollapsed. —Justin (koavf)❤T☮C☺M☯ 13:16, 5 September 2024 (UTC)

There was a bug in the classes used by the template, see Template_talk:Wikidata/FamilyTree#class="collapsible_autocollapse"_not_working. This was fixed today.
 ∞∞ Enhancing999 (talk) 13:19, 5 September 2024 (UTC)

I don't see how that responds to what I wrote, but it does seem to respond to the original comment. How is what you wrote relevant to what I wrote? —Justin (koavf)❤T☮C☺M☯ 13:47, 5 September 2024 (UTC)

You write that you prefer it in an uncollapsed form. If you read my comment and its link to additional discussion then you discover that your preference leads to category pages being replaced by family trees. I think this response both to the original comment and yours.
 ∞∞ Enhancing999 (talk) 13:50, 5 September 2024 (UTC)

Thanks. —Justin (koavf)❤T☮C☺M☯ 14:06, 5 September 2024 (UTC)

I think it should be collapsed if it is to be included in category pages. That's not really what category pages are for, not how or where people look for such data and it hides category contents (mainly subcats and files) as well as cause UI issues. Another example. Prototyperspective (talk) 13:44, 5 September 2024 (UTC)

• The new template has been around since 2019, replacing the hand built trees that been around for a decade or more. You only see them where the person is a member of a large family such as in royal/noble lines. It isn't decorative, it is a navigation device. It sometimes is the only way to see that there is a disconnection in the family, caused by incorrect merges or the deletion of someone in the family when someone doesn't realize it has a structural need. The problem is that in the current collapsed state it is not obvious that a tree is present. --RAN (talk) 16:59, 5 September 2024 (UTC)

  The problem is that in the current collapsed state it is not obvious that a tree is present. Because the way it's wrapped into a collapsed box is having it show only the text "Byington Ford (Q5004096) [Expand]" (in this example) instead of e.g. "Show family tree [Expand]". The name is already in the cat so redundant and the Q number is not useful to the reader and also already on the page via the infobox. Prototyperspective (talk) 17:07, 5 September 2024 (UTC)

  I think "autocollapse" is the old version for collapsed state. It must have been designed to be collapsed.

  The header of the template should be improved. Merely using the name of a person and a quid doesn't really explain what it's meant to be. This isn't really better when it's expanded and covers the entire screen.
   ∞∞ Enhancing999 (talk) 17:08, 5 September 2024 (UTC)

• See: Category:Thomas_Jefferson where consensus was to have the tree collapsed so a collapse function was wrapped around the tree, now it is doubly collapsed. --RAN (talk) 17:15, 5 September 2024 (UTC)

  Seems the problem was known, but incorrectly fixed.
   ∞∞ Enhancing999 (talk) 17:19, 5 September 2024 (UTC)

One thing I like about the wrapper on Category:Thomas Jefferson is that it actually says "Family Tree". If that text got added in the template header it would already tell people a lot more on what the information is about before/without having to expand it. ReneeWrites (talk) 18:20, 5 September 2024 (UTC)

Having it say "Family Tree" is great, having it doubly collapsed is probably something we should fix. - Jmabel ! talk 18:58, 5 September 2024 (UTC)

Looking at the Thomas Jefferson example: do I understand correctly that the tree reads right-to-left, and that for the central figure there is no indication who is the other parent of their various children, nor is there any indication of legitimate vs. illegitimate offspring? - Jmabel ! talk 19:03, 5 September 2024 (UTC)

Oh my goodness, this is heinous: now there are two collapsed boxes and you have to vertically scroll within a div?!?!? This is inaccessible and poor web design, folks. —Justin (koavf)❤T☮C☺M☯ 19:11, 5 September 2024 (UTC)

• About the label issue, it's seems that the default text is "Family Tree (tree of ancestors and descendants)", but somehow this is overwritten sometimes by the QID. It seems that the template is just not used as designed: Sample at Category:Ulrica Christina Wellingk, the default is overwritten with |title={{Q|Q104549892}}.
   ∞∞ Enhancing999 (talk) 19:15, 5 September 2024 (UTC)
  • Jeez. At least that could be |title={{Q|Q104549892}} family tree. - Jmabel ! talk 21:14, 5 September 2024 (UTC)

    For translation purposes, it would be better if that label came directly from the template. In the sample, |entityId=Q104549892|title={{Q|Q104549892}} could be limited to |entityId=Q104549892, if the QID isn't determined directly from the category.

    To sum it up: the following maintenance seems to be needed:

    • (1) fix the label in the template
    • (2) remove |title={{Q|Qnnnn}}
    • (3) remove the duplicate collapsing (as on Category:Thomas Jefferson)

    
     ∞∞ Enhancing999 (talk) 08:28, 6 September 2024 (UTC)

• I think Jmabel has the fix which solves 1 and 2. --RAN (talk) 04:55, 7 September 2024 (UTC)

  That might work for English, but not for any other language.
   ∞∞ Enhancing999 (talk) 10:20, 7 September 2024 (UTC)

• Now Category:Henderikus Cashow has the title: "Category:Neighbourhoods in Heerenveen" --RAN (talk) 07:00, 7 September 2024 (UTC) fixed
• Changes I would like to see:

1 only have to add in Q number once, instead of twice and have title be "Q family tree" appended. --RAN (talk) 15:58, 7 September 2024 (UTC)

2 have collapsed be default but allow that to be changed manually to open. We have Categories called X family or X noble family, here you expect to see the tree by default. --RAN (talk) 15:58, 7 September 2024 (UTC)

3 if using the year function, take out the line space between the two so it is more compact and put the years in parentheses to match our style guide. --RAN (talk) 15:58, 7 September 2024 (UTC)

I would say always collapsed. This is a media repository; family trees are metadata that we may keep here for convenience, but they should not dominate the page. It's easy enough to open it if that is what you want. - Jmabel ! talk 23:03, 7 September 2024 (UTC)

I don't see how to make any individual tree not-collapsed for the display when a category is opened. When I am working on a noble family, it would nice to have the tree open while I am working on it. RAN (talk) 02:09, 9 September 2024 (UTC)

@Richard Arthur Norton (1958- ): So for your particular purpose, you can click once to open it. But most people go to a category looking for media. - Jmabel ! talk 06:40, 10 September 2024 (UTC)

• A. I did some cleanup on the duplicated "collapsing". This should be mostly fixed.
• B. Also, titles now behave as described at Template:Wikidata/FamilyTree#Title_of_family_tree_box. It also mentions how to improve localization for a given language. A few cases with other titles can be found at Special:Search/Category: hastemplate:"Wikidata/FamilyTree" -"Family tree of", notably when the "entityID" doesn't match the item in the title.
• C. I noticed a few persons where the corresponding Wikidata item doesn't exist or was deleted: such as Category:Marion Boisot, Category:Jacob Ford (1759-1845). Supposedly the template should report some error there.
   ∞∞ Enhancing999 (talk) 13:13, 15 September 2024 (UTC)

September 06

Categorizing Newspapers by date (YYYY-MM-DD)

Hi, there are a few newspaper collections here on Commons that are categorized by date, for example the Abilene Daily Reporter. Other newspapers are not categorized this way, which makes it harder to find contemporary news. With some newspapers, the amount of files is large enough that I think this work could be delegated to a bot. For starters, there is The Ohio Sentinel, with conveniently labelled files like File:Ohio Sentinel 1952-06-28 - DPLA.... Older files of the same newspaper from 1951 are less convenient: File:Ohio Sentinel August 11-August 18, 1951 - DPLA.... Then there is the Galveston Tribune with file names like File:Galveston Tribune. (Galveston, Tex.), Vol. 17, No. 100, Ed. 1 Tuesday, March 16, 1897 - DPLA.... More examples: File:Gazeta săteanului 1886-05-05, nr. 07.pdf, File:Epoca 1886-05-18, nr. 146.pdf, File:Bukarester Tagblatt 1886-05-02, nr. 095.pdf, File:Томские губернские ведомости, 1886 № 19 (1886-05-15).pdf, Journal de La Haye 03-01-1847 (IA ddd 010258178 mpeg21).pdf.

Is bot-processing feasible? --Enyavar (talk) 16:50, 6 September 2024 (UTC)

There seems to be {{Book}} (most likely) with {{{publication date}}} set to the date. Assuming it is correctly done, or corrected beforehand, a bot can easily categorize that info -- DaxServer (talk) 17:22, 6 September 2024 (UTC)

Why not use Wikidata en SD? Newspaper issues can be itemized in Wikidata with publication date (P577). Examples d:Q45747062 (Category:Journal de Bruxelles nr 76), d:Q46834135 (Category:Journal de Bruxelles nr 83), d:Q62015763 (Category:Journal de Bruxelles nr 90) Smiley.toerist (talk) 08:55, 9 September 2024 (UTC)

Hi, whatever "en SD" is, it seems to not help at all with search results. When I search for "1799-12-17", the Journal de Bruxelles does not appear in the search results (with quote marks not at all, without quote marks not before literally tens of thousands of other manuscripts from different dates, some of them decades/centuries earlier/later than 1799. Furthermore, the Category:1799-12-17 is so empty that it appears as if Commons does not have any media regarding that specific date. Only your link proves the contrary. So I think that WD-en-SD could also benefit from some categorization.

What good are the vast newspaper archives of Commons if they are buried and inaccessible unless you know the title of an accessible newspaper? Please tell me what was in the news around the world, on 1844-02-20 or another random date. --Enyavar (talk) 05:38, 10 September 2024 (UTC)

It is in the category 1799 newspapers. I have my doubts that a specific publishing date is of any use in researching a specific event. At that time there was no instant communication, and all news travelled slowly. So in practice the newspaper got dispatches from different places and times. In the issue of 76 (12 december 1799), there are many dates and places: al in the year 1799:

• Paris: 3-12 (2X), 29-11, 27-11
• 20-11 (Marseille), 25-11 (Nice)
• Genua 8-11, Florence 18-11
• Lausanne 23-11, Bern 23-11, Basel 25-11, Zurich 25-11
• Leiden 30-11
• London 21-11
• Frankfurt 24-11, Rastadt 29-11
• Stockholm 15-11
• Sint Petersburg (Russia) 9-11
• Istanbul (Constantinople) 29-10
• Ratisbonne 28-11 (latest incoming news in the morning)

If you looking for a specific event, you must look at all issues, months after. News across the Atlantic could even take more than a month. Smiley.toerist (talk) 09:13, 10 September 2024 (UTC)

That's true, but who expects pre-telegraph newspapers to print news from the other side of the globe? That is why I strongly suspect that the issue of long news-travel times stops being this noteworthy after the 1870s. And even the weird French Revolutionary Calendar dates you give above, are not that problematic.

The thing is that Wikidata is not working either: Yes, Q46834135 = [Journal de Bruxelles (1790-1800)/83-1799] exists and has a publishing date. Now what? There are no links to any other media of the same publishing date, nor are there links to previous or later issues of the JdB itself. The publishing date (P577) is apparently not even meant to be a searchable item on wikidata: "P577 = 17 December 1799" --> No match found. "P577 = 1799-12-17" --> No match found either.

The search function here on Commons actually works: My search for "date = 1897-03-16" immediately spits out a few newspapers as a search result - thankfully - but that still does not mean that the search results would match my request (1897-03-04 and 1897-07-16 are among the results), and newspapers without proper description attributes ("date = 1897" and March 16 only in the file title) are again lost to the search filter. The search function can only help that much, after all.

Furthermore when relying on search, it remains impossible to browse between different newspapers that were released on the same date. Nor is it easily possible to go a few days forward or backward. Take for example The Halletsville Herald, The Abilene Reporter and The Daily Hesperian (I found all of them with the query above): Neither of them is meaningfully categorized at all; while the Galveston Tribune is at least categorized by year. And the categories are certainly not sorted by date either. --Enyavar (talk) 14:23, 10 September 2024 (UTC)

The Journal de Bruxelles is a nice and precious project of nine preserved issues. Categorizing less than 100 categories/files is a task that a dedicated editor can quickly tackle. Sorting all available newspapers on Commons by publication date is a different thing, and I would not suggest doing so if we only had a few isolated copies of each paper.

• Many big and small newspapers have their own categories, and files with the newspaper issues often follow standardized patterns with regards to descriptions/filenames, like the ones I linked above. Some of them have hundreds and thousands of digitized issues.
• Many thousands of files already have the attribute of "date = YYYY-MM-DD", right here either in the description on Commons, or in the filename like those I pointed out in the initial question.

It is these that I'd like to be more accessible. Category:Newspapers published 1900-01-01 and basically thousands of days before and after this date, have a huge potential. If a bot can be tasked, one newspaper-archive-category after the other, I believe no day between 1850 and 1950 will not have at least a few files, and that is before Commons editors manually categorize the many "very incomplete" archives (like Category:Le Gaulois du dimanche with merely 27 files).
And sure, I am aware that his is casually asking to create 36'525 categories and more.
And sure, I have more concurrent projects and to-dos than I will ever have time.
And sure, I don't know the first thing about bots.

But this would be a really nice upgrade to the newspaper section of Commons. --Enyavar (talk) 14:23, 10 September 2024 (UTC)

Lets start with creating the missing YYYY-MM-DD categories. I just created Category:1799-12-21 and Category:1799-12-31 for the Journal de Bruxelles issues. (And 1800-01-31, 1800-02-05, 1800-02-11, 1800-03-08) If the date gets crowded, we can always add the more specific Newspapers published xxxx categories.Smiley.toerist (talk) 12:09, 15 September 2024 (UTC)

• Agree this could be useful. IMO YYYY-MM-DD should have been the preferred date format for Commons from the beginning, and we should eventually transition to using it (and get rid of categorizing by English language month names). -- Infrogmation of New Orleans (talk) 15:07, 10 September 2024 (UTC)

September 07

20@ Wikimedia COMMONS

🎉 HAPPY #20 BIRTHDAY WIKIMEDIA COMMONS & COMMUNITY !

(not as widely popular or loved as Wikipedia or Wikidata,

but hopefully worth fixing, updating and making sustainable,

if not advancing where no media server has gone before)

What are you doing today to celebrate Commons talk:Wikimedia Commons 20th anniversary?

Zblace (talk) 06:14, 7 September 2024 (UTC)

We really should mention this on the homepage and we should have had birthday-related media spotlighted. This reminds me of when we hit 100 million files and no one really seemed to care. :/ —Justin (koavf)❤T☮C☺M☯ 15:35, 7 September 2024 (UTC)

Is it too late to temporarily change the logo and maybe have it link to somewhere? Is there any press reporting about this like they do for Wikipedia anniversaries? Prototyperspective (talk) 21:41, 13 September 2024 (UTC)

It would be nice to celebrate a few anniversary days or weeks, even if starting after the actual anniversary day.

not as widely popular or loved as Wikipedia or Wikidata: I think it's because most people don't realize that the vast majority of images in Wikipedia actually belong to Commons. Wikipedia wouldn't be what it is without its media. If all projects were viewed as a single whole (almost all media in Commons, even if not used in any article, can be viewed as an extension of some Wikipedia article, and the same for any citation in Wikiquote, any book in Wikisource, any contributor-made book in Wikibooks, any travel guide in Wikivoyage, etc), Commons and other projects would probably be much more noticed. I am not against each project's own personality, but I am against any kind of rivalry between them. If it was better for the Wikimedia ecosystem and the dissemination of knowledge, I'd have no problem if Commons was renamed to "Wikipedia Media Repository" and Wikisource to "Wikipedia Library", for example. MGeog2022 (talk) 11:06, 14 September 2024 (UTC)

Don't think there's any kind of rivalry between them. Zblace I think WM Commons is far more popular and used way more than Wikidata. I'm interested in real usecases of Wikidata beyond linking Wikipedia articles and the infoboxes but for WMC there's lots of use-cases such as people coming here to find images for their videos (often starting on Google Images due to which addressing it not properly indexing most media here is a key problem and I wonder why noone is addressing it except for a user writing this proposal). Prototyperspective (talk) 11:47, 14 September 2024 (UTC)

Yes, I was surprised when reading that Wikidata was more popular than Commons. I doubt Wikidata has many direct human readers, but maybe it's popular to get machine-readable information with automatic systems. MGeog2022 (talk) 12:22, 14 September 2024 (UTC)

(and, if we consider images in Wikipedia articles, I think Commons is as popular and loved as Wikipedia, even if unconsciously) MGeog2022 (talk) 12:25, 14 September 2024 (UTC)

If you or somebody else knows of any applications (not for demo purposes but actually used), please let me know. It can't be used to get data about studies (far more incomplete than OpenAlex & ScienceOpen) or books (Anna's Archive) or foods (see this and OpenFoodFacts or propriety MyFitnessPal) or films (eg IMDB) or music (MusicBrainz etc) or chemical ingredients (CodeCheck) or anything else where data repositories are currently used in society. Prototyperspective (talk) 12:27, 14 September 2024 (UTC)

No, I don't really know any real Wikidata use case (that's why I said maybe). I haven't searched anything about it, though. MGeog2022 (talk) 12:36, 14 September 2024 (UTC)

Many images of book scans

Is there some policy about how book scans are to be handled? I think it would be best if books and similar literature were uploaded as one PDF document rather than as many scattered separate image files.

This way one can easily download or read them / go through pages and they don't clutter search results or require subcategories for just one literature item. For scans already uploaded, a bot could convert them into PDF files. One can also embed single PDF pages like an image on Wikipedia so there's not really any disadvantage to converting them to document files. Example example. --Prototyperspective (talk) 17:22, 7 September 2024 (UTC)

How about we leave them as the projects that are using them are uploading them? One may be able to embed single PDF pages, but I don't know how, and it's hard to find the appropriate illustration pages. Not to mention that PDFs use compression, and if the originals were PNGs, converted to JPEG2000 for the PDF, and then converted to JPG for Commons, that makes worse final images than directly working with the original scans.--Prosfilaes (talk) 18:19, 7 September 2024 (UTC)

I described several reasons why not to keep them as people and projects upload them. Moreover, they could change how they upload them. Scans of one page of a book are nearly never used on a Wikimedia project and when they are used often having the full book available at the page would be much better and useful. How to embed a specific page of a PDF is described here: Help:PDF#Page. As for quality they could be converted without loss of quality and it doesn't have to be PDF files if there is something better. Prototyperspective (talk) 18:24, 7 September 2024 (UTC)

They could be converted without loss of quality how? You're adding another level of conversion.--Prosfilaes (talk) 06:04, 8 September 2024 (UTC)

With a command that converts losslessly. Maybe ImageMagick's convert ./page*.png ./output.pdf already converts losslessly and somebody should check if that is the case. Prototyperspective (talk) 13:20, 8 September 2024 (UTC)

• I am not against merging into a pdf or djvu file, but as pointed out previously book illustrations can be used by other projects as well as the title page to illustrate the Wikidata entry. --RAN (talk) 20:51, 7 September 2024 (UTC)

  Can one not specify the page of a PDF document on Wikidata for the image/cover property? Maybe that functionality can be added. Then people could also upload the cover or a particular image separately rather than uploading a whopping 300 files for one book. That is also useful because the title can be more descriptive and here is an example of an image from a PDF file that is used on Wikidata...it's much better than having the image just as some whole-page generically titled document scan image. Prototyperspective (talk) 21:04, 7 September 2024 (UTC)

  As far as I'm aware, the default thumbnail for PDF/DjVu documents is always a thumbnail of the first page. Which is a shame; there are a lot of books where that page is a Google Books notice, or an image of a badly damaged cover. Being able to override that with a thumbnail of the title page would be a huge improvement. Omphalographer (talk) 21:33, 7 September 2024 (UTC)

@Prototyperspective: I feel like the benefits of something like this would depend on the subject of the book. Like if its mainly or only text, cool. Convert it into a PDF and get rid of the JPEGs. There's of books with photographs or illustrations of historical subjects and places where it makes sense to have individual images. And not just for other projects but in general. Its kind of redundant to have individual images for books that are purelu text though but I think they are easier to transcribe for other projects that way. But I'd still argue its pointless (if not against the guidelines and /or goals of the project) to have jpegs of individual pages that are purely text on our end. --Adamant1 (talk) 21:22, 7 September 2024 (UTC)

Strong  Support towards converting multi-page documents into multi-page document formats - PDF. (I also posted some thoughts about this once) ~TheImaCow (talk) 21:28, 7 September 2024 (UTC)

I tend to agree with the idea that it should just one file, but PDF support hasn't really gotten better. It's actually somewhat broken and even the WMF person in charge of Commons has no idea if or when it's going to be fixed.
 ∞∞ Enhancing999 (talk) 21:49, 7 September 2024 (UTC)

 Weak oppose Maybe for type-written works it makes sense to only have a PDF, but for hand-written it's often really useful to have higher-resolution files and if they were combined into PDFs the PDFs could be quite large. A small example could be something like this where it's often useful to be able to zoom right in on a letter to better see the pen strokes etc. It's also more likely that people preparing PDFs will end up with trusting whatever their scanner software gives them and by doing so be throwing away information that we'd rather keep (e.g. postmarks on letters). I wonder if more could be done with the search system and structured data to make it easier to exclude individual scans? Sam Wilson 04:47, 8 September 2024 (UTC)

Maybe a Wikidata property for scan quality or something that could be used to push bad quality PDFs and images down in the search results? I've been wanting something like that for awhile now to suppress crappy scans of postcards from the search results. --Adamant1 (talk) 05:02, 8 September 2024 (UTC)

@Adamant1: Yes, good point. Maybe DPI for original size (P10300) would suffice? I've not ever bothered adding that, but it would totally make sense. Sam Wilson 05:12, 8 September 2024 (UTC)

Good call. I didn't know that existed. Although the "for original size" thing seems a little needless, but whatever. I don't see why it wouldn't work. --Adamant1 (talk) 05:26, 8 September 2024 (UTC)

If you have poorly printed pages, where OCR does not work, pdf is not an usefull format. For the Category:Journal de Bruxelles, I scan most pages, two at a time folded open. I have a standard naming principle for the files. In Wikisource the pages have to be manualy typed over as the OCR does not work. A lot of work, but a usefull result.Smiley.toerist (talk) 11:16, 8 September 2024 (UTC)

 Comment Commons doesn't have an official policy on this, but I like to keep in mind what other projects might need these files for and how. For regular books, Wikisource needs an original .pdf or .djvu to be the source/reference material, and illustrations exported separately, usually retouched. See for example here: https://en.wikisource.org/wiki/Page:The_Osteology_of_the_Reptiles.pdf/23 ReneeWrites (talk) 10:39, 8 September 2024 (UTC)

Note that Wikisource can also work with individual image files as well as PDFs/DjVus. Sam Wilson 12:52, 8 September 2024 (UTC)

 Comment I've been working on Category:Helix (newspaper). If these had been PDFs, I'd have had to extract files for almost every page to document them decently. Yes, there are probably times whe PDFs are best, but it's not a universal. - Jmabel ! talk 12:15, 8 September 2024 (UTC)

 Comment something I find suboptimal with individual pages is that {{Book}} doesn't really seem to be adapted for it. Also, when actually using elements from a page, one generally needs to do another crop just for that part. In the end, that part and the original page might end up categorized for that content.
 ∞∞ Enhancing999 (talk) 13:23, 8 September 2024 (UTC)

• "when actually using elements from a page, one generally needs to do another crop just for that part": there's a template for that. See the syntax used for the image at en:Native American civil rights#Fishing and hunting rights. - Jmabel ! talk 06:46, 10 September 2024 (UTC)

  Interesting, but most users would probably still want to crop the photo as a separate file if they want to use that part.
   ∞∞ Enhancing999 (talk) 06:50, 10 September 2024 (UTC)

• Remember nothing actually gets deleted, so we are not saving any space. We also have had the case where a page was missing, a page was out of order, or a page was upside down in the pdf, and we had to recompile the file. Perhaps if all the individual pages were in a folder there would be less clutter once the pdf was created. --RAN (talk) 18:01, 8 September 2024 (UTC)

  It's not about space but about clutter. It also causes misleading upload stats and clutter the UploadedFiles page. The main issue is the clutter in the search results and from views that e.g. combine categories. The many subcategories are also clutter. Then it's also hard to download the file and a main problem is that it's hard to read a document if it's in dispersed pages instead of in one document. And I think this also applies to old 1800s drawings of organisms which are not really useful anymore, not what people look for, and for which there are now high-quality photos & illustrations. If an image is needed one can specify the page of the PDF or extract an image (that is different from a whole page) from it. Prototyperspective (talk) 18:21, 8 September 2024 (UTC)

  This also applies to old 1800s drawings of organisms which are not really useful anymore, not what people look for, and for which there are now high-quality photos & illustrations. I strongly disagree with this. You have made the common mistake of assuming that what you find useful or interesting is what other people also find useful or interesting, and what you find irrelevant or annoying is what other people also find irrelevant or annoying. For some users of the Commons, "old 1800s drawings of organisms" are in fact more useful than modern photographs, and individual page scans are more useful than PDFs, especially if PDFs of the same public domain documents are already widely available from Google Books, Internet Archive, Hathi Trust, and other repositories. We all use the resources here differently, and the specific resources you like to use and the way you like to use them are not universally shared. There may be good reasons to consider changing the way that multipage documents are handled, but generalizations about "what people look for" based solely on your own preferences are not among them. Crawdad Blues (talk) 20:00, 8 September 2024 (UTC)

  No, I did not make this mistake – maybe I have made this mistake of not clarifying which of my statements are a statement of opinion/argumentation. It's not surprising that there are users who think so since there are users who upload such images particularly as separate pages and with that sentence I was addressing an earlier comment arguing it would be good to do so for images that contain images. These users are very few and I have yet to see any actual usefulness case / application of such images. It's great that we have them on WMC, but I don't see why having them in separate scans would be reasonable. Please make a survey or look at pageviews or explain specific use-cases with examples if you think what I said is wrong. Prototyperspective (talk) 20:17, 8 September 2024 (UTC)

  (With such images I was referring to separate pages as scanned page image files, not whether or not these files are on WMC.) This proposal is mainly about documents with text that include images, not documents which contain only drawings as a page. I think an example of a WMC search that shows mostly scans of a few books and burying what most users are looking for is needed to illustrate what I mean. Here's a bad but maybe still useful example: if you search for "animal" there is an undue number of scans from Category:The animal kingdom, arranged after its organization, forming a natural history of animals, and an introduction to comparative anatomy (1834) at the top instead of higher-quality drawings/artworks and photos (like the collages at the very top). They can be useful but often inaccurate unreliable 1834 drawings are usually not what the user can use for any of the purpose such as adding them to a WP article or illustrating the species. These images (the book) are still useful and it's worse for other searches. Prototyperspective (talk) 20:35, 8 September 2024 (UTC)

  I agree with Crawdad Blues: images of images from books (and other documents), like drawings, prints and photographs, should stay and be images: one in a file. Then they are easy to reuse and then end users do not have to go through the upload process, but can directly use the file. For a type-written, printed book that primarely is about text: yes, then a PDF file is easier, for searching within the text and to leafing through it. JopkeB (talk) 05:17, 9 September 2024 (UTC)

It depends a lot on each specific case, but, if uploading a new book, I think PDF is the best option. If the book contains images that are interesting in their own right, they should be uploaded as separate files (or even be left for another user who is specially interested to upload them, if you don't have time for it). For already uploaded books, I think that existing images should not be deleted, but creating a new PDF book can be a good idea.

I think Commons, for some cases, can be a good book deposit/library, in addition to Wikisource (with OCR or some freely licensed or public domain original PDF books, you can even have machine-readable PDF books in Commons with relatively little effort, while migrating their content to Wikisource can be a really big work in many cases). MGeog2022 (talk) 10:51, 10 September 2024 (UTC)

Use of NoFoP-category template on broad categories

I'm in a bit of a disagreement with someone on this issue, so I thought I'd ask for clarification here: should Template:NoFoP-category be applied to broad categories in a NoFoP country (e.g., "Statues in X city" or slightly more specific ones like "Statues of animals in Y city")? My understanding is that it should be reserved for categories dedicated to specific structures or monuments, as some in those cities may be old enough to no longer be under copyright protection. What are your thoughts? — Golden ^talk 21:31, 7 September 2024 (UTC)

The (English) text of the template suggests to me that it's meant for specific works, not classes. Not entirely sure if we should have such a template.
 ∞∞ Enhancing999 (talk) 21:47, 7 September 2024 (UTC)

I would never put it on that broad a category. - Jmabel ! talk 23:07, 7 September 2024 (UTC)

I agree with Enhancing999 and Jmabel. This belongs as a category header for specific works in NoFoP countries, for the reason you stated. ReneeWrites (talk) 10:23, 8 September 2024 (UTC)

Totally agree with everyone else. It doesn't make sense to use the template on a general topic because works in the category (or that will be uploaded to it) will inevitable be PD due to age or other factors. --Adamant1 (talk) 10:30, 8 September 2024 (UTC)

• Disagree I now accept that the template should not be used in broad categories. All such templates that I erroneously added to categories have been helpfully deleted by the nominator and his friends. Thanks for that guys. Moving to non-broad category usage, the example cited - "Statues of animals in Y city" - does not fit the broad criterion in my view. As I mentioned to @Golden: on my talk page, "In the case of the "Statues_of_animals_in Qəbələ" category, I see two pics of wooden eagles and one pic of dinosaurs. I conclude that it is not general, it is not broad, the statues are new, it is quite specific (a triple intersection of art (statue), subject(animals) and location (Qəbələ)). So as far as I'm concerned, it meets all of the criteria". Certainly where all the pics in a category contain nothing but images which, of themselves, would all be legitimate candidates for marking with the template "NoFoP-Azerbaijan", then I think that a categorical marking is merited and a more efficient use of editors' time. Laurel Lodged (talk) 13:23, 8 September 2024 (UTC)

  @Laurel Lodged or better, leave the generalized categories with no such templates? I was the one who proposed this template and its original purpose was for specific works. Leaving the generalized categories without such templates removes the unsightly clutter in the said categories. JWilz12345 (Talk|Contrib's.) 13:45, 8 September 2024 (UTC)

  TBH, I can see the merit of using this template in certain broad categories where virtually any photo will be a FoP violation. For instance, Qatar has strict FoP, and essentially no buildings or public artwork old enough to be in the public domain, so placing FoP warning templates on related categories might be warranted. Omphalographer (talk) 21:02, 8 September 2024 (UTC)

@Omphalographer: I'd be interested to know what exactly you think the merrits of doing it that way are. People are going to add images of copyrighted works to the categories regardless. The same could be said for the main categories for the subjects in the image, but at least users expect to see the template there. Plus at least in my experience broad categories tend to not be persistent anyway. So it's just encouraging people to add the template to the main subject level category instead of the one for the particular work and in an instance where the template will likely be removed or deleted at some point anyway. Categories for specific works at least have less chance of being deleted, and again, users expect the template to be there. --Adamant1 (talk) 00:12, 9 September 2024 (UTC)

The sort of situation I have in mind is where more specific subcategories might not exist on Commons because any image of the subjects would be non-free. It'd be analogous to {{NoUploads}}, which we use on categories for many well-known artists whose works are mostly non-free. Omphalographer (talk) 20:04, 10 September 2024 (UTC)

@Omphalographer: I just fixed Adamant1's ping above, so it may not have pinged you. - Jmabel ! talk 06:52, 10 September 2024 (UTC)

September 08

Template:How to delete empty categories

When working on Commons:Report Special:UncategorizedCategories, I noticed that many categories are there, merely because users don't know how to have categories deleted with typos or other minor problems.

Template:How to delete empty categories (brought to my attention by @Jmabel) is meant to explain it to them.

I think it could be formulated better, though I'm not entirely sure how. Personally I prefer {{Badname}} or {{empty, parentless category}}. Also I noticed some users adding {{SD|C2}} including nowiki tags.
 ∞∞ Enhancing999 (talk) 12:50, 8 September 2024 (UTC)

Someone is not doing it right if they include those nowiki tags.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 03:18, 9 September 2024 (UTC)

Yeah, accordingly, I hope we can improve the template
 ∞∞ Enhancing999 (talk) 09:07, 9 September 2024 (UTC)

I usually just use C2 unless it's clearly a bad name. I actually didn't know C1 was an option until just now. So things could clearly be explained better. Heck if I have any idea how though. --Adamant1 (talk) 03:31, 9 September 2024 (UTC)

Whatever we do: keep the template short. If this is going to turn into a wall of text, it should be in a page linked from the template, not the template itself. - Jmabel ! talk 06:55, 10 September 2024 (UTC)

Yeah. It's an important template. Commons:Report Special:UncategorizedCategories is again full of categories that could have been tagged for speedy deletion.
 ∞∞ Enhancing999 (talk) 07:01, 10 September 2024 (UTC)

September 10

Munich metro type

• 
• 

I would normaly put these metrotrains into the Category:MVG C (U-Bahn München), However the windows are different to the other images in that category. They ont have the pull open part. Is this an early C type, where later the windows where replaced or is it a totaly different type? Smiley.toerist (talk) 11:20, 10 September 2024 (UTC)

Might be worth reaching out about on the German Wikipedia? Portal Diskussion:Bahn ReneeWrites (talk) 13:57, 10 September 2024 (UTC)

That's a Type C with the wooden seats near the door. The skylight windows are only on one side of the vehicle (most likely to avoid "Zugluft"). -- Herbert Ortner (talk) 20:58, 11 September 2024 (UTC)

Button for 3D models added on main page

A button that shows the 3D models was added on the main page, next to images and videos. It is a good point in time to highlight textured meshes that could be presented :) --PantheraLeo1359531 😺 (talk) 11:41, 10 September 2024 (UTC)

Repeated file renaming requests, how to react to their occurence

Hello,

I am a filemover and came across this request. The requested move seems to be for that the new name is similarly styled to the other 2 in Category:DC candidates TSE portraits, but it does not really convince me as it would only be "a bit better looking" (maybe! capital lettering is not nice to read), per COM:FRNOT. Hence, I declined the request. Now, it was back again in the queue (denied again by me). Is there any procedure on how to deal with repeated renaming requests after a denial, or any established way of appeals? Regards, Grand-Duc (talk) 19:11, 10 September 2024 (UTC)

@Grand-Duc: As far as I know there's no formal review process for file moving. In my experience what usually happens when I decline a request and someone disagrees is that they request it again and either I change my mind or I leave it for another filemover to deal with. I don't think I've seen anyone try to get a fourth opinion after two declines from different filemovers. In this case, while criterion 4 obviously doesn't apply I did wonder if Erick Soares3 and KakuLogia+ might be connected in a way that would allow criterion 1 to apply, since they've been making very similar requests. And anyway the overwriting of that file was bad under COM:OVERWRITE and maybe it needs its history splitting. At which point I decided it was all too complicated and I should do something less confusing instead. --bjh21 (talk) 21:31, 10 September 2024 (UTC)

@Bjh21: and the specific dataset is for Category:TSE electoral portraits of 2024 (the general category for this year) or even Category:Files from Portal de Dados Abertos do TSE (about 200 styled the same way in the first page) with almost everything from 2004-2024, while the DC is only for members of this specific party. Criterion 1 is if we were the same uploader, and no, this isn't the case: we are only from the same country, and we are working with this dataset (specially because we are less than a month before the elections and those images are useful in the Wikipédia/Wikidata). Erick Soares3 (talk) 21:38, 10 September 2024 (UTC)

So the rename is from:

• File:Bebeto Haddad Candidato a Prefeito de São Paulo 2024 - TSE.jpg

to

• File:2024 BEBETO HADDAD CANDIDATO PREFEITO SP SAO PAULO TSE (250002355541).jpg

? This because other files had been renamed?

I DON'T THINK FILENAMES SHOULD BE IN ALL CAPS AND ONE SHOULD NOT RENAME CORRECTLY CAPITALIZED FILENAMES TO ALL CAPS. RENAMES ARE NOT HERE FOR SORTING FILES IN CATEGORIES NOR FOR ACHIEVING SOME COSMETIC GOAL.

Another problem with the file is that an initial photo was overwritten.
 ∞∞ Enhancing999 (talk) 01:53, 13 September 2024 (UTC)

Selection of deprecated categories in category entry fields

Hi, when entering categories, category names that have been deprecated and redirected, such as, let's say, Category:SS Shieldhall, pop up in the list of suggestions in the same way as any other category, without any warning or labelling, so it is easy to choose them and never notice that you shouldn't have. I wonder whether this could be handled better somehow. ITookSomePhotos (talk) 20:10, 10 September 2024 (UTC)

@ITookSomePhotos: Can you say which category entry fields have this problem? Because when I enter that category in the one on Special:Upload, it gets automatically converted into the correct category when I click "OK". Similarly if I try to add it to a file using HotCat or enter it into Cat-a-lot. --bjh21 (talk) 21:22, 10 September 2024 (UTC)

I used the Upload Wizard. I uploaded some pictures of the ship "SS Shieldhall", typed "SS Shie..." in the category field, and then selected Category:SS Shieldhall from the list. Later, when for interest I went to look at what other images there were in that category, I found only mine, plus the redirection notice. The I manually changed my images to Category:Shieldhall (ship, 1955). This has happened to me before, with other categories too, though I can't remember specific examples now, but most probably these were also entered via the Upload Wizard. ITookSomePhotos (talk) 23:29, 10 September 2024 (UTC)

Things like that are exactly why I usually just nominate obsolete categories for deletion instead of redirecting them. 99% the redirect isn't useful anyway and it just cause more problems or work in the long run. There's absolutely no reason the few redirects that are worth having should show up in search results though. --Adamant1 (talk) 02:09, 11 September 2024 (UTC)

@Adamant1: I disagree. It's very helpful (to me at least) that Category:Herons, a redirect to Category:Ardeidae, turns up in search results, because it means that I type the word that I'm familiar with into HotCat and it will use the correct category. --bjh21 (talk) 12:06, 11 September 2024 (UTC)

I mean sure they are helpful in some cases. I didn't say they are absolutely worthless, but I've seen plenty of instances where the category should have just been deleted instead of redirected. The fact is that they are way over used. --Adamant1 (talk) 12:10, 11 September 2024 (UTC)

• HotCat automatically converts the redirect cat and it's only a problem if the two category titles start of the same way because then one may wonder which of the two autocompletes are the one to pick.
• For categories in the Upload Wizard, people already called for this in the Upload Wizard improvements talk page, e.g. here but maybe there should be a new thread about this since it probably should be fixed and HotCat already does this. I think files are automatically moved out of redirect categories and usually also out of disambiguation cats. If somebody knows whether this is done automatically please add info about this (like how long it takes).

Prototyperspective (talk) 11:35, 11 September 2024 (UTC)

As mentioned in that thread about Upload Wizard improvements, files are moved out of redirected categories by RussBot. Based on its recent contributions it runs daily, so you should allow at least a day for a new upload to be moved out of redirected categories. --bjh21 (talk) 12:18, 11 September 2024 (UTC)

Thanks, I didn't know that there was an automated process to do this. ITookSomePhotos (talk) 16:50, 11 September 2024 (UTC)

Hopefully it's still dealt with eventually even if there's a bot to move the files. --Adamant1 (talk) 06:55, 12 September 2024 (UTC)

Proposal for a path forward for bringing together folks with a stake in Commons’ future

While at Wikimania, I was able to spend time with folks who participate in and contribute to Commons. I attended the Photowalk community session, where we had a lovely and rainy meander along a brick lined city walkway, where we saw lots of iconic buildings and neighborhoods in Katowice, as well as a lovely park and views of trains and city life. I also was able to sit down with 10 people attending Wikimania who I’d previously met and talked with me about Commons, or who had discussed my recent comments on-wiki about the future of Commons and some of the big challenges and questions we face and need to tackle together.

In that meeting, I spent a lot of time listening to perspectives and the challenges that technical contributors, photographers, organizers, GLAM advocates and individuals just representing themselves each see as we try to determine what next steps to take.

I asked the group to help me think about what comes next, and how to work together to bring the many parts of Commons together in a meaningful way, so that we can start to make some important decisions together. Any choice we make will involve tradeoffs – of attention, time and resources. And I’d like us to all be able to do that with as much information as we can bring together and put on a shared table as possible.

Some of the perspectives I heard included:

• The Wikimedia Commons Query Service doesn’t work very well and needs focus.
• Wiki Loves contests attract a lot of attention, but haven’t been optimized for getting new contributors. Things like licenses, templates and other complexities might be significant barriers to new contributors. Other sites don’t have such complex workflows and maybe attract new folks much more easily.
• Each time a project starts and ends, we lose important knowledge because we don’t have continuity across projects or anyone really working to ensure that we have continuity over time.
• Some projects focus on small batch uploads, and other projects focus on doing very large batch uploads. The disconnect in approach and goals may be problematic when trying to prioritize where we focus attention and effort, particularly from the WMF.
• We don’t have clarity about which tools should be used for producing, reusing, finding and reporting photos, and some tools that have been made don’t have enough functionality to be truly useful and to replace older tools.
• There's a tension between admins and patrollers asking for more things to prevent vandalism, but also campaign creators who want lower barriers to entry. We also have the tech communities with needs for APIs, Commons embedders who would like different features on other projects,  and yet more needs from photographers user groups, GLAM professionals, and  external reusers. We asked: how could we go about helping these folks see each other, and help everyone understand some of the tradeoffs involved in supporting such a complex project?

In listening to each other, people remarked that they could see how different people’s perspectives were, and also that there were perspectives not represented in the room. We spent some time trying to name them, and discussed what a good next step might be to try and help one another come to some conclusions about how to best prioritize the limited resources of the Foundation, and how best to ask for help from the whole of our movement.

As a result of this discussion, several people suggested that regular meetings that helped to surface and then explore the challenges we now face among Commons contributors and users would be really helpful, with the intention that this will lead us to identify key strategic trade offs.

We have a wide variety of tools ranging from very specific to very general, and we have many sub-communities with different needs and agendas. The Foundation and contributors all need to understand this landscape in order to plot a way forward together.

So my proposal for the next year or so is to start having monthly forums, where we pose some of the big questions around Commons, and come together as a community. I think this will involve a live discussion as well as on-wiki discussions to get to the heart of some of the big tradeoffs and questions that we all need to face together.

I am committed to finding a better way of supporting Commons, and I see the need to get to a shared goal and a timeframe for achieving a clear set of things. And I will need help from all of you to identify the most important problems to solve, which ones not to solve right now, and then the right kinds of solutions for supporting a vibrant Commons into the future.

Thanks for all the input so far, and I’m looking forward to connecting with more of you in the near future! SDeckelmann-WMF (talk) 22:01, 10 September 2024 (UTC)

Thanks Selena. Strange that video has not been discussed. Ymblanter (talk) 18:31, 11 September 2024 (UTC)

@SDeckelmann-WMF, maybe some things I said in my comment here are of interest to you when requesting resources for Commons at WMF. Maybe some improvements to Commons can be seen as secondary, but Commons as a whole in no way is so. Unlike other WMF projects (all of them important as they are), Commons content is continuously shown in Wikipedia articles themselves, so Commons is, in some way, truly part of Wikipedia, without question. MGeog2022 (talk) 11:18, 14 September 2024 (UTC)

September 11

Proposal: AI generated images must be clear they're AI in the file name

Now these are being used for a good purpose (reporting on the misuse of AI at en:Wikipedia:Signpost) so please don't just nominate them for deletion, but look at these filenames:

File:Amoeba moving.jpg File:Leukocytes.jpg

Now I've moved them to File:AI genetated image of... - but that's just actively setting people up to use semi-believable illustrations that have no scientific accuracy, and then making it relatively hard to catch what happened.

Should we be somewhat stricter about filenames for AI? There's cases where I think it matters less than these, but the capacity to mislead is high. Adam Cuerden (talk) 10:01, 11 September 2024 (UTC)

Oh, there's also File:Cancer cell.jpg, now File:AI generated image of a cancer cell.jpg which is not used anywhere, and looks ridiculously misleading. That's just the AI giving the cell its own tumor. Actually, maybe that should be in that article about misleading AI Adam Cuerden (talk) 10:05, 11 September 2024 (UTC)

File names for AI generated images not indicating that's what they are is definitely an issue. There's no reason there shouldn't be some indication in the file name that an image is AI generated. I think it would be in alignment with the changes to guideline on how to name files that was passed recently to. Regardless, file names should be as descriptive as possible and I can't see why that information shouldn't be included in the file name. --Adamant1 (talk) 11:02, 11 September 2024 (UTC)

An alternative would be to add a tag to the media without requiring files to be moved or named with that in the title from the start. Just like any NSFW image has an indicator for that on sites like reddit. It would be shown on all files in Category:AI-generated images either at the end of the file-title or e.g. within a corner of the thumbnail. I think adding that automatically would be better. However, when uploading the file using the Upload Wizard and checking made with AI one could also automatically append (AI-generated) or (made using AI) to the file-title. Prototyperspective (talk) 11:29, 11 September 2024 (UTC)

Is it really misleading if people cant be arsed to even read the template? Trade (talk) 11:30, 11 September 2024 (UTC)

The template only shows on the file page. And even there it doesn't look very different from other common license templates which people only interested in the content usually probably don't look at either and many files like the linked examples don't even have these templates. Prototyperspective (talk) 12:47, 11 September 2024 (UTC)

 Support The file name and caption are the first things you see when you select an image that's used on Wikipedia for better viewing, right before you click through to the file's own page. For most people it'll probably be the only information they'll see. This information is absolutely important enough that it should be mentioned in the file name. ReneeWrites (talk) 13:03, 11 September 2024 (UTC)

 Support per ReneeWrites. I agree that having AI generated marked in the file name will give Wikipedia users much more transparency on the provenance of files. William Graham (talk) 15:36, 11 September 2024 (UTC)

 Oppose. Nice idea, but I prefer templates that can be translated and add properties. Latin letters in a filename are not a good clue in other scripts. We may have endless rename requests. File naming hacks are also not systematic; we do not routinely encode other properties in filenames. Glrx (talk) 15:47, 11 September 2024 (UTC)

At the same time, an actively misleading filename is a problem. They are not leucocytes (for example. They don't even look much like cells. AI is very good at creating images that look like they're plausible depictions but really aren't, they just ape the - for lack of a better word - art style of real scientific illustrations, coloured electron microscope depictions, and so on. Adam Cuerden (talk) 16:05, 11 September 2024 (UTC)

we do not routinely encode other properties in filenames - We routinely use naming systems like "Flag of [Country]" for other types of files. Using filenames to make important disclosures about the origin of files isn't a huge leap. Omphalographer (talk) 19:11, 11 September 2024 (UTC)

@Omphalographer, Well said. -- Ooligan (talk) 17:11, 12 September 2024 (UTC)

•  Support Update with caveat: my support is for this idea in principle, with the understanding that we would need an additional discussion about implementation to cover things like wording. — Rhododendrites ^talk |  12:32, 12 September 2024 (UTC) This is a good idea, and in line with the spirit of many off-wiki policies proposed for AI content. It also doesn't preclude a template. The question, though, is what label/language should be used. It would need to be something someone wouldn't choose accidentally for a non-AI image. Also, documentation for this rule would need to be clear that we're talking about media that is produced through generative AI models (as opposed to, say, a scientific visualization in which machine learning was used somewhere in the process). — Rhododendrites ^talk |  16:10, 11 September 2024 (UTC)

  I wouldn't be too concerned about language necessarily. If the filename is not in a language people speak, they're much more likely to check the decription. We don't need a perfect solution, just an improvement. Adam Cuerden (talk) 16:14, 11 September 2024 (UTC)

• Comment - This is a good idea, but it needs refinement. Besides Rhododendrites's caveat's above, I think it should only apply to images which depict something in a realistic manner. There's not much point requiring this for something like File:Portrait of a Unicorn.png. Otherwise, I would only support it as a recommendation, not a requirement. Nosferattus (talk) 18:21, 11 September 2024 (UTC)
  • What harm would it be to apply it to that image, to make clear (a) this is not a human-made illustration, (b) this is not a Lisa Frank image, etc.? — Rhododendrites ^talk |  18:33, 11 September 2024 (UTC)
    • We shouldn't be mass changing file titles without a compelling reason. It just generally causes chaos. I think files being factually misleading is a compelling reason, but otherwise, I'm not convinced. Nosferattus (talk) 16:57, 15 September 2024 (UTC)

  I'd say there's a class of images where it matters less. But a human-made illustration probably has some effort to get key aspects, whatever those might be. AI just tries to get something that looks like other images with similar key words, and might miss out important bits that a human wouldn't. Honestly, as a general rule, the higher the likelihood it'd be used on Wikipedia, the more that's an issue. Adam Cuerden (talk) 19:34, 11 September 2024 (UTC)

  Agreed on Nosferattus' conditional support: images that can be mistaken for something else, should be marked, and the filename is the most obvious place to do so. By the way, this also applies to photoshop fabrications of "real life flower elfs" etc. And from a filemover perspective: We are supposed to only rename files that are realistically going to be kept. Is there even a rationale to keep misleading non-scientific AI illustrations? I mean, beyond illustrating how you can't trust AI illustrations? --Enyavar (talk) 00:01, 13 September 2024 (UTC)

  Aye. These couple are useful to illustrate the problem, but we certainly don't need more. Adam Cuerden (talk) 15:22, 14 September 2024 (UTC)

   Oppose for now, unless proposal is substantially modified to address concerns above. Nosferattus (talk) 16:53, 15 September 2024 (UTC)

•  Support, as we should use any (and all) means to achieve maximum transparency for re-users about the non-authenticity of AI-generated images. --Túrelio (talk) 18:27, 11 September 2024 (UTC)
•  Support: I don't see any downside. One remark, though: like everything else on Commons, this should not be restricted to English, and I don't imagine I would recognize something if it were marked in Chinese as AI. How do we intend to deal with the multilingual aspect of this? - Jmabel ! talk 19:32, 11 September 2024 (UTC)

  As I said above, I think that perfection isn't needed. If it's labelled in Chinese, as long as the whole filename is in Chinese, Anglosphere people will presumably go to the description. They might not for one that has a plausible English filename. Adam Cuerden (talk) 19:37, 11 September 2024 (UTC)

  Yep. In a Czech file name, the warning should be in Czech, and in a Japanese file name, in Japanese - tailored to the native languages these images are likely to get used for. And if I'm that determined to use a cool image with Tamil filename in the German WP, I the user must make sure to understand the filename and description. (GTranslate exists.) --Enyavar (talk) 00:10, 13 September 2024 (UTC)

•  Support: Let´s do it. Transparency first. Alexpl (talk) 20:11, 11 September 2024 (UTC)

 Support as a general idea. Would this extend to AI-upscaled images, which can get very strange at the deep end? Belbury (talk) 20:39, 11 September 2024 (UTC)

How do I unsee that image?! Omphalographer (talk) 22:58, 11 September 2024 (UTC)

Extremely disturbing heh Bedivere (talk) 04:49, 12 September 2024 (UTC)

 Comment from a filemover. If you want to apply this requirement to files after upload, you should amend Commons:File renaming to make it clear that lacking a statement of AI-generation in the filename is good cause for renaming. Either by adding a new numbered criterion or by finding a way to shoehorn it into an existing one (2 or 3, I'd guess). --bjh21 (talk) 21:01, 11 September 2024 (UTC)

@Bjh21: You could argue, in clear cases like the ones I mentioned earlier, it's already covered by 2, since they aren't actually pictures of (say) leukocyctes, but I agree that adding an example would help. Adam Cuerden (talk) 20:40, 12 September 2024 (UTC)

@Adam Cuerden: I think you mean 3 (obvious error), and I agree that would cover clear cases like those. But there are other cases that I don't think would be covered, like File:White generic hatchback.png or File:Wikimedia LGBT+ graphic illustration 1.png. --bjh21 (talk) 21:48, 12 September 2024 (UTC)

Fair. Adam Cuerden (talk) 10:01, 13 September 2024 (UTC)

It'd be nice to expand criterion 2 to allow adding information about the non-factual nature of an image in general (e.g. AI generated images, simulations, reenactments, historical reconstructions, artistic representations, etc). Omphalographer (talk) 22:40, 13 September 2024 (UTC)

Aye. Certainly in the spirit of, but explicitly permitted never hurt. Adam Cuerden (talk) 15:23, 14 September 2024 (UTC)

• I believe that ALL substantially manipulated or fabricated images, that might be misunderstood as "real", should be very clearly marked. It shouldn't depend only on whether someone decides or rules that the fabrication method was "AI". ITookSomePhotos (talk) 21:37, 11 September 2024 (UTC)

  Fair, but this is an easy "bright line" case. We can easily spot AI by tags and upload tools, Adam Cuerden (talk) 15:23, 14 September 2024 (UTC)

 Support, probably difficult to enforce though given the backlogs of other bad file names needing renaming (screenshot, whatsapp, etc). Gnomingstuff (talk) 22:28, 11 September 2024 (UTC)

 Support AI generated images must have "AI" in the file name as a principle, perhaps even better would be "AI generated", which is more clear. And always at least in Latin letters. Yes, the backlog might be a problem, but we can start now for new uploads. --JopkeB (talk) 05:12, 12 September 2024 (UTC)

What do people think about when uploading the file using the Upload Wizard and checking made with AI one could also automatically append (AI-generated) or (made using AI) to the file-title? (No replies on that above or on the idea of a tag displayed dynamically next to the file-title and in the thumbnail.) I think doing something automatically and in a standardized way would be better than just requiring this which many uploaders will not follow up on. Prototyperspective (talk) 10:49, 12 September 2024 (UTC)

Given that the Upload Wizard already asks about AI tools, I think it would be appropriate for it to ensure that uploads using them follow whatever policy arises from this discussion. --bjh21 (talk) 17:26, 12 September 2024 (UTC)

•  Support All AI images must use this required prefix phrase: "AI generated image of..." -- Ooligan (talk) 05:58, 12 September 2024 (UTC)

 Support. on top of this, if we need to rename these files, i suggest requiring the new name to begin with " «AI generated» " or " ~AI generated ". this will make them appear behind all ascii letters when sorted alphabetically. RZuo (talk) 13:58, 12 September 2024 (UTC)

If you want to change where something sorts, I think it's better to do it using {{DEFAULTSORT}} rather than by requiring a particular pattern in the filename. --bjh21 (talk) 15:46, 12 September 2024 (UTC)

@Bjh21, Can we do both? -- Ooligan (talk) 16:47, 12 September 2024 (UTC)

@Ooligan: I can't see why you would want to, but you certainly can. --bjh21 (talk) 17:23, 12 September 2024 (UTC)

this is just an idea that can be done with no extra cost, when the file will be renamed anyway. RZuo (talk) 20:50, 12 September 2024 (UTC)

Probably doable through the AI templates. Something like {{DEFAULTSORT:«{{BASEPAGENAME}}}} Adam Cuerden (talk) 21:05, 12 September 2024 (UTC)

Please no. This makes file names unnecessarily difficult to type - most keyboards don't have «» keys, and ~ is difficult to find on many mobile devices. The goal is to label these files, not to make them difficult to use. Omphalographer (talk) 22:53, 12 September 2024 (UTC)

Agreed. DEFAULTSORT is the better solution for de-prioritizing AI images. ReneeWrites (talk) 07:23, 13 September 2024 (UTC)

+3. Adding special characters to file names should be banned. --Adamant1 (talk) 07:42, 13 September 2024 (UTC)

It really depends on the meaning of "Special", lest we ban, say, Korean file names, or accents. We have French filenames with French-style quotes in them, and we shouldn't change those. At the same time, we have default sort; let's not make it a policy to name AI images File:💩AI generated💩 Foobar.jpg Adam Cuerden (talk) 10:03, 13 September 2024 (UTC)

That's not really what I'm talking about. I don't think arbitrary putting brackets in file names is useful though. Maybe circle brackets, but «» or ~. If for no other reason then most keyboards don't have them to begin with. I'm also super annoyed by file names with emojis them though. They should 100% be banned. I'd be totally fine with requiring people put (AI generated image) at the end of a file name though. --Adamant1 (talk) 10:50, 13 September 2024 (UTC)

Aye, merely trying to avoid bad policy coming out of this. Should we append characters at the start of filenames to deprioritise them? No. That's a job for {{DEFAULTSORT}}. But «» are the standard quotes used in French, so we shouldn't ban their use, lest we require bad French. I'm a little bit of a stickler for trying to avoid policy for one situation that screws up other situations. Adam Cuerden (talk) 15:38, 14 September 2024 (UTC)

Keep it simple. Just put "AI" infront of the filename. Those who want to know more can check the summary / category of a file for details. Alexpl (talk) 11:06, 13 September 2024 (UTC)

Please rather put it at the end of the filename. Moreover, "AI" is ambiguous and also included in many other files, so again I'd suggest (AI-generated) or (made using AI) and this could be appended to the initial file-titles automatically in the Upload Wizard. Prototyperspective (talk) 11:24, 13 September 2024 (UTC)

• Oppose Use a template, similar to {{Retouched}}. Note that we already have non-AI files with names beginning "Ai ". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:17, 13 September 2024 (UTC)

  The examples people have brought up in support or as examples in this discussion include "AI generated", not just AI. Edit: Except for Alexpl's comment. ReneeWrites (talk) 14:22, 13 September 2024 (UTC)

• Support When images are used internally editors know to check the filepage, when outside people reuse the images they are usually not aware of the info on the files page. We have had people reusing images without complying to the terms of the license by naming the creator. I would like to see (AI generated) the way we use "(cropped)" in file names. --RAN (talk) 18:06, 13 September 2024 (UTC)

  Ooh, that's a good point - if a user saves an image from Commons (or another wiki) to their computer, for instance, there's a decent chance that its file name will remain intact as a warning. A template on the file's talk page certainly won't. Omphalographer (talk) 18:13, 13 September 2024 (UTC)

  Yes, I agree. @Richard Arthur Norton (1958- ) & @Omphalographer -- Ooligan (talk) 02:57, 14 September 2024 (UTC)

•  Strong oppose no no no, file names shouldn't be used for that. This opens up Pandora's box for controversial subjects. This should be in the file description, not in the name. Multichill (talk) 12:53, 15 September 2024 (UTC)

Working out changes

I'm sensing pretty widespread support, so let's plan out what would need changed:

1. Commons:File renaming: #2 gains "To identify AI generated works" with a possible more general version of "to point out major manipulations" (colourization, etc). This is explicitly allowed to be in any language.
   • 1b. Also Commons:File naming, under "Clear".
2. Commons:AI-generated media notes that the AI-generation must be mentioned in the filename, ideally in the same language as the rest of the filename.
3. File upload wizard appends "AI generated" if the AI creation option is ticked, with the option to change this after, but with a note saying that identifying AI art in filenames is important. Alternatively, this can just be a soft prompt, that suggests a new filename, but doesn't require. (Similar to others where you can click "ignore and upload file anyway)
4. Possibly, {{PD-algorithm}} and similar can be edited to add a {{DEFAULTSORT}} to move AI works lower in categories.

Have I missed anything, and anyone have suggestions? Adam Cuerden (talk) 19:55, 14 September 2024 (UTC)

I think #4 should either not be implemented or be for files in Category:AI misgeneration. Images shouldn't be sorted by how they were produced but by by where the user is expecting to find them / looking for them or generally the relevance and quality of the image as it relates to the category concept, not the method/techniques used to produce it. You may have missed an addition to Commons:File naming. Prototyperspective (talk) 20:40, 14 September 2024 (UTC)

Added File naming, and you're probably right about #4. Wanted to pull all the suggestions made, but that may be too much (if nothing else, AI image categories wouldn't do the headers for first letter of filename). Adam Cuerden (talk) 11:44, 15 September 2024 (UTC)

#3 and #4 are terrible ideas. #3 will cause uploader confusion, filename conflicts, language issues, etc. This needs to be done by humans, not machines. #4 will also be confusing as no one will expect {{PD-algorithm}} to mess with the sorting. Plus it's just unneeded and potentially unhelpful, as there may be other reasons an AI-generated file needs to be sorted in a particular way. Nosferattus (talk) 17:05, 15 September 2024 (UTC)

Footage from security cameras in the US

Someone remind me again what is the copyright status of this? Trade (talk) 11:34, 11 September 2024 (UTC)

• Robotic cameras have no human creator and are not copyrightable, unless a human operator takes over to point the camera. --RAN (talk) 12:48, 11 September 2024 (UTC)

  so what template do i use? Trade (talk) 14:39, 11 September 2024 (UTC)

  @Trade: {{PD-ineligible}}.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:46, 11 September 2024 (UTC)

  @Trade: {{PD-automated}} ReneeWrites (talk) 14:49, 11 September 2024 (UTC)

  @ReneeWrites: Thanks, that works better.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:16, 11 September 2024 (UTC)

September 12

Help in closing CfD

Hello, it would be extremely helpful if some users could read the CfD and weigh in their opinion at Commons:Categories_for_discussion/2024/09/Category:Towers_in_Iran#Resolution. —Matrix(!) {user - talk? - _uselesscontributions} 17:29, 12 September 2024 (UTC)

Just close it guys asap, any way to do so is good, as per the comment there: "To avoid further edit warring and loss of brain cells... " . It is utterly inconsequential how these categories are called, see the arbitrariness categorization theory here: Fuzzy_set. These (potentially mis-)categorized pics are searched for in (and by) multidimensional vector spaces anyway: LLMs; via image recognition engines: Computer_vision, and that is for the starters... Zezen (talk) 05:54, 14 September 2024 (UTC)

Just an FYI, but the CfD doesn't have anything to do with what the categories are called. It revolves around if main categories for towers should be child categories of ones for buildings by shape. Since at least IMO, "tower" isn't a shape. Regardless, it's not about the names of the categories. --Adamant1 (talk) 06:38, 14 September 2024 (UTC)

Re: 'if main categories for towers should be child categories of ones for buildings by shape' - same problem (or lack of it): the debate over whether “towers” should be categorized under “Buildings by shape” could be seen as a matter of degree rather than a strict yes-or-no decision. This approach (see again fuzzy sets, recursive ontology entities...) acknowledges that categories can overlap and that elements can belong to multiple categories to varying extents. In practice, see: Thomas Aquinas who discussed smth similar in Summa Theologiae, Part II (On Angels) Chapter LII § 3: "Whether Many Angels Can Be in the Same Place at the Same Time [e.g. at the needle's pin]"...

The only practical answer: "😔 possibly..." Zezen (talk) 13:03, 15 September 2024 (UTC)

Created a derivative work, unsure how to tag it when uploading

Good evening. I've created a derivative of the work File:Balanced_justice_scale_silhouette,_small.svg, featuring the same image, but overlaid with a red X. The use of this work will be to create a "No legal threats" template, for use on the English Vikidia website. Could you please tell me, while uploading, how I should tag a derivative file, or whether that comes as part of the upload process? Thanks! DaneGeld (talk) 20:05, 12 September 2024 (UTC)

You can add the {{Derived from}} template to link the original file and its author. And add the {{Derivative versions}} template to the original file to link back. For example: File:Cumulus clouds in fair weather.jpeg and File:Cloud.jpg. William Graham (talk) 20:37, 12 September 2024 (UTC)

Thank you! I have already found the "Derived from" template, which is on the derivative I've created - File:Balanced_justice_scale_silhouette_(crossed_out),_small.png. The other one you linked is the one I have been looking for, so I appreciate your help in linking me to it. Regards, DaneGeld (talk) 20:52, 12 September 2024 (UTC)

@DaneGeld: What happened to the chains for the baskets? Nosferattus (talk) 16:47, 15 September 2024 (UTC)

@Nosferattus: Now that's odd. I see the chains when I look at the file on my PC, and when I view the file on commons. I presume what I have is a cached version which I should have purged. My guess is that I've not grouped the chains with the rest of the image before saving the file, and then exporting it. I'm not too well at the moment, but I'll correct the error tomorrow, and re-upload the file. Thanks for pointing it out! DaneGeld (talk) 19:13, 15 September 2024 (UTC)

Super-CfDs

Hi everyone, we recently had an alert about the CfD on the issue of “Georgia” here in the village pump, and now I realized that “Historical images” is eerily similar. The result of this second CfD was essentially: "delete and upmerge to Category:History". There is sound reasoning to do so, but we're talking about the previous parent category to numberless sub categories (I cannot even give estimations on a probable number... tens of thousands?), which are currently all in a waiting list for getting deleted and upmerged, one by one. This campaign is lasting for months already, I have no clue what the percentage of completion is on that front. Various angry protests of various kinds against this action have not been organized well, and the prevailing counter-argument is: "the CfD lasted many years, we reached consensus, there were no counter-proposals".

My concerns on this issue were close to nil previously (again: there was sound reasoning), but now I've checked Commons:CFD for guidelines on CfDs that process multiple categories. The guidelines imply that the concerned categories should be mentioned in the CfD, but that was not done in either of these two cases. Only the top-most parent category was put up for debate, and I'm fairly certain now: The reason it took five years to gather a meager ten votes was not because there was no interest. Rather, there were only ten votes because close to nobody was aware that this debate was ongoing. Not until the bulldozers arrived at the front doors.

Sound reasoning and good intentions or not: Not notifying those who are going feel the impact of your decision, is the behavior of the Vogons from "Hitchhiker to the Galaxis".

The particular CfDs I linked initially should not be debated here. I'd rather like to focus on our CfD procedures. In fundamental cases like these two mentioned above - can we agree that all concerned child categories (i.e. the ones that are going to be affected by the CfD, because of similar naming conventions) should have the same CfD notification in their header? --Enyavar (talk) 23:31, 12 September 2024 (UTC)

Commons:Categories for discussion/2024/09/Category:Towers in Iran, mentioned a couple of threads above this, is another CfD that would affect a hundred categories but has only been raised against one (and not even the top one). Belbury (talk) 07:52, 13 September 2024 (UTC)

I wouldn't say Commons:Categories for discussion/2024/09/Category:Towers in Iran is the same as the one for "historical images" because there's a pretty clear guideline I was following. The CfD was only started because someone decided to edit war me and a couple of admins over it. Otherwise the CfD wouldn't have been necessary. I don't really think it was necessary to notify everyone who came within 100 miles of a "towers" category in the last 20 years in that case though. Since again, 99% of the issue that led the CfD was caused by a single user.

Really, the same goes for the "historical images" CfD. Although I do think it should have at least been announced on the Village Pump after it was closed. It clearly wouldn't have been workable for the closing admin to notifying everyone who was going to be impacted by it though. Same goes for the nominator putting a CfD notification in the header of every category involved. It's ridiculous to suggest people should notify hundreds of people or put a notification in the header of potentially thousands of categories just for the outcome of a CfD to be valid. Neither one is really a fair, workable way to do things. There should have at least been a notification about the outcome of the CfD for "historical images" on the Village Pump once it was closed though, but that's more then enough IMO. --Adamant1 (talk) 08:11, 13 September 2024 (UTC)

I think it would be better if a large-scale CfD was announced at the village pump right after it was opened rather than closed, so more people can read the discussion and participate. Once a discussion is closed you're not supposed to start it up again. ReneeWrites (talk) 14:20, 13 September 2024 (UTC)

Either way. The main issue for me is that I just don't think it's fair to expect whomever opens the CfD to add the notification template to hundreds or thousands of sub-categories. Although it's debatable what makes something a "super-CfD" to begin with and the expectation should be that people normally find them through Commons:Categories for discussion. To the degree that it's not a good way to find important CfDs is more about the backlog then anything. It wouldn't be as much of an issue if there wasn't such a huge backlog though. ---Adamant1 (talk) 06:53, 14 September 2024 (UTC)

Of course, we have so many CfDs, and what I called here "Super-CfDs" are exceptionally rare. Just because a CfD is about a top-most super-category (like here) does not mean that all sub-categories need to be notified. In case of Category:Past, only the super-category itself will be affected, no cascading effects. So no need to notify, of course.

But: Once it becomes clear that a CfD will have impact on its structured subcategories (like deletion or renaming), all these subcategories should get a notification. These rare and special discussions are long-lasting anyway, so if there are hundreds or more of impacted subcategories that all have the same naming structure (like "Historical images of" or "in/of Georgia"), a bot-job should be tasked with inserting the CfD-note on all these subcategories. This should not be the job of the original CfD-opener (for example, in case that the CfD is uncontroversially rejected or doesn't change anything in the sub-categories). But once it becomes clear that a large impact will happen as a result, then a wide-spread notification is necessary, before continuing the CfD for another appropriately long time. And I would hope that our guidelines can be amended, to include this as a future rule. --Enyavar (talk) 12:52, 14 September 2024 (UTC)

I guess you could do it with a bot. But it seems like derailing to put the notifications on the pages once it becomes clear that a CfD will have impact on its structured subcategories. There's already going to be clear consensus to delete or rename the categories at that point. So the only reason to find more people to participate in the CfD would be to change the outcome. Especially since people who created the categories to begin with, which realistically are the being notified about the CfD at that point, are going to vote to a certain way. How is that any different then canvasing? --Adamant1 (talk) 22:36, 14 September 2024 (UTC)

September 13

Feedback research

Mandatory settings must be made regarding image classification before uploading them. Otherwise, the site will be flooded with images and it will be difficult to find images when searching. Mohmad Abdul sahib 02:05, 13 September 2024 (UTC)

It's unclear what you're asking for. Files have filetitles and categories and both are used (alongside descriptions) to find and organize images. Prototyperspective (talk) 21:43, 13 September 2024 (UTC)

Is there a categories need to be improved tag?

There is an uncategorized tag, but what about a categories need to be improved tag? Like something I would add in the event that I see a random photo on a farm somewhere in Japan but all it is categorized as is just "Japan" Immanuelle ❤️💚💙 (please tag me) 04:37, 13 September 2024 (UTC)

@Immanuelle: yes, {{Check categories}} and the corresponding Category:Media needing category review. MKFI (talk) 06:28, 13 September 2024 (UTC)

You can dissiminate it it easily into:

• Category:Unidentified plants
• Category:Unidentified landscapes
• (there’s no Category:Unidentified farms, maybe it should)
• Category:Unidentified locations in Japan

It’s a start whence other people can pick from. -- Tuválkin ✉ ✇ 18:28, 13 September 2024 (UTC)

There's also Category:Files needing categories‎ (see Category:Commons needing categorization). Tools to easily/quickly add the mentioned tag would be useful as well as scripts adding it to files. Many of un/badly categorized files are problematic or simply low-quality. Prototyperspective (talk) 21:47, 13 September 2024 (UTC)

I was going to mention Category:Unidentified locations in Japan. I'm not a super big fan of the whole "unidentified" category thing myself but there doesn't seem to be anything better at this point. --Adamant1 (talk) 21:53, 13 September 2024 (UTC)

Crop Tool SNAFU

Crop tool is not working, again. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:24, 13 September 2024 (UTC)

What's SNAFU? --PantheraLeo1359531 😺 (talk) 14:23, 13 September 2024 (UTC)

Situation Normal: All Fucked Up. Means the Crop tool is broken but this is not unusual. ReneeWrites (talk) 14:52, 13 September 2024 (UTC)

Ah thank you :) --PantheraLeo1359531 😺 (talk) 16:32, 13 September 2024 (UTC)

"! 502 The CropTool backend is currently having problems." is one message I have gotten all day. -- Ooligan (talk) 00:42, 14 September 2024 (UTC)

Community Wishlist: Let’s discuss how to improve template discovery and reuse

Hello everyone,

The new Community Wishlist now has a focus area named Template recall and discovery. This focus area contains popular wishes gathered from previous Wishlist editions:

• Wish #1: Quickly add infobox – an easier way for newer editors to find and insert common templates such as infoboxes.
• Wish #2: Quickly add favorite and related templates – a way to show recently used templates and favorited templates for frequent template use.
• Wish #3: Select templates by categories – a way to find templates by "type".
• Wish #4: Easy access templates – help users configure the Template dialog to show common and favorite templates.

We have shared on the focus area page how are seeing this problem, and approaching it. We also have some design mockups to show you.

We are inviting you all to discuss, hopefully support (or let us know what to improve) about the focus area. You can leave your feedback on the talkpage of the focus area.

On behalf of Community Tech, –– STei (WMF) (talk) 16:06, 13 September 2024 (UTC)

@STei (WMF): : Just check the thread about this one. Here’s one for the Community Wishlist: the WMF should drop their nonsensical makework, for it breaks tools maintained by the community. -- Tuválkin ✉ ✇ 18:10, 13 September 2024 (UTC)

I think that focus area is far less important than other focus areas that would save contributors much time and also less relevant to WMC than other focus areas or proposals. Maybe sharing a link for all proposals that are WMC-related would be useful (such as the one about WMC media dumps or a WMC copyvio-detecting bot). These template wishes all just seem like nice-to-haves without much benefit and which aren't solving a real problem but can and are implemented quite well by editors and bots sooner or later. Prototyperspective (talk) 21:52, 13 September 2024 (UTC)

W. A. Schulenburg of Copenhagen

Can anyone find out more about this photographer File:Sophus_Theodor_Pihl_(1840-1888)_by_W._A._Schulenburg.png to fill out their Wikidata page. --RAN (talk) 18:09, 13 September 2024 (UTC)

September 14

Fate of image that is broken, wrong, unused and duplicated simultaneously

The image in question was brought to the Graphic Lab when User:Swiãtopôłk discovered it displays as a white rectangle. After looking at it, I found that:

• The image uses some exotic SVG features, but is easy to fix
• Once fixed, it is almost identical (except empty space) to File:OceanGate_logo.svg
• This is not what the flag of OceanGate looks like. Sources: [6][7]
• Nothing obvious uses it.

I can think of some solutions:

• Leaving it alone
• Overwriting with actual flag, once available (creation requested and I'll probably do it)
• Overwriting with fixed version
• Fixing and renaming
• Fixing, renaming and reusing the name for the actual flag
• Speedily deleting as broken and usused
• Speedily deleting as a duplicate
• Speedily deleting and reusing the name

etc. What's the proper way to deal with it? Gabuxae (talk) 07:42, 14 September 2024 (UTC)

If fixed it's a duplicate, one would use {{Duplicate}} and it would end up being deleted and redirected.

However, as "flag" would be misleading, I'd just have it deleted.
 ∞∞ Enhancing999 (talk) 22:34, 14 September 2024 (UTC)

The file had a classic Inkscape bug, so it should display properly with Inkscape. It would have displayed properly on Commons until April 2024.

The file has been around for a year, so I would not just delete it; there should be a redirect.

For me, I would not bother deleting the file. It represents the OceanGate logo, so any errors are minor. If you believe the file does not represent the flag, then add {{Fact disputed}} with the reason.

So I'm mostly in the fix the file and then leave it alone camp. Glrx (talk) 15:52, 15 September 2024 (UTC)

Requesting some simple category renaming

I believe his should be easy for someone who uses AWB.

The subcats of Category:Interchange Exit Direction Signs in the United States by state all need "Signs" capitalized. "Sign" is part of the proper noun, as documented by the link at Category:Interchange Exit Direction Signs in the United States. - Jmabel ! talk 09:13, 14 September 2024 (UTC)

@Jmabel It might be better of you can add it to User:CommonsDelinker/commands so the bot can do that -- DaxServer (talk) 10:17, 14 September 2024 (UTC)

That would be another way, though if renames are done, Cat-a-lot makes the rest easy.

What I'm trying to avoid is 43 non-trivial by-hand actions, and putting it in User:CommonsDelinker/commands editing each category name into the correct format to make the request. - Jmabel ! talk 20:49, 14 September 2024 (UTC)

@Jmabel:  Done with a bit of AWB and mostly copypasta in Notepad++, see here.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:53, 15 September 2024 (UTC)

September 15

Own work selfie upload with a contested "no permission" tag

See File talk:Sanija selfie.jpg

COM:MYWORK says: Usually, stating that it is a selfie will suffice if that is really the case, though in some cases you may be asked for additional evidence.

I have stated that there is no reason to ask for additional evidence because (1) it very much is really the case that the photograph is a selfie, (2) there is no reason to ask for additional evidence relative to any given case of a user uploading a selfie from a pseudonymous account, which is the default and expected scenario, (3) there is mild circumstantial evidence (yes, mild evidence, but there is no evidence to the contrary as far as I can tell) that the uploader specifically is the subject and the author (explained on the linked talk page).

So there is no reason that this should be the case when additional evidence is requested.

Under these circumstances, as the tag is controversial, I believe that it is time for a COM:DR discussion to finally determine if additional evidence is genuinely needed or not. When one user considers the permission to be missing and another the permission to be present (present insofar as the uploader who is the author added the CC BY-SA 4.0 license at the time of the upload), surely the way to resolve the disagreement is a deletion discussion. However, instead of substantively discussing, one file mover threatens that they will delete the file, which they technically can accomplish using a combination of actions that they are technically privileged to as a file mover, but in terms of the deletion policy, it would be improper for them to so.

I admit that I could be wrong about how this should be handled, and I could be missing some fact or circumstance, in which case I apologize. I tried talking on that talk page, and one contributor supported the view that this is a legitimate own work selfie, but there is no dialogue and the file is simply heading for deletion as if the talk page had never existed. Therefore, I ask for a community review of this situation, and my suggested resolution is to remove the tag and start a deletion discussion.—Alalch E. (talk) 01:27, 15 September 2024 (UTC)

It looks like a selfie. The question for me would be if she is the same person who uploaded it. Probably not. That can easily be dealt with though by having her or them send permission to the Volunteer Response Team. Although even at that point there would still scope/PROMO issues. But they probably don't matter since she's a politician. The more important thing is verifying that her and uploader are the same person or that they have permission to upload the image if they aren't her. --Adamant1 (talk) 02:03, 15 September 2024 (UTC)

There are no scope issues because the pic is perfectly functional as illustration for her Wikipedia articles, and is being used so in various languages without issue. About the same person question: I really don't see why "probably not". What's the reason for suspicion? Alalch E. (talk) 02:12, 15 September 2024 (UTC)

I meant as far as it being uploaded purely for promotional purposes. Which I don't think images get a pass on if they are being used on other projects. Especially if the image is of the person who uploaded and their the one's who added it to their own Wikipedia article. As to why I don't think the uploader is the same person, different names and the fact that the selfies are available on other websites. It's immaterial though. They should still be required to send VRT permission for the image anyway. Especially since again, the image is already out there on other places. What's your evidence that it was just uploaded from another website by a random PR person for Sanija Ameti or something? --Adamant1 (talk) 05:14, 15 September 2024 (UTC)

We don't really need to get into who has what degree of suspicion. Given that some suspicion exists, COM:VRT would be the right way to sort this out. - Jmabel ! talk 15:54, 15 September 2024 (UTC)

Request to delete previous version of file

Hi. I like to delete older version of a file but I can't manage to find the correct way to do it. Should I go to deletion request, contact administrator or there are a another dedicated page for it ? — Preceding unsigned comment added by Nicolas22g (talk • contribs)