I have a few observations to make:
First, is it worth doing this with templates which can simultaneously handle formatting of {{flat}} and {{sharp}} as well as categorisation? It shouldn’t be too hard to use the convention of upper case letters for major, lower case for minor, and sharps and flats denoted by # and b. (Unless we also want to implement say German, French, Italian and Spanish usage for the sake of it. Hmm maybe not... ambiguity of German B-Dur = B
flat major!)
Second, there are obviously some pages where we will want to go outside the major/minor key signature paradigm, as works have been written up to the current day that are clearly in identifiable modes, rather than major and minor keys. If we can use case switching to implement the common keys, then the modes are just an extra set of cases. In particular, almost all works prior to the Baroque should be classified modally, and
not as being “major” or “minor”.
Third, works in expanded tonality with multiple key centres (or starting in one key, finishing in another) can surely be handled by multiple uses of the template? If you were considering a template where E major was handled by {{key|E}}, then a work like Mahler’s 5th would have a line in the general info field that looks like:
|Key={{key|c#}}—{{key|D}}
Any works pages with greater numbers of key signatures than two should probably have that information relegated to the Misc. Comments field.
I agree 31,650 work pages is an unappealing number, but that is no reason to not think about it. Would a bot be able to deal with most cases by doing a strict search on the |Key= variable in the general info field?
Also, there may be a fair proportion of pages that either don’t get or shouldn’t have keys assigned. Publications of collections of multiple works, perhaps.
Cheers, Philip
EDITED TO ADD: I’ve implemented the first half of this – there is now a template,
http://imslp.org/wiki/Template:K , which will display the appropriate key signature from the Bb/f# type shorthand. If we wish to categorise pages, then I propose making a second template {{Key}} which
in addition handles the categorisation (it would be inefficient for the {{K}} template to be called from within {{Key}}).