Camera categories: parse category and switch in mediawiki namespace


Author: test5555

Allow categorization based on "model" value in exif data in the following ways:

(1) Using "[[Category:Exif model: $1]]" as value for "MediaWiki:Exif-model-value"

This currently adds the category to the file description page, but the file doesn't get categorized in the category. If the file description page already contains an identical category, the category is displayed twice.

(2) Using the following value for "MediaWiki:Exif-model-value":


NIKON D200=[[Category:Taken with Nikon D200 (exif)]]
[[Category:Taken with $1 (exif)]]


Currently the switch function doesn't seem to work. Based on:
*the history of
(used from ),
it appears that this used to work.

(3) Possibly allow a combination of "exif-make-value" and "exif-model-value" to select the category.

Fixing at least (1) of the above would allow to generate categories for cameras automatically, see:
for manually made ones.

Version: 1.16.x
Severity: enhancement

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz21795.
bzimport created this task.Via LegacyDec 8 2009, 12:24 PM
IAlex added a comment.Via ConduitDec 9 2009, 9:24 PM

There're two problems:

  • first one (easily fixable): parameters are replaced after parsing magic words, this means the switch will always evaluate to the default case
  • second one (hard to fix, if this would ever been fixed one day): recording category membership and other links is done just after saving the new edit (in the same request) and not when rendering the page. Furthermore, this is only done for the content of the article (i.e. what you have in the text box) and not for system messages used arround it. If exif data where added to the wikitext before parsing the page, this mean we would need either to record all used exif messages as templates so that the links are updated each of these message changes (and I don't see a clean way to do it) or to invalidate all images pages each time a exif message changes (which would be very expensive).
bzimport added a comment.Via ConduitDec 10 2009, 9:10 AM

test5555 wrote:

I mentioned your comment at Commons:Village pump ([[Commons:Commons:Village_pump#How is camera type categorization done?]])

*for the first problem: yes, {{#switch:$1|$1=Result 1|asdf=Result 2|Result 3}} currently gives Result 1 for $1="asdf". One could restore the previous
behavior (Oct 2007) to provide pretty links to Wikipedia, but I don't think this is a priority.

bzimport added a comment.Via ConduitDec 10 2009, 9:12 AM

test5555 wrote:

*for the second problem:

The general idea is to evaluate exif data and create categories based on that.

It seems that this would need a step where exif data is evaluated when a file is uploaded/re-uploaded or an exif mediawiki namespace message is changed. This wouldn't necessarily be more expensive than any change to It is likely that people would edit it each time a new camera type is discovered (or a camera manufacturer changes its camera string).

a. One way to solve this could be to create a separate table with the exif data and make this searchable. Given the structure of exif data, this isn't necessarily that useful. An intermediate solution could be to parse some fields only into a table. A separate table wouldn't necessarily helpful unless we build an interface around it. Currently we can't make much use of MIME types (e.g. to identify SVG).

b. Another way could be based on the MediaWiki messages mentioned above.

c. A third way could be to create a special message in MediaWiki namespace (e.g. [[MediaWiki:Exif categories]]) that would be parsed on file upload/re-upload. It could contain variables for exif fields and switch functions to generate categories.

Gilles added a project: Multimedia.Via WebNov 24 2014, 3:38 PM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.