GuildWiki talk:Style and formatting/Skills

Addition of blank template
I added a blank basic template under the example one. Would it be better to change their order (that is, provide the blank and then the prefilled as an example) or is it better as is? Or should I do away with it altogether? --HopefulNebula 02:45, 5 June 2006 (CDT)

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)

No comments on this for over a week. If there are no objections, I'm going to start implementing this soon. --Bishop (rap|con) 09:52, 19 May 2006 (CDT)
 * Exactly why would this need to be done? I do not think the builds need to be more accessable, it will be alot of data to update if a build was updated/removed than just the build page. I would rather not see such variable and technically opinionated information be added to the skill pages which should be entirely concrete fact. --Draygo Korvan 10:13, 19 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)
 * I believe he said it under a different context. Specifically, he said it in the context of having data being centralized.  I believe he wasn't talking abut different in teh sense of server load. -PanSola
 * Before that sentence, he was discussing MediaWiki's caching, so I don't think so. --68.142.14.78 00:37, 15 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.

Factions Skill Icons
Some of you may have noticed I uploaded a clean good looking skill icon for Bull's Charge, Resurrection Signet, and Signet of Capture. Thats because I found them, and all the factions skills, at 50x50 on the Guild Wars Japan site. Because those were all core/prophocies skills I figured I should take advantage of that and resize/add border to them and upload them so we have good looking versions. However, I'm not sure what to do about the factions ones. I could easily take all the factions icons and resize/add border to them and upload them but do we want to instead wait for the fansite kit to come out first? The icons already formatted to 64x64 from the fansite kit would look much better and it looks like it might be out soon seeing as they are already using the icons for those skills. (T/C) 23:26, 14 May 2006 (CDT)
 * We have no clue when the fansite kit will be updated, as a point of information. -PanSola 00:28, 15 May 2006 (CDT)

Discussion with major implications
Not sure if anyone would be paying attention here but not GuildWiki talk:Community Portal. Anyways, there's a discussion over there about how data used in multiple places is to be handled. Just follow this link: GuildWiki talk:Community Portal. -PanSola 05:58, 16 May 2006 (CDT)

Elite Skills categorized
When an elite skill is categorized in any category page other than Category:Elite skills, it should be added with the keytag (Elite) this will make it easier for people to spot elite skills from regular skills eg: Illusionary Weaponry (Elite skill)  --Jamie 04:01, 4 June 2006 (CDT)


 * I don't understand what you are talkinga bout... - 04:45, 8 June 2006 (CDT)

Vote: Format of Fractional activation time for Skills
I apologise if this has been finally settled before, but I am unable to find a decision about this within the WiKi (and especially within the Archives of this very talk page).

What's all this about? There's skills like e.g. Blessed Light that have a fractional activation time like three quarters of a second that can be written in different formats:

1 (aka: plain text)
1/4, 1/2, 3/4
 * 1/4, 1/2, 3/4

2 (aka: htmlchar)
&amp;#188;, &amp;#189;, &amp;#190;
 * &#188;, &#189;, &#190;

3 (aka: htmlcode)
1/4 1/2 3/4
 * 1/4 1/2 3/4

4 (aka: latex)
, ,
 * [[Image:Frac_1_4.png]], [[Image:Frac_1_2.png]], [[Image:Frac_3_4.png]]

Note: GuildWiki does not currently use the latex plugin to support variant 4, so I just uploaded the corresponding images created on wikipedia.

5 (template)
1⁄4, 1⁄2, 3⁄4
 * 1⁄4, 1⁄2, 3⁄4

Pros and Cons
Variant 1 (plain text)
 * Pro
 * simple
 * readable in any browser


 * Con
 * harder to recognize as a fraction

Variant 2 (htmlchar)
 * Pro
 * conforms to html standard
 * easy to recognize as a fraction


 * Con
 * very small and hardly readable

Variant 3 (htmlcode)
 * Pro
 * easy to recognize as a fraction
 * good readable


 * Con
 * not the standard html representation
 * considered ugly

Variant 4 (latex)
 * Pro
 * easy to recognize as a fraction
 * good readable


 * Con
 * requires latex plugin or images
 * huge as compared to the others and the non-fractional numbers

Variant 5 (template)
 * Pro
 * conforms to html standard
 * easy to recognize as a fraction
 * easy to input without memorization of fancy stuff


 * Con
 * very small and hardly readable

Vote

 * Please submit your vote for one of the above variants or add another variant I didn't yet think about

This vote is open until 7 July 2006

Variant 1 (plain text)

Variant 2 (htmlchar)
 * --Bishop (rap|con) 04:36, 8 June 2006 (CDT) Standards, standards, standards!

Variant 3 (htmlcode)
 * Chi Li [[Image:Chi_Li.gif|Chi Li]] 04:21, 8 June 2006 (CDT) For me it's most important to have a readable format (seen in current mainstream browsers like Firefox, Opera, IE, ...). Please don't bring up the "Lynx doesn't display that" argument again, I just don't believe you are usually browsing this wiki with lynx.
 * &mdash; Skuld Easiest to read, most compatable (I wouldn't be against #2 if it had an inflated text size, &#188; for example)

Variant 4 (latex)

Variant 5 (template)
 * (best of both worlds)

P.S.
Please don't feel offended by me using my preferred variant while moving skill pages to the new template. As stated on my talk page I volunteer to change every skill template to the standard format once a decision is reached. --Chi Li 04:21, 8 June 2006 (CDT)

Discussion
As I see it, there have been various attempts to standardize this tiny aspec ot the Skill description, but none of them led to a final decision. In the recent past the discussion about this fractions was brought up again on various talk pages, including Chrono traveller (talk) and Chi Li (talk).

On the existing skill pages and skill templates the variants 1, 2 and 3 are used, so in fact no standardization has taken place yet. The Example Skill currently uses variant 2, but that's IMHO just a result of an unfinished discussion from the past.

I'll try to summarize the pros and cons for each variant (these are initially based on my opinion, so please add your own pros and cons): - Chi Li

Previous discussions on this issue: - 04:35, 8 June 2006 (CDT)
 * GuildWiki talk:Style and formatting/Skills/Archive 2
 * GuildWiki_talk:Style_and_formatting/Skills/Archive_5


 * Variant 3 will look like ^1/[4] on text browsers, so I reject that option. If variant 2 gets passed, I'm just going to ignore it, type "1/4", and let other people clean up after me, because there is no way I am going to memorize the htmlcharr code.  This is a wiki for the love of Cunningham.  Variant 4 is currently not pratical, so is a moot option. - 04:53, 8 June 2006 (CDT)
 * That totally works for me. 2 is the correct one to use, imho, but if you feel like using 1 instead, that's fine because content over presentation. --Bishop (rap|con) 04:58, 8 June 2006 (CDT)
 * Correct with respect to what? Half the point of wiki is to avoid html code.  Kinda ironic to be using something that is being labeled as "htmlcharr" (unless that's just a random misnomer invented by Chi Li).  Granted, I'm guilty of using lots of fancy formatting and templating to enhance presentation, but I pay extra attention to make sure those fancy stuff are hidden away from the average contributor, so all they need to do is filling out a template without needing to know how the fancy formatting/character stuff works (separation of content from presentation).  I'm fine with variant 2 and content over presentation (as long as ppl clean up after me), but I challenge it being "the correct one to use". - 05:20, 8 June 2006 (CDT)


 * Just curious (and hoping for an honest answer): Are you (or anyone you know) really browsing this wiki with a text browser? --Chi Li [[Image:Chi_Li.gif|Chi Li]] 05:06, 8 June 2006 (CDT)


 * Ask LordBiro. He's the major advocate for it back when we were re-designing the skill box templates. - 05:15, 8 June 2006 (CDT)