Last modified: 2014-11-17 09:48:23 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 7866 - Allow downloading multiple image files in a compressed archive
Allow downloading multiple image files in a compressed archive
Status: NEW
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
All All
: Low enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2006-11-10 23:50 UTC by Yug
Modified: 2014-11-17 09:48 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Yug 2006-11-10 23:50:57 UTC
Currently, in a page, category, or gallery, all pics show a link to its commons'
page such as 
* =>
And that's only when in this page, that, finding a link such as 
* ,
the user can download one-by-one the true media file.
In the category page, "right-clic + download all images linked" doesn't work

I think commons need to have a tool to enable users to download all the media
files of a page or category just by one clic. At least on commons, in the
Toolbox. Or on .
I really think that we need a way to download quickly all the files of one page
or category. I mean the true file, not the 100px preview visible in the

That may be usefull to share media of all categories with hundreds of files, such :
* Category:Chinese stroke order in BW pictures  (~1.200 files)
* Category:Coats_of_arms 
** and its subcategories
*** And sub-subCategory such as Category:SVG coats of arms - France (300 files)

As said pfctdayelise : "[that may be interesting to find a solution to download
serie of media, since] this it gets asked quite often..." pfctdayelise (说什么?)
05:35, 3 October 2006 (UTC)

Platonides then said on the village pump : "I could make such program (i already
did one to list the images on a category) but should better ask brion or Tim
about a proper delay." 19:35, 3 October 2006 (UTC)

A solution is need.
Comment 1 Daniel Kinzler 2006-11-11 13:27:18 UTC
While such a feature sounds quite nice to have, it poses several problems:

* It would be a violation of CC and GFDL to offer such an archive without
including information about license, creator, uploader, history, etc. Basically,
the image description pages would have to be packet along with the files.

* Compression does not work well on bitmap files like png/jpeg/gif (because they
are already compressed). It would be a huge waste of cpu cycles to try. Perhaps
a non-compression format like tar could be used, or such files could be stored
in the zip-archive with no compression.

* Creating such an archive takes quite a bit of resources, and may take to long
to be done "live" in an HTTP request. It would probably be a good way to
implement some type of throtteling and/or caching; Perhaps it would be best to
do this  as an "asynchronous" service: registered users could request an archive
and would receive an email with a download link when it is done.

* Traversing subcategories recursively may have unintended effects - one
erronous categorization could cause several thousand files to be included, even
though they are not really wanted. It may be a good idea to show all categories
that would be included, along with a total number of files and a total
uncompressed size to the user to confirm - but that may already be too expensive
to compute "live". But there must also be a hard limit - someone *will* try to
download *everything* - for a large wikipedia or commons, several terrabytes, if
I recall correctly. 

So, the request is reasonable, but not trivial to implement.
Comment 2 Yug 2006-11-11 15:49:31 UTC
Enable this function at least for administrator seem good.

Copyright : a table with [ License | Uploader | ImageName ] seem to be need.
Comment 3 Yug 2006-11-11 16:13:30 UTC
An Idea : [ ImageName | License | Uploader ] can be merge in a new dowloaded
file name, such as :
* On commons : [ Image:France_map.png | CC-sa-fr | Uploaded by Piom ]
* downloaded on you computer : France_map-CC-sa-fr-Piom.png
Problem, I really have no idea how do such thing.
Comment 4 Yug 2008-01-12 20:55:38 UTC
what about this request ?
Comment 5 Yug 2008-02-02 14:47:32 UTC
Commons really need this functions, at least for admin, otherwise categories such or , where users have involve so much energy to accumulate this images, are IMPOSSIBLE to download, and so totally useless.
Comment 6 Bryan Tong Minh 2008-02-03 19:16:32 UTC
Since this requires extracting data to obtain author and license information, it is more a task for the toolserver.

Another possibility is to add all revisions of the image description page to the archive, and have a static set of files added to the image (licenses).
Comment 7 Nemo 2012-11-03 09:46:38 UTC
Raising priority, this is a very requested feature which prompted the creation of the partial workaround (linked from Commons default sidebar).
Comment 8 Bawolff (Brian Wolff) 2014-05-22 17:57:54 UTC
(In reply to Nemo from comment #7)
> Raising priority, this is a very requested feature which prompted the
> creation of the partial workaround
> (linked from Commons
> default sidebar).

Sorry, but I'm going to re-lower this to low priority. Well it would be cool, it would be quite complicated to implement, both technically (Some categories have over a TB worth of images in them...), and socially with regards to license compliance. At the same time this hardly seems like a critical feature to commons

Note You need to log in before you can comment on or make changes to this bug.