Help talk:Extension:FileImporter

Jump to navigation Jump to search

About this board

Central feedback page for FileImporter/FileExporter.

Geagea (talkcontribs)
  • 1) The import log should be added to the file info as a separate section or Information field. The information regarding to Who moved the file, from which project and date of move. Now it look like the file uploaded directly to Commons by original uploader. Some info must be given her.
  • 2) If one of the imported files nominated for deletion. The original uploader gets notification in Commons. The user that moved the file does not get any notification. This is not healthy. The user that moved the file to Commons is the real uploader of the file to Commons. He must be notified as well. And also. The discussion about the deletion will be in Commons. Might be some problems with that. For example, part of the users from he.wiki active only in he.wiki and uploading files to he.wiki. Involving in DR discussion might be a problem for them. Language problem, not familiar enough with Commos rules etc. I have no instant idea to solve it but we must give it a thought.
  • 3) I don't think it is correct to link the original uploader in Commons. See the screenshot of the file I have moved from he.wiki. See A in the field of the author I added the template: Commons Template user at project and also B Should link to the author in his own wiki - the wiki he uploaded the file firstly.
Reply to "Some thoughts"

Local opt-out

12
Summary by Thiemo Kreuz (WMDE)
Roy17 (talkcontribs)

Is there a way for a local project to opt out of FileImporter? Some wiki project(s) are too laxed on copyright fraud. I believe FileImporter should be turned off for these projects with or without a local consensus.

Thiemo Kreuz (WMDE) (talkcontribs)

I wonder under which circumstances the limitations encoded in the configuration pages at Extension:FileImporter/Data aren't enough to prevent unwanted uploads from happening? Can you please provide one or more specific examples of such problematic files?

Roy17 (talkcontribs)

It's not the problem of the config. Some wikis have very poor oversight of local files that copyvios are often tagged with free licences. I think such wikis should have FileImporter turned off.

As far as I know, on Commons, there is currently no tool to identify all files imported from a particular wiki. They are not put into a single category either.

Thiemo Kreuz (WMDE) (talkcontribs)

I would like to rephrase my question and ask you to provide more information that allow us to understand the issue better. It appears you are talking about one specific wiki. Which wiki is that? Can you please provide examples of files that have been imported to Commons, but shouldn't? It sounds like the issue are different community standards. It even sounds like the community you are referring to is willingly violating standards that exist on all Wikimedia wikis. Is this the case? If so, wouldn't be the Wikimedia Foundations legal team in charge?

Would it help if FileImporter sets a category to mark the source of an import?

Jeff G. (talkcontribs)

@Thiemo Kreuz (WMDE): "FileImporter sets a category to mark the source of an import" would definitely help.

Thiemo Kreuz (WMDE) (talkcontribs)

The question remains, I'm afraid: help with what? Please provide all information you have to enable us to help.

Jeff G. (talkcontribs)

@Thiemo Kreuz (WMDE): Help with copyright enforcement. Two projects that come to mind as potentially problematic with respect to copyrights are Arabic Wikipedia and Arabic Wikisource. We had a declined bot request for transferring files from those two projects to Commons early last year, which revealed the following quotes: "Different Wikipedias have different attitude toward copyrights and its enforcement." by EugeneZelenko; "Seems to be an overall lack of consensus on Arabian Wikipedia about the process for how this bot would work. One commented that they don't trust Commons because there files got deleted for no convincing reason, another mentioned copyright issues and perhaps images not being transferable due to licenses." by ~riley; and my "I have issues with whoever is selecting these files for transfer, and that person's attention to detail (or lack thereof)." 60% of the files selected as examples for transfer (which should have been the best ones) had copyright problems which made them unsuitable for Commons or any WMF project. Admittedly, five is a very small sample size, but 60% is a huge error rate.

Thiemo Kreuz (WMDE) (talkcontribs)

Thanks. I created phab:T222445 to help us keep track of this request. It would be great if you could provide specific examples here or in the ticket.

EugeneZelenko (talkcontribs)

I think it's reasonable request. Other factor which should be taken in account is availability of active administrators on Commons who knows particular language well, better because communication mat lead to better local review before enabling transfer or just reduce misunderstandings between Commons and other projects.

Roy17 (talkcontribs)

Actually, to turn it off is pretty simple: remove/comment out all acceptable templates in the config, and protect the config. What is missing is a formal process. The best is of course if the local wiki has a consensus of disabling it, but in the event of no consensus, or if small wikis insist on enabling it but do nothing to tackle problematically licensed files, the larger Commons community should be allowed to initiate/impose an opt-out on such small wikis, since FileImporter involves both the local wikis and Commons. meta:Non-free_content is a not so up-to-date monitoring of local files.

On the other hand, a maintenance category akin to c:Category:Files moved to Commons requiring review by source would be very useful. Currently a line of the format <!--This file was moved here using FileImporter from //xxx.wikipedia.org/wiki/File:Example.jpg--> is automatically prepended for each import. We'll just need to append for example a line [[Category:Files moved from xxx.wikiproject to Commons requiring review]], or a remodeled c:Template:BotMoveToCommons.

Roy17 (talkcontribs)
EugeneZelenko (talkcontribs)

It's reasonable to have transfer disabled by default and enable it after formal review. Historically I could refer to bot-assisted transfer organized in Polish Wikipedia where several Commons administrators were actively involved. Russian Wikipedia changed attitude toward copyrights and started to review files scrupulously ~ 4th year of existence.

Reply to "Local opt-out"

ZWNJ and Whitespace not recognized in parameters

3
Summary by Thiemo Kreuz (WMDE)
4nn1l2 (talkcontribs)
Thiemo Kreuz (WMDE) (talkcontribs)

Thanks for reporting this extra example. Alternative source parameter names for the same target parameter name are currently not supported, see phab:T213955. You can keep the extra parameters on the config page. Just make sure the most important one is listed last.

Michael Schönitzer (WMDE) (talkcontribs)

Thanks, I created a phabricator-ticket for this, so that our developers can look into it: T221959

[Update: I Answered simultaneously to Thiemo… See his answer]

Reply to "ZWNJ and Whitespace not recognized in parameters"
Hanooz (talkcontribs)
Jeff G. (talkcontribs)
Hanooz (talkcontribs)

Thanks.

Jeff G. (talkcontribs)

You're welcome. I imported File:Raami-011.jpg, but I couldn't access the tickets of the rest.

Hanooz (talkcontribs)

Thank you very much. I will ask on Persian WIkipedia for help.

Jeff G. (talkcontribs)

You're welcome.

Please add PD-Australia to the allowed list

2
Summary by Michael Schönitzer (WMDE)

It's up to the communities to decide which templates they put on the white-list. You can change the whitelists and blacklists here.

Kerry Raymond (talkcontribs)

Currently images licensed as PD-Australia are rejected by the FileImporter but PD-Australia images are allowed on Commons.

Jeff G. (talkcontribs)

"The 12 file versions you are currently trying to import exceed the file size limit the import can handle."

3
Adam Cuerden (talkcontribs)

The situations where there's multiple versions and a decent size to them are pretty much the exact situations where having bot-assisted movement is most useful. It might be mildly annoying to move a single 75 KB image over. It's bloody awful to move 12 images of 36 megabytes each. The maximum move size needs pushed WAY up.


As to how this situation arose: Long story short, I was doing a difficult restoration while copyright status was being worked out on Commons. I uploaded partially-done files as I went. Consensus came down in favour of Commons hosting the file, as the only thing that would give doubt to the status (a partial attribution in an unreliable source to a name that does not appear to have any other known works discoverable, nor any reliable sources that even cover his or her existence) was deemed trumped by the very reliable source (the BnF) that said it was both anonymous and public domain.


Oh, there's also a PNG version of the file. 6 files in the history, 87 megabytes each. What IS the limit, anyway?

Thiemo Kreuz (WMDE) (talkcontribs)

Can you please provide a link to the specific file you are trying to import?

The current limits are 100 revisions, and 250 megabytes.

Adam Cuerden (talkcontribs)

Sure, it's https://en.wikipedia.org/wiki/File:Cavalleria_Rusticana_-_Santuzza_and_Turiddu_outside_the_church.jpg and https://en.wikipedia.org/wiki/File:Cavalleria_Rusticana_-_Santuzza_and_Turiddu_outside_the_church.png


I realise there will probably be secondary blocks in the license check - En-wiki does not have the most relevant license, and I'd like to keep a local copy there anyway, just in case it turns out the unreliable source was somehow both correct and that it makes any difference to status - but it's not too hard to work around that.


The commons discussion as to why it's fine for there is at https://commons.wikimedia.org/wiki/Commons:Village_pump/Copyright#Unidentified_artist


And the end licensing should be as in https://commons.wikimedia.org/wiki/File:Cavalleria_Rusticana_-_Alfio_and_Turiddu_embrace.jpg

Reply to ""The 12 file versions you are currently trying to import exceed the file size limit the import can handle.""

Move original file (instead of copy)

3
Rehman (talkcontribs)

The file exporter essentially "copies" the original history from localwiki to commons. Hence (even though the original page will eventually be deleted) it duplicates contribs. Can an option be made, where a file can be "moved" in it's entirety from localwiki to another (thus no contribs remains on localwiki)? Is it possible to enable that function at least to power users (i.e. admins on one or both projects)?

Thiemo Kreuz (WMDE) (talkcontribs)

Thanks a lot for the suggestion. It would certainly be nice to provide this as an option. Unfortunately, it is technically not possible. To explain this briefly: The source and target wikis run on two independent databases where page and revision IDs refer to different pages. It is technically necessary to create a new page on the target wiki.

Maybe phab:T196735 is an option for your use case?

Rehman (talkcontribs)

Thank you for your reply, Thiemo. T196735 speaks about deletion of the original file, thus there is still some "duplicate" edit created, before being deleted for most users (users with privileged access can permanently see the duplicate edits).

Maybe this could be posted as a suggestion somewhere?

Reply to "Move original file (instead of copy)"

Local wikilinks should be adjusted during import

2
Summary by Thiemo Kreuz (WMDE)
Kaldari (talkcontribs)

Local wikilinks (mostly found in descriptions), like [[Belphegor's prime]] should be changed to [[:en:Belphegor's prime|Belphegor's prime]] during import so that they don't all turn into redlinks.

Jeff G. (talkcontribs)

Support.

Reply to "Local wikilinks should be adjusted during import"
Kaldari (talkcontribs)

When I clicked on the "Export to Wikimedia Commons" tab, I expected it to open a tab (as all the other tabs do), not send me off to a completely different website. The link should either be moved under the "More" menu (which is where the similar function of file moving lives), or next to the "Open in Media Viewer" button under the image. It's placement in a tab is both confusing and overly prominent (as this is not a feature that will be used anywhere near as often as other tab features). Otherwise, it is a great feature. Nice work!

Reply to "Misuse of the tab metaphor"

Cross-wiki imports of Commons-incompatible media

5
Summary by Thiemo Kreuz (WMDE)
Manlleus (talkcontribs)

Hi! I don't have tested the extension yet, but i see another "feature" to be added, something like the ability to export an image to another wiki edition, not only commons. That can save some time to article maintainers. Thanks

Thiemo Kreuz (WMDE) (talkcontribs)

What exactly do you have in mind when you say "another wiki edition"?

Manlleus (talkcontribs)

to upload an image from english wikipedia (copyrighted like film or game cover for example) to another language without using local uploader of the wiki target, all from the same page with a button or option and the ability to modify some info text fields of the license template like description, portion, resolution, etc.

Something like local wiki to another local wiki (no Commons)

Thiemo Kreuz (WMDE) (talkcontribs)

Thanks a lot for the clarification. Unfortunately there are no plans to install the FileImporter extension on other wikis than Wikimedia Commons. This would need at least a clearly communicated community consensus, as well as resources being assigned, mostly for communication. WMDE is currently unable to do this. However, the example of non-free media like cover art or movie stills that can be used in a few wiki languages only seems very plausible. We will keep this in mind.

Manlleus (talkcontribs)

Thanks, its just an idea, maybe a new extension cross-wiki to be added in the future. Good stuff