Board Thread:Consensus Track/@comment-22479560-20131027141943/@comment-770155-20131030165248


 * 1) The overcomplicated example does not yield any redundancy, but the lesser complicated version where the base infobox shouldn't need any alterations does. When information would be copied into a subpage instead of moved.
 * 2) Weapons (Skyrim) is one of those pages that would exceed the limit. And those are the most important ones. I know they are already split up and transclude all different weapon types from their corresponding pages, but all nested transclusions count to the total limit when processing the Weapons-page.
 * 3) The Wikipedia example only covers the basics of translusion. It does not refer to any overhead transcluding does introduce since every bit of software performs different. In our case we have to deal with a webserver that runs the MediaWiki software. Everything is stored into different files the webserver has to look up and process. In the MediaWiki specific case, this introduces an awful amount of overhead. There is an admin-tool Wikia enabled on the biggest wikis they host, which calculates page loading times. We played around with transclusions in the past in some sandboxes, and those pages containing an awful lot of transclusions took 8 seconds on average for MediaWiki to process.
 * 4) DPL can read infoboxes. For example, we can make DPL create tables that list the 1st, 3rd and 4th entry in that infobox, for every infobox in a category. So our list-pages will be generated once by a DPL-script, and cached. The next time any user visits that page, MediaWiki will present that user with the cached page, instead of generating a new one (which would happen every single time with transclusions). Here is an example of a list page generated by DPL. Every entry in that table is read from infoboxes on the skill-specific pages.