Although I think it's fairly simple to implement, there are many magic words that could be implemented with ease, but without a good use case it would just end up with a big mess.

Can you provide an example use case for this (fictitious is okay, but real one would be preferred)

I'd use it to enable 100% proper hotlinking use of my wiki images I created a feature to copy an image to a static destination where images are never renamed or deleted
As described in #27917 https://bugzilla.wikimedia.org/show_bug.cgi?id=27917

I'd like to add the tiemstamp of teh file revision (= upload date in the history table, not the last page edit date) to ensure that files are not overwritten.

Using {{REVISIONTIMESTAMP}} does work for this case since a file re-upload creates a new {{REVISIONTIMESTAMP}}. But it's not 100% correct when the page is edited after first upload and then copied to the static destination.

(In reply to comment #2)

I'd use it to enable 100% proper hotlinking use of my wiki images I created a
feature to copy an image to a static destination where images are never renamed
or deleted

This feature is not in the wiki itself, right ? Why do you need a {{FILEREVISIONTIMESTAMP}} in the wiki articles ?

Why do you even need a timestamp for that, and if you needed, how does knowing the timestamp of the latest revision in the wiki help that ?

As for hotlinking in general, see my comment in bug 27917.

(In reply to comment #3)

This feature is not in the wiki itself, right ? Why do you need a
{{FILEREVISIONTIMESTAMP}} in the wiki articles ?

I pass it as URL parameter to a script that copies files in a static destination.

Why do you even need a timestamp for that, and if you needed, how does knowing
the timestamp of the latest revision in the wiki help that ?

As for hotlinking in general, see my comment in bug 27917.

I add that timestamp URL parameter to the filename. If the file is re-uploaded it will create a new copy instead of overwriting the previously created one.

As said, {{REVISIONTIMESTAMP}} does that too but is not 100% correct.

I get that you add that to the filename, so you need the timestamp in your image-copy script.

Why do you need it on-wiki ?

The only page where that magic word would return that timestamp is on the file-page itself, and there the image is already shown anyway.

And for what it's worth, re-uploading should only rarely occur. In general different version of a work should be uploaded as seperate files. re-uploading is only needed (atleast on the wikis I use) to fix bugs, correct typos, etc. those kind of things. In other words: useful to not have the image link to the exact version and instead auto-correct.

Anyone else following the bug stream: What do you think about this magic word ?

The only page where that magic word would return that timestamp is on the

file-page itself, and there the image is already shown anyway.

That's exactly where it would be needed, yes.

re-uploading is only needed (atleast on the wikis I use) to fix bugs, correct typos, etc. those kind of things.

Sorry, I don't want to sound too harsh but this makes no sense. You don't seem to use images much. My images don't have bugs or typos. I won't discuss with you what re-uploading images is useful for. And what your wikis are used for is not the point here.

If the only use case is to do some fancy templating to work with some customization that one person did to their wiki, sounds like it should be implemented as an extension. If there is a more general use case for such a magicword that's not dependant on running some form of custom code, then it'd make more sense to implement in core. So as it stands, I think this is more suited to an extension.

I agree it may not be of general use tho. Somebody feel free to close this.

Ok. Closing as wontfix. If anyone does come up with a general use case, please feel free to re-open.