Help talk:Extension:FileImporter

About this board

Central feedback page for FileImporter/FileExporter.

PD files with hidden revisions

4
Illegitimate Barrister (talkcontribs)

There are a bunch of public domain free files that have hidden revisions because they were wrongly tagged as copyrighted. These can't be imported with fileimporter. How would I move them?

Pppery (talkcontribs)

Get an admin to unhide them. It this is about the English Wikipedia then en:Wikipedia:REFUND is the standard venue.

Thiemo Kreuz (WMDE) (talkcontribs)

I see two options. Either ignore the old revisions and manually re-upload only the latest one. Or ask an admin to undelete the revisions on the source wiki before starting the export.

Stefan2 (talkcontribs)

I suspect that these files are mostly logos initially tagged with w:Template:Non-free logo and then re-tagged with w:Template:PD-textlogo. If so, carefully check that the deleted revisions aren't older logos for the same entity (which might be copyrighted).

Reply to "PD files with hidden revisions"

Imported using FileImporter

3
BoldLuis (talkcontribs)
Tacsipacsi (talkcontribs)

How? Using a parameter won’t work; without Multilingual Templates and Modules, we can’t make sure that it works across wikis. The name of the template is taken from Wikidata, but Wikidata can’t provide any information on a template other than its name.

Christoph Jauera (WMDE) (talkcontribs)

Hi @BoldLuis. Currently the template used as default to be added to the source wiki is configured as a Wikidata item of the type Wikimedia template. For the wikis in production this is https://www.wikidata.org/wiki/Q5611625


This way we can make sure that each project gets the language version needed. Apart from that there's no customization possible at the moment.

Reply to "Imported using FileImporter"

It says to activate in the Beta portion of preferences...

4
Summary by Thiemo Kreuz (WMDE)
Jmabel (talkcontribs)

... but I don't see it offered in the preferences on en-wiki. - Jmabel (talk) 03:15, 23 November 2022 (UTC)

Jeff G. (talkcontribs)

Jmabel: It was included in "Deployment as a default feature on all remaining Wikis" on 2020-08-05 per Help:Extension:FileImporter#Deployment roadmap (ignore the language about "beta" on that page). While viewing a file description page on enwiki (or any non-Commons WMF production wiki), look for a tab labeled "Export to Wikimedia Commons" in Vector or "export to wikimedia commons" in Monobook.

Jmabel (talkcontribs)

Then the remark here about Beta should be removed, no? - Jmabel (talk) 16:04, 23 November 2022 (UTC)

Jeff G. (talkcontribs)
Reply to "It says to activate in the Beta portion of preferences..."

FileImporter is not recognizing {{PD-textlogo}} from Wikiversity

3
Ixfd64 (talkcontribs)

I tried to import a file tagged with {{PD-textlogo}} on the English Wikiversity to Commons, but FileImporter does not recognize it as having a valid license.

Tacsipacsi (talkcontribs)
Ixfd64 (talkcontribs)

Thanks. I've added the template.

Forcing Import for duplicate file

3
Locke Cole (talkcontribs)

Not sure if this is beyond the scope of this extension, but would it be possible to detect when someone is attempting to upload an identical file from another Wikimedia project (like English Wikipedia) directly to Commons and change that action into a FileImport automagically? This would help keep revision histories intact, and stop editors who may be deliberately trying to "take credit" for work they didn't do from doing so (bonus points if it detects an attempt to upload a non-current version of an identical file from another project).

Thiemo Kreuz (WMDE) (talkcontribs)

I think this is technically possible. It can probably reuse the technology we can see at the bottom of Commons file description pages where usages in other wikis are listed. What makes it especially complicated is that there are so many ways to upload files. Some UX work is needed as well to let the user know what's going on. The team at Wikimedia Deutschland currently doesn't have the resources to work on this. But it might be wort a feature-request ticket on Phabricator.

Locke Cole (talkcontribs)
Reply to "Forcing Import for duplicate file"
Jonteemil (talkcontribs)
Christoph Jauera (WMDE) (talkcontribs)

Hej @Jonteemil!

There was an issue with FileImporter that triggered that error and might have broken some imports. [1]

It should be fixed now though. If you have a broken import on Commons now, please try to reach a Commons admin and ask for the file to be deleted there so you can import it again.

Thanks!

Reply to "Bug?"

CannotCreateActorException

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

Hi! I tried to re-import ja:ファイル:Tojyo-kiha120.JPG so I deleted the file on Commons and tried. I get the message "[81d89d35-b45b-4150-9712-1c6331024e55] 2022-05-18 17:32:23: Fatal exception of type "CannotCreateActorException"". Any idea why? (I restored the file on Commons again so you will get a dupe warning if you try now. You can just revert on ja.wiki and try).

Jeff G. (talkcontribs)
Reply to "CannotCreateActorException"
Summary by Thiemo Kreuz (WMDE)

Added to the config page.

Silraks (talkcontribs)

Maybe I am missing something, but I think the license cc-by-sa-4.0 is allowed on Commons.

If that is so, then it seems FileImporter does not recognize it properly and does not allow importing of such images.


Maybe it does not affect all images with the license, but I had trouble with this file (and the reason of a incompatible license being given)

Thiemo Kreuz (WMDE) (talkcontribs)

One file revision returns a 404 error

4
Stefan2 (talkcontribs)

The first revision of w:File:Almakerek6.jpg returns a 404 error. It is possible to start the transfer process and I was able to press the edit button to add c:Category:Lutheran church in Mălâncrav-interior to the file information page, but when I press the final transfer button, the transfer fails because the tool can't find the file.

If a file can't be transferred, please warn before the user starts cleaning up the file information page so that time isn't wasted on this if the cleaned up information can't be used in the end. Also, please try to find a way to transfer files like this while preserving the upload log. If the file is gone from the server, then it can't be uploaded to Commons, but it's still useful to see that there was a file on Wikipedia at one point.

Jeff G. (talkcontribs)
Johanna Strodt (WMDE) (talkcontribs)

Thanks for reporting this issue! I've passed it on to our engineering team so they can have a look at it.

Thiemo Kreuz (WMDE) (talkcontribs)

There are many things that can go wrong during a file transfer. Most of them are checked before. But this is not always possible. We can't, for example, download megabytes worth of files just to check if it will work.

It might be possible to add a validation step that does a quick HEAD check for all file revisions. This will catch the described edge case. However:

  • What to do then? We don't want to skip broken revisions without leaving a trace, nor do we want to create broken database entries.
  • Implementing this takes up resources that can't be invested otherwise. Is this worth it? How many files like this exist?

In a situation like this the best solution might be to use one of the older transfer tools.

Reply to "One file revision returns a 404 error"

FileImporter is not showing on all files on fa.wiki

21
MGA73 (talkcontribs)

Is it my settings that is messed up or is there something strange going on at fa.wiki?

On fa:File:Ertn.png the export tab does not show up unless I click edit (then it shows up).

On fa:File:Alidivandari-photo1.jpg the export tab shows up both with and without edit.

I tried both with and without "Use Legacy Vector".

Thiemo Kreuz (WMDE) (talkcontribs)

I had a look but don't understand what's going on. A bunch of criteria must be met, but they all are: You need to be "autoconfirmed". The file must be local (i.e. not already on Commons). For me, the button is always there. Might be some kind of caching issue?

Stefan2 (talkcontribs)

On fa:File:Ertn.png with "Use Legacy Vector", I see the "Export to Commons" link for half a second and then it disappears. The link also shows up for half a second if I use useskin=monobook. It doesn't disappear if I click on edit.

If I disable javascript (setting javascript.enabled in Firefox about:config), then I see the "Export to Commons" link properly.

Tacsipacsi (talkcontribs)
Jeff G. (talkcontribs)
MGA73 (talkcontribs)

When I click the link User:Jeff G. mention (safemode=1) then I see the tab.

Thiemo Kreuz (WMDE) (talkcontribs)

That helps a lot already. Thank you! Unfortunately I'm unable to do more tests myself. I don't have access to an account that is autoconfirmed on fawiki. Since MGA73 apparently doesn't have any custom JavaScript running, I believe either one of the gadgets or Beta features is causing the issue. Can one of you do the following test?

Try to do the same with the Beta features and let us know. Thanks!

MGA73 (talkcontribs)

I had no beta and even if I disable all gadgets it still do not work.

Tacsipacsi (talkcontribs)

I found it in Common.js (added by Huji), and it seems to be intentional: it’s hidden for non-free files. While I understand the intent, it turned out to be confusing, so maybe another approach should be considered (e.g. greying out the tab), or simply FileImporter should be set up in a way that it doesn’t allow importing non-free files.

MGA73 (talkcontribs)

FileImporter can allready prevent you from moving "bad" files. However it was not set up to do block non-free files. But since no non-free licenses is added it can't move then.

But I like the idea that FileImporter is grey if FileImporter can't move the file.

Thiemo Kreuz (WMDE) (talkcontribs)

Thanks for figuring this out.

I suggest to not remove or disable the button. Being able to click it is helpful: It gives the user an explanation. Hiding the button is just confusing, as we have seen.

MGA73 (talkcontribs)

I have added the category for non-free content but not the two other. I agree that files normally need a source and author but if it is a very old file or it is PD-ineligible then we do not need it. Or perhaps someone want to move the file to Commons and fix it there. Personally I find it very hard to edit on pages that do not edit left-to-right so I usually move to Commons and edit there.

Stefan2 (talkcontribs)

I think that it only is a waste of time to clean up a page on the source wiki since it's just going to be deleted shortly after the transfer. Say a PD-textlogo is tagged as w:Template:Non-free logo and you wish to move it to Commons. You need a correct file information page on Commons, but there is no need for an adjusted file information page on Wikipedia as it will simply be deleted shortly after it's transferred. It's much faster to clean it up on Commons only than to first clean it up Wikipedia and then clean it up again on Commons because the transfer tool doesn't take care of everything which need to be done on Commons. If files without source or author can't be moved without adding a pro forma template, this just increases the time to transfer files to Commons.

MGA73 (talkcontribs)

Good example Stefan. But in this case we have to balance between saving time and prevent users without knowledge of copyright to move lots of copyvios to Commons. I'm afraid that if we make it too easy then we will flood in bad files.

Huji (talkcontribs)
MGA73 (talkcontribs)

@Huji: Perhaps that will be confusing too. Now users can see the tab and click it but nothing happens. If you do not disable it and users click they will get a message like this:

"This file cannot be transferred to Wikimedia Commons, because it is marked as رده:تصویرهای با منبع نامعلوم. Wikimedia Commons does not allow such files. This might be resolvable, but most probably means the file is not compatible. Please consult the Wikimedia Commons community policy and talk pages about licensing."

That way users will be told what the problem is and they will have an idea how to fix it. Is there a way to make the tab grey but still allow users to click it?

Huji (talkcontribs)

@MGA73: done in fa:Special:Diff/32777121. Can you point me to where the ineligible category names are stored? I want to make sure the list is complete.

MGA73 (talkcontribs)

@Huji: The configuration is done at Extension:FileImporter/Data/fa.wikipedia.

You can add both bad categories and bad templates. If they are on the file FileImporter will refuse to move the file.

You can also add good templates. FileImporter will only move the file if at least 1 good template is found.

Jeff G. (talkcontribs)

@MGA73: Is it fair to assume that anything bad overrides any good templates?

MGA73 (talkcontribs)

Jeff Yes a bad category or template means full stop. End of game.

Huji (talkcontribs)

@Jeff G.: the logic seems to be defined here and the functions called there are defined here. The page must have at least one good template AND no bad templates AND no exclusionary categories.

Reply to "FileImporter is not showing on all files on fa.wiki"