Help talk:Extension:FileImporter

Jump to navigation Jump to search

About this board

Central feedback page for FileImporter/FileExporter.

Allow the extension to export files with supressed files/revisions

5
Summary by Johanna Strodt (WMDE)
Calvinkulit (talkcontribs)

I want this particular extension to import those files that have suppressed revisions/versions, so that it can absolutely replace CommonsHelper.

Johanna Strodt (WMDE) (talkcontribs)

Thanks for your feedback. In the past, the development team investigated the question whether files with suppressed revisions can be imported, but found out that this is very hard to do. You can find more information in this ticket: T225588

Best,

Johanna

Calvinkulit (talkcontribs)

Has it been finished? This question is the reason why I reopened this topic.

Calvinkulit (talkcontribs)
Pikne (talkcontribs)

T225588 mentioned above concerns revisions that are not hidden in source wiki. I'm not sure to what degree that's relevant here.

T162255 and T173836 also explored hidden revisions/file versions. It seems these tickets necessarily don't advice against importing such files, though the decision initially was to output an error message.

Reply to "Allow the extension to export files with supressed files/revisions"

Disable FileImporter in unfree files

7
Summary by Thiemo Kreuz (WMDE)
Andriy.v (talkcontribs)

Actualy when someone try to transfer files from local to Commons using FileImporter it redirect to a error banner. Is it possible to completely disable FileImporter button in unfree files?

Tacsipacsi (talkcontribs)

I’m not sure that would result in better user experience. Now the user loads a page, just to get the message that the file cannot be transferred, which wastes several seconds. If the tab is removed, the user only sees that the tab is not there, without any explanation of why (and there are many possible reasons: lack of free license template, presence of {{Do not move to Commons}} or similar, hidden file revision etc.).

Thiemo Kreuz (WMDE) (talkcontribs)

We investigated this at length as part of phab:T228858. There are two main reason we can not and do not want to do this: 1. Just disabling the buttons means users who see the button have no idea why it is disabled. Users need to be able to click it to see a helpful error message that allows them to understand what's going on. 2. Disabling the button means we would need to transfer all information from the Importer to the Exporter. This is technically so complicated, we believe it's not worth it.

Andriy.v (talkcontribs)

I can understand that for a huge comunities, like english wiki, it can be usefull because there's a lot of newbies every day, and some of them probably will use this feature one day. But in a medium/small comunities like ukrainian wiki there's only a few users that use this feature and most of them (if not all) are experienced users, like me, and the presence of a useless button is very unconfortable for me, especially because i using a lot of other tools and feature to working with unfree files. My request is a possibility to disable locally this button in MediaWiki namespace (for all comunity) or just for me (via personal script).

Thiemo Kreuz (WMDE) (talkcontribs)

Can you explain in more detail why the button makes you feel "uncomfortable"? There are many more buttons you probably never use. What's the specific issue with this one? Maybe it helps if you share a screenshot of your modified skin?

For what we at Wikimedia Deutschland do it's very important to always consider newcomers as well. It would be unhealthy, if not immoral to assume that all users in a particular community are experts. If we would do this, we would actively exclude newcomers – from communities that desperately need newcomers.

Tacsipacsi (talkcontribs)

If the goal is to disable it with a user script (or an on-wiki gadget), creating an API on Commons (i.e. in FileImporter) could resolve it with no additional runtime cost compared to a FileExporter API (a script/gadget makes an API query anyway, it doesn’t matter whether it’s a local or a Commons one). That’s relatively cheap in terms of development and maintenance costs, and the script/gadget is opt-in by nature, so newbies don’t get it by default.

Thiemo Kreuz (WMDE) (talkcontribs)

Yes, that's a possible implementation. However, having to provide long-term support and maintenance for an API is not cheap.

Reply to "Disable FileImporter in unfree files"

Date marking Template:Now Commons

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

Can FileImporter follow this syntax on en.w. so that the file isn't categorized in en:Category:Wikipedia files with the same name on Wikimedia Commons as of unknown date. Now you have to date mark the files manually but this can be fixed if FileImporter would use subst:. This is the syntax that should be used:

Same filename on Wikimedia Commons:

  • {{subst:Now Commons}}

New filename on Wikimedia Commons:

  • {{subst:Now Commons|NEW FILENAME.ext}}

Thanks!

Jonteemil (talkcontribs)

Ping anyone

Thiemo Kreuz (WMDE) (talkcontribs)

The feature is designed to work with all wikis. Not all wikis use subst:. We would need to somehow distinguish between wikis that want the "Now Commons" template to be placed with subst:, and wikis that don't want subst:. While it might be possible to implement this, it requires resources we can not spend on other things then, it requires a new configuration and someone who keep it up to date, it complicates the code and the process, and it's a new source of errors. We will have a look in our next FileImporter sprint, but no promises.

Jonteemil (talkcontribs)

That's understandable, just wanted to bring it to attention. Thanks for you answer’

Reply to "Date marking Template:Now Commons"

Admins to be able to ignore the NowCommons template restriction

4
Rehman (talkcontribs)

I often come across deletion requests on enwiki, for files that have been manually transferred to Commons (instead of using FileImporter). So instead of simply going ahead with the deletion request, I:

  1. Delete the previously manually transferred Commons file
  2. Edit the enwiki page to remove the "NowCommons" template (as FileImporter blocks imports with pages that has this template)
  3. Re-transfer the file from enwiki to Commons with history
  4. Delete the enwiki file.

Can we somehow overcome step 2? At least for power users? To me, it mostly seems to be an obstacle than a helpful feature. ~~~~

Michael Schönitzer (WMDE) (talkcontribs)

Hi, thank you for your input, it is valuable to see how people use FileImporter. You can edit the configuration of FileImporter for you wiki on Meta: https://www.mediawiki.org/wiki/Extension:FileImporter/Data/en.wikipedia When you remove NowCommons from bad, FileImporter will no longer block uploads of files with that template. It is however not yet possible to make this behavior depending on the user rights, so if you change it, this will apply for all users from English Wikipedia, so please check with others of your community, if they are ok with this change.

Rehman (talkcontribs)

Hi Michael. Thanks for the reply. When I get a bit more time, I will consider starting a discussion about this. Cheers.

Rehman (talkcontribs)

Hi again. Would you be able to suggest where I could start this discussion?

Reply to "Admins to be able to ignore the NowCommons template restriction"

Move original file (instead of copy)

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

Peteforsyth (talkcontribs)

It seems to me that this used to automatically add the "NowCommons" template, to tag the original file for deletion...but it is no longer doing that. Am I misremembering? It would be nice to have at least an option to automatically add that template. -Pete Forsyth (talk) 08:03, 6 December 2019 (UTC)

Tacsipacsi (talkcontribs)

@Peteforsyth: The option is still there, and I don’t remember it having been removed once it was added for the first time. It’s a checkbox, so it’s really just an option, but I think it defaults to checked, i.e. to add the {{NowCommons}} template.

Peteforsyth (talkcontribs)

Thanks, not sure why I missed it...I'll try the importer again soon to confirm on my end. Maybe I was blocking some relevant javascript or something. -~~~~

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

Activation on Wikisource

3
Summary by Thiemo Kreuz (WMDE)
VIGNERON (talkcontribs)

Hi,

Is it possible to activate this extension on the multilingual Wikisource? There is a lot file there (especially for the languages who are or were in incubation).

Thiemo Kreuz (WMDE) (talkcontribs)

There is a plan to enable the feature on all wikis, possible this April. If you like you can track phab:T232542 to get updates.

Tacsipacsi (talkcontribs)

According to phab:T198594, it was enabled on the multilingual Wikisource nearly two years ago. I have the beta feature on in my global preferences, so I’m not 100% sure whether the tab is visible by default, but certainly I managed to transfer File:Papillon les rousses.JPG, so it seems to work.

Reply to "Activation on Wikisource"
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.

Tacsipacsi (talkcontribs)

I also ran into this problem several times. I don’t want to be an OTRS volunteer, but I do want to import files to Commons that already have OTRS tags (added by OTRS volunteers, so having been confirmed). It’s really annoying when I spend several minutes with making the description Commons-compatible, finding the appropriate categories (sometimes even creating new ones, just to leave them empty), and then I get the error message saying “if you’re sure, please press the save button again”—but there’s no save button!

Reply to "OTRS"

Attribution breaks in some cases, potentially violating licenses

5
Summary last edited by Tacsipacsi 21:35, 15 March 2020 14 days ago
Peteforsyth (talkcontribs)

This is a great tool! However, I notice that when moving a file (example: File:Mary A Boren.jpg), the original uploader's name -- which in some cases is significant for attribution, i.e. with a CC BY or CC BY-SA license -- is originally linked to the user page on the origin wiki, but after file transfer it is linked to the user page on COMMONS (which may not exist). A simple change would avoid legal problems: change the link [[User:Name]] to [[languagecode:originwiki:User:Name]].

-Pete Forsyth (talk) 19:10, 1 February 2019 (UTC)

Thiemo Kreuz (WMDE) (talkcontribs)

Since the SUL finalisation (T37707) got resolved in 2015, the user pages on all Wikimedia wikis are guaranteed to the refer to the same legal person. So I have to ask. Can you please explain what exactly you mean when this "breaks", and what the "some cases" are that you are referring to?

Peteforsyth (talkcontribs)

Hi Thiemo, from the Creative Commons attribution license (v. 4.0):

If You Share the Licensed Material (including in modified form), You must: retain the following if it is supplied by the Licensor with the Licensed Material: identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated);

I would point specifically to the words "retain" and "reasonable." Take a look at the following example:

  • File on English Wikipedia:
    • Username attributed on the Wikipedia page prior to move (blue link leading to genuine information):
  • File after move to Commons:
    • Username attributed on Commons after move, but before manual repair (redlink):

The photographer uploaded the file to English Wikipedia, and in so doing, defined the way he wanted to be attributed. In addition to his username, the method of attribution included a link to a page that has his username, and further information about himself, including links to blog and website.

After a move by this tool, that information is not retained. The blue link becomes a red link, which leads to a blank page inviting the reader to "create" it. It matters not to any reader who lacks intimate familiarity with the inner workings of wiki sites that there is some link between that blank page with the word "create" and some page on a different website which has the information they may have been seeking. To expect most users to get from the page they land on to the page originally linked as attribution would not be reasonable.

The solution to this problem, I think, is technically very simple: Simply have the tool insert the proper code in any relevant userpage links to retain the original link, as I did manually here.

-Pete Forsyth (talk) 19:18, 4 February 2019 (UTC)

Peteforsyth (talkcontribs)

To be clear, my primary concern is about the licensing requirement for attribution and the "author" field, not about provenance and the upload log. In this similar case, I don't see a major problem, even though this tool does result in the loss of some information (the user page of the original uploader). In an ideal world, moving the page would not result in the loss of that information; however, it is less important that the upload log be retained, because information about the author and about the uploader is kept separately, and authorship is more important (both legally and in practice). -Pete Forsyth (talk) 19:33, 4 February 2019 (UTC)

Thiemo Kreuz (WMDE) (talkcontribs)

Thanks a lot for the additional information, this is super helpful! I believe this can be solved together with what we already collected in T198584.

Summary last edited by Tacsipacsi 21:31, 15 March 2020 14 days ago
Stjn (talkcontribs)
Thiemo Kreuz (WMDE) (talkcontribs)

The syntax in your example is perfect. Good job! Unfortunately, the tool currently does not fully understand this. When a parameter is listed multiple times, only the last instance is used. I created phab:T213955 to help us keep track of this requirement. Until then, I suggest to list the more common spelling variant of each parameter last.

Hinweistext anpasssen, dass Vorlage "Now Commons" einzufügen ist

5
Summary by Tacsipacsi
Z thomas (talkcontribs)

Nach dem Dateiimport erscheint die Hinweismeldung

"Wir bitten dich, dass du zur Originaldatei zurückkehrst und das Folgende unternimmst:

  1. Entferne alle Vorlagen, die vorschlagen, dass diese Datei nach Wikimedia Commons kopiert werden soll.
  2. Ergänze eine Vorlage, die erklärt, dass diese Datei jetzt auf Wikimedia Commons verfügbar ist.

Vielen Dank!"

Schön, wäre es, wenn unter Punkt 2 der Hinweis "eine Vorlage" durch den Vorlagennamen ersetzt wird.

Noch schöner wäre es, wenn die Vorlage automatisch bei der Vorlage gesetzt wird

Thiemo Kreuz (WMDE) (talkcontribs)

Danke für den Vorschlag. Leider sind die NowCommons-Vorlagen kein Teil der Software, sondern ein Teil des jeweiligen lokalen Community-Prozesses, und heißt auf vielen Quell-Wikis anders, zum Beispiel fr:Modèle:Image sur Commons. Der Aufwand zur Pflege von an alle Quell-Wikis individuell angepassten Nachrichten wäre zu hoch. In vielen Sprachen wäre der Hinweistext schnell veraltet und dann für den Benutzer noch weniger hilfreich als der momentane, allgemein gehaltene Text. Solche Aufgaben werden besser von Bots übernommen, die Dateiduplikate erkennen und passend markieren.

Z thomas (talkcontribs)

Ah, vielen Dank für die Antwort. Gibt es die Möglichkeit zusätzlich zu den lokalen Vorlagen eine globale Vorlage zu erstellen, die in allen Sprachversionen existiert?

Falls ja, könnte man diese einbauen und dem Dateiüberträger aber die Möglichkeit geben, eine andere (lokale) Vorlage einzubauen.

Thiemo Kreuz (WMDE) (talkcontribs)

Globale Vorlagen sind ein seit langem geäußerter Wunsch, siehe task T52329 und task T121470, aber weit außerhalb dessen, was aktuell für den FileImporter realisierbar ist.

Es wäre auch nicht richtig, die Hinweistexte manuell anzupassen. Der französischsprachige Hinweistext darf nicht den Vorlagennamen von der französischsprachigen Wikipedia enthalten, denn welche Sprache der Benutzer des FileImporters auf Commons für sich eingestellt hat (z. B. Französisch), ist unabhängig davon, von welchem Quell-Wiki importiert wird (z. B. dewp). Der Text würde dann fälschlich darum bitten, in dewp {{Image sur Commons}} zu benutzen.

Z thomas (talkcontribs)

Da hast du natürlich recht. In dem Fall müsste der Hinweistext dynamisch sein, dh. es müsste das Template des Quell-Wikis eingebunden werden. Aber da hattest du ja schon zu recht gesagt, dass das von der wartung zu aufwendig ist.