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 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/2026/02. 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. For questions about copyright, technical matters, or help that does not relate to the general Commons community as well as proposals, please see the other discussion boards linked in the blue panel at the top. 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.

Women at the well, India, early 20th century. [add]

Centralized discussion See also: Village pump/Proposals   ■ Archive User talk:CommonsDelinker/commands#Replace images with .svg version (5 August 2025) Category talk:Heroes' Cemetery in the Philippines#RfC: Cemetery name (18 July 2025) Discussion on Copyright law of North Korea (16 March 2025) Hosting of free fonts in Commons (18 July 2024) 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.

December 30

Do you want to help, to categorise 34,000 media needing categories as of 2020, please?

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)

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)

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)

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)

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)

@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)

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)

Nice to have that preference (although hard to notice) but Hot-cat doesn't have it and it would be useful. Pere prlpz (talk) 15:26, 17 February 2026 (UTC)

Because with HotCat a message displays that asks whether or not you would like to remove this template. Simply click No there. Prototyperspective (talk) 15:48, 17 February 2026 (UTC)

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)

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)

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)

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)

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)

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

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)

We are making good progress: 7,167 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) (count was updated on 18 Feb)

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)

• 
• 
• 
• 

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

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)

This file has been overwritten and categorized by now. NearEMPTiness (talk) 09:45, 1 February 2026 (UTC)

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)

Would it be useful to start with the 5,951 images that are currently used in Wikipedia? -- Vysotsky (talk) 22:28, 25 January 2026 (UTC)

@Vysotsky: Thanks, this is a very useful link, indeed. It is relatively easy to categorize these files, especially those of people. However, I am also interested in finding high-quality photos that are not being used, because they cannot be found, unless they are better described. NearEMPTiness (talk) 08:54, 1 February 2026 (UTC)

Completely agree. Even more: categorizing photos not being used might be more important. At the same time, I think it is good to also look at the ones heavily used. Your call has worked fine so far: 34,000 uncategorized images brought back to 19,139 within one month. Thanks. Vysotsky (talk) 14:24, 1 February 2026 (UTC)

Is there any idea what the backlog is for the following years of 2011, 2012 etc?Smiley.toerist (talk) 13:36, 6 February 2026 (UTC)

The number of these backlog items is 0 – those are all solved. The number of such files used to be far smaller which is why addressing this at the source is needed. The number of files for 2025 is essentially unmanageable already. Prototyperspective (talk) 14:32, 6 February 2026 (UTC)

Sorry, I meant the years 2021, 2022 etc. Smiley.toerist (talk) 00:21, 15 February 2026 (UTC)

Question: When you clear these backlogs, do you attempt to provide meaningful categorization or do you just stick any old category on it and call it good? For years now, continuing to the present day, I've come across copyvios that have lingered on the site for years. This occurred mainly because the file contained a random, irrelevant category which effectively hid it from anyone knowledgeable about the subject. Oftentimes, they were originally uploaded by bad actors or just plain clueless contributors. Another phenomenon I've observed is with my own uploads where I didn't have time to add categories. The revision history shows an entire series of categorization edits which amount to kicking the can down the road. It's as if to suggest it's my responsibility to come back and properly categorize the files, while it's perfectly okay for them to fuck around incessantly. If you think I'm being unnecessarily mean, go read what COM:CAT says about including the most appropriate category in the tree. I believe that also applies to those editors. Taking an uncategorized file, adding Category:Men or similar, and walking away patting yourself on the back for what a great job you did is utterly ridiculous. RadioKAOS / Talk to me, Billy / Transmissions 02:54, 8 February 2026 (UTC)

I, for one, would never remove the "uncategorized" template unless I had provided one or more quite relevant categories, and when I'm going through a list like this I often am nominating files for deletion (or speedying them) when I see problems. Hence my remark above about 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 05:02, 8 February 2026 (UTC)

Yes, I fully agree that applying non-sense categories such as Category:Men or just their first name does not fulfill the objective of this exercise. I think, we should focus on enabling authors or readers of Wikipedia articles, to find relevant photos more easily. Currently, we are working on the 2020 files. Thus "anyone knowledgeable about the subject" had sufficient time to request the deletion of files. Requesting deletions can also more effectively be done in parallel to categorization. If we do not start from A to Z by alphabet, but if start by categorizing high-quality photos, for instance the uncategorized photos uploaded via Flickr. On some occasions it might be helpful, to add temporary categories such as Category:Unidentified cities or Category:Unidentified automobiles, because these are being looked after by motivated specialists. NearEMPTiness (talk) 05:18, 8 February 2026 (UTC)

A lesser problem than copyvios are the duplicates wich become visible, when placed next to each other. Sorting the category by date makes them even more visible.Smiley.toerist (talk) 11:55, 8 February 2026 (UTC)

More Information: Useful tools and some guidelines are currently collated at Commons:WikiProject Minimum One Category. We are looking forward to your contributions to this page. NearEMPTiness (talk) 06:14, 8 February 2026 (UTC)

Thanks! Also added to this page. For the category here, I think now for the files left there is a large fraction of files for which SDs, DRs, and permission needed tags would be good to add or at least probably would be good to consider using more often. In part for the sake of making it more feasible to complete this, probably the cutoff for quality/usefulness expectations may be good to raise so that eg this file and this fall beneath it (these don't add much but clutter really). Prototyperspective (talk) 23:04, 9 February 2026 (UTC)

In addition to requesting deletion, it might be useful to split some very populated categories into two parts, by using or setting-up a subcategory such as Category:Cats (low quality) or Category:Sunsets (low quality). NearEMPTiness (talk) 10:08, 10 February 2026 (UTC)

Agree. This info would also be good to add to that page. Also similar ways to separate types of images, e.g. Category:Moon from Earth instead of dumping further low-quality photos where the Moon is somewhere in the image directly into high-level Category:Moon. There's probably more similar ways that would be good for categorizers to be aware of. Prototyperspective (talk) 13:26, 10 February 2026 (UTC)

There are still approx 13682 uncategorized files, which are used on Wikipedia and related projects, as shown on Glam-Tools. Some of them can be easily categorised by using the lemma of the English Wikipedia. NearEMPTiness (talk) 21:03, 10 February 2026 (UTC)

(13682 uncategorized files overall of which 4518 are used anywhere in the wikiverse of which 3584 are used in mainspace of any Wikimedia project) Prototyperspective (talk) 23:40, 10 February 2026 (UTC)

I don't like "low quality" categories. For one thing, we have no systematic way to make such a judgement. For another, it unnecessarily insults users who may not agree with that description of their work. - Jmabel ! talk 00:45, 11 February 2026 (UTC)

Would scale better and draw in less time resources if more was done to address this issue at the source; e.g. via what's suggested at Commons_talk:WMF support for Commons/Upload Wizard Improvements#Guidance/facilitation of categorization. Then we could worry about undercategorized files (example) and other tasks. Prototyperspective (talk) 13:54, 12 February 2026 (UTC)

Location is the most important part in most cases an often frustrating: I have found three basic categories for File:Humans Being - Flickr - simiant.jpg (aquariums, Children and Pinnipedia), but the most important is where? Luckely I found the place in the flicker comments. From there I found alot more precise categories. Taken pictures from Flickr without correct descriptions is asking for problems. Smiley.toerist (talk) 23:34, 16 February 2026 (UTC)

In terms of usefulness / likely applications, unique value and where people would look for a file like this, I think more useful than location in many and this cases is some category about 'people standing in front of large aquariums'. Theoretically one could have a tool try to suggest categories based on flickr tags, flickr comments, and the albums the file is in so one doesn't have to go to the flickr page or it could load these things directly on the file page. Prototyperspective (talk) 23:48, 16 February 2026 (UTC)

It is tricky to have meaningful categories. In this case I dont think aquarium is correct. This is probably a water basin where aquatic air breathing mammals and birds swim around in, with an underwater window. No temperatur control and limited water treatment. In general I prefer using structured data to search for special combinations, instead of creating very specialized categories. SD is more flexibel and can be used by AI, scripts and search engines. Some users dont understand this and want to link combination categories to new dataitems, please dont. Dont import al the quirks and combination Common categories into wikidata. Each search system has its purpose. I would like the Common file to have at least a link to one content data item. (not the technical properties such as image size, its a picture, f-number, focal length, etc). Its easy work scanning the categories and using the SDC script. Find the correct data item by going to the upper categories until one finds a category linked to a data item.Smiley.toerist (talk) 15:07, 17 February 2026 (UTC)

Please set fitting categories and don't ask users to not set fitting categories, thanks.

And one can't even get to 'people standing in front of large aquariums' via the set SD. SD are only set on less than 2% of files and even there often missing the key thing shown or having something super broad set. Prototyperspective (talk) 15:51, 17 February 2026 (UTC)

I think the proportion is much larger than 2%, but that maybe that the subjects where I am interested, have a much larger part of SD filled. I certainly add a lot of SD to files (from categories from with data item). Have you any source for this 2%? Smiley.toerist (talk) 23:59, 19 February 2026 (UTC)

No, it's just anecdotal from a) seeing changes to many files in the Watchlist and b) checking the SD of many files. Maybe SDs are set substantially more often, but when SD is set, they 1) are often missing at least one of the key things shown (eg 'microphone' is in the depicts but not the actual point of the picture which is the person holding it) 2) aren't nearly as comprehensive as the categories. SD could be written eventually from the categories of files (afaik that's also the most common way they are set along with during upload in the UW).

Regarding 2), the SD 'Aquariums' and 'Children' on a file wouldn't imply (or only show) children standing in front of aquarium windows. Additionally, querying for this would be intuitive and overly difficult to do, assuming it works at all because one would query if anything for 'Aquariums' and 'People' where it would then have to resolve the latter to also include items tagged only with 'Children' (and countless other items).

Either way, categorization itself is already more than enough work so instead of worrying also about setting SD, imo it would make more sense to see if some things could be encouraged to be done by uploaders at upload and whether some tools could help with all of this. Prototyperspective (talk) 01:01, 20 February 2026 (UTC)

Its not either categorization or SD activity. If the files are correctly categorised (as specific as posible) its a matter of minutes to fill the SD side with the SDC script. The reverse from SD to categories is also posible, but a bit more dificult. So the research work is only done once.Smiley.toerist (talk) 13:47, 21 February 2026 (UTC)

It's down to just 4,747 files now. Prototyperspective (talk) 13:49, 25 February 2026 (UTC)

January 02

History maps of Europe

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)

@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)

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)

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)

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)

In our Commons:WikiProject Postcards we have the similar problem. Is this a "old postcard of the German Empire" or a "Postcard of Germany". There we are mostly agree, that today people often search for postcards be the locations of today. So many former German towns are now Polnish towns and so we are categorized this postcards under the polnish name of the town. See also Commons:WikiProject_Postcards#Categories. Best regards --sk (talk) 12:29, 12 February 2026 (UTC)

February 15

Being logged in should override the IP address block

I get the message outlined below when trying to update a page even when I am logged in. Being logged in should override the IP address block and allow the update.

You do not have the permissions needed to carry out this action. Your IP address is in a range that has been blocked on all Wikimedia Foundation wikis.

The block was made by ‪JJMC89‬. The reason given is Open proxy/Webhost: See the help page if you are affected.

Start of block: 00:51, 3 July 2024 Expiry of block: 00:51, 3 July 2027 Your current IP address is 52.94.133.131. The blocked range is 52.94.128.0/20.

Please include all above details in any queries you make. If you believe you were blocked by mistake, you can find additional information and instructions in the Stewards Block Wizard.

My-wiki-photos (talk) 21:05, 15 February 2026 (UTC)

@My-wiki-photos: Hi. That is a global block of an Open proxy/Webhost. Please read m:WikiProject on open proxies/Help:blocked.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:39, 15 February 2026 (UTC)

I know. However, if you are logged in, the fact that you are no longer an anonymous user should override the block. By logging in you are assuming all the consequences of your actions. If a user does something wrong, such a user can be blocked. My-wiki-photos (talk) 22:54, 15 February 2026 (UTC)

It appears you need IPBE (IP Block Exempt) right.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:59, 15 February 2026 (UTC)

No, I don’t really need it personally. I was just thinking it would make more sense for the IP address block to be overridden when a user is logged in and their credentials are known. My-wiki-photos (talk) 04:49, 16 February 2026 (UTC)

It is intentional that IP blocks apply to logged-in users by default. This prevents certain types of abuse. Omphalographer (talk) 05:30, 16 February 2026 (UTC)

No, the default is that they only apply to anon users. They only apply to logged in users and account registration if multiple abuse accounts used the IP. GPSLeo (talk) 06:33, 16 February 2026 (UTC)

Registering an account doesn't make you not anonymous, it just gives you a username. Open proxy users are anonymous by default and due to their ease of abuse blocked from editing, as they should be. You can ask for an IP block exemption as Jeff recommended, or disable your VPN. ReneeWrites (talk) 08:25, 16 February 2026 (UTC)

Maybe people with roles demonstrating that the community has trust in them (e.g. file mover, patroller, rollbacker, template editor) should be IP exempt? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:34, 16 February 2026 (UTC)

This would not be useful as one would need a whole lot of editing before that occurs and request extra permissions and just quite few users have any such. 'demonstrating that the community has trust in them' would better be done via something like account age + fraction & count of unreverted edits. Prototyperspective (talk) 18:50, 16 February 2026 (UTC)

Well, if you reason like that, any IP address is anonymous. Internet Service Providers won't reveal their clients' information due to privacy reasons. My-wiki-photos (talk) 18:42, 16 February 2026 (UTC)

No, that specific argument only addressed your point on why registering doesn't make someone not anonymous anymore. It is also besides the point, as the issue is not about anonymity inherently. Jeff G. linked the Meta-Wiki page about open proxies, have you read it? What is the reasoning stated on that page for why open proxies are blocked? ReneeWrites (talk) 23:03, 16 February 2026 (UTC)

@ReneeWrites Yes, I have read the explanation provided for open proxies. That does not change my opinion. As I have already stated, if a user is logged in using their account, there is no valid reason to block an edit simply because they are connected through an open proxy. Any abuse on their part can be addressed through their account. Furthermore, please prevent the registration of new accounts through open or residential proxies. My-wiki-photos (talk) 08:07, 19 February 2026 (UTC)

@My-wiki-photos: Are you using a VPN? If so, which one?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 08:33, 16 February 2026 (UTC)

@Jeff G. I don’t use a VPN at home. As I mentioned earlier, I don’t really need an IP block exemption. I simply wanted to perform a quick update from my workplace, which uses an open proxy. After logging in, I discovered the update had been blocked, which was quite inconvenient at the time. It occurred to me then that many others likely face this same issue. As I’ve said before, if a logged-in user abuses their account, they can be blocked before causing further damage. Therefore, it doesn't seem reasonable to me that open proxies are blocked by default. My-wiki-photos (talk) 18:56, 16 February 2026 (UTC)

I support allowing the use of VPNs for registered editors without requiring any extra "IP Block Exempt" permissions or similar. Maybe only users of a certain age and/or minimum count/fraction of unreverted edits. This would better protect privacy and safety. Prototyperspective (talk) 11:44, 16 February 2026 (UTC)

yeah it's becoming a bit ridiculous. half the internet is on an open proxy and we will have fewer and fewer people NOT in that situation. We need to find different ways. Maybe with like dynamic blocking and unblocking of ranges whenever there is abuse or something. This overblocking is costing us editors. I hear people wanting to try editing complain about it all the time. We mostly don't hear that, because we don't see those people, which is convenient... I guess. —TheDJ (talk • contribs) 12:59, 16 February 2026 (UTC)

February 18

Allow dcterms namespace

It makes little sense that we allow (in SVG uploads) as an XML namespace the URI for Dublin Core 1.1 (http://purl.org/dc/elements/1.1/) but not DC Terms (http://purl.org/dc/terms/). Desaccointier (talk) 04:38, 18 February 2026 (UTC)

While we’re at it I would also advocate allowing all the common RDF namespaces as defined in the canonical RDFa Core Initial Context. At the very least we should also permit Schema.org, seeing as how prevalent it is online. Desaccointier (talk) 04:40, 18 February 2026 (UTC)

@Desaccointier File a request in Phabricator. The current list of accepted namespaces is here btw: https://github.com/wikimedia/mediawiki/blob/HEAD/includes/Upload/UploadVerification.php#L543 —TheDJ (talk • contribs) 14:40, 18 February 2026 (UTC)

.see Phab:T283316.

.see also User:Glrx#MediaWiki_whitelisted_namespaces.

Glrx (talk) 22:47, 19 February 2026 (UTC)

February 19

More explicit policy against upscaling needed

Hi all,

I believe the guidelines in Commons:First steps/Quality and description, specifically the sentence "Generally speaking, image quality and resolution should be as high as possible so images can be used in high-quality printouts", should be modified to discourage upscaling beyond the native resolution of the original media. The file upload page also encourages users "Upload the highest resolution file that is possible", which can also be problematic.

I have run into a user who is upscaling their 5568x3712 images from their 20 megapixel Nikon D7500 camera to as large as 30893×17377 (537 megapixels) before uploading, in some cases ballooning an otherwise 5-10 megabyte file to over 100 megabytes for absolutely no benefit and significant detriment. I've notified their talk page about this, but this should be more clearly discouraged in policy. EDIT - the user responded and said this was a mistake with their export settings, and was not intentional.

I also think we should have clearer policies against upscaling (except for media explicitly illustrating upscaling as a technique), as use of AI and other tools to invent detail seems to run counter to the project's scope in hosting educational media. The only policy I've found against upscaling is on Commons:Overwriting existing files, which discourages overwriting existing files with upscaled ones. 4300streetcar (talk) 05:44, 19 February 2026 (UTC)

Commons:AI-generated media used to require AI-upscaled images to be tagged and categorised, but this was dropped in June 2024 as this concerns images modified by AI, not images generated by AI. We should create separate guidelines to handle the former. I'm not sure what the per Rhododendrites refers to in that edit summary; if there was a connected discussion I can't find it.

Commons:AI images of identifiable people#Altered images requires upscaled photographs of people to be tagged as such, and to include a link to the original source photo for comparison, but it takes no view on aircraft or other non-human subjects. It doesn't rule that such images shouldn't be hosted here. Belbury (talk) 09:21, 19 February 2026 (UTC)

•  Strong oppose upscaling. It should be prohibited. I've checked File:Gridiron Air’ Boeing 777-232ER ‘N866DA’ @IND.jpg and failed to find where 537 MP file is better that original (~8 MP). More, I even think that giant photo became more blurry than sharp and detailed original. Plus upscaling is just a useless waste of space. Юрий Д.К. 20:30, 19 February 2026 (UTC)
•  Oppose I agree such upscaling is useless, and should be prohibited. Yann (talk) 20:39, 20 February 2026 (UTC)
• Agreed with Юрий Д.К. and Yann to make this a more explicit part of the policy. --ReneeWrites (talk) 13:29, 21 February 2026 (UTC)

• I just noticed that files are upscaled with AI to achieve higher resolution. Just for example, File:20230621 Lapillus (라필루스).jpg is a screenshot from a 4K YT video, which was upscaled to a 8k-x-5k image and then cropped for details. I have to admit, one has to look close to find inaccuracies, but in the respective video, this popstar wears some kind of multi-finger-chain-rings which the AI could not properly figure out and it looks like her hand got distorted as the result. The image IS properly tagged as required by the guideline that Belbury mentions. However, I do not really understand why we would allow ANY upscaling made by AI (and other reality filters) on images that are then placed in WP biographies and/or articles about the depicted people.
  That said, I do understand that reality-distorted images would be uploaded for technical explanations of AI/filter technologies. --Enyavar (talk) 18:52, 21 February 2026 (UTC)
• per others. Original content in high-res is better ;) --PantheraLeo1359531 😺 (talk) 19:35, 21 February 2026 (UTC)

 Strong oppose upscaling per above. It would be nice if others would express their opinions as !votes.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 17:01, 22 February 2026 (UTC)

 Oppose to upscaling. It is really not needed, I find it increases file sizes & takes up more storage space unnecessarily while not actually increasing quality. A lot of these images look very weird, smooth and unnatural. Commons should be preserving original copies of media in their highest original resolution, instead of altering them with AI to achieve a false 'higher' resolution. If we really need to upscale an image in some rare cases where it could be useful, it should be clearly marked as so with {{AI upscaled}}, and not overwriting the original file. The vast majority of user-uploaded content taken with phones and cameras do not need upscaling of any kind so we should restrict this option. PascalHD (talk) 17:40, 22 February 2026 (UTC)

• It only should be done when paired with the original image and marked {{AI upscaled}}. Upscaling was used in Get Back, no one is saying that the Beatles were unrecognizable in the project. Upscaling from just a few years ago has been improved. --RAN (talk) 19:24, 22 February 2026 (UTC)

 Strong oppose upscaling images above their original resolution (with exceptions when needed, such as restoration of low quality old or otherwise significant images). Millions of media files (including redundancy and backups) need a lot of storage space, so that space must be used, not wasted. MGeog2022 (talk) 15:42, 26 February 2026 (UTC)

File captions capitalised or not

in english, if Commons:File captions are not full sentences and start with words that arent proper nouns, should the first letter be capitalised?

or should it be like wikidata item labels and descriptions that do not want the 1st word capitalised?

or it doesnt matter?

e.g. for File:Apple splitting 01.ogv, if any of these is preferred?

1. splitting an apple by hand
2. Splitting an apple by hand

RoyZuo (talk) 16:29, 19 February 2026 (UTC)

I, personally, prefer capitalisation and no dot at the end. --NearEMPTiness (talk) 17:30, 19 February 2026 (UTC)

Same here. Sometimes caption can be two sentences where there are dots but these are rare. Prototyperspective (talk) 18:10, 19 February 2026 (UTC)

I also think every good caption should be a full sentence and therefore first letter should be capitalized. GPSLeo (talk) 20:19, 20 February 2026 (UTC)

I'm not objecting to the capitalization, but I think plenty of good captions are not full sentences: "Stephens Block, Binghamton, NY, 2025"; "Main entrance to Pike Place Market, 2004"; "Exterior of Marienkirche, Ber