User talk:Fæ

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Notice If you want to see Python source code that supports some of my projects, go to Github and help yourself. The code is not written with reuse in mind... -- (talk) 15:57, 15 May 2018 (UTC)
Notice

If you are concerned that a category gets flooded with automated uploads, check that a template like {{Disambig}}, {{Photographs}}, {{Categorise}}, {{CatDiffuse}} or {{CatCat}} has been applied before complaining. In the case of my batch upload projects, any category marked this way will not be added to new photographs. -- (talk) 16:32, 20 September 2018 (UTC)

Archives.png

2017
2018
2019

File:Noah Silliman 2016-11-02 (Unsplash).jpg[edit]

{{Please link images}}

File:Noah Silliman 2016-11-02 (Unsplash).jpg (edit|talk|history|links|watch|logs) Stombari7 (talk) 21:56, 25 May 2018 (UTC)Stombari7

Silverton[edit]

Recatagorized all images in the Category:Silverton to Category:Silverton, New South Wales.

Image Deletion[edit]

File:Internet Archive book plate project, blank example 1.jpg[edit]

Elisfkc (talk)

Thanks~Cessna_208_Caravan#/media/File:Cessna_208_Caravan_I,_Seawings_(Jet-Ops)_AN1347237.jpg[edit]

It is helping young students learn that the cockpit is not really that complicated ~ and all those fancy buttons and such do have a purpose and are very easy to learn ~ Mitchellhobbs (talk) 21:25, 13 April 2019 (UTC)

— Preceding unsigned comment added by Mitchellhobbs (talk • contribs) 21:30, 13 April 2019 (UTC)

Poor duplicates from trainpix.org[edit]

Hi Fæ!
You uploaded a lot of images from trainpix.org. Very good job overall. However, my trainpix images are weak duplicates and they hit Commons. I have a trainpix account and i uploaded a large photo on Commons and a small copy on trainpix. Trainpix has a limit to images no more than 1280 pixels wide only.
All my uploads on trainpix can be viewed here: [trainpix gallery]
For sample: original image and poor copy from trainpix.
Look at your uploads from trainpix and make deletion request for poor duplicates, please.
With best regards, --George Chernilevsky talk 07:55, 23 September 2019 (UTC)

Housekeeping of this type, where images are later uploaded which are duplicates, is not obviously an action for the uploader of the older image. As you know which files you have uploaded and were also released on trainpix by yourself, this is more an action to be considered by yourself.
You can mark lower resolution duplicates with {{duplicate}}, which is probably the simplest process to use.
Thanks -- (talk) 10:37, 23 September 2019 (UTC)

Seattle Sanborn maps[edit]

I see you uploaded a bunch of Sanborn maps of Seattle (thank you very much for that). However, it looks like a lot of them for 1893 were missed. If you look at https://www.loc.gov/resource/g4284sm.g4284sm_g09315189301/?st=gallery&c=160, we are missing a lot of these images (maybe half? I haven't entirely worked it out). I noticed this because I was looking in Commons for the images that are at https://www.loc.gov/resource/g4284sm.g4284sm_g09315189301/?sp=83 and https://www.loc.gov/resource/g4284sm.g4284sm_g09315189301/?sp=84.

Is there any chance of coming up with a way to upload the missing pages of this? - Jmabel ! talk 02:39, 22 July 2019 (UTC)

@Jmabel: this would just get re-archived by ArchiverBot on the next run. See [1], Fæ, I've increased the archive time from 12 to 30 days. You can reconfigure it however you like when you're back. - Alexis Jazz ping plz 02:52, 12 August 2019 (UTC)
@: I see you've been answering some questions lately, so I'm pinging you again. Is this something you can help with, or should I look elsewhere? - Jmabel ! talk 15:53, 30 August 2019 (UTC)
@Jmabel: I briefly looked into this when you raised it, but I cannot tell what the cause is. It could be that the LOC image API (IIIF) has some bugs we don't know about, such as not returning all the files in a scanned album. The 'multisheet' or locbooks uploading routine I use should be comprehensive, and has been rerun several times across the collection. It's a slow but intelligent routine, which notices where files have been uploaded under different filenames. It might be that some of the files you are noticing have actually been uploaded under other names previously, either by me or others, or it could be that the LOC have dummy images getting returned, or it could be that the images are failing within the IIIF image generator on the LOC server side because of something odd happening with the original image scan.
If you can further refine the pattern as to what is missing, then this would greatly help the chance of an easy diagnosis. For me to spend a lot of time digging in to case examples, I would need to know that we were talking about thousands of missing images, rather than a hundred which might be fixable via manual uploads.
My time on uploads is low right now. I should probably try an RFA again, which would warm up my interest as a volunteer with access to deletions and history manipulation, things that have held me back from improving what happens around Commons deletions for several years. It's the main reason that the Commons Fair Use Upload Bot was abandoned as a project, shockingly this was four years ago, itself a rather depressing thing to recognize. -- (talk) 16:09, 30 August 2019 (UTC)
  • It's definitely at most hundreds. And I suspect it was something along the lines of uploading the same number of images as there were plates, but each plate is actually two images. As I say above, for Volume 1 the pattern of what is missing is very straightforward. For both TIF & JPEG, we cut off at "Sanborn Fire Insurance Map from Seattle, King County, Washington. LOC sanborn09315 003-40"; I'm pretty sure that the remaining plates can be had by continuing exactly the same pattern, incrementing that '40', to get images 41-84. Would that much be easy to do? - Jmabel ! talk 16:37, 30 August 2019 (UTC)
If it's detectable, then it should be possible to add a trigger in the upload script to compensate for it. Not going to investigate today, I'm adding a DNAU for a few months to ensure we don't lose it as a wanted fix. -- (talk) 16:40, 30 August 2019 (UTC)

Category:Internet Archive (uncrop needed)[edit]

Hi Fæ. It looks like Category:Internet Archive (uncrop needed) hasn't been tended to for at least a couple of weeks. All the best, --Animalparty (talk) 20:55, 27 September 2019 (UTC)

I'm in the process of swapping my 11 year old HDD to a larger SSD, albeit a cheap refurbished one. It may take a while for me to revisit how this works, but it's caused by "retiring" my old upgradable Macmini which was running these sorts of tasks as a slightly inadequate headless server, so they should be migrated to my X220 Thinkpad. If you notice Faebot activities, you may want to endorse my request at the WMF hardware donation programme, presuming that it's still active. I've cut down a lot on my volunteer time this year due to travelling and a lack of suitable kit. -- (talk) 11:03, 28 September 2019 (UTC)
SSD working, doing a one off catch up run for IA backlog. Due to some odd error with login in to Faebot, which I cannot be bothered to debug right now, having to do these from my main account. -- (talk) 17:40, 28 September 2019 (UTC)
Now running as a Faebot task, every 6 hours. -- (talk) 13:18, 2 October 2019 (UTC)

@Animalparty, Ruff tuff cream puff: If you have some time to investigate, could you examine why these 404 errors might be happening? It may be the cause of a 'residual' number of unprocessed images in the uncrop backlog.

File:Image from page 1120 of "The Saturday evening post" (1839) (14784846062).jpg

IA link: saturdayeveningp1933unse/saturdayeveningp1933unse#page/133/mode/1up
IA page: 133
IA name: saturdayeveningp1933unse 
Download: https://archive.org/download/saturdayeveningp1933unse/page/133.jpg 
Sleeping for 38.2 seconds, 2019-09-29 12:58:04
WARNING: API error http-bad-status: There was a problem during the HTTP request: 404 Not Found
 APIError("http-bad-status", "There was a problem during the HTTP request: 404 Not Found", {u'help': u'See https://commons.wikimedia.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes.'}) 
 Exception of this type not handled! 

-- (talk) 12:05, 29 September 2019 (UTC)

These could be a glitch in the archive. The uncropped image is stored at jp2, but I thought that all formats should be rendered as part of the archive. Based on this one(?) case, I'm not planning to try to rewrite code to fix it or work around it. For the time being I have manually emptied the category without uncropping the files, not a solution but we are so far unclear what the problem is, or if there is a fixable problem. -- (talk) 10:35, 30 September 2019 (UTC)

About your uploaded images[edit]

I noticed that there are many images on your talk page which have been deleted, it seems that you often does things that seem to violate policies.--Kai3952 (talk) 08:14, 6 October 2019 (UTC)

Can you answer my question please?--Kai3952 (talk) 01:02, 8 October 2019 (UTC)
I thought you were making a statement rather than asking a question.
Many of these deletions relate to upload projects from years ago where issues like the copyright of signs was missed as an issue. For large upload projects some housekeeping is normal, even when the source is a famous and well managed archive. For example many hundreds of my uploads of public domain images from the Library of Congress have been deleted because the way we interpret international copyright restrictions is not solely based on U.S. property law.
I encourage those doing this type of normal retrospective and non-controversial housekeeping to use Category:Uploads by Fæ needing speedy deletion rather than spending more time than is needed using deletion templates and individual review. -- (talk) 01:40, 8 October 2019 (UTC)
@Kai3952: By the way, the archive period for this page was set to 30 days by another user without my consent. This was the reason that an unusually high number of notices were hanging around this page. I have set that back to a more manageable period. Thanks -- (talk) 09:11, 8 October 2019 (UTC)

File:New York City (4374518926).jpg[edit]

File:New York City (4374518926).jpg (edit|talk|history|links|watch|logs)
Commons:Deletion requests/File:New York City (4374518926).jpg A1Cafel (talk) 03:59, 9 October 2019 (UTC)

File:Wall Street bull, New York, New York LCCN2011630801.tif[edit]

File:Wall Street bull, New York, New York LCCN2011630801.tif (edit|talk|history|links|watch|logs)
Commons:Deletion requests/File:Wall Street bull, New York, New York LCCN2011630801.tif A1Cafel (talk) 04:02, 9 October 2019 (UTC)

File:The_Capture_of_William_Joyce,_Germany,_1945_BU6910.jpg[edit]

The picture was croped as a "profile picture" without the context. However I suppose it would be good if the original picture would also exists. Maybe you can upload it again, and so on. Thanks. --Soenke Rahn (talk) 21:05, 10 October 2019 (UTC) ːBy the way, thanks that you have uploaded important old pictures from Flensburg. I hope you will find, step for step more of them. ;-) --Soenke Rahn (talk) 21:07, 10 October 2019 (UTC)

Notification about possible deletion[edit]

Bundle DR:
Commons:Deletion requests/Files in Category:Spirit of Ecstasy

Affected:


Yours sincerely, — Racconish💬 06:28, 11 October 2019 (UTC)

File:Sir Charles Sissmore Tomes. Photograph by Olive Edis. Wellcome V0027267.jpg[edit]

File:Sir Charles Sissmore Tomes. Photograph by Olive Edis. Wellcome V0027267.jpg (edit|talk|history|links|watch|logs)
Commons:Deletion requests/File:Sir Charles Sissmore Tomes. Photograph by Olive Edis. Wellcome V0027267.jpg — Racconish💬 18:02, 11 October 2019 (UTC)

Do not feel discouraged[edit]

Following your unsuccessful sysop request I hope that you will not feel discouraged from your ambitions on Wikimedia Commons in any way, you are our most valuable contributor and your presence is a blessing for Wikimedia Commons. Please keep up being the amazing contributor that you are, and I hope that you will edit with a smile on your face thinking of all the people you help educate. Face-smile.svg --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:59, 11 October 2019 (UTC)

+1 GMGtalk 20:24, 11 October 2019 (UTC)
+1 Thanks, — Racconish💬 20:37, 11 October 2019 (UTC)
+1 -- Tuválkin 13:31, 14 October 2019 (UTC)

Source of derivative work is not properly indicated: File:Record, sound (AM 2013.14.3-13).jpg[edit]

File:Record, sound (AM 2013.14.3-13).jpg (edit|talk|history|links|watch|logs) And also:

Extended content

Yours sincerely, Patrick Rogel (talk) 12:05, 12 October 2019 (UTC)

File:The history and antiquities of the cathedral church of Hereford - illustrated by a series of engravings of views, elevations, and plans of that edifice, with biographical anecdotes of eminent persons (14594564989).jpg[edit]

File:The history and antiquities of the cathedral church of Hereford - illustrated by a series of engravings of views, elevations, and plans of that edifice, with biographical anecdotes of eminent persons (14594564989).jpg (edit|talk|history|links|watch|logs)
Commons:Deletion requests/File:The history and antiquities of the cathedral church of Hereford - illustrated by a series of engravings of views, elevations, and plans of that edifice, with biographical anecdotes of eminent persons (14594564989).jpg Jan Kameníček (talk) 17:38, 12 October 2019 (UTC)

Rollbacks in watchlists[edit]

@Jeff G.: With regard to User_talk:Fæ/2019#Rollback, I went with this for all wikis:

.mw-changeslist-line .mw-rollback-link { visibility:hidden; }

.mw-watchlist seems to not exist as a class on my version, this might be down to other javascript mods in my layout. Previously my javascript swapped rollback link text with "-", but that has not worked for a couple of years, presumably due to restricting how javascript is allowed to behave. I could not get :after in css to work within the anchor itself which might have effectively done the same thing. -- (talk) 10:40, 14 October 2019 (UTC)

Thanks.   — Jeff G. please ping or talk to me 13:49, 14 October 2019 (UTC)

File:Kikötő, előtérben a kis hableány szobra. Fortepan 28566.jpg[edit]

File:Kikötő, előtérben a kis hableány szobra. Fortepan 28566.jpg (edit|talk|history|links|watch|logs)
Commons:Deletion requests/File:Kikötő, előtérben a kis hableány szobra. Fortepan 28566.jpg Dannebrog Spy (talk) 11:32, 15 October 2019 (UTC)

Notification about possible deletion[edit]

Bundle DR:
Commons:Deletion requests/Files found with "AM 2017.117.51"

Affected:

And also:

Extended content

Yours sincerely, (talk) 14:39, 16 October 2019 (UTC)

Notification about possible deletion[edit]

Visualization of the horror that awaits photographers of old toys.

Bundle DR:
Commons:Deletion requests/Files uploaded by Fæ

Affected:

And also:

Yours sincerely, GMGtalk 14:56, 16 October 2019 (UTC)

It occurs to me that you may not have the DR watchlisted. But alot of these seem to be late 20th century toys. We may want to consider pausing this upload and sorting through them more carefully, since it looks like about a 50/50 hit/miss ratio right now of files that would have to be deleted per TOY. GMGtalk 15:13, 16 October 2019 (UTC)
They should be fairly easily findable, so far I only see the two toys from the McDonald's freebies. Though the museum has a significant toy collection, most are 70+ years old as they are part of the wartime catalogue and so are highly unlikely to be copyright issues. Of the 120,000+ images uploaded (most a couple of years ago), about 1,500 seem to be of 20th C. toys if we can trust the museum's classification text. Try this search.
If necessary, a better action might be to mass add a review category based on date and classification text. However a manual visual check would probably be just as effective to weed out any obvious copyvios as there appear to be so few.
BTW, if you raise more DRs, could you do so based on the Auckland categories rather than the huge bucket category of "Files uploaded by Fæ"? Thanks -- (talk) 16:21, 16 October 2019 (UTC)

File:Sprinkhaan-Rijksmuseum AK-MAK-1154.jpeg[edit]

File:Sprinkhaan-Rijksmuseum AK-MAK-1154.jpeg (edit|talk|history|links|watch|logs)
Commons:Deletion requests/File:Sprinkhaan-Rijksmuseum AK-MAK-1154.jpeg GMGtalk 17:06, 18 October 2019 (UTC)

Notification about possible deletion[edit]

Bundle DR:
Commons:Deletion requests/Files found with NLI Ref.: ODEA

Affected:

And also:

Extended content

Unfortunately photographs appear to be in Copyright. Yours sincerely, Djm-leighpark (talk) 07:00, 20 October 2019 (UTC)