We are currently categorizing all media needing categories as of 2020. Progress is good so far, as shown on Category talk:All media needing categories as of 2020, but the task is getting increasingly more difficult, because the 'low hanging fruit' have been harvested by now. Do you want to help us? If so, please leave a comment about your approach or your achievement either here or on the discussion page.--NearEMPTiness (talk) 08:21, 30 December 2025 (UTC)Reply

One way is to categorize the trees in the pictures. Example File:954I8789 نمایی از زن و مرد گردشگر در درکه - تهران.jpg and File:954I8790 زن و مرد گردشگر در درکه - تهران.jpg. However I cannot read Arabic, so I dare not place it in a country category.Smiley.toerist (talk) 12:44, 30 December 2025 (UTC)Reply

But, please, if all you can do with an image that is clearly supposed to depict a place is to categorize a tree, don't remove it from Category:All media needing categories as of 2020! - Jmabel ! talk 19:22, 30 December 2025 (UTC)Reply

A few months ago I went there, categorized a few images (spent quite some time geolocating them), provided some ideas at the talk page which were fully, totally ignored by that community as if I do not exist. Not going to do it again. Ymblanter (talk) 19:33, 30 December 2025 (UTC)Reply

I don't think that you should feel ignored, keeping in mind that "no criticism is praise enough." Implementing procedures to fight the backlog will take some time. It's a task for unsung heroes, who are sufficiently self-motivated to categorise files or to motivate uploaders to to it themselves. --NearEMPTiness (talk) 20:15, 30 December 2025 (UTC)Reply

@Jmabel: I completely agree with the comment “don't remove it from Category:All media needing categories as of 2020!“, but the problem is that when using Cat-a-lot it automatically removes it. Wouter (talk) 07:54, 31 December 2025 (UTC)Reply

This is false – in the preferences there is the setting "Remove {{Check categories}} and other minor cleanup" which one could uncheck. Prototyperspective (talk) 18:33, 12 January 2026 (UTC)Reply

Cat-a-lot makes it easy to add the category Unidentified people to all photos of people, for example. The user can be proud because now so many images have a category added. Another user has then to solve the problem with "Unidentified people" with over 31,000 images. I've personally noticed that there are images with the person's full name in the description and that also have a Wikipedia article. Wouter (talk) 10:10, 31 December 2025 (UTC)Reply

This is a very good comment, indeed. I have subsequently categorized some of these people and found that this is easier than categorizing those grouped by dates. Thus, I think it is helpful, to put them temporarily into this category. You may skip the mass uploads starting with a number, if you want to categorize them manually. --NearEMPTiness (talk) 03:50, 5 January 2026 (UTC)Reply

You can combine the research of several people and get a result: File:Bakkikayam.jpg The description is in the Malayalam language. This limits the picture to the Indian state of Kerala, or the union territories of Lakshadweep and Puducherry (Mahé district). This is a dam on some river. But I dont want to speculate.Smiley.toerist (talk) 15:58, 9 January 2026 (UTC)Reply

Sometime the research is incomplete. File:Bernard Becker & wife Janet.jpg, There is an Wikipedia article about Bernard Becker. One problem is that he died in 2013, so this picture cannot have been taken in 2017.Smiley.toerist (talk) 16:20, 9 January 2026 (UTC)Reply

Based on the metadata and image quality, I have the impression that the photo was not taken in 2017, but that a scan of a photo was made in 2017. Wouter (talk) 19:25, 9 January 2026 (UTC)Reply

I have added a before date.Smiley.toerist (talk) 09:54, 11 January 2026 (UTC)Reply

Thanks for this effort. However, I think it's not nearly as useful and needed as for example categorizing files in Category:2020s maps of the world in unidentified languages (complete) or Category:Renewable energy charts with unspecified year of latest data (under construction) or Category:Diagrams in unspecified languages (under construction) or Category:Renewable energy charts in unspecified languages (complete) for example or any of the requested tasks in Commons:Categorization requests.

There also is the issue that most of the files in these needing-categories cats are of low quality and/or low usefulness/relevance so what categorizing them does is

• cluttering categories
• creating work for those contributors who keep these categories clean and well-subcategorized

Prototyperspective (talk) 18:41, 12 January 2026 (UTC)Reply

We are making good progress: 24,000 media needing categories as of 2020, but we need more volunteers, to clean the backlog by reviewing these files one-by-one or by semi-automated procedures. NearEMPTiness (talk) 10:04, 11 January 2026 (UTC)Reply

Does someone know what the Italian phrase 'Coletti Gino' means? I categorized the first one, but maybe better if some Italian works on this.Smiley.toerist (talk) 23:46, 18 January 2026 (UTC)Reply

It seems to be some Italian person: it:Gino Coletti Smiley.toerist (talk) 23:50, 18 January 2026 (UTC)Reply

Warning: These four images are modern pictures taken with an i-phone, so the actual location is incorrect and all of the same place.Smiley.toerist (talk) 23:45, 19 January 2026 (UTC)Reply

I hope not to many files land in broad unknown categories. There are stil some frustrating files without location: example: File:Italy- handbook for travellers. First Part, Northern Italy and Corsica (1869) (14597135680).jpg. It could be in France (Corsica or Massilia? (in Provence?)).Smiley.toerist (talk) 11:12, 24 January 2026 (UTC)Reply

Hi, I would like to discuss the description in all categories of the scheme "Maps of <country> in the <x>th century" (see for example Italy, Belgium, Spain, Poland). There are three different points about the current system I would like to invite comments on:

• the wording of the definition in the first paragraph of the hatnote
• whether or not to include "you may also be looking for similar maps" (second and third paragraph) of the description
• whether or not to re-include a distinction between history maps (in this category group) vs. old maps (not in this category group)

For the first point, there are two proposals, the first is the current "Maps showing all or most of the territory (geographic area) of modern-day <country> - as the lands were in the 8th century (701-800 CE)" which I would prefer to replace with a simple "This category is about maps of the history of <country> in the 8th century (701-800 CE)", given that "modern-day territories" are not always the same as they were in the respective century. Another critism of mine is that "all or most" excludes history maps that only cover smaller parts of the country in question.

For the second point, my argument is that these paragraphs are not necessary, since the links to the Atlas project should be included in the respective parent category (i.e. "Maps of the history of <country>"), which is also linked via template.

For the third point, I find it essential to point out that Commons has always distinguished "current", "history" and "old" maps, formulated in Template:TFOMC: "history" maps include this map of Poland in the 16th century (created recently, depicting the past) but "old" maps include this 16th-century map of Poland (created to depict the present, back then). There are certain grey areas where these categories DO overlap, especially "old history maps", but in quite many cases they don't. The respective category names are quite similar and can be confused, so I would suggest to mention this right in the category description.

I've put my own opinion in italics to explain why I think this requires debate, but I would like for people to check out the scheme examples for themselves, and judge on their own. Peace, --Enyavar (talk) 08:11, 2 January 2026 (UTC)Reply

@Enyavar: I'm trying to understand the first point. A couple of questions that may help me understand:

• Would there be no such thing as "maps of Germany" for any date before 1866? Or would we take "Germany" before that date to mean the German-speaking world (and, if so, would that include areas where the rulers spoke German, but most of their subject did not)? or what? (Similarly for Italy.)
• Similarly: would there be no such thing as maps of Poland or Lithuania between 1795 and 1918? If so, what would we call maps of that area in that period?

I could easily provide a dozen similar examples, but answers to those two will at least give me a clue where this proposes to head. - Jmabel ! talk 18:49, 2 January 2026 (UTC)Reply

Thanks for that question, our categories about "history of" do not really care for nation states existing. Germany's history begins quite some time before it became a nation in the 19th century, and Polish history did not stop during the times of division: Poland in the 19th century is unquestionably a valid category. Our history categories generally imply that people know the limits of a subject without exact definitions.

Your question is getting to the reason why I am uncomfortable with the current hatnote/definition of these categories. I have not checked for all countries in Europe, but I'm quite confident: We do not define the subject of "Maps of the history of Poland" with a hatnote. We do not define "Poland in the 16th century" either. So why would we define the combination subcategory of the two so narrowly and rigidly, that only 6 out of 26 files currently in the category even match that (unreasonable) definition? (And of course, Poland/16th is just a stand-in here, I would argue the same for Spain/12th and Italy/8th and all others)

I would even be okay with no definition at all, besides a template notice (my third point) that "maps of <country> in Xth century" is about history maps, and old maps have to be found in "Xth-century maps of <country>". --Enyavar (talk) 04:53, 3 January 2026 (UTC)Reply

Categories denoted as old, or historic, are not terribly useful. Much better to put dates on them. Rathfelder (talk) 17:05, 15 January 2026 (UTC)Reply

Please read the original post, that is not a comment on the actual questions of this topic. Old maps are not the topic here, this is about history maps (i.e. Maps showing history of specific countries/centuries) regardless of when they were produced.

The term "historic maps" that can denote both, has rightfully fallen (mostly) into disuse. --Enyavar (talk) 16:23, 17 January 2026 (UTC)Reply

Hello everyone and happy new year 2026,

Following Stewart Xaosflux's guidance and request, allow me to inform the Commons community that I requested a one month extension for my temporary importer rights to finish Lingualibre.org/wiki/'s selected imports toward Commons:Lingua Libre. See the previous discussions and votes there :

• Commons:Village_pump/Archive/2025/10#Migration_of_Lingua_Libre_project_pages_to_Commons - scope and initial approval
• meta:Steward_requests/Permissions/2025-11#User:Yug@commonswiki_(importer)
• meta:Steward_requests/Permissions#Yug@commonswiki_(2)
• Commons:Lingua Libre#Current status

Best regards. Yug (talk) 19:14, 3 January 2026 (UTC)Reply

I'm adding 10 days temporarily while this is open. @Yug: when this closes please drop a new request at SRP. If 2 months is what you need, please express that here. — xaosflux ^Talk 20:06, 3 January 2026 (UTC)Reply

Hello User:Xaosflux,

As discussed here, I'm depending on other users collaboration for Translations pages, we will see if 10 days will be enough. Yug (talk) 20:57, 3 January 2026 (UTC)Reply

What I meant was that it would be at least long enough for this discussion to come up with a consensus. — xaosflux ^Talk 00:44, 4 January 2026 (UTC)Reply

[EDIT] Please express your position on this userrights extension. Yug (talk) 21:31, 10 January 2026 (UTC)Reply

•  Support I seem another extension would be warranted given that Yug has already been able to do much of the task. ─ Aafī on Mobile ^(talk) 18:41, 14 January 2026 (UTC)Reply

 Support Given that the project has already been approved and seems to be going smoothly. Chrs (talk) 21:51, 14 January 2026 (UTC)Reply

 Support per others above, the migration project seems to be going well and the user seems to be using their rights responsibly. Thanks. Tvpuppy (talk) 22:07, 14 January 2026 (UTC)Reply

• Steward note: this has been extended for 3 months. — xaosflux ^Talk 18:07, 18 January 2026 (UTC)Reply

i think it'd be a good idea to copy cat names (if english) to en label (if empty) or en alias of the wd item it's linked to, if it's not already present in any language on the wd item.

for years i'm annoyed by this problem. now it's especially irritating when the same thing has different names for depicts and category. RoyZuo (talk) 00:47, 10 January 2026 (UTC)Reply

There is no clear priority among Wikipedia, Commons, and Wikidata for naming an article/category/item. I don't see how we can say Commons dictates to Wikidata any more than vice versa. - Jmabel ! talk 02:10, 10 January 2026 (UTC)Reply

In the absence of any English name for an entity in Wikidata, using one from the Commons category seems like a reasonable starting point. Omphalographer (talk) 03:05, 10 January 2026 (UTC)Reply

Bot has been doing this for years. Multichill (talk) 18:43, 10 January 2026 (UTC)Reply

1. it didnt seem to do that for these 5000 recent edits spanning over 4 days https://www.wikidata.org/w/index.php?title=Special:Contributions/Pi_bot&target=Pi+bot&offset=20260107122856&limit=5000
2. it didnt add the commons cat name back as an alias since 2015 for https://www.wikidata.org/w/index.php?title=Q7452846&action=history

so either it needs to do that a lot more frequently, or it needs to be restarted. RoyZuo (talk) 21:52, 11 January 2026 (UTC)Reply

Agree that this would be good to do. I think this thread about a technical subject should be moved to the Commons general discussion forum about technical subjects, COM:Village pump/Technical. Prototyperspective (talk) 00:36, 13 January 2026 (UTC)Reply

Or d:Wikidata:Project chat as this concerns edits on Wikidata. Samoasambia ✎ 01:49, 20 January 2026 (UTC)Reply

Hello, hundreds of my files have been modified like 1 or 2, making my watchlist giant to reset. User:MB-one, as the performer, do you have a solution? The problem has been evoked at COM:ANU and participants said the edits were tagged "QuickCategories", however now the tags are different ("AC/DC" or "openrefine"). My mail box is full of unread notifications, and I don't know how to reset each file without patiently clicking on all links. Help much welcome! -- Basile Morin (talk) 02:14, 10 January 2026 (UTC)Reply

Your files have not been modified, their description pages have. That is what we do here, collaboratively edit a wiki. You choose to have every edit create an email notification for you it seems, so then this one of the risks. Luckily email filtering is easy, and selecting a bunch of notifications and deleting them all at once is also pretty easy. And you can of course choose to disable the notifications. —TheDJ (talk • contribs) 11:12, 10 January 2026 (UTC)Reply

Their description pages have... The sound of wisdom 💫 :-)

User:TheDJ, "That is what we do here": thanks, but after 14 years on this project, this is the first time I have so many notifications on the same day.

Question about your recommendation: "deleting them all at once is also pretty easy", then do you think the notifications will be maintained by the system, for example in case of vandalism, wrong edit, or just basic update? In my opinion, no. -- Basile Morin (talk) 12:32, 10 January 2026 (UTC)Reply

The notifications will not be saved, but the underlying edit history is always kept. Even for deleted files, it is still available to admins. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:44, 10 January 2026 (UTC)Reply

Hello @Basile Morin,

yes, some of these edits are created with AC/DC or Openrefine as well as QuickCategories. I am using a combination of these tools for efficiency reasons. You can filter filter out these edits on your watchlist and opt-out of e-mail notifications. If you spot errors in these edits, you can reach out to me on my watchlist and I will correct them.

Cheers, MB-one (talk) 11:20, 10 January 2026 (UTC)Reply

MB-one you used "QuickCategories" at the beginning, then "AC/DC" and "Openrefine", maybe tomorrow "Nirvana" and "Whatever". Is there a full list of all the tags likely to produce the same hurricane, to filter them in advance? -- Basile Morin (talk) 12:32, 10 January 2026 (UTC)Reply

@Basile Morin, Besides these three I'm currently working also with QuickStatements and Hotcat. All these tools tag their edits accordingly. However, I can not guarantee that I will never use any other mass edit tool. And I certainly not speak for other users. I'm not aware of there's any possibility to group all "mass edit" tools together and filter all of them at once. But maybe that's a good feature request.

Cheers, MB-one (talk) 13:50, 10 January 2026 (UTC)Reply

Aren't camera characteristics structured data usually added by bots? Bot edits are easy to filter. Nakonana (talk) 21:23, 10 January 2026 (UTC)Reply

It could technically be done by bots. However, since there's no bot doing this work currently, I decided to do what I can. MB-one (talk) 21:17, 17 January 2026 (UTC)Reply

Makes sense. Probably it would be good to request the development of a bot for this or the addition of a task to an existing bot at Commons:Bots/Work requests if you haven't done so.

Another thing I forgot to mention below is that one could also hide all structured data edits, this seems to be what m:Community Wishlist/W5 is about. Prototyperspective (talk) 23:00, 19 January 2026 (UTC)Reply

@MB-one i think you should use a bot account if you make thousands of edits like this batch https://editgroups-commons.toolforge.org/b/OR/c3d78ad5204/ . RoyZuo (talk) 19:08, 17 January 2026 (UTC)Reply

See also en:User:Nardog/RCMuter – This script allows you to "mute" users you specify, i.e. stop seeing their edits, on watchlist and recent changes. To mute a user, click "Edit muted" below the top heading on watchlist or recent changes and enter their name, or click "Show toggle buttons" and click "mute" in the list. The list of muted users is stored in your account's preferences, so it is not public and is shared across devices.. Prototyperspective (talk) 13:14, 13 January 2026 (UTC)Reply

Are edits like [1] and [2] in accord with policy or against it? I'll say it straight out: I'm against this. "Photographs" is the default and we do not need to introduce an extra layer of categories all over the place. But we certainly should go one way or the other on this, and do it consistently.

Pinging @GT1976. - Jmabel ! talk 00:17, 14 January 2026 (UTC)Reply

I'm against it as well. We don't need the extra layer of useless categorization. Pi.1415926535 (talk) 00:27, 14 January 2026 (UTC)Reply

Hello! This structure with photographs has been standard for years, and millions of photos are categorized within it. However, I have no problem with this intermediate level being omitted. Best regards, --GT1976 (talk) 02:06, 14 January 2026 (UTC)Reply

This is in accordance with policy according to COM:CAT, specifically the modularity principle. "October 2007 United States photographs" is a subcategory of "October 2007 in the United States" and it's part of a long-standing and broadly-utilized category structure, at the bottom of which you find (for the first photo) Category:United States photographs taken on 2007-10-26.

We have had similar discussions before recently, and I feel like a lot of the issues people have with photos being moved from a visible category to the hidden "country photos by day" categories would be solved if we just unhid those categories.

I also disagree that "photographs" are an unneeded layer of abstraction; the content and structure of Category:October 2007 in the United States is very different from Category:October 2007 United States photographs. ReneeWrites (talk) 09:39, 14 January 2026 (UTC)Reply

It's reasonable to say the default is the media format images which is e.g. why Category:Images by subject was turned into a redirect (it's a subcat of the Category:Images which is linked at the very top of the very front page). However, that doesn't go for photographs vs other images. Nevertheless, in various categories photographs may be the default – probably fewer than you assume or think and imo not in this case: it makes sense to distinguish videos (and other files?) from photographs at Category:October 2007 in the United States. The issue I think comes down to what I asked about at COM:CAT – it would be better to not subcategorize things like that / create subcategories like that unless the categories are populated by the subcat-creator quite comprehensively so don't give users a wrong impression of what is there and are useful and not extremely incomplete.

The caveat here however is that with the MediaSearch one can already separate videos from images dynamically so there isn't necessarily much use of this subcategorization if the user knows that this is possible and how it is possible. It can still be useful but due to this caveat I haven't formed any personal conclusion yet on this and maybe you're right that this subcategorization shouldn't be done where I would just object to your claim "Photographs" is the default which sounds like bias from somebody who happens to be involved with lots of photographs-categories and photo-uploads but which isn't the case for other types of users, contributors, files, and categories (e.g. there is nearly no photo in the large Category:Our World in Data). For now, I'd just leave things as they are and maybe considering creating a comprehensive carefully-thought-out CfD at the relevant large-order cat and/or RfC including some ideas for changes. GT1976 and ReneeWrites make good points.

The previously mentioned way to browse or search or filter files via MediaSearch works like this (note: does not work for some categories with long chains of subcats): deepcategory:"October 2007 in the United States". Prototyperspective (talk) 12:09, 14 January 2026 (UTC)Reply

I had this issue, too in my categorization. The photographs cat is actually my category I prefer. The "October 2018 in the United States" is probably for things like events or so, but not so much needed as photographs. --PantheraLeo1359531 😺 (talk) 15:23, 17 January 2026 (UTC)Reply

Hi, does anyone know why I (or maybe more users) get logged out, even when I place a √ at 'keep me logged in' while login in? - Inertia6084 (talk) (talk) 22:48, 15 January 2026 (UTC)Reply

Did this happen only recently? I was wondering why sometimes I get logged out. It seems to be a technical issue (and maybe it would be good to move this to Commons:Village pump/Technical). However, for me it's very far from every ten minutes or so. Did this never happen before and now very often? Prototyperspective (talk) 23:17, 19 January 2026 (UTC)Reply

Hi all. I've stumbled upon a photograph that was uploaded from geograph.org.uk File:Side of the Angel, Midhurst - geograph.org.uk - 3891742.jpg - the problem with this photo is that it is not as described in the title or description due to an error on the part of the photographer - it is actually the side of the next building along. The description etc. is pulled from a template (Template:Geograph from structured data), so can't be changed - I've added a correct summary of the subject below, so there are now two conflicting descriptions, also the title of the file remains incorrect - what would normally happen in cases like this? Is there an established way to correct photo descriptions of files imported via the geograph.org.uk project? Many thanks, Simon Burchell (talk) 09:53, 16 January 2026 (UTC)Reply

Change the structured data. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:43, 16 January 2026 (UTC)Reply

If the file name needs to be changed, use the template {{Rename}}. Nakonana (talk) 17:32, 16 January 2026 (UTC)Reply

And if you want to preserve the old name for reference, you can use {{Original caption}}. - Jmabel ! talk 21:52, 16 January 2026 (UTC)Reply

I've recently created {{Corrected metadata}} with the intent to better document factual problems in the original metadata, and document why we corrected it. I think we should be clearer about what we change from the sourced metadata than we do now, and provide links to our reasoning for doing so. Hadn't completely finished it yet, but it's out there. —TheDJ (talk • contribs) 08:38, 19 January 2026 (UTC)Reply

Thanks! Simon Burchell (talk) 10:02, 19 January 2026 (UTC)Reply

The file still has two {{Information}} when there should be only one. As far as I understood it, the solution is pointed out here in the first comment: changing the SD (this does not seem to be about the exif metadata). Prototyperspective (talk) 12:51, 22 January 2026 (UTC)Reply

Hello, in Category:Paintings in the National Gallery, London by inventory number I intend to list the paintings by inventory number. There are a few thousand. How do I structure this so that a table of contents allows one to navigate without clicking next umpteen times? Thank you, Maculosae tegmine lyncis (talk) 16:30, 17 January 2026 (UTC)Reply

Have you checked Category:TOC templates or Category:Navigational templates for a suitable template? Nakonana (talk) 16:38, 17 January 2026 (UTC)Reply

Certainly, but I couldn't anything suitable/intelligible. It looks like it's easy to sort by the start of the category name, eg Category:800 births, Category:801 births, but what if the categories are named as in Category:Paintings in the National Gallery, London by inventory number? How does one apply a ?sortkey? so that the (inventory) numbers in Category:xxxxNG101 Category:xxxxNG5203 etc can be picked up by a category's table of contents? Or can one at least have a navigator to eg page 8 or page 20 of subcategories within a category? Thank you, Maculosae tegmine lyncis (talk) 18:48, 17 January 2026 (UTC)Reply

We don't normally use categories this way. This would be a much better case for one or more gallery pages. - Jmabel ! talk 20:25, 17 January 2026 (UTC)Reply

That would have its advantages... (Category:Objects in the National Archaeological Museum of Athens by inventory number is a similar case.) Thanks, Maculosae tegmine lyncis (talk) 01:43, 18 January 2026 (UTC)Reply

@Maculosae tegmine lyncis: As Jmabel pointed out, it sounds like a gallery is more likely to get you the result you're looking for (sorting by inventory number, not having pagination). The National Gallery of London has a gallery page such as that, which can be found here: Paintings in the National Gallery, London. ReneeWrites (talk) 09:43, 22 January 2026 (UTC)Reply

As said, a gallery would probably be the right approach but you could also have the unique ID at the beginning of the subcat names and/or the file names so that one can navigate by that (there's TOC templates for cats). Prototyperspective (talk) 12:47, 22 January 2026 (UTC)Reply

(from COM:FORUM) I might be picky, but I noticed something. Let's pick Category:21st-century photographs of Berlin. The 21st-century ranges from 2001-01-01 to 2100-12-31. If we pick the subcat Category:2000s photographs of Berlin, we get the years 2000 to 2009. Yes, the year 2000 is within the 2000s, but not within the 21st-century. So we have a correct categorization of 2000 in the 2000s, but not the 21st-century. Since Category:2000s photographs of Berlin is not completely contained in set Category:21st-century photographs of Berlin, it should also be categorized in Category:20th-century photographs of Berlin, because of the last 20th-century year 2000. What do you think? :D --PantheraLeo1359531 😺 (talk) 19:56, 17 January 2026 (UTC)Reply

Strong oppose. The purpose of categories is to help people find things, not to express ontology.

While this may be technically correct from a prescriptive point of view, it goes against common usage.

Further, this would have the additional problem that every category pertaining to the first decade of a century would no longer fit neatly in a century category. - Jmabel ! talk 20:29, 17 January 2026 (UTC)Reply

 Oppose per Jmabel. ReneeWrites (talk) 21:01, 17 January 2026 (UTC)Reply

 Oppose per above. This feels particularly unnecessary given that, in practical terms, it only affects the year 2000. (There's orders of magnitude less media categorized as 1900, 1800, etc.) Hopefully we'll have better ways of representing this data before 2100 rolls around. :) Omphalographer (talk) 01:11, 18 January 2026 (UTC)Reply

Thank you for your responses :). Yes, a new structure would be more complicated :) --PantheraLeo1359531 😺 (talk) 10:25, 18 January 2026 (UTC)Reply

we could just ditch all these intersections of time and place. instead have simplest cats like 2000-11-11 and paris. when people want to search a time period, the search automatically helps them to find files from a well defined range, e.g. 2000-01-01 to 2009-12-31 for 2000s, 2001-01-01 to 2100-12-31 for 21st century...

or people should just learn to count from 0 and use a Holocene calendar that starts from year 00000. then 0th century for year 00000 to 00099, 1st century for 00100 to 00199... 120th century for 12000 to 12099... then decades 12000s to 12090s are all well contained in the 120th century. RoyZuo (talk) 15:15, 18 January 2026 (UTC)Reply

Maybe it would be better if eg the 21st century started at 1st January 2000. I think many people and probably most think it does start at that point. Moreover, en:Category:21st century also includes 2000-related categories. Valid point and good it's raised but currently this can't really be dealt with anyway. Prototyperspective (talk) 23:10, 19 January 2026 (UTC)Reply

I agree. As we don't have a year zero, the first year of the 1st century is 1, and it goes on in the next centuries, so that every century has the same length (if we ignore phenomena like leap years/leap seconds etc. ) --PantheraLeo1359531 😺 (talk) 12:44, 21 January 2026 (UTC)Reply

Not sure what you agree with but regardless of what you mean: it would probably be good or needed to add an info about this to some categories like Category:Centuries and all top-level subcats, probably via editing template(s) including Template:centurybox. Prototyperspective (talk) 13:07, 21 January 2026 (UTC)Reply

✝iѵɛɳ२२४०^{†ลℓк †๏ мэ} 13:34, 18 January 2026 (UTC)Reply

I am writing to you to let you know the annual review period for the Universal Code of Conduct and Enforcement Guidelines is open now. You can make suggestions for changes through 9 February 2026. This is the first step of several to be taken for the annual review. Read more information and find a conversation to join on the UCoC page on Meta.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. This annual review was planned and implemented by the U4C. For more information and the responsibilities of the U4C, you may review the U4C Charter.

Please share this information with other members in your community wherever else might be appropriate.

-- In cooperation with the U4C, Keegan (WMF) (talk)

21:01, 19 January 2026 (UTC)

(This message was sent to Commons:Txokoa and is being posted here due to a redirect.)

Hi all,

I often see titles such as "DSCF1234" or "qwerthjkl" on Commons.

I also happen to develop an upload tool for Commons.

What do you think about the opt-in experiment below?

• Detect such titles using a local-only (thus privacy-friendly) small LLM.
• If it is such a title, show a tooltip such as "Make sure to write descriptive names, see Commons:File_naming".
• This would be a separate version of the app, that only people who really want to try this experiment would download.
• If the experiment goes well, I would consult the community again and possibly let more people use it.

I know the community feels strongly about AI, which is why I am consulting here. To be clear, the LLM resides on the local device, and never uses the Internet, nor reports query content to anywhere.

Any feedback welcome, thanks! :-) Syced (talk) 08:36, 20 January 2026 (UTC)Reply

I like the idea, but wouldn't a local LLM (or a SLM/small language model) use up significant amount of RAM/CPU? Leaderboard (talk) 08:46, 20 January 2026 (UTC)Reply

Yes, it does take RAM! CPU, not so much: less than a second for this detection, possibly doable while the user does something else like picking depictions. This project is focused on the long-term horizon, and in the future an embedded LLM will probably sit in memory of the OS, ready to use by any program, so using it will not take more RAM. :-) Syced (talk) 08:27, 22 January 2026 (UTC)Reply

i think people who care enough to use such apps dont write gibberish captions in the first place? RoyZuo (talk) 13:13, 20 January 2026 (UTC)Reply

The app in question actually does get some gibberish (sigh). I try to monitor all uploads and warn such users, but I believe that explaining in realtime (before the upload) is more efficient. Also, realtime explanation increases chances of turning a "silly" newcomer into a long-term contributor. Banning them or admonishing them after the upload(s) decreases chances of them becoming a long-term contributor. Syced (talk) 10:37, 22 January 2026 (UTC)Reply

no i dont mean the app you are already using, but "separate version of the app, that only people who really want to try this experiment would download". those who would enter the experiment dont write gibberish in the first place.

i agree with you about being nice and helpful to new users. i have also made several proposals in this direction over the years. RoyZuo (talk) 15:56, 22 January 2026 (UTC)Reply

The Upload Wizard is actually already catching some of those generic filenames, especially the "DSC_" or similarly styled ones, and warns about their use. That may only be a reminder, not a prohibition, which could explain that some uploads still sport such names. The other, more probable, reason is found in imports from Flickr et al., where the names aren't really filtered. Regards, Grand-Duc (talk) 13:56, 20 January 2026 (UTC)Reply

Yes, I think reminder is the best way to go, because some common names from my region may look like gibberish to an English speaker haha. By the way, an LLM would probably be able to tell the difference (further testing will be needed to confirm this). Syced (talk) 10:44, 22 January 2026 (UTC)Reply

Sounds like sth for Commons talk:WMF support for Commons/Upload Wizard Improvements. I don't know if your proposal is about file titles or captions or both (the latter would probably make most sense). Prototyperspective (talk) 17:11, 20 January 2026 (UTC)Reply

file titles or captions: both :-) Syced (talk) 10:38, 22 January 2026 (UTC)Reply

something's wrong with Commons:File requests/header such that it makes the reply function fail on pages transcluding it, but i cant figure out why. could someone more skilled take a look please? this problem has been bugging Commons:File requests for years. RoyZuo (talk) 11:09, 20 January 2026 (UTC)Reply

I don't know what the cause is but it's one of the things I requested to be fixed at m:Community Wishlist/Wishes/Fix the issues breaking the Reply tool (voting open!) where I will add your example.

Either way, please do not post more threads about technical issues/subjects to general VP but to the board about technical issues, Commons:Village pump/Technical. Prototyperspective (talk) 17:14, 20 January 2026 (UTC)Reply

Isee people go through gymnastics to upload files. Could the instructions be improved? Krok6kola (talk) 01:20, 21 January 2026 (UTC)Reply

Could you please give more details about how you try to upload photos and what specifically you find difficult? Thanks. -- Infrogmation of New Orleans (talk) 01:36, 21 January 2026 (UTC)Reply

Probably sth for Commons talk:WMF support for Commons/Upload Wizard Improvements but lacking explanation. The upload buttons are well-visible. Prototyperspective (talk) 13:04, 21 January 2026 (UTC)Reply

The primary reason it is difficult, is because we need to know a lot about a file before we can host it. This is very uncommon to most people and not really an experience people are used to or questions that people have ever had to think about before doing it here. —TheDJ (talk • contribs) 09:34, 22 January 2026 (UTC)Reply

Do we have a page like en:Wikipedia:Link rot/URL change requests fr reporting usurped URLs that are linked from multiple Commons pages?? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:58, 21 January 2026 (UTC)Reply

Do we track this with a category? It is an intersection of two categories, but one that is being actively tracked by other organizations because of the connection between concussive brain damage and suicides. RAN (talk) 16:07, 22 January 2026 (UTC)Reply

I don't think so. I agree that it's a potentially interesting intersection from an encyclopedic perspective, but it's not relevant to the media we host of these people. Omphalographer (talk) 19:07, 22 January 2026 (UTC)Reply

We have images of news articles on American football players who died by suicide, I think that is what people may be looking for. We also have images of people where too little is known about them to create a Wikipedia article, it would just be a few sentences, and be a perma-stub. --RAN (talk) 20:05, 22 January 2026 (UTC)Reply

Technically it's not relevant for the media we host to categorize people by when or how they died in general, unless the category contains media related to that death (very few of them ever do). But seeing as the parent category exists and is used in this manner, I wouldn't be opposed to an intersecting category about this being made. ReneeWrites (talk) 20:36, 22 January 2026 (UTC)Reply

I wouldn't be opposed to this category (I've definitely found examples of this while doing my uploads of 1920s photographs). Abzeronow (talk) 01:10, 23 January 2026 (UTC)Reply

If we do this, we need to define what level of playing football qualifies someone to belong in the category. I wouldn't want to see this include, for example, someone who played high school football for a year and then killed themself in their 70s. - Jmabel ! talk 01:40, 23 January 2026 (UTC)Reply

Could be wrong but I think the American football players already is just for professional-level American football players. At most, at the top-level there could be some photos of amateur players too but these wouldn't be moved to any subcat (unless there is eg a cat for this type of photos) or at least not this one. Prototyperspective (talk) 11:18, 23 January 2026 (UTC)Reply

Such categories should not exist. They only create edit wars on cases where the cause of death is unclear. This is a job for Wikidata and Wikipedia, not for Commons where we are not able to add references to categories. GPSLeo (talk) 12:05, 23 January 2026 (UTC)Reply

• We already have Category:People who died by suicide, so not controversial. --RAN (talk) 19:25, 23 January 2026 (UTC)Reply

Do disambiguation categories belong in the surname categories? Should Category:John Smith be in Category:Smith (surname)? They do not appear to be in them currently. RAN (talk) 18:30, 22 January 2026 (UTC)Reply

Disambiguation categories are navigational tools, and often group different kinds of subjects that merely share a name (people, places, fictional characters, etc.), which makes them unsuitable to be categorized like this. The John Smith disambiguation page for instance not only includes people, but also a publishing company and a film with this name. ReneeWrites (talk) 20:32, 22 January 2026 (UTC)Reply

Should disambiguation categories also contain images of the people listed? When looking for the correct person, sometimes it is easier to visually identify the correct person, rather than just looking at occupations and birth and death dates. Disambiguation categories currently read: "This category page should not hold any files." I think they should contain a single image of each person being disambiguated, preferably a close crop of the face. RAN (talk) 18:56, 22 January 2026 (UTC)Reply

Neutral, but if we do this it should be a <gallery> element after the text. Absolutely opposed to categorizing images in a disambiguation category, almost guaranteed to be a maintenance nightmare. - Jmabel ! talk 19:54, 22 January 2026 (UTC)Reply

Do we already have a bot that removes all images from the disambiguation categories? If so, your solution would be perfect. I find uncategorized images of people, where the name of the person in the title or description, and have been trying to assign them to the correct person. Visually this is a lot easier. Think of how many John Smiths we have. As we grow, the number of uncategorized people with similar names grows. Anyone that does category maintenance on people, knowns the problem of people assigned to the wrong category, because they have a similar/same name. --RAN (talk) 20:07, 22 January 2026 (UTC)Reply

There isn't a bot that removes images from disambiguation categories as it's uncertain which category they belong to, but disambig categories with media do get put in a maintenance category for manual (human) review (Category:Non-empty disambiguation categories). There are bots that move content from redirects, though. ReneeWrites (talk) 20:21, 22 January 2026 (UTC)Reply

To categorize people, I first search Wikipedia for their name. If the description is in Spanish, I search the Spanish Wikipedia page. Based on the estimated age of the person in the image, I can select the most likely candidates and view the corresponding pages. If there's an image, it's easy. Otherwise, the sources can provide a clue. Wouter (talk) 20:39, 22 January 2026 (UTC)Reply

Galleries for visual identification for subcategories aren't uncommon - see Category:Categories with a gallery for a better choice of sub-categories. I don't see any reason why we couldn't extend it to disambig pages, though I'm not sure how useful it would be. Pi.1415926535 (talk) 21:08, 22 January 2026 (UTC)Reply

There are no pages or files in this category is superfluous. Can the mediawiki software recognize {{Disambig}}? --Henrydat (talk) 18:22, 24 January 2026 (UTC)Reply

Not dissimilar to the suicide-related category question above. Wondering what other folks think about the phrasing on this category. Wikidata and English Wikipedia style does not attribute deaths to AIDS directly, in line with the medical consensus; people with AIDS who died as a result of their condition almost always die from a related infection or illness, so the terminology is usually "from/due to AIDS-related illness" or "from/due to AIDS-related complications". I'm not sure if this was just truncated for space reasons ("Deaths from AIDS-related illness" is longer than "Deaths from AIDS", but not that long), or if it was an oversight/unintentional. Thoughts? 19h00s (talk) 13:26, 23 January 2026 (UTC)Reply

I think this would be better to discuss the normal way via a CfD (category for discussion) where the cat could be renamed to e.g. Category:Deaths associated with AIDS. Prototyperspective (talk) 14:03, 23 January 2026 (UTC)Reply

Thanks, done! Anyone interested please feel free to chime in, I'm not personally sure which alternative makes the most sense/is the most appropriate. 19h00s (talk) 14:59, 23 January 2026 (UTC)Reply

I want to rename a large number of files. About 1000 files. I don’t want to file manual requests is there a way to do this that doesn’t cause issues for the filemovers? Immanuelle ❤️💚💙 (please tag me) 21:48, 23 January 2026 (UTC)Reply

A month ago I renamed 1200 files in 16 hours, so 1000 files is a lot of work, hours and hours, but it is possible. I don't like bot moves for renaming, but that's my personal opinion, as you can see. - Inertia6084 (talk) (talk) 21:52, 23 January 2026 (UTC)Reply

I see you're not a file mover (yet). Then I leave it to somebody else, to answer this. The 1200 was nice to do, but not a second time, lol. - Inertia6084 (talk) (talk) 21:57, 23 January 2026 (UTC)Reply

@Inertia6084 Oh okay. I am not sure how the filemover permission works either. But if it just involves clicking approve or whatever that would be easy Immanuelle ❤️💚💙 (please tag me) 22:03, 23 January 2026 (UTC)Reply

@Inertia6084 so you recommend just putting the template on them? It also might not be the best reason. But for ones like File:Sitelen-seli-kiwen-Nutan.svg I want to move them to File:Sitelen seli kiwen - Nutan.svg since I decided that the current way they are named does not explain clearly what the glyph name is vs the font name. Immanuelle ❤️💚💙 (please tag me) 21:59, 23 January 2026 (UTC)Reply

No I don't recommend that, because I thought you became file mover, but I see the request is still there. A thousand is a lot, and I'm not going to do that amount of renames anymore. Maybe someone reads this, as I said above, who knows the right answer. - Inertia6084 (talk) (talk) 22:05, 23 January 2026 (UTC)Reply

See Commons:File renaming#Mass rename. Prototyperspective (talk) 23:18, 23 January 2026 (UTC)Reply

Now you can do it, you're a filemover now. In one day is too much, it are not requests, but you have to rename it manually every time. Partly it's semi. 100 a day, and in ten days you're ready, or 200 a day (a lot) and five days. :-) lol. - Inertia6084 (talk) (talk) 17:40, 24 January 2026 (UTC)Reply

What about the tool that @Prototyperspective mentioned? Immanuelle ❤️💚💙 (please tag me) 17:46, 24 January 2026 (UTC)Reply

I think this has been proposed in the past (including sort of one time by me a decade ago), I wanted to try and bring it up again. Part of the reason to bring it up now is that WMF is working on a lot of image stuff right now, so its a good time to ask for a change if we want it. (I have no idea if WMF would allow this change as in the past there was concerns about changing the size of so many images at once. However with changes going on with how images are rendered, i suspect that may be less of an issue now. In any case, can't hurt to ask). I also think expectations on the internet have changed and people expect larger images now a days then they did a decade ago.

Currently category pages display images quite small. I am of the opinion they are displayed too small, especially when taking into account how much whitespace there is between images. I think it would be better to make them larger so that people can see the images better.

I made a comparison of options at User:Bawolff/different_gallery. I think if we are sticking to the traditional gallery, then a size of 180px would make more sense then the current 120px

Alternatively, I think the "packed" gallery mode actually looks nicer, so my actual proposal would be to change the mode type and keep the current size. You can see what that looks like here. This would also look somewhat more similar to the output of Special:MediaSearch. The main downside to this is that for very narrow images, the caption containing the file name might get cut-off due to lack of room.

As a note, currently MediaWiki only has an option to change the default gallery settings everywhere. This would affect everything: categories, Special:NewFiles, the <gallery> tag (if other options aren't specified), etc. If there is consensus to change it just for categories and not other places, that would require additional changes to MediaWiki, but I suspect would not be difficult to get added.

Thoughts? Bawolff (talk) 08:05, 24 January 2026 (UTC)Reply

Please see (and vote on if you agree) Wish413: Larger thumbnails in category views.

Even worse is the current display of categories on mobile Web; I intend to make a separate wish about that soon. Agree with what you said; you may want to add some of that to the talk page of the wish. Prototyperspective (talk) 11:49, 24 January 2026 (UTC)Reply

It would be helpful to have consensus here (assuming people agree with the idea) as that would allow me to push this through non-wishlust processes. Bawolff (talk) 16:29, 24 January 2026 (UTC)Reply

The 180px packed gallery mode looks very nice. Long captions should be collapsed. All of them should be optional. Less frequently used options will be removed. We don't need to think too much about them. What do you think? --Henrydat (talk) 19:49, 24 January 2026 (UTC)Reply

My main gripe with the standard gallery isn't the default thumbnail size, as it can manually be adjusted, but the lack of mobile-friendly (or even mobile-compatible) options. ReneeWrites (talk) 16:43, 24 January 2026 (UTC)Reply

How do we categorise images like the above, that use a rule for scale? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:17, 24 January 2026 (UTC)Reply

There's a Category:Rulers indicating scale. Belbury (talk) 15:20, 24 January 2026 (UTC)Reply

Thank you. I tried a host of terms, in various combinations, but that one didn't occur to me. I've now set up a bunch of redirects. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:41, 24 January 2026 (UTC)Reply

Legal clarification of Article 52 which deals with the use of works permanently located in public places. Here’s a breakdown:

1. Free Use: Works that are permanently located in public places such as squares, parks, or streets can be freely used and accessed by the public.
2. Restrictions on Three-Dimensional Reproductions:
- No Three-Dimensional Reproductions: While these works can be freely viewed, they cannot be reproduced in three-dimensional form.
- No Economic Advantage from Reproductions: Any reproduction of these works in three-dimensional form must not be used for economic gain.
3. Attribution: If the work includes information about its source and authorship, that information must be provided when the work is used.

The legal clarification regarding Article 52 of the copyright law in Bosnia and Herzegovina is accurate, and therefore, freedom of panorama (FOP) exists in Bosnia and Herzegovina, albeit with certain limitations.

Explanation
The provided text accurately describes the specific nuances of FOP in Bosnia and Herzegovina under Article 52 of its copyright law.

- Free Use of Public Works: The public is generally allowed to use and access works that are permanently located in public places such as parks, squares, or streets.
- Restrictions: The key limitation, which is common in jurisdictions with limited FOP, is the prohibition of three-dimensional reproductions for commercial gain. This means taking a photograph (a two-dimensional reproduction) of a public sculpture is generally fine, but creating and selling a physical replica (a three-dimensional reproduction) of that sculpture is prohibited without permission from the copyright holder.
- Attribution: Proper attribution is required if information about the source and authorship is present on the work.

These conditions confirm that while a form of FOP exists, it is a limited form that does not allow for all types of use, particularly commercial 3D reproduction.
You are also free to carefully examine the documents outlined on this page: /wiki/User:My-wiki-photos
Due to time constraints on my part, I will not make any comments on this topic.