I would like this change is discussed on meta. before to see it implemented.

Does the community really want this, especially Wikimedia-wide?

brian.mcneil wrote:

From the point of view of Wikinews' requirements, this is a "kludge" that would address a problem we have:

Say Commons has [[File:Spread of Zombie Apocalypse.png]] and, country by country, people are developing a taste for brains.

If we publish an article [[n:Zombies reported in Paris]], including this file, then someone looking at that article should always see the version where France has just been coloured-in as infected.

If, later on, we publish [[n:New Zealand last Zombie-free nation]], then the file included there should be the more-current version leaving that as the only country not coloured in.

Unless there are far more-complex requirements that justify use of the External images parameter, I would suggest the appropriate solution is to have another parameter within [[File: ]] which accesses the version in-place on a specific date.

Thus: [[File:Spread of Zombie Apocalypse.png|date=2012-11-01|...]] could be used in one Wikinews article, and [[File:Spread of Zombie Apocalypse.png|date=2012-12-21|...]] in a later article.

That isn't really a bug, but a feature request - and seems far more logical than mucking about with the external images parameter.

rd232 wrote:

Yes, I had similar thoughts initially at http://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals/Archive/2012/08#Transcluding_old_file_versions, before I thought External Images could work as a quick alternative.

Note that date isn't a sufficient identifier for files. I don't know if date+time would work, or if it would need to be a file equivalent of a revisionID as we have for pages. But expanding the wikisyntax would certainly be more elegant, and solve the presentation problem with External Images (no control over presentation).

brian.mcneil wrote:

Revision ID is problematic in that I doubt it is particularly portable (think export and import to another wiki).

And yes, date may-well not be granular enough if you assume that it should be an exact revision you refer to. In that respect it should be possible to specify a date and time.

However, the behaviour of the software should be to present the version of the File: which was current at the date-time given, even if there is no version with an exact match for date-time. It should work by looking back through the revision history to identify which version was valid/current at that given point in time.

I'm glad you see this as a more elegant solution, it also has the benefit of abstracting away from the underlying data without a large processing hit. Those sort of approaches to problems generally last longer, make more sense to end-users and developers alike, and I'm sure Wikinews could wait for this if it's pencilled in as something which will be developed.

Currently, for old file versions MediaWiki actually use the timestamp (date+time) to identify a single version. This already led to problems (2 files uploaded under the same name at the same time).

Each file revision should have a unique ID and you should be able to find the file with this unique ID....

As an interim solution, one could allow using “archive”-versions by URL. But this markup is nothing, I like to see inside a Wikipedia Article, just for discussion, ...

(In reply to comment #1)

I would like this change is discussed on meta. before to see it implemented.

Still missing a discussion in order to proceed, plus an URL to it.

I thought the FlaggedRevs MediaWiki extension already covered Wikinews for historical images. I seem to remember it having the ability to do a "point in time" snapshot of pages, including templates and images. If FlaggedRevs is insufficient, that's probably a separate bug in the FlaggedRevs extension or its Wikinews configuration.

Regarding this bug, I'm very hesitant to see $wgAllowExternalImagesFrom used in this way, mostly as it seems like a kludge, and it'll sacrifice one of the saner parts of our home-grown image inclusion syntax: image usage tracking (both local and global [Wikimedia wiki-wide]). To me, that's a deal-breaker.

And, for what it's worth, as I recall, Commons and any other Wikimedia wiki can already do this locally. The whitelist at [[commons:MediaWiki:External image whitelist]] presumably works. I know it works on mediawiki.org (cf. [[mw:MediaWiki:External image whitelist]]). It's still not a great idea, though.

rd232 wrote:

"The whitelist at [[commons:MediaWiki:External image
whitelist]] presumably works. " - I presumed that too, but it doesn't. $wgAllowExternalImages and $wgEnableImageWhitelist both default to false and neither is set to true on Wikimedia.org. Hence this bug request, which seemed a safer way of opening that door than allowing the whitelist.

(In reply to comment #8)

"The whitelist at [[commons:MediaWiki:External image whitelist]] presumably
works." - I presumed that too, but it doesn't. $wgAllowExternalImages and
$wgEnableImageWhitelist both default to false and neither is set to true on
Wikimedia.org.

From https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=includes/DefaultSettings.php;hb=HEAD:

$wgEnableImageWhitelist = true;

The default setting is true. And it's not overridden by Wikimedia's configuration files.

Again, I don't think it's a good idea to use this whitelist, but it _is_ enabled on Wikimedia Commons and every other Wikimedia wiki. You're free to play around with it at [[testwiki:MediaWiki:External image whitelist]] (I've gone ahead and made you an admin there).

Adding myself to the cc, since any change to the default image whitelist would probably have to be mirrored in parsoid.