Commons:Village pump/Archive/2025/12

Freedom of panorama, Norway

https://commons.wikimedia.org/wiki/Commons:Copyright_rules_by_territory/Norway#Freedom_of_panorama I believe this is wrong. According to the Norwegian Copyright Act (Åndsverkloven) § 23 (1), works of art that are permanently placed in or at a public space may be freely depicted, unless to be used commercially. This means that photographing and publishing such images is permitted without obtaining permission from the rights holder. Source: Åndsverkloven (Copyright Act) § 23 (1).

Because of how this has been interpreted, I've noticed that photos of a few public artworks/statues have been unnecessarily deleted. Birdesigns (talk) 13:34, 1 December 2025 (UTC)

"unless to be used commercially" exactly means that we can not host the images. Ymblanter (talk) 14:51, 1 December 2025 (UTC)

Per Commons:Licensing: Wikimedia Commons only accepts free content, that is, images and other media files that are not subject to copyright restrictions which would prevent them being used by anyone, anytime, for any purpose. --Rosenzweig τ 15:04, 1 December 2025 (UTC)

I’m commenting on my own post to point out that Norwegian law / the Copyright Act distinguishes between commercial use (press, magazines, merchandise) – which is allowed – and advertising – which is not. I was not aware (as I should have been) that Commons doesn't make this exception/distinction. Birdesigns (talk) 17:18, 1 December 2025 (UTC)

@Birdesigns: Can you cite something that substantiates that distinction?

I'm not sure where that distinction, if valid, leaves us. We've accepted the equivalent for pictures in the U.S. as a personality rights issue (hence non-copyright); however, this seems to be more of a true copyright matter than that. - Jmabel ! talk 00:54, 2 December 2025 (UTC)

Files with no machine-readable source

I cannot see a difference in the source data between File:David Ogilvie 23.jpg and File:David Ogilvie 24.jpg. Yet, the #24 file pulls through a source in the information template, whilst the #23 file does not. Hence, the #23 file gets put into the Files with no machine-readable source category. Can anyone work out what's going on, please? Schwede66 22:57, 4 December 2025 (UTC)

@Schwede66: The one that works uses described at URL (P973) where the one that does not uses work available at URL (P953). - Jmabel ! talk 00:25, 5 December 2025 (UTC)

Thanks for spotting the difference, Jmabel. I thought I was going mad. Schwede66 00:35, 5 December 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 20:39, 8 December 2025 (UTC)

Do we have a category for text files that need OCR run on them?

Do we have a category for text files that need OCR run on them? RAN (talk) 23:17, 5 December 2025 (UTC)

@Richard Arthur Norton (1958- ): Yes, Category:Needing transcription is that, I think. It's added with {{Transcribe here}}. Sam Wilson 23:27, 5 December 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 20:38, 8 December 2025 (UTC)

Otto Warmbier is missing

This section is resolved and can be archived. If you disagree, replace this template with your comment. ReneeWrites (talk) 01:12, 9 December 2025 (UTC)

Category:Arrest and death of Otto Warmbier is empty. I assume, it contained one or more now deleted files. But if empty, it cannot fulfull its purpose --PantheraLeo1359531 😺 (talk) 19:05, 8 December 2025 (UTC)

see Commons:Deletion requests/Files in Arrest and death of Otto Warmbier. So the cat should be deleted, IMO --PantheraLeo1359531 😺 (talk) 19:07, 8 December 2025 (UTC)

Why did you make a thread about this? Prototyperspective (talk) 20:37, 8 December 2025 (UTC)

Hi @PantheraLeo1359531, in that case it would be best to create a deletion request for it at Commons:Deletion requests Commons:Categories for discussion :-) --SimmeD (talk) 00:00, 9 December 2025 (UTC)

No, empty categories can just be speedied. - Jmabel ! talk 00:47, 9 December 2025 (UTC)

Ah, Well, there you got it :-) —SimmeD (talk) 04:32, 9 December 2025 (UTC)

Scans of papyri

In continuation of a previous similar discussion: are scans of papyri (which are completely two-dimensional) I find online free to upload to Commons? for example this one.

Tagging Jmabel who helped me a lot in the previous discussion. פעמי-עליון (talk) 16:52, 8 December 2025 (UTC)

Looks like a simple technical reproduction to me --PantheraLeo1359531 😺 (talk) 19:08, 8 December 2025 (UTC)

Fyi, Morgan Library and Museum terms and conditions states, "The Morgan will not grant permission for the reproduction or commercial use of these low resolution downloadable images." -- Ooligan (talk) 03:28, 9 December 2025 (UTC)

That last sounds to me like an unenforceable non-copyright restriction. That same terms and conditions page also claims the images are all coyrighted, which this image clearly is not. It would apply to anything copyrightable on their site, but cannot apply to public-domain images. This is exactly what {{PD-Art}} is about. - Jmabel ! talk 03:52, 9 December 2025 (UTC)

Thank you for those details @Jmabel.

Great discovery @פעמי-עליון. -- Ooligan (talk) 04:35, 9 December 2025 (UTC)

If there are follow-up questions, please ask at Commons:Village pump/Copyright. Prototyperspective (talk) 12:08, 9 December 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 12:08, 9 December 2025 (UTC)

DEMO.MID

Good afternoon! I found this file titled DEMO.MID on the Olidata Recovery Disk for Windows ME, which I actually don't know what famous 90s MIDI software it came from... Could you help me? Thank you! DanielParoliere (talk) 12:32, 4 December 2025 (UTC)

favicon.ico too dark at night

https://commons.wikimedia.org/favicon.ico is too dark on dark themed browsers. Possibly due to transparency. Jidanni (talk) 03:23, 5 December 2025 (UTC)

it just depends on which type of browser, like Opera, Brave, Firefox, Edge, etc. Because I use chrome, I have no problem with it. ₘₒd cᵣₑₐₜₒᵣ ✰ ʜᴀʙʟᴀ ⍟ コントリビューション 23:17, 5 December 2025 (UTC)

Formatting Wikidata query

Hi, In the table of Paintings by Wassily Kandinsky, how to format the result of the WD query so that it looks like this instead of the current one. The external links should be within [ ] avoiding to create an oversized column. Also is the description really useful? It is always "painting by Kandinsky". Yann (talk) 16:42, 9 December 2025 (UTC)

Any one please? Yann (talk) 18:10, 11 December 2025 (UTC)

This appears to be about the "described at URL" column, unless I've misunderstood the question. Current version appears not to have the "description" column, which seems reasonable. - Jmabel ! talk 20:03, 11 December 2025 (UTC)

@Yann: If you want it to format just like [number]] you have to write [http://en.rusmuseum.ru/collections/painting-of-the-second-half-of-the-xix-century-beginning-of-xxi-century/artworks/siniy-greben/?sphrase_id=205947] instead of just http://en.rusmuseum.ru/collections/painting-of-the-second-half-of-the-xix-century-beginning-of-xxi-century/artworks/siniy-greben/?sphrase_id=205947 (that is, use square brackets). - Jmabel ! talk 20:08, 11 December 2025 (UTC)

@Jmabel: Thanks for your answer. Yes, I know that. I was asking how to format the result of the WD query. The description was removed by User:ReneeWrites. See the page history. Yann (talk) 20:14, 11 December 2025 (UTC)

@Yann: where is the query? - Jmabel ! talk 20:25, 11 December 2025 (UTC)

@Jmabel: In Paintings by Wassily Kandinsky:

{{Wikidata list |sparql=SELECT ?item WHERE { ?item wdt:P31 wd:Q3305213 . ?item wdt:P170 wd:Q61064 . MINUS { ?item wdt:P31 wd:Q15727816 } } |section= |sort=571 |columns=P18,label,P195,P217,P528,P571,P276,P973,P180 |thumb=128 |min_section= |freq=30 }}

Yann (talk) 20:29, 11 December 2025 (UTC)

@Yann: I believe SPARQL has a capability where you can get formatting into the return, so the brackets you want would be part of the returned column. I believe you use CONCAT, but I'm not familiar enough with SPARQL to form the query myself. - Jmabel ! talk 21:30, 11 December 2025 (UTC)

@Yann: I recommend asking at d:Wikidata:Request a query. BTW, you may also be interested in {{Wikidata Gallery}} (and/or the code at Dytaster) as an alternative way of formatting the Wikidata list output. Thanks. Mike Peel (talk) 23:52, 11 December 2025 (UTC)

TomT0m got the magic. Yann (talk) 20:17, 12 December 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 22:04, 12 December 2025 (UTC)

P1/Sergt. Louis Gargano

Does anyone know what the "P1/Sergt." for the Louis Gargano entry corresponds to at Wikidata? I get the Sergeant part, not "P1" or is it "Pl" or maybe F1? Is it perhaps "Sergeant First Class". See here: File:Eugene Freudenberg II (1925-1945) body returned home in the Jersey Journal on January 14, 1949.png — Preceding unsigned comment added by Richard Arthur Norton (1958- ) (talk • contribs)

• @Richard Arthur Norton (1958- ): I'm assuming that's Platoon Sergeant. GMG^talk 13:27, 11 December 2025 (UTC)

Thanks! That makes perfect sense. I looked for a fuller obit and he is listed there as "Platoon Sergeant". --RAN (talk) 13:42, 11 December 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 11:04, 12 December 2025 (UTC)

change summary

File:The-Drowsy-One-Friedrich-von-Amerling.jpg I don't know how to change the summary of this file, which refers to the painter while it should refer to the painting, and yet it looks good, with informations of the painting ! I don't understand. Io Herodotus (talk) 08:02, 11 December 2025 (UTC)

What part do you want to edit? The painter information is included from wikidata, so it needs to be edited there. The description of the painting can be edited right in the summary, there's an edit button next to the summary heading. --rimshot^talk 16:43, 11 December 2025 (UTC)

thank you. That painting should refer to Q137341778 in the summary. Io Herodotus (talk) 16:56, 11 December 2025 (UTC)

I have added a link to Q137341778 in the {{Artwork}} template for File:The-Drowsy-One-Friedrich-von-Amerling.jpg. Thanks. Tvpuppy (talk) 22:05, 11 December 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 11:04, 12 December 2025 (UTC)

MP3s are allowed.

https://commons.wikimedia.org/w/index.php?title=Template_talk%3AAbusefilter-warning-mp3#mp3_format_is_allowed.

Please turn off the warning. Jidanni (talk) 11:50, 3 December 2025 (UTC)

@Jidanni: It's apparently restricted to users with autopatrol. -- Asclepias (talk) 12:45, 3 December 2025 (UTC)

Maybe someone from the Mediawiki Foundation could turn it off? Jidanni (talk) 01:45, 4 December 2025 (UTC)

@Jidanni Per Commons:File types#MP3, MP3 are only allowed to be uploaded by users with the autopatrol (or higher) right. This restriction was introduced by a RFC on Commons, so this isn't something we can just "turn it off". So, please use another acceptable file type, such as ogg, or consider applying for autopatrol right at COM:RFR. Thanks. Tvpuppy (talk) 02:12, 4 December 2025 (UTC)

@Jidanni: Can you discuss what kind of mp3s you wish to upload? Sound recordings can be tricky copyright-wise. Abzeronow (talk) 02:28, 4 December 2025 (UTC)

At least someone should fix the tiny box in Phab:T411579 so people can read the message! Jidanni (talk) 06:45, 4 December 2025 (UTC)

I guess the issue is that MediaWiki:Abusefilter-warning-mp3 is using table based layout Bawolff (talk) 22:53, 4 December 2025 (UTC)

I opposed it when it was introduced and still oppose it, most definitely for this user level. It would be different if it was auto confirmed (or extended confirmed like on some wikis). I do think this is a thing we should look at. We have very little between auto confirmed and image reviewer. We are missing something like extended confirmed, or better, established community member, based on contributions on other wikis. It would be good to have something that identifies experienced community members from experienced Commons users... —TheDJ (talk • contribs) 13:06, 8 December 2025 (UTC)

Lat/Lon: DD vs. DMS

Maybe there should be a preference setting, that shows every coordinate pair, in the format preferred by the user.

So if I write {{Location|24.17|120.72}} it will show up in DD, not DMS. Not just for Template:Location, but everywhere, and for all Wikimedia wikis too. Jidanni (talk) 01:32, 6 December 2025 (UTC)

We have this on en.wp and like 6 people make use of it. I don't really think it is worth it. —TheDJ (talk • contribs) 12:57, 8 December 2025 (UTC)

Uploading cubemap projections of 360 degree panoramas

User:Sdkb recently requested I seek further discussion on this.

Recently I've been uploading cube map projections of 360 panorama images (phptospheres) as alternative versions of the image. Most of these images are currently in equirectangular format, which projects the entire 360 degree view into a single rectangle. This causes distortions similar to how a map of the earth is distorted as you cannot project a sphere on to a 2D rectangle without distortion, thus you can't really use the images directly unless you are doing so for artistic effect. Mostly they are used with {{Pano360}} to link to a viewer on toolforge. I've been uploading an alternative version of these images, where instead of one image they become 6, one for each direction - up, down, left, right, front, back (or up, down, north, south, west, east if you prefer).

The reason for doing this, is that the projected images are easier to work with on wiki without special software support. I view it somewhat similar to cropping an image for better use in an article. Like any derrivitave image, if the original changes the derrivatives would also need to be reuploaded. The six views can be used independently if applicable since they don't have distortion, however the main reason is that they can be joined together with templates to give an immersive view directly on wiki. Sometimes this is called cubeapping, because its as if your camera is inside a cube and these would be the faces of a cube.

As an example, consider, File:Panorama 360 of Basilique Saint-Patrick, Montreal, Quebec, Canada.jpg. In equirectangular projection it looks like

Splitting it up into a cube we get six images like so:

We can then combine them in to a unified view

Note, enwiki has a more complex viewer template that is better.

On english Wikipedia there is a gadget that provides a more interactive viewer. It does have some limitations though in that it doesn't support pinch to zoom or dynamic level of detail loading, but is quite a bit better than the pure wikitext commons template i used above. You can see it at w:Template:cubemap viewer. So far its been used on 34 articles. Its also been copied to fawiki and kowiki

Previously 360 panoramas were used on articles by having an external link to the panoviewer tool, but i think there is benefit to having a viewer directly in the article. It still links to the toolforge tool for a full screen view.

Thoughts? Bawolff (talk) 19:45, 7 December 2025 (UTC)

I'm very impressed with the cubemap viewer template you linked to, great job! I wonder though what's the reason the 360 panoviewer can't be placed directly in an article like the cubemap viewer? ReneeWrites (talk) 20:23, 7 December 2025 (UTC)

The basic answer is that I took this approach because all it involved was creating a template which i could do all by myself with no permissions or approvals, which is pretty freeing. The enwiki template does use a gadget, however that gadget was already approved to power w:template:Calculator, so it already existed and was live. There's something to be said about the Wiki-way of just being bold, is very motivating.

To integrate pannellum (That's the library panoviewer uses) there is basically two approaches. The first is proper integration with MediaWiki, which in the ideal world would be the best option. User:TheDJ has been on and off working on this for years (See mw:User:TheDJ/panoviewer for his work). I'm a bit unclear how much he is still working on it in the present. Getting custom MediaWiki extensions deployed on Wikimedia is often very politically difficult as a volunteer contributor. Its possible, and people have done it, but its an exhausting, uncertain process, and WMF seems to be even more reluctant these days about that sort of thing than it was in the past. Anyways, I wish anyone pursuing that the best of luck, it is definitely the ideal outcome, but I also think its unlikely to happen any time soon, and I don't really want to be involved with the politics of getting something deployed, as that's not really the sort of thing I like to do. Maybe if it wins the community wishlist that would get some momentum behind it.

The second approach would be a gadget for specifically embedding pannellum. It would probably be a large gadget, historically that would have been less than ideal, but with the advent of category gadgets, maybe that's less of a concern now. Of course someone would have to make such a gadget which might be a non-trivial effort, but at the same time not super hard (There are some previous attempts at just iframing toolforge like d:MediaWiki:Gadget-Panoviewer.js however that is not really what i mean. I think a proper tool would embed the viewer directly in the page and not just iframe toolforge). I think panellum has a native "pyrimid" image format, which is what it considers ideal and the panoviewer toolforge tool converts images to that in the background. In gadget form that wouldn't be viable, but it seems like panellum also supports normal equirectangular images, just without as much support for zooming in. Bawolff (talk) 03:33, 8 December 2025 (UTC)

Just to give an update on the other route that Bawolff was talking about. The basic status is at: User:TheDJ/panoviewer. The tool works, but there are some downsides. Primarily... it's still an issue to deal with large resolution images. That really needs tiling (like the Panoviewer toolforge tool does), but adding a tiling service to Wikimedia is ... PAIN. Secondly, you need some support to override angles etc for when that is not correctly provided by the metadata of the image (pretty common) and ideally serve those up via some sort of private API or something. Either magic words or Wikidata properties are an option for that, but I haven't been able to work on that for a while. Lastly.. the quality of tools in this space is... very low. A lot of the libraries are more suited for special dedicated websites and not so much for bigger websites, that have higher demands on quality and maturity. However, the extension does work, I updated it and verified this two months ago. —TheDJ (talk • contribs) 13:18, 8 December 2025 (UTC)

Overall, {{Pano360}} has some very significant limitations, and I'd love to see us using more photospheres overall in Wikimedia projects, so I share the praise for the technical work improving the viewer.

That said, we also currently have very poor infrastructure in place for relating files to one another, which is already a concern with cropped versions, and creating a cubemap results in even more files than a crop (a six-fold increase rather than just a doubling). This has the potential to add substantially to Commons' maintenance burden, especially as the use of photospheres increases over time, since with a cubemap e.g. each additional category has to be added in six places rather than just one.

Trying to think in a future-facing way, I wonder whether adding cubemaps to all 20,000 photospheres on Commons would really make them more accessible to Commons users (in which case it's more justified), or whether we ought to stick to the seemingly more common equirectangular projection format, and focus on technical improvements to the panoviewer rather than the stopgap solution of a cubemap viewer. I don't have a strong enough view about that to !support or !oppose the creation of future cubemaps. But given the number of files affected I do think it's a topic that could use some discussion/attention from interested editors, so I appreciate Bawolff following up from the discussion on their talk page to bring this here.

Cheers, Sdkb ^talk 23:51, 7 December 2025 (UTC)

To clarify, i support making new ones on an as needed basis, when a file is being used. I don't necessilary think doing this for every photosphere file makes sense. As you say its a ton of files and if its not being used in an article i don't think there is much benefit. Bawolff (talk) 00:32, 8 December 2025 (UTC)

I love it --PantheraLeo1359531 😺 (talk) 19:04, 8 December 2025 (UTC)

That looks quite interesting. -- SimmeD (talk) 00:02, 9 December 2025 (UTC)

Near-empty Category:Statistics about communication

Adoption of communication technologies, World

This cat has a problem that only a small fraction of categories has and it's not really a subject for a CfD: the category scope and title seems fine; it's just that there's many files on Commons that would belong into it but the cat is nearly empty.

Assuming there is indeed no better solution such as merging the cat somehow: could some other user(s) help populating it?

A difficulty and also sth where input here would help is that probably not all of Category:Internet statistics should go into it but only a fraction that is actually about the communication and not e.g. the share of Web browsers used. Prototyperspective (talk) 23:06, 8 December 2025 (UTC)

Don't forget {{See also cat}} for categories that are related, but neither exactly belongs as a child of the other. - Jmabel ! talk 00:49, 9 December 2025 (UTC)

Yes; in this case of Internet statistics I think soon a subcat of that cat should become the subcat of the Statistics about communication and this is why I didn't link that cat as see also.

There's of course also other categories relevant to it where it needs some thought how they relate to each other (make it a subcat, add one of its subcats, create a new subcat and add it, or add files from there and only link cat as see also) such as Category:Media statistics.
Prototyperspective (talk) 12:06, 9 December 2025 (UTC)

Attention filemovers

Please see Commons:Administrators' noticeboard#Mass rename requests with Criterion #4. Posting here so other filemovers have a chance to weigh in on use and scope of filemoving criterion #4 (harmonizing). Geoffroi 21:21, 9 December 2025 (UTC)

Add a Like button to each image

When we see an image that we like, we have the urge to click a like button. But there is none. Jidanni (talk) 04:36, 12 December 2025 (UTC)

That's because this is not a social media site. - Jmabel ! talk 06:30, 12 December 2025 (UTC)

Nor is a like button a feature unique to social media sites. See my common gripe about this argument at w:WP:Facebookization. —TheDJ (talk • contribs) 10:08, 16 December 2025 (UTC)

A similar feature briefly existed on the English Wikipedia, where users could rate articles with a moodbar, but it was disabled. Is there a reason why you made this thread? —Justin (koavf)❤T☮C☺M☯ 06:45, 12 December 2025 (UTC)

Having an "urge" for something is not a good reason. There was a wish in the Wishlist about this where you can see feedback and discussion about this idea: m:Talk:Community Wishlist/W108.

There is a way to "favorite" files publicly using a gadget or to download them into a private local folder. Engagement functionality / indicators for creators and uploaders are: 1. file uses (visible e.g. via the glamorous tool) 2. page-views or media views and 3. featured pictures and other community highlighting. Prototyperspective (talk) 11:03, 12 December 2025 (UTC)

You can thank people for edits, which includes the original edit of a file being uploaded. You can also create a gallery in your user space for images you like. ReneeWrites (talk) 12:58, 12 December 2025 (UTC)

There is a "Favorite" button which adds images to a personal gallery (and thanks the uploader, iirc). But you might have to enable that button in your settings (Gadgets). Nakonana (talk) 17:39, 12 December 2025 (UTC)

functional alternatives have now been listed – if you'd like to propose this, see Commons:Village pump/Proposals or the (wish in the) m:Community Wishlist. Prototyperspective (talk) 16:21, 15 December 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 16:21, 15 December 2025 (UTC)

List of "good" sources for PD works

I seem to recall coming across a policy or guideline here with a list of institutional sources where we automatically accept content tagged as public domain, "no known copyright restrictions", etc. I can't seem to find it. Was I hallucinating? Phillipedison1891 (talk) 17:01, 13 December 2025 (UTC)

I think there is no such list. Generally all public archives, libraries and museums should have correct copyright information. Every institution of course sometimes has incorrect data in their database. GPSLeo (talk) 17:28, 13 December 2025 (UTC)

There are certainly some institutional sources, like the Internet Archive, which we know to be more unreliable than others. (In IA's case, this is because many of their holdings are unverified user uploads.) Omphalographer (talk) 23:38, 13 December 2025 (UTC)

@Phillipedison1891: perhaps you mean Commons:Free media resources such as Commons:Free media resources/Photography? MKFI (talk) 08:45, 14 December 2025 (UTC)

By the way, questions like this is what users could ask a tool suggested in W442: Adopt Wikipedia-trained WikiChat LLM & make it learn about help pages & categories to help newcomers (if it comes up with no link, one could still ask here). I don't think there is a page like you're describing; just some for bad sources and the free media resources pages which aren't what you're describing but only partly similar (e.g. most works on US gov resource pages like NASA & CDC are PD). Prototyperspective (talk) 12:48, 14 December 2025 (UTC)

Or you may be thinking of MediaWiki:Copyupload-allowed-domains, although it's not really what you describe either. For context, see Commons:Upload tools#Uploading by URL. See also Commons:Upload tools#From specific external websites. -- Asclepias (talk) 15:41, 14 December 2025 (UTC)

Thanks everybody. I think either I came across something on another WMF project, or I literally imagined it while dreaming. (I have been confined indoors due to weather and have spent long hours online lately.) Phillipedison1891 (talk) 16:39, 14 December 2025 (UTC)

• A few images uploaded to Gallica that were "no known copyright restrictions" have been found to still be under an active copyright, when a death date for the creator was found. Gallica, when contacted, has changed the license when notified. --RAN (talk) 20:30, 14 December 2025 (UTC)

I assume that some users may have created sort of lists about that topic. I know about Poly Haven and ambientCG spontaneously, which create CC0 assets --PantheraLeo1359531 😺 (talk) 12:47, 15 December 2025 (UTC)

Commons:Free media resources is lists about the topic you mean and it has been linked/named here twice (1,2) (before your comment). Prototyperspective (talk) 16:18, 15 December 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 16:18, 15 December 2025 (UTC)

Your support for colored 3D models on Wikipedia needed

You can show your support for colored 3D models on Wikipedia and Commons here: https://meta.wikimedia.org/wiki/Community_Wishlist/W326. As this topic is becoming more urgent, it should get some attention to finally implement a new file format. Thank you :) --PantheraLeo1359531 😺 (talk) 19:36, 10 December 2025 (UTC)

It's now the top wish in the Wishlist by votes. I also mentioned this wish in the thread above which briefly summarizes some further listed wishes and includes links to see more Commons-related wishes. I'll mention that a key topic/need is not just filing wishes and supporting them, but also sufficient software development capacity so that (more) wishes are getting implemented such as via what's proposed here and here. Thanks, Prototyperspective (talk) 11:50, 11 December 2025 (UTC)

Thank you for your efforts :) --PantheraLeo1359531 😺 (talk) 15:17, 11 December 2025 (UTC)

Car identity to date image

See: File:Manoir_de_Vaumurier_(entrée).png. RAN (talk) 05:25, 11 December 2025 (UTC)

It can be a clue. At least, it tells that it was after 1901 or 1902, depending when this model was first sold. -- Asclepias (talk) 11:03, 11 December 2025 (UTC)

Why is Category:Mute (toki pona) not connecting to tok:nimi:mute as per the interwikis

I thought a bot was supposed to run this and create a wikidata item that links the article and category. Why is the connection not happening? Has this just not been a part of wikimedia commons for a long time? Immanuelle ❤️💚💙 (please tag me) 11:43, 8 December 2025 (UTC)

Neither of these two items seem connected to a Wikidata item but both are connected to each other, I didn't even know that was possible. But if this isn't done automatically, couldn't it still be done manually? ReneeWrites (talk) 20:07, 8 December 2025 (UTC)

It's the old way of connecting, predating Wikidata. Yes, it would be better to create a Wikidata item for this and link them in the normal present-day manner. - Jmabel ! talk 00:44, 9 December 2025 (UTC)

@Jmabel @ReneeWrites yeah it is the old way. Originally sites were all linked like this, and a bot connected them all to wikidata and removed the links. But for almost ten years the bots still ran. The reason I didn't create the wikidata items is that it will be very difficult to create all the items manually. Quickstatements does not work for it. Immanuelle ❤️💚💙 (please tag me) 05:08, 9 December 2025 (UTC)

If there is no functional bot, is there any way to see which pages do have the legacy interwiki connection links? Not even searching for insource:"[[tok:" works (and this would only show pages of that particular language). Maybe Allforrous knows more(?) Prototyperspective (talk) 10:57, 12 December 2025 (UTC)

I believe the following regex-based search should work: insource:/\[\[[a-z]{2,3}(-[a-z][a-z])?:[^\]]+\]\]/gm. But I imagine that is enough of a complex regex to put some detectable burden on the search engine. At the very least, you'd want to narrow it to "Category" space so it doesn't waste time searching through file pages. - Jmabel ! talk 19:22, 12 December 2025 (UTC)

Does en:WP:NBZ apply for Commons? (in regards to South Tyrol/Südtirol/Alto Adige)

I just reverted a category renaming from Category:Gerichtsplatz Bozen to Category:Piazza del Tribunale (Bolzano) because it changed the language name from German to Italian, and I knew this would likely be a controversial change in South Tyrol. I talked to User:Yeagvr about it and they said they applied en:WP:NBZ to rename the category. So I'm wondering if that is a policy on Commons and what should be our general principle on category names in South Tyrol/Südtirol/Alto Adige? Abzeronow (talk) 00:35, 9 December 2025 (UTC)

Comment: I reverted some of User:Yeagvr's changes of German language categories to Italian language and informed him that (at least on the English wiki) we adhere to en:WP:NBZ. Example: I moved the category to Category:Hydroelectric power station Töll (Algund) after he had moved it to Category:Hydroelectric power station Tel (Lagundo). I did not revert his moves related to the city of Bolzano, as per WP:NBZ that city has a Italian majority and hence uses Italian language (e.g. he moved Category:Oswaldpromenade (Bozen) to Category:Passeggiata di Sant'Osvaldo (Bolzano)). I would also like to know what the policy on commons is for names in South Tyrol. So far I have applied WP:NBZ and upheld that, e.g. when I requested (still pending) that Yeagvr's move of Category:Tschögglberg to Category:Monzoccolo be reverted as per WP:NBZ the four municipalities on the Tschögglberg are 95% to 98% German speaking, hence on the English wiki everything associated with them is in the German language. Thank you, Noclador (talk) 10:53, 9 December 2025 (UTC)

But we could have category redirects in the minority languages, I think. Nakonana (talk) 16:33, 9 December 2025 (UTC)

Yes. - Jmabel ! talk 19:23, 12 December 2025 (UTC)

Unsure how copyright is applied or if it is

I have found photos of Joanne Segal Brandford's art that I am hoping to be able to use for her article. The art pieces in the photos range from 1967 to 1988 and they are not/never were copy-written (conclusion after search through the different copyright databases and speaking to her friends and family). However, I don't know who took the photos or when the photos were taken. Is the copyright that we care about the one for the art itself (in this case it would be public domain) or do I need to figure out the copyright status of the photo? Thank you in advance for any assistance. Snugglebuns (talk) 18:23, 11 December 2025 (UTC)

• I see you have uploaded File:Bundle by Joanne Segal Brandford.jpg. Photographs of 3D works have their own copyright, and you will need permission from the person who took the photo, in the form of a free license or a public domain dedication. In addition, her artwork may fall under exceptions in US copyright law if it was published before 1989 and never registered for copyright. Make sure you annotate this on the file page, or it is liable to be deleted. If you have communication with her heirs, it might be best to have one of them write an email to COM:VRT confirming the status. -Nard (Hablemonos) (Let's talk) 18:55, 11 December 2025 (UTC)

  That picture is one that was taken by the Smithsonian because that piece is in their collection, the pictures I'm talking about are her other pieces that there aren't photos of anywhere other than in books. Snugglebuns (talk) 19:17, 11 December 2025 (UTC)

  Well, and the scans that I have but those aren't really helpful. I will see if I can get her son to email. Snugglebuns (talk) 19:18, 11 December 2025 (UTC)

  Works (in this case a photograph) by the Smithsonian are not automatically in the public domain. - Jmabel ! talk 20:11, 11 December 2025 (UTC)

  Mainly because they are not always made by government employees. For example, they definitely hire outside photographers. - Jmabel ! talk 19:38, 12 December 2025 (UTC)

• I can see the confusion for the "bundle" image. Usually the SI has the license on the objects page for the image, but it is missing in the metadata and on the page. https://www.si.edu/termsofuse --RAN (talk) 19:18, 11 December 2025 (UTC)

  How do I fix it? Or should I just go ahead and mark it for deletion just to be safe until I can talk to her son again? Snugglebuns (talk) 19:23, 11 December 2025 (UTC)

  • I don't think this is an emergency, but you actually have two copyrights to clear here. The Smithsonian didn't mark this as CC-0, but that may be only because the underlying work is still copyrighted. Once you can sort out the permissin from her son (which we definitely need), you'll probably need to contact the Smithsonian and ask them if they agree that their contribution to this is also CC-0 or PD. - Jmabel ! talk 19:43, 12 December 2025 (UTC)

Virus

On file File:The-Drowsy-One-Friedrich-von-Amerling.jpg, I was searching sources on "Source/Photographer", look what happens! How to fix that ?--Io Herodotus (talk) 10:20, 12 December 2025 (UTC)

What happens? If there's some issue on the site: if the site is malicious, I suggest you replace the source page with either an archived version in Wayback Machine or another site via image reverse search. (For me it only shows "You’ve enabled HTTPS-Only Mode for enhanced security, and a HTTPS version of www.artclon.com is not available.") Prototyperspective (talk) 11:00, 12 December 2025 (UTC)

Archived versions are the same. The thing is, I don't know where to find a proper source. Io Herodotus (talk) 12:50, 12 December 2025 (UTC)

Well, on https://web.archive.org/web/20130415062657/http://www.artclon.com/artist/friedrich-von-amerling/ you're not bombarded with Chinese-lettered porn site adverts, but that's still something not really serious, trying to offensively sell stuff. Porn-banner filled sites aren't malicious per se, but you should exert good care (and use script blockers: Firefox + NoScript, for instance), as it's at least a sign that the webmaster doesn't care about the security of his adverts. Artclon may have been subject to a domain sale, hence it's not a source anymore. Regards, Grand-Duc (talk) 13:10, 12 December 2025 (UTC)

Shouldnt we have a template for hijacked domains? The dead link template doesnt make sense since the link still works Trade (talk) 00:35, 13 December 2025 (UTC)

I'll try to import en:Template:Usurped. It will still need internationalizing, though. - Jmabel ! talk 01:07, 13 December 2025 (UTC)

Doesn't import simply (hard to kill the link); working on it. - Jmabel ! talk 01:30, 13 December 2025 (UTC)

Try what I have at {{Usurped}}. You can test it with Template:Usurped/testcases. I'd really be happier if there were a way to kill mediawiki's link to the usurped page, but I could not work out a way to do that. At least this now warns. Also, as I said above, internationalization would be good. Please feel more than free to try to improve this. - Jmabel ! talk 01:52, 13 December 2025 (UTC)

Hatnotes in History maps of Europe

Since September, Ty and me are increasingly stuck in several arguments (essentially this entire page: User talk:Ty's Commons), one of them about the proper definition of history maps.

I will readily admit that Ty is the person who established a uniformed definition of European history maps by century, please compare Italy, Belgium, Spain, Poland, and so on. That level of standardization was in itself an achievement, where I had just created a patchwork-in-progress before. However, I get stomach issues when reading the elaborate hatnotes:

• Territorial definition: Ty has chosen this rigid definition: "map showing all or substantially all of the territory of modern-day <country> - as the lands were in the 16th century (1501-1600 CE)" (example here). This definition has two major problems: relevant history maps of subregions are not "all of <country>", and would by that logic be excluded. The second problem is word "modern-day", indicating that our current borders of today are the only acceptable definition of what may be included in Polish history. So my counter-suggestion has been: This category is about maps of the history of <country> in the 16th century (1501-1600 CE) - no "territory", "all" and "modern-day" involved. Ty refused this in several text walls.
• Atlas links: The second paragraph is the link to the Atlas project. Ty claims that it is important to guide interested users to other curated pages of related content; while I think that the Atlas does not need to be linked in every sub-subcategry. The "Atlas of France" may be linked in "Category:Maps of France", and the history subsection may be linked in Category:Maps of the history of France. However, links to the Atlas are superfluous for each by-century subcategory.
• Even more user guidance: Like the Atlas, so the following Additional maps related to... paragraph. The link is already included in the navigation bar just below, and is self-explanatory there.
• Missing differentiation: An important part that I think needs to be distinguished and explained, is that "old maps" are not "history maps" (in short: this is a "16th-century map of...", but this is a "map of ... in the 16th century"). The similarity of the category names make it important in my opinion to clarify the matter in each category. Ty has for some principled reason removed this part of the hatnote and just places it in the see-also-box.

Ty and me are apparently both frustrated by this matter, so I am hoping for intervention and some comments by other users: What would be the best wording in the hatnotes/definitions for these categories? --Enyavar (talk) 12:55, 7 December 2025 (UTC)

Thanks for your note and apologies for the delay in follow up since I've been involved in another project. I believe we've made progress on a number of issues (as challenging as they've been at times). But I think the matters have warranted considerable attention because we've been addressing overall frameworks that involve a large number of maps related to the histories of our European countries - which are no doubt complex. I'm also especially concerned, as you know, that our categorizations of maps line up as well as they can with both our overall categorization policies (which empahasize a uniform and systematic approach to the handling of our current countries and their histories) - as well as to other parts of Wikimedia Commons categorizations for the histories of our countries (to which maps should be linked).

• Regarding the key remaining issues of territorial definition etc., I will respond shortly regarding these since I haven't had a chance to address your recent proposal. Some of the confusion has been caused by your use of the term territory in a way that is different than what is actually being referred to in the category definitions. From your most recent comments, I appreciate that what you're actually getting at is the handling of regions within the territory - and I will address the proposal regarding these.
• Going forward, I do intend to address the issue of numerous maps being categorized and effectively separated from each other (and from related subject matter) - not based on their subject matter (i.e. the particular region and time they are portraying) - but rather on each map's year of publication. The most important subject matter for maps showing history is the country or territory with which it is associated and the time period of its history being reflected in the map. Indeed no map is particularly valuable if the time period being shown is not clear. It's publication date, licensing status, etc. are properly part of secondary attributes. I think that is consistent with both our file descriptions (which effectively separate subject matter from publication date and licensing), and our overall categorization principles based on subject matter.

The issue is especially true for maps showing history - because these maps generally reflect the contributions of historians who have been focused on aspects of the prior events, which necessarily occurred years or even centuries earlier. In my view (as both a user and contributor of such maps), I believe that for the benefit of users, maps showing France in the 16th century (which is their subject matter) should be categorized together. In particular, users have a need for maps of a particular era or period in a country's history for a variety of purposes - both research as well as articles etc. - and they should be able to readily see the corresponding set of maps with that subject matter together.

Conversely, sequestering maps of related subject matter into completely separate and essentially unpredictable hidden "drawers" - based on they're having been published in 1956 versus 1955, or in 1843 versus 1833 - clearly makes maps much harder to find. And finding some leads users to naturally assume they represent all that's available - even though maps of greater interest (for detail, size, etc,) might be available. Unfortunately, they didn't know in advance that the map of France in the 16th century was actual sequestered away into a category such as "old maps" of France published in 1922. Indeed, related categorization systems based on ambiguous terms such as "old," "old contemporary," "historic," etc. are not considered generally helpful. I see that concerns with these have been raised by other users in the past - but not really addressed - and they do need to be.

• A related but very important issue is accuracy. Relatively new maps may contain better information (or be smaller etc,) - but since they're often not from publications it is often unclear where the overall information used to generate it has been obtained. And even for cases in which a citation has been provided, the actual map and other information from the cited source are often not - making it difficult to know whether the creator accurately reflected what was earlier reflected and published. Conversely, older maps are often quite detailed, but it's possible that later historical information has led to corrections. Seeing maps showing what should be the same basic territory and historical status (including names, borders, internal regions etc.) side-by-side is the best way to determine whether there are inconsistencies. Categorizing these maps together by subject matter then allows users to quickly compare the group, assess their accuracy and relevance, and then select the map or maps that best match their remaining interests (including such additional attributes as publication date and licensing status, level of detail, size, cities included, regional borders, neighboring countries, coloration, etc.).
• Finally, regarding Wikimedia Commons extensive and ongoing atlases of our country's histories (such as Wikimedia Commons: Atlas of Spain ) - which not only reflect contributions from many members of our community but are quite closely related to categories of maps showing the territories and histories of these same countries - I was certainly very surprised by Enyavar's suggestion that cross-references to the Wikimedia Atlases (a project he's made clear he has no interest in despite his frequent involvement with related maps) should actually be effectively suppressed from corresponding categories.

I was even more surprised by his suggested reason for this being that the "Category tree is not primarily supposed to guide Users to potentially useful files."

If the category tree and categorization in general is not primarily supposed to guide (and help) users to find potentially useful files, then I think there are even more signficant conversations to be had. Among them, our overall Wikimedia categorization principles, which are in large part directed to that very goal of helping users to find what they're looking for, would need to be substantially reconsidered and rewritten.

In closing, I will plan to continue these discussions with Enyavar - focusing on our official categorization policy and its agreed principles, consistency across our categorization framework for the histories of countries, and last but most important, enabling users to find what they're looking for even, if they're not familiar with all of the intricacies of European countries and their complex histories. Hopefully the eventual outcome will be improved categorizations of maps, especially for maps reflecting the histories of each of our current countries. Ty's Commons (talk) 15:40, 7 December 2025 (UTC)

This topic was strictly and only about the category hatnotes. On the topic of user guidance, Ty misquoted me in that reply. I hope that you all see why I am hoping for an intervention. --Enyavar (talk) 19:21, 7 December 2025 (UTC)

Enyavar initial post here raised a large number of largely orthogonal issues whose only two common threads are (1) that they have to do with [hatnotes of] maps of Europe and (2) which two people have been disagreeing about them. If I read correctly, Ty's Commons then widened that even further. It is almost unimaginable to me that we can have a coherent discussion about this on a single thread.

At the very least: could we start separate threads to discuss each issue whose answer is independent of the others (or almost entirely so)? Better yet, could we prioritize two or three issues to discuss first (each in a separate thread) so we do not have 8 or 10 simultaneous discussions about maps of Europe? Alternatively (though I guess the two could be combined) could we spin out a project page to discuss these issues, rather than the Village pump? - Jmabel ! talk 03:07, 8 December 2025 (UTC)

Gladly, I see three threads from my own original post. The idea to split them into three distinct threads is fine with me, maybe that can create coherence?

• the wording of the definition in the first paragraph of the hatnote (i.e. the subject definition, currently in all these categories)
• whether or not to include the proposed "user guidance" of the second and third paragraph of the hatnote (currently in all these categories)
• whether or not to re-include the proposed clarification on the distinction between old/history maps into the hatnote (currently absent in all these categories)

"These categories" means all categories in the scheme "Maps of <European country> in the <x>th century", which was a scheme we introduced together last year to create meaningful subcategories for "Maps of the history of <European country>". On background: There was an earlier by-century-scheme ("Maps of <x>th-century <European country>") which we fully converted to the above new scheme. That old scheme was fragmentary and unsuitable to be used together with templates. Another earlier scheme is still partial existent and groups history maps by-periods-by-country, i.e. "ancient period", "medieval period", "modern period", and in some cases additional periods. The period-scheme has obvious definition flaws.

I would like to not discuss the fourth+final issue here, because that topic is already dealt with by a CfD: whether or not history maps according to the above scheme must be made available for each century and each country of Europe, or if neighboring countries (e.g. ancient/medieval Low Countries, Scandinavia, Baltics, Balkans...) can be grouped together by region for practical reasons, and then be connected via redirect. Again, that is part of that linked CfD.

Aside from those four topical issues, I am not aware of more (praxis-related) disagreements between Ty and myself. Ty might disgree? --Enyavar (talk) 04:11, 8 December 2025 (UTC)

I generally agree with User:Jmabel that "Enyavar['s] initial post here raised a large number of largely orthogonal issues". I didn't actually widen it further as it was Enyavar's fourth point entitled "Missing differentiation" that relates to a parallel framework intersecting with this one - for which the issues are substantial (as reflected in my response). I'll separate that further below since it needs to be the subject of an ongoing review but will reference the overall issues from the perspective of this project. (Ty's Commons) (talk) 10:55, 12 December 2025 (UTC)

A. Current framework (Maps of 'Country Abc' in the Nth century)

Regarding the current categories at issue (e.g. Maps of France in the 18th century), I appreciate Enyavar's recognition that "Ty is the person who established a uniformed definition of European history maps by century… That level of standardization was in itself an achievement, where I had just created a patchwork-in-progress before."

Developing a uniform framework for such maps is challenging given the complexity and ever-changing entities that swept back and forth across Europe for two millennia. The framework is essentially anchored by one key touchstone: organization based on the territories (i.e. geographic area) of our current European nations - each of which territories is precisely defined - and each of which is also central to the history of the current nation. That organizational framework not only has the benefit of addressing what's been referred to as the territorial problem (discussed further below), but is also consistent with the treatment of the histories of European and other countries across Wikimedia Commons. In particular, overarching metacategories such as Category:History of Europe by country and its corresponding subcategories are all effectively organized in the same manner (i.e. beginning with our current countries and then categorizing the histories of their territories back through time, typically to the Roman Empire and in some cases beyond).

• For the framework to function and be populated most effectively, the corresponding category definitions need to make clear that it is the territory (geographic area) of each of our existing nations that is the principal focus. That's especially important because in many cases the earlier political entities (both internal and external controlling ones) had varying names as well as evolving and in some cases "revolving" domains. Not only can the current framework readily handle those, it's essentially designed to.
• To use Enyavar's example of various "Polish" entities, these were sometimes much larger than modern-day Poland - including at times not only Lithuania but parts of modern-day Belarus, Ukraine etc. Maps that relate not only to Poland but to the territories of these other current countries form essential parts of each of their histories and should be categorized accordingly. And they are with this organizational framework in two parallel ways: (i) they're reflected in the maps of Poland because they include its territory; and (ii) they're reflected in the various time-relevant categories for Lithuania, Belarus, Ukraine etc. (when and as those territories were included and are therefore reflected in the corresponding maps).
• Such a framework can be applied to readily and systematically categorize each nation's distinct history without having to effectively merge them into that of other nations or into regional agglomerations. So I don't agree with redirecting or otherwise merging any of our nations' categories of maps into those of other countries or regions and don’t believe that's consistent with either the uniform and systematic treatment of countries expressed in our official categorization policy (including the universality principle) - or with the parallel organizational schemes for the histories of our countries such as those referred to above.

The evolutionary changes of associated names and territories (both larger ones and smaller) are as complex as European history is, and so they're also very helpfully noted and illustrated in the corresponding Wikimedia country atlases; including, e.g., the Atlas of Poland (the history section of which tracks the territory that evolved into modern-day Poland) and the partially overlapping Atlas of Ukraine (the history section of which tracks the territory that evolved into modern-day Ukraine). These features combine to provide the organized framework of maps that allows users to both appreciate and easily navigate what would otherwise be a complicated jumble of historic entities and corresponding maps.

Additionally, from each and every category "landing page" such as Maps of Hungary in the 17th century, users can quickly see not only a set of maps depicting its territory (geographic area) at that time, but the link to the corresponding atlas page helps to inform them not only about its territory and evolution but also its time-dependent position within the various larger entities reflected in the maps (such as Hungary's place within the Ottoman empire and then later within the Austrian Habsburg territories). Since the categorization framework also includes a navigational template that Enyavar helped to inspire, users can then easily switch to any other century of interest for Hungary, or to any other European country, for example to see what the Austrian or Czech territories looked like at that time; and soon enough, additional maps for Romania, Serbia, Slovakia, etc.

The principal territorial issues have thus been covered, with one remaining exception - which is what Enyavar refers to as rigid defining language directed to maps showing "all or most" (previously "all or substantially all") of the territory of interest. That language was included to keep the categories closely focused on their subject matter - which is "Maps of country X" (e.g. maps showing France, not maps of Lyon or La Rochelle). Across the framework and within categories, the maps would thus reflect each current nation's territory at the corresponding time - and not become cluttered with maps showing various internal regions, cities or other localities.

Since the categories are only just being developed and populated and so don't yet have that many maps, I could potentially remove the limitation "all or most" from the category definitions going forward, since internal regions can be treated via subcategorization when and as appropriate. But I want to hold off on that at least for now because Enyavar and I are still discussing the issue and, even more importantly, because the best solution will likely be influenced by considerations of a parallel organization of maps that are collected and sorted based essentially on their publication date. These are discussed further below.

In sum, the current system is still being developed and populated but seems to be a valuable way of both organizing and navigating these maps, and is consistent with other frameworks on Wikimedia Commons as well as our categorization policy and associated principles. I plan to get the remaining European countries into the framework so that both I and others can then readily place additional maps into the categories of over time. (Ty's Commons) (talk) 10:55, 12 December 2025 (UTC)

B. Intersection with parallel framework of "Old" maps (collected and categorized based on year of publication)

An orthogonal but pertinent point relates to the last of Enyavar's issues (i.e. so-called "old" maps, which are currently any maps published prior to 1955). The categorizations discussed above should continue to be based on their essential subject matter (i.e. maps showing the applicable territory at the corresponding time) rather than when a map matching the subject matter happens to have been published.

The reason is that if maps showing the relevant subject matter are separated from each other based on year of publication, then not only will users not see the set of relevant maps together, but there is actually no second "set" or parallel grouping at all - because they would be separated not based on the corresponding subject matter but rather on their years of publication, which are scattered over decades and indeed centuries as noted above. What person in their right mind would want to hunt through a very large series of map drawers by publication year or decade - especially when they include both country maps, regional maps and others, showing different but varying time periods? They wouldn't, and they don't need to be. They should be shown maps of the same basic subject matter together so they can quickly see what's available, compare them according to whatever secondary interests they may have, and then choose the one that best suits their interests and needs. (Ty's Commons) (talk) 10:55, 12 December 2025 (UTC)

C. Ongoing considerations related to the parallel "Old maps" framework

The parallel framework of categorizing some maps as "old" based on their having been published more than 70 years ago, itself originated decades ago when the categorization scheme had relevance to separating files that were in the public domain. But the 70 year cut-off no longer accomplishes that - and the issue is now handled separately and methodically through the licensing provisions and otherwise.

In addition, it has been increasingly considered that the use of vague terms such as "old" or "historic" should be discouraged; see, e.g. the Categories for discussion 2024/04 Historic buildings. Key conclusions were as follows:

1. The category name is too vague to be useful.

2. Category names with vague words in the name like "historic..." and "old" should be deleted, not get a redirect or become a disambigious page, to prevent that they are used by unexperienced uploaders. Another opinion is that we should keep some of these categories with very generic titles so that they catch all such files added by clueless users. then other users can sort them into better category. This means that editors should spend time on this kind of maintainance, which is not desirable.

3. Though, we can create Category:Old buildings (or use something like "in the public domain" instead) for buildings that are in the public domain in countries with limited FOP.

4. Perhaps it is even better to develop a page Help:Historic that redirects to Help:Categorisation which we develop to help people to better categorise.

Consensus was reached and the discussion was closed as follows:

Consensus: > Resolved by consensus

Actions:

- Empty and delete categories with "historic" and "old" in titles with no redirection or disambiguation.

- Create categories like "X in the public domain" for PD stuff. / Optional, but create Help:Categorization with Help:Historic as a redirect.

The related issue was also intitially broached in the context of maps in November of last year in Categories for discussion 2024/11 Category:Old Maps. In that Cfd, Enyavar mistakenly suggested that user Sbb was somehow complaining about "maps of <location> by century".

But he was not - and the connection to "location" by century versus time of publication appears to have been added by Enyavar (presumably inadvertently) to what was supposed to be a quote. In fact, consistently with what is being said here, Sbb was referring to the April 2024 Cfd and essentially questioning the maintenance of the category "Old maps," by century (which is inherently redundant). The actual quote and relevant points were as follows:

(Sbb): I used to think that Category:Old maps would include only the maps whose copyright terms were expired. I don't know who has put Category:Maps by century under this category, which should be removed. BTW, categories starting with "historic(al)" or "old" are now discouraged, see Commons:Categories for discussion/2024/04/Category:Historic buildings. But this may or may not be an exception, even though it is a bit redundant to Category:Maps by century, Category:Maps by decade, Category:Maps by year, etc.

As reflected by Sbb and others, the fact that terms such as "old" or "historic" are both questionable and discouraged does pose an issue to be addressed more generally going forward.

Some earlier comments were frankly even more "pointed" - including in response to posts on Enyavar's user page at Old maps categories.

In that case a user noted as follows, in December 2023 (Pi): I don't think recreating Category:Old maps of Boston is a good idea. "Old" and "historical" are vague and subjective terms, which isn't useful for an archive that strives for accuracy. The consensus at Commons:Categories for discussion/2019/09/Category:Historical images was clearly in favor of depreciating "historical" in category names, and I've begun doing so with "old" as well.

The 'response' was as follows: (Enyavar): As suspected. There were seemingly three ignorant voices clamoring for deletion of the whole old maps category tree, which has millions of maps sorted into hundreds of thousands of subcategories. I don't think those three people have categorized any larger amounts of old maps.

In any case, the comments were before the April 2024 consensus discouraging the use of categorization based on concepts such as "historic" or "old." And even if such parallel categories are to be maintained in the coming year(s) for some purposes such as collection or indexing (which I'm not opposed to), that certainly isn't a basis for separating the particular groups of maps being organized here by shared subject matter into one set (but currently only those published after 1955, to be changed again in a couple weeks) - and then leaving the remainder scattered across dozens or even hundreds of potential drawers based on what years the relevant maps happened to have been published in. Not only does that seem crazy but my extensive efforts to assemble relevant maps by subject matter would be effectively gutted, so I would certainly have little if any interest in continuing them.

To Enyavar's credit, I've noticed that following the 2024 consensus, he has increasingly taken a newer tack, including in this more recent post from May 2025 on his user page: Consensus to remove maps by individual year:

(Enyavar): Per the principle with old maps, that the correct location is more important to categorize than the incidental year/month/day of publishing, I re-structured the "old maps of Kansas" by county depicted, unless they actually showed large portions or the whole state.

So the treatment of Kansas started to sound more similar to the treatment of France and other European countries that I've been working on (including the focus on "large portions or the whole state").

Even more pertinent was this one from July 2025 in Maps by Year:

(Enyavar): At least with maps, the exact year of creation is not a prime categorizing criterion (while still important metadata, sure).

Sure, "by year" is the easiest way by far to quickly subdivide large amounts of files, but that level of granularity has no advantage at all for users on Commons. All that you achieve, is having split up a lot of files (of the same type) by some arbitrary factor. In my opinion, you should instead subcategorize by the survey sweeps, which means matching the files by real content. The probably best approach: subcategorize by the geographical subdivisions that are covered in each map.

So overall, I believe that we increasingly agree in principle - which is part of the reason I've continued working on the related project. I do understand that it will be a big task to consider potential revisions of the larger categories - but if there's anything I'm sure of, it's that Enyavar is capable of large-scale recategorizations. I'll also be here to help and to consult in any way I can.

In the meantime, this is another reason that I didn't want to loosen the definition for the current categories referred to above. When they are essentially limited to maps showing entire countries, there are not that many relevant maps (even for major countries such as France or Germany). And it would certainly be illogical and unhelpful for the category showing Maps of France in the 16th century to specifically exclude the small subset that happened to also have been published in the same century. However, if regions, cities and towns were also included then I wouldn't want the categories to be effectively crowded or cluttered so that the main subject matter is distracted. I would therefore suggest that issue to be addressed in future - after there has been further discussion of the "old maps" categorization scheme. We can then also consider related issues in that context, such as whether the term "history" should be used and in what contexts. (Ty's Commons) (talk) 10:55, 12 December 2025 (UTC)

Summary and proposed next steps

1. Regarding the current framework:

For reasons noted above (in the preceding paragraph and in section A) I'll hold off for now on loosening the definition in the current categories in order to keep them as closely focused as possible on their key subject matter of countries. Since there are relatively few maps available, especially for earlier centuries, it makes it even more important that any relevant maps be gathered and presented together.

Once the country categories are set up, I'll turn more attention to retrieving additional maps of relevance - and of course would always appreciate Enyavar's and others' additions of relevant maps.

2. Regarding the parallel "Old maps" framework:

I'll look forward to future discussions regarding the "Old maps" categorization scheme. Since I fully share Enyavar's interest in better organizing our related maps - and it intersects with the current framework - I'd be happy to begin with a bit of offline brainstorming as we've done before once Enyavar has given further thought to possible approaches. I recall he's even considered a more radical 21st century approach in which maps from this century might potentially be categorized differently - the sort of "new" maps aproach that might well make sense. Perhaps we could then come up with a possible plan to be recommended in a separate Cfd directed to the issue. In any case I look forward to helping when and as I can. Best, Ty (Ty's Commons) (talk) 10:55, 12 December 2025 (UTC)

@Jmabel: - so here you have it. I still would argue that this thread must be strictly limited to the question(s) of the hatnote(s) on the history maps of Europe by century categories that I formulated above. Do you have a suggestion how to mediate the issue?

The other subjects that were raised are... not less important, but "parallel", to use your geometry metaphor. All the best, --Enyavar (talk) 15:56, 12 December 2025 (UTC)

@Enyavar: TBH, there is simply more here than I am willing to wade through in an area where I am not all that involved. It would astound me if the substance of this could not be expressed in a third this much text, or less.

I hope someone more active in this area than I will make that paraphrase.- Jmabel ! talk 19:06, 12 December 2025 (UTC)

@Jmabel: Sorry to put you through this, which was not my intention in the first place; but hopefully the basic categorization principles and overall approach makes sense, and I think Enyavar and I largely agree on that. I do think it was important to address the remaining technical points since he raised them; as well as lay out a path for going forward regarding the larger issue of the parallel framework (using publication date as subject matter as discussed in section C) - since he raised that as well with his point called "Missing differentiation" - and it has much broader implications as noted. Those are intended to be the subject of ongoing consideration as proposed in my final point. Ty's Commons (talk) 11:36, 13 December 2025 (UTC)

@Enyavar: You raised issues on the history maps that I think are more than fully addressed but also their intersection with the parallel "old" maps-by-date framework per your fourth item at the start of this discussion. Going forward, the ongoing considerations regarding that parallel framework (as discussed at C) are a much larger issue, as noted - so the final point above suggests a plan for future consideration. Ty's Commons (talk) 11:14, 13 December 2025 (UTC)

Correcting errors

We house thousands of news articles not transcribed at Wikisource. Do we have a standardized way to point out errors of fact or typos? RAN (talk) 19:25, 11 December 2025 (UTC)

{{Fact disputed}}? (maybe not, because if it's in the file itself, it is something that can never become "resolved".) Or just part of the description. - Jmabel ! talk 20:13, 11 December 2025 (UTC)

For "errors of fact" in the file content, not title or description, it would be {{Factual accuracy}}. Prototyperspective (talk) 22:40, 11 December 2025 (UTC)

Very good, thought that seems a bit strong for a typo, unless it is in a date, proper name, etc. Should we maybe have something "milder' for things like that? - Jmabel ! talk 19:45, 12 December 2025 (UTC)

Yes, it's not suited for typos. These are currently usually pointed out on the talk page (usually with the user forgetting to ping the uploader which I do whenever I see it). I don't think there's a template or standardized way yet – maybe {{Typo}} could be edited (or moved) and that template be used for that. Prototyperspective (talk) 19:54, 12 December 2025 (UTC)

It looks to me like the only page making any meaningful use of {{Typo}} is File:Utf8test.png. I'm inclined to "subst" it there and then repurpose the template. - Jmabel ! talk 00:15, 13 December 2025 (UTC)

Pinging @Tuvalkin. - Jmabel ! talk 00:18, 13 December 2025 (UTC)

I had even forgotten about that one, thanks for pinging. That {{Typo}} is a formatting template that merely adds wavy red underline to any text. I should have categorized as such — and if I had then maybe it would have met wider use. I renamed it and altered that singe use to match, so please go ahead at repurposing {{Typo}}. -- Tuválkin ✉ ✇ 13:53, 13 December 2025 (UTC)

• I have been adding the text twice, once with the typo and [sic] and a second time corrected, so that someone searching for the correct spelling will find it, and I mark the text as "corrected text". If an error of fact, I will leave a note explaining the error. It seems like we have no standardized way, like Wikisource. Wikisource leaves all errors in place and the error can be discussed in the notes section. --RAN (talk) 02:38, 13 December 2025 (UTC)
  • @Richard Arthur Norton (1958- ), Prototyperspective, and Tuvalkin: New Template:Typo available; test cases at Template:Typo/test, feel free to add more. First time in a while I've coded up a tricky template, took longer than it used to, out of practice. Let me know if there is anything that needs tweaking (more arguments, etc.). Also if you can think of additional appropriate categories for the template, please add them (as NOINCLUDE, of course, unless your intent is to categorize the pages where it is used). - Jmabel ! talk 22:39, 13 December 2025 (UTC)

What is this style of wearing a tie called?

What is this style of wearing a tie called? The tie goes over the collar, rather than under the collar. Cravats are a type of tie worn over the collar, but this looks like a standard tie. File:Frank E. Wade, New York Superintendent of State Prisons in 1916.jpg I added Category:Cravats, but not sure. --RAN (talk) 03:52, 19 December 2025 (UTC)

• That's called a stand collar, and it optionally paired with an attachable stiff collar for formal occasions (here is a modern reproduction[1]). Here's another example with tall detachable collars[2] The man in this picture is simply wearing his shirt without the additional collar, which was a common choice. -Nard (Hablemonos) (Let's talk) 06:11, 19 December 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 17:01, 19 December 2025 (UTC)

Category:Comic books by year

This section is resolved and can be archived. If you disagree, replace this template with your comment. ReneeWrites (talk) 15:45, 19 December 2025 (UTC)

This is made by a template, and it puts these categories into Category:Magazines by year - under C. Can someone fix it so it doesnt appear between China and Czechia? I cant find the template, or the discussion about templates. If anyone would like to move this request to a more appropriate place I would be very grateful/ Rathfelder (talk) 15:12, 19 December 2025 (UTC)

@Rathfelder:  Done, made a small change to the template so it now appears separate from the country categories, see Category:1933 magazines for example. Due to caching you may have to refresh the parent/subcategory before it appears at the right location for other years, or wait a few hours or so for it to happen automatically. --ReneeWrites (talk) 15:38, 19 December 2025 (UTC)

Thank you very much. Rathfelder (talk) 15:39, 19 December 2025 (UTC)

You're welcome :) --ReneeWrites (talk) 15:45, 19 December 2025 (UTC)

Notifications

I made a deletion request today and now I receive reply notifications every time a new deletion request is added to Commons:Deletion requests/2025/12/10. The same thing happened when I submitted a request the other day, but it has never happened before then.

Is there any way to stop and prevent this?

Sinigh (talk) 20:02, 10 December 2025 (UTC)

Same with me, unsure why adding DR nominations to the daily Commons:Deletion requests list now automatically subscribes you to the section, which means I have to click "Unsubscribe" each time when I added DRs to the list. I'm not sure what's the cause for this, but maybe someone else will know what has changed recently. Thanks. Tvpuppy (talk) 20:45, 10 December 2025 (UTC)

The default in special:preferences for automatically subscribe me to things i comment on, was recently changed, so its probably related to that. Bawolff (talk) 20:53, 10 December 2025 (UTC)

There seems to be a bug in the implementation of phab:T295090. I have a huge problem with notifications on every archived mass message sent by me. GPSLeo (talk) 20:57, 10 December 2025 (UTC)

Had the same problem. At the top of the page there is another [unsubscribe] button. If you click that, the notifications stop. Prototyperspective (talk) 23:26, 10 December 2025 (UTC)

Thanks! I don't know what selective amnesia made me forget about that button.

I suppose it's still better for users not to subscribe to those pages by default. Sinigh (talk) 08:05, 11 December 2025 (UTC)

This is due to the subscribe by default setting in the preferences. Are you asking for a way to specify pages to exclude from this behavior? If so, maybe a phabricator code issue would be good so that users can specify the deletions page or that page is by default excluded. Prototyperspective (talk) 10:10, 11 December 2025 (UTC)

The daily DR pages should definitely be excluded by default. That many notifications won't serve any meaningful purpose for most users.

Even with automatic subscription activated, this wasn't an issue before, so something must have been changed recently for this to start happening.

Sinigh (talk) 11:19, 11 December 2025 (UTC)

It's even worse on mobile browser because you don't see the "unsubscribe" button unless you switch into desktop mode. I was already aware of the issue since I had seen this discussion here, but it still took me several minutes just now to figure out how to unsubscribe from the December 13 deletion nominations after I had started a DR. Nakonana (talk) 12:50, 13 December 2025 (UTC)

 Comment, there's a related discussion at Commons:Village pump/Technical#Receiving reply notification when subsequent DRs are added to daily page. Thanks. Tvpuppy (talk) 17:08, 14 December 2025 (UTC)

Files under wrong license?

I came across some files like File:Am-tuat 025.jpg which have the wrong license. You can't "only" license a file for Wikimedia Commons, that's against COM:L. However they can be converted to PD-Scan right? —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 15:29, 14 December 2025 (UTC)

@Matrix: Yes. ReneeWrites (talk) 18:30, 14 December 2025 (UTC)

Correct. This license statement should be reviewed (and probably removed) in all instances where it appears - most of the texts hosted by Sacred-Texts are in the public domain. Scanning those texts does not create a new copyright which Sacred-Texts can assert. Omphalographer (talk) 19:49, 14 December 2025 (UTC)

Question

This section is resolved and can be archived. If you disagree, replace this template with your comment. ReneeWrites (talk) 11:47, 20 December 2025 (UTC)

Hi! Just wanna ask if this is acceptable or {{PD-textlogo}} of this picture? Royiswariii Talk! 08:21, 20 December 2025 (UTC)

@Royiswariii: It is. You're good! ReneeWrites (talk) 09:19, 20 December 2025 (UTC)

But the graphical work on the right? --PantheraLeo1359531 😺 (talk) 16:46, 20 December 2025 (UTC)

What country is this from? - Jmabel ! talk 20:15, 20 December 2025 (UTC)

Government agencies and acronyms

When titling files, descriptions and categories related to US government agencies is it preferred that we use the full name or acronyms?

Examples being:

• FBI/Federal Bureau of Investigation
• ICE/Immigration and Customs Enforcement
• DoJ/Department of Defense

etc Trade (talk) 13:40, 9 December 2025 (UTC)

Per Commons:File naming#Clear, ...it is allowed to use well-known acronyms and initialisms such as NATO, so long as other parts of the name provide sufficient information to identify the subject.... I think acronym FBI is well-known enough, but ICE and DoJ may mean different things other than the US agencies, so you may want to use the full name if the rest of the file name doesn't have enough context. Thanks. Tvpuppy (talk) 14:34, 9 December 2025 (UTC)

Seconding Tvpuppy. When I see "ICE", I'm thinking of German bullet trains (aka InterCity Express, see File:ICE-Logo.svg, Category:ICE train services, Category:ICE network maps etc.). So, keep the international community of Commons in mind. People around the world might know what NATO is, and they probably have heard of the FBI / CIA / NSA in the news or in American movies, but... ICEs are German trains and I wouldn't have a clue what DoJ is if you hadn't written it out (and even after you wrote it out I might still question whether I deciphered the acronym correctly, because, why is it DoJ instead of DoD?). Nakonana (talk) 16:18, 9 December 2025 (UTC)

Yes, @Nakonana that is an error. Department of Defense = DoD or DOD, and DoJ or DOJ = Department of Justice. -- Ooligan (talk) 20:13, 9 December 2025 (UTC)

@Trade, I agree with @Nakonana to "keep the international community of Commons in mind."

Many citizens of the United States are also unfamiliar with these acronyms used in your recent uploads:

HSI

FUGOPS

ERO

Some are found here: Category:Media without a license as of 9 December 2025

Please, use the full names of the U.S. Government agencies. and their separtely named Departments to help searches and categorization. Thanks, -- Ooligan (talk) 10:24, 11 December 2025 (UTC)

"HSI" stands for "Homeland Security Investigations" and the people working for them are officially called "HSI criminal investigators"

Is "HSI criminal investigators" acceptable for you? Trade (talk) 13:11, 11 December 2025 (UTC)

@Ooligan: --Trade (talk) 13:41, 11 December 2025 (UTC)

Please use full names as suggested by @Nakonana. I note that @Tvpuppy's quotation from Commons:File naming#Clear is about NATO- an internationally recognized organization. Domestic U.S. Government agencies and their sub-divisions are not likely known internationally. Since the Commons project is international, please avoid the use acronyms. It can be used together with the full name to aid searches and understanding. For example: U.S. Immigration and Customs Enforcement (ICE)

You may already know that,

FUGOPS = Fugitive Operations of the U.S. Department of Homeland Security and

ERO = Enforcement and Removal Operations (ERO) of the U.S. Immigration and Customs Enforcement (ICE). This acronym is also shared by the U.S. Internal Revenue Service (IRS) for their Electronic Return Originator (ERO) related to eFiling tax returns. One more reason to use full names instead of acronyms.

IPR = National Intellectual Property Rights Coordination Center

Perhaps, when you have time, you will change the files names of your recent U.S. Immigration and Customs Enforcement (ICE) Flickr uploads which include, IPR, ERO, FUGOPS and of course, ICE. Thanks again for asking your questions here. Respectfully, -- Ooligan (talk) 21:19, 11 December 2025 (UTC)

What about the United States Border Patrol? Is "United States Border Patrol agents" appropriate? Trade (talk) 09:09, 12 December 2025 (UTC)

For file names local acronyms are fine as there are unlikely name clashes. For categories the full name should be used. A detailed description should contain both for searchability. GPSLeo (talk) 18:31, 12 December 2025 (UTC)

Yes. -- Ooligan (talk) 17:59, 12 December 2025 (UTC)

There are a few, though, where I'd go the other way. FBI, NASA, and NOAA in the U.S.; ONCE in Spain; CERN in Europe: all of these are far better known by their initialisms and acronyms than by their full names. I'd venture that in all these cases, most people who know these organizations couldn't quickly tell you the full name (maybe the FBI, but not the others). - Jmabel ! talk

Would it be worthwile to just have a list of preferred acronyms somewhere?--Trade (talk) 21:59, 12 December 2025 (UTC)

Not everything needs to be mandatory or forbidden. Length of filename can also be a consideration, and we really do allow a lot of latitude in naming files. I've tended toward longer filenames over time, but if I'm just indicating where a particular artifact was photographed, I'm still more likely to write "MUHBA" in a filename rather than "Museu d'Història de Barcelona", especially since the former is commonly used in English, Spanish, and Catalan, whereas the latter (the official name) is specifically Catalan.

I think it might be useful to have general advice that unless an organization is better known by its acronym/initialism it is better to spell it out, but I think we have to leave it to people to decide which way they go in any particular case. - Jmabel ! talk 00:01, 13 December 2025 (UTC)

Its very easy for people familiar with an acronym to use it, but acronyms are generally a problem for those from other cultures. Can we at least make sure that there is an explanation for all the acronyms? Even something like FBI or NHS may mean something else. Rathfelder (talk) 13:23, 15 December 2025 (UTC)

Are images that were taken from Flickr, but no longer hosted there, eligible for speedy deletion?

See for example: File:Family doing laundry outdside (14071772716).jpg. I believe we addressed this at least once before. When Flickr threatened to delete all your files unless you paid the $89 USD annually, many users deleted accounts as protest, or deleted images to stay under the free limit. --RAN (talk) 00:47, 15 December 2025 (UTC)

No, I don't think they're eligible for speedy deletion in that situation, unless the license was never reviewed. Isn't that partly the point of the FlickReviewer bots, to ensure that if a Flickr account is deleted or the content is deleted (or if maybe one day Flickr goes away entirely), we have evidence that the content was once published there under a free license? 19h00s (talk) 01:00, 15 December 2025 (UTC)

The Wayback Machine has a capture of that page from 2022. Sam Wilson 01:13, 15 December 2025 (UTC)

• The licenses need to be changed, since these are a republishing of historic images, but I don't see them as eligible for speedy. --RAN (talk) 01:17, 15 December 2025 (UTC)
• Of course not. This is completely against the very narrow range where a speedy deletion is performable. I'll remove it.

Even considered as a DR, the fact that it's no longer easily verifiable today doesn't matter. This is why we have the FlickrReviewer bot, to check these things in a trustworthy manner at the time when they are uploaded. Andy Dingley (talk) 01:41, 15 December 2025 (UTC)

I reverted the speedy, but it was immediately re-added. See Commons:Deletion requests/File:Family doing laundry outdside (14071772716).jpg Andy Dingley (talk) 02:06, 15 December 2025 (UTC)

Seems like there are some deeper issues with the Flickr account in question (although I think that should've been clearly linked/explained in the speedy tag rationales). 19h00s (talk) 02:11, 15 December 2025 (UTC)

• They just need a little research . Can someone check if more were nominated for speedy? --RAN (talk) 04:38, 15 December 2025 (UTC)
• Speedy? No. But certainly a DR for that image is reasonable. The license indicated could probably only be valid if the uploader either is very old or had inherited the rights to the photo, and the fact that it looks most likely to be rephotographed in a museum setting makes the latter unlikely. Given that all that was validated at time of upload is that this (unlikely) license was offered on Flickr, we are basically looking at a photo that lacks a plausible license claim, might be PD (but we have no evidence it is), and probably is going to end up deleted unless someone can work out who took it when and in what country (probably U.S., though certainly could be Canada) and when, and what might be its publication history. - Jmabel ! talk 07:23, 15 December 2025 (UTC)

  If you search on simpleinsomnia, it's pretty clear that on their Flickr account they stuck the same license on old works by a lot of photographers; they could not readily have been heir to all of them, and however old they are some of these go too far back to be their own work. The works involved include cabinet cards (always made by professionals), photobooth/strip photos, images in many different formats, etc. - Jmabel ! talk 07:30, 15 December 2025 (UTC)

  @Richard Arthur Norton (1958- ): You could see if other photos of theirs are tagged with "No source since" by searching for "simpleinsomnia" insource:"No source since". It actually looks like an awful lot are tagged that way (191 files). I'm about to go to bed, but probably at this point the best solution is a batch edit with VFC to change these to a regular deletion, which can then be procedurally closed as "keep" because they are pretty diverse and some are almost certainly PD, and then if someone wants to nominate them for deletion, they can do this right (not batching up unrelated photos).

  Pinging @Phillipedison1891 as a courtesy, because it looks to me like he made a mess here. @Phillipedison1891: the absolutely simplest thing is if you would revert your own "No source since" speedies here and start nominating these one-by-one or in reasonable groups. I believe you are the only person who can simply revert rather than turn these immediately into DRs. - Jmabel ! talk 07:40, 15 December 2025 (UTC)

  I apologize for any disruption I inadvertently caused, but reading the relevant policy, I thought the {{No source since}} tag was appropriate. This Flickr account always, always, always just uploads old-looking photos from private sources (antique shops I suspect) without any additional information. I've spot checked quite a few with Google Lens and TinEye and the only matches I can find are those that cite back to that Flickr account. You can see this deletion request where I disclosed this and offered to start a standard deletion request instead. Since this has proven controversial, I have done so. Phillipedison1891 (talk) 15:33, 15 December 2025 (UTC)

• I don't want to get involved in an edit war, but the deletion of the speedy tags are being reversed. See for example: File:Young African American boy standing on a porch (16487759743).jpg. See above for the rationale, that the Flickr account does not count as a source. The Flickr account scanned unique historical images, and is no longer active. I agree that the licenses need to be changed, if they are PD-US or, if they circulated prior to 1930 or never had a copyright registration or renewal prior to 1964 (PD-US-not renewed). I don't believe adding "no source" is correct. We allow, and even encourage people to scan historical images in their collections. The template is {{Photo scan}}. I think this would have been better by starting with a question here at the pump, rather than jumping to speedy deletion. --RAN (talk) 16:14, 15 December 2025 (UTC)
• It looks like all have been migrated to Commons:Deletion requests/Files on User:Phillipedison1891/Simpleinsomnia batch delete in a massive list. One request above was "not batching up unrelated photos". --RAN (talk) 17:38, 15 December 2025 (UTC)

File:Carlos Villarreal Esparza.png

At File:Carlos Villarreal Esparza.png can we return the date to "circa 1865". Pretending that the image maybe from any date up to the present is just silly. We know the person's approximate age, and their death date. I don't mind arguments that "circa 1870" may be more appropriate, but pretending there is no way to estimate the date is just silly. RAN (talk) 23:20, 20 December 2025 (UTC)

•  Done -Nard (Hablemonos) (Let's talk) 23:28, 20 December 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 15:29, 21 December 2025 (UTC)

App says I am blocked

If I try to upload using the Commons app on Android, it says I am blocked from editing.

I can edit without issue in my browser, on the same device.

Does anyone else see this issue? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:56, 15 December 2025 (UTC)

Very weird. But your log says you are not banned :) --PantheraLeo1359531 😺 (talk) 12:46, 15 December 2025 (UTC)

Have you tried to log out and then log in again in the app? Ruslik (talk) 19:13, 15 December 2025 (UTC)

No, but when I tried again later in the day, it worked. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:40, 16 December 2025 (UTC)

@Pigsonthewing I don't think you are IP exempt ? Because lots of IP addresses in the mobile space are permanently blocked, either locally or even at the wikimedia global level. Only IP exempt will do to get around that, not matter how long you have been on the website. —TheDJ (talk • contribs) 09:59, 16 December 2025 (UTC)

I was at home, on my own broadband connection. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:39, 16 December 2025 (UTC)

sr-ec Language Tag in Captions

I noticed this change log in my Watchlist: "Added [sr-ec] caption: Слика "Агонија" (1878), Аугуст Фридрих Шенк". The problem is sr-ec is not a correct language tag; if I understand it correctly, the fully correct tag for Ekavian Serbian would be sr-ekavsk, though sr-Cyrl-ekavsk would be useful for tagging the Cyrillic alphabet. (I'm not confident in this, but AI tells me that the ekavsk is irrelevant here, that sr-Cyrl-ijekavsk would be exactly the same, so probably the best tag would be sr-Cyrl?)

Beyond the problems with the language, I don't see what generated it and how to fix it, as it's part of a caption. Is this an internal thing, where sr-ec is part of a list that was picked off of, or was it an external thing, where sr-ec was typed in by the user? If the latter, where do I fix it? If the former, ergh, I don't know that I want to mess with it, but it really should use standard language tags.--Prosfilaes (talk) 01:35, 17 December 2025 (UTC)

Please see mw:Project:Language policy#Language codes or mw:Manual:Language#Names.php, language codes (e.g. sr-ec) are set internally and can be seen here. Thanks. Tvpuppy (talk) 02:15, 17 December 2025 (UTC)

Also, there's a related discussion about renaming "sr-ec" to "sr-Cyrl" in phab:T117845. Thanks. Tvpuppy (talk) 02:23, 17 December 2025 (UTC)

Wikimedia Foundation Product & Technology Initiatives for this Fiscal Year published

Hi all, we have published a list of initiatives that Wikimedia Foundation has decided to take regarding Wikimedia Commons.

Over this fiscal year, Commons has been the focus of several Product & Technology efforts addressing infrastructure scalability, contributor workflows, event organization, multimedia performance, and tool sustainability. These initiatives fall into four broad categories: Infrastructure & Platform Stability; Contributor Experience & Community Workflows; Multimedia & Data Modernization; and Safety, Governance & Responsible Use of Infrastructure.

Together, these initiatives reflect a combination of foundational engineering, contributor-facing product improvements, and long-term sustainability work that reinforce Commons’ role as the movement’s central media repository.

You can read more about them at this page. We are of course welcoming feedback on what you think might be some more initiatives we need to take. You can reply here or on this year's initiatives talk page. Thank you in advance! Sannita (WMF) (talk) 12:15, 17 December 2025 (UTC)

Respectfully, these initiatives (with the possible exception of video2commons work, and maybe the DB stuff depending on how you define "commons") are only tangentially related to commons. Bawolff (talk) 17:40, 17 December 2025 (UTC)

Writing a bot

Hello, I having an idea of a bot, here how it works:

1. Get a files (SDC) where this match:

creator (P170)	some value edit Wikimedia username (P4174) <value here> 0 references add reference
		add value

Then change the "some value" to a item that have the same value of Wikimedia username (P4174) in the qualifer.

Could it be possible, even this type of statement match around ~40 million files? DinhHuy2010 (talk) 03:21, 17 December 2025 (UTC)

Can you explain what you're specifically trying to accomplish here? Omphalographer (talk) 03:51, 17 December 2025 (UTC)

Replace the "some value" with a item.

That item must have the same value of Wikimedia username (P4174) with the qualifer

Useful I guess for tracking purpose? DinhHuy2010 (talk) 03:58, 17 December 2025 (UTC)

@DinhHuy2010: I don't see what you think would be more useful, but that may be because I don't see what you are actually proposing. creator (P170) cannot take a string for a value; either you are ignoring that, or your wording is unclear. If the latter, could you show with a {{Statement}} what you propose this should end up looking like? - Jmabel ! talk 06:24, 17 December 2025 (UTC)

@Jmabel

For example, for Jimbo Wales

Before:

creator (P170) some value / Wikimedia username (P4174) Jimbo Wales

After:

creator (P170) Jimmy Wales (Q181) / Wikimedia username (P4174) Jimbo Wales

Either overwrite the statements or create a new statement and mark as preffered and the old statement as deprecated. DinhHuy2010 (talk) 06:48, 17 December 2025 (UTC)

So do this only if there is a Wikidata item for that user? I believe this has been proposed before, and there were people who had Wikidata items but did not want their Wikidata item tied that closely to their activity as a user. And, of course, most users do not have Wikidata items, and probably (in my view at least) shouldn't. - Jmabel ! talk 07:17, 17 December 2025 (UTC)

@Jmabel, proposed before? What does that mean?

Also "And, of course, most users do not have Wikidata items, and probably (in my view at least) shouldn't." does this mean?

Should I continuing to do this anyway? DinhHuy2010 (talk) 07:29, 17 December 2025 (UTC)

This is nothing we can decide on Commons. The rules for items for people are defined in the Wikidata notability policy. This does not include even the most active contributors here unless they have an identifier in external databases. It was discussed to have some kind U-items for users but the implementation was never discussed further. GPSLeo (talk) 09:04, 17 December 2025 (UTC)

I think the obvious solution here is to only do it for people with wikimedia username field set on their wikidata item. If someone doesnt want the association known then i guess it is their responsibility to make sure the association isnt set at wikidata. Bawolff (talk) 17:44, 17 December 2025 (UTC)

@DinhHuy2010: I'm not sure what is unclear to you about my meaning, but I'll try being more verbose. (1) This is not the first time that someone has proposed making this substitution; last time I saw it proposed, several users who have Wikidata items indicated that they would not want their Wikimedia account tied to their real-world identity. (2) The majority of people who upload photos here do not have Wikidata items for themselves as individuals and I believe that is entirely appropriate. Your example works only because Jimmy Wales (Q181) exists for Jimbo. To make this work in general, you have to have a Wikimedia item for every user who uploads. Or maybe the answer to your first question is "yes, do this only if there is a Wikidata item for that user and it is already tied to their account," in which case the rest of what I said is largely moot, though it does raise a different question: if there is a Wikidata item about you, is it possible to opt out of having your account tied to that Wikidata item, if someone else has a citation to document that you are the same person? - Jmabel ! talk 21:37, 17 December 2025 (UTC)

If the user has P4174 set they are already effectively connected. I certainly wouldn't advocate adding that to non-notable people against their will, but i feel like once its set the person is connected. Wanting to not be associated after that point is like uploading an image to commons but demanding it not be used on Wikipedia (to be clear, i dont know specificly what DinhHuy2010 is advocating for, but i would only advocate doing this for people who have an existing wikidata item with P4174 set, leaving the rest to use blank nodes (some value) as they currently do.) Bawolff (talk) 00:08, 18 December 2025 (UTC)

once its set the person is connected: so Commons:Harassment#Posting of personal information would not apply here? That seems wrong to me. - Jmabel ! talk 01:12, 18 December 2025 (UTC)

If someone posts personal information on their user page on another projet, and then it gets an interlanguage link from commons, is that a violation of the policy? As written technically maybe, but i think most people would think that is rediculous. I think this is a similar situation. Note that wikidata does have a policy (according to usage instructions at d:Property:P4174) that using the property to out people at wikidata will result in a block, so it shouldn't have personal information against people's wills. I think its important to respect people's privacy, but if they've voluntarily disclosed it on a wikimedia project, i dont see anything wrong with linking to it. Bawolff (talk) 03:35, 18 December 2025 (UTC)

This has been one of my pet peeves of SDC for a long time. Doing this not only makes sense for how commons ontology is set out, it also makes queries (especially aggregating queries) much more performant on blazegraph. So i think this is a really good idea. Bawolff (talk) 17:42, 17 December 2025 (UTC)

Small question

How can I delete one of my contributions? Benzekre (talk) 10:57, 18 December 2025 (UTC)

It depends on which type of contribution…an edit, or an upload, or an upload of a new or prior file revision, or a recent upload. Prototyperspective (talk) 15:26, 18 December 2025 (UTC)

@Benzekre: if, as I suspect, you are asking how to get a recently uploaded file deleted, you can tag it with {{SD|G7}}, and it will almost certainly be deleted. This is further explained at Template:My bad upload, if you want to understand a little better. If you are asking something else, then you'll have to be more specific. - Jmabel ! talk 21:21, 18 December 2025 (UTC)

Continuing notifications problem

I filed a deletion request just now, and I was subscribed to the whole December 18 deletion request page rather than just my own deletion request. This was posted here a couple weeks ago, but is still a problem. Geoffroi 18:13, 18 December 2025 (UTC)

See Commons:Village pump#Notifications. It's probably not something that can be solved on Commons's end. Nakonana (talk) 18:45, 18 December 2025 (UTC)

Would it help if I added Commons:Deletion requests to muted pages in notification preferences? Geoffroi 19:18, 18 December 2025 (UTC)

Probably not, because that isn't the page which the notifications stem from - it's the daily subpages like Commons:Deletion requests/2025/12/18. Omphalographer (talk) 19:56, 18 December 2025 (UTC)