User talk:Flominator/Flinfo

Todo

Topic	Description	Status
Translation interface	A way to enable people to easily contribute translations	Brainstorming
URL input	Call Flinfo by using a Flickr-URL instead of the ID	OK since early 2010
test categories	Just convert the tags with existing categories	OK since 9. Oct 2007
html2wiki	Convert html links to external links	OK since 18. Oct 2007
geocoding	Add Template:Location dec where suitable	OK since 3. Dec 2007
LoC images	Support PD-Bain, PD-USGov-FSA and LOC-image	OK since 20. Jan 2008
no categories	test categories didn't work longer, because the API had been changed	OK since 24. Mar 2008
whitespace categories	categories like Category:Shiny Toy Guns weren't detected correctly	OK since 20. Apr 2008
Powerhouse images	images from the latest commons addition are tagged with Template:PD-Australia	OK since 20. Apr 2008
Brooklyn Museum	images from the Brooklyn Museum are now tagged with Template:Flickr-Brooklyn-Museum-image and Template:Flickr-no known copyright restrictions	OK since 4. Jun. 2008
pipes removed	some images from the Brooklyn Museum contained the pipe character, which is now replaced by "-"	OK since 4. Jun. 2008
e-mail addresses	convert e-mail addresses, like the one at [1] by a clickable link	Not done
notify removed	the message that asks to notify the Brooklyn Museum is now included in Template:Flickr-Brooklyn-Museum-image and will be therefore removed from the description	OK since 5. Jun. 2008
wrong form	the links to the upload forms were outdated, since Commons changed them some days ago	OK since 5. Jun. 2008
unknown source	all images from new sources, like the ones from the Smithsonian Institution are tagged with Template:Flickr-no known copyright restrictions	OK since 19. Jun. 2008
Fonds Trutat	pictures from Bibliothèque de Toulouse taken by Eugène Trutat are marked with Template:PD-old	OK since 11. Jul. 2008
only correct dates	timestamps before January 01, 1970 and those after today are no longer inserted	OK since 11. Sep. 2008
copy to upload form	template {{information}} is automatically copied to the upload form	OK since 29. Nov. 2008
disclaimer links	disclaimers of institutions participating in Flickr's TheCommons are linked at the permission field (but only if there is a rights statement for the institution)	OK since 29. Nov. 2008
Oregon + Florida	added the disclaimer links to Oregon State University Archives and Florida Memory	OK since 07. Mar. 2009
Getty	added the disclaimer link to Getty Research Institute	OK since 16. May 2009
Scotland	added support for pictures from National Galleries of Scotland Commons.	OK since 29. May 2009
White House	pictures marked with United States Government Work are translated into Template:PD-USGov-POTUS	OK since 29. May 2009
Field Museum Library	added support for their pictures	OK since 22. Aug. 2009
Nantucket Historical Association	added support for their pictures	OK since 22. Aug. 2009
input parameters	you can now configure Flinfo's output (see User:Flominator/Flinfo)	OK since 22. Aug. 2009
name as fall back description	when now description is entered at Flickr, Flinfo will take the name of the image as description	OK since 22. Aug. 2009
Swedish National Heritage Board	added support for their pictures	OK since 19. Sep. 2009
LLGC/LSW	added support for two new organisations: [2], [3]	OK since 8. Nov. 2009
no brackets	added removal of brackets in flicker's image titles. Also "Book & Manuscript" is turned into "Book and Manuscript" in order to keep the preview working.	OK since 20. Jan. 2010
category redirects	categories containing Template:Category redirect will no be replaced by the target category.	OK since 22. Jan. 2010
user agent	set user agent according to [4] and [5] after occurrence of error message	OK since 22. Feb. 2010
main categories	now ignoring categories using Template:Categorise	OK since 22. Feb. 2010
NARA	now supporting images from National Archives and Records Administration	OK since 28. Feb. 2010
JDA	now supporting images of Jewish Women's Archive	OK since 11. Mar 2010
UW DC	now supporting images of University of Washington Libraries Digital Collections	OK since 13. Mar 2010
3 new commons	now supporting images of UA Archives, Center for Jewish History and The National Archives UK	OK since 01. May 2010
some new commons	now supporting images of Library of Scotland and some others	OK since 03. July 2010
new code	finally uploaded a version of Flinfo that was completely rewritten by my new partner Lupo.	OK since 03. July 2010
ipernity and panoramio	new modular architecture of the tool by Lupo now allows use of pictures from these two other image pages	OK since 03. July 2010
Picasa	New engine for retrieving image info about Picasa images added by Lupo	OK since 11. May 2011
whitelisting	Selective whitelisting and license extraction from EXIF.	OK since 15. May 2011
LA BW	Retrieving image information from Landesarchiv Baden-Württemberg	OK since 15. April 2017

Please post German postings at w:de:Benutzer Diskussion:Flominator/Flinfo

geocoding?

Hi! Do you have any plans to add geocoding to the info gathered by Flinfo? This would be a useful feature. Cheers--Ragesoss 22:31, 28 October 2007 (UTC)

I didn't think about it yet. Please show me some examples on Flickr und Commons and I'll see what I can do. --Flominator 09:33, 29 October 2007 (UTC)

Done. --Flominator 18:52, 3 December 2007 (UTC)

Locations

Hi. A question about locations has come up at User talk:Jeff_G.#Stated_location_on_Commons:Questionable_Flickr_images.3F. Would you please address it there? Thanks!   — Jeff G. (talk|contribs) 19:02, 30 November 2007 (UTC)

Download link

The download link on the Flinfo page doensn't work for me. It seems Flickr is blocking it. Is this a known bug? I don't mind downloading direct from Flickr's site, but it's annoying to have that broken link, because I know I'm going to click it. :) Superm401 00:06, 12 December 2007 (UTC)

Flinfo down

Flinfo is down for me, and it's worked in the past. VanTucky 21:33, 13 February 2008 (UTC)

Flinfo minor bug

Just a minor error, but when it detects something like "all rights reserved", it says {{copyvio|Flickr, licensed as "All Rights Reserved" which is no free license --~~~~}} when it should be "not a free licence" rather than "no free licence". -mattbuck (Talk) 00:30, 3 May 2008 (UTC)

Thanks. Changed. --Flominator (talk) 20:00, 9 September 2008 (UTC)

Update your Flickr 2 Commons scripts

Hello

I may update these scripts : http://wikipedia.ramselehof.de/flinfo.php http://toolserver.org/~magnus/flickr2commons.php because Smithsonian Institution has join Commons.

Thanks. I already noticed it. I just need to know which template to use. --Flominator (talk) 09:06, 17 June 2008 (UTC)

Fill in upload form

Ibn Hajar

(contributed by Farooque Ahmed for Wikipedia, the free encyclopedia)

Ibn Hajar ibn Ali Usqalani (d. 853 AH/ 1449 AD) is one of the most famous Traditionists and Hadith collectors who worked tirelessly about the activities and numbers of Sahabas and Shaybat who went to Abyssinia in 614 and 615 and about their return activities in Arabia. He is also known as Hafiz ibn Hajar, or Al Hafiz (Ibn Hajar) or Ibn Hajar Shahbuddin Abul Fazl Usqalani._{M.M.Yusuf Kandhlawi, 2004, Hayatus Sahaba: Lives of the Sahaba, vol. 1, pp. 429, 463, 443.}

Biography

Name: Ibn Hajar or Al Hafiz Ibn Hajr Name of Father: Ali Usqalani Date of Birth: ? CE Date of Death: 1449

Major Works

His major work on Abyssinian Hijarat question is Asaba or al-Isabah ( meaning: About the Sahabas dealing with mainly Abyssinia bound first Hijaratis). Al-Isabah (Asaba) makes up the main story of this episode where in many Sahabas, traditionists and commentators put in their views._{Kandhlawi, Hayatus Sahaba (v.1), pp. 450-51.)His reputed work clearly indicated that Sa'd and his father Abi Waqqas were not among those returning from Abyssinia to Madinah (Arabia).}

“Ibn-Hajar was an Arabian author who wrote more than a hundred books, among which are Lisan-ul Mizan and Asaba.He died in AD 1449/853 AH)”._{T. William Beale, 1971, An Oriental Biographical Dictionary, New Delji:Manohar Reprints, p.168.}

His major work on Traditions was Bulugh al- Maram, an abridgement of which, called Muntakhib Bulugh al-Marani, was printed in Calcutta with an interlinear Urdu Translation.”_{T.W. Beale, An Oriental Biographical Dictionary, p. 359.} Ibn-Hajr also wrote a famous book Fath al-Bari, Pub. Cairo, 1348 CE._{Prof. Dr. Abd al-Rahman I. Doi,2000, Sciences of the Quran, New Delhi: Sterling Publishers, p.23)}

Legacy

Ibn Hajar made the significant statement: “A Collection of the commentaries of Abd-Allah ibn Abbas was in Egypt according to the traditions of Abi Talhah. Ibn Hajar mentions that Abu Salih, the transcriber of Laithi, and a traaansmitter of Hadith had in Egypt this manuscript of the Tafsir ibn Abbas in his possession. This information he had received from Muawiyah, the son of Abu Sufiyan and he, from Abu Talhah and he from Abbas. Abu Jafar in his work Nasikh took the tradition from this very source. Whatever Imam Bukhari reflects in his book as statements of Ibn Jarir, Ibn Abu Haitham and Ibn al-Manzur, also received their information for commentaries of the Ibn Hajar, above through several mediums.”_{Prof A. Doi, 2000, The Sciences of the Quran, p. 271.}

The high tribute paid to Ibn Hajr in his lifetime and later is reflected by a statement: “Sir Syed quoted Hafiz Ibn Hajr, one of the most respected theologians of that time, as saying that in ‘most of the traditions relied upon Tabari there is no basis at all’”._{Rafiq Zakaria, 1991, Muhammad and the Quran, New Delhi 14.}

Notes

1. Maulana Muhammad Yusuf Kandhlawi, 2004, Hayatus Sahaba: Lives of the Sahaba, vol. 1, pp. 429, 463, 443. 2. M.M. Y. Kandhlawi, Hayatus Sahaba (v.1), pp. 450-51.)His reputed work clearly indicated that Sa'd and his father Abi Waqqas were not among those returning from Abyssinia to Madinah (Arabia). 3. T. William Beale, 1971, An Oriental Biographical Dictionary, New Delji:Manohar Reprints, p.168. 4. T.W. Beale, An Oriental Biographical Dictionary, p. 359. 5.Prof. Dr. Abd al-Rahman I. Doi,2000, Sciences of the Quran, New Delhi: Sterling Publishers, p.23).

6.Prof A. Doi, 2000, The Sciences of the Quran, p. 271. 7.Rafiq Zakaria, 1991, Muhammad and the Quran, New Delhi 14.

Replace Template:Information by Template:Flickr

Hello.

I think you can replace, in Flinfo script and here, the Template:Information by Template:Flickr. This template:flickr include Flickr image in Flickr category.--ComputerHotline (talk) 10:52, 18 October 2008 (UTC)

I don't really understand what that would change ... --Flominator (talk) 15:17, 10 November 2008 (UTC)

The actual Flinfo and the actual flickr2commons uses "Template:Information". I think these scripts would use this template "Template:Flickr", not "Template:Information". --ComputerHotline (talk) 18:52, 10 November 2008 (UTC)

I understood that. What I didn't understand was the reason. --Flominator (talk) 09:47, 13 November 2008 (UTC)

Replace in yours scripts the Template:Information with Template:Flickr. This Flickr template include automatically the image in "Flickr" category. --ComputerHotline (talk) 16:57, 15 November 2008 (UTC)

Support of this site

Hello.

Your scripts (Flinfo script and Flickr2commons) may supports this site which joined The Commons.--ComputerHotline (talk) 11:53, 21 October 2008 (UTC)

Flinfo supports every uploader with an appropriate license. Do you think that Template:PD-NL-Gov may be applicable? --Flominator (talk) 09:59, 24 October 2008 (UTC)

I don't know. --ComputerHotline (talk) 15:09, 24 October 2008 (UTC)

Download link again

I tried to upload the following file from Flickr http://flickr.com/photos/dbfrom1kb1/2041518247/ , when I clicked on download original size I get http://static.flickr.com/2347/2041518247_a3a027eda9_o.jpg, but the image is there as I can manually download it; it just appears to be calling for the wrong link. It seems that it should be calling for http://static.flickr.com/2347/2041518247_f8d41b5ba9_o.jpg this. Is this a bug in Flinfo, something wrong with Flickr, something I'm doing wrong, or something else?--User:Doug^{(talk • contribs)} 00:06, 21 October 2008 (UTC)

Hi Doug, it seems that is has something to do with the fact, that this image is hidden in flickr. --Flominator (talk) 09:37, 24 October 2008 (UTC)

I guess I don't understand something. Other users have said that they can't see these images, but I can search and view these files without difficulty. Does this have to do with the safe search filter on Flickr?--User:Doug^{(talk • contribs)} 14:15, 24 October 2008 (UTC)

I can only see the image by accessing the direct file file above. I changed safe-search but wasn't able to see them either. I think it also has something to do with the country from which you want to access the pictures. I've heard that they've blocked something for German users. May I ask where you are from? --Flominator (talk) 11:43, 25 October 2008 (UTC)

US - north of Boston.--User:Doug^{(talk • contribs)} 22:43, 25 October 2008 (UTC)

Australian War Memorial collection

Hello

The Australian War Memorial collection has joined the Flickr Commons. You can integrate it in Flinfo and Flickr2Commons. --ComputerHotline (talk) 08:53, 11 November 2008 (UTC)

Do you think, I should assign Template:PD-Australia to these pictures? --Flominator (talk) 09:56, 13 November 2008 (UTC)

I don't sure. You can read it to know the answer at the question. --ComputerHotline (talk) 19:03, 13 November 2008 (UTC)

Imperial War Museum

Hello.

Imperial War Museum has joined commons. You can integrate it in yours scripts. --ComputerHotline (talk) 19:05, 13 November 2008 (UTC)

New sites should be integrated automatically. --Flominator (talk) 11:05, 19 November 2008 (UTC)

Flinfo not working for me

When I tried using the Flinfo tool [6] I got this message:

Problem while retrieving picture http://www.flickr.com/photos/phaudio/967190500/

I used this Flickr upload tool instead:

• http://tools.wikimedia.de/~bryan/flickr/upload

So the photo is uploaded here:

• File:Tal Wilkenfeld 2007 July 28.jpg

Has the Flinfo tool been superseded by http://tools.wikimedia.de/~bryan/flickr/upload ?

Should the Flinfo link be removed from here:

• http://commons.wikimedia.org/w/index.php?title=Special:Upload&uselang=fromflickr

Please see MediaWiki talk:Uploadtext/fromflickr. --Timeshifter (talk) 11:19, 5 February 2009 (UTC)

Hi Timeshifter, no Flinfo wasn't superseeded. These are just two different tools. For the rest, see the talk page you linked. --Flominator (talk) 19:45, 16 February 2009 (UTC)

Unable to load Flinfo

For the last few hours my server has been unable to locate Flinfo. Is this the fault of my server, or is Flinfo down? --Geronimo20 (talk) 00:49, 17 February 2009 (UTC)

Flinfo date question

How do you get the time the image was uploaded? --Odie5533 (talk) 07:38, 28 March 2009 (UTC)

I receive $photo['dates']['taken'] and use strftime to format it. Sorry for the late reply. --Flominator (talk) 20:56, 17 July 2009 (UTC)

Any more Flinfo input parameters?

I wrote a {{Flinfo}} template so I can edit a list of calls to Flinfo for uploading a set of photos. Or just to document individual uploads on a user subpage of notes. I almost always want to edit the filename, description, and categories that Flinfo produces. This makes the "[Open upload form]" link less useful than it could be. It would be nice if I could tell Flinfo what to use for those three items, so the [Open upload form] link would be directly useful with no need for subsequent editing in the upload form. I would rather do all the editing in one place (on a user subpage, before I call Flinfo), which makes it easier when uploading a set of related photos that all require the same or similar corrections to filenames, descriptions, and categories. I could put those items into the {{Flinfo}} calls, and generate a link to Flinfo that would pass them as input. Otherwise, I have to make the same corrections repeatedly in individual browser tabs for each photo, which is tedious and error-prone. Does Flinfo accept any URL parameters other than ?id= ? --Teratornis (talk) 09:10, 15 July 2009 (UTC)

Hi Teratornis, nice thing you got there. I think, I can get Flinfo to use such input parameters. Just give me some time. --Flominator (talk) 20:57, 17 July 2009 (UTC)

Thank you very much. In the meantime, see my experiments with using the sed command to generate the wikitext I use to upload all photos from a Flickr photoset. If I could tell Flinfo the description text (to replace or append to the Flickr description), the categories, and the filename, I could almost automate the upload of a whole photoset in one step. Except for the need to save all the largest photo sizes to local disk. --Teratornis (talk) 21:49, 18 July 2009 (UTC)

You might want to as Magnus for access to the bot behind Flickr2Commons to avoid that, as well. --Flominator (talk) 09:41, 19 July 2009 (UTC)

Done. --Flominator (talk) 08:21, 22 August 2009 (UTC)

"Download original size" link is broken for me

I have the same problem that other users reported with the "Download original size" link - it never works for me. For example, for this photo:

• http://www.flickr.com/photos/54741439@N00/453762032/

the Flinfo result page is:

• http://wikipedia.ramselehof.de/flinfo.php?id=453762032

which displays the link:

• http://static.flickr.com/168/453762032_8ccda2f206_o.jpg [Download original size]

which always redirects to:

• http://l.yimg.com/g/images/photo_unavailable.gif (a graphic which says "This photo is currently unavailable")

The actual largest size is here:

• http://www.flickr.com/photos/pickinben/453762032/sizes/o/

--Teratornis (talk) 09:10, 15 July 2009 (UTC)

This seems to be a flickr problem with some pictures. Please use the Flickr interface and download the large version from there. --Flominator (talk) 20:59, 17 July 2009 (UTC)

Managing category redirect.

Would it be possible when a category redirect is found to provide the final category instead ? Like if the flickr tag match emu which look like Category:Emu could you propose Category:Dromaius novaehollandiae ? - Zil (d) 07:58, 26 December 2009 (UTC)

I got something in mind, that might actually work. Please give me some time. --Flominator (talk) 19:36, 22 January 2010 (UTC)

This was an interesting challenge, so I did it right away :) See this for a sample. --Flominator (talk) 20:12, 22 January 2010 (UTC)

That's wonderful. Thank you for your time. - Zil (d) 21:08, 11 February 2010 (UTC)

FlickrInfo suggestion

Instead of waiting for the upload page to tell you "This image already exists under the following name...", would it be possible for FlickrInfo to tell you "This image ID# has already been uploaded at File:X" ? It wouldn't block the information because someone may be uploading a crop, etc - but it'd still be worth pointing out to save time for interested users.Max Rebo Band^{"almost suspiciously excellent"} 19:45, 8 February 2010 (UTC)

Nice idea. Maybe using link search might work. But then you would only cat the images that are linked with the right link in their description. --Flominator (talk) 19:57, 22 February 2010 (UTC)

An odd error

I got the following error message when trying to use an id of 2614444121:

Warning: file_get_contents(http://commons.wikimedia.org/w/api.php?action=query&format=php&prop=revisions&titles=Category%3AKate+Voegele) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.0 403 Forbidden in /home/www/kunden/ramselehof.de/wikipedia/flinfo.php on line 559

I did get a text box with copyable info though. I'm using Safari 4.0.4 on Windows XP SP3.--Rockfang (talk) 01:43, 16 February 2010 (UTC)

It might be link to this. - Zil (d) 18:52, 17 February 2010 (UTC)

Can't help with why it is happening, but I've been getting the same error message the last few days. It also results in a failure to pick up categories from the Flickr page. - MPF (talk) 01:03, 21 February 2010 (UTC)

Great hint. Found this and fixing it right now. --Flominator (talk) 19:37, 22 February 2010 (UTC)

Main Categories

When a category is a main category containing {{Categorise}} ("This is a main category or subcategory requiring frequent diffusion and maybe maintenance. As many pictures and media files as possible should be moved into the right subcategories"; example: Category:Birds), would it be possible to stop Flinfo from adding it as a category to an image? That would help a lot, by preventing the placing of images in categories which should not contain images. Thanks! - MPF (talk) 01:03, 21 February 2010 (UTC)

I included it, but currently got some problems with retrieving categories at all. --Flominator (talk) 19:24, 22 February 2010 (UTC)

Done. --Flominator (talk) 19:53, 22 February 2010 (UTC)

Unusual characters

Another query ;-) . . . Flinfo doesn't appear to support unusual characters, e.g. when I tried to include the Turkish place name Kaş into a description, Flino changed it to Ka%u015F, necessitating an extra post-upload edit to correct this. Any chance of solving this? - Thanks, MPF (talk) 15:28, 21 February 2010 (UTC)

Couldn't find out what's causing it at first glance :( --Flominator (talk) 19:28, 22 February 2010 (UTC)

Location coordinates

It provides wrong coordinates. For example here it gives 49° 59' 25.8" N, 36° 13' 48.72" E, but there is no soccer stadium there. The coordinates should be near 49° 58′ 50″ N, 36° 15′ 40″ E.--Anatoliy (talk) 21:54, 8 May 2010 (UTC)

It only takes what people geotagged over there at Flickr. --Flominator (talk) 20:24, 10 May 2010 (UTC)

Errors ?

I've got errors this morning, like this one.

Warning: file_get_contents(http://commons.wikimedia.org/w/index.php?title=User:FlickreviewR/bad-authors&action=raw) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.0 403 Forbidden in /home/www/kunden/ramselehof.de/wikipedia/flinfo/FlinfoFlickr.php on line 121

Warning: Cannot modify header information - headers already sent by (output started at /home/www/kunden/ramselehof.de/wikipedia/flinfo/FlinfoFlickr.php:121) in /home/www/kunden/ramselehof.de/wikipedia/flinfo/FlinfoOut.php on line 168

- Zil (d) 11:47, 9 April 2011 (UTC)

Should be fixed now. Lupo 09:19, 19 April 2011 (UTC)

Flickr upload tool

The tool keeps blocking requests that are by default labeled All rights reserved even though the image is PD in the EXIF or description. Could you have an "ignore all warnings" checkbox installed so it is possible to override the block? Thank you. Marcus Qwertyus (talk) 17:13, 6 May 2011 (UTC)

I suppose you are referring to PEOSoldier's Flickr stream. We could basically create a whitelist for such cases (which I guess would be rare anyway). But there will be no general "ignore all warnings" switch in Flinfo. Lupo 22:41, 11 May 2011 (UTC)

Though upon second thought, such a whitelist is not a good idea. Consider this photo from PEOSoldier's photostream at Flickr. Is it PD-USGov-Military-Army? No. It's also used on the web page on that rifle @remingtonmilitary.com and in the product catalog that can be downloaded there. In fact, the original image states in the IPTC data author "Joshua Cutlip" and "Copyright ©2010 Remington Arms Co. Inc." It's a contractor's image, not a U.S. Army image, and thus indeed "all rights reserved".

Or consider this image; which unfortunately is at the Commons as File:XM2010 November 2010.jpg. It is a photoshopped image; the background has been removed, and it doesn't carry any useful copyright information in the EXIF. But it appears to me that this image was produced by removing the background from another image that is again used in the Remington product catalog (on page 3), and that it, too, is in fact an "all rights reserved" image from Remington.

Hence the tagging at Flickr was actually correct.

Just because some U.S. governmental agency like the U.S. Army publishes an image doesn't mean that they had also created the image or owned the copyrights.

Lupo 20:14, 12 May 2011 (UTC)

It has been determined through multiple deletion discussions and subsequent OTRS verification that the images are indeed freely licensed. If possible, a checkbox for turning off the filter would be very nice for uploading images that are explicitly labeled as free in the captions or EXIF data. Marcus Qwertyus (talk) 04:42, 13 May 2011 (UTC)

Are you claiming that this photo were "free"? It would also help if you could provide example links. Lupo 06:29, 13 May 2011 (UTC)

OTOH, for accounts such as the U.S. Embassy in Kabul, who seem to post their images as cc-by-nd (some as cc-by), we could set up a system in which Flinfo has a list of known Flickr accounts for which it will additionally go through the EXIF data and if that EXIF data indicates a U.S. gov't employee, it could select an appropriate license. Hmm. Would have to check several EXIF fields: description must contain "(Author/U.S. agency)", must also look in IPTC fields, Author from description must match the Author field, copyright fields must indicate a U.S. agency, e.g. "Department of State", and the list must tell flinfo to use PD-USGov-State in this case. Could be done, but each such account would have to be scrutinized individually. For instance, I wouldn't include PEOSoldier, but the Kabul embassy looks OK. Lupo 10:51, 14 May 2011 (UTC)

Selective whitelisting

All right; I've implemented selective whitelisting. Try it e.g. with this image; Flinfo should recognize it's actually PD. This only works for explicitly whitelisted Flickr accounts, and only if Flinfo can indeed find some indication in the EXIF for a free license. Currently, the following accounts are whitelisted: U.S Embassy Kabul Afghanistan, The U.S. Army, US Army Africa, U.S. Department of Defense Current Photos, and United States Forces - Iraq.

If you find other accounts, feel free to ask for whitelisting here. Unfortunately, I'll have to examine each candidate's photo stream manually to figure out what exactly they put in the EXIF; these guys can be pretty inconsistent in their tag usage; I have to write tailored Flinfo-configurations for each candidate. Lupo 11:26, 15 May 2011 (UTC)

Thanks.

Let me say that flinfo is a great tool, one I may have used over 1000 times. So thanks in general for this tool.

There is at least one USCG site that should be whitelisted. I`ll let you know which one, when I remember.

I don`t know if you saw my account of writing a flickrmail to flickr-id ISAFmedia, about their application of restrictive liscenses to images taken by American GIs. Someone junior wrote me back, telling me the liscense they applied was the one they had been ordered to use. But the boilerplate at the bottom of their flickrmail included the email address of a superior officer. I wrote them and ISAFmedia changed the liscense to all their images to a free liscence. But that free liscense is only appropriate for images from American GIs, and ISAF is an International force, so a significant fraction of its images are crown copyright, or otherwise non-free. I try to be responsible and only upload those I think were really taken by American GIs. Geo Swan (talk) 16:01, 15 May 2011 (UTC)

Well, ISAF is NATO, not a U.S. federal entity. It's annoying they publish U.S. Army photos under CC-BY, but at least that's Commons-compatible. Flinfo can't do anything about this, as the EXIF at Flickr does not contain any copyright information. But it appears you can find the U.S. photos on the ISAF account also on DVIDShub, compare e.g. this ISAF photo and this DVIDShub photo (found through a simple Google search for the first sentence of the description). You could use that latter link to make a case for {{PD-USGov-Military-Army}}. Flinfo cannot do it for you, it has no way to ascertain that any DVIDShub link that it might find actually referred to the same photo. Lupo 21:27, 15 May 2011 (UTC)

Also whitelisted now is Official U.S. Air Force. Lupo 21:27, 15 May 2011 (UTC)

And now also United States Marine Corps Official Page. Though their use of EXIF is very erratic, so Flinfo does not unlock all their images. It only "unlocks" an image if it can indeed find positive indication for a free license or PD status. Lupo 22:01, 15 May 2011 (UTC)

• Here is another flickr-id http://www.flickr.com/photos/usjfcom/... Geo Swan (talk) 22:00, 21 May 2011 (UTC)

  Done. Lupo 16:30, 22 May 2011 (UTC)

  Also done: Former U.S. Navy Gallery (Navy Visual News Service). Lupo 16:47, 22 May 2011 (UTC)

  +U.S. Central Command (CENTCOM)

  +U.S. Embassy Canberra, Australia

  +U.S. Pacific Fleet

  +U.S. Coast Guard

  +U.S. Pacific Fleet Command (PACOM)

  +U.S. Navy

  +Defense Media Activity Hawaii

  Lupo 10:49, 23 May 2011 (UTC)

  +NATO Training Mission-Afghanistan; despite the name, most of their photos are from the U.S. military. Most but not all have EXIF data giving clear PD-US indications. Lupo 21:46, 24 October 2011 (UTC)

FlickreviewR

The only issue now seems to be how to teach FlickreviewR about this. See e.g. File:A Kawasaki mule adapted to become a firefighting vehicle in Kabul -b.jpg, where FlickreviewR failed the review because the license displayed at Flickr is cc-by-nd.

Possible solutions for such cases:

1. User shall remove the {{Flickrreview}} tag, either before or after upload.
2. Flinfo does not generate a {{Flickrreview}} tag in such cases.
3. Flinfo generates a {{flickrreview|Flinfo|~~~~~}} tag for such cases.
4. FlickreviewR is updated to recognize and correctly validate such cases.

(1) is the current situation. It has the major drawback that the review bot will not run on the image, and will therefore not upload the image at the largest resolution. (2) is also a possibility, but do we really want this? It has the same drawback. (3) is not such a good idea because Flinfo has no account here and is not a human; and again, if the user uploads a small version, no bot will automatically upload the larger version.

(4) is IMO the only real option, though it might be tough to get implemented, as I don't know how actively this bot is maintained. Technically it's not that difficult; the bot might simply call Flinfo's API, requesting raw, json, or php output, and see if that contained a matching {{FlinfoExifLicense}} in the permission info. If that approach were chosen, I could even provide a quick check API that the bot could call with the image ID and that would return only the {{FlinfoExifLicense}} (if any) that Flinfo generates for that image. Flinfo not always uses the Flickr API to get the EXIF; Flickr reports sometimes "Permission denied" (for instance, for all the Official U.S. Air Force images). In such cases, Flinfo gets the EXIF directly from the image. That's something the FlickreviewR should account for if it is to re-do the checking itself, and thus calling Flinfo for the check would probably be better (and simpler for FlickreviewR).

Lupo 09:36, 19 May 2011 (UTC)

For the time being, whatever you do, make sure you upload such images in the full resolution. Flinfo gives you the link. Lupo 14:59, 19 May 2011 (UTC)

Extraction of info for files aready on commons

The file File:Ardea humbloti.jpg has had a change of license on Flickr, so when I wanted to use Flinfo to do the work to get the geo-location I could not do this. I would like to use Flinfo to update info of files already on commons, when the previous information extraction was inadequate. White-listing should be overridden in these circumstances. Snowmanradio (talk) 07:27, 30 May 2011 (UTC)

Flinfo does not know whether or not a particular image is already at the Commons, and it has no reliable way to determine this on its own. If you just wanted to know the geolocation, you could click on the map shown at the Flickr page, which takes you to this map. Then click on "Link to this map" in the upper right corner; the link contains the coordinates. Lupo 15:46, 30 May 2011 (UTC)

Quite, the bot does not know whether the image is already on commons or not, so why let it block the facility of finding the geo-coordinates for use on an image already uploaded to commons when its licence on flickr has changed. Without using Flinfo, I still can find out exactly what to put on the image after clicking on several links. Snowmanradio (talk) 17:24, 30 May 2011 (UTC)

So why should we update Flinfo if you can find the information you're looking for using other means? Flinfo is a tool to facilitate image uploading. The task you propose is not related to that at all. Lupo 19:44, 30 May 2011 (UTC)

User:Lupo wrote: "Flinfo does not know whether or not a particular image is already at the Commons, and it has no reliable way to determine this on its own." OK, while it can't definitively guarantee an image isn't already uploaded to the commons, it does compute a canonical URL for each image -- the URL it will place in the information template. Flickr could check to see if that URL is in use on Commons. It could warn the user, just as it warns the user now when they are trying to upload an image with the same name as an existing image. Personally, I would love to see flinfo perform this check. Geo Swan (talk) 18:39, 27 August 2014 (UTC)

@Geo Swan: Now that's an idea.  Done. Note that this doesn't find images already at the commons that are linked to using non-standard URLs. Lupo 15:51, 30 August 2014 (UTC)

Support for deviantART

Some days ago an experienced user from de.wp asked about support of deviantART. Would you consider this feature necessary? At least they have an API. Regards, --Flominator (talk) 17:47, 12 November 2011 (UTC)

I don't see anything about license info neither on the few pages I just visited there nor in their API description. Also, from what I've seen from deviantArt so far (it's not much, admittedly), there may also be lots of derived works and parodies there, for which third-party copyrights come into play. User-created art is not exactly useful for most of the projects. I don't think we need a flinfo plugin for the few exception where such works might be appropriate and be appropriately licensed. Lupo 14:21, 13 November 2011 (UTC)

JavaScript allergy

I realize I might be in a minority but JavaScript gives me rash. Is there a way I could use this handy tool without JS? Palosirkka (talk) 11:24, 18 March 2012 (UTC)

Flinfo uses JS only for the "open upload form" button, and sometimes to fix the layout of a warning message. Everything else works just as well with JS disabled. Hence to upload, open the Commons' upload form yourself, fill in source and destination file names, and copy-paste the output from Flinfo into the summary box. Lupo 13:21, 18 March 2012 (UTC)

Right. Thanks for the explanation and the tool! Palosirkka (talk) 13:13, 19 March 2012 (UTC)

Non-free licensed files

• http://wikipedia.ramselehof.de/flinfo.php

Hi, I am using your tool through Mediawikiwiki:Manual:Pywikipediabot/flickrripper.py. There is a problem ([7] v [8]) when the code meets a work that is fully copyrighted because sometimes I need to upload files that appear fully copyrighted but have OTRS permission. While I agree that your check for copyrighted files is needed, I also feel that it should be possible to override it.

I do not know if you are developing flickrripper.py as well but I may have a few suggestions for that as well.

-- とある白い猫 ^ちぃ？ 16:08, 14 August 2012 (UTC)

you've got mail --Flominator (talk) 19:24, 14 August 2012 (UTC)

I have the same problem. matanya • talk 23:57, 15 November 2012 (UTC)

Problem with Import of a Public Domain photo from MO

Hello, I've tried to import a photo (which is Public Domain) from Mushroom Observer to Wikimedia Commons but Flinfo shows me the message "Licensed at the source as "http://wiki.creativecommons.org/Public_domain" which is no free license. Bild ist nicht frei lizenziert." Could you help me please? --Ak ccm (talk) 08:27, 14 May 2013 (UTC)

Please give me the source link to file at MO. Lupo 08:32, 14 May 2013 (UTC)

Here you could find the photo: http://mushroomobserver.org/image/show_image/327272?_js=on&_new=true&q=1El3o --Ak ccm (talk) 08:36, 14 May 2013 (UTC)

The problem is that MO uses the wrong license URL. They use http://wiki.creativecommons.org/Public_domain but the correct license URL would be http://creativecommons.org/publicdomain/mark/1.0/ and even that is not the best choice, http://creativecommons.org/publicdomain/zero/1.0/ would have been better. Anyway, I've added code to handle that; their curious license identification gets now treated as {{Pd-author}}, with the author filled in. When I have more time (tonight), I might add something to translate this automatically to {{PD-USGov-USDA-FS}}, but that's a bit more work. In any case, this should be fixed now. Lupo 09:18, 14 May 2013 (UTC)

Thanks, I will test it later. At the moment I've got a new problem with uploaded photos: they contained the wrong license template "Cc-by-sa-http:":

• http://commons.wikimedia.org/wiki/File:2012-08-18_Agrocybe_dura_%28Bolton%29_Singer_250954.jpg
• http://commons.wikimedia.org/wiki/File:2012-08-18_Agrocybe_dura_%28Bolton%29_Singer_250955.jpg

Sorry, that was a stupid mistake. Fixed. Lupo 13:34, 14 May 2013 (UTC)

Thanks again. --Ak ccm (talk) 14:25, 14 May 2013 (UTC)

Authorship info missing for Panoramio files (and other stuff)

A few bugs and wishlist items:

1. I'm guessing it's got something to do with Panoramio's recent redesign, but authorship information is no longer being extracted correctly. (I believe it used to be.) The author field is left blank. As this information is legally required, I believe that fixing this should be a priority.
2. I frequently clean up sloppy uploads done using the Upload Wizard with help of this tool. (Thanks!) It would help keep the diffs cleaner if the {{Information}} parameters were in the same order and capitalised the same as in the Upload Wizard, i.e. description, date, source, author, permission and other_versions. I don't really care whether or not you include other_fields, because I usually remove the empty parameters anyway.
3. The link name for the source is a lower-case "panoramio". This could be made a bit tidier by grabbing the title of original image at Panoramio. (Perhaps the current behaviour is just a fallback caused by the redesign.)

Thanks again for a very helpful tool! —LX (talk, contribs) 19:28, 24 October 2013 (UTC)

1 and 3  Done. Both were caused by the panoramio redesign. Unfortunately they have no API to get information about a single photo, so flinfo has to sift through the page HTML. (2) not done: flinfo uses the same order and capitalization as the old upload form. Maybe that should be synchronized first with the UploadWizard, otherwise, whatever I do, Iit'll make some people unhappy. Lupo 14:27, 25 October 2013 (UTC)

"Blacklisted user"

Where is this blacklist? Why is a user on it? (please include this in the Flinfo error message) Palosirkka (talk) 19:15, 11 November 2013 (UTC)

Please see Commons:Questionable Flickr images. Lupo 23:15, 11 November 2013 (UTC)

Thanks. I love Flinfo! Palosirkka (talk) 08:03, 12 November 2013 (UTC)

Missing header

Hello,

When uploading files, the header is missing (=={{int:filedesc}}==). Thanks for your great tool. Yann (talk) 06:57, 24 November 2013 (UTC)

This header is generated by the WMF servers after an upload is done and the file description page is created. Flinfo produces a {{Information}} template that can be put as is in the old upload form. It's then the WMF server's business to handle the upload and to create the file description page, including all the right headers. Flinfo does create the =={{int:license-header}}== header because the license info will be in the description field; the server will thus not create that header. But since the server will see a description, it should create the =={{int:filedesc}}== header automatically. Lupo 10:31, 24 November 2013 (UTC)

Help

I want to develop software like this for all websites. Please tell me the source code. Plaese --Sridharbsbu (talk) 10:53, 15 December 2013 (UTC)

For all websites? Not doable. Each website is special. Some have APIs that can be used to obtain image metadata (such as license, description, author, and so on), other don't and then you're limited to analyzing the HTML. The HTML of course differs from website to website, and so do the APIs, if any.

Flinfo currently can deal with Flickr, ipernity, panoramio, Picasa, Mushroom Observer, Insect Images, Invasive Species, Weed Images, IPM Images, Forestry Images, and LeMill. Did you have a particular website in mind?

Cheers, Lupo 14:23, 15 December 2013 (UTC)

Any way. But please give source code based on that I want to develop another tool.--Sridharbsbu (talk) 14:01, 19 December 2013 (UTC)

The source code of flinfo is available at gitorious. Lupo 09:41, 28 June 2014 (UTC)

Flinfo not working

All I get is a blank page. This has been so for a few days now. What's up? Palosirkka (talk) 18:47, 8 January 2014 (UTC)

I also get the same blank page. I have just found that works the following link: http://wikipedia.ramselehof.de/flinfodev.php5 Jacopo Werther ^iγ∂ψ=mψ 19:09, 8 January 2014 (UTC)

Thanks alot! Works for me as well. What a handy tool. Palosirkka (talk) 20:03, 8 January 2014 (UTC)

Thanks for the report. Should be fixed now. The hosting provider changed their configuration. The usual links http://wikipedia.ramselehof.de/flinfo/ or http://wikipedia.ramselehof.de/flinfo.php work again. Lupo 18:25, 9 January 2014 (UTC)

Certainly works for me now! Thanks alot! Palosirkka (talk) 14:59, 11 January 2014 (UTC)

Bad response from server (403)

I keep getting that for a few hours now I believe. Palosirkka (talk) 19:45, 27 June 2014 (UTC)

Thanks for the report. Flickr returns that 403. They newly require https, while flinfo still used http. Is fixed now. Lupo 21:18, 27 June 2014 (UTC)

Thanks alot mate! I love flinfo, it has put so many good images on commons! Palosirkka (talk) 08:15, 2 July 2014 (UTC)

Upload warning

(previously posted at the help desk, but I see this is the more appropriate spot to place this question)

I'm currently uploading files from Flickr through Flinfo, which eventually opens an upload browser that is not the normal upload wizard (but it works in conjunction with Flinfo and gets all the info from Flickr across), and I'm getting the following warning with this file: "This file contains HTML or script code that may be erroneously interpreted by a web browser." Some questions:

1. What does this mean?
2. What can I do about it?
3. Why isn't the error message linked to a page that gives more context? Schwede66 23:41, 27 June 2014 (UTC)

As the message says:

1. The file contains some HTML in the EXIF data; see here: it's the "Caption-Abstract" EXIF entry.
2. Remove the HTML from the offending metadata entry from the exif, for instance using exiftool.
3. I don't know. What more context did you expect?

Lupo 09:39, 28 June 2014 (UTC)

Thanks for pointing me in the right direction. I've got myself exiftool, struggled around for a long time (my 'failure' is that I'm not a programmer or Linux user, and I'm struggling with command line entries), got on top of it when I downloaded the GUI that runs this tool, and from then on it was pretty easy. So, to make this accessible to others, I suggest you create a little entry in the Flinfo documentation along these lines, and then link to it from the error message: "To remove HTML from an image file's metadata entry, you will need to have access to software that allows you to edit such metadata. A suitable free tool is exiftool, and it is relatively simple to use in conjunction with ExiftoolGUI. Place both tools in the same folder on your computer before you start the GUI." I only arrived at that point after mucking about for a long time and if somebody had given me those simple instructions, it would have been much more plain sailing. What do you think? Schwede66 04:13, 29 June 2014 (UTC)

Excellent suggestion. I've written a FAQ entry and linked it from the error message. Feel free to improve the FAQ entry. It's a wiki after all! Lupo 10:35, 29 June 2014 (UTC)

Great FAQ; reads well and gets it all across. I'm glad that I've invested the time in working through this, as something really useful has come from it. Schwede66 09:28, 30 June 2014 (UTC)

Completely agree with Schwede66, great job! Thank you, thank you both! <3 Palosirkka (talk) 08:55, 2 July 2014 (UTC)

Hi, I have problems uploading a photo from Flickr as I get the warning "This file contains HTML or script code that may be erroneously interpreted by a web browser." I tried to remove all exif data, but it's still not working. I'm talking about this file: https://www.flickr.com/photos/nationalarchives/7838528332/. Your help is highly appreciated.--Ion Tichy (talk) 14:47, 8 January 2019 (UTC) It works now, don't know why it didn't yesterday.--Ion Tichy (talk) 14:55, 9 January 2019 (UTC)

Flinfo issue 1?

I've been getting this error message pretty often, on properly free-licensed files with short names, forex https://www.flickr.com/photos/jsjgeology/14736672692/ Renamed to Homestake Mine gold ore.jpg

What's this mean? Usually seems to happen when loading photosets. --Pete Tillman (talk) 20:30, 1 August 2014 (UTC)

Uploaded just fine on a 2nd try as a single foto: File:Homestake Mine gold ore, town of Lead, northern Black Hills, western South Dakota (3.6 cm acr.) (14736672692).jpg

Are you sure you're using Flinfo? I am not aware of any such error message in Flinfo. Flinfo doesn't load photosets, and it has no problem with the image you linked above. Lupo 08:23, 4 August 2014 (UTC)

Largest available Picasa image

Here Flinfo offers .../s1600/pa154601.jpg as the largest available image size. This has most of the EXIF data missing. I think the correct link should be .../d/pa154601.jpg. Pikne 08:35, 27 August 2014 (UTC)

Thank you for reporting this.  Done Flinfo previously used the original link (.../d/...) only if it was larger than the largest thumbnail available. It now also does so if the original has the same size as the largest thumbnail. Lupo 19:29, 27 August 2014 (UTC)

Please...

@Flominator and Lupo: ...read this! Josve05a (talk) 22:25, 4 September 2014 (UTC)

 Done. Lupo 13:30, 5 September 2014 (UTC)

 Thank you. Josve05a (talk) 00:42, 6 September 2014 (UTC)

Categories + Flickr2Commons

@Lupo and Flominator: Please refer to this twitter conversation betwen me and Magnus Manske: link. Josve05a (talk) 21:52, 16 July 2015 (UTC)

Fixed. Lupo 16:11, 28 July 2015 (UTC)

Public DOmain Mark on Flickr != PD-author

File:UMAG Facultad de Ingenieria - Facultad de Ciencias (15843250798).jpg should not be uploaded with the PD-author-template, but with {{subst:Flickr-public domain mark/subst}}. Josve05a (talk) 15:52, 30 January 2016 (UTC)

Ping @Lupo, Flominator, and Magnus Manske: . Josve05a (talk) 15:53, 30 January 2016 (UTC)

Federal Reserve & DHS Template

Can someone write it so that photos from Flickr user 92618257@N08 get tagged with Template:PD-USGov-Federal Reserve instead of just Template:PD-USGov? This would be similar to how the Navy images get automatically tagged with Template:PD-USNavy. Also, images from 54593278@N03 should get tagged with Template:PD-USGov-DHS. Elisfkc (talk) 00:58, 8 April 2016 (UTC)

@Lupo: Do you have any chance to fix those two requests or should I try to get back in touch with the code? Regards, --Flominator (talk) 16:15, 21 May 2016 (UTC)

 Done in this commit. Lupo 15:33, 22 May 2016 (UTC)

@Lupo: Thanks. What about the one above this one? --Flominator (talk) 18:11, 22 May 2016 (UTC)

Was  Done long ago. Lupo 20:18, 22 May 2016 (UTC)

System Error

The system seems to be down right now, causing issues with Flickr2Commons. Elisfkc (talk) 18:44, 10 May 2016 (UTC)

Fixed, webhosting provider had a problem. --Flominator (talk) 16:12, 21 May 2016 (UTC)

Wrong category

Excellent tool. During my most recent upload File:Danny Bhoy - Just For Laughs Festival Montreal 2009.jpg: it generated the following cats: Category:Comedy, Category:Up, Category:Anatoly Tsapenko, Category:Festivals, Category:Juste pour rire, From here, I have no idea what Up and Anatoly Tsapenko are or how did it get fetched, assuming the tool uses keywords, right? Ugog Nizdast (talk) 17:30, 22 November 2016 (UTC)

@Ugog Nizdast: up came from the tags of [9], no clue about Anatoly Tsapenko, though. Lupo? --Flominator (talk) 19:57, 22 November 2016 (UTC)

There are funny tags on this image: "Just" "For" "Laughs". Somehow the tag "Just" ended up (probably through Category:Files by Just‎) providing Anatoly Tsapenko. Lupo 17:33, 25 November 2016 (UTC)

Actually, through the category redirect Category:Just. :-) Lupo 17:42, 25 November 2016 (UTC)

System Error

The system seems to be down right now, causing issues with Flickr2Commons. Elisfkc (talk) 19:08, 2 March 2017 (UTC)

Seems to work fine now. No idea whether it didn't work at 19:00 on 2017-03-02, or what was up. Lupo 11:38, 3 March 2017 (UTC)

Potential duplicate entries due to Flickr profile change

Hi!
Joost J. Bakker (no longer existing profile in Flickr) and PhotosForFree 333 (who had several user names in Flickr these last years, this one being the last one) appear to be the same person. But Flinfo don't "see" it, and allows to make duplicates of files already uploaded as Joost J. Bakker's work. See this Flickr Renault 16 and its already uploaded sibling, for example, or this Renault Colorale and this one already present in Commons.
Is there a way to fix it, please, or even just a tip to avoid checking through the 3,888 pictures made by Joost J. Bakker when trying to upload a file from PhotosForFree 333? Or would a merge of the 2 categories make things easier? Regards. -- BarnCas (talk) 06:09, 24 September 2017 (UTC)

@BarnCas: If the files are binary identical there should be a way. Can you link to a new existant example please? --Flominator (talk) 12:22, 28 October 2017 (UTC)

Whitelist addition

Can you add the City of Orlando Flickr stream to the whitelist, with the license being set at {{PD-FLGov-Orlando}}? I am planning on adding photos from that account, and I have a pending OTRS ticket (#2017120410010589) proving the Public Domain aspect. Thanks, Elisfkc (talk) 19:26, 5 December 2017 (UTC)

@Elisfkc: Did the ticket meanwhile get approved? --Flominator (talk) 15:40, 28 March 2018 (UTC)

@Flominator: Not sure, I'm not an OTRS volunteer. Elisfkc (talk) 15:54, 28 March 2018 (UTC)

The ticket was a forwarded statement that all conetent on their official pages are created by city employees. I, as a OTRS agent and admin, agree thatthis account should be whitelisted unless evidence found to do otherwise. --Jonatan Svensson Glad (talk) 12:29, 31 March 2018 (UTC)

@Lupo: I added 41134062@N06=cityoforlando=PD-FLGov-Orlando to the flickrusgov.txt but it doesn't work anyway. Is this because pictures are licensed with "all rights reserved"? --Flominator (talk) 14:15, 1 April 2018 (UTC)

@Elisfkc, Josve05a, and Lupo: The ticket is now directly approved. I tagged the two files it mentions.   — Jeff G. ツ _{please ping or talk to me} 18:57, 25 April 2018 (UTC)

@Jeff G., Josve05a, and Lupo: Sorry I've been really busy and totally forgot about this. Did we ever figure out how to white list this? Elisfkc (talk) 03:09, 23 June 2018 (UTC)

Mushroom Observer

Tracked in Phabricator
Task T187302

Hello I, and also a colleague, regularly use the tool in order to upload images from Mushroom Observer. Is it possible that the tool don't add a header == {{int:filedesc}} == because it is also automatically added by the uploading tool, and then we have to remove one of the header? Christian Ferrer ^(talk) 18:11, 14 March 2018 (UTC)

@Christian Ferrer: Please see phab:T187302 and COM:VPP#Proposal to stop Special:Upload and Special:UploadWizard from adding headers to file description pages automatically.   — Jeff G. ツ _{please ping or talk to me} 00:35, 15 March 2018 (UTC)

ah ok, it is maybe better to wait, thanks you. Christian Ferrer ^(talk) 05:39, 15 March 2018 (UTC)

Try the Upload Wizard instead

I click on "open upload form" and the page says "Try the Upload Wizard instead." I click that and have to do everything from scratch. I could have just skipped the FLinfo steps and not lost anything. what's going on? --NessieVL (talk) 14:18, 17 August 2018 (UTC)

Error

Me sale el siguiente error:

Error 403: your request was denied

Possible causes for this error are:

• No index page (e.g. index.php or index.html) was found

• Your request was denied by our web application firewall. In case you are the operator of this website, you are able customize or disable the Web Application Firewall in our control panel web180.dogado.net:8443.

MiguelAlanCS (talk) 15:52, 23 June 2019 (UTC)

See also COM:VPT#Flickr upload tool.   — Jeff G. ツ _{please ping or talk to me} 16:04, 23 June 2019 (UTC)

Bug in the case of Mushroom Observer

Hi, the tool don't seems to work anymore with Mushroom Observer. Christian Ferrer ^(talk) 03:49, 15 June 2020 (UTC)

I also cannot get it to work with Mushroom Observer. I want to download image 1228870, but always get the message "Problem while retrieving image 1228870", though I can download the image myself at https://mushroomobserver.org/images/orig/1228870.jpg. When I use that URL in Flinfo it understands it but gives the same result. Strobilomyces (talk) 09:00, 31 August 2020 (UTC)

I downloaded PHP to my PC, installed Flinfo, and reproduced the error locally. When I added one statement to the program, it started working OK. The statement was 'curl_setopt($request, CURLOPT_USERAGENT, "PHP");' added to method newRequest of file Curly.php. The effect of the statement is to set a Curl option which causes the user agent header string to be included in the https request. Apparently Mushroom Observer now requires that parameter to be set. By the way, the code does issue numerous warnings, perhaps because I am using a different version of PHP. The change applies to all repositories - I don't know if that could be a problem, but I don't think so.

So now I can use Flinfo locally, but it would be good to install the same change in the public version. Could anybody tell me how I should go about arranging for that? Strobilomyces (talk) 12:00, 3 October 2020 (UTC)

Thanks for looking into it, Strobilomyces. Feel free to create a merge request at [10] (maybe user agent "Flinfo" would be nicer?). Anyways I deployed your version with "PHP", let's see if that works. --Flominator (talk) 13:54, 3 October 2020 (UTC)

Thanks for answering. At present with http://wikipedia.ramselehof.de/flinfo.php?id=1254599&repo=mushroom&user_lang=en I still get the "Problem while retrieving image" error. Strobilomyces (talk) 18:26, 3 October 2020 (UTC)

On my PC I changed the string from "PHP" to "Flinfo", and it still works. Strobilomyces (talk) 18:33, 3 October 2020 (UTC)

Looks like I caught the wrong line, now it works, Strobilomyces. --Flominator (talk) 18:36, 3 October 2020 (UTC)

@Flominator and Christian Ferrer: Yes, it works for me now. Thank you very much for your intervention.

Now I don't have much motivation to create a merge request at present. If you would like me to, please could you tell me where I can find instructions how to use GitLab in this context? Strobilomyces (talk) 19:06, 3 October 2020 (UTC)

URL/duplicate Mushroom Observer

• I just use managed to use upload Flinfo and to upload File:Clitopilus prunulus (Scop.) P. Kumm 696104.jpg, however 2 points: 1/ I had to generate myself the URL to upload the image, I took "https://mushroomobserver.org/images/orig/" and added "696104.jpg" I could not take the URL provided by MO https://mushroomobserver.nyc3.digitaloceanspaces.com/orig/696104.jpg because the domain is not whitelisted. 2/ Flinfo don't say the image is now already here (http://wikipedia.ramselehof.de/flinfo.php?id=696104&repo=mushroom&user_lang=en), if I remember well he did. Christian Ferrer ^(talk) 06:32, 4 October 2020 (UTC)

@Lupo: Can you help here? --Flominator (talk) 13:23, 7 November 2020 (UTC)

No time. But see the banner at their site: "We are having technical issues with our image server for older images. We’ll update this banner as we learn more."[11] It should not be necessary to deal with some back-end server domain name. Lupo 16:43, 10 November 2020 (UTC)

Flinfo not working for Mushroom Observer again

When I try to load image 1533158 from Mushroom Observer, I get error "Problem while retrieving image 1533158." If I give the whole correct URL "https://images.mushroomobserver.org/orig/1533158.jpg", I get "Cannot determine image ID from input https://images.mushroomobserver.org/orig/1533158.jpg". The format of the URL to get the Mushroom Observer image has changed from something like "https://mushroomobserver.org/images/orig/1533158.jpg" to something like "https://images.mushroomobserver.org/orig/1533158.jpg". Please could someone update Flinfo according? Otherwise this useful tool will not work again for MO. Strobilomyces (talk) 20:55, 12 January 2023 (UTC)

Hello. I have spent a little more time on this problem now. The links to Mushroom Observer in File pages previously generated by FlInfo no longer work without log-in (except that strangely the observation pages like "https://mushroomobserver.org/observer/show_observation/480069" and some other links do work without log-in). That is perhaps not too terrible as users just have to log in once and after that the links use the browser cookie to connect.

But there seem to be lots of changes needed to the interface used by FlInfo; perhaps it is necessary to use the official Mushroom Observer API, which requires authentication. Strobilomyces (talk) 20:35, 30 May 2023 (UTC)

In fact, I was wrong to suggest above that authentication is necessary to get the required information from the new Mushroom Observer interface. The interface is documented at [12]. Given the observation number, a Json file of the information required can be obtained with an API call without authentication like https://mushroomobserver.org/api2/observations?id=513648&detail=high (where the observation number is 513648). You can get the observation number from the image number with a call like https://mushroomobserver.org/api2/images?id=1645884&detail=high (where 1645884 is the image number). So I think it would be possible to make Flinfo work for Mushroom Observer again. Strobilomyces (talk) 20:41, 15 January 2024 (UTC)