Commons:Village pump
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/2024/08. Please note:
Purposes which do not meet the scope of this page:
Search archives: |
Legend |
---|
|
|
|
|
|
Manual settings |
When exceptions occur, please check the setting first. |
|
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days. | |
July 26
Self-taken photo
I took this photo years ago, and then noticed a wikimedia user claimed it as their own. How can I remedy this issue? I've gone on both the photo's talk page and the users talk page and have gotten no response.
— Preceding unsigned comment added by Criticalthinker (talk • contribs) 10:15, 26 July 2024 (UTC)
- @Criticalthinker: Hi, You uploaded your photo under the name File:10 Lansing Center.JPG to the English-language Wikipedia on 2 April 2006. The other user merely transferred it to Commons in 2011. You can correct and complete the information in the description page. An administrator on en.wikipedia should check what license you gave the file on Wikipedia. -- Asclepias (talk) 11:21, 26 July 2024 (UTC)
- Licensing was {{PD-self}}, uploaded by User:Criticalthinker. I believe this is now fixed, but feel free to edit further if I didn't have it right. - Jmabel ! talk 18:33, 26 July 2024 (UTC)
- Oh, wow. Thanks! Criticalthinker (talk) 07:09, 27 July 2024 (UTC)
- @Criticalthinker: Just a side note, as you released the file into the public domain through "PD-self", you have relinquished your right to be named as the creator of the file. It's still a good idea to do so, so people see who has released the file and that everything is in order license-wise, but basically, anyone can now do with this file what they want without mentioning you. If you want to prevent this, you should use an attribution license like CC-BY or CC-BY-SA. That being said, it would probably still be inappropriate for any other person to claim that they're the author, but as others pointed out, that's not what happened here. Gestumblindi (talk) 16:49, 27 July 2024 (UTC)
- Okay, so this wasn't "fixed." What do I do? I've been on Wiki for awhile, but I have no idea of the process you've spoken of. What do I need to do, specifically? Criticalthinker (talk) 00:12, 28 July 2024 (UTC)
- You start uploading your photographs under the Creative Commons Attribution-Share Alike 4.0 license. Thats what you do now Trade (talk) 03:44, 28 July 2024 (UTC)
- For this specific image and any images that you may have uploaded as "PD-self" in the past, you can't "fix" it - it means you have irreversibly released them into the public domain and people don't need to mention you as the creator. As said above, if you want to be credited, just use CC-BY or CC-BY-SA for future uploads. Gestumblindi (talk) 08:42, 28 July 2024 (UTC)
- As was said, it was uploaded in 2006. I'd not even remembered that I'd uploaded it until I came across it, again, years and years later, let alone the licensing. I don't even remember what the old wiki would have looked like, then, and I don't imagine many of you do, either. The rudeness was completely unnecessary in the replies. But if that's how you're going to deal with it, thanks for absolutely nothing. Criticalthinker (talk) 06:36, 29 July 2024 (UTC)
- I didn't mean to be rude, I thought I was just stating the facts for your information; if that came across as rude, I apologize. Gestumblindi (talk) 17:08, 29 July 2024 (UTC)
- Okay, so this wasn't "fixed." What do I do? I've been on Wiki for awhile, but I have no idea of the process you've spoken of. What do I need to do, specifically? Criticalthinker (talk) 00:12, 28 July 2024 (UTC)
- @Criticalthinker: Just a side note, as you released the file into the public domain through "PD-self", you have relinquished your right to be named as the creator of the file. It's still a good idea to do so, so people see who has released the file and that everything is in order license-wise, but basically, anyone can now do with this file what they want without mentioning you. If you want to prevent this, you should use an attribution license like CC-BY or CC-BY-SA. That being said, it would probably still be inappropriate for any other person to claim that they're the author, but as others pointed out, that's not what happened here. Gestumblindi (talk) 16:49, 27 July 2024 (UTC)
- Oh, wow. Thanks! Criticalthinker (talk) 07:09, 27 July 2024 (UTC)
- Licensing was {{PD-self}}, uploaded by User:Criticalthinker. I believe this is now fixed, but feel free to edit further if I didn't have it right. - Jmabel ! talk 18:33, 26 July 2024 (UTC)
- "it would probably still be inappropriate for any other person to claim that they're the author" Would it be against policy tho? Trade (talk) 03:45, 28 July 2024 (UTC)
- I should hope so. While there may be no requirement to credit the creator, knowingly adding false information in any way to any WM project is vandalism. Unfortunately, marking uploads as one's own creation to upload hassle-free is pretty rampant--I was shocked at the number of people who think this is okay so long as they are not trying to actually claim rights or profit from the image. Josh (talk) 01:54, 11 August 2024 (UTC)
- "it would probably still be inappropriate for any other person to claim that they're the author" Would it be against policy tho? Trade (talk) 03:45, 28 July 2024 (UTC)
- You can convert the image to a png and then reupload the image, and ask that the jpg be deleted. --RAN (talk) 15:49, 30 July 2024 (UTC)
- That's not a helpful comment. What exactly would the uploader achieve with that? The file format wouldn't change the PD-self license. Also, I don't see the advantage from a technical point of view of converting a JPEG photo to PNG. Gestumblindi (talk) 18:43, 30 July 2024 (UTC)
- @Richard Arthur Norton (1958- ): Any png image will look fuzzy when scaled down (due to design decisions discussed in phab:T192744), so you may want svg or jpg versions instead. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:43, 4 August 2024 (UTC)
August 03
Should we convert all TIFFs to JPEGs?
Following this discussion - Commons:Bots/Work requests#Convert Category:Photographs by Carol M. Highsmith to JPEG (bot request), I'm trying to assess what sort of consensus we have regarding the conversion of TIFFs to JPEGs in general. Also, see past discussion in the archive. -- DaxServer (talk) 16:36, 3 August 2024 (UTC)
- Reasons to prefer JPEG over TIFF for our purposes:
- Easier to view, download & use for people with slower internet connection
- JPEG is generally much easier to use for average people without specialized programs/knowledge about file types
- Often significantly smaller file size while preserving the image quality (often over 1000% smaller (sometimes over 10000% (TIF|JPG))
- TIF has issues with displaying correctly as thumbnail
- raw .tif files cannot be displayed in browsers (URL ending .tif (TIF example, JPG example) - this means properly zooming is not possible without downloading a large file to your PC (or even better your phone)
- TIF is not indexed by Google and presumably other image search engines (as the format is unsuitable for web purposes, see above)
- Proposed solution is to convert the TIF file to JPG and upload as such, copy all information, and make both files cross reference each other. This has been done already with ~250,000 NARA/LOC files (see e.g. here)
- TheImaCow (talk) 17:05, 3 August 2024 (UTC)
- All these problems are solved by the jpeg thumbnails they are available. GPSLeo (talk) 18:14, 3 August 2024 (UTC)
- TIFF is the world's most featureful image format, so not all TIFFs are good candidates for conversion to JPEG. Multipage TIFFs might be converted to PDF, and non-photographic TIFFs would be better off as PNGs.--Prosfilaes (talk) 17:38, 3 August 2024 (UTC)
- @Prosfilaes: Any png image will look fuzzy when scaled down (due to design decisions discussed in phab:T192744), so you may want to upload svg or jpg versions, too. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:41, 4 August 2024 (UTC)
- We don't need to align 100%. Anything that goes "we do this here, so we should do it everywhere" is flawed. We shouldn't waste resources on this. Targeted approaches might make sense sometimes, but most of this material isn't even in use, nor will it ever be. —TheDJ (talk • contribs) 17:40, 3 August 2024 (UTC)
- Oppose. Let sleeping dogs lie. (BTW, I have some old LoC code that will read TIFF but not JPEG.) Glrx (talk) 18:26, 3 August 2024 (UTC)
- Oppose convert master images (ie. the file what Wikimedia Commons uses as source when scaling jpg) from lossless format to lossy ones. It just means lower image quality. If user needs smaller files user can already download the jpeg versions of the files from Wikimedia Commons instead of original file. --Zache (talk) 19:23, 3 August 2024 (UTC)
- Comment Nothing prevents you from converting a tif into a jpg and uploading it alongside the original tif. Ruslik (talk) 19:41, 3 August 2024 (UTC)
- Time does.
- It is finite, and either it is spend
- - downloading the TIF
- - converting the TIF to something else
- - uploading the tif
- - copy & adjust file info
- - adjust file info of the tif
- -- repeat x1000
- or
- -doing anyting else that cannot be easily automated. TheImaCow (talk) 20:59, 3 August 2024 (UTC)
- It's already available for each tif, so no need to duplicate it. Enhancing999 (talk) 05:06, 4 August 2024 (UTC)
- Support Yes, for most Wikimedia projects, JPEG is better. Yann (talk) 19:44, 3 August 2024 (UTC)
- Comment: I have been thru this issue here in the case of an archived TIFF and subsequent JPEG with suitable cross‑linking. So please consider this use case given an original high‑quality TIFF scan and a downstream usable JPEG image. And please add some nuance to the algorithm that goes thru converting everything "in general" and explicitly identify and exclude this corner case. TIA RobbieIanMorrison (talk) 22:06, 3 August 2024 (UTC)
- Of course, converting of all images from lossless to lossy format is unacceptable. This can be discussed only for some particular cases. In the general case TIFFs can be converted to PNGs, they will become smaller (but not as small as JPGs). Sneeuwschaap (talk) 23:27, 3 August 2024 (UTC)
- @Sneeuwschaap: Any png image will look fuzzy when scaled down (due to design decisions discussed in phab:T192744), so please use 100% quality jpg images to preserve quality and allow easy display on WMF projects. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:47, 4 August 2024 (UTC)
- Oppose I can see the benefit of this, but then it would also create needless duplicates that just screw with search results and take extra curation. I'd probably support it if there was a way to hide or suppress TIFF images though, but it's hard enough dealing with multiple images formats as it is. Some TIFF files probably aren't worth converting to JPEG in the first place either. One thing I'd like to see fixed is how TIFF images display in thumb nails though. I think that would solve a large part of the problem with them. --Adamant1 (talk) 01:32, 4 August 2024 (UTC)
- Comment How many edits were already done on the 250,000 existing duplicates? How much time was wasted in duplicated curation somebody uploaded two formats of the same photo? Enhancing999 (talk) 05:12, 4 August 2024 (UTC)
- Oppose I think tiff files are higher-quality aren't they? So if they are converted then to something that is lossless and I don't know if there is such a filetype. More useful would be converting gifs that are not animated to another filetype. Prototyperspective (talk) 10:18, 4 August 2024 (UTC)
- Oppose as ambiguous: What whould be done with the TIFFs? If kept, support. If deleted, oppose. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:51, 4 August 2024 (UTC)
The proposal incudes "make both files cross reference each other.", so clearly the intention is to keep them.Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:03, 4 August 2024 (UTC)- @Pigsonthewing: No, it doesn't. DaxServer, COM:VPP is the more appropriate venue. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:23, 4 August 2024 (UTC)
- My mistake; apologies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:39, 4 August 2024 (UTC)
- I wanted to post it here as a general discussion, but it took a different turn. -- DaxServer (talk) 12:24, 4 August 2024 (UTC)
- @Pigsonthewing: No, it doesn't. DaxServer, COM:VPP is the more appropriate venue. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:23, 4 August 2024 (UTC)
- if a bot has the ability to automatically convert tiff to jpeg (upload as new file), i think obviously the sensible option is
- make a template that users can use to tag files for automatic conversion. something similar to rotation requests.
- because as users have explained, most tiff files are not actively in use. there's no urgency to convert them. maybe when they do become needed in future, web technology has developed to being able to display tiff properly.
- so for now, if any tiff is to be used somewhere, and the user thinks it's beneficial to have a jpeg version instead, only then convert that specific tiff. otherwise most files dont need a duplicate jpeg. RZuo (talk) 12:42, 4 August 2024 (UTC)
Oppose, original-quality and file type of the TIFF files must be maintained, especially if these were directly imported from GLAMs that various Wikimedians partnered with. If there is a need for JPEG, then upload under a new file name. We can't be sure if forced conversion of TIFFs to JPEGs may lead to discouragement of some GLAMs to continue partnering with Wikimedian volunteers. And by the way, TIFF is a lossless file type, whereas JPEG is a lossy file type. I've read somewhere above that this proposal may be of benefit for Wikipedia articles (this is solved by uploading a JPEG version under a new file name), but as per some of our voices at Commons talk:Media knowledge beyond Wikipedia, Wikimedia Commons does not only aim to be a central media repository for all Wikimedia projects like enwiki; it aims to be a reliable partner of external institutions like GLAMs and non-profit orgs for their freely-licensed media content to be hosted and reused globally. To be a reliable partner, IMO, we should not alter the original, raw TIFF files that the GLAMs donate to us; instead, it is best to convert to JPEG and upload as a new file. I can recall a template for LoC files that states raw files directly donated by LoC should not be altered in any way so that those represent the exact-quality files from LoC, and any modification/s must be uploaded as a/as new file/s. JWilz12345 (Talk|Contrib's.) 23:55, 4 August 2024 (UTC)- @JWilz12345: You seem to be opposing some proposal other than the one being made. To quote from the original post, "Proposed solution is to convert the TIF file to JPG and upload as such, copy all information, and make both files cross reference each other." Your objection seems to presume that the TIFF would be delete, but nothing of the sort is being proposed. - Jmabel ! talk 03:16, 5 August 2024 (UTC)
- @Jmabel: ah, then that's better. I have striked my comment and vote. As long as the original raw TIFF files that GLAMs and other NGOs donated to us are kept intact and not deleted (whether JPEG versions as separate files are mandated), then any proposal is fine for me. The raw TIFF files should be kept in perpetuity as we are supposed to be reliable partners of various GLAMs that Wikimedians partnered for many years. JWilz12345 (Talk|Contrib's.) 03:40, 5 August 2024 (UTC)
- As long the original files are not being deleted, I am not against it but. But the question is if it is necessary in every case, and some already have JPEG copies :) --PantheraLeo1359531 😺 (talk) 07:04, 5 August 2024 (UTC)
- The next question is that we currently have automatic conversion from tiff to jpg for every tiffs. What benefit would manual duplication do? (cost for manual duplication is that there would be huge number of duplicate files which metadata would be needed to updated, keep in sync etc. It also multiplies the edits done to the files which user are seeing etc. --Zache (talk) 07:12, 5 August 2024 (UTC)
- As long the original files are not being deleted, I am not against it but. But the question is if it is necessary in every case, and some already have JPEG copies :) --PantheraLeo1359531 😺 (talk) 07:04, 5 August 2024 (UTC)
- @Jmabel: ah, then that's better. I have striked my comment and vote. As long as the original raw TIFF files that GLAMs and other NGOs donated to us are kept intact and not deleted (whether JPEG versions as separate files are mandated), then any proposal is fine for me. The raw TIFF files should be kept in perpetuity as we are supposed to be reliable partners of various GLAMs that Wikimedians partnered for many years. JWilz12345 (Talk|Contrib's.) 03:40, 5 August 2024 (UTC)
- @JWilz12345: You seem to be opposing some proposal other than the one being made. To quote from the original post, "Proposed solution is to convert the TIF file to JPG and upload as such, copy all information, and make both files cross reference each other." Your objection seems to presume that the TIFF would be delete, but nothing of the sort is being proposed. - Jmabel ! talk 03:16, 5 August 2024 (UTC)
- Oppose automated. Likely to cause confusion, because how would we link the JPEG version? We could end up either massively overemphasising the JPEG. For instance, File:Negro drinking at "Colored" water cooler in streetcar terminal, Oklahoma City, Oklahoma by Russell Lee - Original.tiff links a restored version as a JPEG, but lacks an exact copy as JPEG. I suspect bots would be tempted to use a gallery, as in File:"... American Army Engineer task force in Liberia find themselves in a land from which their ancestors came. Wash day an - NARA - 531144.tif - but that gives a lot more emphasis to a copy with literal film edges over the featured picture. Gallery links are kind of terrible, as they often resolve to something like TIFF: 5040x3300 JPEG 5040x3300 JPEG 5025x3295 PNG 5025x3295 - that doesn't give anything like a useful navigation.
- The only way I'd support it is if it was a de-emphasised templated link. Nothing as prominent as {{Extracted image}}, more on the lines of:
- It really needs to be minimally disruptive. Adam Cuerden (talk) 07:38, 5 August 2024 (UTC)
- Another comment: I spend a lot of time, as a human in the loop, adding sensible metadata to image files. Any bot'ed activity can only do this badly and vary probably contribute to at least some misleading information. RobbieIanMorrison (talk) 11:25, 5 August 2024 (UTC)
- Oppose TIFF is the better, lossless format, and usually, the automated JPEG thumbnail generation from TIFF works. You can download any TIFF file in various sizes as JPEG from Commons. There are some issues with the thumbnail generator, but these mean that the thumbnail generator should be fixed. I don't see a need to flood Commons with JPEG duplicates of TIFF files. Gestumblindi (talk) 12:32, 5 August 2024 (UTC)
- Oppose, including per Gestumblindi. -- Ooligan (talk) 19:10, 8 August 2024 (UTC)
Comment One thing that is unclear to me is why the current thumbnail links are not enough? Is there some technical aspect that needs to be fixed, or are the current links too hard to find or understand what they do? From a technical perspective, it should be a server-side task to generate jpeg versions or download links to jpegs automatically instead of duplicating photos manually. Mediawiki already does that, so I am asking what you think is currently failing and what should be done to fix it. --Zache (talk) 16:53, 12 August 2024 (UTC)
Semi-protection on the Village Pump?
I see that the Village Pump is now semi-protected, which strikes me as quite inappropriate. Yes, vandalism is a pain, but this is the Village Pump, where users, including new users and IPs, should be able to come to start or participate in a discussion.--Prosfilaes (talk) 17:40, 3 August 2024 (UTC)
- @Prosfilaes: I think you are right about this. @A.Savin: Please reconsider. Per this log entry 13:45, 22 June 2024 (UTC), you changed protection to "Edit=Allow only autoconfirmed users" for six months. If vandalism here is such a problem, then we just need more Admins to patrol it. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:33, 4 August 2024 (UTC)
- I recall that I had the bad idea to revert vandalism here myself .. rather than wait for an admin to do so and apply semi-protection. Agree that it could have been done for a shorter period, but most newbie questions are better on Help Desk. Maybe we should just add a notice for that. Enhancing999 (talk) 13:26, 4 August 2024 (UTC)
- @Enhancing999: Some header tweaking may do the job. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:54, 4 August 2024 (UTC)
- I wouldn't even call it "vandalism" here. This is not an article, but a talk page: there is nothing to vandalize. Inappropriate comments that are out of place should be removed, but they are written in his/her own name by the person who writes them: there is no visible wrong information. MGeog2022 (talk) 14:07, 4 August 2024 (UTC)
- Diff. Enhancing999 (talk) 14:22, 4 August 2024 (UTC)
- Certainly, sorry: I wrote too quickly. MGeog2022 (talk) 14:25, 4 August 2024 (UTC)
- Perhaps new or unregistered users could be restricted to adding comments and editing their own comments, if that's possible. MGeog2022 (talk) 14:27, 4 August 2024 (UTC)
- Is it possible to add page protection so only logged-in users can edit, even if the account is new? This seems like the most reasonable course of action to me as well. ReneeWrites (talk) 20:27, 4 August 2024 (UTC)
- That sounds reasonable :) MedivalNerd (talk) 20:45, 14 August 2024 (UTC)
- Is it possible to add page protection so only logged-in users can edit, even if the account is new? This seems like the most reasonable course of action to me as well. ReneeWrites (talk) 20:27, 4 August 2024 (UTC)
- Perhaps new or unregistered users could be restricted to adding comments and editing their own comments, if that's possible. MGeog2022 (talk) 14:27, 4 August 2024 (UTC)
- Certainly, sorry: I wrote too quickly. MGeog2022 (talk) 14:25, 4 August 2024 (UTC)
- Diff. Enhancing999 (talk) 14:22, 4 August 2024 (UTC)
- I wouldn't even call it "vandalism" here. This is not an article, but a talk page: there is nothing to vandalize. Inappropriate comments that are out of place should be removed, but they are written in his/her own name by the person who writes them: there is no visible wrong information. MGeog2022 (talk) 14:07, 4 August 2024 (UTC)
- @Enhancing999: Some header tweaking may do the job. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:54, 4 August 2024 (UTC)
- I recall that I had the bad idea to revert vandalism here myself .. rather than wait for an admin to do so and apply semi-protection. Agree that it could have been done for a shorter period, but most newbie questions are better on Help Desk. Maybe we should just add a notice for that. Enhancing999 (talk) 13:26, 4 August 2024 (UTC)
- This is the new normal, instead of doing their job they'll just ban everybody from editing, like they did with overwriting files. Yilku1 (talk) 18:51, 7 August 2024 (UTC)
- Can we have it back? Non admins are now revert warring with Ips Enhancing999 (talk) 07:47, 17 August 2024 (UTC)
- Done I semi-protected it again, as per [1]. Yann (talk) 07:55, 17 August 2024 (UTC)
August 04
Further dissemination of Wikimedia Commons Atlas of the World needed
I have the feeling that Wikimedia Commons Atlas of the World is barely known among Wikipedia or even Commons regular visitors. Its quality can certainly be improved, but the first step to achieve that is that it is known enough. If it was an independent project (Wikiatlas), no doubt it would be much more known and used (and improved). There's no need to create a new independent project, but I think it should be given more own character, and find a way to make Wikimedia and Commons users who are looking for maps, aware of its existence. MGeog2022 (talk) 14:17, 4 August 2024 (UTC)
- Maybe it would work better as a separate project. I'm not really convinced of the usefulness of gallery namespace in general. Enhancing999 (talk) 14:25, 4 August 2024 (UTC)
- Yes, but it would need a lot of WMF involvement and devote resources to it. I'm not too optimistic about it. I am convinced that there can be other ways to give it visibility.
- I'm not really convinced of the usefulness of gallery namespace in general: I don't agree with that, unless gallery namespace is split in several ones, for different types of galleries. Surely there are lots of galleries that do not add anything, but others, for example, galleries about cities, allow you to see things you could not see in Wikipedia or other wikis, including the hypothetical future atlas. MGeog2022 (talk) 14:36, 4 August 2024 (UTC)
- I wonder how many galleries of locations consist of less than 10 pictures all taken more than 10 years ago. This despite there being dozens of other images available. Enhancing999 (talk) 14:39, 4 August 2024 (UTC)
- Many galleries about sufficiently important cities are not bad (photos being some years old does not have to be a problem):
- Of course, there are also examples of not so good city galleries (perhaps the perception depends on the size and country of the cities in which one places the focus):
- MGeog2022 (talk) 14:59, 4 August 2024 (UTC)
- Rennes seems to be mostly more than 10 years old. 2008?
- Old isn't a problem as such, but it just makes it likely that the gallery isn't representative any more.
- Obviously, you could consider any image as relevant if you just want a visual list of subtopics. Enhancing999 (talk) 01:36, 5 August 2024 (UTC)
- The lack of scope or a point to a lot of galleries is the main problem with them IMO. They don't really well as dump for random images of a large subject area, but then the reverse is also true if the gallery just exists to recreate a couple of images from a near empty category. So there really needs to be a clear purpose, direction, and theme for them to work. --Adamant1 (talk) 02:54, 5 August 2024 (UTC)
- Old isn't a problem as such, but it just makes it likely that the gallery isn't representative any more.: to see city landmarks, perhaps any 21st Century photo is good enough. But it is a symptom that nobody cares about the gallery, and obviously this lack of interest is a very bad sign. See my comment below: what I propose for the Atlas may be a solution for other gallery pages as well. MGeog2022 (talk) 09:50, 5 August 2024 (UTC)
- I wonder how many galleries of locations consist of less than 10 pictures all taken more than 10 years ago. This despite there being dozens of other images available. Enhancing999 (talk) 14:39, 4 August 2024 (UTC)
I have long felt that the gallery capability is potentially very valuable and tremendously underutilized. A few examples of ones I've done: Places of worship in Seattle, Romanian Orthodox churches in Bucharest, Pioneer Square Park. - Jmabel ! talk 19:47, 4 August 2024 (UTC)
- I totally agree. For example, I created this gallery page to show the map sheets organized in a comprehensive way. Looking at the category to which they belong doesn't provide a good general view of the map series.
- Returning to the problem with some galleries, perhaps some of them are not necessary at all, but others just need more dissemination, which is the same problem Wikimedia Commons Atlas of the World has. If there was an easy way to navigate galleries, with a clear hierarchy, things would be better. Galleries are to be seen as a means, not an end in themselves. Perhaps a solution would be that Commons main page linked some special important galleries (such as Atlas of the World, and others, let's say paintings, galleries of cities, etc), that serve as a starting point to continue navigating gallery pages. MGeog2022 (talk) 09:44, 5 August 2024 (UTC)
- In Commons main page: "If you are browsing Commons for the first time, you may want to start with Featured pictures, Quality images, Valued images or Featured media.". Why not also some special root galleries? Content section below that links to some root categories, perhaps there could be more of them there, and also some important galleries that allow navigating to many other gallery pages. MGeog2022 (talk) 09:54, 5 August 2024 (UTC)
- Returning to the true subject of this discussion, I think that Atlas of the World (perhaps also more galleries) should be linked from Commons main page. Can this be done? What do you think about it? MGeog2022 (talk) 08:40, 6 August 2024 (UTC)
- Main_cities_of_Spain_at_MTN50_first_digital_edition can work indeed, as it doesn't need maintenance.
- Similarly the 1866 map at Maps_of_France#Historical_maps.
- Dynamic lists are another possibility: Streets in Fresnes (Val-de-Marne).
- Even in Wikipedia articles not edited on a daily basis, it can be worth comparing the current illustrations with what's available here. Sometimes all illustrations date back from the time the article was created. Enhancing999 (talk) 10:05, 5 August 2024 (UTC)
- Yes, that's a problem even with text content in Wikipedia: once the subject is well covered, not much care is taken to update it. On the other hand, this probably is a lesser problem than the opposite: the tendency to replace all existing content by a new one created from scratch, in cases where it is no needed at all. In any case, as you said, the problem is not unique to Commons galleries (but the more dissemination they have, the lower the risk of this occurring). MGeog2022 (talk) 10:18, 5 August 2024 (UTC)
- It doesn't really happen when users go directly to the categories and look there. Enhancing999 (talk) 10:20, 5 August 2024 (UTC)
- Yes, galleries that only exist to replicate a category make no sense. But many others, even if they only have a subset of the images in the category, help to present them in a structured way, or to focus in the most important ones (if the category has many hundreds of elements, or many subcategories, nobody would view all of them, or be easily able to find the most important ones; good galleries fulfill this, but the matter is to have good galleries and keep them updated). MGeog2022 (talk) 10:30, 5 August 2024 (UTC)
- It doesn't really happen when users go directly to the categories and look there. Enhancing999 (talk) 10:20, 5 August 2024 (UTC)
- Yes, that's a problem even with text content in Wikipedia: once the subject is well covered, not much care is taken to update it. On the other hand, this probably is a lesser problem than the opposite: the tendency to replace all existing content by a new one created from scratch, in cases where it is no needed at all. In any case, as you said, the problem is not unique to Commons galleries (but the more dissemination they have, the lower the risk of this occurring). MGeog2022 (talk) 10:18, 5 August 2024 (UTC)
- In Commons main page: "If you are browsing Commons for the first time, you may want to start with Featured pictures, Quality images, Valued images or Featured media.". Why not also some special root galleries? Content section below that links to some root categories, perhaps there could be more of them there, and also some important galleries that allow navigating to many other gallery pages. MGeog2022 (talk) 09:54, 5 August 2024 (UTC)
- I like gallery pages, use them often. I also made some gallery pages, see an overview on my user page. My remarks for this discussion:
- Indeed, they need to have a clear purpose, direction, and theme. The purpose of gallery pages can be found on Commons:Galleries: "to present readers with a structured and meaningful collection of the media found here on Wikimedia Commons." Themes can be endlessly: navigating within a big category, with links to subcategories like Headgear; an impression of how something looks like, like a populated place or a landscape; an overview of the works of an artist; an overview of the live of a famous person.
- If the images in a gallery page are old or otherwise not good enough, you can always replace them with more recent or better ones. This is a wiki, so everybody may contribute, also to existing gallery pages. Can we mark a gallery page with something like: This gallery page needs some TLC (and give the reason why it should have TLC)?
- Navigation: see Category:Gallery pages. The problem is, that gallery pages often lack at least one of its subcategories. Cause may be: in the past the rule was to add either a topic OR a gallery category. Even the current text in Commons:Galleries only says that you should add the category with the same name (so a topic category) and does not say anything about Category:Gallery pages. I would like to make it a rule that a gallery page always has to be put into at least two categories: one topic and one gallery category.
- Agree: galleries that only exist to replicate a category make no sense, or only contain a few files. I see too many gallery pages that are disappointing, and where the focus of the creator certainly was not to show a meaningful collection of media. Can we make it a rule, one way or another, that a gallery page should either be about a very large category (200+ files) or about at least a couple of categories (subcategories included)? Because I see too many categories with only a few (1-3) files, but I have no good tool to address that.
- Perhaps a reward system for good quality gallery pages, just like for photos? Perhaps revive Commons:Featured galleries? That would also make it easier to choose from if links to galleries are placed on the main page of Commons.
- JopkeB (talk) 18:22, 6 August 2024 (UTC)
- I don't think that "a gallery page should either be about a very large category (200+ files) or about at least a couple of categories" is a particularly good rule. One of the examples I gave above (Pioneer Square Park) would be useful even if those were the only images in that category. Similarly, I think, for Seattle and the Orient: even if that book were a little smaller, it's a good way to handle a book. - Jmabel ! talk 21:39, 6 August 2024 (UTC)
- We can discuss the numbers, my proposal is just a starting point. I want to get rid of all those disappointing gallery pages, that do not have any added value, and to have a tool to address that. Category:Pioneer Square Park (Seattle) has also seven subcategories, that is enough for me. JopkeB (talk) 07:13, 7 August 2024 (UTC)
- I think that any rule should be applied to the gallery itself, not to the category or categories to which the included files belong. If a gallery presents a number of files in a structured way, including good descriptions, etc., there is no reason to remove it. If a gallery shows all or almost all of the files of a category that includes not many files, and doesn't show any information that isn't in the file names of the shown files, or doesn't present them in any particular structured way, or if the gallery includes, let's say, only 1 or 2 files and there isn't a special reason to have it, the gallery could well be deleted. MGeog2022 (talk) 13:02, 7 August 2024 (UTC)
- For example, just showing the names/descriptions of all the files in a category in more than 1 language (file name can only be in one language), can be a good reason to have a gallery in some cases. The existence of barely viewed galleries, by itself, causes no harm to anyone. MGeog2022 (talk) 13:09, 7 August 2024 (UTC)
- That is a good point, I did not think of that. But then there should be a note in the gallery page with this reason, to prevent misunderstanding. JopkeB (talk) 14:29, 7 August 2024 (UTC)
- The existence of barely viewed galleries, by itself, causes no harm to anyone. @MGeog2022: As far as I know there are no metrics for how many views certain galleries get. Assuming there's some that have either no or extremely low views it's still a time suck maintaining them and just makes it that much harder for people to finding good galleries. Look at it like a museum with near infinite space that we are custodians of. To many niche, half thought out exhibits just detracts from educating our costumers and puts us in a position where we are wasting more time on dusting off or organizing things our costumers don't care about to begin with. Instead of building exhibits that people are actually interesting in and get educational value out of.
- For example, just showing the names/descriptions of all the files in a category in more than 1 language (file name can only be in one language), can be a good reason to have a gallery in some cases. The existence of barely viewed galleries, by itself, causes no harm to anyone. MGeog2022 (talk) 13:09, 7 August 2024 (UTC)
- I think that any rule should be applied to the gallery itself, not to the category or categories to which the included files belong. If a gallery presents a number of files in a structured way, including good descriptions, etc., there is no reason to remove it. If a gallery shows all or almost all of the files of a category that includes not many files, and doesn't show any information that isn't in the file names of the shown files, or doesn't present them in any particular structured way, or if the gallery includes, let's say, only 1 or 2 files and there isn't a special reason to have it, the gallery could well be deleted. MGeog2022 (talk) 13:02, 7 August 2024 (UTC)
- We can discuss the numbers, my proposal is just a starting point. I want to get rid of all those disappointing gallery pages, that do not have any added value, and to have a tool to address that. Category:Pioneer Square Park (Seattle) has also seven subcategories, that is enough for me. JopkeB (talk) 07:13, 7 August 2024 (UTC)
- I don't think that "a gallery page should either be about a very large category (200+ files) or about at least a couple of categories" is a particularly good rule. One of the examples I gave above (Pioneer Square Park) would be useful even if those were the only images in that category. Similarly, I think, for Seattle and the Orient: even if that book were a little smaller, it's a good way to handle a book. - Jmabel ! talk 21:39, 6 August 2024 (UTC)
- At least for me 99% of my time on here is acting as a glorified janitor. I much rather be uploading images and creating eductional exhibits for people. But there's just to much cleaning and reorganizing that needs to be done in most areas to even get to that point. Be it galleries, categories, or whatever, but the issue is particularly bad with galleries. --Adamant1 (talk) 04:14, 8 August 2024 (UTC)
- @Adamant1, in any gallery page, you can be how many views per day it has at "History -> Pageviews Analysis".
- I'm not saying that having galleries with few/almost none views is good, what I wanted to say is that content in Commons or any other Wikimedia project is not valued according to how many views it has. If for whatever reason people do not usually look at a well-done wiki page, it isn't a reason at all to propose its deletion. MGeog2022 (talk) 10:03, 8 August 2024 (UTC)
- @MGeog2022: Thanks for the info. I wasn't aware that was an option. You make a good point, but I do think we are ultimately here to create things other people will see and get value out of. Not to say we should delete everything that has a low view count either. I think there's a line with galleries in particular where deletion is justified if it both has extremely low views and is badly designed without a chance of salvaging it though. But I have no issue with an extremely well designed gallery that also happens to have low viewer numbers for whatever reason either. Something like reviving Commons:Featured galleries would certainly help with that. --Adamant1 (talk) 10:45, 8 August 2024 (UTC)
- Yes, and is badly designed is the point I was referring to. If it has low views, it may not be worth improving the gallery in those cases. MGeog2022 (talk) 10:51, 8 August 2024 (UTC)
- @MGeog2022: Thanks for the info. I wasn't aware that was an option. You make a good point, but I do think we are ultimately here to create things other people will see and get value out of. Not to say we should delete everything that has a low view count either. I think there's a line with galleries in particular where deletion is justified if it both has extremely low views and is badly designed without a chance of salvaging it though. But I have no issue with an extremely well designed gallery that also happens to have low viewer numbers for whatever reason either. Something like reviving Commons:Featured galleries would certainly help with that. --Adamant1 (talk) 10:45, 8 August 2024 (UTC)
- At least for me 99% of my time on here is acting as a glorified janitor. I much rather be uploading images and creating eductional exhibits for people. But there's just to much cleaning and reorganizing that needs to be done in most areas to even get to that point. Be it galleries, categories, or whatever, but the issue is particularly bad with galleries. --Adamant1 (talk) 04:14, 8 August 2024 (UTC)
- Reviving Commons:Featured galleries would be a good thing, as it would encourage improving galleries in general. But, aside from that, I think that special galleries, or rather, systems of galleries, such as the Atlas of the World (perhaps even there are no more than this, but others such as city galleries could be organized in a similar way), that are like a project in themselves, deserve a direct link from Commons main page. MGeog2022 (talk) 11:49, 7 August 2024 (UTC)
- It's kind of a side thing but we should really create a guideline beyond Commons:Galleries (which at least IMO is to focused on the technical) that lays out what makes a "good" gallery and provides some standard for them. I'm not sure it's possible to, or worth, encouraging people to improve galleries in general without clear standards for what makes one good to begin with though. --Adamant1 (talk) 15:23, 8 August 2024 (UTC)
- Atlas of the World deserves a direct link from Commons main page: what do you think about that? If this view is shared by others, how is Commons main page updated (for example, I can't edit it, even having more than 1,000 edits in Commons, and obviously there is a good reason for it)? MGeog2022 (talk) 11:16, 10 August 2024 (UTC)
- As a lover of maps in Commons, I stumbled regularly across these gallery pages, but the lack of curation let me ignore them completely, and I don't think I will change my attitude. It takes so much effort to categories maps properly (and the category system is may more dynamic than galleries), and we have so many ten thousand maps that are uncategorized (so not even linked to their subject), that picking a the nicest maps to showcase the subject in a dedicated Atlas-gallery-page seems like wasted effort to me. Sorry. --Enyavar (talk) 12:31, 10 August 2024 (UTC)
- @Enyavar, thanks for your work categorizing maps, I wasn't aware of this category. I'm struck by the fact that people upload maps without any information at all (it's more likely to happen with photos, but with maps or other publications it's really striking).
- If the Atlas was more known, it would be in a better state for sure. But in any case, I agree that many maps aren't and won't never be in a gallery, so perhaps Category:Maps itself could be linked from Commons main page, as the best "atlas" that we can offer to users. MGeog2022 (talk) 14:53, 10 August 2024 (UTC)
- To be more precise, both maps category and Atlas of the World are already linked from main page, but they are hidden by default inside "By type -> Images". I think this should be restructured to make them more visible. They are at the same level as photos, diagrams or drawings, but an Atlas (and we could consider Maps category also as such) isn't the same as millions of photos without a defined subject, it's something whose presence should be more visible. I think they (Atlas of the World and maps category) should be directly in "Content - by topic", probably as a new entire topic to be added to Nature, Science etc. How could this change be achieved? MGeog2022 (talk) 15:02, 10 August 2024 (UTC)
- I created this proposal for the change, to be voted. On the other side, I added a link to the Atlas of the World at Atlas English Wikipedia article, in the section External links -> Online atlases, in an effort to make it a bit better known MGeog2022 (talk) 12:07, 13 August 2024 (UTC)
- To be more precise, both maps category and Atlas of the World are already linked from main page, but they are hidden by default inside "By type -> Images". I think this should be restructured to make them more visible. They are at the same level as photos, diagrams or drawings, but an Atlas (and we could consider Maps category also as such) isn't the same as millions of photos without a defined subject, it's something whose presence should be more visible. I think they (Atlas of the World and maps category) should be directly in "Content - by topic", probably as a new entire topic to be added to Nature, Science etc. How could this change be achieved? MGeog2022 (talk) 15:02, 10 August 2024 (UTC)
- I Support utilizing gallery pages more often. I also love galleries and contributed on gallery pages, including atlas pages. Sbb1413 (he) (talk • contribs • uploads) 12:46, 14 August 2024 (UTC)
August 07
Any idea what should be in there? It looks like almost everything "needs updating". Shouldn't that be the exception? Enhancing999 (talk) 15:18, 7 August 2024 (UTC)
- You put files in there that track statistical trends and are meant to be used in general Wikipedia articles (vs. articles covering a specific moment in time). A cursory glance tells me lots of files in that category don't belong there, though, like maps tracking hurricane paths that took place years ago. ReneeWrites (talk) 17:28, 7 August 2024 (UTC)
- I think a substantial part of the problem is the {{Hurricane season auto track map}} template, which automatically adds {{current}} to the file page by default. Omphalographer (talk) 17:45, 7 August 2024 (UTC)
- I updated the template to limit it to the current year, but that may just be a small part.
- Another 101,591 are Australian timeseries with User:99of9/ABS-graph or similar (which seem reasonable). [2] Enhancing999 (talk) 13:07, 8 August 2024 (UTC)
- I made a subcategory for the Australian stuff and cleared out some of the hurricane maps. Updating still takes some time, but the content seems much more reasonable now. Thanks for your input. Enhancing999 (talk) 14:10, 8 August 2024 (UTC)
- The bulk of the Australian ones are now in a subcategory. To look at files after the remaining ones, use filefrom=ABS1.
- [[:Category:Files that need updating (drugs)|Drugstats] seems to be another group (ca. 1000 files). Then COVID-19 (maybe this could be removed entirely).
- I fixed a few random ones and listed File:2016 DNC Primary Map.png for deletion. Enhancing999 (talk) 11:38, 9 August 2024 (UTC)
- Would it be useful to create a new subcategory for "files which should be kept updated as the facts change" (provisional name)? An example would be File:Metrication by year map.svg - it's possible that one of the three remaining countries will go metric, requiring an update to the map, but the map doesn't "need updating" other than that. There's a lot of other files, particularly maps, which are in a similar position. Omphalographer (talk) 20:54, 10 August 2024 (UTC)
- @Omphalographer: how is this different from using {{Current}}? Or do you want an particular value there for "interval" to have a side effect? - Jmabel ! talk 23:12, 10 August 2024 (UTC)
- Maybe by using {{current|interval=on change}} after creating Category:Files_that_need_updating on change, even if "on change" isn't an actual interval? Enhancing999 (talk) 07:50, 11 August 2024 (UTC)
- Would it be useful to create a new subcategory for "files which should be kept updated as the facts change" (provisional name)? An example would be File:Metrication by year map.svg - it's possible that one of the three remaining countries will go metric, requiring an update to the map, but the map doesn't "need updating" other than that. There's a lot of other files, particularly maps, which are in a similar position. Omphalographer (talk) 20:54, 10 August 2024 (UTC)
- I think a substantial part of the problem is the {{Hurricane season auto track map}} template, which automatically adds {{current}} to the file page by default. Omphalographer (talk) 17:45, 7 August 2024 (UTC)
Documentation of Template:Current
I notice that the parameters that are defined in Template:Current/doc fail to show up in the resulting documentation and that parameter "subset" is undocumented. Normally I'd try to fix the latter, but the former tells me things are broken here and this should be taken on by someone more experienced with wiki templating than I am. Jmabel ! talk 23:22, 10 August 2024 (UTC)
- Noticed that too. I had tried, but couldn't figure it out so I added the list of parameters and two samples (interval and subset). Easiest might be to edit templatedata. Enhancing999 (talk) 18:03, 11 August 2024 (UTC)
August 08
Good news: Cat-a-lot works again like a charm!
For who likes to work with Cat-a-lot: since the beginning of this year there were problems. But now it works well again, also for moving/copying subcategories that have subcategories themselves. (See MediaWiki_talk:Gadget-Cat-a-lot.js#Problems_categorizing_category_pages for more information.) I now can start to clean up my list with postpones jobs because of this problem. JopkeB (talk) 03:37, 8 August 2024 (UTC)
- It is extremely useful for category maintainers like me. Sbb1413 (he) (talk • contribs • uploads) 12:29, 8 August 2024 (UTC)
- It's nice to see something on here get fixed for once lol. --Adamant1 (talk) 14:53, 8 August 2024 (UTC)
- It does. Awesome. Enhancing999 (talk) 18:03, 11 August 2024 (UTC)
Bangladesh files in West Bengal
While categorizing the files related to Category:Bangladesh and Category:West Bengal, I found that Beauty of my second home.jpg was categorized under WB. Upon closer inspection, I found that the college ("second home") is in Rajshahi, Bangladesh. I had also seen some Bangladesh files in WB categories before, and I had moved them to appropriate Bangladesh categories. So why do Bangladesh files get categorized under WB categories? Sbb1413 (he) (talk • contribs • uploads) 12:33, 8 August 2024 (UTC)
- Why are you asking this here instead of on the user talk page of the person who added the category? Enhancing999 (talk) 12:38, 8 August 2024 (UTC)
- Oh, thank you. I'm asking the user instead. I have posted it here since this is a recurring phenomenon. Sbb1413 (he) (talk • contribs • uploads) 12:41, 8 August 2024 (UTC)
- It's hard to give a general answer with just a single file. Possibly it's something similar that happens at Germany: anything in German might end up there. Enhancing999 (talk) 13:29, 8 August 2024 (UTC)
- Oh, thank you. I'm asking the user instead. I have posted it here since this is a recurring phenomenon. Sbb1413 (he) (talk • contribs • uploads) 12:41, 8 August 2024 (UTC)
- It's worth to note that Bangladesh was known as East Bengal from 1947 until 1955, when it was renamed East Pakistan, and then in 1971 (year of independence) to Bangladesh. Perhaps this may have some connection to it. MGeog2022 (talk) 11:23, 11 August 2024 (UTC)
- Yes, the British-era province of Bengal was split into West Bengal and East Bengal in 1947. According to my analysis, the main reason of such miscategorization is probably the fact that the Bengali language is used in both Bangladesh and West Bengal. Sbb1413 (he) (talk • contribs • uploads) 12:45, 11 August 2024 (UTC)
Add "Upload file" link for mobile?
Hello friends. Today at a conference I was helping an iOS user debug a poor quality app he was using to upload files to Commons. The app was bad enough that we started looking for alternative ways to upload files, and I had him try uploading files through his iOS Safari browser instead. He opened Commons in his browser and there was no upload link, which surprised me. So I created phab:T372078 and wrote a patch to add "Upload file" to the left menu of the Minerva (mobile) skin. Clicking on it takes you to Special:UploadWizard.
When I went to go get this patch merged, someone told me that this "Upload file" link might not be wanted because it would increase uploads of unwanted images. The implication was that mobile editors have a tendency to upload images that are inappropriate for Commons. So I'd like to check with the community and see how y'all feel about adding an "Upload file" link for mobile editors. Thoughts? If this is a bad idea I will abandon my patch. Thanks. –Novem Linguae (talk) 20:28, 8 August 2024 (UTC)
- We live in an age where almost everyone surfs the internet on a mobile device most of the time, almost every website is very specifically designed around mobile devices, and most of the time online services request people to download their apps in Google Play or similar marketplaces. Yet, for whatever reason Wikimedia websites aren't just mobile unfriendly, they are mobile hostile. What's worse is that this laptop-centric and desktop-centric thinking actively excludes the vast majority of people from developing countries, I've met plenty of rural Filipino men and women in their 20's this year that have never even seen a laptop. How can we expect these people to contribute free educational media if their browser specifically tells them that this website is only for consuming and not producing? It's time to get rid of these antiquated restrictions on mobile users. I think that we might have to lobby the Wikimedia Foundation (WMF) to force their developers to edit and contribute at least two (2) whole weeks a year exclusively on mobile devices or hire engineers that only use mobile devices to contribute so they can get some valuable feedback, because they have been ignoring mobile users for years. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:51, 8 August 2024 (UTC)
- Oppose It seems like a lot of COPYVIO comes from screenshots on mobile. Do we really want to make it worse by allowing people to upload directly from their phones? Probably not. It looks like we're already going to block cross project uploads for the same reason and I don't see why we should allow mobile users to upload junk in mass while not allowing people from Wikipedia to do the same. --Adamant1 (talk) 00:39, 9 August 2024 (UTC)
- @Adamant1 Please provide a link where there is a proposal that is "... going to block cross process project uploads ..." Thank you, -- Ooligan (talk) 07:14, 9 August 2024 (UTC)
- @Ooligan: Check out Commons:Village_pump/Proposals#Deactivate_cross-wiki_uploads_for_new_users. Technically it's to block uploads from people who don't have special rights but I don't think that negates my point. As it's still a restriction on making it easier for random people from uploading images to Commons in an area that leads to a massive amount of COPYVIO. Although we could restrict this to certain users or something but I'd still be against it because at the end of the day "confirmed" is a pretty low bar and it would kind of defeat the purpose anyway. --Adamant1 (talk) 07:33, 9 August 2024 (UTC)
- I feel like a big part of the problem with cross-wiki uploads was that the tool encouraged users to do the wrong thing, and thus they did indeed do the wrong thing. That is, the real issue was not that it was "mobile" it was that that was a bad tool with bad UX. I suspect having an upload link on mobile linking to Special:UploadWizard would not have the same type of problems as the cross-wiki upload tool did. Or at least not to the same degree. Bawolff (talk) 08:58, 9 August 2024 (UTC)
- I do wonder how easy UploadWizard would be to work with on mobile. It's not the most intuitive UI even on desktop. --Adamant1 (talk) 09:59, 9 August 2024 (UTC)
- I feel like a big part of the problem with cross-wiki uploads was that the tool encouraged users to do the wrong thing, and thus they did indeed do the wrong thing. That is, the real issue was not that it was "mobile" it was that that was a bad tool with bad UX. I suspect having an upload link on mobile linking to Special:UploadWizard would not have the same type of problems as the cross-wiki upload tool did. Or at least not to the same degree. Bawolff (talk) 08:58, 9 August 2024 (UTC)
- @Ooligan: Check out Commons:Village_pump/Proposals#Deactivate_cross-wiki_uploads_for_new_users. Technically it's to block uploads from people who don't have special rights but I don't think that negates my point. As it's still a restriction on making it easier for random people from uploading images to Commons in an area that leads to a massive amount of COPYVIO. Although we could restrict this to certain users or something but I'd still be against it because at the end of the day "confirmed" is a pretty low bar and it would kind of defeat the purpose anyway. --Adamant1 (talk) 07:33, 9 August 2024 (UTC)
- @Adamant1 Please provide a link where there is a proposal that is "... going to block cross process project uploads ..." Thank you, -- Ooligan (talk) 07:14, 9 August 2024 (UTC)
- Sure, please add it. I don't think this has anything to do with cross-wiki uploads. Mobile view of Commons is known to be broken. Enhancing999 (talk) 09:33, 9 August 2024 (UTC)
- Cross-wiki uploads is just another example of where people not uploading images directly through the website on desktop can lead to problems. I'm not claiming they are 100% exactly the same though, but there is some is (or would be) similar issues with both IMO. At the end of the day anything other then directly uploading images through Special:UploadWizard on desktop will just lead to more errors and COPYVIO. --Adamant1 (talk) 09:59, 9 August 2024 (UTC)
- This is much needed. The vast majority of original photos today are from phone cameras. We should make it easy to upload. The question about copyright is not really relevant, it is not linked to the skin used. Geraki TLG 12:28, 9 August 2024 (UTC)
- @Geraki: "The vast majority of original photos today are from phone cameras." Are you saying this about photos in the world at large (in which case I agree) or about Commons uploads (in which case my own impression is that you are wrong, and I'd like to see some sort of evidence for that statement). - Jmabel ! talk 15:12, 9 August 2024 (UTC)
- Without neglecting the need to control COPYVIO and not overburden administrators, not allowing uploads from mobile is a discrimination against people with lower income (and it could even be viewed as racial discrimination, since, for example, black South Africans are much less likely to own a computer than white South Africans), and also against older people in most countries (who are much less likely to use a computer, but they usually use a smartphone), so it should be addressed, provided that it is possible to monitor the profile of each new user and easily detect if he/she is going to make inappropriate use. MGeog2022 (talk) 11:10, 10 August 2024 (UTC)
- Alright, I only see one objection so far, and several supports. Should this stay open for a bit longer or can the patch move forward? –Novem Linguae (talk) 12:29, 11 August 2024 (UTC)
- I think we should try this first limited to autopatrolled users, if there are no problems also for autoconfirmed users and if this also works we can open it for all users. If there are problems we step back to the previous limitation. GPSLeo (talk) 12:42, 11 August 2024 (UTC)
- Any patch I make to the Minerva skin needs to be wiki-agnostic. If we are going to add some logic that only applies to Commons, such as checking for permissions before displaying the link, then we might need to look into MediaWiki:minerva.js or a default gadget or something instead of a Minerva patch. –Novem Linguae (talk) 13:26, 11 August 2024 (UTC)
- As long as we no inter wiki user rights checking we can only do this by blocking after clicking on upload what of course is not a really good solution. GPSLeo (talk) 13:41, 11 August 2024 (UTC)
- I didn't realize that anything on VP would constitute a proposal with voting. I expected that this was some people discussing something they would then propose at COM:Village pump/Proposals. I am objecting to this being a mandate to go ahead. There was no one specific proposal here I felt I could vote on. - Jmabel ! talk 16:56, 11 August 2024 (UTC)
- I have to agree with Jmabel here. This should be an actual proposal with voting and last for the normal time frame of one. This being open for three days regardless of where isn't nearly enough to call it approved regardless though. But this is still the wrong venue and format for it either way. --Adamant1 (talk) 10:39, 12 August 2024 (UTC)
- If someone pursues this in the future, what is the correct page, duration, and process, if I may ask? –Novem Linguae (talk) 11:12, 12 August 2024 (UTC)
- Am I missing something or isn't this just a bug? Enhancing999 (talk) 11:16, 12 August 2024 (UTC)
- Anyone? Does Commons have an RFC process somewhere I can read up on? What board should a future RFC about this be posted on? –Novem Linguae (talk) 12:42, 15 August 2024 (UTC)
- Here we go: Commons:Village_pump/Proposals#Proposal:_fix_bug/feature_of_missing_upload_link_in_some_skins/for_some_devices, you can "vote" to fix the bug. Enhancing999 (talk) 12:57, 15 August 2024 (UTC)
- If someone pursues this in the future, what is the correct page, duration, and process, if I may ask? –Novem Linguae (talk) 11:12, 12 August 2024 (UTC)
- As long as we no inter wiki user rights checking we can only do this by blocking after clicking on upload what of course is not a really good solution. GPSLeo (talk) 13:41, 11 August 2024 (UTC)
- Any patch I make to the Minerva skin needs to be wiki-agnostic. If we are going to add some logic that only applies to Commons, such as checking for permissions before displaying the link, then we might need to look into MediaWiki:minerva.js or a default gadget or something instead of a Minerva patch. –Novem Linguae (talk) 13:26, 11 August 2024 (UTC)
August 09
Flickr2Commons
Flickr2Commons appears to be down. Does anyone know what is going on? - Jmabel ! talk 00:32, 9 August 2024 (UTC)
- Hello, @Jmabel. I also noted this continuing issue at the "Technical" page here: Commons:Village pump/Technical#Flickr2Commons tool not working for about 24 hours. I get this message currently-
- * "Wikimedia Toolforge Error"
- * "Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again later."
- * "tools-proxy-8.tools.eqiad1.wikimedia.cloud"'
- It has been about 40 hours. Other Users are apparently using this same tool without any problems. (located on other continents)
- Thanks, -- Ooligan (talk) 06:49, 9 August 2024 (UTC)
- @Jmabel: Not even connecting for me, via Optimum Online in New Jersey, USA, North America. Obviously, I can read and post here. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:16, 9 August 2024 (UTC)
- Via T-Mobile too - "ERR_CONNECTION_ABORTED". — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:18, 9 August 2024 (UTC)
- Then "ERR_NETWORK_IO_SUSPENDED" when I put my laptop into hibernation for transport, and again not connecting via Optimum Online. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:28, 9 August 2024 (UTC)
- Toolforge itself is responding just fine, at best 34ms away over 100 pings. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:48, 9 August 2024 (UTC)
- I created issue 320 for Magnus Manske. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:00, 9 August 2024 (UTC)
- Thank you @Jeff G. -- Ooligan (talk) 21:39, 9 August 2024 (UTC)
- Not loading for me in Australia. Bidgee (talk) 22:21, 9 August 2024 (UTC)
- @Ooligan: You're welcome. Then, I got "Wikimedia Toolforge Error" and "Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again later." from tools-proxy-8.tools.eqiad1.wikimedia.cloud and a page titled "504 Gateway Time-out" with "Webservice request timed out". I updated that issue. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:57, 10 August 2024 (UTC)
- Pinging @GFontenelle (WMF) per Commons:Village pump/Archive/2023/06#Flickr Foundation adopts Flickr2Commons. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:07, 10 August 2024 (UTC)
- ... and we're back to that "Webservice request timed out" error. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:37, 13 August 2024 (UTC)
- Still. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:06, 16 August 2024 (UTC)
- Tagging @Magnus Manske FYI -- DaxServer (talk) 15:49, 14 August 2024 (UTC)
- https://phabricator.wikimedia.org/T372451 M2k~dewiki (talk) 15:56, 14 August 2024 (UTC)
- @M2k~dewiki: "The maintainer doesn't read" Commons talk:Flickr2Commons and "Magnus Manske prefers it if you take tool issues to his Bitbucket." per {{Magnus is not here}} atop that page. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 09:36, 15 August 2024 (UTC)
- @DaxServer: I already pinged him on the 9th per above, to no avail. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 09:38, 15 August 2024 (UTC)
- I wanted to host a copy, but I am constantly get barricaded at finding all the dependencies required. I hope to get it working in case the tool isn't back up soon -- DaxServer (talk) 20:08, 15 August 2024 (UTC)
- I was able to get it up here https://flickr2commons-ng.toolforge.org/ However, it now suffers from now being to read the credentials for Commons DB replica. The code is adjusted accordingly to the tutorial on Wikitech. If someone has an idea why it's not working, please leave me a message 🙏. I'll chat with someone on IRC tomorrow to debug. -- DaxServer (talk) 22:04, 15 August 2024 (UTC)
- I wanted to host a copy, but I am constantly get barricaded at finding all the dependencies required. I hope to get it working in case the tool isn't back up soon -- DaxServer (talk) 20:08, 15 August 2024 (UTC)
- Tagging @Magnus Manske FYI -- DaxServer (talk) 15:49, 14 August 2024 (UTC)
- Still. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:06, 16 August 2024 (UTC)
- Thank you @Jeff G. -- Ooligan (talk) 21:39, 9 August 2024 (UTC)
This is all particularly annoying because Flickypedia is also down. - Jmabel ! talk 22:16, 15 August 2024 (UTC)
- Yeah, that's terrible. --A1Cafel (talk) 04:03, 16 August 2024 (UTC)
- What's the deal with Magnus Manske? Is he just not working on it anymore or something? --Adamant1 (talk) 10:11, 16 August 2024 (UTC)
- @Jmabel, Ooligan, Jeff G., Bidgee, Magnus Manske, M2k~dewiki, and A1Cafel: For the moment, I enabled a copy at https://flickr2commons-ng.toolforge.org/ I cloned Magnus' repo at https://gitlab.wikimedia.org/toolforge-repos/flickr2commons-ng Tests seem okay: https://commons.wikimedia.org/w/index.php?title=Special:RecentChanges&tagfilter=OAuth+CID%3A+9374 -- DaxServer (talk) 10:45, 16 August 2024 (UTC)
UI of Special:UncategorizedCategories has just changed, and in my opinion not for the better. Typeface is larger so less information on screen at once; hovering no longer tells you anything about whether the category has members (just repeats the obvious link, in a popup). I might have been willing to trade off the prior hover behavior for getting red links for categories that are already deleted, but we don't get that, worst of both worlds. [This seems to have been a temporary glitch. Weird. - Jmabel ! talk 20:51, 9 August 2024 (UTC)]
Also, the report is now 34 days old, which is an awfully long time between reports on something where certainly hundreds of the 1500 or so categories listed have already been dealt with. Makes it hard to spot which ones still have work to be done.
Does anyone know what is going on here, and whether there was a reason for these changes, or the now infrequent running of the report? - Jmabel ! talk 19:39, 9 August 2024 (UTC)
- Phab:T369024 it was changed to once a month. However i think part of the change was missing so it might have accidentally been changed to never (its been a long time since i have looked at the system, so i might be mistaken about that and maybe the cron job is just no longer needed or something) Bawolff (talk) 22:23, 9 August 2024 (UTC)
- If this is used regularly to take care of these categories, I think it should run daily or at least every other day.
- Maybe @Marostegui can explain why he had it deactivated how he plans to replace it.
- I don't think there was a community consultation as we had at Commons:Village_pump/Proposals#Request:_delete_"Pages_where_lack_of_wikilinks_indicates_a_problem" for pointless special pages (at Commons). Enhancing999 (talk) 09:56, 10 August 2024 (UTC)
- Performance concerns are not something the community generally gets a say in. Keeping the site running in a healthy matter trumps individual Special pages. The special pages get more costly to run the larger the site gets. Enwiki already has a bunch of these on a delayed schedule, commons just got big enough that it has now become neccesary to switch some of them to once a month. Price of being big. Bawolff (talk) 11:36, 10 August 2024 (UTC)
- I don't think it was live before either. There is a big difference between something running daily and monthly.
- Well, it's a substantial change to the site. One would expect that this is communicated, properly assessed and then a decision is made.
- A query running for 6 minutes seems rather trivial and cheap, at least on a WMF site beyond the early days. Enhancing999 (talk) 11:43, 10 August 2024 (UTC)
- I think it was updated every 6 or 7 days before, which isn't that long between updates but running it four times a month instead of once really couldn't have been that costly. Once a month is kind of worthless regardless though. There should really be a middle ground between not running something like this to much while also not making the time between updates so long that it's unhelpful to doing the task. --Adamant1 (talk) 11:49, 10 August 2024 (UTC)
- I think it was every 3 days previously. I'm not sure where Enhancing999 got 6 minutes from, the query is a lot longer than that according to the phab task. Potentially devs might be open to some compromise (e.g. twice a month) if this is really causing problems, i don't know how they would feel about it but it never hurts to ask. In regards to Jmabel's concern about it being hard to see what has already been done, it would probably be pretty easy to strike out entries that dont fit the criteria the same way some other special pages do. Bawolff (talk) 11:57, 10 August 2024 (UTC)
- It was three days previously. I use it extensively. I've probably fixed several thousand of these in the last 12 months. When the data is over a month out of date, it makes the task much more difficult. Early this year we had this down to 100 or so files. It has now swelled back to over 1500. - Jmabel ! talk 19:23, 10 August 2024 (UTC)
- I think it was updated every 6 or 7 days before, which isn't that long between updates but running it four times a month instead of once really couldn't have been that costly. Once a month is kind of worthless regardless though. There should really be a middle ground between not running something like this to much while also not making the time between updates so long that it's unhelpful to doing the task. --Adamant1 (talk) 11:49, 10 August 2024 (UTC)
- Performance concerns are not something the community generally gets a say in. Keeping the site running in a healthy matter trumps individual Special pages. The special pages get more costly to run the larger the site gets. Enwiki already has a bunch of these on a delayed schedule, commons just got big enough that it has now become neccesary to switch some of them to once a month. Price of being big. Bawolff (talk) 11:36, 10 August 2024 (UTC)
August 10
Dating Monaco postcard
This is certainly not own work, but a scanned old postcard. The railway line was electrified in 1969, but there are other clues. The uploader mentions that this is the 'first' church implying that there is a later church. Unfortunatly there is no French article on the 'Couvent des Carmes' in Monaco.Smiley.toerist (talk) 10:09, 10 August 2024 (UTC)
- I found out that the second building was openend in 2002, so this gives no dating clue (fr:Église Sainte-Thérèse de Monaco).Smiley.toerist (talk) 10:19, 10 August 2024 (UTC)
- 20th century for the photography? Enhancing999 (talk) 10:35, 10 August 2024 (UTC)
- Per the same article, construction of the original church (which is the one we see here I guess) was finished in 1913. --Rosenzweig τ 11:25, 10 August 2024 (UTC)
- If I were to guess the postcard was probably published in the twenties or thirties. Publishers didn't really publish sepia postcards of that quality before then and they were pretty much phased out by the 40s in favor of black and white RPPCs. --Adamant1 (talk) 16:08, 10 August 2024 (UTC)
- When has the green space build over? Space is very precious in Monaco. The entire railway was put underground to gain some space.Smiley.toerist (talk) 20:30, 10 August 2024 (UTC)
Should COM:CSD#G4 include files that has been tagged with {{No permission since}}, deleted after 7 days, and then reuploaded without any permission? Or how to handle such files, such as File:Lawrence Alegwu Ega.jpg? To give it further 7 days feels weird. Jonteemil (talk) 13:17, 10 August 2024 (UTC)
- @Jonteemil: Admins regularly patrol Category:Media missing permission and children, deleting when necessary (presumably under F5). What makes you think pages tagged for speedy deletion under F5 get "further 7 days"? That file already had 7 days. I warned the uploader to stop uploading it. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:41, 10 August 2024 (UTC)
- Okay, let me rephrase. Are files that have been deleted in lack of permission eligible for speedy deletion once they are reuploaded? And if so, under what CSD parameter? Or, alternatively, should they just be retagged with {{No permission since}}? Jonteemil (talk) 16:44, 10 August 2024 (UTC)
- No, there is no need to tag them with "No permission". Please tag them as G4, and they will be speedy deleted. Yann (talk) 16:52, 10 August 2024 (UTC)
- Okay, then COM:CSD#G4 needs to be rephrased. As it is phrased atm it seems it only encompasses files that have been deleted after a DR, not after a PROD (no permission/license/source since), or maybe it's just me who interprets it like so. Jonteemil (talk) 17:38, 10 August 2024 (UTC)
- Your interpretation is correct, IMO. As noted by Jeff G., the deletion can be with F5. -- Asclepias (talk) 18:44, 10 August 2024 (UTC)
- G4 doesn't apply by its terms, IMO. If we think these should be deleted, I think COM:CSD#F5 is a better way to do it than G4. (Indeed, looking again at F5, it might actually not need any changes: "may be given a grace period" does not mean "must", and it was already given one...) —Mdaniels5757 (talk • contribs) 19:04, 10 August 2024 (UTC)
- Okay, then I'll use F5 for these files in the future. Thanks. Jonteemil (talk) 19:06, 10 August 2024 (UTC)
- Okay, then COM:CSD#G4 needs to be rephrased. As it is phrased atm it seems it only encompasses files that have been deleted after a DR, not after a PROD (no permission/license/source since), or maybe it's just me who interprets it like so. Jonteemil (talk) 17:38, 10 August 2024 (UTC)
- No, there is no need to tag them with "No permission". Please tag them as G4, and they will be speedy deleted. Yann (talk) 16:52, 10 August 2024 (UTC)
- Okay, let me rephrase. Are files that have been deleted in lack of permission eligible for speedy deletion once they are reuploaded? And if so, under what CSD parameter? Or, alternatively, should they just be retagged with {{No permission since}}? Jonteemil (talk) 16:44, 10 August 2024 (UTC)
August 11
Template documentation
Parameters are not being correctly displayed on template pages using the {{Documentation}} template (in turn using the {{TemplateBox}} template). This means all templates are showing just "The template takes no parameters." under the Usage section, instead of the table showing the parameters (see {{TemplateBox}} itself for this, as this template has several parameters). I have had multiple users ask about how to use templates I've worked on, due to this missing information. Does anyone know what is going on with this? Josh (talk) 01:48, 11 August 2024 (UTC)
- @Jarekt: Special:Diff/907688459 --Geohakkeri (talk) 10:21, 11 August 2024 (UTC)
- @Geohakkeri and Joshbaumgartner: Thank you for reporting and diagnosing this. I reverted my edit. I do not like Module:Languages's autolang function as it is using different language fallback rules than most of the other pages on Commons, but I do not have time at the moment to debug it. --Jarekt (talk) 15:22, 12 August 2024 (UTC)
- @Jarekt Thanks for tackling this. Hopefully we can still fix the language issue downstream. Josh (talk) 18:41, 12 August 2024 (UTC)
- @Geohakkeri and Joshbaumgartner: Thank you for reporting and diagnosing this. I reverted my edit. I do not like Module:Languages's autolang function as it is using different language fallback rules than most of the other pages on Commons, but I do not have time at the moment to debug it. --Jarekt (talk) 15:22, 12 August 2024 (UTC)
Different Types of Flagmaps
Most flag maps on Wikimedia Commons follow the naming format 'Flag_map_of_Country.' These maps have been created by various contributors, each using different base maps with varying levels of accuracy. Typically, they feature thicker border strokes in the colors of the respective flags. However, I found the inconsistencies across these maps unsatisfactory, so I created my own set of flag maps using OpenStreetMap as the base. My maps are highly accurate and consistent, with all borders depicted using black, slightly thinner strokes. So far, I have completed maps for European and Asian countries and plan to expand to other continents. My flag maps follow the naming format 'Country-Flagmap.' I'm writing this to prevent renaming conflicts and to foster consensus among users. Thank you. Kamran.nef (talk) 13:24, 11 August 2024 (UTC)
- (As someone who loves both flags and maps, I’d like to see this kind of hybrid monstrosity relegated to the trashbin of bad ideas. -- Tuválkin ✉ ✇ 18:15, 14 August 2024 (UTC))
Resolving Potential Copyright, Educational Value, and Scope Problems with Media for a Wikibooks Project
Hi there,
I've been building a project for a month on Wikibooks that introduces high school leveled physics explained through a video game. To explain, I have been uploading media from the multiplayer physics browser game Bonk.io to explain real world physical concepts. On Bonk.io, users can publicly create user-generated content, called "maps." This allows for other players to play and modify each other's works freely within the game via a database structure, called the "level select."
Wikibooks Project Link: https://en.wikibooks.org/wiki/Physics_Explained_Through_a_Video_Game
Copyright Concerns
As recently brought to my attention by @Adamant1 (on my talk page), Bonk.io does not currently have a copyright policy for maps. As such, regardless of the fact that the physics engine of the game, BOX2D is freely licensed via a MIT License, many of my uploads for the project potentially violate Wikimedia's copyright policy. With this understanding, I have immediately contacted the developer of the game to see if user-generated content can explicitly be released under the public domain.
With much of the media that I have uploaded for this project, they are partially derived from user-generated content on Bonk.io that was created by another user. Because of the lack of a formal licensing policy for maps, I have notified the other users of whom I had used maps for their permission for others to modify and use their work freely. At this time, I have had confirmation on Discord (messaging website) from several users, comprising the majority of the uploaded content, that they are okay with their work being in the public domain (specifically Creative Commons 0).
However, I am unsure of whether if another individual claims that their work is in the public domain, provided that the database lacks a formal copyright policy, that this is acceptable under Wikimedia's copyright policy as freely licensed content. Secondly, I am unsure of how these individuals can be independently verified by others on Wikimedia such that it is clear that the original publisher of the map on the Bonk.io database has claimed that their work is in the public domain. As such, this alternative method may be problematic.
To note, my goal is to reach a resolution with the existing copyright concerns that exist with my uploads. Ideally, I want to resolve this problem such that my project on Wikibooks remains functional and can grow, even if such a resolution will be time-extensive on my part.
Educational Value Concerns
In addition, I was informed that my existing project may fail to meet the educational value requirement for uploaded media on articles. This is because of concerns on how well the a video game engine can model real world physics and whether it can be realistically used as an educational resource.
To note, I strongly feel that my uploaded media does adequately function as an educational resource for explaining topics in elementary mechanical physics. However, I acknowledge there are limitations of the Bonk.io game and the BOX2D physics engine, including that:
- The content is displayed in a two-dimensional environment.
- Shapes in user-created maps are only solidly colored.
- Automatic lightning and shading is unavailable.
- A limited number of physical concepts are presentable. For example, fluids cannot exist in the game.
As such, this may make the uploaded media as a lower quality resource for general usage on Wikimedia, especially compared to media that exists from more powerful physics simulators, such as Unity or Algodoo. However, it does not impair the ability to use this resource for explaining elementary mechanical physics, in my opinion. This is particularly the case if high quality maps that are specifically designed to model real world situations are used.
Scope Concerns
Finally, I understand that there presently is not a clear policy on Wikibooks on whether video game content can be used to discuss real-world concepts. To note, content that wholly concerns video games, specifically strategy guides, were approved by a consensus on Wikibooks back in 2021.
To my understanding, there has not yet been a discussion on whether video game content can be used to talk about real-world concepts on Wikibooks. Also, I am unaware about any other projects on Wikibooks that have or had existed specifically in this topic area. If needed, I would be more than willing to encourage community discussion on Wikibooks to decide if my project, in regards to its topic, is appropriate on the site.
Questions
- Would the approval of the developer of Bonk.io that uploaded content is under the public domain resolve copyright concerns for using any uploaded media on the database?
- Would approval from individual players that their maps are under the public domain alternatively resolve these concerns?
- If "yes" to Question 2, how can this be done to assure the authenticity of each of these players such that others on Wikimedia Commons can independently verify this?
- Does the current state of some or all of my uploads for the above-mentioned project fall under "Low-quality content that does not add value beyond our existing coverage of the same topic" on Wikimedia Commons, thereby not being realistically useful for an educational purpose?
- Should there be a community discussion on Wikibooks concerning whether my project's topic is appropriate for Wikibooks?
TheMonkeyEatsBananas (talk) 18:09, 11 August 2024 (UTC)
- @TheMonkeyEatsBananas: where you say users have released their content to the public domain on Discord (which I don't use): is that public-facing, and if so can their comments be referenced via a URL? If so, you can cite that in the permission section of the {{Information}} template or other similar template. - Jmabel ! talk 02:39, 12 August 2024 (UTC)
- It would be kind of pointless if content from Bonk.io can't be used in this way to begin with. That would probably be the best way to deal with it if or when the developer ever gets backs to the TheMonkeyEatsBananas and says content from the game is PD or whatever though. --Adamant1 (talk) 02:50, 12 August 2024 (UTC)
- I have already acknowledged to you that it was a misunderstanding of mine that Bonk.io is inherently public domain content. I had made this assumption because its physics engine is under an MIT license. Also, because I have been building this project with others in the Bonk.io community, I uploaded the files in the public domain because I was in regular communication and discussion with each of these users about the project and my intention concerning it.
- Beforehand, I was merely asking for their approval to use their work and/or modify it. I now understand that this is not enough for declaring another person's work under a CC0 - Public Domain license. As such, after you mentioned your concerns to me yesterday, I have contacted all of these users individually to confirm that they are okay with having their work specifically be under a CC0 license.
- With @Jmabel's recommendation, I will provide a citation in the permission section of each file. This will provide a public link such that members of Wikimedia can access and independently verify that each of these players have released their work under a CC0 license. TheMonkeyEatsBananas (talk) 03:17, 12 August 2024 (UTC)
- Thank you for your response. The messages on Discord are public facing and linkable. However, this would require for users to have a Discord account to be able to independently verify. I can include the Information template that you've mentioned and include it on each of the files. TheMonkeyEatsBananas (talk) 03:06, 12 August 2024 (UTC)
- It's a common issue but that's not really how it works with derivatives. The game itself needs to be PD for us to host images or video of content from it. Either that or we need explicit permission to do so from the developer. Its not enough to simply get permission from whomever posted the original images on Discord. --Adamant1 (talk) 03:53, 12 August 2024 (UTC)
- To note, I don't experience with copyright law. As such, I do want to know more about whether the game necessarily needs to be in the Public Domain for any user-generated work to be freely licensed. Could you elaborate on how a person may lose their intellectual property rights if the service they created their user-generated content on lacked any written or implied claim for their work? If they do keep their intellectual property rights, does this instead violate Wikimedia's policy for file uploading?
- To clarify, these are not the people who have posted images of other people's work on Discord. They are the people who have created the user-generated content themselves. Then, these people are confirming that they are publishing this content under a CC0 license (proposed process provided below).
- Proposed independent confirmation process:
- Every user whose work is in the project confirms on a public Discord server (https://discord.gg/QKrdE45y6h), accessible for anyone with the link and a free Discord account.
- Their confirmation includes:
- A list of their Bonk.io accounts.
- The statement (directly adapted from the CC0 Commons Deed): "I, the copyright holder of this work, hereby publish it under the following license: This media is made available under the Creative Commons CC0 1.0 Universal Public Domain Dedication. The person who associated a work with this deed has dedicated the work to the public domain by waiving all of his or her rights to the work worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law. You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission."
- Videos of the player visibly logged in on each account that they own. All videos include them creating a custom game room and manually scrolling through all of their personally published material on Bonk.io.
- TheMonkeyEatsBananas (talk) 06:29, 12 August 2024 (UTC)
- Videos of the player visibly logged in on each account that they own. See, that's the issue right there. Just because they log into the game as a player doesn't mean they can post images of it here on Commons, let alone that you can, even if those images are released by them or you under a free license. Please read Commons:Screenshots. I'll cite the relevant part of it for you in the next paragraph.
- It's a common issue but that's not really how it works with derivatives. The game itself needs to be PD for us to host images or video of content from it. Either that or we need explicit permission to do so from the developer. Its not enough to simply get permission from whomever posted the original images on Discord. --Adamant1 (talk) 03:53, 12 August 2024 (UTC)
- It would be kind of pointless if content from Bonk.io can't be used in this way to begin with. That would probably be the best way to deal with it if or when the developer ever gets backs to the TheMonkeyEatsBananas and says content from the game is PD or whatever though. --Adamant1 (talk) 02:50, 12 August 2024 (UTC)
- "if you do not own the copyright to a piece of software, you may publish a screenshot under a free license only if all the content shown itself has a free license. If a screenshot contains icons or content that is non-free, it is normally also not free...If all content shown is in the public domain, then the screenshot is also, because there is no creative contribution added when creating a screenshot. This may not be true in all jurisdictions, but holds at least in the U.S.....If the copyright holder(s) (usually the programmers, software company, producer, or broadcaster) do not agree to publish the program under a free license, then screenshots are normally only free if they explicitly license the screenshot (or all screenshots) under a free license."
- Another relevant guideline you could read through is Commons:Derivative works. Although I think Commons:Screenshots and what I quoted from it is the most important thing here. --Adamant1 (talk) 07:20, 12 August 2024 (UTC)
- I understand your concerns with my uploaded contributions. As I've stated when we began discussing a few days ago, you and anyone else have my support with requesting a mass deletion discussion if you feel that it is needed.
- However, I still want to be able to continue my project either on a Wikimedia project or on another community. What options would I have if a consensus is meant where some or all of the media for my project does not follow a freely licensed policy? TheMonkeyEatsBananas (talk) 21:40, 12 August 2024 (UTC)
- You could look for actually freely licensed media that illustrates the same concepts as are in the files that get deleted if any do. That's really your only option. I haven't looked into it but it shouldn't be that hard if your just trying to illustrate basic ideas. --Adamant1 (talk) 01:06, 13 August 2024 (UTC)
- Another relevant guideline you could read through is Commons:Derivative works. Although I think Commons:Screenshots and what I quoted from it is the most important thing here. --Adamant1 (talk) 07:20, 12 August 2024 (UTC)
E.R.C. acronym
At File:Walter Lindsey Avery (1892-1978) biography in History of Ohio State University.png from 1918 I have been able to expand all the acronyms except "E.R.C.", can anyone work out what it meant in 1918? Most of the acronyms were military jargon from WWI. --RAN (talk) 21:06, 11 August 2024 (UTC)
- I know nothing about military history but could it make sense for the acronym to refer to Enlisted Reserve Corps (which I guess is a term of art of some sort)? --Geohakkeri (talk) 21:27, 11 August 2024 (UTC)
- Thanks! I think you got it, it makes sense. I'll add it and if someone finds something more fitting, we can change it. --RAN (talk) 00:02, 12 August 2024 (UTC)
One‑off Creative Commons license on East Side Gallery photograph
The East Side Gallery is located in Berlin. And I am currently contributing to a project that includes one of the graffiti artworks and will be talking to the artist in due course. I recently took a photograph of their artwork and am happy to license it CC‑BY‑4.0 or similar and/or assign copyright to another party. But my photograph is merely a record of that artwork, albeit with the perspective tweaked, barrel distortion removed, and other similar edits. The underlying artwork would remain copyright of the artist. So here is my question.
Should I approach the artist, offer to transfer my copyright in the photograph to them, and then get them to issue that one photograph under CC‑BY‑SA‑4.0 for just that one photograph. That is why I headed my inquiry "one‑off Creative Commons license".
Is this suggestion legally feasible? Or would this one‑time license just leak to all subsequent photographs by all others? (And the East Side Gallery is widely photographed by tourists.) The German copyright act would apply I guess? The artist in question is resident in New Zealand, but I doubt if that is material?
Would be nice to have more visual reference material on Wikipedia. TIA, RobbieIanMorrison (talk) 21:13, 11 August 2024 (UTC)
- Isn't the East Side Gallery a public space, outdoors, in Germany? If so, I'm pretty sure German laws on Freedom of Panorama would mean you don't even need the artist's permission.
- Questions about copyright are usually better asked at Commons:Village pump/Copyright. - Jmabel ! talk 02:45, 12 August 2024 (UTC)
- @Jmabel: Many thanks as always! I know a couple of copyright lawyers in Germany and may take this question up with them. Regarding the subcategory for copyright, I did not realize the little hints on the tab at the top of this page were actually hyperlinks. Sorry. RobbieIanMorrison (talk) 05:07, 12 August 2024 (UTC)
- Academic publication Shtefan (2024) looks current and useful: doi.org/10.2924/EJLS.2024.012. Best, RobbieIanMorrison (talk) 06:11, 12 August 2024 (UTC)
- Noting also Wikimedia policy: Commons:Freedom of panorama/Europe. Best, RobbieIanMorrison (talk) 06:26, 12 August 2024 (UTC)
- And some dedicated case law: Bundesgerichtshof 19 January 2017, case I ZR 242/15 East Side Gallery, (2017) 119 GRUR 390 apparently protected work of art on a remaining section of the Berlin Wall. RobbieIanMorrison (talk) 07:10, 12 August 2024 (UTC)
- More here at footnote 79. RobbieIanMorrison (talk) 07:18, 12 August 2024 (UTC)
- And to point out that the East Side Gallery is under heritage protection (or Denkmalschutz) for some time. The reason I mention this is that the 2017 judgement seems to be related to an absence of permanence (but I am looking into this question further). RobbieIanMorrison (talk) 15:31, 12 August 2024 (UTC)
- Here is an example ("Mauerspringer") that claims a permitted use under article §59 of the German copyright law. I would not bet on that being a correct assessment. RobbieIanMorrison (talk) 16:33, 12 August 2024 (UTC)
- Comment: I will have an opportunity to talk to Gabriel Heimler (see thumbnail image) in the coming weeks. So I need an answer to my original question and will therefore migrate to the copyright track to seek help there. RobbieIanMorrison (talk) 12:09, 13 August 2024 (UTC)
- And to point out that the East Side Gallery is under heritage protection (or Denkmalschutz) for some time. The reason I mention this is that the 2017 judgement seems to be related to an absence of permanence (but I am looking into this question further). RobbieIanMorrison (talk) 15:31, 12 August 2024 (UTC)
- More here at footnote 79. RobbieIanMorrison (talk) 07:18, 12 August 2024 (UTC)
- And some dedicated case law: Bundesgerichtshof 19 January 2017, case I ZR 242/15 East Side Gallery, (2017) 119 GRUR 390 apparently protected work of art on a remaining section of the Berlin Wall. RobbieIanMorrison (talk) 07:10, 12 August 2024 (UTC)
- Noting also Wikimedia policy: Commons:Freedom of panorama/Europe. Best, RobbieIanMorrison (talk) 06:26, 12 August 2024 (UTC)
- Academic publication Shtefan (2024) looks current and useful: doi.org/10.2924/EJLS.2024.012. Best, RobbieIanMorrison (talk) 06:11, 12 August 2024 (UTC)
- @Jmabel: Many thanks as always! I know a couple of copyright lawyers in Germany and may take this question up with them. Regarding the subcategory for copyright, I did not realize the little hints on the tab at the top of this page were actually hyperlinks. Sorry. RobbieIanMorrison (talk) 05:07, 12 August 2024 (UTC)
August 12
Fatal errors when editing
I keep getting a "fatal exception of type Wikimedia\Rdbms\DBUnexpectedError" error every time I do an edit. Anyone else having the same problem or know what's causing it? Adamant1 (talk) 08:50, 12 August 2024 (UTC)
- Test edit (and had some recent edits, too). —Justin (koavf)❤T☮C☺M☯ 08:52, 12 August 2024 (UTC)
- I was unable to access my Watchlist just now and it gave the same error (copy-pasted below), but now it works again. Seems to be something that happens occasionally with any action you take on Commons? Something's definitely up though.
- Internal error
- [716936fc-0c27-4546-840e-29aa0d19f0f9] 2024-08-12 08:52:09: Fatal exception of type "Wikimedia\Rdbms\DBUnexpectedError" ReneeWrites (talk) 08:57, 12 August 2024 (UTC)
- I keep getting errors today too. It took me forever to load this message. ~WikiOriginal-9~ (talk) 21:53, 13 August 2024 (UTC)
People taking pictures
Are there categories for people just taking pictures? Photografers categories only seem to have only professional photografers.Smiley.toerist (talk) 09:31, 12 August 2024 (UTC)
- Category:People photographing or Category:People with cameras. --Geohakkeri (talk) 09:45, 12 August 2024 (UTC)
- There's Category:People photographing whose description is inclusive of amateurs and professionals alike. ReneeWrites (talk) 09:45, 12 August 2024 (UTC)
- There's also Category:People holding cameras and similar categories. It's not really clear to me what the difference between that and Category:People photographing or Category:People with cameras is though. Let alone which category would be better in this case. --Adamant1 (talk) 09:47, 12 August 2024 (UTC)
- "People with cameras" sounds like they are only holding a camera or one around the neck. --PantheraLeo1359531 😺 (talk) 10:50, 12 August 2024 (UTC)
- Indeed. What is the difference between that and Category:People holding cameras? --Geohakkeri (talk) 10:57, 12 August 2024 (UTC)
- Category:People holding cameras sounds like a subcat of Category:People with cameras to me --PantheraLeo1359531 😺 (talk) 17:11, 12 August 2024 (UTC)
- Maybe Category:People with cameras can also mean people with cameras on tripod etc. --PantheraLeo1359531 😺 (talk) 17:13, 12 August 2024 (UTC)
- Good call. I made Category:People holding cameras a subcat of Category:People with cameras. --Adamant1 (talk) 12:43, 13 August 2024 (UTC)
- Maybe Category:People with cameras can also mean people with cameras on tripod etc. --PantheraLeo1359531 😺 (talk) 17:13, 12 August 2024 (UTC)
- Category:People holding cameras sounds like a subcat of Category:People with cameras to me --PantheraLeo1359531 😺 (talk) 17:11, 12 August 2024 (UTC)
- With mobile phones it is often not clear what people are doing, but in this case it clearly photographing. There are other functions than camera. Thanks anyway, I have recategorised to Men taking photographs in Japan.Smiley.toerist (talk) 11:12, 12 August 2024 (UTC)
- Indeed. What is the difference between that and Category:People holding cameras? --Geohakkeri (talk) 10:57, 12 August 2024 (UTC)
- "People with cameras" sounds like they are only holding a camera or one around the neck. --PantheraLeo1359531 😺 (talk) 10:50, 12 August 2024 (UTC)
- There's also Category:People holding cameras and similar categories. It's not really clear to me what the difference between that and Category:People photographing or Category:People with cameras is though. Let alone which category would be better in this case. --Adamant1 (talk) 09:47, 12 August 2024 (UTC)
And what about photos with shadows which clearly depict the photographer holding the device they're using to take the photo? Since category creep is such an unhinged free-for-all around here, why not? RadioKAOS / Talk to me, Billy / Transmissions 17:41, 14 August 2024 (UTC)
- See Category:Shadow of the photographer. One’s «unhinged free-for-all» is another’s accurate and useful curation. -- Tuválkin ✉ ✇ 18:13, 14 August 2024 (UTC)
Should galleries use the translate extension?
I think it would be useful for galleries to use the translate extension, as otherwise translators would have to manually edit all the mld tags first. It would also allow for translation of the page title. Thoughts? —Matrix(!) {user - talk? - uselesscontributions} 10:52, 12 August 2024 (UTC)
August 13
Uploads stopped working
I've tried repeatedly to upload a pic, it sits doing nothing for ages, then throws up this error message:
Request from 82.41.2.30 via cp3069 cp3069, Varnish XID 90145027 Error: 503, Backend fetch failed at Tue, 13 Aug 2024 21:11:42 GMT
Uploads were working fine earlier this evening, it is just in the last half hour or so. Thanks for any insight! - MPF (talk) 21:16, 13 August 2024 (UTC)
- Working now! - MPF (talk) 22:01, 13 August 2024 (UTC)
- Apparently there was some kind of hamster strike at the WMF servers. I also got messages that because of high database load I couldn't see the edits of the last 720 seconds or so on my watch list. --Rosenzweig τ 22:54, 13 August 2024 (UTC)
- Thanks! Hope the hamsters are being offered better pay now! - MPF (talk) 00:10, 14 August 2024 (UTC)
- @MPF: The hamster beatings will continue until morale improves. :) Seriously, though, I got a similar error message and reported it via phab:T372473. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:15, 14 August 2024 (UTC)
- Thanks! Hope the hamsters are being offered better pay now! - MPF (talk) 00:10, 14 August 2024 (UTC)
Upload failed repeatedly for me just now; the image is only ~500Kb. Page deletion on Wikispecies also failing. Both worked eventually, after several attempts. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:06, 14 August 2024 (UTC)
- The hamster strike apparently continues. It just took me over 20 minutes to add some categories to a page. --Rosenzweig τ 14:29, 14 August 2024 (UTC)
- Yeah, I ran into this yesterday and then again today. Whenever it's down for long enough, it means the upload jobs I'm running (which can take up to an hour) give up after several retries and I have to restart the process from scratch. hinnk (talk) 21:08, 14 August 2024 (UTC)
August 14
Message in AutoWikiBrowser - "doesn’t have enough privileges"
I have been using AutoWikiBrowser for years in Portuguese wikipedia an Commons, but today I was not enable to use it. Message said "This user doesn’t have enough privileges to make automatic edits on this wiki" . What's wrong?
- Sorry, I updated AWB and now everything is working fine — Preceding unsigned comment added by JotaCartas (talk • contribs) 22:37, 13 August 2024 (UTC)
I believe these two categories deal with the same game. fr:Jeu de l'assiette quotes a source from the 17th century, putting it in a similar timeframe to Belltafel = de:Pielkentafel. In England the game was called shovel board (related to but different from shuffleboard). Can the two categories be merged? Should they be kept separate, but both be put into (new) category:shovelboard that collects the cultural/regional variants? --Jonas kork (talk) 08:05, 14 August 2024 (UTC)
- I'd keep both categories, but would categorize them under Category:Table shuffleboard. Cryptic-waveform (talk) 21:24, 14 August 2024 (UTC)
- Sounds good, done! Thanks for the suggestion! --Jonas kork (talk) 07:39, 15 August 2024 (UTC)
Lists of GFDL
Hello!
I have made some lists at m:User:MGA73/GFDL files/Categories of the number of files licensed GFDL on all the wikis I could locate (updated since this). The lists look like this example for Wikinews:
I would like to find out how many files that can't be moved to Commons because Commons do not accept files licensed GFDL only after 15 October 2018.
There are many wikis and many languages I do not understand. So if you speak "Foo language" you are very welcome to check "Foo wikis". If the files are licensed correctly etc. you can Export them to Commons. If you need help setting up FileImporter just let me know.
If the files are not okay or does not look usable then you can nominate them for deletion locally. --MGA73 (talk) 13:08, 14 August 2024 (UTC)
- MGA73, I looked through n:pl:Category:GFDL and those files would be likely deleted on Commons due to {{No permission}} --Jarekt (talk) 13:53, 16 August 2024 (UTC)
- Thank you Jarekt! Yeah there can be other reasons than just the date. Some photos also have FOP issues. --MGA73 (talk) 17:15, 16 August 2024 (UTC)
- The four files of pl.wikinews would probably not be deleted for that reason, or at least it's not obvious.
- "Plik:1-7326 g.jpg" was licensed with GFDL at its source. The related pl.wikinews story gives it as an example of a montage on an external website that reused a GFDL-licensed Commons image. The external reuse initially did not comply with the GDDL requirements for reuses, but that was corrected after Wikimedians contacted the website. There are archived copies of the external website where the GFDL is seen.
- "Plik:SG hack1.png" is a screen capture of a webpage of pl.wikipedia from April Fool's day in 2008, claiming to be created by hackers. it contains 2 photographs
- "Plik:Konferencja zachlebem03.jpg" says that the permission was given by the photographer. It could probably be kept per "Grandfathered old files".
- "Plik:Kupony Lotto wykorzystane przez tvn24.png" may be a more complex case. It is an example of a modified version on an external website that did not comply with the reuse requirements of a CC BY-SA 2.5 licensed Commons image. The pl.wikinews article says that the image was removed from the external website. The pl.wikinews file description page says that the external website accepted to publish the modified version under the GFDL, which is strange. There does not seem to be an archived copy of that, so that could be difficult to verify 14 years later. However, the change in the modified version looks rather non creative and it could be uncopyrightable. An argument could be made that it could be used with the CC license of the original Commons image.
- -- Asclepias (talk) 22:16, 16 August 2024 (UTC)
- Asclepias,
- n:pl:Plik:SG hack1.png my main concern was copyrights of files in the photo, but I found them to be File:Paterm as metal star.jpg and File:Mickiewicz's spider.jpg, so I transfered the file to File:Polish Wikipedia screenshot - Strona główna - 2008-04-01.png
- n:pl:Plik:Kupony Lotto wykorzystane przez tvn24.png seem to be scaled down version of File:Kupony Lotto.jpg used and screenshot on external website. I agree that "the change in the modified version looks rather non creative and it could be uncopyrightable" and I transfered it to File:Kupony Lotto wykorzystane przez tvn24.png
- n:pl:Plik:1-7326 g.jpg claims to be licensed in 2007 with GFDL at its source, but there is no VRTS ticket related to it, no link to Wayback Machine page, and no {{LicenseReview}} template
- n:pl:Plik:Konferencja zachlebem03.jpg says that the permission was given in 2005 by the photographer, now we would need VRTS ticket.
- Those last 2 files likely comply with standards at a time of the upload, but I do not think are suitable for transfer to Commons as they do not comply with current standards. --Jarekt (talk) 02:47, 17 August 2024 (UTC)
- @Asclepias@Jarekt@MGA73 one image at English Wikinews licensed as such may need to stay there. It is their local copy of File:14-02-04-Parlement-européen-Strasbourg-RalfR-046.jpg, one of the infamous buildings of France that does not allow commercial FoP and is one of ADAGP's prized architectural possessions vs. inclusion in Wikipedias. JWilz12345 (Talk|Contrib's.) 05:35, 17 August 2024 (UTC)
- Asclepias,
- The four files of pl.wikinews would probably not be deleted for that reason, or at least it's not obvious.
Hebrew language help needed
Pls check and correct this autotranslated cleanup warning: Template:DistortedAspectRatio/he. Besides the bad grammar, there are two words that should be bold, but I didn’t know exactly which. -- Tuválkin ✉ ✇ 18:10, 14 August 2024 (UTC)
People by location
Which category to add or create to connect for example Category:LeBron James by location and other people by location? Eurohunter (talk) 21:57, 14 August 2024 (UTC)
- @Eurohunter: There's Category:Sportspeople by location. It's a little obtuse but you might create Category:Sportspeople by name by location or something like that. --Adamant1 (talk) 04:27, 15 August 2024 (UTC)
- @Adamant1: Yes, something like that, just I wasn't sure about the name for it. Eurohunter (talk) 08:36, 15 August 2024 (UTC)
- Please nooo, burn this category tree down to the ground. Category:LeBron James by location (no files) -> Category:LeBron James in the United Kingdom (no files) -> Category:LeBron James in England (no files) -> Category:LeBron James in London (1 file).
- That whole category tree only hides the files, instead of making them findable, although I still suspect that some people think that is the goal of categories. Multichill (talk) 16:37, 16 August 2024 (UTC)
- Please don't do this. This is typical overcategorization. This is not how categories should be used, and part of the reason the category system is going to eventually fail for Commons. We have way too many categories already. Categories should not be used as a short description of the file. It’s not supposed to be a query language. —TheDJ (talk • contribs) 17:14, 16 August 2024 (UTC)
- @Adamant1: Yes, something like that, just I wasn't sure about the name for it. Eurohunter (talk) 08:36, 15 August 2024 (UTC)
August 15
Problem renaming file
Hello, I am trying to rename this file (https://commons.wikimedia.org/wiki/File:Dhhshd2bidb3.jpg) to: Photograph of Gurdwara Fatehgarh Sahib, by Dhanna Singh Chahal 'Patialvi', ca.1920's–30's
But it says that title is blacklisted and invalid? I checked and it should not be (no unsupported characters) so I tried just "Photograph of Gurdwara Fatehgarh Sahib, by Dhanna Singh Chahal 'Patialvi' " and it said that name is blacklisted too. I do not know why it is not letting me rename this file. Any fix? — Preceding unsigned comment added by MaplesyrupSushi (talk • contribs) 00:53, 15 August 2024 (UTC)
- @MaplesyrupSushi: Hi, and welcome. I was able to rename it for you to File:Photograph of Gurdwara Fatehgarh Sahib, by Dhanna Singh Chahal 'Patialvi', ca.1920's–30's.jpg. Please sign your posts. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 09:22, 15 August 2024 (UTC)
- @Jeff G. Thank you! MaplesyrupSushi (talk) MaplesyrupSushi (talk) 03:05, 16 August 2024 (UTC)
How to delete metadata of a picture?
Hi. I can't find the procedure to delete/remove metadata of a picture.
Or should I nominate the photo for deletion and reupload it?
Cheers Shkuru Afshar (talk) 07:29, 15 August 2024 (UTC)
- @Shkuru Afshar: What picture? — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 09:24, 15 August 2024 (UTC)
- Any
- The pictures that I took but I forgot to delete the metadata before uploading. Shkuru Afshar (talk) 10:02, 15 August 2024 (UTC)
- @Shkuru Afshar: You may overwrite instead. Which metadata is it important that you remove, and why? — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:34, 15 August 2024 (UTC)
- Thank you for your guidance. Because it is personal data. Shkuru Afshar (talk) 10:43, 15 August 2024 (UTC)
- :@Shkuru Afshar: You can upload a new version without metadata and then request suppression of the original upload. - Jmabel ! talk 18:01, 15 August 2024 (UTC)
- Thank you Shkuru Afshar (talk) 20:20, 15 August 2024 (UTC)
- Where should I submit this suppression request? Shkuru Afshar (talk) 20:21, 15 August 2024 (UTC)
- You could post it here, or COM:AN, but if you want to keep it confidential and it's not more than 10 or so files, feel free to email me the list and I will take care of it. - Jmabel ! talk 22:15, 15 August 2024 (UTC)
- :@Shkuru Afshar: You can upload a new version without metadata and then request suppression of the original upload. - Jmabel ! talk 18:01, 15 August 2024 (UTC)
- Thank you for your guidance. Because it is personal data. Shkuru Afshar (talk) 10:43, 15 August 2024 (UTC)
- @Shkuru Afshar: You may overwrite instead. Which metadata is it important that you remove, and why? — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:34, 15 August 2024 (UTC)
POTY new rules
Dear users,
As you all know some featured pictures eventually end up being a Picture of the Year finalist. POTY scripts have been completely rewritten and I think a vote should be held to know it the rule stays "top 30 overall + top 2 of each category becomes finalist" or if, as proposed on POTY talk page by Ingenuity, it becomes "top 30 overall + top 5% of each category becomes finalist". Please vote on this page only.
Thank you for your time and I wish you all a beautiful day -- Giles Laurent (talk) 12:40, 15 August 2024 (UTC)
August 17
Uploaded public transport photos - how to let people know they can use them in articles
Hello, just finished uploading of public transport photos from around the Europeː https://cs.wikipedia.org/wiki/Wikipedista:Penguin9/Moje_fotogalerie_MHD
Where I can let other Wikipedia users know they can use photos on Wikipedia articles if they find it good idea? Of course I can use photos in articles myself too.
Also, is there any quality check? If some photos will not be sufficient for Wikipedia, will I be asked to remove them to not flood Wiki with trash content?
Thank you very much on advanceǃ
--Penguin9 (talk) 00:23, 17 August 2024 (UTC)
- You might want to look for a WikiProject that deals with transport and engage on the talk page. For example enwiki has en:Wikipedia:WikiProject Transport and cswiki appears to have cs:Wikipedie:WikiProjekt Doprava. Local to Commons there is Commons:WikiProject Transport, but it largely seems concerned with categorization. William Graham (talk) 02:14, 17 August 2024 (UTC)
Mention of overwriting cases at COM:FLICKR
COM:FLICKR currently does not have a section discussing the possibility of Flickr uploaders changing or overwriting their images on Flickr (which is permitted on the site). For example, File:Butanding Whale Shark (Donsol, Sorsogon) (794278440).jpg vs. this (which the file description points to as the source). While the CC licensing is widely-considered "irrevokable", it is better worth-mentiong the overwriting case in the policy page regarding Flickr imports. JWilz12345 (Talk|Contrib's.) 05:31, 17 August 2024 (UTC)
Keep local discussion on enwiki
Hello, just a notice that I have started a discussion to prevent use of "Keep local" template for files which are not fully or partly own work. You are welcome to join in. —Matrix(!) {user - talk? - uselesscontributions} 06:36, 17 August 2024 (UTC)