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.

Search Flickr by checksum[edit]

One crucial missing piece of the Flickr API that I've found when working with Commons images and Flickr is that there's no way to search by file checksum/hash. Commons files have sha1 hashes (e.g.) available for each file, and these can be really useful when checking for file existence on different services. I'm not sure if Flickypedia will be needing to do this, but if a side effect of this project was to expose a public checksum API that would be brilliant! — Sam Wilson ( TalkContribs ) … 04:13, 8 July 2023 (UTC)Reply[reply]

Hi. We at the Flickr Foundation don't have a way to change the Flickr API directly, (as we're a totally different organisation) but, I'll let the flickr.com team know you've mentioned this. Ukglo (talk) 10:51, 12 July 2023 (UTC)Reply[reply]
Yes, we'll be working with the API ourselves for the most part for the things we'll be building at the Flickr Foundation, at least for now. I encourage you to reach out to the flickr.com developers either via their Help Form or their Help Forum (in addition to Ukglo's note) to see if you can get it on their radar. I do agree, it would be a useful thing to have be searchable. Jessamyn (talk) 16:59, 12 July 2023 (UTC)Reply[reply]
Will do! Thanks. — Sam Wilson ( TalkContribs ) … 04:48, 13 July 2023 (UTC)Reply[reply]
Hi @Samwilson - one of the team asks "Does md5 work or do you need sha1?" Ukglo (talk) 10:58, 7 August 2023 (UTC)Reply[reply]
@Ukglo: MediaWiki stores sha1 hashes of files so it'd be simpler if that were possible, but if they've already got md5 available then that'd be better than nothing most definitely! Any way to check for an existing file would be terrific. Send them my thanks! Sam Wilson 11:10, 7 August 2023 (UTC)Reply[reply]
I'll pass that along. Ukglo (talk) 14:05, 7 August 2023 (UTC)Reply[reply]
It would be really helpful if both (Flickr and MediWiki - and also every other provider of images (free images, commercial images)) would offer not only one hash, but a number of hashes: sha1 and md5, and even more important: hashes of the image content only (without the EXIF, XMP, IPTC, ICC data) as it is often the case, that metadata is changed but not the image itself (exiftool offers such a hash for some time now) and even even more important: a semantic hash, that is independent of image resolution, of cropped image frames, of compression artefacts, of changing the image from tiff to png to jpeg to webp - it is still the identical image! C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 11:48, 10 December 2023 (UTC)Reply[reply]

Uploading OOC images with with non-open licences[edit]

I have just competed the survey, but forgot to mention this:

One of my bugbears with the current F2C tool is not being able to upload images where the Flickr user has not used an open licence, but the image is out of copyright (scan of a Victorian painting or photograph, old postcard, old ephemera, etc.), and is thus acceptable to Commons.

I realise this could be open to abuse, but the ability to do so could be given to users with a good track record, as a user-right. A tag in the edit summary could mark such uploads as requiring extra scrutiny. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:20, 2 August 2023 (UTC)Reply[reply]

That's useful feedback. Figuring out the way to mesh (or track) the licenses in a way that takes into account things like that is something we're eager to do. Jessamyn (talk) 16:57, 3 August 2023 (UTC)Reply[reply]
Note that Commons also allows users to upload images that are nearly but not yet out of copyright, and then tag them for deletion (which keeps a non-public copy in the database), so that they can be undeleted once the copyright expires. Flickypedia should allow for this circumstance, also. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:19, 7 August 2023 (UTC)Reply[reply]
AFAIK Flickr metadata does not contain any information on when a photo will fall out of copyright. Not sure how we'd know? Ukglo, flickr.org 🌸 (talk) 14:59, 6 October 2023 (UTC)Reply[reply]
@Ukglo: You wouldn't need to; that's where the user-right, for "users with a good track record" comes in - it would be up to those people to use their judgement (subject, as always to community review). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:36, 6 October 2023 (UTC)Reply[reply]
Hi - Sorry. I don't understand how this would work... It seems to imply that Flickypedia should allow an upload of an image with any license. Ukglo, flickr.org 🌸 (talk) 11:46, 1 November 2023 (UTC)Reply[reply]
@Ukglo: Yes; precisely that. The use case is that some Flickr users upload scans of out-of-copyright works (Victorian ephemera, Edwardian postcards, etc) and claim copyright over them (probably by neglecting to change from their default photo licence). Because assessing the copyright status of such images requires a degree of experience, only users who have been granted permission by the Commons community, after demonstrating such experience, should be allowed to use the tool to upload such images. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:27, 1 November 2023 (UTC)Reply[reply]
Where is the permission you're referring to recorded?
(Just to set expectations, I think this is not in scope for our Version 1, but it would be good to note in our issues list for possible future consideration.) Ukglo, flickr.org 🌸 (talk) 11:51, 28 November 2023 (UTC)Reply[reply]
@Ukglo: You can see my current user rights ("file mover, patroller, rollbacker, template editor"), for example, at [1]. I presume this is also available via API. Caveat noted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:39, 28 November 2023 (UTC)Reply[reply]
Hi Andy - How and when would you insert a tag in the edit summary? Ukglo, flickr.org 🌸 (talk) 14:58, 6 October 2023 (UTC)Reply[reply]
@Ukglo: Whenever a user with the user right uploads an image that does not have a free licence. You can see a randomly-selected edit with three tags in this diff. There's more about this at mw:Manual:Tags. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:46, 6 October 2023 (UTC)Reply[reply]
+1 Beireke1 (talk) 09:57, 23 October 2023 (UTC)Reply[reply]

Upload by tag[edit]

I was just looking for something else and found a suggestion I made in 2020:

Here for example, is a set of 57 Flickr images sharing a unique tag. Is it possible to upload all images with that tag, in one go? If I use Flickr2Commons, specifying the Flickr account name and the tag, it finds no results.

T245063 also refers. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:51, 18 August 2023 (UTC)Reply[reply]

Not entirely certain but I believe this is functionality we're hoping to have. I agree, it would be very useful. Jessamyn (talk) 15:54, 5 October 2023 (UTC)Reply[reply]
After checking, I don't think by user/by tag is something v 1.0 is going to have, but it is a nice way to think about future directions. Jessamyn - Flickr Foundation (my talk page) 16:22, 6 October 2023 (UTC)Reply[reply]
Returning to this – we do support finding photos by tags!
(Although I don’t actually see any photos at that tag?) Alexwlchan (talk) 11:21, 7 December 2023 (UTC)Reply[reply]

Upload from Category interface[edit]

So I recently was introduced to this INaturalist extension that helps me "Discover" Inaturalist content that is a good candidate for upload into a category: [2]-- I would love to have a similar interaction with Flicker -- where it generates a candidate link for potential tags or search results that would give me candidates for upload to Commons, Sadads (talk) 13:29, 28 November 2023 (UTC)Reply[reply]

This would be particularly useful on things with Proper names (i.e. people, buildings, taxons, etc), Sadads (talk) 13:30, 28 November 2023 (UTC)Reply[reply]
Hi! Good idea! And/but, this is easier on iNaturalist because of taxonomy/agreed naming - hard to see how it could work for the arbitrariness on Flickr! We'd sort of have to put a button on every WM page just in case? Ukglo, flickr.org 🌸 (talk) 12:01, 29 November 2023 (UTC)Reply[reply]
@Ukglo So, I would have a link for a "Flickipedia search", or even do an API call to Flickipedia for tags that string-match. At one point, Magnus had a tool that suggested likely matches from Flickipedia, and this was particularly useful for names of people, species and buildings -- it was less useful for general concepts -- but saving the step of search and having to conciously leave Commons to search on Flickr, would be super valuable for those of us looking for content gaps. Sadads (talk) 11:58, 7 December 2023 (UTC)Reply[reply]

Changing Flickr's CC license drop-down[edit]

I was hoping to batch change the licensing at my Flickr account from all rights reserved to Attribution Share-alike which links to https://creativecommons.org/licenses/by-sa/2.0/ this 2.0 license. Can we get Flickr to link directly to our CC-BY-SA 4.0 International license? Also, does anyone know if there's a way to batch-change the license on our Flickr image? I have far too many images to update the license individually, and simply not tech-savvy enough to figure out how to do it. Atsme Talk 📧 20:27, 9 December 2023 (UTC)Reply[reply]

Yes, I was inmvited to test this on Commons but the first URL I entered said 'None of these photos can be used because they have licenses that Wikimedia Commons doesn’t accept.' Charlesjsharp (talk) 21:33, 9 December 2023 (UTC)Reply[reply]
Adding support for CC-BY-SA 4.0: currently flickr.com only has the 2.0 version of the CC licenses, and I don't know of any timeline for that changing. You’re not the first to ask, and I know it’s been discussed, but I can’t say if/when it will happen. (That would require work from flickr.com, which is a separate org from the Flickr Foundation who built Flickypedia. I don’t know more than you on this topic!)
Changing licenses in bulk: there’s a tool for batch changing your licenses at https://www.flickr.com/account/prefs/license/batch, which requires a Flickr Pro account. Alexwlchan (talk) 12:00, 12 December 2023 (UTC)Reply[reply]

Birdy[edit]

PICA PAU DO CAMPO

Would this be a better avian mascot? Jim.henderson (talk) 21:42, 9 December 2023 (UTC)Reply[reply]

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[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[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[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[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[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[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[reply]
Thanks for the explanation. Good luck fixing the bugs! JopkeB (talk) 15:41, 12 December 2023 (UTC)Reply[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[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[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[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[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[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[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[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[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[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[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[reply]

Internal Server Error[edit]

The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.

i run into this problem quite a few times. RZuo (talk) 11:29, 12 December 2023 (UTC)Reply[reply]

Stuck at "Uploading..."[edit]

my tab is stuck at the animation "Uploading..." after batch uploading 4 photos successfully. not a big issue for now, since the uploads are already done.--RZuo (talk) 11:43, 12 December 2023 (UTC)Reply[reply]

Username[edit]

if possible, Template:Uploaded with Flickypedia should use "Special:Redirect/user/<User ID>" to jump to the user, instead of username, because users can be renamed. RZuo (talk) 11:49, 12 December 2023 (UTC)Reply[reply]

Ability to detect deleted image duplicates[edit]

So far, Flickypedia works satisfactorily, though I hope some suggestions brought here are made into consideration. I have one suggestion: Flickypedia should have the ability to detect deleted images, so that the imports will not be reuploaded. I have seen cases in which images (mainly those showing unfree buildings and monuments of France, Iceland, and other countries not allowing commercial freedom of panorama) are "reuploaded" (by different users). This indirectly results to duplicates, and eventually, deleted duplicates. Flickypedia should have this detection ability and perpetually block the attempts to import that Flickr image. JWilz12345 (Talk|Contrib's.) 09:57, 16 December 2023 (UTC)Reply[reply]

Sample cases of reuploading Flickr images that Commons cannot accept because of the source countries of depicted buildings and monuments not allowing commercial freedom of panorama (those were the Flickr-2-commons days): Commons:Deletion requests/File:Le centre Georges Pompidou (Paris) (8191200447).jpg (France) and Commons:Deletion requests/Files in Category:Harpa (concert hall)#Files in Category:Harpa (concert hall) 6 (Iceland, for File:Harpa (21460143573).jpg). JWilz12345 (Talk|Contrib's.) 10:03, 16 December 2023 (UTC)Reply[reply]
If you try to upload a file with the same message digest as a deleted file, you get a warning message and can stop the upload. But is thre a way to check the message digest against deleted files before upload? Also: MW only stores the Message Digest of the complete file. Changing a single bit in the file will change the message digest. A semantic message digest for (at least deleted) files would be helpful. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 11:12, 16 December 2023 (UTC)Reply[reply]