GuildWiki talk:Style and formatting/Skills

Suggestion: linking elite skills to builds
moved from Community Portal

While trying to figure out ways to better display and make accessible our builds collection, I've come up with the following suggestion: I think we should make an addition to the default skill template for elite skills (possibly even for all skills), called "Builds focusing on this skill" or similar, and under the headline, link in the builds in the that make use of the skill in question. This would showcase and make the good builds more easily accessible, make it easy to see if your idea for a build has already been done, and just plain be a practical reference for finding a build you know is here (but don't know the exact name). Thoughts? --Bishop (rap|con) 21:55, 10 May 2006 (CDT)


 * The way current template mechanics are, the section you want will appear above progression and acquisition. I do not believe it is the proper place for it.  It should be manually added towards the bottom of the article, if the linkign is to be done. -PanSola 23:13, 10 May 2006 (CDT)


 * Agreed. I wasn't suggesting, or even thinking of, anything automagic. --Bishop (rap|con) 00:11, 11 May 2006 (CDT)
 * To showcase, rather than explain, what I mean, I have taken the liberty of adding my idea to the IW article, as an example. --Bishop (rap|con) 00:34, 11 May 2006 (CDT)

Do not use include/templates for Skill Quick References

 * ''moved from User talk:PanSola

What are you trying to achieve, and wouldn't it be better to experiment on non-live pages? Hank 22:19, 11 May 2006 (CDT)
 * I thought I was done with experimenting. Then as I was pushing it live, I discovered I was wrong.  Now Ithink I'm done with experimenting again, so I'm pushing it live again.  -PanSola 22:21, 11 May 2006 (CDT)
 * Gah! Can you not explain what you're trying to do? Is this related to that subst issue above? If so there is a simple solution. . Hank 22:57, 11 May 2006 (CDT)
 * I'm keeping things dynamic, but using template instead. -PanSola 22:59, 11 May 2006 (CDT)
 * It is a terrible idea. Can I talk you out of it? You will kill the server with a page such as Mesmer Skills Quick Reference. Not to mention template pollution and confusion for editors. Please use subst. Hank 23:03, 11 May 2006 (CDT)

Like you said, template stuff are cached, so I don't see why it'll kill the server. SKill articles get edited often, but not the skill details that are being put into the templates. I think subst still defeats the entire motivation behind GuildWiki talk:Style and formatting/Skills/Archive 4. Namely, we need to remember to update multiple articles when a single skill changes. I see little benefit in re-subst compared to manually updating Mesmer Skills quick reference, Interrupt Spells Quick Reference, Mantra Quick Refernce, Signet Quick Refernce, Degen Skills Quick REference, or a sixth article whenever Anet changes skills between ladder seasons. -PanSola 23:08, 11 May 2006 (CDT)


 * I never said "template stuff are cached". That would be wrong in any case. I have considerable experience with the MediaWiki templating engine, so please let me examine the proposal again. There is no principal difference in recaching if the skill quick reference article includes or  . The costs are identical. Every time a page that has about a 150 templates or so is rendered, it will still query every single template at the database to see if it needs to rerender.   So you do not avoid any cost in separating a fixed portion of a skill article from a variable portion. MediaWiki templates are not robust enough for a page to have more than a couple dozen of them without consuming a terrible amount of memory. This is by design.. Hank 23:19, 11 May 2006 (CDT)
 * If the article Rush has been edited, but all the edits happen in the noinclude section, then is the render engine robust enough to not re-render it (when loading a page containing ?  It still makes a difference between 150 queries and not having to re-render, or 150 queries and HAVE to re-render because an artiticle got stubbed, or someone while editing a non-included part of the article, suddenly decide to adjust the whitespace in the included section to make the raw text in the edit box easier to read. -PanSola 23:26, 11 May 2006 (CDT)


 * No, it will force a recache of all pages that include a page whenever the text of the included page is changed. However, this is not the issue. Stripping noinclude sections takes nanoseconds. What is the bigger issue is that a page that includes 150 templates will cause O(150) database queries every time, even if the templates themselves have never been touched since the last render. The strain on the database is far greater than the computation required to rerender the page. Hank 23:27, 11 May 2006 (CDT)


 * Darn, and this is including features since MediaWiki 1.6, not just 1.5 and prior right? I would've thought if MediaWiki figured out how update link tables to deal with categories used inside templates, then this wouldn't be a problem. -PanSola 23:38, 11 May 2006 (CDT)


 * It is true of MediaWiki 1.7+ CVS as of last night. Like I said, by design. There have been no plans to "pre-cache" templates or any other suggested alternative because it was deemed long ago that it is worth paying the price of querying the DB for every used template. Hank 23:44, 11 May 2006 (CDT)


 * I guess it's no huge surprise the wiki is becoming so unbearably slow, then, with the recent template-craze (I'm not referring specifically to this, but the general use of templates everywhere)... of course, it's easy for me to be smug, I've never liked templates in the first place (beyond very limited use, anyway). --Bishop (rap|con) 23:39, 11 May 2006 (CDT)


 * BTW, the "recent template-craze" is about editing, changing, and updating templates. We aren't using templates in any articles we weren't using them before.  In fact there is a net number of reduction of templates being used, as teh armor and skill articles each used to use about 10~15 templates each, and now it's more like 3~4.

BTW, so when it checks whether a rerender is needed, does it do a diff, or does it look at timestamps of most recent modification? -PanSola 23:42, 11 May 2006 (CDT)


 * Timestamps mostly. The most accurate answer is that it first asks any of the object caches if the referenced template with the referenced parameters have been invalidated, and if any of them answers yes, then it queries the template article's timestamp to see if the invalidation was the result of a modification or because of other cache coherency conditions. But, generally when it gets to the second stage, it has already made two database queries (though to much more memcacheable tables than the full article itself). Hank 23:48, 11 May 2006 (CDT)


 * So if I compare a page that uses 150 templates (which take no parameter and only contain plain text), versus a page that has 150 links, does the number of queries differ? I presume queries are needed to decide whether links should be rendered as to the articles directly or to an edit page for new article creation. -PanSola 23:52, 11 May 2006 (CDT)


 * You are right that queries are needed to verify the existence of links, but the problem is far simpler, as databases are very efficient at answering existence queries. Also, it should be noted that existence queries are possibly the most cacheable queries possible. I should make one other point clear, because I am not sure if I conveyed it correctly. The O(150) queries are needed on a recache, but not on every visit of the page. Presumably the quick reference page has far more views than the skill articles change, so there is still some amortization. Hank 23:58, 11 May 2006 (CDT)
 * "The O(150) queries are needed on a recache, but not on every visit of the page" I definitely misunderstood you earlier. Another question: does use of embedded images generate the same type of quieries as use of templates?  And is MediaWiki smart enought to only send one query if a particular image is embedded 150 times in the same article? -PanSola 00:03, 12 May 2006 (CDT)


 * The MediaWiki rendering code does nothing clever about images, but the database layer in the MediaWiki code is clever enough to remember the result of asking if an image exists (and where its imagefile can be found) the first time the render layer makes the query. So the next 149 queries finish about a thousand times faster because no database queries are needed. Hank 00:11, 12 May 2006 (CDT)

Hmm, back to an earlier point, because the O(150) renders only happen on a recache, which only happens when the included article/template is modified, and becasue we only expect the skill details part to be modified between ladder seasons, I feel the usage of the templates will only cause a relatively insignificant amount of server drain (note this is different from including the full skill article, which gets edited OFTEN and produces big server stress). Comparing it to the benefits of keeping information centralized, I am still supportive of using the templates. IF I am proven to be wrong and it does have a non-negeligable impact on the server, we can always (and easily) subst them at that point. This is my opinion after considering all the evidence presented above. -PanSola 00:27, 12 May 2006 (CDT)


 * Recaches are not triggered only by changes. Any number of things can trigger it. For instance, the there may simply be too many entries in the object cache, in which case some entries are expired using a LRU algorithm. Also all cached objects have a forced hard expiry time after which a rerender is forced no matter what. Also some pages are simply uncacheable for various convoluted reasons and I have to read the cache code again to convince myself that the quick reference pages are cacheable. I still think that if you want a centralized location, then the difference between and  > is minor. Hank 00:34, 12 May 2006 (CDT)


 * By the way, if you want to persist with your plan, I would suggest making "subpages", ie., Rush/Skillbox, instead of polluting the Template namespace. Hank 00:38, 12 May 2006 (CDT)
 * I consider the difference to be major if we have to redo the subst. Or more precisely, if we have to remember to do the subst on other articles.  I didn't realize sub-pages take parameters.  I thought only articles with colons in their names do.  Why is the way I use the template namespace considered as "pollution" btw.  That concept is relative foreign to me. -PanSola 00:42, 12 May 2006 (CDT)


 * There is nothing special about pages in the Template: namespace except that Template: is the default namespace for transclusion, just like     is the default namespace for normal articles, etc. All transclusions can take arguments. It would be rather hard to test out templates in user subpages if they didn't. About pollution -- wouldn't you prefer all pages about the "Rush" skill to be named "Rush/somethingorother" rather than half being "Rush", half "Template:Rush", and the remaining half in some other place? I would. Plus, I was browsing the Special:Allpages in the template namespace earlier to see what sorts of templates you guys use, and I would hate to wade through 500 templates with no real purpose. Hank 00:45, 12 May 2006 (CDT)


 * Another reason for subpages just occured to me. Talk:Rush/Skillbox would naturally be a real subpage of Talk:Rush then. Hank 00:48, 12 May 2006 (CDT)


 * Hmm, the overall GuildWiki practice has a trend to make transclusion be as easy (ie short) as possible, as evidenced by Template:Monk, Template:G, and so on. As a 6-month GuildWiki user and not familiar with other major wikis, I'm not particularly bothered by the fact that some info of Rush is in Template:Rush, especially when that info is accessible and has an edit link to it from the Rush page (and any page that transcludes Template:Rush.  We are trying to categorize all our templates via Category:Templates instead of using Allpages, since similar templates won't get grouped together anyways.  Besides, if something is a template (I consider Template:Rush to be a template, not just a subpage, but our views obviously differ), it makes the most sense to put it in the template namespace.  It's a template that takes parameters and controls how information about Rush is displayed in other articles.  Anyways, I'm going to leave this entire issue just hang here for half a day or so, so others can voice their opinions. -PanSola 00:54, 12 May 2006 (CDT)


 * What is hard about including a "subpage"? Just add to every article. This is so systematic that it can be templated into  to be added at the top of every skill article. The quick reference pages will presumably be created by clueful people who will know to include  . A half day's cooldown is good. Hank 01:00, 12 May 2006 (CDT)


 * I'm late to the discussion, but I think Karlos would be furious about some info being in Rush and some being in Template:Rush. I wouldn't be furious but I agree with his issue on redundant data.  --68.142.14.79 05:24, 13 May 2006 (CDT)


 * The proposal is to have some info about Rush in Template:Rush, some different info about Rush in Rush, which includes Template:Rush. This is called splitting the data as opposed to having redundent data.  Redundant data is the alternative: All info about Rush in Rush, half of the same info about Rush is in Warrior Skill Quick Reference, and also in whatever other quick reference articles or build articles that want to include Rush's information.   The third alternative to avoid Split Data or Redundant Data, is to have a very very over-worked server. -PanSola 05:46, 13 May 2006 (CDT)

Looks like this subject isn't something most ppl keep an eye on. I'll continue ahead with the project. -PanSola 01:06, 13 May 2006 (CDT)


 * Subpage or include only it or something&mdash;polluting the template namespace is a BAD idea! Hank is right on the money here. If I knew anything about this "subst" thing you keep bringing up, I'd argue about that too. :) &mdash;Tanaric 21:12, 13 May 2006 (CDT)


 * Okay, after rereading this, I see I was mistaken before about what you were doing. But now I'm unclear on how the new templates either simplify editing or decrease server load.  The QR pages will still include the same number of templates as far as I can tell.  QR would include, which ends up using  versus QR including  which through includeonly/noinclude would use .  Is the change just to reduce the number of lines in the skill articles that the unknowledgeable shouldn't touch?  --68.142.14.79 22:06, 13 May 2006 (CDT)
 * Compare to the original plan of including skill articles directly in quick reference pages, the use of the templates do decrease server load. The reason is, in the original plan, whenever someone edit the article Mantra of Recovery, perhaps to correct a spelling on a usage note, perhaps having a revert war on the edit note, or whatever;  whenever someone edit that article, all other articles that include Mantra of Recovery (various quick reference pages) would have to rerender their own cache.  The plan of using the template reduces server load because re-render would only be needed if someone edit the actual skill details of Template:Mantra of Recovery, as opposed to if someone edit the skill article directly. -PanSola 22:19, 13 May 2006 (CDT)
 * Hank said that (he thinks) "the difference between and  > is minor."  --68.142.14.79 22:35, 13 May 2006 (CDT)

The "Plan"
So here's what my planned template will feature (not all features implemented):

1. When in the quick reference view, the ability to hide or override the profession/attribute column, the stats symbols, the description, the skill type, and/or the campaign. This will be done by providing parameters to whatever is being included (be it a template or a subpage).

Example syntax: (the "row" is used to trigger the special quick reference view.

Usually just including Backfire will cause it to display everything. But if you set any of the fields to "hide", the entire column will be hidden. Even the icon can be overridden or hidden.

2. Ability to add custom notes. This can be done by either overriding existing fields (say I want the column that used to display attribute to change to % speed increase for a speed article), or by adding a "notes" parameter.

Except the custom notes functionality, everything else have been implemented.