Last modified: 2014-05-06 12:15:48 UTC
Passing a flickr set (album) with more than 50 items only loads the first 50 items. It possibly makes sense to set a maximum of images a user can upload at once, but if we want to select only a few of the set's images, we can't access those past the 50 mark. Besides, no message is presented to the user to tell them that only 50 of the set's images have been loaded.
50 is hardcoded (not sure why?) If there are problems uploading more than 50 images at once the user should be provided with a pop-up asking for the limits eg. 1-50, 51-100..
Something like http://jqueryui.com/slider/#range seems plausible
On rethinking I figured that we can simply limit the selectable images to 50. https://gerrit.wikimedia.org/r/#/c/42385/ does this. However, a small message is needed that informs the user that he can select only 50 images at one go.
Actually, it turns out we may need to reduce the number rather than increasing it. The Flickr API ToS say that 3rd party applications can only display up to 30 images per page. I guess what we need to do is implement some sort of pagination system which shows 30 images at a time.
(In reply to comment #4) > I guess what we need to do is implement some sort of > pagination system which shows 30 images at a time. I don't completely get how the pagination should be done.. after entering the URL can the user select more than 30 images? Any particular reason why 50 has been set as the upload limit?
(In reply to comment #5) > after entering the URL can the user select more than 30 images? There definitely should be a way to access the images of a 30+ set past the 30th mark! The limit of 30 images from the Flickr API ToS [1] seems to be for display only; as I see it, the user should be able to select more than 30 images if he does so from subsets (pages) of 30 images each. That said, there should indeed be a (conceptually different) upload limit for commons, which should be set based on software limitations and community consensus (we don't want users uploading thousands of images at once erroneously or maliciously, and in fact the ToS also say that we shouldn't "use an unreasonable amount of bandwidth") 1. http://www.flickr.com/services/api/tos/ -- section 1.b.iii
The 50 number was a completely arbitrary choice. It was just a number to start with for testing purposes. Ideally, we should allow the user to browse through all the images of a photoset with some sort of pagination or infinite scrolling system. I also think we shouldn't allow the user to actually upload more than 100 images at a time, as the chances of something going wrong with uploads larger than that is rather high. If we allow them to paginate though the set, they can always continue uploading where they left off.
Attempt 2 with infinite scrolling https://gerrit.wikimedia.org/r/#/c/45951/
Just got a reply back from Ross Harmes, an engineering manager at Flickr/Yahoo: "I think that it would be fine to display more than 30 images in your tool (as thumbnails). It does technically violate the ToS, but not in a way that is likely to get your API key deactivated. Use your best judgement as to how many images to show here." So it sounds like we would be OK with an infinite scrolling or client-side pagination interface. I would still like to limit the number of images you can select for uploading at one time to some arbitrary number (50? 100?), but allow the user to choose from all the photos in the set.
(In reply to comment #9) > Just got a reply back from Ross Harmes, an engineering manager at > Flickr/Yahoo: That's great, I will rework the change a bit.
(In reply to comment #10) > (In reply to comment #9) > > Just got a reply back from Ross Harmes, an engineering manager at > > Flickr/Yahoo: > > That's great, I will rework the change a bit. Any update? The problem here is not the limit in itself, rather the inability to give an offset. I'd be fine selecting the first 50 items, then selecting from 51 on etc.; but I can't, so all sets with more than 50 images are unusable and one has to use [[m:flickr2commons]] or PWB. I'd even call this a major bug.
(In reply to comment #11) > Any update? Still waiting for review :/
I just come here to report the same issue, but I guess Waldir, beat me to it (by 2 years). Any progress?