Topic on Help talk:Extension:FileImporter

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

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?

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.

Does it occur also in safe mode, i.e. on https://fa.wikipedia.org/wiki/%D9%BE%D8%B1%D9%88%D9%86%D8%AF%D9%87:Ertn.png?safemode=1 (with JS enabled)? If it doesn’t, the bug should be in a sitewide script, a gadget, or your m:User:Stefan2/global.js file.

My experience is the same as that of MGA73 above, but Tacsipacsi the tab does show on https://fa.wikipedia.org/wiki/%D9%BE%D8%B1%D9%88%D9%86%D8%AF%D9%87:Ertn.png?safemode=1 (with JS enabled). I am autoconfirmed on fawiki, I use the MonoBook skin, and my scripts are publicly available.

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

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?

• Open fa:File:Ertn.png in one tab.
• Open fa:Special:Preferences#mw-prefsection-gadgets in another tab.
• Disable 1 gadget at a time, save your preferences, and see what happens when you reload the 1st tab.
• If nothing changed, enable the gadget again, and disable the next one.

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

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

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.

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.

Thanks for figuring this out.

• The more recent edit is this one. Three categories are excluded: non-free content, images with unknown source, and images with unknown creator.
• FileImporter already checks for non-free files and doesn't allow moving them. However, for performance reasons this check is not done on the source wiki. The export button must be clicked to get told if the file can be exported.
• Unfortunately, the relevant configuration page for fawiki is was incomplete. The categories need to be added to the "bad categories" section.

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.

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.

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.

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.

@MGA73, Tacsipacsi: I liked the idea of disabling rather than hiding the tab, so I implemented it in fa:Special:Diff/32772652

@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?

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

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

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

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

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