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).

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.

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 http://commons.wikimedia.org/wiki/Template:Information. 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.

(2) seems to be working fine now?

See https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Multimedia_and_Commons/Allow_category_in_EXIF_data

Maybe there should be a cirrus search task to expose this data as a search operator (?)