Help talk:Extension:FileImporter/2019

Central feedback page for FileImporter/FileExporter.

Not yet in Common's preferences

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

@Johanna Strodt (WMDE): In spite of what’s announced here, this feature is not yet shown in my preferences. (Apparently, I hadn’t set my preferences here in MW to disable the VisualEditor. Boy, is this thing even more of an UI nightmare than it was before! Cannot go and tick it disabled fast enough!) Tuvalkin (talk) 12:06, 14 January 2019 (UTC)

Oh, I’m so dumb. Of course a gadget to import files to Commons i not available in Commons! Please forget this! Tuvalkin (talk) 12:10, 14 January 2019 (UTC)

No worries, @Tuvalkin.

Also, right now, the beta feature is available on a handful of first wikis. Deployment to all other wikis is planned for January 16.

Best, Johanna Johanna Strodt (WMDE) (talk) 12:13, 14 January 2019 (UTC)

@Tuvalkin I've just updated my message on Commons. Now it should be clearer that there are two different extensions at work; one on Commons, and one on the wikis to export from:

https://commons.wikimedia.org/w/index.php?title=Commons%3AVillage_pump&type=revision&diff=334807278&oldid=334805974 Johanna Strodt (WMDE) (talk) 12:19, 14 January 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Localization

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

This is a great extension! I've started trying it out on yue.wp .

How do we localize the tool's messages? For example the name and description of the tool on Special:Preferences? Deryck C.^Meta 14:15, 16 January 2019 (UTC)

We are happy you like it! All languages other than English are managed here: https://translatewiki.net/wiki/Special:Translate/ext-fileimporter Thiemo Kreuz (WMDE) 14:21, 16 January 2019 (UTC)

(translatewiki:MediaWiki:Fileimporter-sourcetitleexists)

"The title you are currently trying to import to already exists on the source wiki."

Do you mean "destination wiki"? Deryck C.^Meta 16:55, 18 January 2019 (UTC)

Excellent question. I checked and made sure the message intentionally talks about the source wiki. I updated the explanation for this message at translatewiki:MediaWiki:Fileimporter-sourcetitleexists/qqq. I hope this explains it better. Thiemo Kreuz (WMDE) 17:58, 18 January 2019 (UTC)

Thanks. I localized it with the meaning "The title you are trying to use is being used by another file on the source wiki." Deryck C.^Meta 10:12, 22 January 2019 (UTC)

yue and zh-hant all done! Thank you! Deryck C.^Meta 18:31, 18 January 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Parameter aliases

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Is this a fool-proof way to add parameter aliases? If not, what is one? We have some discrepancies in the way information template is filled in across the files, and I would like to fix this when importing. stjn^[ru] 18:35, 16 January 2019 (UTC)

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. Thiemo Kreuz (WMDE) 19:26, 16 January 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

delete original file?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I uploaded this from this, changing the file name. I'm curious about what to do next: mark the original for deletion, or redirect it...? Tx! Zack (talk) 22:16, 16 January 2019 (UTC)

This depends on the processes in your local wiki. One possibility is to make sure the old file name is not used any more, and then delete it. Thiemo Kreuz (WMDE) 09:23, 17 January 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Cross-wiki imports of Commons-incompatible media

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hi! I don't have tested the extension yet, but i see another "feature" to be added, something like the ability to export an image to another wiki edition, not only commons. That can save some time to article maintainers. Thanks Manlleus (talk) 12:26, 17 January 2019 (UTC)

What exactly do you have in mind when you say "another wiki edition"? Thiemo Kreuz (WMDE) 13:13, 17 January 2019 (UTC)

to upload an image from english wikipedia (copyrighted like film or game cover for example) to another language without using local uploader of the wiki target, all from the same page with a button or option and the ability to modify some info text fields of the license template like description, portion, resolution, etc.

Something like local wiki to another local wiki (no Commons) Manlleus (talk) 14:51, 17 January 2019 (UTC)

Thanks a lot for the clarification. Unfortunately there are no plans to install the FileImporter extension on other wikis than Wikimedia Commons. This would need at least a clearly communicated community consensus, as well as resources being assigned, mostly for communication. WMDE is currently unable to do this. However, the example of non-free media like cover art or movie stills that can be used in a few wiki languages only seems very plausible. We will keep this in mind. Thiemo Kreuz (WMDE) 09:20, 18 January 2019 (UTC)

Thanks, its just an idea, maybe a new extension cross-wiki to be added in the future. Good stuff Manlleus (talk) 10:51, 18 January 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Incompatible "self" license

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

When exporting from it.wiki, I encountered a file (https://it.wikipedia.org/wiki/File:2007-Mostra_di_Riccardo_Del_Fa3.JPG) where the import was blocked because of "incompatible license". The license in this case is more than valid: {{Self|cc-by-sa-4.0}}.

Maybe what's behind the "self" should be checked as well... Thanks Ruthven (talk) 12:43, 17 January 2019 (UTC)

Which licenses allow a transfer to Commons is an individual community decision. The relevant configuration in this case is Extension:FileImporter/Data/it.wikipedia#Good. It seems it misses the it:Template:Cc-by-sa-4.0. I see Creative Commons 4.0 licenses are listed on other configuration pages (e.g. en and de), so I assume it is fine to add it.

The fact that a license template is transcluded indirectly via {{self|…}} does not make a difference. FileImporter will find it. Thiemo Kreuz (WMDE) 13:28, 17 January 2019 (UTC)

That's correct, my mistake. I assumed that the CC by-sa 4.0 license was added to the list already. Just adding the name of the template in the list will suffices? Thanks. Ruthven (talk) 13:32, 17 January 2019 (UTC)

Yes, your edit looks like it should do it. Thanks for using the tool and the feedback. Both is very much welcome. Thiemo Kreuz (WMDE) 08:50, 18 January 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Option to delete file on transfer to Commons?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

So I am an admin on Enwiki, and after I do the import, I would like to be able to quickly fill out the deletion rational and delete the file that is unnecessarily hanging out on the local Wiki. Is there any way to toggle an option to go directly to the deletion interface? Otherwise, It takes me about 4 more gestures with my mouse to get to the Delete File interface. I am leaving the names on the files the same -- so it, in theory, should be something that could be made much more efficient. Sadads (talk) 23:07, 17 January 2019 (UTC)

@Sadads Thanks for your comment! Currently, there's no way to do this, but this request has been raised before: T196735 I've added your comment there.

Have a happy weekend,

Johanna Johanna Strodt (WMDE) (talk) 12:36, 18 January 2019 (UTC)

Thanks @Johanna Strodt (WMDE)! Sadads (talk) 15:46, 18 January 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Not working, and error message not helpful

The configuration file for your wiki (https://www.mediawiki.org/wiki/Extension:FileImporter/Data/id.wikipedia) does not contain enough info about <Information/Licensing> to know if this file can be put on Commons.

I'm trying to move my file: https://id.wikipedia.org/wiki/Berkas:Laweyan.svg

What does it mean that it does not contain enough info about <Information/Licensing>? Bennylin (talk) 01:06, 20 January 2019 (UTC)

We updated this message just a few days ago. Now it says: The configuration page for your wiki (Extension:FileImporter/Data/id.wikipedia) does not contain enough information to know if this file can be put on Commons. Please make sure it contains a section "Information/Licensing". Does this explain it better?

I also fixed a spelling mistake on Extension:FileImporter/Data/id.wikipedia. Can you please try again? Thiemo Kreuz (WMDE) 08:53, 21 January 2019 (UTC)

Is "subst:" allowed in {{Information }} template configuration?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I am trying to properly configure Extension:FileImporter/Data/en.wikipedia after there were requests to rewrite Information template on Commons to make it work with this extension. The issue is that w:en:Template:Information has some rarely used extra parameters as compared to c:Template:Information ("Location" and "Additional_information")and we would like not to loose their content. Traditionally when mapping from one template to another we use substitution, for example c:Template:Artwork/subst(information) can be used to map from c:Template:Information to c:Template:Artwork. I would like to use the same mechanism to handle w:en:Template:Information's "Location" and "Additional_information" so we can add them either to c:Template:Information's "description" field or to a separate field added using "Other fields" parameter. So can I use "Subst:" configuration file? Jarekt (talk) 16:00, 21 January 2019 (UTC)

Thanks for testing the feature and for your question, @Jarekt. Using "Subst:" currently isn't possible, but I've created a Phabricator ticket so T214365 we have this request on our radar.

Best,

Johanna Johanna Strodt (WMDE) (talk) 11:39, 22 January 2019 (UTC)

Johanna thanks for you reply. Is there another way one can use to map multiple fields in the source template into one? Jarekt (talk) 14:41, 22 January 2019 (UTC)

Hi @Jarekt. No, I'm afraid at the moment there's no way to merge multiple source parameters into one. I've updated the task description to make room for other solutions than "subst:". I hope that's alright with you.

Also, I've added your question to the FAQ, as I can imagine it's of interest for others, too.

Best,

Johanna Johanna Strodt (WMDE) (talk) 09:25, 24 January 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

difficulties for configuration

Hi, We have been trying to use it on frwikisource, for books that are now PD is US also :D

for configuration, I began by copying the enws file https://www.mediawiki.org/wiki/Extension:FileImporter/Data/fr.wikisource - but the configuration is quite tricky, and not easy to do...

we would like to automatically add the Book template, to add info... but, I do not understand how to do this :( Hsarrazin (talk) 18:47, 29 January 2019 (UTC)

@Hsarrazin Thanks for your feedback. I'm guessing you want to match the contents of the template:Book on frwikisource to the template:Book on Commons? And maybe do the same for template:Information?

Can you describe a bit more what it is that you'd like to do? An example file would also help.

Thanks a lot,

Johanna Johanna Strodt (WMDE) (talk) 15:18, 30 January 2019 (UTC)

Project to import previously manually transferred files

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hello. Once the FileImporter passes all testing and becomes a fully enabled feature, are there any plans to [mass] import all of the historic content that was previously transferred without history (i.e. FAQ: What if I want to import a file to Commons that has been imported before (without the history)?

I understand that manually doing this would be almost impossible, mostly due to conflicting edit histories and having to painstakingly select correct history versions over thousands of files. Thus may I suggest that a simple tool be created (for admins) where we could:

1. Compare both histories of localwiki and commons side by side, including deleted versions
2. Select versions to undelete/transfer/delete, with the ability to undelete and delete files on the same screen/dashboard.
3. Also with a AWB-style diff-comparison for descriptions and categories
4. Maybe also features to support structured data.

Of course, we first need to figure out how to generate a list of files that were manually transferred before.

Just like me, I'm sure many of you feel the discomfort of knowing that many years worth of valuable edit history was lost when large numbers of files were manually transferred before this feature... I feel some level of effort should be put in at least creating a queue for the task, rather than depending on random people to select desired files to save history from... Just my thoughts. Best wishes from Colombo. Rehman 04:13, 30 January 2019 (UTC)

Thanks @Rehman! There are no plans for such a feature yet. But I've created a Phabricator ticket so we can keep track of this request: T215008

Feel free to edit or comment there if I got something wrong.

Best,

Johanna Johanna Strodt (WMDE) (talk) 10:04, 31 January 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Attribution breaks in some cases, potentially violating licenses

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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)

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? Thiemo Kreuz (WMDE) 12:00, 4 February 2019 (UTC)

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: [1]
  • Username attributed on the Wikipedia page prior to move (blue link leading to genuine information): [2]
• File after move to Commons: [3]
  • Username attributed on Commons after move, but before manual repair (redlink): [4]

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)

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)

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. Thiemo Kreuz (WMDE) 11:52, 7 February 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Option to delete original (or mark for deletion)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

When moving a file, in most cases, the description page on the origin wiki becomes unnecessary. Could a checkbox be added (like there is on Commons Helper) which will either delete the description page (if the user has the requisite rights), or marks it for deletion (e.g., by adding the "NowCommons" template)? -Pete Forsyth (talk) 19:12, 1 February 2019 (UTC)

@Peteforsyth Thanks a lot. There's a similar request on Phabricator (T196735), and I've added your feedback there.

Best,

Johanna Johanna Strodt (WMDE) (talk) 12:53, 4 February 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

language-tagged

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

To have Commons parameter language-tagged, it should be prefixed with "@". Description and source parameters have been prefixed with @ for Information template in Extension:FileImporter/Data/fa.wikipedia#Transfer. However, when I imported c:File:کباب تابه‌ای آبدار.jpg just a few minutes ago, none of the parameters were language-tagged, and I added {{fa|1=}} manually.

For example, try to import fa:پرونده:اشکنه خوراک ایرانی.jpg yourself and see the result. 4nn1l2 (talk) 05:48, 14 February 2019 (UTC)

@4nn1l2 Hi! Yes, the language tagging isn't working yet, but we have it on our radar: T198607

(It might be confusing that the configuration pages already include information for how to do the language tagging. That's because the config pages originate from the configuration files of the Commons2Helper tool.)

Best,

Johanna Johanna Strodt (WMDE) (talk) 08:57, 20 February 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Under 10 bytes file description page revisions break import to Commons for new Commons users

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

We have been having problems on Wikimedia Commons with new (to Commons) users of this tool not being allowed to import files with under 10 bytes file description page revisions, such as en:File:2018 AWS Sites ALL 03 29 2018.jpg and en:File:AntiBullyingCampaign.jpg, due to denial by c:Special:AbuseFilter/4. The current discussion is at c:COM:FILTERT#Report by Splattereel. Can this tool please be configured to not import under 10 bytes file description page revisions, or at least to pad the ones under 10 bytes with spaces or the 10 byte string "Padded4AF4"? See also phab:T215429 and phab:T213409.   — Jeff G. ツ 13:33, 15 February 2019 (UTC)

Thanks for your feedback, @Jeff G. I've added this to our list of feature requests that we'll look into during the beta phase.

Best,

Johanna Johanna Strodt (WMDE) (talk) 09:14, 20 February 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Move original file (instead of copy)

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)? Rehman 16:35, 9 March 2019 (UTC)

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? Thiemo Kreuz (WMDE) 10:49, 11 March 2019 (UTC)

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? Rehman 12:00, 13 March 2019 (UTC)

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)

@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. Tacsipacsi (talk) 21:41, 15 March 2020 (UTC)

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. -~~~~ Pete Forsyth (talk) 23:33, 15 March 2020 (UTC)

Misuse of the tab metaphor

When I clicked on the "Export to Wikimedia Commons" tab, I expected it to open a tab (as all the other tabs do), not send me off to a completely different website. The link should either be moved under the "More" menu (which is where the similar function of file moving lives), or next to the "Open in Media Viewer" button under the image. It's placement in a tab is both confusing and overly prominent (as this is not a feature that will be used anywhere near as often as other tab features). Otherwise, it is a great feature. Nice work! Kaldari (talk) 04:48, 13 March 2019 (UTC)

Local wikilinks should be adjusted during import

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Local wikilinks (mostly found in descriptions), like [[Belphegor's prime]] should be changed to [[:en:Belphegor's prime|Belphegor's prime]] during import so that they don't all turn into redlinks. Kaldari (talk) 04:52, 13 March 2019 (UTC)

Support.   — Jeff G. ツ 04:56, 13 March 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

"The 12 file versions you are currently trying to import exceed the file size limit the import can handle."

The situations where there's multiple versions and a decent size to them are pretty much the exact situations where having bot-assisted movement is most useful. It might be mildly annoying to move a single 75 KB image over. It's bloody awful to move 12 images of 36 megabytes each. The maximum move size needs pushed WAY up.

As to how this situation arose: Long story short, I was doing a difficult restoration while copyright status was being worked out on Commons. I uploaded partially-done files as I went. Consensus came down in favour of Commons hosting the file, as the only thing that would give doubt to the status (a partial attribution in an unreliable source to a name that does not appear to have any other known works discoverable, nor any reliable sources that even cover his or her existence) was deemed trumped by the very reliable source (the BnF) that said it was both anonymous and public domain.

Oh, there's also a PNG version of the file. 6 files in the history, 87 megabytes each. What IS the limit, anyway? Adam Cuerden (talk) 21:14, 19 March 2019 (UTC)

Can you please provide a link to the specific file you are trying to import?

The current limits are 100 revisions, and 250 megabytes. Thiemo Kreuz (WMDE) 10:28, 20 March 2019 (UTC)

Sure, it's https://en.wikipedia.org/wiki/File:Cavalleria_Rusticana_-_Santuzza_and_Turiddu_outside_the_church.jpg and https://en.wikipedia.org/wiki/File:Cavalleria_Rusticana_-_Santuzza_and_Turiddu_outside_the_church.png

I realise there will probably be secondary blocks in the license check - En-wiki does not have the most relevant license, and I'd like to keep a local copy there anyway, just in case it turns out the unreliable source was somehow both correct and that it makes any difference to status - but it's not too hard to work around that.

The commons discussion as to why it's fine for there is at https://commons.wikimedia.org/wiki/Commons:Village_pump/Copyright#Unidentified_artist

And the end licensing should be as in https://commons.wikimedia.org/wiki/File:Cavalleria_Rusticana_-_Alfio_and_Turiddu_embrace.jpg Adam Cuerden (talk) 09:49, 21 March 2019 (UTC)

Please add PD-Australia to the allowed list

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Currently images licensed as PD-Australia are rejected by the FileImporter but PD-Australia images are allowed on Commons. Kerry Raymond (talk) 01:44, 17 April 2019 (UTC)

Oppose, files with such tags on enwiki may still be subject to US copyright due to URAA and therefore are not automatically hostable on Commons. See also c:Commons:Village pump#"Export to Wikimedia Commons" from en.Wikipedia - licence problem.   — Jeff G. ツ 02:07, 17 April 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

OTRS

I'm not able to import files with OTRS tickets from Persian Wikipedia (fa:رده:کارهای تایید شده توسط OTRS). Hanooz (talk) 19:44, 24 April 2019 (UTC)

That's because you're not a global OTRS member. Yet. Please see m:OTRS/Volunteering.   — Jeff G. ツ 20:32, 24 April 2019 (UTC)

Thanks. Hanooz (talk) 10:00, 25 April 2019 (UTC)

You're welcome. I imported File:Raami-011.jpg, but I couldn't access the tickets of the rest.   — Jeff G. ツ 12:05, 25 April 2019 (UTC)

Thank you very much. I will ask on Persian WIkipedia for help. Hanooz (talk) 12:12, 25 April 2019 (UTC)

You're welcome.   — Jeff G. ツ 12:20, 25 April 2019 (UTC)

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! Tacsipacsi (talk) 21:50, 15 March 2020 (UTC)

ZWNJ and Whitespace not recognized in parameters

Tracked in Phabricator
Task T213955

At Extension:FileImporter/Data/fa.wikipedia#Transfer, I have defined "اجازه‌نامه" and "اجازه نامه" and "اجازه_نامه" as "Permission" when converting local template to Commons template. However, only the last definition works. The first one contains ZWNJ and the second one a whitespace.

Here is an example: fa:پرونده:Woman with pears.jpg 4nn1l2 (talk) 10:28, 26 April 2019 (UTC)

Thanks for reporting this extra example. Alternative source parameter names for the same target parameter name are currently not supported, see phab:T213955. You can keep the extra parameters on the config page. Just make sure the most important one is listed last. Thiemo Kreuz (WMDE) 11:25, 26 April 2019 (UTC)

Thanks, I created a phabricator-ticket for this, so that our developers can look into it: T221959

[Update: I Answered simultaneously to Thiemo… See his answer] Michael Schönitzer (WMDE) (talk) 11:28, 26 April 2019 (UTC)

Local opt-out

Tracked in Phabricator
Task T222445

Is there a way for a local project to opt out of FileImporter? Some wiki project(s) are too laxed on copyright fraud. I believe FileImporter should be turned off for these projects with or without a local consensus. Roy17 (talk) 12:05, 2 May 2019 (UTC)

I wonder under which circumstances the limitations encoded in the configuration pages at Extension:FileImporter/Data aren't enough to prevent unwanted uploads from happening? Can you please provide one or more specific examples of such problematic files? Thiemo Kreuz (WMDE) 13:20, 2 May 2019 (UTC)

It's not the problem of the config. Some wikis have very poor oversight of local files that copyvios are often tagged with free licences. I think such wikis should have FileImporter turned off.

As far as I know, on Commons, there is currently no tool to identify all files imported from a particular wiki. They are not put into a single category either. Roy17 (talk) 13:31, 2 May 2019 (UTC)

I would like to rephrase my question and ask you to provide more information that allow us to understand the issue better. It appears you are talking about one specific wiki. Which wiki is that? Can you please provide examples of files that have been imported to Commons, but shouldn't? It sounds like the issue are different community standards. It even sounds like the community you are referring to is willingly violating standards that exist on all Wikimedia wikis. Is this the case? If so, wouldn't be the Wikimedia Foundations legal team in charge?

Would it help if FileImporter sets a category to mark the source of an import? Thiemo Kreuz (WMDE) 14:03, 2 May 2019 (UTC)

@Thiemo Kreuz (WMDE): "FileImporter sets a category to mark the source of an import" would definitely help.   — Jeff G. ツ 16:34, 2 May 2019 (UTC)

The question remains, I'm afraid: help with what? Please provide all information you have to enable us to help. Thiemo Kreuz (WMDE) 07:03, 3 May 2019 (UTC)

@Thiemo Kreuz (WMDE): Help with copyright enforcement. Two projects that come to mind as potentially problematic with respect to copyrights are Arabic Wikipedia and Arabic Wikisource. We had a declined bot request for transferring files from those two projects to Commons early last year, which revealed the following quotes: "Different Wikipedias have different attitude toward copyrights and its enforcement." by EugeneZelenko; "Seems to be an overall lack of consensus on Arabian Wikipedia about the process for how this bot would work. One commented that they don't trust Commons because there files got deleted for no convincing reason, another mentioned copyright issues and perhaps images not being transferable due to licenses." by ~riley; and my "I have issues with whoever is selecting these files for transfer, and that person's attention to detail (or lack thereof)." 60% of the files selected as examples for transfer (which should have been the best ones) had copyright problems which made them unsuitable for Commons or any WMF project. Admittedly, five is a very small sample size, but 60% is a huge error rate.   — Jeff G. ツ 11:57, 3 May 2019 (UTC)

Thanks. I created phab:T222445 to help us keep track of this request. It would be great if you could provide specific examples here or in the ticket. Thiemo Kreuz (WMDE) 12:23, 3 May 2019 (UTC)

I think it's reasonable request. Other factor which should be taken in account is availability of active administrators on Commons who knows particular language well, better because communication mat lead to better local review before enabling transfer or just reduce misunderstandings between Commons and other projects. EugeneZelenko (talk) 12:40, 3 May 2019 (UTC)

Actually, to turn it off is pretty simple: remove/comment out all acceptable templates in the config, and protect the config. What is missing is a formal process. The best is of course if the local wiki has a consensus of disabling it, but in the event of no consensus, or if small wikis insist on enabling it but do nothing to tackle problematically licensed files, the larger Commons community should be allowed to initiate/impose an opt-out on such small wikis, since FileImporter involves both the local wikis and Commons. meta:Non-free_content is a not so up-to-date monitoring of local files.

On the other hand, a maintenance category akin to c:Category:Files moved to Commons requiring review by source would be very useful. Currently a line of the format <!--This file was moved here using FileImporter from //xxx.wikipedia.org/wiki/File:Example.jpg--> is automatically prepended for each import. We'll just need to append for example a line [[Category:Files moved from xxx.wikiproject to Commons requiring review]], or a remodeled c:Template:BotMoveToCommons. Roy17 (talk) 12:46, 3 May 2019 (UTC)

meta:Non-free_content/taking_stock#List_of_Wikipedias_having_local_media_files is the actual monitoring of files on each local wiki. It's not regularly updated. Roy17 (talk) 12:50, 3 May 2019 (UTC)

It's reasonable to have transfer disabled by default and enable it after formal review. Historically I could refer to bot-assisted transfer organized in Polish Wikipedia where several Commons administrators were actively involved. Russian Wikipedia changed attitude toward copyrights and started to review files scrupulously ~ 4th year of existence. EugeneZelenko (talk) 12:54, 3 May 2019 (UTC)

Some thoughts

• 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. Geagea (talk) 12:18, 22 July 2019 (UTC)

• 2) Any example for your claim? I know only a bug in the Commons mobile App phab:T232142 → User: Perhelion 12:26, 8 September 2019 (UTC)

phab:T232142 is not about FileImporter Geagea (talk) 18:03, 8 September 2019 (UTC)

Yes it is more general. You are right, as you described the problem more detailed on Commons. → User: Perhelion 07:26, 9 September 2019 (UTC)

I created example personal template for files I imported from he.wiki https://commons.wikimedia.org/wiki/File:Shlomo_lorentz.jpeg I think that this kind of template whan importing, would be useful. Geagea (talk) 09:31, 22 August 2019 (UTC)

• 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. Pikne 09:05, 10 September 2019 (UTC)

Curious about categories

Hi, I'm curious to learn more on the decision not to transfer categories. With Wikidata, matching most categories that exist both on source and destination wiki should be fairly simple. Is there any specific reason why you're reluctant to use this method? Strainu (talk) 22:12, 17 August 2019 (UTC)

Hi, thank you on the input! We decided not to do this for the first version, since it wasn't foreseeable how hard this would actually be to implement and we'd rather have FileImporter out of beta without that feature now, than with that feature in several moths. That doesn't mean the feature can't be added in a future version. There are lot's of things that could be done to make moving files even easier, but we have to also consider both: the resource effort needed to implement and maintain in the future and the benefit for the users. We always try to focus on the things for which this ratio is best. Michael Schönitzer (WMDE) (talk) 12:16, 27 August 2019 (UTC)

Some thoughts

Make it non-beta. ~ Calvinkulit (talk) 09:49, 18 August 2019 (UTC)

Looks like it is going to be a default feature in first wikis. See Help:Extension:FileImporter#Deployment_roadmap. 94rain ^Talk 10:39, 18 August 2019 (UTC)

It will soon go out of beta. Thanks for the feedback! Michael Schönitzer (WMDE) (talk) 15:54, 19 August 2019 (UTC)

When exactly? Calvinkulit (talk) 08:12, 20 August 2019 (UTC)

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. Michael Schönitzer (WMDE) (talk) 10:11, 20 August 2019 (UTC)

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)

Allow the extension to export files with supressed files/revisions

Tracked in Phabricator
Task T225588

I want this particular extension to import those files that have suppressed revisions/versions, so that it can absolutely replace CommonsHelper. Calvinkulit (talk) 05:10, 22 September 2019 (UTC)

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 Johanna Strodt (WMDE) (talk) 13:49, 6 November 2019 (UTC)

Has it been finished? This question is the reason why I reopened this topic. Calvinkulit (talk) 13:58, 6 November 2019 (UTC)

@Johanna Strodt (WMDE): Also, I hope that the development team finds a solution to this problem. Calvinkulit (talk) 14:01, 6 November 2019 (UTC)

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. Pikne 12:48, 25 March 2020 (UTC)

Automatically insert date for Now Commons?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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}}}} . Roy17 (talk) 09:10, 28 September 2019 (UTC)

@Roy17 Thanks for your comment! I have created a task for this, so we can keep it on our radar: https://phabricator.wikimedia.org/T237512

Best

Johanna Johanna Strodt (WMDE) (talk) 10:52, 6 November 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Deactivate on ptwikipedia

The portuguese Wikipedia only hosts non-free media under the restricted content exception (https://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Conte%C3%BAdo_restrito). It only uses free media that is already at Wikimedia Commons. GoEThe (talk) 11:13, 23 October 2019 (UTC)

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? Michael Schönitzer (WMDE) (talk) 14:16, 23 October 2019 (UTC)

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. GoEThe (talk) 09:48, 24 October 2019 (UTC)

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. Michael Schönitzer (WMDE) (talk) 11:49, 24 October 2019 (UTC)

Allow Template:Copyrighted free use images on enwiki to be exported to Commons

I've been trying to export copyrighted free use files to Commons, but it will not work. Calvinkulit (talk) 08:56, 10 November 2019 (UTC)

The configuration page mw:Extension:FileImporter/Data/en.wikipedia currently does not list the template en:Template:Copyrighted free use as one that would be allowed on Wikimedia Commons. Given Commons does have an identical license template, it might be allowed. But I'm not sure about this. I suggest to ask at commons:Commons:Village pump/Copyright. Thiemo Kreuz (WMDE) 08:34, 11 November 2019 (UTC)

License selector

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. Kees08 (talk) 04:04, 5 December 2019 (UTC)

Handle the "raw page scan" templete from English Wikisource

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)

@Peteforsyth: I copied the template to c:Template:Raw page scan and made an adjustment, please see the preliminary result at https://commons.wikimedia.org/w/index.php?title=File:Portland,_Oregon,_its_History_and_Builders_volume_1.djvu-389.png&oldid=379183981   — Jeff G. ツ 14:47, 7 December 2019 (UTC)

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

@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.   — Jeff G. ツ 13:44, 12 December 2019 (UTC)

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)