This page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Archive/2025/05.
Please note:
If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias.
Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer).
Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam.
Purposes which do not meet the scope of this page:
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.
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 -
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.
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]
scan of bad quality newspaper print will not improve with higher resolution
@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]
April 26
Naming conventions for flags (for example Flag of Honduras)
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 ! talk23: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 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.
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 ! talk17: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]
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]
Are we nearly there yet? 5000 media of 2018 needing categories, please
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]
Poland bans photography of military and critical sites, including bridges, tunnels, viaducts, port facilities and the National Bank
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]
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]
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]
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]
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]
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]
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.Savin19: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]
May 07
Enabling Dark mode for logged-out users
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.
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, WMF19:41, 13 May 2025 (UTC)[reply]
Historic Baltic ferry shedules
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.
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). --rimshottalk21:03, 7 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]
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]
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]
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]
@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 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]
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]
@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]
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]
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]
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.
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]
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 ! talk03:16, 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]
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]
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]
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]
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.
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.
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]
@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 ! talk04:06, 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]
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]
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]
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]
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]
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, 2345. Prototyperspective (talk) 12:04, 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]
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]
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 ! talk18:29, 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]
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]
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 ! talk18:39, 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:
That the nomination was made on an invalid basis, such as that the file was pornographic, demeaning to women, etc.
That the file nominated was part of a larger set of images by Panteleev, and that those photographs have artistic value.
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]
@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]
I'm just going to note that the apparent mindset of some users, which seems to be "any deletion request for Panteleev photographs is an attempt at censorship", is just as concerning as the apparent supervote was. Again: I don't think the image should be deleted. I don't think it shouldn't be deleted. Regardless of the image's merits or lack thereof I don't think a deletion request that established a consensus for deletion should be closed as keep, especially in a way that makes no comment whatsoever of the discussion and, instead, reads as "this is being kept and it was always going to be kept no matter what the community discussion established". With all due respect to Infrogmation (and I do appreciate the photographs they've contributed, too!) that makes me wonder why we even have deletion requests, when they can be (and, apparently, are) closed in such a manner. - The Bushranger (talk) 17:53, 16 May 2025 (UTC)[reply]
Interesting double standards where actually useful AI images are being deleted after being in use for quite a while, showing how they can be realistically useful while uneducational porn is kept. No, this is not censorship any more than DRs in general are censorship. What you say is one thing: absurd. Prototyperspective (talk) 09:48, 16 May 2025 (UTC)[reply]
Again, I do not oppose relisting. However it is simply not true that "there was unanimous consensus to delete". Please look at the listing again. You will see that Ikan Kekek voted "keep". Rhododendrites did not vote, but noted precedents which at least leaned keepish. Please try to be accurate in summaries, thank you. Cheers, -- Infrogmation of New Orleans (talk) 00:06, 16 May 2025 (UTC)[reply]
Question Do we have to make a rule against nominating Exey Panteleev photography for deletion or we just gonna have to accept the fact that this DR have become an quarterly Wikimedia Commons tradition? I suspect at least some of the DRs might have been made by users who logged out of their accounts beforehand to avoid pushback--Trade (talk) 16:28, 16 May 2025 (UTC)[reply]
Do we have to No, we neither have to nor is there a need for it.
against nominating Exey Panteleev photography for deletion
On what basis?
Which other images are exempted like that?
How are hundreds of unused uneducational redundant porn images cluttering sexuality-unrelated categories and search results anyhow compatible with COM:SCOPE, in particular with part "Must be realistically useful for an educational purpose." They are not. Does that policy apply or does it not apply or only selectively apply? Does Commons:Deletion policy apply or does it only selectively apply? Non-arbitrariness and policy-adherence & -consistency are cornerstones of a functioning community, here made up of volunteers who spend their time and lots of effort on this platform and have some good right to expect some assumption of good faith.
I suspect at least some of the DRs might have been made by users who logged out of their accounts it doesn't seem like it but the potential pushback clearly is or would be a problem. Most of the DRs had a pretty bad deletion rationale if any so if anything these contributed to these files being kept in prior DRs.
I have no idea what point you’re making with that statement; this section is about banning DRs for these images. But in any case Commons literally exists to serve all the other projects, so your argument wouldn’t make sense anyway. Dronebogus (talk) 19:27, 16 May 2025 (UTC)[reply]
But in any case Commons literally exists to serve all the other projects
You just complained about me referring to Enwiki standards and now you are doing the exact same thing. Also the “about” page for commons says [Commons] acts as a common repository for the various projects of the Wikimedia Foundation. This is its primary purpose. Dronebogus (talk) 19:37, 16 May 2025 (UTC)[reply]
The essay I cited is just common sense – if you don't even know our aim, you're not here to help us build the project.
Anyway, the page regarding the scope of Commons – the one you mention so often (you?) – states loud and clear that "the aim of Wikimedia Commons is to provide a media file repository (...) that makes available public domain and freely-licensed educational media content to all". Serving Wikipedia and other projects is merely a consequence of Commons's core purpose. We would do just fine, thank you, without Wikipedia and company. RodRabelo7 (talk) 19:41, 16 May 2025 (UTC)[reply]
I think the essay I cited was common sense as well, but you said it was invalid because it was on Wikipedia. Make up your mind. And I am fully aware that Commons is meant to be a repository of freely usable materials for everyone, but the other primary purpose is serving Wikimedia. I never denied the first one existed, but you seem to be acting like the second one doesn’t exist or is unimportant. Dronebogus (talk) 19:48, 16 May 2025 (UTC)[reply]
The use in other projects has nothing to do with the scope of Commons. I don't know if this was addressed to me and if so why but I totally agree neither actual nor potential use in other existing Wikimedia projects is or should be a requirement for the scope of Commons. I disagree with Commons literally exists to serve all the other projects – that is just one of its uses. Btw, if this was indeed addressed to me / relating to my comment, I think you should better check when you accuse somebody of fallacies and also address what somebody actually said. Prototyperspective (talk) 21:34, 16 May 2025 (UTC)[reply]
I asked that question in my opening statement, not so much because I support it but because if the powers that be have decided that they cannot be deleted, then it should at least be open and official. Obviously I actually think Infrogmation was just wrong here period but I also know their position isn’t exactly a fringe one. Dronebogus (talk) 19:07, 16 May 2025 (UTC)[reply]
My understanding is that the files are typically kept because the combination of project and photographer are notable (i.e. it's a notable series -- one which has, for better or worse, received a surprising amount of press). The challenge is that individual photos from the series are frequently nominated individually, leading to random DR participants. I would think that if there's consensus that a series is notable, that precedent does matter for subsequent DRs, otherwise, we just nominate individual files enough times to find the time when delete !votes outweigh keeps. Perhaps it would be useful to have a single RfC here at VP with a straightforward question: "Are photographs in the Exey Panteleev 'Geekography' series in COM:SCOPE? [Yes/No/Case-By-Case]. If Case-By-Case, what should we consider in each case if not the notability of the series?" — Rhododendritestalk | 19:47, 16 May 2025 (UTC)[reply]
That’s kind of what I was looking for, but not the way you framed it. Obviously some of them are COM:INUSE and are in scope, so that just leaves a question of “are they all automatically in scope”? I’d say “no” just because I can’t think of another case where “scope is inherited”. You can’t tether an individual file’s notability to being part of a loose set; a tightly connected series maybe, but not just a thematic collection. Dronebogus (talk) 19:56, 16 May 2025 (UTC)[reply]
But then we would start discussing that one of similar files is in scope and one is not, because there are now to many similar files? That are discussions we should definitely not start. GPSLeo (talk) 20:05, 16 May 2025 (UTC)[reply]
If we were to hold such an RFC (which I would be in favor of), it might also be helpful to pose the question "how should these files be categorized". Users have frequently been surprised to find the Geekography photos in categories where nudity was completely unexpected (e.g. body paintings containing logos of products being placed in the category for that product), and I believe there's been some back-and-forth on whether that's appropriate. Omphalographer (talk) 20:17, 16 May 2025 (UTC)[reply]
I agree with Omphalographer. Personally, I don't care one way or the other about these images being on our site. I do care about violating the "law of least surprise" by turning up images of nudity when someone is searching on innocuous technical terms, company names, etc. - Jmabel ! talk06:05, 17 May 2025 (UTC)[reply]
Fair question to ask, but a separate/subsequent one IMO. Multi-question discussions tend to get messy. There are also broader considerations with regard to categorization -- it seems like it's largely about explicit images in categories where explicit images aren't expected, and this is just a good case of that, rather than it being about this case (like the scope question is). — Rhododendritestalk | 14:39, 17 May 2025 (UTC)[reply]
Call for Candidates for the Universal Code of Conduct Coordinating Committee (U4C)
The results of voting on the Universal Code of Conduct Enforcement Guidelines and Universal Code of Conduct Coordinating Committee (U4C) Charter is available on Meta-wiki.
It definitely isn't 1804, if that's what you're asking. The other side of the postcard is a photograph, but the first successful photograph wasn't taken until 1826. Omphalographer (talk) 19:51, 16 May 2025 (UTC)[reply]
Also, there were no such postcards nor stamps in 1804. As 2004 is implausible as well, you can safely interpret the year as 1904. Gestumblindi (talk) 20:29, 16 May 2025 (UTC)[reply]
It's still the sower and by the same artists, but the 1906 stamp is different from the 1903 stamp. On the 1903 stamp: lined background, no ground, sun. On the 1906 stamp: united background, ground, no sun. -- Asclepias (talk) 22:34, 16 May 2025 (UTC)[reply]
I have been speaking to local groups interested in the history of my hometown and have convinced several people to contribute their old photos of the area to Wikimedia Commons. Most have said they will upload their photos themselves but a few are elderly and not IT literate and I have offered to upload their photos on their behalf. Would it be acceptable for me to create a Wikimedia account to upload their photos, or should I upload them from my own account and properly attribute them? Adam Blacktalk • contribs21:29, 16 May 2025 (UTC)[reply]
One of the people I plan on uploading photos for is my grandmother. My late grandfather and her had hundreds of inherited photos of Lanark from the early 1900's through to WWII which were all donated to the local museum in the 90's and unfortunately lost in a fire, so we can be fairly certain the ones that remain were taken either by my grandmother or grandfather. The problem I would have though is that for those taken by my grandfather with the copyright inherited by my grandmother, in many cases we have no way of knowing which photographs were taken by which grandparent - my grandfather was the more prolific photographer so would it be best to tag them all with the heirs license? This isn't so much an issue with the others as the photographs were taken by those offering them. Adam Blacktalk • contribs08:46, 17 May 2025 (UTC)[reply]
I dont think you need to be specific using the heirs licence. For example in File:Modelspoorbaan bij oom van smiley toerist 1959.jpg I specified taken bij family of, as this could be only my grandmother or grandfather who would take this picture. You only need to be one of the remaining heirs. My mother and father are also deceased so the heirs rigths are passed on to me. If there are other heirs, I think in practice, a family agreement to publish is sufficient. In most cases only one family member possesses and manages the collection.Smiley.toerist (talk) 10:38, 17 May 2025 (UTC)[reply]
Add them to a Flickr account too, never rely on one place to store them. I would also see if the local library wants to keep digital copies and I would see if your hometown has an Arcadia Publishing book yet, if not you should write it. You can also create a Facebook group for the town. They are just books of old postcards and photos with minimal annotation. Scanning the photos is the time consuming part. Also make videos of the old timers memories and upload them to Facebook. If they are photos of people that are long dead add those to Familysearch and Findagrave. --RAN (talk) 02:56, 17 May 2025 (UTC)[reply]
Thank you for your suggestions. I had planned to create a website to host many of the old photos I have been offered. Some have educational value and can be contributed to Commons but many are out of scope (e.g. family portraits, events, gatherings, etc.). I had considered Flickr but it's been a long time since I last used it and when I recently went to the website was rather off-put by the fact they now operate a subscription model. I have taken a look at Arcadia Publishing's website and unfortunately it appears they don't operate in the United Kingdom (Lanark, Scotland is my hometown) which is a shame as it seems like a great idea to me. Adam Blacktalk • contribs09:00, 17 May 2025 (UTC)[reply]
@Adam Black: Are family portraits etc out of scope? I've been uploading random photos of e.g. these blokes in the 1930s (in Australia). Depending on the time frames of your photos, I'd say they're acceptable (we don't seem to have an overly large number of photos of normal life in Scotland in the early 20th century!). You could create yourself a subcat of Category:Family archives perhaps. SamWilson11:16, 17 May 2025 (UTC)[reply]
I would say a reasonable number of family portraits and photos of normal family life would be within COM:SCOPE, as I understand it anyway, but for example my grandmother has hundreds if not thousands of photographs of my mum and uncle throughout their childhoods and uploading all of them to Commons would not provide much educational value. Adam Blacktalk • contribs11:30, 17 May 2025 (UTC)[reply]
@Adam Black: Fair enough, that makes sense. I handle that by having a family wiki (or rather multiple, some closed-access), and putting the bulk of material there. That way, Commons files can be loaded seamlessly alongside those uploaded there. SamWilson01:06, 18 May 2025 (UTC)[reply]
I also agree that family portraits are in scope, they capture interior design and fashion, and we need more historic images that do this. Outdoor images capture architecture and landscape design. Researchers need dated images and location specific images so that people can use them to date and identify unlabeled images. Creating your own website is great, but the problem is when you stop paying the monthly fee, the website is deleted. We have so many links to now dead websites, you have to think of your collection outlasting your life. Our local library used a third party website for scanned images and those images disappeared when the company went out of business. Flickr gives you room for 1,000 free images, and you can always create a new account for another 1,000 and you can pick any of multiple licenses. --RAN (talk) 19:39, 17 May 2025 (UTC)[reply]
I didn't mean to suggest all such photos weren't in scope, just that if I uploaded all of the family photos I have been offered, that would be out of scope. Thousands of similar photos of the same family wouldn't add much value. A selection of them, however, would. I plan to create a website where eventually all of the photographs that don't make the cut can be scanned and archived. Adam Blacktalk • contribs19:48, 17 May 2025 (UTC)[reply]
Sorry, I missed the second half of your comment. I own an e-commerce business and plan on using my company's existing web hosting so hopefully it will last a long while assuming my business doesn't suddenly collapse. I'll also make copies of the archive to give to the local museum and library who will I am sure be able to preserve them for many future generations, and whichever other groups interested in local history want them. Adam Blacktalk • contribs19:58, 17 May 2025 (UTC)[reply]
@Richard Arthur Norton (1958- ): I'd recommend against trying to get around Flickr's free limits, they seem to be cracking down on that sort of thing. But it sounds like @Adam Black has a hosting option in mind. The other place I'd suggest is the Internet Archive (if you upload a pile of TIFFs into an item there, thumbnails and a gallery etc. are created; that doesn't seem to be true of JPGs or PNGs). SamWilson01:11, 18 May 2025 (UTC)[reply]
Might there be a problem with the US licence in the case of unpublished work? Many pictures in family archives have never been published. see {{PD-US-unpublished}}. If the author is deceased in 1955 or later, or if is anonymous or not known when deceased. In these cases it has to be works before 1905!. An heirs licence gives protection from this. It defies Common Sense, that a anonymous published picture has less restrictive PD conditions, while there are more commercial interest in protecting published work. Most unpublished work is amateur work or professional work, not worthy of publishing. A picture wich has been in the family possession for many generations (and local family content) would not be allowed to be published in the US?Smiley.toerist (talk) 11:28, 17 May 2025 (UTC)[reply]
@Smiley.toerist: Some of this gets quite off-topic, so Adam Black can choose to ignore much of my response to you. Taking up your points:
If the uploader is the inheritor of the copyright, then there is no problem: they grant a license, just as good in the U.S. as anywhere. But, yes, for third-party work this can be a problem. It can also be a problem sorting out just what qualified as "published." A group portrait (more than a handful of people) where all (or most) of the people in the photo got a copy was thereby "published."
The reason previously unpublished work is given more protection is that the law was primarily driven by the idea of protecting commercial rights, not of facilitating free use. Someone who has already published commercially has already had the opportunity to gain value from the exploitation of their work. The intent with longer protection for certain unpublished work was to give people a motivation to publish it commercially. This law predates the wide dissemination of free content on the Internet, so that was barely a consideration.
On your last question: it's all up to the heir(s) of the photographer. They can publish, they can give someone else permission to publish, they can refuse to publish. - Jmabel ! talk19:36, 17 May 2025 (UTC)[reply]
Another thing is wat are the copyrigths of commissioned works. For an example by a marriage there is often a professional photografer wich takes pictures This work is bougth by the family and the family is free to use distribute the pictures freely. It is unclear if there are publication restrictions (it could be different by country). Can these works be published in the Commons, as these works (and copyrigths) are bought? In commerce once the photografer has sold the rigths the buyer can do what its wants with it. For the family archives it is necessary to go back in time and see what the legal rules where at that time. Smiley.toerist (talk) 11:50, 17 May 2025 (UTC)[reply]
In the U.S., you cannot transfer copyright orally. If the contract didn't transfer the copyright, it's still held by the photographer or their heirs. Inconvenient, to say the least. - Jmabel ! talk19:38, 17 May 2025 (UTC)[reply]
If the copyrigth transfer happened in the US. I dont think US law, overrules the other countries rules about the transfer of copyrigths. So if in the other country rules the buyer of the photos automaticaly acquires the copyrigths, the owner should have the copyrigths to under US law. (certainly unter the foreign laws). I suspect that the Lanark photos are taken in Australia, so for the commissioned works, the Australian law applies. (I take it as Australian Adam Black's Commons CV has a lot of Australian connections). Smiley.toerist (talk) 11:00, 18 May 2025 (UTC)[reply]
I am interested in Australian history (my brother-in-law is Australian) so some of my contributions are of Australian things but it's the Lanark in Scotland that I'm from. I'll have to look into this aspect of UK copyright law. I am hoping the local museum might be willing to allow me to scan and upload some of the photographs in their archives - they have a lot of portraits of prominent Lanarkians and their families from one of the original photo studios in town (c. 1870s to the early 20th century) and I presume most of them will be in the public domain now but I'll need to make sure. There's also the issue that there are two sets of laws here - Scots law and British law. Some laws apply only to Scotland and others apply across the entire UK. I'm not sure whether Scotland had its own copyright law before the Copyright Act 1956 and its successor, the Copyright, Designs and Patents Act 1988, the current UK-wide law, and if so whether it would still apply. Copyright protections can be quite long in the UK too - the original Winnie the Pooh book for example was published in 1926 but copyright of the text doesn't expire until 2027, and the copyright on the illustrations doesn't expire until 2047 (70 years after the author's and illustrator's deaths, respectively). Adam Blacktalk • contribs11:32, 18 May 2025 (UTC)[reply]
May 17
Please vote for new checkuser
Hello community, I would like to take this opportunity to invite you to vote for a new checkuser, Lymantria, at Commons:Checkusers/Requests/Lymantria. Your vote is critical to make Commons work better in the future. The poll ends in four days so please take your time when available to cast your precious vote.
Are there specialists in early motorcycles? As far as I can read it is Auroleá sports. If I read the notice of my grandfather on the backside correctly.
I'm working with a UN agency who are considering sharing some photos on Commons, but they have some concerns. They have asked if they can add a watermark to the images in the corner with the UN organisation name and the UN emblem. I know that watermarks are discouraged in general, but can I ask if a watermark with the UN emblem would be allowed? I'm aware of Commons:Watermarks and have shared this with them.
It's interesting that a UN agency has these reservations. In my perception, the UN serves humanity as a whole and it's thus in their interest and general remit to produce content that can be shared as widely as possible, with the priority being usefulness and reusability. Visible watermarks don't feel right in this regard. Of course content can be shared under licenses that require attribution, which serve the exact purpose of what the agency may want/appreciate.
They could add a watermark. However, if they upload to Commons then the most restrictive license would probably be CC-BY-SA and that license still allows to edit a file as one pleases, which means that re-users can choose to either crop the watermark out or to somehow edit it out. That's something that the UN should keep in mind when uploading a watermarked image to Commons. Nakonana (talk) 20:45, 17 May 2025 (UTC)[reply]
Shorter version of that: watermarks are allowed but discouraged, and people are allowed to make derivative works that omit the watermark, or even overwrite the original with a retouched version that omits the watermark. - Jmabel ! talk21:25, 17 May 2025 (UTC)[reply]
Officially maybe allowed, certainly discouraged, but practically watermarked images are not used in Wikimedia platforms, as watermarks are considered problematic.
@Romaine: I'm sure John is long since aware of all that. But your point is valid that if the agency wishes its content to be used in Wikipedia, watermarking it is a bad idea. On the other hand, if they are just using Commons as a way to make this content more broadly available, they may have their own priorities and agenda. - Jmabel ! talk03:56, 18 May 2025 (UTC)[reply]
You can add a margin around the image and add a catalogue number and the symbol there. See what the Bundesarchiv did: here. Destructive watermarks are a terrible idea. You should also get a free Flickr Commons account. The more places you store the images, the more likely they will be around in 100 years. You can also make sure that you add in information in the Metadata. That information is preserved if someone downloads and reuses. --RAN (talk) 15:16, 18 May 2025 (UTC)[reply]
Just when will we get a better system than categories
(Two recent actions triggered me to finally write down this long rant, but let me be clear, I'm not discussing them specifically and I actually dont care about them:
mediawiki categories can only have one fixed name. hence users are just throwing away time doing these ridiculous category moves, discussions... and when someone doesnt notice, they make certain names red instead of redirects, then the next person cannot find them when they use uploadwizard/hotcat/cat-a-lot. ¯\_(ツ)_/¯
just when will we have a system that can associate a concept with multiple alternative names in multiple languages? instead of a single PAGENAME? RoyZuo (talk) 20:13, 17 May 2025 (UTC)[reply]
There is no good reason to delete, or to fail to make, simple redirects like those in your examples. It breaks in bound links, and confuses and disadvanatages colleagues and users who only know the old name. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits20:45, 17 May 2025 (UTC)[reply]
Our alternative to the "tag" system is COM:SDC, which is more precise, because the values for "wood" (for example) are different for timber and and an area of trees, whereas in English tags they would be the same. SDC is also multilingual (as, incidentally the labels on Wikidata for our categories). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits21:01, 17 May 2025 (UTC)[reply]
All this was often discussed and with the structured data we also have a solution path defined. The only problem is that the WMF suddenly dropped the funding of the development of structured data. GPSLeo (talk) 21:18, 17 May 2025 (UTC)[reply]
I think its very regrettable that WMF stopped SDC half way through. The UI for the existing SDC system is terrible in my opinion. Sure you can add metadata, but you can't get listings (ignoring external applications) of files by metadata. What use is making a catalog if nobody can read it? Its like the proverb about a tree falling in the woods. On the subject of categories though, half the problem is self-inflicted. The category tree structure system that commons uses is bizarre and difficult to navigate. Nothing in the technology says categories have to be used that way. They can be used like tags instead (i.e. Instead of Category:Pictures_of_Barack_Obama_eating_a_sandwich_in_central_park you could just have Category:Barak_Obama, Category:Eating_a_sandwich, category:Central_park. A large flat namespace that can be intersected isntead of having oddly specific small categories). Bawolff (talk) 22:17, 17 May 2025 (UTC)[reply]
Categories also are used like tags. They're just not displayed like them. However, they could be displayed like them and maybe that would be better, e.g. directly beneath the image. I don't think SD would help with anything described here. There is no category page, SD largely comes from categories and depicts SD are about what the image shows not e.g. its topics with other SD even less rarely set than the depicts. There aren't so many overly long category titles but these are not a problem either, some grouping of categories and sorting would be helpful regarding that though. Prototyperspective (talk) 22:31, 17 May 2025 (UTC)[reply]
@Bawolff: which is mostly an argument against making over-specific intersection categories. But even when the "splitters" win out, categories can be very useful in that once you have a picture that is sort of what you want, you can usually navigate the category hierarchy to get to something more precisely like what you want. - Jmabel ! talk03:59, 18 May 2025 (UTC)[reply]
Bawolff is right that the SD-interface on Commons is bad. As a categorizer, I cannot use it to (timely) tag for example books by their publishing date or location. In principle SD is possible, but it takes minutes to find the correct SD-tag-name, and then fill it with the correct SD value. We have millions of books scans on Commons, and given how structured even the file descriptions are, bots could easily do the filling-in of simple tags, or maybe a trained AI. (I am not talking about advanced image recognition, I am talking about basic text processing.) As end result, we'd have structured data for most books on Commons, featuring the publication info.
Once that stage gets reached, Category:1897 books from Iowa would be largely redundant, but I don't see a reason why we would then completely abandon the category approach. We could keep both SD and categories.
Categories created by "splitters", as Jmabel puts it, are indeed very useful. Take Category:Books about education in Iowa. Lots of material if you're specifically interested in that subject, 56 books are nothing to sneeze at. However, there are two problems: the category needs to get defined in the first place (I did it on a whim when I realized how many 19th-century books from Iowa were about this topic) and the category needs to be filled (how many books on the subject are already uploaded on Commons - does the category even include 25% of the actual number?). The SD approach would allow any adept user to combine three tags (books, education, Iowa) and effectively search, without any pre-defined category. --Enyavar (talk) 10:43, 18 May 2025 (UTC)[reply]
that solves the intersection cat problem, but it doesnt solve the problem of "category having one single fixed name". "St. Marienkirche" "Marienkirche" "Marien church" "Mary church" "Sankt Marienkirche" "St Marienkirche"... could well be the name with which users try to find it. Switzerland or Singapore having 4 offcial langs has many things having 4 offcial names, but the mediawiki category system makes it such that there is only 1 name for 1 thing. Neither multiple alternative names in 1 language, nor names in multiple languages, are possible.
creating cat redirects is not a good solution:
it takes my fast fingers still at least 10 seconds to create 1 redirect (even though i have 2 scripts in place to speed up the "copy pagename paste into wikitext" process).
there're constantly people deleting that shit (this time trigerring my rant).
I like categories, but it would be nice to see them improved. E.g. the ability to search for/filter all files within a category tree (not just the top level), and the ability to filter based on other categories files within a tree might be tagged with. FastCCI seems to be doing all these things, but the tool hasn't worked for years. ReneeWrites (talk) 10:14, 18 May 2025 (UTC)[reply]
There is a problem that once you recursively look in subcategories, the semantic concepts drift surprisingly fast. Five levels down it might be still related or it can be something completely different. That said, it is again an interface problem. We have the incategory: and deepcat. If you really want to do something complicated, we have the category sparql endpoint. We have the backends, it is just not discoverable to users due to UI. However the reason there are UI issues is because when people experiment with this they usually quickly realize querying the current category tree is not what they really want, so nobody bothers putting effort into a really smooth ui. Bawolff (talk) 12:24, 18 May 2025 (UTC)[reply]
This depends on the category. There are a lot of categories where this is no issue. Theoretically offtopic images displaying deepcat results can be solved but it needs a lot of categorization work so the broader the cat, currently the less likely it is it will not show offtopic files. A better way to address this though and which would also address the drift issue is by improving how files are sorted, for example by showing files closer to the top-level category or in quality images subcats or that are used often in WM projects further up than other ones etc. In addition, a way to easily filter out various common subcats such as 'xyz in art' subcats in the results or any of a list of subcategories sorted by number of files they contribute to the results seems needed / very useful, as outlined roughly at phab:T376440#10354943. Regarding UI, maybe FastCCI could be improved or a new tool with a button (if possible also having more easily understandable text) forked from it. It does work sometimes but it loads too long and loads to unreliably (phab:T367652) – clicking the dropdown->"All files" didn't work on this cat where deepcategory works but it does not display all files (click on "Switch to Special:Search" to see the error). Prototyperspective (talk) 14:20, 18 May 2025 (UTC)[reply]
Now if considering what I wrote above, this would be dealt with via 1. improved sorting (various techniques and methods) and 2. improving the categorization so e.g. this should be in this subcat (and this can be done via the view we're talking about) and 3. by category "Dog equipment" displaying in the list of top subcats files are from to filter out with just one click as I outlined at the link. Prototyperspective (talk) 17:22, 18 May 2025 (UTC)[reply]
Equally stupid filenames
Essentially the same problem, just in file namespace instead of category.
a filename is too short / generic, people dont like it; too long, also dont like it. ¯\_(ツ)_/¯
then some people insist on "harmonising" or nitpicking other users' uploads, and some fight back to insist on their own naming schemes. what for? ¯\_(ツ)_/¯
after all the hassle, filename is often just an ill fated attempt at summarising what actually goes into the description (and sdc caption is a whole other debate). a picture is worth a thousand words! there can be a million ways to name a file. how to cram 1000 words into 256 bytes? why waste each other's time in pursuit of your personal stringent standard?--RoyZuo (talk) 20:42, 17 May 2025 (UTC)[reply]
Files have titles for reasons, to make it easy to find them with searches or evaluate search results or on category pages. There is no problem except lots of files are named badly (example File:Fphar-11-00937-g001-ru.jpg) and people often don't care sufficiently about making them accurate and descriptive. You did not make any suggestion for improvement. There is no time of others wasted, very rarely do I ever see people move files and it's happening far too rarely and if it does, it doesn't waste anybody's time except when the uploader for no reason rejects an actually useful descriptive title which I've seen happening for just one user. Prototyperspective (talk) 20:52, 17 May 2025 (UTC)[reply]
nobody cares about what a specific file's filename is on flickr/getty/any other image hosting site. it's just a string of ascii letters and numbers.
commons has this stupid system coz it uses mediawiki, which fixes PAGENAME, and changing it requires a "page move". it could well just be a string of text freely editable for any number of times. but it cannot because mediawiki has to identify the file by PAGENAME instead of an internal file number. RoyZuo (talk) 21:02, 17 May 2025 (UTC)[reply]
just look at loc or any library/archive in the world https://www.loc.gov/item/91795009/ . every item has a catalog / control number. no matter how the information gets edited, the number stays stable, so the info (including title) can be edited as many times as you want and there can exist multiple versions as long as you like.
no image hosting site or library/archive uses stupid systems like this that changing a name requires moves and breaks file usage (if redirects are kept, it's not broken within wmf projects, but it still breaks outside wmf projects coz the raw url used for embedding the file changes!)
mediawiki is 2000s tech designed for a text website that decided to use "pagename" as the only means to locate a page. if it started with an alphanumeric identifier for every page, or if it recognised the need for some pages to change titles frequently, we would not waste all this time on these trivial things.
i mean, why should it have a fixed page name? look at blogspot, every blog article has a fixed url that may or may not be related to the title of the blog article. you can also edit the article after you have fixed the url. the url is just a link for convenience, why tie the title to the url? ¯\_(ツ)_/¯ RoyZuo (talk) 21:27, 17 May 2025 (UTC)[reply]
the same is also true for usernames. most websites let you change your username however you want coz most often the system doesnt rely on that name to identify the user but rather uses a number.
mediawiki? needs approval, and a special kind of user to carry that out, and it still sometimes breaks things along the way.
all because it uses the PAGENAME to identify a user. ¯\_(ツ)_/¯
which also makes it such that one name can only be used by one person. no identical names. not even similar names (coz that causes confusion they say)! RoyZuo (talk) 21:41, 17 May 2025 (UTC)[reply]
Nothing is stopping anyone from naming files File:02e5c4e8-489c-4de2-9382-1efcc2a9fb81.jpg if they so desire. Ultimately though files are going to need human readable names at some point, and people are going to look for those names, and are going to be confused when they change, regardless of if they are the primary identifier or not. Even if instead of using urls like https://commons.wikimedia.org/wiki/File:Duisburg,_Landschaftspark_Duisburg-Nord,_Erzbunker_--_2024_--_4214.jpg, we used a url like https://commons.wikimedia.org/entity/M148107007 or a url like https://commons.wikimedia.org/?curid=148107007 (I think both of these numeric urls stay the same after a file move and possibly even after delete/undelete) people still think in terms of file titles not file numbers. If the primary concern is that old links will break, it seems like that problem is easily solved by leaving a redirect behind. I honestly don't see what the practical difference is. Bawolff (talk) 22:09, 17 May 2025 (UTC)[reply]
@Bawolff the human readable name needs not be the single thing the file is identified throughout wmf projects. why cant it be like "description" that's editable without a "page move"?
page id (aka curid) does stay the same, but PAGENAME is still how the system handles files.
i kinda remember that there's talk (phab task) about making it possible to directly use a specific version of a file (i.e. referencing a specific file revision directly, most likely through an alphanumeric identifier), but when will that eventually happen? RoyZuo (talk) 13:25, 18 May 2025 (UTC)[reply]
well i fixed it for thumbnails (but not original files) in 2013. No idea if it still works though. High liklihood the move to thumbor broke it again, and it never worked for original files. Regardless i would agree that there are a wide variety of reasons why it would be better to use hash based urls for the actual file asset. However that is entirely separate from what mediawiki calls the file. In fact i believe mediawiki already has support for this for a while (the storageLayout parameter to $wgLocalFileRepo), its just difficult to convert all the pre-existing files. Bawolff (talk) 14:53, 18 May 2025 (UTC)[reply]
It doesn't matter what other sites do for that matter but most of them including in your example do have proper titles. In your example, it is "Declaration of Independence: July 4th 1776". I don't understand why some people have such difficulties in understanding of proper descriptive well-readable file titles. It harms the platform as well as the usefulness and visibility of your files. Prototyperspective (talk) 22:27, 17 May 2025 (UTC)[reply]
That title can be easily edited, for as many times as possible. Can be multilingual. Can be arbitrarily long.
I'd support making it easier to change file-titles. They can already be moved but not so many users have permissions to do that directly and even then it seems only to be used when there really is a big issue. For example Incidence and prevalence of extensively drug-resistant tuberculosis, World, OWID chart (the title within the image) would be much more readable and clearer than File:Extensively-drug-resistant-tuberculosis.png but the latter still has some descriptive info that makes it not as much of a problem as the title of say File:Fmicb-02-00157-g001.jpg. Regarding multilingual I've linked something in a comment further up and regarding length, limiting it is needed because otherwise it's too long to be useful and not cause display issues – it needs to be concise with any further info going into the Commons caption and/or file description. Prototyperspective (talk) 15:45, 18 May 2025 (UTC)[reply]
implemented by creating a new parameter "title" for {{Information}}. default value is PAGENAME, but users can of course manually give a different value overriding PAGENAME. and the template will call {{DISPLAYTITLE:...}} to display the manual value.
And then the same problem also occurs to file descriptions. some users are fixated on editing descriptions into a way they like.
no, description does not need to be reduced to a mechanic statement. creators (photographers) sometimes have additional things to say and it's completely fine. sometimes the original description is too generic, it's also fine, coz you can add on to it for the original authors.--RoyZuo (talk) 20:42, 17 May 2025 (UTC)[reply]
I occasionally get people on my watch list editing a bunch of files I've uploaded/created where they change or remove my gallery tags (if the image is part of a series), or place the "other versions"/"extracted from" template outside the file description space; I'm never quite sure if I'm allowed to revert those edits. ReneeWrites (talk) 10:19, 18 May 2025 (UTC)[reply]
"other versions"/"extracted from" template outside the file description space don't know what you mean by this but the standardized {{Information}} has a |other versions = parameter into which other versions belong which could then be read properly using for example apps like the Commons app, APIs, scripts, search methods, and so on. Prototyperspective (talk) 10:54, 18 May 2025 (UTC)[reply]
my personal stand is i leave as much original description as possible, unless it's plain irrelevant or wrong. quite often i see original description, that contains much more detail and is written with more literary techniques/devices, gets trimmed by commons users to become cold and boring. why? ¯\_(ツ)_/¯ RoyZuo (talk) 13:51, 18 May 2025 (UTC)[reply]
@RoyZuo: Some of that should have been kept, but are you honestly saying we should keep, "Ready to improve your bedroom performance? Try LOAD BOOST by VB Health and see what everyone is talking about" as part of the description of a file? - Jmabel ! talk16:18, 18 May 2025 (UTC)[reply]
Agreed. The original description contained some material which was clearly promotional in nature and wildly inappropriate for Commons. And, perhaps it's a separate issue, but I'd also question whether it's appropriate at all for Commons to host a podcast episode which includes promotional segments for penis pills. Omphalographer (talk) 19:24, 18 May 2025 (UTC)[reply]
May 18
Difference between "architecture" and "structure"?
Architecture (literal "covering the tip") means the style of buildings and the art to build, structure the constellation of single element to a whole object. --PantheraLeo1359531 😺 (talk) 12:24, 18 May 2025 (UTC)[reply]
Architecture is clearly the superordinate term. Note that for example gardens and parks belong to architecture too, but are not structures as a whole. --A.Savin12:44, 18 May 2025 (UTC)[reply]
That last answer seems to me to be quite a stretch. Yes, we refer to a "landscape architect" but the fact remains that they are not, strictly speaking, an architect, any more than a "software architect" is an architect. However, architecture includes architectural education, architectural libraries, studies of the history of architecture, etc., none of which are structures. - Jmabel ! talk16:27, 18 May 2025 (UTC)[reply]
I am not a botanist, but it seems to me that in general we should trust labels in a plant conservatory over a random Commons user. In this case, my original species identification as Kalanchoe thyrsiflora c-3218, "Desert cabbage", Crassulaceae came from just that sort of label. Neux-Neux (of whom I otherwise know nothing) edited these in July 2023 to say Category:Kalanchoe luciae instead of Category:Kalanchoe thyrsiflora. The category page for Category:Kalanchoe luciae says, "It is very difficult to distinguish between the two species when only leaves are present" and goes on to discuss the differences, such as they are.
Although of course a conservatory can make a mistake, when should we (or shouldn't we) presume that a given Commons user, providing no references or explanation, knows more than the conservatory about the conservatory's plants? - Jmabel ! talk16:41, 18 May 2025 (UTC)[reply]
Misidentification is not uncommon in botanical gardens. Even some of the pictures on Kew's POWO are obviously misidentified, e.g. https://powo.science.kew.org/taxon/urn:lsid:ipni.org:names:274478-1/images: the plants in the four photos are all Kalanchoe × houghtonii but unfortunately misidentified as K. serrata. As for the case of K. luciae / K. thyrsiflora, it is indeed difficult to identify a plant with no flowers and I must admit that I changed the identification simply because K. thyrsiflora is extremely rare in cultivation and K. luciae is too often mislabelled "K. thyrsiflora". Of course, that does not mean K. thyrsiflora has never been cultivated; for example, the plants labelled "K. thyrsiflora" in the Huntington Gardens in Pasadena, CA were the true ones (https://www.agaveville.org/viewtopic.php?t=5365). You can certainly change the identification back, but the best solution I think is to put them under Category:Kalanchoe. Neux-Neux (talk) 20:17, 18 May 2025 (UTC)[reply]
Minor note: I use apps on my phone which accurately tell me the species of insect or plant but nothing of that sort is used for Commons categorization. Maybe at some point some bot could scan taxonomic categories to identify files that appear to be miscategorized so people can check them. Prototyperspective (talk) 21:23, 18 May 2025 (UTC)[reply]
Thousands separators
Started a rather technical request here - the person who made this template retired in 2013, so if you can help by adding a function to a template, please stop by. The issue is that the thousands separator added to the output of a template wrecks my attempt to do math with the resulting numbers. Best, mr.choppers (talk)-en-19:19, 18 May 2025 (UTC)[reply]