Last modified: 2010-07-31 21:31:50 UTC
example templates: {{DELETION REQUEST}} (watermark should be perhaps a red copyright (C) symbol with a questionmark, indicating the image has uncertain copyright status) {{SUPERSEDED}} (watermark should be... perhaps a large grey cross) I guess you would make both the trigger template list and corresponding watermark images customisable. This would allow better communication of the image management process between admins and users. At the moment there is no way to see an image in use and instantly know that is being discouraged from use.
I think it would be technically simpler to place a notification in the HTML outside the image rather than to change the image itself.
That is true, Tim, but I believe the motivation for the request is the same as that of any other watermarking... to do something TO the image that makes it clear what the story of the image is itself, which cannot be easily removed. However, if there is a way to make the appearance of the image (on any page) show this information, that cannot be circumvented in wikimarkup, that doesn't require modifying the image itself, perhaps that's preferrable?
Just a note, on enwiki we've wanted something like this for a while so we could mark non-free images with a reader visible mark. It might make sense to do this local feature first. If the implementation resulted in something in HTML it would have the side effect of making it possible to suppress it with a preference or with user-css.. which some may like. One challenge is that if the mark is overlayed there is no one location which will not be really bad for some images. Instead the image size could be increased and the mark left outside the image, or the thumb could be decreased to make room for it.
A similar (broader) proposal was given out http://permalink.gmane.org/gmane.org.wikimedia.commons/1639 some weeks ago.
I proposed a generic system to implement some magic word on image pages that would cause a CSS class to be applied to the image in articles. Then it's just a matter of editing the global stylesheet/JavaScript to make images with scertain classes appear the way we want them to in articles (red borders overlayed watermarks, whatever). See Bug 8298 for details.
I am more in favor of Sherool's generic system, it could do everything in this proposal also, but in a more extensible way.
So, what we'll have is a column added to the image table called img_class (varchar(255)), and a magic word {{MEDIACLASS:css_classname_here}}, when this magic word ends up on an image page (either via a template or directly) the image table will be updated to set img_class to css_classname_here. XSS and other weird stuff will be prevented by some sanity checking on the classname. When a thumbnail is displayed we use the provided class name (taking it from the cache or the database if it is not in the cache). I don't think there would be any performance impact from this change and it should be easy to make it work across the commons/localwiki boundry. As a matter of policy we can define a standard naming convention for classes, but mediawiki doesn't need to know about the policy, it only provides the mechanism. If people are okay with this, I'll see that it gets coded.
Would a CSS class be sufficient? It would be difficult to impossible to have scaling watermarks, for instance; they'd have to be tiled. That's unless people toss in JS.
an alternative operation would be something like, at parse time the img_class column is built up additvely from multiple {{MEDIACLASS:}} statements. For example if an image page (and its templates) contained {{MEDIACLASS:nonfree}}... {{MEDIACLASS:commonsdelete}}... {{MEDIACLASS:nudity}} ... the resulting img_class column would be "img_nonfree_commonsdelete_nudity" and this value would be set on the images for local/user css/js to act on as it sees fit (it would have to iterate over all images checking their classes against patterns). This adds a little complexity to what was proposed above, and moves a little of the policy (all begin with img_) into mediawiki, but I think it would work better with the way that an image's description is build up additively from templates.
I don't know.. how much do we want to avoid JS for these applications? I think that JS is fine (and my last comment would pretty much require JS to do anything at all).
Yeah, maybe. It doesn't seem to me that concatenation is the way to go, incidentally. Classes are space-separated, so best to use that: just have class="nonfree commonsdelete nudity". I'd let different wikis establish their own conventions for the class names, too, not force any special prefix. (In particular, it seems likely that foreign-language wikis might want localized prefixes. Remember that any Unicode character except some reserved ASCII marks and maybe a few insane ones can appear in class names.)
I for one love the idea of a watermark the site could customize. I cater to the satellite industry, and have already been told by other site admin they want to steal my pictures.
Watermarks as discussed here would not affect the image source. The relevant images could still be downloaded easily, probably just by right-clicking and selecting "Save". The idea is certainly not to encourage possessiveness of images used on the wiki; for that you'll want to come up with an extension yourself.
Space separated class names sent from perhaps multiple instances of the magic word {{MEDIACLASS:foo}} on the image page (both directly and via transcluded templates) seems ideal. This way you may have multiple templates on the image page, with each individual template having the least required number of {{MEDIACLASS:}} mentions for its use, but from the article page you would get the informative benefit of all of them. This system would be exceptionally useful by the way.
Does this try to address the same issue as bug 8298 ?
I believe so, yes.
*** This bug has been marked as a duplicate of bug 8298 ***
