Help talk:Extension:FileImporter

Jump to navigation Jump to search

About this board

Central feedback page for FileImporter/FileExporter.

Admins to be able to ignore the NowCommons template restriction

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

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

Handle the "raw page scan" templete from English Wikisource

5
Peteforsyth (talkcontribs)

It would be nice if this could properly bring information from the "raw page scan" template on English Wikisource. Here is an example of what the File Importer will bring over: https://commons.wikimedia.org/w/index.php?title=File:Portland,_Oregon,_its_History_and_Builders_volume_1.djvu-389.png&oldid=379183981

Here is an example of how Magnus Manske's "CommonsHelper" tool would handle a similar situation: https://commons.wikimedia.org/w/index.php?title=File:Harvey_W._Scott_portrait.png&oldid=160507227

Can the FileImporter be modified to behave in the same way? -Pete Forsyth (talk) 03:08, 6 December 2019 (UTC)

Jeff G. (talkcontribs)
Peteforsyth (talkcontribs)

@Jeff G.: That's a great improvement! Ideally, it would be nice to have a script that could interpret {{raw page scan}} and replace it with {{information}} -- but that might be a lot to ask. As a strong intermediate step, importing the template as you did is certainly a big help. Thanks! -Pete Forsyth (talk) 23:22, 11 December 2019 (UTC)

Jeff G. (talkcontribs)

@Peteforsyth: You are welcome to improve the imported template to better serve the needs of Commons, English Wikisource, and any other interested projects or users. Commons is a wiki, too.

Peteforsyth (talkcontribs)

I'm operating on the belief that documenting a useful possible improvement, even if I lack the technical skill to implement it myself (which I do), is a useful thing to do. If I'm in error, please let me know and I'll stop. -Pete Forsyth (talk) 18:59, 12 December 2019 (UTC)

Reply to "Handle the "raw page scan" templete from English Wikisource"
Calvinkulit (talkcontribs)

Make it non-beta. ~~~~

94rain (talkcontribs)
Michael Schönitzer (WMDE) (talkcontribs)

It will soon go out of beta. Thanks for the feedback!

Calvinkulit (talkcontribs)

When exactly?

Michael Schönitzer (WMDE) (talkcontribs)

We don't have an exact date yet. We hope that we can go out-of-beta in the first few wikis (de, fa, ar, ko, wikisourceswiki) still in August and then follow with the all other wikis in September. But as always it depends on whether we still find any important bugs or are blocked by anything.

Peteforsyth (talkcontribs)

For what it's worth, I agree -- it seems to me important bugs have been fixed, and this is ready for wider deployment. Kudos to the team! -Pete Forsyth (talk) 08:07, 6 December 2019 (UTC)

Reply to "Some thoughts"

Move original file (instead of copy)

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

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

Would the option to select a license, similar to when you upload a file, be possible? Currently it denies the move and I have to hunt down the license.

Reply to "License selector"

Allow {{copyrighted free use}} images on enwiki to be exported to Commons

2
Calvinkulit (talkcontribs)

I've been trying to export copyrighted free use files to Commons, but it will not work.

Thiemo Kreuz (WMDE) (talkcontribs)
Reply to "Allow {{copyrighted free use}} images on enwiki to be exported to Commons"

Allow the extension to export files with supressed files/revisions

4
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)
Reply to "Allow the extension to export files with supressed files/revisions"

Automatically insert date for Now Commons?

2
Summary by Johanna Strodt (WMDE)
Roy17 (talkcontribs)

The latest feature of automatically marking source files with Now Commons is great, but could it please include the date as well? Instead of {{Now Commons|file name}}, please insert {{Now Commons|file name|date={{subst:#time:Y-m-d}}}} .

Johanna Strodt (WMDE) (talkcontribs)
GoEThe (talkcontribs)
Michael Schönitzer (WMDE) (talkcontribs)

Hi, thanks for reaching out to us. We are curious, how did you manage to have no free files uploaded on ptwikipedia? Are there no files that are accidentally uploaded locally even-through they could be uploaded to Commons? We would be glad to see any links about that. Furthermore we're wondering what the motivation is for disabling the extension on ptwikipedia?

GoEThe (talkcontribs)

The community voted not to allow local file upload in 2006 (https://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Vota%C3%A7%C3%B5es/Impedir_carregamento_de_imagens). I don't remember how this was implemented (I was a newbie at the time). We then allowed non-free content in 2009 (https://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Vota%C3%A7%C3%B5es/Uso_Restrito_de_Conte%C3%BAdo_(fair-use)). Only users with more than 500 edits and registered more than 45 days ago can upload files (implemented through a filter: https://pt.wikipedia.org/wiki/Especial:Filtro_de_abusos/92). Our upload page also has clear instructions on how to proceed for free and non-free images (https://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Carregar_ficheiro).

My only concern about having the extension active is that it might produce unnecessary work for others as the only files we have would not be allowed in Commons, so allowing the extension might allow the upload of non-free files that would have to be deleted.

Michael Schönitzer (WMDE) (talkcontribs)

Thank you very much for the explanation and the links – this is very interesting for us to know. About your concern that non-free files might get moved to Commons and produce extra work: This can be avoided easily by editing the configuration page of File-Importer. You can find it here: https://www.mediawiki.org/wiki/Extension:FileImporter/Data/pt.wikipedia Only files that have a template listed under the section "good" can be moved to Commons using the FileImporter. If you empty the list, you disallow to move any File to Wikimedia Commons.

Reply to "Deactivate on ptwikipedia"
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.
Perhelion (talkcontribs)
  • 2) Any example for your claim? I know only a bug in the Commons mobile App phab:T232142
Geagea (talkcontribs)
Perhelion (talkcontribs)

Yes it is more general. You are right, as you described the problem more detailed on Commons.

Geagea (talkcontribs)
Pikne (talkcontribs)
  • 1) It's somewhat similar to moving a file within a wiki. Then file also wasn't uploaded directly to new location. I think it makes sense that import information is kept in page history and logs along with other information on who did what to a file. While the situation that file version wasn't uploaded directly to Commons is relatively new, it has been the case for page revision imports for quite some time that author necessarily didn't edit on the very same wiki. I think we'll get used to it regarding file versions too. :)
  • 2) Notifying the importer might be something for maintainers of the gadget behind "Nominate for deletion" sidebar link on Commons to consider. Discussion being on Commons and possible language problem concern earlier files moved to Commons, too. Having FileImporter and cross-wiki notifications I'd say is definitely an improvement in this matter as it's easier to notify the original uploader. Wiki communities should probably give thought on how to handle these discussions better and then see if this leads to some specific technical feature request.
  • 3) File version being attributed to local user on Commons to my understanding is deliberate. T209346 has some of the background. Editable links, including links to user pages, were already set to point back to source wiki automatically (T198584). As for "user at project" template I know that some people use it, but I've never felt comfortable with it. After all, author field is where author provides proper attribution in accordance with licensing terms, and we probably shouldn't alter this by adding something like "from Wikipedia" to it. Using this template probably isn't straightforward enough to include it for all FileImporter imports.
Reply to "Some thoughts"