Shortcut: COM:VP

#	💭 Title	💬	👥	🙋 Last editor	🕒 (UTC)
1	Help choosing scanning resolution for photos	11	10	Taylor 49	2025-05-13 09:08
2	Naming conventions for flags (for example Flag of Honduras)	14	7	NicoScribe	2025-05-18 10:17
3	Are we nearly there yet? 5000 media of 2018 needing categories, please	8	5	Tvpuppy	2025-05-19 19:37
4	Poland bans photography of military and critical sites, including bridges, tunnels, viaducts, port facilities and the National Bank	22	14	Dronebogus	2025-05-15 20:05
5	Enabling Dark mode for logged-out users	3	3	Jon (WMF)	2025-05-13 19:41
6	Historic Baltic ferry shedules	8	5	Smiley.toerist	2025-05-18 22:18
7	Wikidata links beginning with M	12	8	GPSLeo	2025-05-13 08:02
8	Flickr searching closed again	12	6	JayCubby	2025-05-19 21:55
9	Help with preparing a page for translation	4	2	Gestumblindi	2025-05-14 18:56
10	Notification of DMCA takedown demand — The Queen presents the 1966 World Cup to England Captain, Bobby Moore	1	1	JSutherland (WMF)	2025-05-12 19:55
11	Notification of DMCA takedown demand — Blessed Virgin Mary	1	1	JSutherland (WMF)	2025-05-12 20:14
12	Pronunciation files in topic cats or even worse in disambig cats	5	4	Taylor 49	2025-05-14 09:35
13	Wrong infobox picture	3	2	Fountains of Bryn Mawr	2025-05-13 22:38
14	Concerns Regarding Cross-Wiki Conduct and Tone by Administrator {{noping|Bedivere}}	1	1	HingWahStreet	2025-05-14 02:00
15	WebP file format and copyright violations	10	7	RoyZuo	2025-05-15 10:12
16	w:Natalya Arinbasarova or not?	3	2	Romano1981	2025-05-15 07:27
17	Image processing question for licence	10	5	Omphalographer	2025-05-15 18:40
18	Category:Images from dead websites	5	4	Trade	2025-05-14 23:50
19	Metadata section size?	7	2	The Bushranger	2025-05-15 22:50
20	Do we do anything when the source is no longer available?	13	7	Jmabel	2025-05-17 21:19
21	Category:Cape Verde	7	4	Prototyperspective	2025-05-15 22:14
22	Exey Panteleev photography and COM:SCOPE	38	14	Rhododendrites	2025-05-17 14:39
23	Call for Candidates for the Universal Code of Conduct Coordinating Committee (U4C)	1	1	Keegan (WMF)	2025-05-15 22:06
24	Dating postcard	7	5	Asclepias	2025-05-16 23:28
25	Advice for uploading others' photos	21	5	Adam Black	2025-05-18 11:32
26	Please vote for new checkuser	1	1	HingWahStreet	2025-05-17 11:22
27	1921/22 motorcycle type?	1	1	Smiley.toerist	2025-05-17 12:31
28	Question about watermarks	8	6	John Cummings	2025-05-19 09:31
29	Just when will we get a better system than categories	39	10	Prototyperspective	2025-05-19 10:55
30	Difference between "architecture" and "structure"?	4	4	Jmabel	2025-05-18 16:27
31	Comparison of flickr upload tools	1	1	RoyZuo	2025-05-18 14:47
32	Species identification	3	3	Prototyperspective	2025-05-18 21:23
33	Thousands separators	2	2	Tvpuppy	2025-05-18 23:14
34	List of files on wikis that are also on Commons	1	1	MGA73	2025-05-18 21:26
35	Family snapshots	12	6	Fountains of Bryn Mawr	2025-05-19 20:07
36	Outreachy intern working on Cat-a-lot – feedback and suggestions welcome!	2	2	Prototyperspective	2025-05-19 13:33
37	Freedom of U.S. panorama, seaching for the WMF letter	5	4	Jmabel	2025-05-19 20:03
38	FYI: Creative Commons 4.0 arriving soon to Flickr.	1	1	Koavf	2025-05-19 19:36

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

Centralized discussion See also: Village pump/Proposals   ■ Archive Commons talk:Criteria for speedy deletion#Explicitly expand F10 to include AI? (1 May 2025) Discussion on Copyright law of North Korea (16 March 2025) Commons_talk:Freedom of panorama#Proposal to abolish acceptance (2 March 2025) Categorization of SVG files (13 February 2025) Costumed character files (14 October 2024) Third-party images published by the National Weather Service (26 August 2024) Commons:Requests for comment/Hosting of free fonts in Commons (18 July 2024) How do we organize categories by date (14 May 2024) Should PD-CQ Roll Call be used for recent images? (5 January 2024) Template: View   ■ Discuss    ■ Edit   ■ Watch

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

I am writing to get advice on what resolution I should use to scan film photos, and an explanation for how to make that decision. It is costly to scan at the highest resolution, and if I use high resolution, I want that choice to make sense for the photos that I have.

Are low, medium, and high resolution scans different in this case?

I see guidance throughout the Commons documentation that users should upload content at the highest resolution, but I am questioning that advice.

• Commons:Why we need high resolution media
• Commons:File_types#Highest_resolution

I am scanning physical film taken in 1993 from a camera. The time difference to scan low / medium / high resolution is significant. As I look at the different outcomes, I personally cannot identify great differences in detail. The photo File:Aerial view of five Parkmerced apartment buildings.jpg is elsewhere used as an example of why uploaders should use high resolution photos, and I understand that because by zooming in, it is easy to see more detail. That file zooms in nicely, but is only a small 8mb. With my photos, high resolution makes 25mb files, and to me it appears that zooming in just makes the pixels larger without clarifying anything. Any computer can zoom in on photos regardless of resolution, and when I zoom in with my device, I see no difference between low resolution and high resolution scans. I am not sure when the benefits diminish for higher resolution scanning.

I uploaded three resolution versions in a single Commons file. Here they are -

• File:Freaks for Freedom.jpg - low, 1mb file
• medium, 5mb file
• high, 25mb file

Please advise - what is the difference in value for archival scans at these three resolutions? Bluerasberry (talk) 22:43, 25 April 2025 (UTC)[reply]

It can depend on the scanner but I have an Epson Scan 600 and have found that scanning at 1200 DPI and saving the images as Jpegs is the best way to do it. I use to scan images at 1200 DPI and save them as TIFF files but they ended up being to large and I don't think people are using images for print much these days anyway, which is the only justification for TIFF files. Really, you could probably get away with scanning 600 DPI jpegs and you'd be fine. --Adamant1 (talk) 22:58, 25 April 2025 (UTC)[reply]

If all of the photos were taken with the same camera and type of film, your "medium resolution" scan should be sufficient for all of them. The film grain is already clearly visible at that resolution - there's unlikely to be any more detail left to capture in the original photos. Omphalographer (talk) 23:09, 25 April 2025 (UTC)[reply]

e/c

I'll approach it from a different perspective.

If you want to print something at a size of 8 by 10 inches, then you want to have a resolution of at least 8 megapixels.

If you want to print something at a size of 4 by 5 inches, then 2 megapixels is enough.

Many photos taken on 35 mm film are suitable for 8 by 10 inch prints. If you want to go larger, then one needs a very fine grain film or a larger than 35 mm film format.

The Freaks photo does not seem suited for 8 by 10 reproduction. It is either grainy or blurred, so the medium resolution (6 MP) is enough. The large banner does not have a uniform color, and some text on a white sign is not sharp. I do not know why. I did not see a place in the photo that has substantially better focus than other. The film may be grainy, old, or a long exposure with camera movement. Colors on old prints would bleed.

I am not happy with the Parkmerced photo either. The cars at the upper left look like they are double exposed: steady for half the exposure and then a jump movement to another steady half. That seems an unlikely circumstance.

When I was using film, there was a huge difference between Plus-X and Tri-X. With Plus-X one could get fine details. Not so with Tri-X.

I had seen the black and white movie Arsenic and Old Lace on TV, but several years ago I saw a 35-mm print at a theatre. I was blown away by the resolution.

Resolution is not everything. Compare

• File:Sir Winston Churchill - 19086236948.jpg 6 MB 45 MP with
• previous version 1 MB 11 MP

The smaller size, lower resolution is sharper. Look at the weave of his shirt.

Glrx (talk) 00:22, 26 April 2025 (UTC)[reply]

A higher resolution image can carry more information than a lower resolution one, but that's not necessarily always the case. Commons policy acknowledges this - somewhat - for example COM:OVERWRITE states that images shouldn't be overwritten with artificially upscaled versions. The higher-resolution version of the example above is indeed of lower quality than the lower resolution one, so I've reverted it. ReneeWrites (talk) 11:43, 6 May 2025 (UTC)[reply]

In short: The best quality available. Scanners usually allow choices like 1200dpi or more, in theory. But above a certain border, a scanner cannot achieve more details when increasing the dpi rate. Many scanners reach their physical resolution at 800dpi, which means that scans of 1200dpi or more don't achieve better quality. A research can be useful, depending on the model --PantheraLeo1359531 😺 (talk) 14:48, 26 April 2025 (UTC)[reply]

The answer depends strongly on what kind of camera and film were used, what the lighting conditions were, and how sharp the focus is in the image. There's no point scanning a blurry or noisy photo at 1200 dpi. Personally, for non-professional photographs I don't think scanning at higher than 600 dpi is usually necessary. In the examples that you present, I would choose something higher than medium, but lower than high. Nosferattus (talk) 05:20, 28 April 2025 (UTC)[reply]

@Bluerasberry: The simple answer is to use the most resolution one can get their hands on. However sometimes when scanning low quality image, high resolution will not get you better quality image, so more nuanced answer would be depending on what you are scanning. For scanning sharp photo prints I would use the highest resolution I can, prints in a book would require lower resolution, and scanning bad newspaper prints would require the lowest resolution. --Jarekt (talk) 22:59, 2 May 2025 (UTC)[reply]

Analog stuff is harder than digital, but if you're scanning a 640x480 pixel image, you need at least a 1280x960 scan to be able to reproduce it, theoretically (w:Nyquist–Shannon sampling theorem), and I'd want at least 2560x1920 to get it exactly. If someone wants to work on your example image, I'd say that newspaper print is scanned at too low a resolution; I'd want at least double that resolution to try and remove the half-toning.--Prosfilaes (talk) 01:51, 7 May 2025 (UTC)[reply]

Pick the highest resolution that gives a visual benefit over a lower one. Scan at 300 dpi and at 600 dpi, zoom up both photos on your screen, and pick some interesting details (for example text). Are there details that look better at 600 dpi than at 300 dpi? It is crucial to focus on details, looking at the complete photo does not give any useful hint. Based on 300 dpi vs 600 dpi, try even higher or even lower. Stop going up AFTER quality has ceased to improve, or stop going down BEFORE quality has started to worsen.

Blurry photos in an absurdly high resolution constitute an efficiency problem. Many current mobile phones give something around 6'000 x 4'000 pixel, but the useful resolution is barely 1/4 in terms of length or 1/16 in terms of area of that ie ca 1'500 x 2'000. This is an illusion of improvement, and in fact just wasting storage space and processing performance. Why is it like that? Pressuring people to buy new mobile phones an computers, and to subscribe to a more expensive internet connection. This is just business. Taylor 49 (talk) 08:45, 13 May 2025 (UTC)[reply]

details What I can see is that all 3 verions are remarkably noisy. Next step worth to try is to scan at the highest resolution (ca 6'000 x 4'000) and subsequently zoom down by factor 4 (in terms of length) using a good program. So scan at the highest one, but then zoom down trying different factors, stop going down BEFORE quality has started to worsen. Taylor 49 (talk) 09:08, 13 May 2025 (UTC)[reply]

Given the ongoing discussion of the Syrian flag, and by request of User:Panam2014 on my talk page (and discussed with User:Jmabel briefly), I wanted to discuss further our naming conventions of recently changed flags and Honduras's flag in particular because that may be one of the least controversial to discuss. Abzeronow (talk) 23:02, 27 April 2025 (UTC)[reply]

@Abzeronow: Are you saying you want to discuss it here (in which case, start by laying out the issues) or that you want people to participate in a discussion elsewhere (in which case, link)? - Jmabel ! talk 23:07, 27 April 2025 (UTC)[reply]

You're right, I should have been more clear, I wanted to start the discussion here and I didn't want to forget to do it. Basically, as evidenced on the of Syria (2025-) talk page], there is an idea that "Flag of Foo" (where Foo is a country) should always be a redirect so our templates can always stay up to date when they just want the country's flag. Regimes and flags can change within some of our lifetimes (my country the United States has last updated its flag in 1960) and we obviously also want a stable name for the current flag of a country, which is why the current flag of Syria is named File:Flag of Syria (2025-).svg. Some are resistant to this idea and always want the current flag to be a file. Since we are doing this for Syria, there is the question of "renaming the flags who have been adopted recently, like Honduras, Kyrgyzstan, South Sudan, Mauritania, Malawi, Myanmar, Libya, Turkmenistan, Iraq, DR Congo, Georgia, Rwanda" that was posed on talk page. Of course, we should start where the discussion would be least controversial. Honduras in 2022 changed the color of its flag from navy blue to turquoise in accordance to a 1949 decree that had never been carried out as en:Flag of Honduras explains. The file File:Flag of Honduras.svg shows revisions with the old navy blue flag and the new turquoise flag. So if the Honduras flag file should be a redirect, should the file be split and then older versions merged with the file depicting the old flag? Should all revisions be moved to a File:Flag of Honduras (2022-).svg file? Basically, it would be a good idea to hammer out what we should do when flags of countries change so the disruption to various Wikimedia projects is minimal and have a good idea of how to "futureproof" flags of countries. I hope I've started to lay out the issues that make for a fruitful discussion on these matters. Abzeronow (talk) 22:09, 28 April 2025 (UTC)[reply]

@Abzeronow: as you know, I'm on the side of moving toward having File:Flag of FOO always be a redirect. Then we can tell sister projects that if you want an article (e.g. about a particular city, or the national football team) to just show whatever is the current flag, use File:Flag of FOO; if it is important that it show a particular flag and not change over time (e.g. you are writing about a particular event, and want the article to retain the chronologically accurate flag for that event) you use something more like File:Flag of FOO 1928-1972 or File:Flag of FOO 1972-.

In theory, the redirect between File:Flag of FOO and, say, File:Flag of FOO 1972- could go either way. I favor having File:Flag of FOO be the redirect, because it seems to me to leave the histories clearer when the flag might later change. If File:Flag of FOO is a redirect, and the flag of FOO changes in 2027, we just:

• upload the new File:Flag of FOO 2027-
• use the usual means to move File:Flag of FOO 1972- to File:Flag of FOO 1972-2027 (keeping the resulting redirect)
• make File:Flag of FOO redirect to File:Flag of FOO 2027- (so its history will show where it used to redirect).

If the redirect is the other way around, we have to do something like:

• move File:Flag of FOO to File:Flag of FOO 1972-2027 (deleting the resulting redirect)
• change the redirect File:Flag of FOO 1972- to point to File:Flag of FOO 1972-2027
• upload the new flag as File:Flag of FOO (note that this will have no record of the history of what was at this name)
• create a new redirect from File:Flag of FOO 2027- to File:Flag of FOO so people have some way to refer to this specific flag that will be stable over time.

There are other ways to do it, but I think they all leave behind confusing file histories. - Jmabel ! talk 03:47, 29 April 2025 (UTC)[reply]

I think we should not have such naming guidelines and redirects. The template use case is exactly what Wikidata is for. If the templates just use the current flag from Wikidata the name of the file on Commons does not matter. GPSLeo (talk) 05:11, 29 April 2025 (UTC)[reply]

@GPSLeo: are there any Wikipedias that currently do this through Wikidata? (Let me guess that if there is one it is de-wiki, because so much of the Wikidata expertise is in Germany.) I know en-wiki does not. - Jmabel ! talk 17:53, 29 April 2025 (UTC)[reply]

I do not know. Dewiki is also one of the wikis using the lowest amount of Wikidata. Not even simple info boxes use Wikidata as fallback for photos. Wikipedia and Wikidata community in Germany are quite separate. During the introduction of structured data we even had discussions if it would be better to get rid of the file names entirely and use the M-ID instead. We should not support using a system of file names and wikitext page redirects to keep old templates working. Instead we should encourage everyone to use a more reliable solution using modules and Wikidata. GPSLeo (talk) 18:28, 29 April 2025 (UTC)[reply]

Yes we should get rid of filenames and use m id. i had the same thoughts special:permalink/1026118809#thoughts. also cat titles, all page titles in general. RoyZuo (talk) 12:37, 30 April 2025 (UTC)[reply]

for 2 obvious reasons:

1. we shouldnt and cant decide what's the "correct" title for a file or which file is "correct" for a title.
2. we can host a myriad of different versions and leave what they should be called to people who use those files.

RoyZuo (talk) 06:04, 1 May 2025 (UTC)[reply]

I support the changes. We should split the current file and transfer the pre 2022 versions to File:Flag of the Republic of Honduras (1949-2022).svg. Panam2014 (talk) 10:55, 1 May 2025 (UTC)[reply]

If no objection, I will start working on that tomorrow night. Abzeronow (talk) 02:14, 8 May 2025 (UTC)[reply]

I've moved the 2022 version with history. I'll do the history merge of pre-2022 version tomorrow. Abzeronow (talk) 00:15, 11 May 2025 (UTC)[reply]

Hello @Abzeronow: if you look at GUC/CommonsDelinker and search the text "Flag_of_Honduras.svg", you will find hundreds of pages where CommonsDelinker has removed "Flag_of_Honduras.svg". Moreover, my GUC link does not show all the removals (because it is limited to 20 results per wiki). What to do? --NicoScribe (talk) 10:17, 18 May 2025 (UTC)[reply]

• A bit belated to this, but - File:Flag of the Republic of Honduras (1949-2022).svg seems to show the flag that Flag of Honduras says is the 1866-1949 flag? - The Bushranger (talk) 05:24, 16 May 2025 (UTC)[reply]

We need your help, please, to categorise 5,000 files from "M" to "W", or by adding categories to more obvious candidates in between. We started on 6 November 2024 at 43,242 files, but now it is getting more and more difficult. --NearEMPTiness (talk) 04:09, 2 May 2025 (UTC)[reply]

Keeping up the momentum. We need your help, please, to categorise 4,000 files from "O" to "W", or by adding categories to more obvious candidates in between. --NearEMPTiness (talk) 10:25, 4 May 2025 (UTC)[reply]

Now, we need your help, please, to categorise 3,000 files from "R" to "W", or by adding categories to more obvious candidates in between. --NearEMPTiness (talk) 09:23, 11 May 2025 (UTC)[reply]

Now it's less than 2000 files --PantheraLeo1359531 😺 (talk) 17:46, 15 May 2025 (UTC)[reply]

There are around 500 files left. We’re very close to the finish line. Keep it up! Tvpuppy (talk) 18:36, 18 May 2025 (UTC)[reply]

For the other cats which are substantially larger I think it would be good to categorize the used files. It's not necessarily very useful if a category is filled with lots of largely useless files (which btw then somewhat require subcategorization there) but files that are in use would definitely be useful in the cat about the subject. See this scan for files in use in another cat, where the file is used also indicates which categories the file belongs to. Prototyperspective (talk) 11:26, 19 May 2025 (UTC)[reply]

---

Looks like we are finished. For 2018, that is. - Jmabel ! talk 19:29, 19 May 2025 (UTC)[reply]

Well done to everyone who had helped categorising them! Tvpuppy (talk) 19:37, 19 May 2025 (UTC)[reply]

Apparently Poland now (since April 17, 2025) “prohibits photographing or filming Polish military facilities and critical infrastructure without authorization”. About 25,000 sites nationwide are concerned, including bridges, tunnels, viaducts, port facilities and the National Bank. Sources: [1], [2], [3]. I'm not sure how that affects already existing photographs taken before April 17, 2025. --Rosenzweig τ 12:47, 5 May 2025 (UTC)[reply]

Not a copyright issue, not our problem Trade (talk) 13:18, 5 May 2025 (UTC)[reply]

It's only "not our problem" if we're okay with Commons being banned in Poland. Robkelk (talk) 15:24, 7 May 2025 (UTC)[reply]

Also understandable, as the Ukrainian war nears. I should always be carefull in photographing militairy transports or anything related. I would not want to inadvertently inform the Russians, as they certainly scan all Commons files.Smiley.toerist (talk) 14:21, 5 May 2025 (UTC)[reply]

Even the BBC is barely aware the site exists seperately from ENWP. I would not be too worried Trade (talk) 19:01, 5 May 2025 (UTC)[reply]

I'm aware it's not a copyright issue, that's why I posted it here and not at COM:VPC. “not our problem” is a rather shortsighted view however IMO. The ban might very well be or become a problem for anyone taking photographs in Poland, including our users. I think we do have some users living in Poland or visiting there. The German foreign office specifically issued a travel advisory because of this issue. --Rosenzweig τ 15:09, 5 May 2025 (UTC)[reply]

As someone who photographed and filmed a few bridges last year in Poland when I went there for Wikimania 2024, that might have been a problem if those rules were in effect. I don't know if a footbridge in Katowice or bridges over the Odra river in Wroclaw are part of that list but it certainly could make future trips to Poland an issue since I would want to film landmarks that catch my attention (I would not purposely film military facilities though for the reasons Smiley.toerist gave.) Abzeronow (talk) 18:42, 5 May 2025 (UTC)[reply]

I wonder if these rules will take effect as desired. I assume there will be many tourists who don't know or don't care. Might be hard to control --PantheraLeo1359531 😺 (talk) 19:39, 5 May 2025 (UTC)[reply]

It'll probably be like many other laws which are on the books but only enforced when the authorities wish to do so. --Rosenzweig τ 20:29, 5 May 2025 (UTC)[reply]

It might at least be worth having a warning template for images like there is for ones containing Nazi symbols. Otherwise it kind of puts re-users at risk. Let alone photographers. --Adamant1 (talk) 20:36, 5 May 2025 (UTC)[reply]

At what point were it suggexted that re-users were at risk? Trade (talk) 20:50, 5 May 2025 (UTC)[reply]

Just speculation on my part. Realistically I don't think there's anything that can be done about it on our end outside of that. People obviously can't be stopped from uploading images of Poland to Commons. So it seems like the only options are having a warning or just ignoring it. --Adamant1 (talk) 00:25, 6 May 2025 (UTC)[reply]

@Rosenzweig, you wrote, "The German foreign office specifically issued a travel advisory because of this issue." Can you please provide a link? Thanks, -- Ooligan (talk) 01:51, 6 May 2025 (UTC)[reply]

I'm jumping in: https://www.auswaertiges-amt.de/de/service/laender/polen-node/polensicherheit-199124 . Regards, Grand-Duc (talk) 06:53, 6 May 2025 (UTC)[reply]

In the Cold War, Russian maps of England were more accurate than English maps, because English maps left out details that might help the Russians. It's the 21st century; everyone has access to satellite data, certainly including the Russians, and tiny video cameras in glasses that would have made 20th century spies drool are available to everyday Joe to film YouTube videos in Goodwill. Why do governments continue to make these rules?--Prosfilaes (talk) 01:37, 7 May 2025 (UTC)[reply]

Security theater. - Jmabel ! talk 04:04, 7 May 2025 (UTC)[reply]

Agreed. Satelite views cannot always replace detailed ground level views. The militairy value of most images, is very time limited. Its no use to to know where your enemy (personel or equipement) was a month ago.Smiley.toerist (talk) 11:44, 9 May 2025 (UTC)[reply]

If I understand it correctly, Rosenzweig, the plan is to indicate affected objects with clear signs (Tagesschau says at the end of the article "Zu Missverständnissen dürfte es kaum kommen, schließlich sind die Schilder groß, rot und eindeutig", that is: "There should be little chance of misunderstandings, after all the signs are large, red and clear.") So, personally, I would avoid photographing objects marked with such a sign, but otherwise, we should be fine. I can't imagine that typical tourist sights (like a historical bridge in a city) would be affected, but of course, we are interested in more than that. Haven't seen anything about retroactivity. Gestumblindi (talk) 08:52, 13 May 2025 (UTC)[reply]

The German foreign office says „die Kennzeichnung kann jedoch unter Umständen schlecht sichtbar oder nicht eindeutig erkennbar sein“ (“However, the marking may be poorly visible or not clearly recognizable under certain circumstances”). So ... take your pick :-) --Rosenzweig τ 08:58, 13 May 2025 (UTC)[reply]

There’s precedent in an incident with a military radio station in France. The article was briefly deleted after the authorities harassed a local sysop but it was almost immediately restored and not followed up. The Polish authorities are most likely not going to notice nor care about any images on Commons; for now a legal notice and common sense (don’t photograph anything with a big red “no photography” sign) is probably all we need; hopefully the authorities will just ask us to delete any photos they find concerning and not immediately resort to legal threats. Dronebogus (talk) 19:29, 15 May 2025 (UTC)[reply]

At least images used on Wikipedia are often amongst the first Google search results, and unlike Commons Wikipedia is widely known. That said, I wouldn't be as certain to believe that "they'll probably never take notice of, and even if they do, they'll probably not care, and even if they care, they'll politely ask to delete first". --A.Savin 19:52, 15 May 2025 (UTC)[reply]

What happened in the French case was the authorities did seem to request the page be taken down, Wikimedia basically just asked “why?”, and then they went ballistic and started threatening some random volunteer with legal consequences. This created a big media storm that made the French authorities look bad and the whole thing seems to have fizzled out. The takeaway here seems to be “they hopefully, and likely, will just ask, and if they don’t and are dicks about it Wikimedia will probably win and they’ll look stupid”. Dronebogus (talk) 20:05, 15 May 2025 (UTC)[reply]

Hello Wikimedians,

Apologies, as this message is not written in your native language. Please help translate to your language.

The Wikimedia Foundation Web team will be enabling dark mode in this Wiki by 15th May 2025 now that pages have passed our checks for accessibility and other quality checks. Congratulations!

The plan to enable is made possible by the diligent work of editors and other technical contributors in your community who ensured that templates, gadgets, and other parts of pages can be accessible in dark mode. Thank you all for making dark mode available for everybody!

For context, the Web team has concluded work on dark mode. If, on some wikis, the option is not yet available for logged-out users, this is likely because many pages do not yet display well in dark mode. As communities make progress on this work, we enable this feature on additional wikis once per month.

If you notice any issues after enabling dark mode, please create a page: Reading/Web/Accessibility for reading/Reporting/xx.wikipedia.org in MediaWiki (like these pages), and report the issue in the created page.

Thank you!

On behalf of the Wikimedia Foundation Web team.

UOzurumba (WMF) 00:08, 7 May 2025 (UTC)[reply]

Thanks, that's great news! However, the dark mode is just black – that may be suitable on mobile but on desktop that's I think not good. Most dark modes are some dark grey for a reason. It's not good to the eyes, not convenient to use basically and many won't use it. Could you please add a dark-grey dark mode like the one that is available in the Wikipedia app (the third of the four in the color schemes settings)? Again, see how the dark mode looks like for most other large websites and desktop apps, most of these are tones of grey. If there already is an issue about this, please link it, thanks. Prototyperspective (talk) 11:06, 7 May 2025 (UTC)[reply]

Hi there!

If I understand correctly you are requesting additional modes be added similar to the native apps. While my team discussed expanding the available options on web during the construction of this feature to include additional themes such as sepia, at the current time we have no plans to add additional modes so that we can focus focus on the roll out of dark mode.

Dark mode requires various on-wiki changes across wikis (that no doubt you'll somewhat aware of as thankfully Commons have adhered to!) but other projects still need to make the recommended changes. When all projects are supporting dark mode, we can consider adding additional modes, which hopefully will not be as difficult thanks to the roll out of dark mode (since we can use CSS variables to theme now!).

As always I encourage experimentation with additional modes via gadgets (dark mode itself started off this way!) and am happy to support developers as needed. Let me know if I can help with that! Jon Robson, WMF 19:41, 13 May 2025 (UTC)[reply]

I took a ferry on the 27th may 2003 from Rostock to Tallinn. I cant find any ferry sheduled in 2025, from Rostock to Tallinn. See also: File:Ostseefährlinien.jpg. There does seem to be no ferry from Germany to Tallinn but lots of other Baltic destinations.

• 
• 
• 
• 
• 

What is the ship and compagny (white and blue stripes)? Is there any websites for historic Ferry shedules?Smiley.toerist (talk) 12:51, 7 May 2025 (UTC)[reply]

It looks similar to File:Finnjet_IMO_7359632_F_Travemünde_1987.jpg. Ruslik (talk) 20:19, 7 May 2025 (UTC)[reply]

According to this ship spotter site, this ferry was active on the route Rostock - Tallinn - Helsinki from 1999 to 2005 (when it was retired), the images also fit, so I'd say this is it (99% confidence). --rimshot^talk 21:03, 7 May 2025 (UTC)[reply]

The corresponding Wikilink would be GTS Finnjet. Regards, Grand-Duc (talk) 21:42, 7 May 2025 (UTC)[reply]

I assumed the departing port was Rostock as I had an hotel for two days (from there a made a daytrip to visit the narrow gauge railways on Rügen island), but File:Finnjet IMO 7359632 F Travemünde 1987.jpg, lets me think it may be Travemünde. On the other hand File:Rostock Tallinn ferry 2003 1.jpg looks as a temporary terminal to me.Smiley.toerist (talk) 10:46, 8 May 2025 (UTC)[reply]

The Finnjet was sailing from and to Rostock in the early 2000's (cf. GTS Finnjet#1987–2005, between Rostock and Helsinki). The gantry crane in the background of File:Rostock Tallinn ferry 2003 1.jpg looks a lot like the one on the background of File:Neptun Werft new hall III.jpg, the Y-legs are characteristic. You have a vantage point (back towards the sea, looking up the Unterwarnow) towards the the shipyard (Neptun Werft) from the ferry terminal at Rostock-Überseehafen. So, it's safe to say that you were indeed in Rostock. Regards, Grand-Duc (talk) 11:59, 8 May 2025 (UTC)[reply]

@Smiley.toerist: I agree that it's the Finnjet. Congratulations for having the chance to travel on such a special, historic and, sadly, now scrapped ship! I see that there are extensive articles e.g. in English Wikipedia or in German Wikipedia, but not in Dutch, maybe that's something you could rectify? ;-) Gestumblindi (talk) 09:02, 12 May 2025 (UTC)[reply]

I will ask around, but the Dutch wikipedia has some gaps in non-lokal subjects. As a maritime nation we have a lot of maritime subjects, but the Baltic sea is underserved. We have only the ferry compagny artikel nl:Scandlines operating in the Baltic sea. As ever it depends on writers have an interest in writing on certain subjects.Smiley.toerist (talk) 22:18, 18 May 2025 (UTC)[reply]

When I edit File:Newspaper_headings.djvu, it says at the bottom of the page:

Wikidata entities used in this page

• M163430529: Title

But Wikidata complains that the ID is invalid. What's going on? Marnanel (talk) 13:44, 9 May 2025 (UTC)[reply]

@Marnanel: I do not see any Wikidata usages on the file description page. MKFI (talk) 07:25, 10 May 2025 (UTC)[reply]

Pinging @Tpt as maintainer of https://ia-upload.wmcloud.org/   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 08:25, 10 May 2025 (UTC)[reply]

When I edit the page, not on the page itself when you're viewing it. Marnanel (talk) 14:13, 10 May 2025 (UTC)[reply]

This is the page ID of the file [4]. That the Commons page ID is listed as usage of a Wikidata item is definitely a bug. Every file page seems to have this. GPSLeo (talk) 14:53, 10 May 2025 (UTC)[reply]

It doesn't show up on all file pages, e.g. File:Pespot na Bellevue - panoramio.jpg (chosen at random) doesn't have it. I think it's being triggered by a template on that page. Omphalographer (talk) 00:09, 11 May 2025 (UTC)[reply]

That's probably just that page needing a linksupdate to record the usage. I agree though that this almost certainly comes from a template. I would assume {{Information}} or something has some fallback code to pull the description from SDC if its not directly specified, or something like that. Bawolff (talk) 09:45, 11 May 2025 (UTC)[reply]

Just for completeness, the link should be Special:EntityPage/M163430529 so likely a module that tries to get local structured data, but incorrectly looks at Wikidata. I looked at the recent uploads of my bots. File:Giovanni Battista Tiepolo (5.3.1696 - 27.3.1770) - Das Martyrium der Heiligen Agathe - 459B - Gemäldegalerie.jpg has the issue, but File:Bales and manure near Green Lane - geograph.org.uk - 7669865.jpg doesn't. Both use a lot of structured data, difference is the template used ({{Artwork}} vs {{Information}}). I think the bug is likely to be in Module:Artwork or one of the underlying modules. @Jarekt: any idea? Multichill (talk) 19:06, 12 May 2025 (UTC)[reply]

@Multichill, Marnanel, and Bawolff: , I am searching for any files with "Wikidata entities used in this page" linking to M-id and I can not find any examples. For example I looked at the files mentioned in this discussion, new uploads by BotMultichillT and all new uploads. Are there some examples or did the issue fixed itself somehow? Most infoboxes, like Information, Artwork, Book, Photograph, etc. access SDC as Bawolff described, but that code has not changed in years and I never run into the issue described. --Jarekt (talk) 02:56, 13 May 2025 (UTC)[reply]

I see it at https://commons.wikimedia.org/w/index.php?title=File:Giovanni_Battista_Tiepolo_(5.3.1696_-_27.3.1770)_-_Das_Martyrium_der_Heiligen_Agathe_-_459B_-_Gem%C3%A4ldegalerie.jpg&action=info . Tbh though i dont see how this is an issue. Bawolff (talk) 06:39, 13 May 2025 (UTC)[reply]

It still shows for me (e.g. on [5], which Omphalographer mentioned earlier). Marnanel (talk) 07:37, 13 May 2025 (UTC)[reply]

Tracked in Phabricator
Task T393997

I tested it using Module:Sandbox: Ever page that uses this module to get the caption gets these incorrect Wikidata links on the page information page. This is not a problem in the modules. The problem is withing MediaWiki. I created a bug report for this. GPSLeo (talk) 08:02, 13 May 2025 (UTC)[reply]

Flickr have again (as they did back in March) closed searches behind a paywall. Last time (see Commons:Village pump/Archive/2025/03#Flickr - possible change of licensing?), @Omphalographer: discovered that you could bypass the paywall then by using the 'Esc' key. Unfortunately this no longer works with the new paywall. Does anyone know if there is a new way round it? Thanks! - MPF (talk) 11:28, 11 May 2025 (UTC)[reply]

Maybe we could use this to make a campaign to get users currently publishing their files on Flickr moving to Commons. Something like "Disappointed from Flickr? Learn how to publish your photos on Wikimedia Commons". GPSLeo (talk) 12:04, 11 May 2025 (UTC)[reply]

I think it should be "Disappointed by flickr" in English, but otherwise... yes, that could be a chance. Though our rustic to rusty interface will probably deter some users accustomed to flickr... - And also, of course, we have stricter policies, as you can't upload just any file to Commons (COM:EDUSE)... Gestumblindi (talk) 08:54, 12 May 2025 (UTC)[reply]

Maybe it's just a test. I don't see any paywall when I try to search on Flickr. Nosferattus (talk) 14:13, 12 May 2025 (UTC)[reply]

@Nosferattus @Gestumblindi @GPSLeo - I still get a paywall when I visit Flickr's search page. It means it is no longer possible to search for Commons-compatible cc-licensed images on Flickr. - MPF (talk) 19:50, 15 May 2025 (UTC)[reply]

@MPF: Interesting, just tested: I don't get a paywall, don't even need to be registered, I can use the search feature (including filtering by license) just fine. The only thing it seems to require to be signed in for is if you want to disable the "family filter". Maybe it's country-specific? I'm using it from Switzerland. Gestumblindi (talk) 19:57, 15 May 2025 (UTC)[reply]

@Gestumblindi - thanks! I'm in Britain; I get a non-removable flashscreen paywall that requires I must sign up for Flickr before I can search for anything there; I can't use the search feature (including filtering by license) at all, it's blocked by the paywall. - MPF (talk) 20:09, 15 May 2025 (UTC)[reply]

Did you try to scroll further down beyond the first results? I can make a search and get results but I can only click on the first ones. If you scroll further down I run into the paywall and also do not get back to the first results. GPSLeo (talk) 20:13, 15 May 2025 (UTC)[reply]

@MPF and GPSLeo: That's it! Yes, if I try to scroll further down, I get the paywall as well, unfortunately. Gestumblindi (talk) 20:45, 15 May 2025 (UTC)[reply]

Just tried it – no paywall for me (accessing from Germany, logged in), even when scrolling to the very end of the search results. With another browser (not logged in) I got a pop-up (saying I should register to continue) after scrolling down. --Rosenzweig τ 21:08, 15 May 2025 (UTC)[reply]

@Rosenzweig @GPSLeo - now we need a workaround (like the earlier use of the Esc key) that'll get access to the search without having to sell my soul to them - MPF (talk) 21:32, 15 May 2025 (UTC)[reply]

@MPF-- https://temp-mail.org/ is your friend. JayCubby (talk) 21:55, 19 May 2025 (UTC)[reply]

https://greasyfork.org/en/scripts/531568-flickr-no-sign-in-nag/code this script works fine  ${\displaystyle 999}$REAL 💬 ⬆   22:07, 19 May 2025 (UTC)[reply]

I would like to translate the documentation page Template:Information/doc into German but I'm not sure how to prepare that page for translation. It seems it's not available in any other language than English as yet? The "language select" at the top of the page has only translated one sentence into Japanese and seems to be the wrong method for this page anyway ("should be used only when there are very few translations, and for translating a few sentences.[...] only intended for pages (like generated activity reports, or user pages) that will be rarely translated"). The only part that is translated into German and other languages is the box {{Documentation subpage}} at the top. I'd like to translate the full documentation into German (note, not {{Information}} itself which is translated at Translatewiki, I gather - where I don't have an account; apparently it's not part of Wikimedia's global account system). Gestumblindi (talk) 08:51, 12 May 2025 (UTC)[reply]

Any help? ;-) Maybe {{Autotranslate}} should be used? But how, exactly? I'm not quite sure how this would be connected to the template itself which is translated at Translatewiki (apparently, I have a hard time even finding the template there)... Gestumblindi (talk) 08:19, 13 May 2025 (UTC)[reply]

I suggest to ask for help at Commons:Translators' noticeboard. Raymond (talk) 07:37, 14 May 2025 (UTC)[reply]

Thank you, I copied my question over there. Gestumblindi (talk) 18:56, 14 May 2025 (UTC)[reply]

In compliance with the provisions of the US Digital Millennium Copyright Act (DMCA), and at the instruction of the Wikimedia Foundation's legal counsel, one or more files have been deleted from Commons. Please note that this is an official action of the Wikimedia Foundation office which should not be undone.

In this specific case, the DMCA was granted because the owner of the picture sent the Wikimedia Foundation’s legal department messages under penalty of perjury claiming that they had never licensed it to the original Flickr upload from where the image was originally taken from. The usage of this image may still be fair use in specific contexts, and the legal department encourages editors to do local uploads to that end with an appropriate non-free content justification under local policy, but it is currently too broadly used for that to be the justification the legal department provided in this case. If you have valid grounds for a counter-claim under the DMCA, please contact me.

The takedown can be read here.

Affected file(s):

• File:The Queen presents the 1966 World Cup to England Captain, Bobby Moore. (7936243534).jpg (edit|talk|history|links|watch|logs)

To discuss this DMCA takedown, please go to COM:DMCA#The Queen presents the 1966 World Cup to England Captain, Bobby Moore. (7936243534). Thank you! Joe Sutherland (WMF) (talk) 19:55, 12 May 2025 (UTC)[reply]

In compliance with the provisions of the US Digital Millennium Copyright Act (DMCA), and at the instruction of the Wikimedia Foundation's legal counsel, one or more files have been deleted from Commons. Please note that this is an official action of the Wikimedia Foundation office which should not be undone. If you have valid grounds for a counter-claim under the DMCA, please contact me.

The takedown can be read here.

Affected file(s):

• File:Blessed Virgin Mary.jpg (edit|talk|history|links|watch|logs)

To discuss this DMCA takedown, please go to COM:DMCA#Blessed Virgin Mary. Thank you! Joe Sutherland (WMF) (talk) 20:14, 12 May 2025 (UTC)[reply]

Cat:Envelopes (currently 24 files) -- Where are the pronunciation files supposed to be? Is there a categorization of pronunciation files by topic or a policy about such? Taylor 49 (talk) 08:26, 13 May 2025 (UTC)[reply]

Is there a categorization of pronunciation files by topic See e.g. Category:Pronunciation by subject. Prototyperspective (talk) 11:14, 13 May 2025 (UTC)[reply]

Classifying words into arbitrary "subjects" seems like a poor way of categorizing pronunciation files, particularly given that words are often polysemic (having multiple meanings). The way I would expect these files to be categorized is primarily by language, to optimize for the use case of "I need to find a recording of someone reading this specific word"; more granular categorization is only going to get in the way of this use case. Omphalographer (talk) 18:38, 13 May 2025 (UTC)[reply]

Both are potentially important (and I agree with Omphalographer that "by language" is close to mandatory). Yes, there is also Category:Audio files of pronunciations by language and its many subcats.

Since the category originally alluded to in the question has now been emptied, I have no idea what files this was about, so I have nothing further to add. - Jmabel ! talk 03:16, 14 May 2025 (UTC)[reply]

Category:Pronunciation by subject (very little content two days ago) turned out to be a dupe of Category:Pronunciation of words (more content two days ago, but less optimal name). Agree that lemmas should be categorized primarily by language, the cat Category:Audio files of pronunciations by language already exists and is heavily used. Taylor 49 (talk) 09:35, 14 May 2025 (UTC)[reply]

Category:Catherine Wolfe Bruce[6] has the wrong infobox picture (it should be no picture at all, not some random Australian). I nuked it everywhere I could but its the thing that wouldn't die. Where did they hide that value? Fountains of Bryn Mawr (talk) 22:01, 13 May 2025 (UTC)[reply]

@Fountains of Bryn Mawr. I don’t see the image anymore, so I think it got sorted out. Sometimes you have to purge the page or make a null edit (submit edit without editing anything) to update the page. Tvpuppy (talk) 22:34, 13 May 2025 (UTC)[reply]

Thanks, saw it disappear as well. Fountains of Bryn Mawr (talk) 22:38, 13 May 2025 (UTC)[reply]

Hello community, this is to notify that there is a request for comment on Meta that some users might be affected. You can join the discussion here.

Please do not reply to this message. 〈興華街〉📅❓ 02:00, 14 May 2025 (UTC)[reply]

Hello,

I busied myself again with looking at the latest file uploads. A few of them were in WebP format, but all of these images were also copyright violations. Blatantly so, being simple grabs from internet sites (example: File:Hanzade dabbag.webp from https://www.worldaquatics.com/athletes/1845366/hanzade-dabbag ). I do not actually recall cases where WebP files were genuinely licensed and "good" for us. What are the experiences of other editors, did they already developed a reflex "WebP = probable copyvio", as I did? If the ratio between good uploads and copyvios using WebP is too bad, I wonder if a filter could be set up to track WebP uploads made by users with a low edit count or recent accounts... I do not suggest to forbid WebP (that's certainly going too far and would only entice moving to another format where copyvios cannot be spotted as easily), but a tracking tool could be welcome. Regards, Grand-Duc (talk) 13:13, 14 May 2025 (UTC)[reply]

I agree that most WebP uploads are copyright violations. I would suggest to introduce the same restriction as we currently have for MP3: Commons currently only accepts MP3 uploads by users with Autopatrol or higher rights, due to concerns about the capacity of the community to monitor for copyright violations. Gestumblindi (talk) 18:45, 14 May 2025 (UTC)[reply]

We've discussed this previously at Commons:Village_pump/Proposals/Archive/2023/11#Restrict webp upload？. There was general support for the proposal, but it wasn't acted upon. Omphalographer (talk) 20:52, 14 May 2025 (UTC)[reply]

Indeed, and I supported the proposal, thanks for the pointer! Well, why wasn't it acted upon? There were some opponents, but I'd say that the support was broad enough. Gestumblindi (talk) 21:02, 14 May 2025 (UTC)[reply]

On the proposal, there was a search link - I clicked on it out of curiosity (to check if I can see a legitimate file...), and the very first image at the top, File:WEBP LANDSCAPE 1620.webp was again a copyvio (evident by Google Image search).

The ideal in my eyes would be: track or maybe even forbid cross-wiki WebP uploads (if that's available as filtering criterion) and track direct WebP uploads. Regards, Grand-Duc (talk) 21:23, 14 May 2025 (UTC)[reply]

Does cross-wiki uploads bring anything good? Sometimes it feels like it doesnt Trade (talk) 21:57, 14 May 2025 (UTC)[reply]

Here is one author/site that releases photos under CC BY 4.0 only in WEBP Category:Photographs by Zahra Ostadzadeh for avash.ir  ${\displaystyle 999}$REAL 💬 ⬆   21:24, 14 May 2025 (UTC)[reply]

 Strong support to disallow upload of WeBP for users not having at least "Autopatrol". Since there is already a consensus, the restriction can be applied immediately, can't it? I apparently do have the privilege to upload toxic fileformats like MP5 and soon also WeBP, but I have never used it so far, and very likely never will. :-D Taylor 49 (talk) 22:21, 14 May 2025 (UTC)[reply]

The main counter-argument in the previous discussion was that a restriction of WebP uploads to Autopatrol users (dramatically and wrongly called "outlawing" the file format in one comment) would lead to users converting WebP copyvios to other formats, making them harder to detect. I think that this risk is rather small; most people uploading WebP copyvios don't seem that well versed and wouldn't bother to convert the files (or often don't even know how to do it). We haven't seen a mass influx of MP3 copyright violations converted to Ogg or WebM audio either... - Otherwise, I would say that there was a broad consensus for this approach; of course, support for such a proposal will never be unanimous. Gestumblindi (talk) 08:41, 15 May 2025 (UTC)[reply]

1. there's another "speed bump" in case they convert them to jpg: abusefilters that prevent new users uploading low resolution/small jpg. such hurdles are sufficient to deter i'd say 95% or more of such bad uploads.
2. there's consensus for that proposal, but it's still not implemented by any sysop, and i'm not sysop either. i still have my proposal on my watchlist.

RoyZuo (talk) 10:12, 15 May 2025 (UTC)[reply]

A person who signed "Natalya Arinbasarova" wrote to the Error Reporting section of the Russian Wikipedia asking to remove a photograph (File:Natalya Arinbasarova 1966.jpg) described as the image of her, but which in fact depicts another woman. For sure, such a request does not allow us to establish the identity of the person who wrote, but we can discuss at least the facts available to us. Yes, the description of the photo in the source is completely unambiguous, this is not an error on the part of the Commons users. But I will share my doubts: a. It seems unlikely to me that the woman in the picture is 19 years old. b. There are a number of undisputed images from that very w:27th Venice International Film Festival in which Natalya looks different: [7] [8] [9] [10] [11]. What should be done to minimize the possible adverse consequences? --Romano1981 (talk) 18:31, 14 May 2025 (UTC)[reply]

I agree that the woman in the other pictures you provide looks different. But if the licensing status of the photograph is fine, it shouldn't be deleted but renamed, with changed description - like "Unidentified woman walking arm in arm with an unidentified man" (maybe they can be identified someday). This affects also the crop File:Natalya Arinbasarova 1966 (cropped).jpg and both files should be removed from the numerous Wikipedia language versions where they're currently in use as a depiction of Natalya Arinbasarova. Gestumblindi (talk) 18:52, 14 May 2025 (UTC)[reply]

I nominated them for renaming as you suggested. Romano1981 (talk) 07:27, 15 May 2025 (UTC)[reply]

On https://apnews.com/article/thailand-illegal-import-electronic-waste-bangkok-port-994ef5e8c3776e9b77580d9954eebaeb click the right arrow for the image at the top of the page, til you get to image 3 of 4.

I made a similar image, which is posted https://ibb.co/xSPH92cC containing only simple geometric shapes.

Is this allowed to be uploaded here as my own work with a free licence?

Thanks Gryllida (talk) 20:43, 14 May 2025 (UTC)[reply]

No. The image you created is a derivative work of the AP photo. Omphalographer (talk) 20:58, 14 May 2025 (UTC)[reply]

Please see below. Gryllida (talk) 14:06, 15 May 2025 (UTC)[reply]

@Omphalographer and Gryllida: I'm actually not sure of that, because it is so abstracted. Certainly with a few relatively small changes it would be OK. Remember, the appearance of the circuit board at the center can't be copyrighted, so it's OK to abstract from that, so it at worst it should just be a matter of getting a bit farther from the composition of that particular photo. - Jmabel ! talk 04:06, 15 May 2025 (UTC)[reply]

Regardless, I don't see it being in scope. Pi.1415926535 (talk) 04:28, 15 May 2025 (UTC)[reply]

It is in scope for another wiki. I just need the licensing cleared as it is a sister wiki using a creative commons licence. The intent is to show a board among pieces of metal junk. I am hoping for some slightly more definite answer as, if acceptable, I could use the same approach to generate basic illustrations with simple geonetric shapes and barebones colors for other pages there. Gryllida (talk) 14:05, 15 May 2025 (UTC)[reply]

@Gryllida: What sister wiki?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:27, 15 May 2025 (UTC)[reply]

news Gryllida (talk) 14:38, 15 May 2025 (UTC)[reply]

How about just compositing any of a bunch of PD or free-licensed pictures of a circuit board onto something like File:Propane tanks.jpg or File:Transfer Station Recyclables, Gainesville, FL 7054.JPG? - Jmabel ! talk 18:24, 15 May 2025 (UTC)[reply]

Or a photo of actual electronic recycling, e.g. File:Electronic junk separation in view of recycling 3.jpg (a little blurry, unfortunately) or File:Computer that's had its chips - geograph.org.uk - 735712.jpg? Mimicking the composition of the AP photo seems altogether the wrong way of going about it; the meaning of that photo is in its content, not the abstract shapes. Omphalographer (talk) 18:40, 15 May 2025 (UTC)[reply]

I noticed we didn't had a category for this purpose so i created one. If anyone see an image where the source is deprecated feel free to help populate it--Trade (talk) 21:52, 14 May 2025 (UTC)[reply]

Images seem to be mostly AS (Artificial stupidity), dubious whether in scope. Taylor 49 (talk) 22:12, 14 May 2025 (UTC)[reply]

w:Italian brainrot  ${\displaystyle 999}$REAL 💬 ⬆   22:13, 14 May 2025 (UTC)[reply]

I wonder why you announce a new cat when there aren't yet good-quality contents in it. This just makes the cat seem dubious and useless and maybe even lead to it being deleted despite it potentially or in principle being useful. I think there are many useful files on Commons from dead websites, for example in scientific journals which have shut down and things like that. Also a 404 source doesn't mean it's deprecated. Prototyperspective (talk) 22:54, 14 May 2025 (UTC)[reply]

Someone on Wikidata decided to link Category:HTTP 404 to link rot (Q1193907). Hence why Trade (talk) 23:50, 14 May 2025 (UTC)[reply]

Is it just me, or is the Metadata text at the bottom of the page larger than it used to be? It used to be small I think, now it's normal size. - The Bushranger (talk) 02:01, 15 May 2025 (UTC)[reply]

...although looking at this, maybe it always has been "normal" size, and I'm just losing my mind. - The Bushranger (talk) 06:03, 15 May 2025 (UTC)[reply]

Someone's definitely been playing with font sizes. Warning messages at the top of pages got a lot bigger recently, e.g. the no-such-user and page deletion messages on User:Nobody. Omphalographer (talk) 06:59, 15 May 2025 (UTC)[reply]

The "User account "Nobody" is not registered on this wiki. Please check if you want to create/edit this page." looks the same as always to me, but the stuff in the pink box atop this page now looks bigger! - The Bushranger (talk) 19:07, 15 May 2025 (UTC)[reply]

Weird - maybe it's browser and/or skin dependent? I'm using Vector Legacy on Firefox, and the "account is not registered" message is rendered at 16px, substantially larger than the 14px text following it. Omphalographer (talk) 20:06, 15 May 2025 (UTC)[reply]

Here's a screenshot of what I'm seeing on Monobook in Firefox. Also found a screenshot of the original thing with metadata - and yes, it is larger now (screenshot at top!) - The Bushranger (talk) 21:05, 15 May 2025 (UTC)[reply]

It looks like there may actually have been a change. Since I noticed it on Wednesday... - The Bushranger (talk) 22:50, 15 May 2025 (UTC)[reply]

File:Navajo woman.jpg - Flicker source no longer availablr. Doug Weller (talk) 10:36, 15 May 2025 (UTC)[reply]

@Doug Weller: Alleged source is https://www.flickr.com/photos/95329455@N02/10490432575. All media from https://www.flickr.com/photos/95329455@N02 (simpleinsomnia) appear to be gone ("simpleinsomnia hasn’t made any photos public yet.") The file itself appeared initially to be broken, but it now looks ok. Snowsector211: How long ago did you retrieve it? Was that directly from Flickr? P.S. Circuit breaker is in effect; please save your work early and often.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:47, 15 May 2025 (UTC)[reply]

I usually add (404) next to the source link if it's a dead or a 404 link. This could be used somehow by some bot and/or users that check(s) for a new live site location or an archived version in the Wayback Machine etc to add it there. Examples: 1, 2 3 4 5. Prototyperspective (talk) 12:04, 15 May 2025 (UTC)[reply]

The upload log indicates that the uploader found it through Openverse. -- Asclepias (talk) 12:12, 15 May 2025 (UTC)[reply]

@Asclepias: Do we trust the licensing presented there? Surely, simpleinsomnia didn't snap this photo in 1907 (118 years ago), and the licensing on the file here (CC0) doesn't match the licensing on Openverse.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:16, 15 May 2025 (UTC)[reply]

The CC0 on Commons was wrong anyway because the author is stated as unknown. Also, it is suspect when an uploader states a precise date while unable to identify the subject nor the author. The CC BY 2.0 on flickr does not seem reliable either. There is no information on the origin of the photo. The flickr user may have just placed any tag, as it happens. -- Asclepias (talk) 12:42, 15 May 2025 (UTC)[reply]

@Asclepias: So, is there enough doubt to recommend deletion based on PRP?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:01, 15 May 2025 (UTC)[reply]

It could be in the public domain, depending if and when it was published, or the license by the flickr user could be good if they are the heir of the photographer. But there is no information. (Does Commons apply AGF to flickr users?) You decide. -- Asclepias (talk) 14:45, 15 May 2025 (UTC)[reply]

Well, it's not "user decided not to pay Flickr one thin dime".   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:00, 15 May 2025 (UTC)[reply]

Date does seem about right (if overprecise) based on the image itself. Certainly well before 1930. The question would be whether it was published in a timely fashion. Of course, if it never had authorized publication before 2003, we are getting pretty close to the 120-year mark. - Jmabel ! talk 18:29, 15 May 2025 (UTC)[reply]

Generally speaking, in some cases it's still possible to verify the original source via the Internet Archive's Wayback Machine. Gestumblindi (talk) 21:01, 15 May 2025 (UTC)[reply]

• Is there fear the image may be fraudulent? I can find no trace of it other than copies made after Flickr such as openverse. --RAN (talk) 19:46, 17 May 2025 (UTC)[reply]
  • If fraudulent it is particularly plausible fraud. Any particular reason to suspect it? - Jmabel ! talk 21:19, 17 May 2025 (UTC)[reply]

Browsing Cape Verde category I can see plenty of images not connected in any way with this West African country. The search engine shows automobiles, vessels, aircraft etc. which happen to have the letters "CV" in their descriptions. Is there a way to remove these from the search results? It is annoying. — Preceding unsigned comment added by Kotoviski (talk • contribs) 12:38, 15 May 2025 (UTC)[reply]

@Kotoviski: Hi, and welcome. You need to check with each file's categorist as to why they categorized that way.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:52, 15 May 2025 (UTC)[reply]

This may be due to flawed categorization. To check, you'd need to provide some examples. Prototyperspective (talk) 13:05, 15 May 2025 (UTC)[reply]

@Prototyperspective: There are currently 56 files in Category:Cape Verde, just look there and you should find some examples.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:11, 15 May 2025 (UTC)[reply]

Couldn't find any examples there and therefor didn't think that's what the user referred to instead of files in some of its subcats or has it been solved by now? Prototyperspective (talk) 13:14, 15 May 2025 (UTC)[reply]

I found one that was not exactly wrong but misleading (a Cape Verdean flag in Boston) and recategorized it accordingly. There is nothing else wrong in the category. @Kotoviski: I take it this was a search result, not a Commons category. What search engine, and what exactly were your search terms? - Jmabel ! talk 18:39, 15 May 2025 (UTC)[reply]

Right. I was searching for media with "Cape Verde" in description, not in Category. Many images shown have letters "CV" (which is ISO 3166 code and Internet Top Domain for the country). A few examples: https://commons.wikimedia.org/wiki/File:Citro%C3%ABn_2_CV_Charleston_(2015-08-29_3174_b).jpg https://commons.wikimedia.org/wiki/File:Simple_CV_Joint_animated.gif https://commons.wikimedia.org/wiki/File:E-2C_VAW-115_CV-63_2007.JPEG

and so on... Photograph by Henryk Kotowski (talk) 19:43, 15 May 2025 (UTC)[reply]

Good to have this clarified, thanks. However, can't see these files in the search results when searching for "Cape Verde" (like so). Don't know if you just scrolled far down or searched differently like with another term or some filter & sorting.

• If this is due to categorization (e.g. via Category:CV letter combinations) then a tool is needed to see how a file is part of a category (category path) – see here
• If this is an issue of the search results broadly, then the search engine / MediaSearch would greatly benefit from improvements in general and e.g. could recognize when the user searches for something that is or redirects to or very similar to a category title (see e.g. #10 here).

When searching for "our world in data" (Category:Our World in Data) there's sth similar happening: it shows e.g. this and this despite that these don't even have the word "world" or "our" in the description or SD. Don't know why that is. For practical purposes, changing the search term to "our world in data" (quotes) solves it. The same may also help here. Prototyperspective (talk) 22:14, 15 May 2025 (UTC)[reply]

They have been a lot of discussions about this guy’s work and its scope (or lack thereof) on Commons, but Commons:Deletion requests/File:ChatGPT by Exey Panteleev.jpg was closed against a broad majority (5:1 counting actual !votes) with the rationale “The series of photos has been discussed and kept repeatedly. Substantial precedent.” This seems to say that: a) individual image scope does not matter in a series, and b) precedent from other files’ discussions overrides consensus at an individual discussion. This is not simply an admin rejecting shitty arguments or no-argument votes; it’s an admin overriding valid arguments because of arguments made for other files. That, to me, seems like a novel and radical interpretation of policy that would not fly anywhere else but this one specific case because it’s become unthinkable that any respected user would ever vote against precedent here, let alone a majority. In fact, it actually seems to contradict policy in several key areas: 1) “Artwork without obvious educational value” is not in scope; 90% of these images have no obvious educational value whatsoever and are simply considered to have sufficient artistic value to be kept. 2) “Files that add nothing educationally distinct to the collection of images we already hold covering the same subject” is not in scope; some of these images are being used to illustrate the project or very occasionally other topics; 90% are not, making them essentially redundant. 3) Many users have defended the project as a whole as notable; however notability and scope are two completely different things— notability is irrelevant to Commons, and this is one of those very rare cases where something notable can be out of scope for the above reasons. So is Exey Panteleev’s photography so special that it gets a de facto policy carveout (and if so should that be made official by the community)? Is User:Infrogmation just in the wrong here and should have closed it as delete (my opinion)? Or is there just something I’m missing here? Dronebogus (talk) 19:56, 15 May 2025 (UTC)[reply]

I would say Infrogmation was in the wrong to close that discussion as keep. The consensus was clearly for deletion. In fact no one in the discussion even suggested keeping it. Even if you only consider policy arguments and ignore voting, SCOPE is a policy, precendent is not. According to Commons:Deletion_requests, the proper recourse is to ask Infrogmation to reconsider their closing, and if that doesn't work, renominating it for deletion. Nosferattus (talk) 22:26, 15 May 2025 (UTC)[reply]

I admire your bravery for wading into the slow-burning garbage fire of discussions about these files. ;) Previous discussions regarding these files have generally been closed as "keep" on one or more of the following grounds:

1. That the nomination was made on an invalid basis, such as that the file was pornographic, demeaning to women, etc.
2. That the file nominated was part of a larger set of images by Panteleev, and that those photographs have artistic value.
3. That previous related deletion discussions were closed as "keep".

If you intend to reopen this discussion, or a larger discussion about the set of files, you should be prepared to address these objections, even if they aren't directly applicable to your nomination. These discussions have come up frequently enough that there are a lot of knee-jerk responses. Omphalographer (talk) 23:21, 15 May 2025 (UTC)[reply]

 Comment In my personal opinion, I often find the work of Exey Panteleev annoying. IMO his "Geekography" concept might have been somewhat clever had it been limited to a few or a dozen images, but as a series of hundreds became beyond tiresome. That said, personal opinions if an artist is annoying or tiresome or something one doesn't care for for whatever reason is not relevant to if it is within project scope. As there have been not merely a couple but rather a considerable number of previous discussions of Panteleev's works which resulted in "kept" decisions, I was merely applying what I understood as precedent. See for example the discussion and links at Category talk:Project "Geekography" by Exey Panteleev (portrayals of computer technology), Category talk:Project "Geekography" by Exey Panteleev (nude portrayals of computer technology). So my decision included those factors in addition to the much narrower discussion at Commons:Deletion requests/File:ChatGPT by Exey Panteleev.jpg. So you've asked me to reconsider the closing; I have done so and decline to reopen as it was based on my understanding of precedent. I have no objection to renominating the file, but suggest that you make clear in the listing that you are not only calling for a particular file to be deleted but also that considerable precedent should be overturned. I have no objection to arguing that precedent should be overturned, merely that any such argument should be made with awareness that it is an issue far broader than a single file or single deletion listing and involves much previous discussion over a period of years. Best wishes to all. -- Infrogmation of New Orleans (talk) 23:22, 15 May 2025 (UTC)[reply]

The thing is, there was near-unanimous consensus to delete, and you closed as keep. I'm not as read-up on Wikimedia Commons policies as I am on en.wiki's (being an administrator there, and just an contributor here), but over there that's what we call a supervote, and that's bad. Precedent might well exist, but consensus can change - and it apparently has. As Nosferattus points out above, scope is policy, precedent is not, and overturning a near-unanimous consensus based on policy in favor of precedent is an extremely bad look. - The Bushranger (talk) 23:54, 15 May 2025 (UTC)[reply]

@The Bushranger: The original nominator was trying to censor Commons, and now effectively so are you and Dronebogus. COM:CENSOR is policy.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 00:02, 16 May 2025 (UTC)[reply]

@Jeff G.: I am simply pointing out that an administrator has taken an action against the consensus of the community as an apparent supervote. I haven't even looked at the image and have no idea what it is. I'm not "trying to censor Commons" and would greatly appreciate it if you would strike that aspersion. - The Bushranger (talk) 00:08, 16 May 2025 (UTC)[reply]

COM:CENSOR simply says, in short, that we do not delete files because they contain nudity, or are offensive, or what-have-you. It does not say that we never delete files which have these characteristics. Files which are deemed out of scope can still be deleted. Omphalographer (talk) 00:40, 16 May 2025 (UTC)[reply]

Omphalographer, the problem here is that the scope definition is being deliberately distorted solely to eliminate images that do not please the delicate sensibilities of a handful of idle puritans – who ironically are probably the ones searching for porn the most on Commons. When Peter talks about Paul, I learn more about Peter than about Paul... The other day I came across an editor who apparently was on the hunt for the perfect vulva with more determination than a 16th-century Spanish colonist hacking through forests, rivers, and cannibalistic natives in search of the mythical El Dorado.

There are hundreds of practically identical images of Michelangelo's Pietà, yet I do not see anyone nominating them for deletion (thank God). There are also many nearly identical images of random streets that are only here because (fortunately) some editor thought it worthwhile to document a place they feel attached to. As the saying goes, the more, the better – and if we set moralism aside that principle should apply equally to images that feature a boob, a shaved vagina (as long as it does not reference the infamous Führer mustache), or any other pudenda.

Exey Panteleev's photographs are professional – that alone should be a reason to keep them. Even more so because they do not just depict nudity for nudity's sake, but touch on other aspects of contemporary life. For instance, who would have thought that one of his Flickr images could illustrate the article about the implosion of the Titan submersible? And yet, it can (though it might require a bit of blurring, for obvious reasons). RodRabelo7 (talk) 01:02, 16 May 2025 (UTC)[reply]

But like, why? We have a much better non-pornographic image of the controller and Wikipedia bas the principle of w:wp:Gratuitous that I think should just be common sense judgment across all Wikimedia wikis, with the specific example of “images of automobiles with naked women posing near them” as something inappropriate. Literally all of Panteleev's photographs, if used to illustrate their supposed subject, would blatantly fall into this category of “needlessly using explicit content to illustrate a SFW subject”. Dronebogus (talk) 10:41, 16 May 2025 (UTC)[reply]

Why not? I repeat: unless you are going to be bold and nominate for deletion dozens of nearly identical images of the Pietà, there is absolutely no reason to take issue with a handful of breasts, vaginas, and anuses that Panteleev captured as nothing more than a cluster of colored pixels.

And of course Wikipedia policies are irrelevant here. As if the world revolved around what English speakers think. This is a multicultural project where there should be no room for Western puritanism. RodRabelo7 (talk) 12:19, 16 May 2025 (UTC)[reply]

Basically any non-western contemporary culture (besides a handful of modern hunter-gatherers who may not know what the internet even is) is more conservative— not that it matters. Even the most liberal western culture isn’t going to use a picture with a background of boobs to illustrate a controller— not because your average, let’s just say Dutch person is a prude or a puritan, but because it’s distracting and confusing if nothing else. Dronebogus (talk) 15:44, 16 May 2025 (UTC)[reply]

I have uploaded up actual pornography to Commons, and will continue to uploads works that show the flowering of the liberation of sexuality in the 1950s and 1960s. In a world where nobody cared about nudity, I would move to delete these. They're simply not in scope, anymore than painting the logo on a lamp or spoon is. In this world, they're not in scope, and they're actively hostile to any educational purpose. Exey Panteleev doesn't have a Wikipedia page, and the top three hits for his name in Google are Commons, Flikr and Commons again. There's no reason to keep his works just because they are his works.--Prosfilaes (talk) 04:07, 17 May 2025 (UTC)[reply]

Omphalographer: COM:CENSOR is policy because a consensus was reached in putting it there as a part of the COM:SCOPE policy. That Infrogmation chose not to include that as one of the reasons to keep may have been an oversight, but not an egregious error. The attempt at censorship was a policy violation, whether or not it was cited as such.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:24, 16 May 2025 (UTC)[reply]