Help talk:Extension:FileImporter

Central feedback page for FileImporter/FileExporter.

The script adds the NowCommons but sometimes the local NowCommons require that "File:" is included and sometimes it does not.

Would it be possble to have an option to include "File:" or not?

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?

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

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.

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).

I suggest include Imported using FileImporter, in the template Now Commons.

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.

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.

Tracked in Phabricator
Task T259690

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

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.

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

Jmabel: That was removed in this edit.

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.

Extension:FileImporter/Data/en.wikiversity#Good lists the known good licenses, you can add any missing ones there.

Thanks. I've added the template.

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).

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.

Done, as phab:T312875.

Hello!

I tried to import w:File:Youth_Olympic_Games_Third_Version.svg the other day but it didn't work, as MGA73 below I got the message Fatal exception of type "CannotCreateActorException". Yesterday I tried again and I again got the error message but c:File:Youth_Olympic_Games_Third_Version.svg was imported anyway, however only the latest version and my import wasn't logged in the log or file history. What's going on?

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!

Tracked in Phabricator
Task T308691

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).

Could this be related to phab:T308663?

Added to the config page.

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)

The reason is that this license is not listed as being compatible in mw:Extension:FileImporter/Data/lv.wikipedia#Good. I believe this was a mistake. I added the license.

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.

@Stefan2: This appears to be the result of a database error in which https://upload.wikimedia.org/wikipedia/en/archive/4/49/20070817224239%21Almakerek6.jpg and https://upload.wikimedia.org/wikipedia/en/thumb/archive/4/49/20070817224239%21Almakerek6.jpg/120px-Almakerek6.jpg (and other thumbnail sizes) are missing.

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

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.