Commons talk:Flickypedia

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
This is the talk page for discussing improvements to Commons:Flickypedia.
Archives: 1

Feedback on Alpha release[edit]

About Flickypedia

No auto uploading title and caption, issue with colons, can't move back to fix not done uploads[edit]

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]
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]


JopkeB[edit]

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]

Common category for all the photos[edit]

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]

Andy Mabbett[edit]

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]

'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]

User:Fuzheado[edit]

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]

Jmabel[edit]

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]

feature requests[edit]

video[edit]

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]

buddyicons[edit]

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]

There are no photos to show at that URL[edit]

  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]

Internal Server Error[edit]

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]

FlickrReview?[edit]

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]

Feature request - next page[edit]

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]

Feature request - nearcoord[edit]

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]

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons_talk:Flickypedia&oldid=867176016"