Commons talk:Flickypedia

Archives
Archive 1

About Flickypedia

Interesting tool, some feedback

• when compared with the share images from Flickr feature of Upload Wizard, it is quicker in that you only have to enter one url for a large album, but the it gets slower because it doesn't auto-load the title and caption.
• Apparently when the title contains a colon, the upload isn't done (this isn't a problem with Upload Wizard) - the error description is "Unexpected result from upload API: {'upload': {'result': 'Warning', 'warnings': {'badfilename': '26069_ancient_Pharsalos.jpg'}, 'filekey': '1ak0awu9rn94.peur69.859193.', 'sessionkey': '1ak0awu9rn94.peur69.859193.'}}".
• Sth that would be useful is to be able and correct such errors without having to redo again adding title, caption and categories. C messier (talk) 20:35, 9 December 2023 (UTC)[reply]

agreed. also:

1. having to manually fill in titles and descriptions is tedious. please automatically use flickr titles and captions like flickr2commons does.
2. should have a way to batch select photos.
3. should have a way to batch add categories, either like uploadwizard having an option to "copy to all uploads" or like f2c having an option to "append everywhere".

anyway, much thanks to flickr owner and employees for the great tool! RZuo (talk) 13:06, 10 December 2023 (UTC)[reply]

instead of writing "Null edit to force re-render of Information}} template -->" you can maybe do a more subtle edit like inserting 1 newline somewhere. RZuo (talk) 13:27, 10 December 2023 (UTC)[reply]

Thanks for the feedback!

The title and caption not being auto-loaded is an intentional choice – metadata on Wikimedia Commons has to be CC0 licensed, but there is no license for metadata on Flickr. We tried to be very cautious to avoid license washing of metadata. I can see there’s a lot of feedback about this decision, so I expect we’ll discuss it further. No promises right now.

Batch selection of photos and addition of categories are interesting ideas, noted, thanks!

Colon bug is interesting – I don't know what's going on here, so I'll have a poke around in the logs.

"Null edit to force re-render" – I need to keep experimenting with this one, yeah. I tried doing a more subtle edit like inserting a newline, but MediaWiki seems to be smart enough to realise that's not a meaningful change, and doesn't do the re-render.

The issue I’m trying to avoid is where you do your upload, click through to see the result, and the Information template is empty ("This file has no description, and may be lacking other information", etc) – because then it looks like your metadata hasn't been copied across. Alexwlchan (talk) 11:49, 12 December 2023 (UTC)[reply]

For completeness, I wanted to note the discussion below in #Bringing in titles from Flickr - CC-BY 2.0. According to Multichill we may be compelled to copy the title in, because CC-BY-2.0 actually mandates that this be done. - Fuzheado (talk) 03:36, 24 June 2024 (UTC)[reply]

At an unknown time Developers silently added an error to MediaWiki: You cannot upload or revision-upload files to MediaWiki, if the Filename contains a colon. There are many pages with a colon in the title in Commons and all other MediaWiki websites. There are also hundreds of files in Commons with a colon in the name. But you cannot upload a new revision to any of this files, you cannot upload a new file with a colon in the name and you cannot rename a file so that the correct title is used, if the correct title contains a colon. As the German language uses the colon as a gender marker (and possibly other languages also use the colon for one purpose or another) a large number of files cannot be uploaded under the correct name. This wouldn't be a problem if Mediawiki used IDs to name uploaded files (like M100000000 for example) instead of names. Commons says it is an international project ("look: we can use hieroglyphs in URLs for files!") but cannot even use german language file names... C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 13:31, 10 December 2023 (UTC)[reply]

At first glance it looks like a great tool. I tested it with IISG Album beroepen, from which I lately uploaded several photos. But:

1. The first thing the tool does, is checking whether photos are already in Commons. Several of the photos I had uploaded, were wrongly in the shown selection. See for instance:
   1. File:Bekabeling telefoondienst Amsterdam 10-24-1946 00460 2.jpg. I first uploaded this one with the original photo and then I uploaded the same photo with some changes (removed edges), in the same file.
   2. The first one shown: File:Effectenbeurs van Amsterdam 00-00-1938 -7106.jpg, was not even adjusted.
2. I tried to upload another photo with the tool, but I keep getting the error "Please choose a different, more descriptive title.". The title I used: Putten ontdooien in Amsterdam 1947 03-10-1947_01271 (like the description of Flickr; Dutch for "Thawing wells in Amsterdam 1947", and the code of IISG). I choose "Nederlands" (Dutch) as language at the top of the form. So I did not succeed in uploading the photo. How more descriptive should the title be?
3. Wish: To have input fields Title and Caption be filled automatically with the Title of Flickr. You can change them if you wish.

JopkeB (talk) 07:29, 10 December 2023 (UTC)[reply]

Thanks for the feedback!

1. Missing the duplicate: oops, this is my oversight. There are a number of ways we need to check whether a Flickr photo is already in Commons (structured data, Wikitext, is it a photo uploaded by Flickypedia itself). In this example, the Flickr URL is in the Wikitext but not in the SDC, and so Flickypedia is missing it.

Our eventual plan is to get all these Flickr IDs into the SDC, but in the meantime I need to sort out Flickypedia looking at the Wikitext.

2. This sounds like another bug I need to investigate. The problem isn't your title, it'll be something in our code. It's based on the Upload Wizard behaviour, e.g. if you type in "IMG 0001" you'll get the same error message, but as you expand your title it gets better. It sounds like something got stuck – it didn't like an early draft of your title, then it didn't re-check it as you wrote a longer title.

3. The title and caption not being auto-loaded is an intentional choice – metadata on Wikimedia Commons has to be CC0 licensed, but there is no license for metadata on Flickr. We tried to be very cautious to avoid license washing of metadata. I can see there’s a lot of feedback about this decision, so I expect we’ll discuss it further. No promises right now. Alexwlchan (talk) 11:54, 12 December 2023 (UTC)[reply]

Thanks for the explanation. Good luck fixing the bugs! JopkeB (talk) 15:41, 12 December 2023 (UTC)[reply]

Is it not possible to set common categories for all photos? Often the complete album subject the same event or similar. Also eych photo should show the same category for Category:Imported files by User:xx. If no, so its more difficult like the old version. thx -- K@rl (talk) Diskussion 09:04, 10 December 2023 (UTC)[reply]

NS: So th points Add to every description and Append everywhere (categories etc.) I cannot find there ;-) ---- K@rl (talk) Diskussion 09:11, 10 December 2023 (UTC)[reply]

Nice to see his in action. A few thoughts, in no particular order

• The first page says "Wikimedia Commons requires CC licenses". This is incorrect, as made clear on the next page
• When selecting photos from an album etc, we need "select all" and "invert selection" options
• When I make a second or subsequent set of uploads, I'm asked again to choose my language. Flickypedia should remember my choice from the first set
• When I make a second or subsequent set of uploads, I'm asked again to log in to Flickr. Flickypedia should remember my first log-in
• Title should be autocompleted from the image title on Flickr
• It should be possible to copy the title from the first image in a set to the rest, with sequential number suffixes
• It should be possible to copy the caption from the first image in a set to the rest (and then modify it in each case, if required)
• If I paste text from my clipboard into the category field, Flickypedia wrongly treats this as a confirmed selection, not a search string
• Tags are not added to SDC (on e.g. File:Amanda Slater - Panettone.jpg)
• Selected categories were not added to the image (on e.g. File:Woodbridge, Suffolk by Amanda Slater.jpg)
• Where the date of an image is known, images should be added to a category, such as Category:Photographs taken on 2023-11-20.
• The text "Null edit to force re-render of {{Information}} template" is correctly used in an edit summary, but should not be included as an HTML comment - we don't need to store thousands of instances of it like that. Just add a space, or a line break, or add {{Uploaded with Flickypedia}} in the second edit. (Also investigate whether the API can force a purge instead)
• The pre-populated link in the "thank" text says " I’ve uploaded your photo to Wikimedia Commons." It should say " I’ve uploaded your photo to Wikimedia Commons, using Flickypedia."
• The "thank" text says "Would you like to see"; it should say "Would you like to see it there"
• Suggest adding to the boilerplate "thank" text (say) "Thank you for using an open licence."

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:30, 10 December 2023 (UTC)[reply]

"investigate whether the API can force a purge instead": Everyone can force a purge by http:commons/w/index.php?file:example.image&action=purge it works without the API, without the need to be logged in, without a (null) edit, without the need to actually load the js, css, media of the page, it just initiates the purge... C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 18:40, 11 December 2023 (UTC)[reply]

Thanks for the feedback! Replying to everything in order:

• "WMC requires CC licenses" ~ will fix, thanks!
• "Select all" and "invert selection" options ~ not changing for now. The friction in the flow is intentional, and the omission of 'select all' is deliberate – our intended use case is closer to "careful selection of a few photos", not "bulk copying of lots of photos". This applies to several other suggestions, e.g. copying the same title with a sequential suffix.
• "Remember my language" selection ~ fixed!
• "Remember my Flickr login" ~ fixed!
• "Pasting into the category field is treated as confirmed selection" ~ hmm, this is a tricky one. We went back and forth on this during development, and there was no clear consensus.
• "Tags were not added to SDC" ~ no, we add tags to the Wikitext (although possibly this wasn't deployed when you tried it?). We deliberately didn't add them to SDC because the community consensus seemed to be that the folksonomy of Flickr tagging wasn't a good fit for how the WMC uses tags.
• "Selected categories weren't added" ~ definitely a bug we need to look into, thanks.
• "Better ways to purge changes" ~ yeah I need to look at that, I have tried to purge API people were suggesting but it wasn't working as expected.
• "Try the speedy-deletion process will lead to sadness" ~ will remove that sentence, thanks!

Alexwlchan (talk) 09:53, 5 February 2024 (UTC)[reply]

@Alexwlchan ""Select all" and "invert selection" options ~ not changing for now."

sure you dont want to give a "select all" button, but at least let users batch select a few at the same time? like pressing shift+click select everything between the start and the end of what the user chooses? RZuo (talk) 10:37, 5 February 2024 (UTC)[reply]

"The friction in the flow is intentional" This is very disappointing

"'Pasting into the category field is treated as confirmed selection' [...]We went back and forth on this during development, and there was no clear consensus" This is very surprising, and the behaviour I described likely harmful

"consensus seemed to be that the folksonomy of Flickr tagging wasn't a good fit for how the WMC uses tags" Where was this discussion, please?

Thanks for you other comments, and fixes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:12, 5 February 2024 (UTC)[reply]

Flickypedia's FAQ includes:

But, if you really, really don’t want your photo on Wikimedia Commons, there’s a community-led deletion process available to you, which you can begin via the “speedy deletion” criteria page.

This is likely to lead to disappointment, as Commons will not usually delete images which have been on Flickr with an open licence for more than a couple of weeks. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:52, 10 December 2023 (UTC)[reply]

• You are still storing multiple copies of <!-- Null edit to force re-render of {{Information}} template -->, and making redundant edits to force page purges. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:33, 11 February 2024 (UTC)[reply]
• On further examination, you are soliciting a "short caption", and using that as both caption and description - Is that correct? There is no facility to enter a description separately? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:43, 11 February 2024 (UTC)[reply]
• There is no good reason to limit this to a maximum of 100 images per batch, for all users. Experienced users regularly use Flckr2Commons to upload much larger sets. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:52, 11 February 2024 (UTC)[reply]

'Pasting into the category field is treated as confirmed selection'

this problem led to https://commons.wikimedia.org/w/index.php?title=File:%E6%B7%B1%E5%9C%B3_2008.jpg&oldid=857898600 [[Category:Category:December 2008 in Shenzhen]]. the current design is counterintuitive. RZuo (talk) 22:11, 4 March 2024 (UTC)[reply]

Some feedback:

• Be like a wizard – Agree with most observations above that we need quick ways to populate title and description with the same type of content, like Upload Wizard allows.
• Initial upload has no edit summary - The very first edit to a new file (the initial upload) has a tag, but no text for the edit summary. I would suggest adding something brief at the very least, such as "Upload using Flickypedia" because right now it looks odd in a listing page like Special:ListFiles
• Autopopulate metadata from flickr - I'm sure everyone has this request to copy over titles from flickr, but I fear I know the answer why not - because the Flickypedia interface says all titles and descriptions must be "CC0 licensed." That means the tool is not going to auto-copy the titles and descriptions to be extra pedantic. I worry, however, that this will render Flickypedia 50% less useful for our community if it is this much less feature rich than flickr2commons. And there's no way to get past this if we want to be strict about copyright, and I can see why an external entity like Flickr Foundation would want to be extra responsible.
• Leaving a message - I like the feature of auto-leaving a message to the flickr user saying their media was used. However, I got an error when I asked the bot to do so - "BZZT! Something went wrong while posting the comment: Unexpected problem with the OAuth signature: oauth_problem=signature_invalid"

Thanks for starting this project. - Fuzheado (talk) 16:49, 11 December 2023 (UTC)[reply]

perhaps they can make a button to one click "use flickr titles and descriptions". and a popup to ask users to confirm the texts will be cc0.

safe, cumbersome, but still usable. RZuo (talk) 18:26, 11 December 2023 (UTC)[reply]

Yes, technically implementing this is not hard to do. However, the tool already plays it very conservative and does not download "No known copyright restrictions" content, so I think it's unlikely they want to roll the dice with copying clearly copyrighted content in the form of titles and descriptions where the author (the flickr account owner) is known. - Fuzheado (talk) 05:32, 12 December 2023 (UTC)[reply]

or, someone can write a script to feed title to title and description to Short caption. :D

otherwise in its current form it's barely good for importing 1 single photo. RZuo (talk) 11:09, 12 December 2023 (UTC)[reply]

for "Initial upload has no edit summary", i suggest they should write the flickr url as the summary.--RZuo (talk) 11:43, 12 December 2023 (UTC)[reply]

Context: I import from Flickr largely to bring in archival materials posted by GLAMs (which is what I'm looking at so far) and occasionally to bring some photographs over from my own Flickr account.

First, some questions:

• I see that this skips the license review stage. For most licensing, that's OK, because the tool can effectively do the license review. (Obviously, no help with "Flickrwashing," but neither was the old bot, all either can do is look at what is claimed.) How exactly is PD-mark handled? In my experience, literally the majority of Flickr PD-mark files are problematic for Commons. Are PD-mark files going to be marked for review?
• Will Flickypedia abide by Commons' blacklist of certain Flickr accounts that we have found problematic in terms of copyvios? Can it do that "up front", so people discover the problem right away, not after going through the whole process?

Straight-out bug:

• I selected two categories, only one came through.

Now my issues; most of these are closely related and have to do with editing the description:

• Couldn't we at least populate the title by default from the title on Flickr?
• Further, couldn't we have the Commons "source" link display the Flickr title of the image? Just saying "Flickr" and an otherwise blind URL for the source is really not best practice. This is exactly why bare-link references are strongly discouraged in Wikipedia.
• Now my core issue: I'm quite unhappy with prioritizing SDC-based short captions over longer descriptions. Above all, when working with material from a GLAM, I have literally no ready means to transfer the (often lengthy) description that the GLAM wrote (and to which, usually, on a topic I know, I will want to add, certainly not remove).
  • I understand that Flickr descriptions can be longer than SDC allows for a caption, and also might run afoul of the SDC requirement for CC-0, but we have been copying these descriptions into wikitext for about two decades, and as far as I know no GLAM has ever objected to that. Someone's preference for SDC over wikitext should not be a hard limit on what we can readily put in our descriptions at time of upload. In my view, the wikitext descriptions figure far more prominently in Commons "ecology" than the SDC-based captions. Certainly that is the case for materials from GLAMs. Plus, I would guess that a very high percentage of even our most active participants have no idea how to hand-edit structured data.
• The template as created in the Commons page effectively discourages further editing of the caption/description. At the very least, we could add a blank "description =" field in the Information template. Slightly more usefully, it could also have an HTML comment in the field along the lines of "description = <!-- drawn from SDC caption. Replace this comment to create a separate wikitext description -->" Really, though, if we are going to have the caption be primary (a decision I still don't endorse) I'd prefer overtly duplicating the caption here.
• Even with that, though, because the original Flickr description was never copied by the tool, if I want to copy it I have to go back to the correct page on Flickr and copy-paste. If nothing else, is it possible to bring this information over at least as commented-out content in the wikitext?
• Separate but similar issue: it is not unusual to encounter errors in the date given by a GLAM for an archival photo. Under Flickypedia's current approach the date is hidden in the SDC and there is no obvious way to edit it unless you are expert in SDC. And if what you want to say is something like "between June 1903 and circa 1907
  date QS:P,+1907-00-00T00:00:00Z/9,P1480,Q5727902
  " (expressible in wikitext as "{{other date|between|1903-06|{{circa|1907}}}}")? That is very hard to do in SDC. (It can be done, but I doubt 5% of our editors would know any way to do it, whereas in wikitext even as a worst case they can just write it out in prose.

- Jmabel ! talk 00:27, 13 December 2023 (UTC)[reply]

@Jmabel agree with your inputs on descriptions. I had to manually add the actual description of an image I recently imported. The copyright concern has been alleviated by my use of actual Wikitext itself. I would suggest Flickypedia devs to add description field using Wikitext. There are also Flickr images in which the descriptions are more than 250 characters long. JWilz12345 (Talk|Contrib's.) 20:19, 26 December 2023 (UTC)[reply]

Although I copied the actual descriptions and pasted those in the "caption" textbox during the uploading of the first 3 imports I made using the tool: File:Bike Polo (Neale Adams) - Flickr.jpg, File:Traffic at Plaridel-Pulilan Bridge (barrera marquez2003) - Flickr.jpg, and File:Plaridel-Pulilan Bridge 2008 (barrera marquez2003) - Flickr.jpg. Though I assume the descriptions are short and may not reached the required threshold of originality, but perhaps in future imports I may need to manually add descriptions thru Wikitext, as a caution. JWilz12345 (Talk|Contrib's.) 20:30, 26 December 2023 (UTC)[reply]

1. Did you consider first checking to see if the flickr image has already been uploaded, by seeing whether the URL for the image, on flickr, is in use for an already existing image's description?
   • The existence of a link in a description does not always mean that is the source. A different image might have a reason to link to Flickr. Any check like this needs to be on the file itself. - Jmabel ! talk 19:59, 22 October 2024 (UTC)[reply]
2. Did you consider adding the unique flickr photo ID into the Commons file name, in the same way flickr2commons does? I see several advantages to this. Both flickypedia and flickr2commons will detect name collissions, and will barf if you try to use a filename that is already in use. But this feature won't prevent contributors from uploading images multiple times, if the two parallel facilities don't use the same filename.
3. Other people have asked whether you considered adding a way for contributors to specify, just once, that all the images in an album upload should share some categories, Category:2011 in London, if they were all taken in London. I agree that this would be very useful
4. Other people have asked whether you considered making the flickr name the image's default name, on the commons, like flickr2commons does? Yes, sometimes flickr contributors give their images unhelpful names like, "Hey, look at this". In that case contributors should give it a different name. Yes, sometimes flickr contributors don't specify a name, at all, and the image gets called something like IMG001.jpg.

   IMO, due to name collision, it would be good, due to name collision problems, if both your tool, and flickr2commons, would create a redirect, at the stupid name. So, if the image would have been named, File:IMG001 (00000001).jpg or File:Hey, look at this (00000001).jpg where (00000001) is the unique flickr-id, a redirect should be created that points to meaningful name the contributor applied when they requested the images upload. Again, creating the redirect results in name collision, which will prevent the image being uploaded multiple times.

   Wait, you ask, if we make the change you suggested, where we confirm the image's flickr URL is not in use, won't that elimate all duplicates? No. Some people who didn't use flickr2commons, or flinfo, uploaded perfectly valid flickr images using a different flickr URL. Depending on how you get to a flickr image it can give you a different flickr URL. Sometimes, for instance, it will give you a URL that includes the Album ID in the URL. I think this means preventing duplication requires both checking for the base flickr image URL, and standardizing names, so name collision protects against duplication, when another uploader used a variant image URL.

5. Depending on how a contributor copies a category they are re-using from an existing file the name they plug in may contain underscores, instead of actual spaces. Flickr2commons is smart enough to map the underscores to spaces. Have you considered adding this facility to your tool?
6. When a contributor types in a caterory name, that is a {{Category redirect}} did you consider mapping it to the actual category?
7. The first time I tried using your tool to upload multiple images from a single album it barfed and didn't upload one quarter of the images I requested. For five of those six attempts it barfed because the upload took too long. This taking too long seemed to be an arbitrary thing. Did you consider allowing the contributor to try again after a timeout?
8. For eight of the 24 uploads in my first attempt to use to upload multiple images from a single album it failed to fill in the author and source fields. I had to go and fill them in myself.
9. Did you consider automatically adding the images to the appropriate Category:Files from jqpublic Flickr stream?

   If you try to do this, and the individual doesn't yet have a Category:Files from jqpublic Flickr stream, would you consider making your tool create one?

   • Perhaps I'm mistaken, but I believe we have had prior discussions about some Flickr users (including some who are also Commons users) specifically not wanting this. I know I don't want it for my Flickr files. - Jmabel ! talk 20:02, 22 October 2024 (UTC)[reply]
10. Is the tool automatically deselecting images because you use some kind of AI tool that guesses at whether an image is a selfie, or personal photo?

    I have a bee in my bonnet. I am an experienced uploader. Even though I am subject to normal human fallibility, I don't want a robot to over-ride my experienced human judgement. This is a problem with the flickr2commons upload process. If the flickr contributor applied a so-called "public domain mark", during the upload a speedy deletion tag gets applied to the image. Yes, we all know they should have applied cc0, and that they should not use public domain mark on images they took themselves, reserving public domain mark for images someone else took they think are public domain, due to age, or due to being taken by an employee of the US Federal government, or whatever. But, something like 50 % of flickr uploaders get this wrong. So, I don't want to see this tag on the flickr images I upload. If I requested its upload it is because I think the flickr contributor is one of those who misunderstood where it should be used.

    Similarly, I want to be able to select images for upload, even when they contain human beings.

    We have images of popular sites, like the Eiffel Tower, or the Statue of Liberty. For sites like that we need both images taken on days when the site was closed to tourists, and images taken on days when they were frequented by tourists, because, being crowded by tourists is the default state. If your tool has some way of discluding images that include people it is over-riding my judgement that the existence of people in the image does not make it out of scope.

    Similarly, when an individual has GNG notability, then a selfie they took is in scope. When an individual has less than GNG notability, but their selfie might be used in a section of a wikipedia article related to them, then a selfie they took is in scope. For instance, selfies of Politicians who held a State or Federal office, are obviously in scope. I would argue that selfies municipal politicians, or of failed candidates, are also in scope, even though they probably don't rise to the level of GNG, because their image might be used to illustrate an article on the election where they ran.

11. Your tool promises to thank the flickr uploaders. For a year or two, around 2009, after I started making an effort to upload more good flickr images, but before I became aware of tools to help me upload multiple images, after every use of flinfo I took thirty seconds to leave a thank you, on the flickr image's description page. I didn't see your tool leave that thank you on the description page. Are you thanking people via flickrmail? I think that would be a mistake, because it could generate a flood of flickrmail message. That is not good.

    In addition, a nice thank you on the image's flickr description page serves to help encourage OTHER flickr contributors to consider using a free license. In my thank you I specifically thanked them for uploading their fine image using a license that allowed the image to be freely re-used.

Thanks for your work on this tool. Geo Swan (talk) 21:51, 7 October 2024 (UTC)[reply]

Attempting to import videos causes 500 error for Flickypedia (in some but not all cases, the special:upload form and video2commons can also throw this error for Flickr videos). Examples follow. Arlo James Barnes 09:17, 25 January 2024 (UTC)[reply]

• https://flickr.com/photos/andrec/4977081281
• https://flickr.com/photos/royblumenthal/3644995329

example: https://farm66.staticflickr.com/65535/buddyicons/92761690@N03_r.jpg Arlo James Barnes 21:56, 14 February 2024 (UTC)[reply]

@Arlo James Barnes: what is this an example of? What do you want done? - Jmabel ! talk 23:30, 14 February 2024 (UTC)[reply]

@Jmabel: Ah, excuse my brevity. That is a "buddyicon", what is called around the rest of the internet an avatar, profile pic, etc. It would be nice if Flickypedia would support importing those which are freely licensed (I think the buddyicon just points towards a regular ol' Flickr image, but I'm not sure how to get one URL from the other). Arlo James Barnes 21:42, 11 March 2024 (UTC)[reply]

1. https://www.flickr.com/photos/sharonhahndarlin/with/52735974979 this url gives this error.
2. "https://www.flickr.com/photos/sharonhahndarlin/ " (with a trailing whitespace!) also gives this error.
3. only "https://www.flickr.com/photos/sharonhahndarlin/" would work.

1 and 2 should be made to work too. RZuo (talk) 10:19, 5 February 2024 (UTC)[reply]

Number 1 don't work. But today 2 and 3 are working. I use the "page..." in the URL do get the next images. Because only 100 images will be scanned per call. SO I use for example: https://www.flickr.com/photos/sharonhahndarlin/page2 and change the URL to page3, page4, ... It work, but it is not a user friendly way. --sk (talk) 04:46, 22 March 2024 (UTC)[reply]

When I try to use Flickypedia, I get an Internal Server Error when it gets to the step https://www.flickr.org/tools/flickypedia/get_photos. Nosferattus (talk) 03:51, 26 February 2024 (UTC)[reply]

Yesterday I can upload around 10 images from Flickr to Commons with Flickypedia. But today I get many Internal Server Error. Please fix it. I would use this cool tool. --sk (talk) 06:35, 20 March 2024 (UTC)[reply]

Not sure if this has been asked before... once a file has been transferred to the Commons, it doesn't ask FlickrReview to scan the file to check if the license is valid or to preserve its status into the future? It just says when it was uploaded and by who. Is this something that will be added? Thanks! PascalHD (talk) 02:49, 15 March 2024 (UTC)[reply]

If Flickypedia validates the license at time of upload, then presumably there is no need for further validation. - Jmabel ! talk 08:19, 15 March 2024 (UTC)[reply]

@Jmabel@PascalHD I still manually add the template, perhaps a routine action by me. See, for example, File:Fulton Savings Bank, Fulton, NY (Doug Kerr) - Flickr.jpg. JWilz12345 (Talk|Contrib's.) 02:00, 28 July 2024 (UTC)[reply]

When I test flickypedia, I search a tag in flickr like "berlin" and use this link: https://flickr.com/photos/tags/berlin in flickpedia. So I get this result. Flickypedia only scan the first 100 images and not more. If I want check the next 100 images I have manualy to change the link to https://flickr.com/photos/tags/berlin/page2 wiht this result. And so on for page3, page4, ... - I would like to have a button "check the next 100 images" or so. --sk (talk) 14:08, 28 March 2024 (UTC)[reply]

In Commons we have a searchword "nearcoord" like in this search. I know many images in flickr have coordinates too. And I can see this images on www.flickr.com/map. So I would like to have this possibility also in flickypedia. Find images x kilometers around a coordinate. So I can find interesting images in the area of my hometown without knowing the right tag. Many images have also not so specifically tags. Like "flower", "monument", "building". But when I see this images I can upload this in the right categories in commons. - I hope the API of Flickr can get you something like "nearcoord". --sk (talk) 14:21, 28 March 2024 (UTC)[reply]

Hi all,

Recently I met up with User:Ukglo (at the meta:AI Sauna conference), where we discussed flickypedia with User:Multichill. He pointed out that we may have a solution/argument for bringing in titles for CC-BY content on flickr. Because flickr has the legacy CC-BY 2.0 license, that particular version has a requirement that says (emphasis mine):

You must keep intact all copyright notices for the Work and give the Original Author credit reasonable to the medium or means You are utilizing by conveying the name (or pseudonym if applicable) of the Original Author if supplied; the title of the Work if supplied...

So rather than being unsure about whether titles from flickr are freely licensed, it seems that with the CC-BY 2.0 license, we are actually compelled to bring in the titles, and not leave them blank. I thought I'd bring it up here for discussion. Thanks. - Fuzheado (talk) 19:54, 10 May 2024 (UTC)[reply]

+1. - Jmabel ! talk 23:39, 10 May 2024 (UTC)[reply]

When I try to use Flickypedia, I get an Internal Server Error at Uplad step (after filling in descriptions, categories, etc. for 37 photos). A bit frustrating. Jklamo (talk) 17:57, 27 July 2024 (UTC)[reply]

"in June" should indicate what year. - Jmabel ! talk 00:05, 9 August 2024 (UTC)[reply]

@Jmabel: Edited. cc @GFontenelle (WMF): . SCP-2000 00:48, 9 August 2024 (UTC)[reply]

This seems to be one of the pain points that the community faces. Neither this tool nor Commons:Flickr2Commons allow such transfers. Would it be possible @Alexwlchan that Flickr considers developing such circumventing feature? cc @Pigsonthewing @Jeff G. -- DaxServer (talk) 14:40, 23 August 2024 (UTC)[reply]

If implemented please add chronological maintenance categories because these uploads would need special checking, like "Uploads from Flickr with nonfree license set at source – 2024-05" or e.g. "2024-05 unchecked uploads from Flickr with nonfree license set at source". Prototyperspective (talk) 11:09, 26 August 2024 (UTC)[reply]

See Commons:Village pump/Copyright#Are we allowed to copy descriptions from Flickr? -- DaxServer (talk) 18:50, 3 September 2024 (UTC)[reply]

here're a few things i notice.

1. because there's no way to see the images clearly (smalll and square thumbnails, no link to the original on flickr, no flickr title or description), i'm keeping the flickr photostream page open and browsing there to decide which ones to import, then tick them on flickypedia.

   so, if you can make the preview work better, then users dont need to do this trick.

2. i'm counting the number of images i ticked in my mind.

   a floating counter makes it much easier to keep track of how many have been selected.

3. i type something to search for categories, but several similarly named ones show up. i'm unsure which one, but there's no way to check. i have to switch to commons to find and check.

   after a category is selected, instead of plain text, make it a link so users can check it by one click.

4. i select from the title to the description in one go. when i paste it, 4 whitespaces are always prepended to the pasted text.
5. i want to cancel one of the uploads at the description (prepare info) step. i cant do that? and i cannot go back to last step. this is the worst and most annoying! @Alexwlchan i had to redo everything!
6. an easy way to add the same category to all or multiple files is needed.

RZuo (talk) 15:52, 9 September 2024 (UTC)[reply]

at the prepare info step, prompt the user when they close the tab, "if you have unsaved changes, are you sure to close..." RZuo (talk) 16:00, 9 September 2024 (UTC)[reply]

https://commons.wikimedia.org/w/index.php?title=File:Xmas_decorating,_60%27s_style.jpg&diff=prev&oldid=921898079

another bot came by soon after upload, and its edit effectively purged the page and then all sdc data are displayed as expected in the information template.

if you want to make sure sdc data are displayed, you could incorporate that bot's addition of media type (P1163). just make sure all sdc are added in two edits, with the 1st one invovling all the fields to be displayed in info (source, author, etc.) RZuo (talk) 20:52, 9 September 2024 (UTC)[reply]

@RZuo and other watchers, I'm working on a fork of Flickypedia that addresses several of the feedback in this page, and as a successor to F2C. Would you/others be interested to test it out? -- DaxServer (talk) 21:07, 9 September 2024 (UTC)[reply]

@DaxServer all commons users would be grateful if you make flickr import tools. RoyZuo (talk) 09:57, 21 October 2024 (UTC)[reply]

Until the description import problem is resolved, i have to go back to uploadwizard or f2c.

here's what i'm doing today: trying to import 9 photos from https://www.flickr.com/photos/niaid/albums/72157682564763213/page10 .

i couldnt copy the crucial scientific descriptions easily, so flicky is no. my files are on page10 so uploadwizard is also no. RoyZuo (talk) 10:01, 21 October 2024 (UTC)[reply]

In a recent in-person discussion with George Oates at the AI Sauna in Helskinki, we talked about how flickypedia was working with a project scope different than flickr2commons. Flickypedia focuses on singleton or small-batch upload of images to support an immediate need for use in specific Wikipedia articles. I noted that there are use cases for large-batch uploads, so I thought I'd present a concrete example of this for the developers to consider:

• The National Book Festival in the United States is a large event each year that is run by the Library of Congress (LOC).
• Photographers employed by the LOC take photos of famous book authors that are then released to the public domain/CC0. By default, their images and metadata are CC0, and they publish their photos with such a license on flickr.
• In these cases, we want to do a wholesale import of all of their images which are high quality, well-described, and are all CC0. After the ingestion into a Wikimedia Commons category, we can then add SDC, run bots to re-format the description to break out the photographer names, etc. So in this case, it's an example of an extract-load-transform (ELT) workflow.

• Here's the example from this year: https://www.flickr.com/photos/library-of-congress-life/albums/72177720319888020/with/53956246001

• After ingestion and metadata enrichment, they might be cropped or re-categorized. They are then either directly placed into infoboxes or biographical articles, or the Wikidata item has the P18 (image) property updated with these photos, and this gets reflected in Wikidata-driven infoboxes in various languages across the Wikipedia editions. Downstream, this will usually result in appearance in Google searches and their knowledge panels.

While the UploadWizard does have support for flickr ingestion including using the title and description, it is limited to 50 images at a time. The image set from LOC is more than 100, and it is not uncommon to want to ingest 100s of images at a time for festivals, concerts, or other event coverage. Thanks. - Fuzheado (talk) 18:50, 13 September 2024 (UTC)[reply]

After adding a new category to a photo, I frequently consult the category page on Commons to check if there is a more specific category. It would be nice if one could click on the list entries. --1-Byte (talk) 16:10, 3 November 2024 (UTC)[reply]

The pink color calls way too much attention to the template that indicates that the file was transferred by Flickypedia. From an end-user point of view, that is of near-zero importance. Why should it use a color highlight? - Jmabel ! talk 00:39, 12 November 2024 (UTC)[reply]