TheSandDoctor

Welcome to Wikimedia Commons, TheSandDoctor!

First steps tutorial Our first steps tour and our frequently asked questions will help you a lot after registration. They explain how to customize the interface (for example the language), how to upload files and our basic licensing policy (Wikimedia Commons only accepts free content). You don't need technical skills in order to contribute here. Be bold when contributing and assume good faith when interacting with others. This is a wiki. Getting help More information is available at the community portal. You may ask questions at the help desk, village pump or on IRC channel #wikimedia-commons (webchat). You can also contact an administrator on their talk page. If you have a specific copyright question, ask at the copyright village pump.

Goodies, tips, and tricks Put Babel boxes on your user page so others know what languages you can speak and indicate your graphic abilities. You can find the files you have uploaded in your Uploads. Please sign your name on Talk pages by typing ~~~~. To link to an image page without embedding the image, type: [[:File:Foo.jpg]], which produces: File:Foo.jpg. You may enable gadgets (custom features) for your account. There are several tools to upload files. Have you edited Wikipedia before? This guide might be useful. Made a mistake? Do you want to have a file renamed or moved? Use the move link and wait for an authorized user to rename it. Do you want to have your recently uploaded picture removed? Tag it as {{speedy|reason here}}. For more information read the deletion guidelines.

-- Wikimedia Commons Welcome (talk) 16:30, 23 January 2017 (UTC)

Autopatroller

Hi, I gave you the Autopatroller right. Regards, Yann (talk) 16:41, 12 January 2019 (UTC)

Hi Yann, I was not expecting that, thank you! May I ask why you did this? --TheSandDoctor (talk) 18:27, 12 January 2019 (UTC)

(talk page stalker) Hey, because you were triggering filters during renames. ‐‐1997kB (talk) 13:20, 13 January 2019 (UTC)

TheSandBot

Hi. Is there any way you can have your bot mark its edits as "bot" edits? It has a bot flag, but is still showing up in recent changes, suggesting that it isn't using the flag. Thanks, --DannyS712 (talk) 04:21, 31 May 2019 (UTC)

@DannyS712: Queued the run in question for deletion on tools and started a patched one. My apologies, it appears that it was a copy and paste error that slipped through and was introduced from patching a memory leak. now fixed. Thank you again for bringing this up, I'm just glad I was around to fix it so quickly after notice. Thanks! --TheSandDoctor (talk) 04:26, 31 May 2019 (UTC)

No problem. Also, if you have a minute to talk about bots, would you mind checking out w:en:wp:Bots/Requests for approval/DannyS712 bot 44? It should only take a few minutes, its pretty straightforward. Thanks, --DannyS712 (talk) 04:27, 31 May 2019 (UTC)

Wrong edits

There is something wrong with your bot. This picture was not taken in 2015. And lots of other similar edits. ~Cybularny ^Speak? 05:15, 31 May 2019 (UTC)

I wrote out a response, but not sure where it went. Anyways, you are quite right. Thank you very much for the report. There was an image 'stuck' that it was referencing against. How it got stuck was a typo resulting from repairing a memory leak, resulting in the temporary save of the new image not overwriting the old. The bot is now currently performing the edits and cleaning up after itself. Thanks so much for bringing this up, @Cybularny: . --TheSandDoctor (talk) 06:03, 31 May 2019 (UTC)

Same here. But as long it is eventually cleaned, its ok. --Arnd (talk) 07:19, 31 May 2019 (UTC)

@Aschroet: Special:Diff/352583015 done. --TheSandDoctor (talk) 12:51, 31 May 2019 (UTC)

• Sorry to pile on, but this case of EXIF date miscorrection might be a different matter. As it seems, this JPEG file does not have any EXIF info we might gather a date from, either confirming or disproving the uploader’s statement on the filepage upon upload (@Geekdidi: ). -- Tuválkin ✉ ✇ 19:28, 31 May 2019 (UTC)

@Tuvalkin: My apologies for the delayed response, I saw the email notification of your message much sooner but was unable to respond/edit until now. That is the same issue as above. Outside of the bot's aforementioned glitch, it only makes changes when "EXIF DateTimeOriginal" is present in the file metadata and disagrees with the value in Template:According to EXIF data. If the EXIF data simply did not exist, then TSB would favour the description page already present and move on without making an edit. By this same behaviour, it will also not automatically clean up after itself in this particular instance because it wouldnt see EXIF data and therefore favour whatever the description page said. In the near future, I will run a (non-editing) test to see how many were changed to read that date that do not have "EXIF DateTimeOriginal" present to hopefully catch these edge cases that it edited via the aforementioned bug and be able to resolve them. --TheSandDoctor (talk) 02:54, 1 June 2019 (UTC)

• Thanks for reverting and good luck with the clean up bot run. Concerning this one photo, it was my fault, as I had kept the {{Exif date}} template for a JPEG without any EXIF. -- Tuválkin ✉ ✇ 12:59, 1 June 2019 (UTC)

• @Tuvalkin: Don't worry. Under normal circumstances the bot would not have even made an edit in that case. The only reason it did was because of the bug mentioned above. I have taken steps to make sure that the code error does not happen in the future.
• So far, the (non-editing) script looking at images which lack "EXIF DateTimeOriginal" and have Template:According to EXIF data containing 2015-10-30 has turned up nothing. Both scripts seem to have run into some corrupt metadata which stops them. I have most likely now patched this. However, since they both crash at what appears to be around the same point, that means that the image you originally mentioned might have been the only case where it edited without any metadata. (Of course, I will keep looking to be sure.) --TheSandDoctor (talk) 16:30, 1 June 2019 (UTC)

• @Tuvalkin: Around 550 others were discovered by the analysis and I have manually reverted the instances. I will run the (non-editing) analysis once more in a day or two to be sure that I haven't missed any. --TheSandDoctor (talk) 05:52, 3 June 2019 (UTC)

File:20170402 - Bangkinang city.jpg

Why did you revert this? Bangkinang is in Riau province in 2017. Seems like a logical category to me. -- Ricky81682 (talk) 06:20, 3 June 2019 (UTC)

@Ricky81682: You are right. Reverting your edit was accidental, what I meant to do was to revert TheSandBot (see above section) as it had made an error on the page. I have reverted my revert of your edit (diff) and performed the proper revert of my bot (diff). My apologies. --TheSandDoctor (talk) 12:53, 3 June 2019 (UTC)

No worries. Thanks! -- Ricky81682 (talk) 01:30, 4 June 2019 (UTC)

File:135 Militkasko .svg

Respeite a língua usada pelo carregador. Você propôs alteração misturando duas linguas: Esperanto (original) e inglês. Eugenio Hansen, OFS (talk) 09:57, 21 July 2019 (UTC)

minhas sinceras desculpas, Eugenio Hansen, OFS. Terei mais cuidado na próxima vez. --TheSandDoctor (talk) 16:53, 21 July 2019 (UTC)

Welcome, Dear Patroller!

---

Counter Vandalism Unit

Hi TheSandDoctor,

You now have the Patroller right and may call yourself a patroller! Please take a moment to read the updated Commons:Patrol to learn how Patrolling works and how we use it to fight vandalism.

As you know already, the patrolling functionality is enabled for all edits, not just for new-page creations. This enables us to keep track of, for example, edits made by anonymous users here on Commons.

We could use your help at the Counter Vandalism Unit. For example by patrolling an Anonymous-edits checklist and checking a day-part.

If you have any questions please leave a message on the CVU talkpage or ask for help on IRC in #wikimedia-commons.

-- ~riley (talk) 06:55, 4 November 2019 (UTC)

Important message for file movers

A community discussion has been closed where the consensus was to grant all file movers the suppressredirect user right. This will allow file movers to not leave behind a redirect when moving files and instead automatically have the original file name deleted. Policy never requires you to suppress the redirect, suppression of redirects is entirely optional.

Possible acceptable uses of this ability:

• To move recently uploaded files with an obvious error in the file name where that error would not be a reasonable redirect. For example: moving "Sheep in a tree.jpg" to "Squirrel in a tree.jpg" when the image does in fact depict a squirrel.
• To perform file name swaps.
• When the original file name contains vandalism. (File renaming criterion #5)

Please note, this ability should be used only in certain circumstances and only if you are absolutely sure that it is not going to break the display of the file on any project. Redirects should never be suppressed if the file is in use on any project. When in doubt, leave a redirect. If you forget to suppress the redirect in case of file name vandalism or you are not fully certain if the original file name is actually vandalism, leave a redirect and tag the redirect for speedy deletion per G2.

The malicious or reckless breaking of file links via the suppressredirect user right is considered an abuse of the file mover right and is grounds for immediate revocation of that right. This message serves as both a notice that you have this right and as an official warning. Questions regarding this right should be directed to administrators. --Majora (talk) 21:36, 7 November 2019 (UTC)

Google Code-In 2019 is coming - please mentor some documentation tasks!

Hello,

Google Code-In, Google-organized contest in which the Wikimedia Foundation participates, starts in a few weeks. This contest is about taking high school students into the world of opensource. I'm sending you this message because you recently edited a documentation page at Wikimedia Commons.

I would like to ask you to take part in Google Code-In as a mentor. That would mean to prepare at least one task (it can be documentation related, or something else - the other categories are Code, Design, Quality Assurance and Outreach) for the participants, and help the student to complete it. Please sign up at the contest page and send us your Google account address to google-code-in-admins@lists.wikimedia.org, so we can invite you in!

From my own experience, Google Code-In can be fun, you can make several new friends, attract new people to your wiki and make them part of your community.

If you have any questions, please let us know at google-code-in-admins@lists.wikimedia.org.

Thank you!

--User:Martin Urbanec (talk) 22:05, 23 November 2019 (UTC)

Congratulations, dear license reviewer

If you use the helper scripts, you will find the links next to the search box (vector) or as single tabs (monobook). They are named license+ and license-.

Hi TheSandDoctor, thanks for your request for license reviewer status. The request has been closed as successful, and you've been added to the list of reviewers. You can now start reviewing files – please see Commons:License review and Commons:Flickr files if you haven't done so already. We also have a guide how to detect copyright violations. Potential backlogs include Flickr review and files from other sources. You can use one of the following scripts by adding one of the lines to your common.js:

mw.loader.load('//commons.wikimedia.org/w/index.php?title=User:ZooFari/licensereviewer.js&action=raw&ctype=text/javascript'); // stable script for reviewing images from any kind of source OR

mw.loader.load('//commons.wikimedia.org/w/index.php?title=User:Majora/LicenseReview.js&action=raw&ctype=text/javascript'); // contains also user notification when review fails, auto blacklist-check and auto-thank you message for Flickr-reviews.

Important: thou shalt not review thy own uploads, nor those of anyone closely related to you!

Please feel free to join us on IRC: #wikimedia-commons ^webchat on irc.freenode.net. You can also add {{User license reviewer}} to your user page if you wish. Thank you for your contributions on Commons! Minorax^talk _{(formerly 大诺史)} 03:09, 15 January 2020 (UTC)

Corrupt images?

Hi SandDoctor, your bot identified 3 images i uploaded as corrupt. Could you tell me why, because they look oke? Regards, Mr.Nostalgic (talk) 12:37, 8 February 2020 (UTC)

example = File:Handschoenen (paar) en beschrijving op papier. objectnr KA 15684.13.tif

• @Mr.Nostalgic: My local system agrees with you, but for some reason when the same code runs on the server it flags it as corrupt. I am investigating. Don't worry, I made sure that it won't nominate your three images. You can see the ticket here I created tracking this if curious. This was a trial run that has now concluded. Thank you very much for coming to me with this. --TheSandDoctor (talk) 18:08, 8 February 2020 (UTC)

Thanks! I was not worried. I know you have good intentions and i actualy experienced the message as quit friendly. Mr.Nostalgic (talk) 19:10, 8 February 2020 (UTC)

@Mr.Nostalgic: I ran it again after updating the server and it now correctly identifies the images you uploaded as not being corrupt. I have also manually updated their database entries to reflect this and reverted the bot's related edits. My apologies for this. I am glad that you found the message quite friendly, that was the intent . --TheSandDoctor (talk) 19:44, 8 February 2020 (UTC)

Thank you and keep up the good work. Regards, Mr.Nostalgic (talk) 20:42, 8 February 2020 (UTC)

And also:

• File:Haim Laskov - Yackov Dori - David Ben-Gurion - Hagana Pin 1958.jpg
• File:David Ben-Gurion pins the Haganah ribbon on Chaim Laskov. D358-069.jpg
• File:Moshe Prager, Jerusalem 1967.jpg

I can understand the last one as the first version was corrupted and I uploaded new file. But can't understand the others. -- Geagea (talk) 06:12, 13 February 2020 (UTC)

@Geagea: Thanks for reaching out! I have ran a couple of tests (results here) and it appears that the first two JPG images are truncated, meaning that the bytes in the file end prematurely/incorrectly. For the first image, it appears to be between 41 bytes and 45 bytes early. In the case of the second, 5 bytes early. These errors I don't think are necessarily noticeable (at least in this particular instance), but essentially means that part of the file is missing. I hope that this helps! Perhaps try uploading again and I can take a look? --TheSandDoctor (talk) 06:45, 13 February 2020 (UTC)

I have uploaded new versions.

Anyway, The 2 first files and also File:PikiWiki Israel 61786 historic site.jpg comes from the The National Photo Collection of Israel. There are thousands of files from this site.

But I think this template is not appropriate. Even if the file is missing 45 bytes it have educational value. This so called "corrupted file" have non visual corruption. I don't think that there is a need to notify for speedy deletion. Adding template to the file says someting like: "this file is corrupted: missing 45 bytes" is ok. -- Geagea (talk) 08:43, 13 February 2020 (UTC)

@Geagea: Unfortunately, telling what is visible corruption to a user/person is not something that is most likely possible for a system to accurately do. Determining what byte threshold should be missing before calling an image corrupt would also be rather arbitrary as it would be a case-by-case thing. Two images could both have 45 bytes missing and, depending where they are, logically there could be vastly different implications for visibility.

Perhaps another approach would be to modify the template message making it more informative and add the ability for users to manually say that the image isn't visibly corrupt? I am not too sure. Ultimately, the failsafe currently in place here is the fact that the bot does not delete images, rather, it nominates them for deletion. As such, human administrators then review them. If it doesn't make sense, they can remove the tag and opt not to take any further action. What I am thinking of doing is adding a parameter of something like "|checked=" where it could then be updated rather than removal.

Anyways, I agree that the template needs work and at current the nomination part of the task is not active because of this. I will be manually reviewing flagged/tagged images for the time being and looking at reports brought to me as well. --TheSandDoctor (talk) 20:04, 13 February 2020 (UTC)

Hello, also one of images I uploaded was indentified as corrupt by the bot. It was corrupt, in fact, but only the original upload while as soon as I noticed, I re-uploaded the image and it seems ok now. The new version was, however, tagged as corrupt. Could you review it? Thanks. Andrzej Otrębski (talk) 18:03, 13 February 2020 (UTC)

Hello Andrzej O. Thank you for reaching out. I have manually checked the image on both my local machine and the server. Both are showing the image as not being corrupt (logs). What I suspect happened was that it was stuck in the queue of images to process (collected from recent changes) and it had the first version cached as a result. I have updated the database and will remove the template once I have the diff of this edit to point to in the summary. Nothing further is needed on your part. I shall have to update the template that is left on file pages to make it more descriptive/helpful. --TheSandDoctor (talk) 19:51, 13 February 2020 (UTC)

Appreciated :) Andrzej Otrębski (talk) 21:10, 13 February 2020 (UTC)

Sandbot EXIF dates

Hi. I just spotted that your bot has a task to set dates based on EXIF data. Yesterday, I came across File:Queen Anne Mansion.jpg with an EXIF date of 2216 (someone must have had an odd date set on their camera). I've changed the date to "Otherdate before 2014" (date of upload to Commons). Your bot hasn't encountered it yet but I wondered if there is anything I need to do to make sure a bot doesn't revert to the future date. Thanks. From Hill To Shore (talk) 21:35, 14 February 2020 (UTC)

@From Hill To Shore: Not to worry! The task was a one-time run basically because the Android app at one point gave everything uploaded the wrong EXIF date. The task has long since completed. That does remind me though that I need to update the userpage....Thanks! --TheSandDoctor (talk) 22:02, 14 February 2020 (UTC)

@From Hill To Shore: Updated userpage. Thanks for the heads up/reminder. --TheSandDoctor (talk) 22:13, 14 February 2020 (UTC)

File:"Looking downstream into upper cofferdam excavation. Dike and constricted river channel at left." - NARA - 293750.jpg

This and this doesn't feel very helpful. Yes, a bit at the bottom seems to be broken, but having a bot put a speedy deletion threat on the file and editing a redirect page is counterproductive. Looking at Category:TSB identified corrupt I see that most files don't qualify for speedy deletion and judging from the deleted edits, no files have been deleted in the past. Probably better to stop this job and revert all the edits. Multichill (talk) 15:24, 15 February 2020 (UTC)

@Multichill: it is operating as intended per the bot request and request for approval (and templates approved). This has been approved since December but only started in earnest since last weekend. It has scanned over 200,000 files and only found 19 corrupt ones, or about 0.0095‬% of files in its current sample size. That is extremely low and as expected as most images on commons are not corrupt. As for why it has not nominated any as of yet is because I am not currently running that part of the program; I plan to check by hand at the moment. It is the responsibility of an admin to review that the file is indeed corrupt and requires deletion.

As for it tagging a redirect: that is indeed odd, but otherwise everything it has tagged does indeed appear to meet the definition of F7 -- the files are indeed corrupt. I have created a task for that and have implemented the check to ensure it does not edit/scan redirects. Thank you for mentioning that. --TheSandDoctor (talk) 18:46, 15 February 2020 (UTC)

• OK. @Multichill and Fae: How about we run this in tag only mode (which it is currently) & I temporarily modify the templates to indicate that the files will not be nominated for deletion. Then we take this to a community RfC regarding nominating for deletion, speedy or otherwise. How does that sound? --TheSandDoctor (talk) 19:15, 15 February 2020 (UTC)

It's good that you tag slightly corrupt files to flag that, just the whole speedy deletion part is complete nonsense and not in line with the deletion policy. It's all about the visual part. You can see that only a bit at the bottom is missing. What's the point in deleting this files? If you really think this is covered by the deletion policy, than you're editing on the wrong project. This is Commons, not the English Wikipedia. Common sense still works here and is not overruled by wikilawyering. You can start your RFC's on the English Wikipedia, that stuff doesn't really work out here. Multichill (talk) 19:55, 15 February 2020 (UTC)

• @Multichill and Fae: Some time ago now I toned down the wording of the templates and the bot will not (nor has it ever) nominated an image for deletion. The followup script has been repurposed for the sole purpose of checking to see if images are fixed (thus updating database/removing the tag). In the event that they are still corrupt, it does nothing. Thank you both for your input. --TheSandDoctor (talk) 06:27, 26 March 2020 (UTC)

Thanks for providing this useful service. Multichill (talk) 17:08, 26 March 2020 (UTC)

Image identified as corrupt. Looks fine(?)

This image here and here was indicated by the bot as corrupt. Need an admin to check. Ominae (talk) 05:51, 26 March 2020 (UTC)

@Ominae: The images are missing some non-visible bytes of information. This can be "fixed" by re-encoding them, but for some reason I seem to be running into a glitch lately where I am unable to do it myself (as in I fix it locally, verify it is fixed, upload it, download it to check & magically corrupt in the same way...). I am investigating that issue on my end, but bottom line is that the images are indeed missing some bytes. Just not sure why I am unable to fix them on my machine... --TheSandDoctor (talk) 06:36, 26 March 2020 (UTC)

I see. Ominae (talk) 06:38, 26 March 2020 (UTC)

@TheSandDoctor: Should I just try to reupload the other "corrupt" image again? Noted that you reuploaded the first one. Ominae (talk) 13:07, 27 March 2020 (UTC)

@Ominae: You can certainly try re-uploading them as that may work, assuming that you have the original files still. JPG files are more likely than others to corrupt during upload. The glitch I was talking about appears to have happened with the new version I uploaded, so try both perhaps? --TheSandDoctor (talk) 17:09, 27 March 2020 (UTC)

@TheSandDoctor: Tried to upload said file again. Not sure if the bot will recognize it as corrupt. Ominae (talk) 05:34, 28 March 2020 (UTC)

Template editor given

Hello. I just wanted to let you know that I have granted template editor right to your account; the reason for this is that I believe you are sufficiently trustworthy and experienced to work with templates. Please consider enabling two-factor authentication for your account. Furthermore, please look at Category:Commons protected edit requests (template protected) occasionally and try to help your fellow Commoners with responding to their edit requests. Thank you.

~riley (talk) 03:32, 2 April 2020 (UTC)

File:03-07-dagebuell-by-RalfR-129.tif

Hi TheSandDoctor, why was this image by Ralf Roletschek tagged as being corrupt? Regards, AFBorchert (talk) 10:24, 21 April 2020 (UTC)

@AFBorchert: TSB sees it as corrupt, but I had it confirmed by AntiCompositeNumber that it is not. I have updated my scripts so that they avoid tif images from here on out and treat them as non-images (basically a "do nothing" operation). My apologies. --TheSandDoctor (talk) 17:15, 21 April 2020 (UTC)

Hi TheSandDoctor, thank you, this is appreciated! BTW, as this message popped up on the talk page of a user who doesn't speak English, I've provided a German translation for it. But there is a problem. The time until the file is reexamined again is specified as “30 days”. I am not aware of a template which translates this to “30 Tagen” (or “30 Tage” in dependence of the grammatical context). It would be simpler if this could be changed to a numerical value without text i.e. without the “days” suffix) or if you would specify it absolutely in {{ISOdate}} format. Regards, AFBorchert (talk) 18:45, 21 April 2020 (UTC)

again: "Image identified as corrupt"

File:GER — BY — München — Hansastraße 19 (ADAC-Zentrale) 2020.JPG

affected image

Dear bot operator,

What is the exact problem here. Why are users threatened with sd, I find it a bit harsh.

Next problem: As ordered, I tried to perform a re-upload. Reason for re-upload: Your message "This image has been automatically identified as corrupt by TheSandBot. Please re-upload and this will be scanned by TheSandBot again." Result: no luck (message: "The upload is an exact duplicate of the current version of File:GER — BY — München — Hansastraße 19 (ADAC-Zentrale) 2020.JPG." Further action: Another fresh upload with another file name.

You're system is bonding a lot of extra precious time. --Mateus2019 (talk) 14:25, 1 May 2020 (UTC)

Hello Mateus2019, you actually are the first to discover/experience this specific error in its over 2.2 million files scanned. That has been corrected and will not re-occur. I have also updated the image in the bot's internal database. Typically when there is no visible corruption, it means that the file has lost its "end" tags and needs to be re-encoded.

Regarding the rest of your message, I fail to see how "If it is still corrupt at that time, then the file may be nominated for deletion. This is most likely to happen when a substantial portion of the image is corrupt." is threatening. What that means in practice is that if over 50% of the image is visibly corrupt, it may be nominated for deletion on a case-by-case basis as at that point its value may be in question. Images without visible corruption will not receive this treatment.

"You're system is bonding a lot of extra precious time." You are corrent in this one instance that it was a software fault, and I do apologize for that. Speaking generally, however, re-uploading a file that was corrupted during upload is hardly a waste of time. The worst corrupt images that the bot has encountered that were unrecoverable and the uploader took no action were indeed nominated for speedy deletion and deleted, but that is because either over 50% of the image was corrupt and/or the primary subject of the picture was entirely corrupted out. --TheSandDoctor (talk) 16:42, 1 May 2020 (UTC)

accepted. So just inclomplete image data is the issue during the upload process. The old one can be deleted now. Anyhow, thanks for your information and best wishes from Germany, --Mateus2019 (talk) 16:55, 1 May 2020 (UTC)

TheSandBot false positive

Your bot marked File:Track near Tobelbach 2020-03-11 16.jpg as corrupt. As the file and metadata looking okay and the downloaded file has the same hashes as the original file it themes to be a false positive. --GPSLeo (talk) 15:32, 3 May 2020 (UTC)

@GPSLeo: It has "f7xnvacfkivafer58h6whi8ezdqydca" stored as the image hash value, which is clearly incorrect per the page information. This requires further investigation. --TheSandDoctor (talk) 16:36, 3 May 2020 (UTC)

What image hash do you mean? --GPSLeo (talk) 19:43, 3 May 2020 (UTC)

File:MD Rasel Molla talking on telephone.jpg

File:MD Rasel Molla talking on telephone.jpg is considered to fulfill the criteria for speedy deletion and has been marked on its page. The following reason has been specified: COM:CSD#F10, Personal photos of or by non-contributors. If you believe the content does not meet the criteria for speedy deletion, you may replace the speedy deletion tag with a regular deletion request (if the content has not been deleted) or request undeletion (if the content has already been deleted). All your uploads, including deleted ones, are listed in your upload log. If you need help, please read our frequently asked questions or visit the help desk. Please do not remove this message from your talk page. You may set up archiving instead. Warning: Wikimedia Commons takes copyright violations very seriously and persistent violators will be blocked from editing.

Gbawden (talk) 13:24, 2 October 2020 (UTC)

File deletion: WG WoWS Keyart FrameArt IDBlock FullColor Eng 1000x1000px Preview.jpg

Why did you mark this file for "speedy deletion"? I was asked by War Gaming to update the cover art image to the released artwork rather than the beta artwork that was on the page? --— Preceding unsigned comment added by Jameme01 (talk • contribs) 04:03, 12 October 2020‎ (UTC) (UTC)

@Jameme01: Because Commons can only hold non-copyrighted images. That image is best uploaded on the English Wikipedia itself, where it would be acceptable under free use. Please see en:Wikipedia:File Upload Wizard. --TheSandDoctor (talk) 04:29, 12 October 2020 (UTC)

File:The World Famous Tony Williams Twitter bio 2020-03-20.png

File:The World Famous Tony Williams Twitter bio 2020-03-20.png has been marked as a possible copyright violation. Wikimedia Commons only accepts free content—that is, images and other media files that can be used by anyone, for any purpose. Traditional copyright law does not grant these freedoms, and unless noted otherwise, everything you find on the web is copyrighted and not permitted here. For details on what is acceptable, please read Commons:Licensing. You may also find Commons:Copyright rules useful, or you can ask questions about Commons policies at the Commons:Help desk. If you are the copyright holder and the creator of the file, please read Commons:But it's my own work! for tips on how to provide evidence of that. The file you added has been deleted. If you have written permission from the copyright holder, please have them send us a free license release via COM:VRT. If you believe that the deletion was not in accordance with policy, you may request undeletion. (It is not necessary to request undeletion if using VRT; the file will be automatically restored at the conclusion of the process.) This file is a copyright violation for the following reason: Screenshot of Twitter. Warning: Wikimedia Commons takes copyright violations very seriously and persistent violators will be blocked from editing.

 

Premeditated (talk) 11:16, 10 April 2021 (UTC)

User:TheSandBot

Congratulations! Task 4 was approved. --EugeneZelenko (talk) 14:08, 19 May 2021 (UTC)

A barnstar for you!

	The Technical Barnstar
	Thanks for helping us to tidy up the metadata on Auckland Museum images! Jetaynz (talk) 22:10, 23 May 2021 (UTC)

Wiki Loves Folklore 2022 is on!

You are humbly invited to participate in the Wiki Loves Folklore 2022 an international photography contest organized on Wikimedia Commons to document folklore and intangible cultural heritage from different regions, including, folk creative activities and many more. It is held every year from the 1st till the 28th of February.

You can help in enriching the folklore documentation on Commons from your region by taking photos, audios, videos, and submitting them in this commons contest.

Kind regards,

Wiki loves Folklore International Team

--MediaWiki message delivery (talk) 07:16, 6 February 2022 (UTC)

Wiki Loves Folklore 2023 in India is on!

Hello TheSandDoctor,

Greetings from Wiki Loves Folklore India Team!

Wiki Loves Folklore is an international photography contest organized on Wikimedia Commons, this campaign invites participants to document folklore and intangible cultural heritage from different regions, including, folk festivals, folk dances, folk music, folk activities, folk games, folk cuisine, folk wear, folktales, folk games, folk religion, mythology and many more. Let's help to protect and develop our intangible Indian culture, which consists of customs or active expressions that we have acquired from our ancestors and passed down to our offspring.

How to Contribute?

The dates for the submission in the photography contest on Wikimedia Commons are from 1 February to 31 March 2023. Probably you are wondering how you can take part. It’s simple: grab a camera, record an image, video or audio under the folklore theme, create a Wikimedia account and start uploading! To learn more about the rules, check out our Project page on Wikimedia Commons.

Below are the exciting prizes which you can win internationally an locally. (Contributors can win both International and Local Prizes as well )

International Prizes

• 1st prize: 400 USD
• 2nd prize: 200 USD
• 3rd prize: 100 USD
• Top 10 consolation prizes: 10 USD each
• Best Video prize and best Audio prize: 25 USD, 25 USD (each)
• Top uploader prize for images: First Prize 100 USD, Second prize 50 USD
• Wiki Loves Folklore Postcards to top 100 Uploader's

Local Prizes

• 1st prize - 15000 INR + WLF Goodies
• 2nd prize - 10000 INR + WLF Goodies
• 3rd prize - 5000 INR + WLF Goodies
• Consolation : Top 5 winners - 1000 INR each + WLF Goodies
• Wiki Loves Folklore Certificate for Winners

(Disclaimer : The above prizes for International and Local Contest will only be disbursed in form of gift card or voucher format only)

If you are interested in participating in the photography campaign, start photographing and collecting media of your local culture and upload them on the photo campaign happening on Wikimedia Commons.

For more information about rules and prizes of the contest, refer the project page. For any questions, reach out to us via support@wikilovesfolklore.org.

You have been sent this message because you have been a part of Wiki loves Folklore in its journey in the past 5 years, lets continue to embrace our folk culture and drive through the path towards creating the largest database collection of folk Images on the internet

Warm regards,

Gaurav Gaikwad (User:Rockpeterson)

Coordinator for Wiki Loves Folklore India.

File:Patrick Howley headshot.jpg

File:Patrick Howley headshot.jpg has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

186.174.163.94 17:07, 9 July 2023 (UTC)

给您一个星章！

	勤奋星章
	Thanks for helping with reviewing my uploads, and license reviewing work in general! 廣九直通車 (talk) 11:07, 28 July 2023 (UTC)