Help talk:Extension:FileImporter

Jump to navigation Jump to search

About this board

Central feedback page for FileImporter/FileExporter.

Move original file (instead of copy)

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

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

Local wikilinks should be adjusted during import

2
Summary by Thiemo Kreuz (WMDE)
Kaldari (talkcontribs)

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.

Jeff G. (talkcontribs)

Support.

Reply to "Local wikilinks should be adjusted during import"
Kaldari (talkcontribs)

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!

Reply to "Misuse of the tab metaphor"

Cross-wiki imports of Commons-incompatible media

5
Summary by Thiemo Kreuz (WMDE)
Manlleus (talkcontribs)

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

Thiemo Kreuz (WMDE) (talkcontribs)

What exactly do you have in mind when you say "another wiki edition"?

Manlleus (talkcontribs)

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)

Thiemo Kreuz (WMDE) (talkcontribs)

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.

Manlleus (talkcontribs)

Thanks, its just an idea, maybe a new extension cross-wiki to be added in the future. Good stuff

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

4
Summary by Johanna Strodt (WMDE)
Jarekt (talkcontribs)

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?

Johanna Strodt (WMDE) (talkcontribs)

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

Jarekt (talkcontribs)

Johanna thanks for you reply. Is there another way one can use to map multiple fields in the source template into one?

Johanna Strodt (WMDE) (talkcontribs)

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

Summary by Thiemo Kreuz (WMDE)
Z thomas (talkcontribs)

Während des Imports habe ich die Möglichkeit, unter anderem den Dateinamen und die Beschreibung anzupassen.

Sinnvoll wäre es, auch gleich Kategorien hinzufügen zu können

Johanna Strodt (WMDE) (talkcontribs)

Hallo @Z thomas! Kleiner Nachtrag: Diese Frage habe ich jetzt auch in den FAQ ergänzt.

Viele Grüße

Johanna

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

2
Summary by Thiemo Kreuz (WMDE)
Jeff G. (talkcontribs)

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.

Johanna Strodt (WMDE) (talkcontribs)

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

Summary by Johanna Strodt (WMDE)

Language tagging isn't working yet.

4nn1l2 (talkcontribs)
Johanna Strodt (WMDE) (talkcontribs)

@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

Attribution breaks in some cases, potentially violating licenses

5
Summary by Thiemo Kreuz (WMDE)
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.

Reply to "Attribution breaks in some cases, potentially violating licenses"

Option to delete original (or mark for deletion)

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

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)

Johanna Strodt (WMDE) (talkcontribs)

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

Best,

Johanna