Handling the Golems[]
With 30 versions of the same minion, Jade Golem presents a new question for the wiki and our systems.
The simplest solution is to follow the game data itself, and simply have 30 different minions, ranging from 1/1 to 30/30. This represents the Jade Golem as 30 different cards, albeit with an identical name. This is accurate, but could cause problems. For a start, the Mogu card list is swamped with Golems, as is the uncollectible minion list, and the artist responsible gets credited for 30 different cards (when they're actually responsible for 1, or arguably 4 pieces of art). If we list Jade Golem as a Jade Lotus card instead of as a neutral card (which is arguably accurate) it will clutter the hell out of the Druid, Rogue and Shaman pages; at present we don't, but that means the Jade Golem is missing from those lists.
The other approach is to represent Jade Golem as a single card, albeit with different versions. This approach has the benefit of not cluttering up tables, although it slightly under-credits the artist responsible for only 1 card, something which contradicts our normal approach with Normal/Heroic/Tavern Brawl versions of cards. It also breaks the usual rules of accounting for every card, and feels a bit off.
I've already made a work-around for the worst consequences of the first solution: this page. By default, any time we want to list minions summoned by Jade Idol or Aya Blackpaw we would have to list all 30 versions of the Jade Golem, which would be unworkable. Likewise the Mean Streets of Gadgetzan page would be even longer and we really don't need a (non-hidden) visual list of all 30 cards on any non-technical page. Therefore this dummy page functions to represent all versions of the card. However, if we take the first solution it is necessary to isolate this from the general card pool, so we don't have 31 different Jade Golem cards. And if we do this, it makes it impossible to include Jade Golem in automatic card lists without including all 30 versions.
It's a tricky situation. The first solution is easier and logically more natural, and is the current arrangement (for the most part), but has some downsides, namely the excesses on and absences from our various lists. If we get more cards like this in the future, lists could get a bit distorted.
I don't have any great solutions to suggest, but I'm interested in opinions and suggestions. -- Taohinton (talk) 00:22, 3 December 2016 (UTC)