User talk:Drecodeam/GSoC 2012 Application

If you're serious about Flickr integration, then by all means consider including Flinfo as an extension into MediaWiki. Flinfo would give you not only proper license detection (and wikified descriptions and geocoding and categories and...) for Flickr images, but also for panoramio, Picasa, ipernity, and a number of other minor repositories out there. Flinfo sources are (L)GPL and are available; see bugzilla:28731 where to find them. The currently latest version is V2.6a.

For Flickr images, Flinfo even respects the Commons' blacklist at commons:User:FlickreviewR/bad-authors. If exiftool is installed, it can even be configured to extract license info from EXIF/IPTC tags. (For instance, some U.S. government agencies post their stuff as CC-BY-ND or ©ARR at Flickr, but the IPTC may say "Copyright:Public domain". See e.g. Flickr image #7002155961.)

For testing, you could even consider querying the live Flinfo without integrating it into MW at all; it has an API that can return JSON or serialized PHP. Examples:

• Human-readable JSON output
• Human-readable PHP output

Use "&format=json" or "&format=php" to get application-readable output.

In Flinfo, all the API issues (Flickr, Picasa, ipernity, ...) are already solved, as is the transformation into wiki-format. There's no need to reinvent the wheel here.

For a real integration, you'd have to port Flinfo into an MW extension. The server it currently runs on doesn't do HTTPS, only HTTP, and it's not on a *.wiki[mp]edia.org domain, and furthermore I'm not sure it'd stand up to the request volume that was to be expected if it was queried from the Upload Wizard.

Lupo (talk) 08:47, 3 April 2012 (UTC)

Thanks a lot for the feedback Lupo, i really appreciate it. I have asked my mentor User:Kaldari about his comments on this, since he started doing work in this direction, he would be able to better guide me over the integration part.

I agree that Flinfo would be a solid foundation; my own Flickr2commons uses it as the description generator. I do add my own geolocation box, but you'd do that anyway according to your proposal. A few more ideas:

• Make the data and description source handlers generic. Flinfo already supports several sources, but there are also the ones here, and upcoming ones like Europeana.
• One important source for files are other Wiki(m|p)edia projects, mostly local Wikipedias. I have a tool for that as well, however, parsing Wikitext can be painful :-(

I think that given the time constraints, i would not be able to integrate other services, but i would surely work on them as soon as i finish the proposed set of deliverables.

• Allow adding of a Flickr stream (full or tag-filtered) or set from a user, as I do in flickr_mass.php

Yes, i would be doing that and would be implementing the interface for the same.

• The upload interface for multiple files could do with some cross-file functions, like "add all these files to a category", or "add a single template to all these files".

This is a very helpful feature and is already been requested bug 26065. I would work on this and implement it in the interface.

• Not sure if this is done already, but highlight/block upload of all files that already exist on Commons

It is already been done in the current wizard

That's all I can think of for now... --Magnus Manske (talk) 13:10, 5 April 2012 (UTC)

Thanks for the suggestions Magnus, Its really appreciated. Like i replied to Lupo, i have started discussing this with my mentor User:Kaldari since he would guide me better.

Maps

Just a heads up about this.

If you make the UploadWizard Extension be able to (optionally) depend on the Maps extension, you're introducing a new extension that isn't reviewed/approved for deployment for WMF usage, and as such would be a large amount of code.

Not wanting to put you off, just wanted to make you aware!

Reedy (talk) 16:48, 5 April 2012 (UTC)

Thanks Reedy, i was not aware of this information. My idea was not to make UploadWizard Extension depend on the maps extension, but rather study and reuse the code written in the Maps extension, as suggested in the Geolocation specs.

Regarding metadata

Hello,

Really excited about this project!

Just wanted to notify you about a problem with metadata. Flickr images on free accounts, when downloaded, do not have the metadata embedded, and this information (camera model, etc.) can be quite useful. The metadata is, however, stored on the server, and can be re-embedded into the images. I wrote a script for dong this: Commons:User:InverseHypercube/flickr_exif.py. Do you think you could implement similar functionality?

Thank you! InverseHypercube (talk) 18:18, 5 May 2012 (UTC)

I would definitely want to integrate it, although I would only be able to do it once I am done with direct uploading of media from Flickr. Thanks a lot for pointing out this issues to me