GuildWiki talk:Style and formatting

This page is 62 kilobytes long
That is worth breaking into TWO archives o_O"""

Can someone who is more familiar with Style and formatting do the archving? Moving any concluded decisions to the "project page"? -PanSola 18:30, 11 January 2006 (UTC)


 * Done. &mdash; Stabber 22:16, 14 March 2006 (CST)
 * I was expecting you to arcive this too d-: -PanSola 22:17, 14 March 2006 (CST)

Categories: General Discussion
I put the boss category crusade on hold for a bit because I realized that I opened a can of worms. Before I continue, I'd like to have a general, basic discussion about the use of categories on GuildWiki.

So far, the way we handle categories requires relatively low maintainance: For example an NPC goes into Category:NPCs, if its a Warrior it goes into Category:Warriors, if it's a human it goes into Category:Humans, and so on. That's very simple, easy and quick, but this way we end up with categories that contain hundreds of entries. And these categories will grow rapidly as new campaigns are released. What is a plain alphabetic list of several hundred bosses good for? IMVHO: NOTHING!!! It helps nobody, with nothing.

All the lists on GuildWiki that are really useful have to be maintained manually. I'd rather see us put a little more work into categories to change them in such a way that they actually become USEFUL.

I'm thinking ahead here, towards Factions and further. Guild Wars Nightfall is already on the horizon, and due for release by the end of this year. A lot of work coming towards us. I think if we'd use categories a littel smarter they could be very helpful to compile lists. This way we can be faster and better than any other GW fansite out there.

Think about it yourself for a bit: What are the lists that most people are looking for on GuildWiki, and how would we have to modify categories in order to help us with these lists?

If a majority of people agrees that our current categories are not very helpful, I'll make a few suggestions how to improve them. I've got plenty of ideas. And I'm willing to do work, i.e. to do category crusades. But I'd rather do it right the first time. -- 00:28, 11 March 2006 (CST)


 * I do not agree. I find our category system very helpful. If I am browsing monsters in an area, the category system works fine for me. It's just the nature of the information that some of it isnot as highly coveted as other information. For example, if I meet a tough Mursaat ele boss, and I have trouble beating him, I will come to the wiki to see what his skills are and also look for helpful needs. I will most likely type in his name, or go to the area page and find his name in the bosses section. Now, I have never (to date) ever click to see: "Pray tell, what other elementalists are out there." That categorization, though logical, is not one I have ever found useful. I have found use for grouping the bosses. And subdividing it into species was a good thing.
 * Now, I would ask that you first propose the changes you want to make. You have held back Stabber from categorizing skills, but have not put in the alternative. Likewise, here, you say: If you're not pleased with the present category say: "Aye" but what are we saying Aye to? --Karlos 02:53, 14 March 2006 (CST)


 * My $0.02 - I've actually been contacted in game by a lot of people with comments/questions/complaints about the wiki. I don't mind it at all as long as they're civil (and all but one has been, that one person simply went on my ignore list when they refused to calm down).  More than a few complaints have been about the categories, but surprisingly people seem to complain when we change them so that they have to delve further into the tree.  For example, I got one complaint over the weekend about the new bosses stuff, this person preferred the main boss category and didn't like having to figure out what species they were and then clicking on that category.  I've also recieved complaints about the splitting up of the Collectable Drops into the different types of drops, seems some people don't like that either (this happened a while ago I know, but it is a similar situation).  So from my experience, people want less categories with more stuff in them.
 * My personal thought is that if a category has less than 200 things in it (which seems to be when the category splits to multiple pages), then there is no reason to split that category. --Rainith 03:15, 14 March 2006 (CST)

My proposal is to have all core skills in Category:Core skills, all Prophecies Campaign skills in Category:Prophecies Campaign skills, and all Factions skills in Category:Factions Campaign skills. At least Rainith has indicated support for this scheme (or, at least, lack of opposition). Do you have any objections to it, and if so, can you lay out a more perspicuous category tree? If not, I will proceed with this categorization. TIA. &mdash; Stabber 18:59, 14 March 2006 (CST)


 * Personally I think categories with several hundred entries are pretty much to useless. I especially hate the fact that, if there are more than 200 entries in a category, MediaWiki will not only split the category entries, but also the subcategories. This means you can not see all subcategories on page 1, which is most confusing and missleading. However, if there are people who find such categories useful, there is an easy workaround: Add a sub-category Category:All . For example, have a look at what I've done with Category:Add Weapon Upgrades. I sorted the subcategories by various criteria, but I also created a subcategory Category:Weapon Upgrades. This is where I dumped ALL weapon upgrades into, regardless of their type. Basically, this subcategory has the state of the original category before I started sorting it.
 * To sum up with few words what I have in mind on the whole matter of categories is not easy. I have plenty of ideas for creatures, items, quests, skills, etc. Most of the ideas involve the use of templates to automate categories.
 * To give you an idea what I'd consider intelligent use of categories in such a way that it will help us to maintain lists I've created a test template (Template:Skills). Have a look at it and comment.
 * There are only two things I'm not sure about:
 * This test template alone, if used throughout the wiki, would create thousands of new categories! Is MediaWiki able to cope with this?
 * I have not found a good workaround of the "plural problem". Since we have agreed that all category names shall be in plural templates would have to be able to automatically generate the plural of a PAGENAME or a template variable. That isn't possible right now.
 * I'll start writing down all my thoughts and plans for categories and will dump them into User:Tetris L/Categories. -- 19:28, 14 March 2006 (CST)


 * I'm sorry to say this, but if every skill page is going to become an instantiated template, then guildwiki will have taken a sharp turn in the direction of the arcane. Template soup is something I wish we had less of &mdash; it runs completely counter to the Zen of Wiki. I will wait to read your full proposal before expanding on this comment. In the interim, Category:Core skills is incomplete. If the design of GuildWiki Categories 2.0 is going to take a while longer, it might simply be better to uncategorize things from Category:Core skills and nuke the category. &mdash; Stabber 19:51, 14 March 2006 (CST)


 * I can not deny that it's true that the use of templates makes GuildWiki a lot more complicated, and less newbie-friendly. Some time ago Karlos warned about the dangers of this development here, and off course has had a strong point. But: I think it is possible to created templates in such an intuitive way that even a newbie will be able to grasp quickly how to use them. How do most people learn wiki markup? They look at other articles, copy code and modify it. And for newbies who have difficulties, there's always the experienced contributors to step in and fix the code, just like we wikify raw articles now.
 * Using templates makes life more difficult for beginners, but a lot easier for the experienced people. And ... face it ... 90% of the work on this wiki is done by the latter group. I'm afraight if we do not expand the use of templates on this wiki, sooner or later we will loose overview. With every campaign released categories and lists will grow, and sooner or later most of them will break through the 200 entry barrier.
 * I think GuildWiki should make the move now, before Factions comes out. Right now we have only one campaign to fix, and if we make the right decisions now, life will be much easier for Factions and all future campaigns.
 * As for Category:Core skills, I would only suggest to split it into subcategories by profession, e.g. Orison of Healing should not be in Category:Core skills, but instead be in Category:Monk Core skills, which would be a subcategory of Category:Core skills by profession and Category:Monk skills by campaign. -- 20:17, 14 March 2006 (CST)


 * All right. I am fine with your suggested categorization. I will categorize the remaining skills in this fashion presently. &mdash; Stabber 20:23, 14 March 2006 (CST)


 * As you have no doubt noticed already, I have done this for ranger and monk core skills. Any objections regarding this categorization must be brought up now. I will hold off on the rest until there has been some time for discussion. &mdash; Stabber 21:44, 14 March 2006 (CST)


 * I am horrified, mortified even, petrified by what I am reading! The little Molenin in me is about to squeal! :) I'll wait and let you formulate a proposition first. I feel we're once again re-opening issues (as if we're done with the gazillion things we want to do), instead of building on what we agreed upon, we are re-hashing things over and over. I feel this will be the biggest detriment to our ability to get ready for Ch2. When it comes out and people re-propose a new skill-box and a re-propose a mission layout and so forth. The OCD freak in me is screaming in agony. I fell most of these re-hashes are by people who simply did not attend the first discussion and thus we keep re-discussing the wheel. But, no more whining. Prehaps your propostion will bring about our salvation.. The Molenin in me hopes you are Molachev, not Krak Flamewhip! :)
 * For now, consider this: In the template you proposed, you are using Categories instead of hyper links which I believe is a poor use of a wiki. To say "See Category:Skill X Quests" instead of "See quest 1, 2 and 3" is to basically drop the braket format . You are practically writing a script to generate the page. Something I am quantitatively and qualitatively against. Molenin be damned! :( --Karlos 20:48, 14 March 2006 (CST)
 * For each case you feel we are rediscussing things, if you can point us to the previous discussion, that would help a lot. Sometimes it's not that we didn't attend the first discussion, but we weren't even onboard yet when the first discussion took place.  Subtle difference.-PanSola 21:06, 14 March 2006 (CST)
 * And I see it much less of "generating a page" as opposed to "generating a list". Of course you can still be quantitatively and qualitatively against that, but it's a slightly different issue. -PanSola 21:06, 14 March 2006 (CST)

My thoughts:
 * 1) If a category does NOT have any subcats, then I don't care if it has over 200 articles.  HOWEVER, if it has at least one single sub-category, then due to the way MediaWiki displays things, I believe the parent category needs to be broken down so either the number of articles + subcats are <= 200, or everything goes into a subcategory (there might be over 200 subcategories, that's ok), and no stray articles.
 * 2) Some templates are hard to learn, some templates are less hard to learn.  But learning how to format a table in various nice and pretty ways is, IMHO, HARDER THAN ANY TEMPLATE I have seen on GuildWiki.  Once you need to use a table that isn't the plain borderless, background-color-less, default width table, the whole Zen of Wiki goes out of the window, because specifying formatting for a MediaWiki table is right on the level of HTML/CSS formatting.
 * 3) No opinon on Template:Skills, although personally I think the categories it generate would be nice.  I just don't have an opinion as to whether we should type the "code" in manually for each article, or use a template for it. -PanSola 21:00, 14 March 2006 (CST)
 * 4) One more thing, I hate it when a category says "A list of all the blah blah blah", because, in fact, most of the time the category isn't complete yet.  Even if it is intended to be complete eventually, or is complete now, I find the "all" still overly presumptuous.  I prefer using the wording "A list of blah blah blah", stripping the "all" part.  It's not like we are going to intentially include only a partial set of them and hide that fact.  We just make no gaurentees that it is complete, or is still complete when a user visits it right after a game update. -PanSola 21:11, 14 March 2006 (CST)


 * Karlos: I hear you! I, too, see the risks. There seems to be a misunderstanding about my intentions. I do not want categories to replace lists in bracket format (except for some few cases). As you no doubt remember, in the past I've often spoken strongly in favor of properly formated lists in articles instead of simple alphabetic categories. I want categories to help us with maintaining manual lists, not replace them. Below the manual list, we can add a note, possibly even in small font, saying "For a simple alphabetic list, see also: Category:" . This way you can check the category to see if any items are missing in the manual list and add them.
 * I totally disagree that this is the "biggest detriment to our ability to get ready for Ch2" though. Quite the opposite!! As I've explained, I think we need a change in policy in order to get ready for future chapters, especially for templates and categories. Most of our templates and categories were made with only ONE chapter in mind. They worked okay for Prophecies, but they are not suited for future campaigns.
 * I think we all agree about at least one thing: This is a crucial, very basic decision that will shake the foundations of this wiki. A decision needs to be made, through a vote, quickly, before Factions comes out. Before the Factions Preview Event even. The longer we wait, the more articles are created, the more painful it will become to change something. -- 23:04, 14 March 2006 (CST)


 * New issue with more categories: We don't currently use the ones we have consistantly. The most glaring example of this is Category:Ascalonians, Category:Krytans, Category:Maguumans, etc...
 * To start with we used to have Ascalons and Krytans as categories and we got rid of them (see Category talk:Ascalons because 1) they weren't being used much and 2) it was rather arbitrary how it was decided where NPCs went.
 * Now they are back in, and both the old objections seem to still be here. 1) Not all NPCs have these categories set for them, not even all NPCs from Pre-Searing have them set, and that seems to me like it would be the easiest, all are from Ascalon with the one exception being Namar (who looking at him has both Krytans and Ascalonians in his categories - WTF?!?).  2) What about the characters in the Souther Shiverpeaks that are wearing the uniforms of the Ascalon military?  Or the Krtyan garbed collectors there?  How do we catagorize them?
 * If we are going to add more catagories to things, we need to document very throughly how they are to be applied. This is something that has not been done in the past, and in part is why many of the categories are such a mess now.  (Note: I'm not blaming anyone here, I'm just as guilty of adding categories and not noting how they are supposed to be used.  I'm just saying that while we're discussing this, let's do it right this time.)  --Rainith 02:26, 16 March 2006 (CST)

Clearing the air
I get the feeling that the above discussion has become too dense to make any further progress. I've tried to distill the essence of the various choices we face in this article:
 * User:Stabber/Skill categorization proposal

I think we are facing a tight deadline to come to a resolution on this matter. If March 24 rolls around and we haven't decided anything, then I am afraid this whole matter will be dropped as people will have better things to do than worry about some internal guildwiki detail. &mdash; Stabber 01:55, 17 March 2006 (CST)
 * I feel the above discussion has nothing to do with how to categorize skills whatsoever. It's about what to name the categories in general (not even specific to skills), not about what skill categories should exist or how skill categories will be connected.  So you are kinda in the wrong place, IMHO. -PanSola 05:36, 17 March 2006 (CST)
 * You are right. I added the subhead to the wrong section. Moving two sections up. &mdash; Stabber 05:44, 17 March 2006 (CST)

Yet another deadlock
This project is currently in deadlock as the principal participants haven't been seen on GuildWiki in forever. I get the impression that no one (besides PanSola) really cares about any of these style and formatting debates. I say kill this project and let anarchy reign. Withdrawing all my proposals. &mdash; Stabber 18:41, 21 March 2006 (CST)

Vote on suffix
See GuildWiki_talk:Style_and_formatting/Archive_2 for the old vote/arguements given. Discuss below.

Voting format: instant run-off (remember to specify your second/third/fourth preferences if applicable!)


 * Alphabetical suffix: Skills (Core), Skills (Factions), Skills (Prophecies)
 * 1) Xeeron
 * 2) Stabber (Like Tetris below, I'd prefer a prefix instead of a suffix)
 * 3) Evil_Greven
 * 4) JoDiamonds (I'm fairly ambivalent about prefixes vs. suffixes, and think that should maybe be a future vote/discussion)
 * 5) Karlos
 * 6) (I'd make it a prefix though, not a suffix, i.e. "Core Skills", not "Skills (Core)"
 * 7) Barek
 * 8) Pan Sola (For article names only, and when it's article name, I don't htink it shoudl be suffix unless it's for disambiguation purposes)
 * 9) Evan The Cursed (Talk) (prefer w/ suffix; second choice: Excluding core, then including core)
 * 10) (vote here)
 * Numerical suffix
 * Including core: Skills (C0), Skills (C1), Skills (C2)
 * 1) Pan Sola (second choice: excluding core), and this vote choice is only for sub-categories, not for any article names whatsoever.
 * 2) (vote here)
 * Excluding core: Skills (Core), Skills (C1), Skills (C2)
 * 1) (vote here)
 * Other (you better have a really really great idea to vote for "other")
 * 1) (vote here)

Exhortation
People who cared enough to vote on the suffix issue previously but haven't voted this time yet
 * Lunarbunny,
 * Rainith,
 * TheSpectator,
 * Nunix

Question/Discussion about what the vote means
Are we voting on a suffix that will be applied to articles and categories alike, or are we just tagging categories? When I voted, I was just thinking category separation. I am completely against adding suffixs to skill articles, UNLESS there are two different skills with the same name for different campagins, in which case the suffix is for disambiguation. But for skills that only appear in one campaign (or a core skill), I disagree with any suffix/tagging in the article title.

If this vote was supposed to also about article tagging, can we restructure the vote to separate the issues? -PanSola 09:11, 15 March 2006 (CST)


 * As always, the suffixs applies to articles only if there are 2 similar names in different campaigns. If the name (without suffix) is enough to identify the article, no suffix. --Xeeron 18:11, 15 March 2006 (CST)


 * Well, I think there is a difference between distinguishing the Storyline of Prophecies vs Factions, and between distinguishing two different items named FooBar, one appearing in prophecies the other appearing in Factions. In this case I think former should use a Prefix and the latter should use a suffix.  More difference scenarios might occure... -PanSola 05:41, 17 March 2006 (CST)

Suffixes revisited
Apart from all the discussion above, I noticed that all the articles mentioned above use the format "Campaign Skill", instead of the "Skill (Campaign), that was previously discussed on GuildWiki_talk:Style_and_formatting/Archive_2. Did sentiments change here? I feel we should discuss this beforehand, since it will affect a huge range of article names. --Xeeron 22:33, 14 March 2006 (CST)


 * Hehe, see section below -PanSola 22:37, 14 March 2006 (CST)

some text below was moved here from Category talk:Monk Core skills

see discussion at GuildWiki_talk:Style_and_formatting, with vote results under it at GuildWiki_talk:Style_and_formatting. -PanSola 22:07, 14 March 2006 (CST)


 * That vote is obsolete. The "chapter" to "campaign" switchover in all official Anet paraphernalia is more recent than the votes. Incidentally, that style and formatting page is impossible to read. &mdash; Stabber 22:10, 14 March 2006 (CST)


 * The obsoleteness only pertains to the specific word "Chapter" vs "Campaign". A numeric system (2 vs Two) with short character cues (Ch vs Chapter can be transferred to C vs Campaign) for ease of sorting vs texual system is the main outcome of that vote, with an assumed suffix system that nobody challenged.  I don't mind if it goes "Monk skills (C0)" or "Monk skills (Core)", but I prefer the suffix system. -PanSola 22:26, 14 March 2006 (CST)


 * I don't particularly care either way if it's Category:Monk Core skills or Category:Monk skills (Core). It just means that I have to unleash my trusty little battery powered GuildWikian one more time. However, I do object to "C0", as it is not used in-game. &mdash; Stabber 22:29, 14 March 2006 (CST)
 * So Category:Monk skills (Core) is something we will both accept, but core is a special case. How about Category:Monk skills (C1) for skills exclusive to the Prophecies compaign, do you also object to "C1" because it is not used in-game?  We might have to bring this back to GuildWiki_talk:Style_and_formatting for another discussion/vote. -PanSola 22:31, 14 March 2006 (CST)


 * Yes, I think further brainstorming, and possibly another vote is warranted, as the last vote was won by the "ch"ers. Moving this entire convo there now. &mdash; Stabber 22:34, 14 March 2006 (CST)

Summary of my thoughts: -PanSola 22:47, 14 March 2006 (CST)
 * 1) I still support a numeric system, for sorting purposes.  When Anet release Campaign 10823 "Gwen's Counter Attack", people might not remember which campaign 10372 refers to anymore, or which number was "Attack of the Frog", but at least those info are readily available on the wiki, and the category's own page can/should mention the official title of the compaign anyways.
 * 2) I still support a short-hand (originally "Ch" vs "Chapter").  Since there is no H in Campaign, I propose to just use "C" (which was also a proposed shorthand for "Chapter" in the previous vote but got defeated by "Ch").  Let's keep things concise and to the point.  Prophacies would be C1, Factions would be C2, Gwen's Counter Attack would be C10823  (at which point we might want to pad Prophecies to C00001 for sorting purposes, but now we got a stabbing bot to do all the tedious crusades!)
 * 3) Using "C0" to refer to core is a possiblity, definitely helps sorting (usually letters get sorted after numbers, which might not be desirable).  However I do not have strong opinion on this issue, and wouldn't mind Core being used instead of C0.  For the purpose of skill box templates though, I would like to display core skills as "C0", even if for everything else we use "Core".  "C0" will auto-link to Chapter 0 which is currently a reirect to Core.  Doing it differently makes my skill box template more convoluted.
 * 4) I like using suffix system, "Monk skills (C1)", instead of "Monk C1 skills" or "Monk Campaign 1 skills".


 * There is one, admittedly convoluted, objection to a purely numerical treatment to the champtaigners -- we assume that their progression will be linear. However, what if after c4 we have a fork in the story, with c4.1 and c4.2 being in alternate universes? Would our elaborately constructed schema just fall to bits then? &mdash; Stabber 23:05, 14 March 2006 (CST)
 * I thought that was the ENTIRE POINT of Anet's change from using "Chapter" to using "Campaign", so they are no longer perceived as one following the other, so that players don't think they are barging into the middle of something if they didn't get the original Guild Wars. So unless they release two campaigns at the same time, or unless an alternate universe actually happens in the real world and this GuildWiki actually crosses the boundry and exists (and remained synced) in both universes, I don't see a problem with the number system. -PanSola 23:13, 14 March 2006 (CST)
 * To clarify, the campaign released after Campain 4, would be campaign 5. The campaign released after comapign 5, would be campaign 6.  It doesn't matter if 5 and 6 are forks of 4 and exist in conflicting alternate universe, or that the one released after 6 is set 1000 years before Prophecies.  Unless, of course, Anet decides to call them Campaign 4.1, 4.2, and -10 respectively. -PanSola 23:13, 14 March 2006 (CST)


 * The problem, in a nutshell, is this: Anet doesn't call them C1, C2, etc., so the question of how they will number the 1000 year prehistorical campaign simply doesn't arise. They, perhaps wisely, give them textual names, so the difficult to number prequel campaigns might just be called "The Charr Menace" or "Attack of the Crones" or whatever. In the past you have been very keen on sticking to the terminology Anet themselves use, so I am a bit surprised that you are willing to chart new waters in this case. &mdash; Stabber 23:18, 14 March 2006 (CST)


 * ANet do identify them by numbers, at least as long as the official name hasn't been decided or anounced. See Chapter Three. But: Since all campaigns are independent, the order not irrelevant, or at least not crucial. Me might as well sort alphabetically. -- 23:34, 14 March 2006 (CST)


 * First of all, I don't think there is going to be a question about numbering campaigns. You had one, and my answer is I don't think there is going to be one.  It is of my opinion, that they changed from "Chapter" to "Campaign" to remove suggestions of in-game timeline/order correlation between their releases.  Thus, my opinion leads to the conclusion that, campaigns will be numbered in the order they are released.  In my opnion, it is not a problem at all to number a prequal as campaign 7.  It is the 7th campain released for GuildWars, it might not be Chapter 7 in the story.  In my opinion.
 * I agree that "the question of how they will number the 1000 year prehistorical campaign" simply doesn't arise, in the exact same manner that "the question of how they will number campaigns that create a fork in the story" does not arise. I believe they are all non-issues.  I believe they will all be integers sequential in the order they were released. But since you think one case might be of issue, I brought up the other one and illustrated how I think they would all be non-issues.  AND if I am wrong and they DO use weird numbers like 4.1 and/or -10 for their campaign numbers, I would unconditionally go with their number system.
 * And if they do something weird in another way, numbering some campaigns and not numbering some other campaigns, then my positions is this: I judge it so extremely unlikely, that I am willing to assume it will not happen, and if the votes I favor prevailed, but I am proven wrong in the end, we will flesh out a new labeling system.
 * Because I believe the scenario is so unlikely, and the expedience of ignoring this scenario so great, that I am willing to take the big risk of having a major restructure of campaign tagging system for campaigns if somewhere down the line there is a campaign that suddenly doesn't get a number.
 * I remain keen on stiking with in-game terms. I am not advocating that information about "Gwen's Counter Attack" campaign be in the article "C10823".  I am advocating that "C10823" be used as a shorthand and sorting mechanism for categories related to the "Gwen's Counter Attack" campaign. -PanSola 23:42, 14 March 2006 (CST)


 * The big, and potentially huge, problem with non-numerical sorting is the fact that all of our article names get very long:
 * Monk Skills (C7) and
 * Monk Skills (Attack of the Crones)
 * are two altogether different breeds, if you need to type them repeatedly. I once made the mistake of creating a category called Category:Tomb of the Primeval Kings maps and I hated myself ever after when I needed to type it.
 * Additionally, numerical ordering automatically orders the campaigns chronologically, so we do not have to manually edit every page to make sure Prophecies comes before Factions.
 * We need to weight the additional work against the potential benefit of having the real names there.--Xeeron 23:57, 14 March 2006 (CST)


 * I'm against making up and prominently displaying to Guild Wars players nomenclature that we are essentially making up, in the form of c1, c2, c3, etc. Sure, it happens sometimes, but when it's relatively easy to avoid I think we should.  The game is called (ok, sort of subtitled) "Factions".  As far as I'm can tell, the actual order of release date is not extremely relevant to ArenaNet.  I see no reason to arbitrarily list things in release-date order (for instance, people don't list Star Wars in 4,5,6,1,2,3 order, generally, and usually talk about each film by name).
 * We can obviously have a page that discusses the release order, but it doesn't seem so inherently important that we should have every single skill, mission, explorable area, and NPC labeled with a number. That might be an extreme conclusion, but at least the areas should say what game they are part of!  (Amusingly, the Battle Isles are the only location in Core, I presume.)
 * As far as actually suffixing, I'm happy enough to see "Monk Skills (Factions)" or "Monk Skill (Core)". But I'm clearly opposed to using C1, C2, etc.  Those things will not mean anything to the average Guild Wars player, especially if we hit a point where there are half a dozen different standalone games that ArenaNet refers to by name.  The needs of the players outweigh the needs of the GuildWiki authors.  (In general, anyway.  Not to be taken to extremes.)
 * --JoDiamonds 02:04, 15 March 2006 (CST)


 * Ok, from all I heard here, the trend seems to go towards suffix. If you disagree and want a vote, shout now. However, there is also the issue of what kind of suffix and the huge majority that existed for Ch2 does not seem to be there for C2. Therefore I would like to reopen the vote for the suffix that is to be used from now on. --Xeeron 02:27, 15 March 2006 (CST)

My reasoning for changing my vote as compared to the old vote: As JoDiamonds has argued very well above, C2 will mean nothing for GW players. This used to be different when we all thought the new campaign would be refered to as Chapter 2 mainly. For me, Ch2 seemed to be reasonably close to Chapter 2 to have a first time wiki user immediatly understand what Ch2 means. Now that the new campaign is refered to as Factions by ANet and the appropriate abbriviation is C2, I dont feel that the user would be able to make the connection C2->Factions that easy anymore. Therefore, while it definitly will mean more work for us, I have changed my opinion about this matter. From the discussion above I get it that others are feeling this way as well, therefore I reopened the vote.

Please do not vote for other if you feel that the numercial suffix should be Ch2 or Cn2 or something else, vote for C2 instead. The same goes for Campaign:Factions vs GW:Factions or whatever alphabetical version we come up with. This should be the decision between numerical and alphabetical only. --Xeeron 02:40, 15 March 2006 (CST)

Currently, if we create a new PvE character, we see from left to right (English reading order) the Prophecies Campaign first, then the Factions Campaign. Open the skill menu and sort skills by campaign, we see Core Skills ordered before Prophecies Campaign. While the rest is speculation, I speculate that on 3/24 when we sort skills by campaign we will see Factions Campaign appear under, not above, Prophecies Campaign. I also speculate that when the third campaign comes now, no matter what its name is, when you want to create a campaign 3 PvE character, the choice will be ordered after both Prophecies campaign and Factions campaign. Thus, to players who purchase multiple campaigns, the order among the campaigns will have meaning. Thus C2, C7, C193, and C10824 WILL have some meaning for GW players. It might be that the some meaning does not have sufficient significance or utility to justify using the number as category tags, and the community shall make its judgement by the votes casted here, but some meaning exist. That, is my speculation. -PanSola 05:50, 15 March 2006 (CST)
 * BTW, if the general feeling is that campaign number/order has no meaning to GW players (contary to my opinion/speculation), then for skills by campaign and armor set listings we should sort the campaigns alphabetically too. -PanSola

Wow! Where was I when all this transpired? That was a lot of text to read! Some very nice arguments too. I would like us all to take a moment to honor PanSola and Stabber with the community award for Imaginative Crativity! "Attack of the Frog," "The charr Menace" and "Attack of the Crones"! Mmmm, good stuff! :) The creativity and intellect in this wiki never ceases to amaze me.

Ok, now to wade into this issue: Overall, I think adding the chapter name as suffix seems the most appropriate thing to do. I hate it as a programmer who likes shorthand, but it seems like the more readable thing for users. --Karlos 07:59, 15 March 2006 (CST)
 * Campaign Order does make a difference and will always make sense. Imagine yourself playing "Revenge of the Dredge" 15 years from now and you meet a newbiw who is telling people in the outpost that the Assassin was always there. So, you tactfully point out that it was introduced in "Factions." The young crowd ask you "What's that?" In response, you can only say: "It was the second chapter/campaign/champaign released of the game."
 * Placing chapter names in the title does spare us the need to place a disclaimer in the article that it only applies to chapter X. If we place a mysterious "C2" next to each skill name, we will likely need to place a sentence in each skill that says "This skill is only available in the Factions campaign." But if the skill is called "Bla Bla (Factions)" then that is pretty self-explanatory.
 * Any way you cut it, it seems skill lists will look nasty. I am trying to envision Category:Monk skills, which I assume will have sub-categories "Monk skills by attribute" and "Monk skills by campaign." Still, it should have an "All Monk skill" or "General Listing" (if we are to avoid the word "all"). That "All" listing will have brackets with "C1" and "C2" or "Factions" and "Prophecies" and will look ugly.
 * For Core skills, I suggest we add no suffix what so ever. Why should, say, Orison of Healing be called "Orison of Healing (Core)" when it's available for all chapters. All users will know it as simply Orison of Healing. Same thing for Battle Isles or Axe or Sword. Why should they be given a tag that makes them look confusing? Simply include them in all categories of all chapters. This way also, they will appear at the top of any listing of things with similar names.
 * Well, good points, though I think the discussion here is mostly about category tagging. I personally am against tagging ANY skill articles with campaign names, whatever format.  I am against renaming Healing Hands to Healing Hands (Prophecies) or Healing Hands (C1).-PanSola 09:06, 15 March 2006 (CST)


 * I certainly agree with PanSola on this count. I'd like the skill pages to remain simply the name of the page.  Assuming we have useful categories at all, the category will be a perfectly useful indicator of what campaign it's from (because it will be in category "Prophecies Skills" or "Monk Skills (Core)" or whatever we do, in fact, call the categories).  I think that's a reasonable way for players to see what campaign a skill is from, though I could see an argument that it is too subtle. --JoDiamonds 12:23, 15 March 2006 (CST)


 * Ok, so that nightmare is not gonna happen. That's cool. --Karlos 12:35, 15 March 2006 (CST)

Screen Resolution supported
Do we care? The GW client at full screen mode supports as low as 800x600, but in windowed mode can be made even smaller. Do we want to at least cater to the 800x600 crowd and make an effort to see that all pages render nicely (on mainstream non-pure-text web browsers) at the 800x600 resolution? Do we care about teh 640x480 population? (I just noticed that neither of my Windows XP computer can choose to go to 640x480 resolution anymore, 800x600 is as low as I can get to).

While I personally run my computer at 1600x1200, I am inclined to cater towards the needs of the 800x600 crowd.

There are some pages that don't exactly look good at 800x600 resolution, with float-right info boxes colliding with tables within the article. One of the more extreme examples I can find is Necromancer's Armor. -PanSola 06:17, 15 March 2006 (CST)


 * The truth is, I dont care. Unless the wiki becomes outright unusable at low resolutions, I dont see me checking different screen resolutions to alter the perfect look of a page. If we stick to the basic "dont overload pages with grafic" rule, this should not be a huge problem anyway.


 * PS: The computers I use run at 1024 and 1280 respectively and I never had a problem with any page here. --Xeeron 06:38, 15 March 2006 (CST)


 * We should definitely support 1024x768. I'm slightly more ambivalent about 800x600, and think that as long as we are reasonable things won't break too much.  We should make sure most pages are viewable at 800x600, I think, but let's not be too strenous.  Main page, skill and quest pages, that kind of thing.  Any page that we have fifty copies of.  =)  Individual pages can be checked on a more ad hoc basis (and if someone complains, we'll fix it, or they will). --JoDiamonds 06:53, 15 March 2006 (CST)


 * This is one of those "we'll cross that bridge when we get to it" kind of issues. If there is a need by our users for us to cater to 800x600 I am sure we will hear about it. We get all kinds of complaints about how the site should be in-game and here on the talk pages. On the flip side, taking on a campaign to ensure the entire site is 800x600 friendly is a vast undertaking. So, in conclusion, if enough people complain about it, then we'll deal with it. --Karlos 07:08, 15 March 2006 (CST)


 * I think it's a good idea. I'm just not sure how we're going to do it.  Or at least ensure it... not easy to check each page (as others have said).  Is there a simple solution, if we keep in mind while formatting?  It might be good to lay down guidelines now before we create new pages for Factions.  But I'm not really aware of what we can do since I'm almost always on 1280.  And having other tables float left just kind of screws it up even more.  Evan The Cursed (Talk) 14:28, 16 March 2006 (CST)
 * I'm just saying doing this as a best-effort thing. If a page is noticed to not be 800x600 viewable, we fix it.  If we are creating new tables/infoboxes, then as we are creating them we check how they work on 800x600.  Instead of making tables float left, you can add "clear:right" in the style, that will prevent any floating table to take up the same Y coordinates as the current table (even if they weren't going to overlap on the x-axis).  -PanSola 15:07, 16 March 2006 (CST)


 * Dammit! I want every page made so that it looks good at 2560x1024 when I have it stretched across my monitors.  :P  --Rainith 16:05, 16 March 2006 (CST)


 * To address Evan's question: The easiest way to test if a page looks reasonable on lower resolutions is simply to shrink your browser window. De-maximize it, and make it only take up 3/4 or half the screen instead of all of it (vertically and horizontally).  If your monitor is 1024x768, cutting it down to about 75% in each direction is a loose approximation of 800x600.  Adjust for whatever resolution you are actually using -- Rainith will have to shrink things down a lot!  =)  This obviously isn't perfect, but it goes a long way with minimum fuss. --JoDiamonds 01:40, 17 March 2006 (CST)


 * Really? Because I tried that before, and it never really caused a collision.  With any tables I've used that on so far - usually it just shrinks it down to near-nothingness.  When do the tables stop scaling and start colliding with eachother?  Evan The Cursed (Talk) 03:14, 17 March 2006 (CST)


 * Originally, Aura of Restoration's progression and skill box collide at 800x600, but I've edited the progression templates (1~3) so they will never ever collide with skill boxes anymore. I think some of the armor pages had armor box and crafting/trading info colliding too, but I have edited the old armor info template (added a depreciation note which also forces it to be thin).
 * It may be a browser dependent thing on how things won't fit is handled. Basically, at 800x600, Aura of Restoration's progression takes up all the horizontal space available, wrapping every white space it can use to try to be thinner.  Thus without the "clear:right" stype specification in the progression template (you can temporarily edit it out just to see the effects), it will collide with the info box. -PanSola 04:50, 17 March 2006 (CST)

Categorization links at bottom of page, why?
First of all, this is a GuildWiki rule that I personally never follow. By the time I noticed this rule, I have been seeing way too many articles with categorization links on the top of the page to take this rule seriously. So, what is the rational for this? - PanSola = SolaPan

a LOT of pages are missing the Ch2 template...
Factions has not been released yet. A lot of articles created during this FPE weekend don't have the proper ch2 tempate on... Not sure if there's an easy way for a bot to just add the Ch2 template tag to every single new page created during the FPE, and let us manually remove false-positives (if there are any...) -SolaPan 01:37, 27 March 2006 (CST)


 * I think that template should be scrapped. It has served its purpose. Many things about the game are clear enough now that the standard Wiki disclaimer should be sufficient. &mdash; Stabber 02:59, 27 March 2006 (CST)


 * Hmm more or less agreed. We need not to delete the template now, but I dont feel we need to stage a hunt for untagged articles either. --Xeeron 08:14, 1 April 2006 (CST)

Why only X11?
The X11 pallette seems to have been designed rather haphazardly back in the 16-bit era, and trying to shoehorn similar profession colours (ranger and necromancer, monk and ritualist, mesmer and assassin) into the x11 pallette has had some odd results, and I don't see things improving as future professions claim more colours. I propose that we add the 216 so-called 'web safe colours' to the list of preferred colours. Any objections? -- Gordon Ecker 19:10, 8 May 2006 (CDT)

Profession Colors

 * For an idea of how these colors look on a full page, you can look at my user page User:Barek/PvE.
 * I'm not sure if those are the best colors to use, and I'm open to improvements, they're just the ones I've been using. I do like most of them better than what's found at GuildWiki_talk:Style_and_formatting, but several are still not quite right.  --- Barek (talk • contribs) - 16:18, 23 July 2006 (CDT)
 * Without the other nearby to contrast, I don't think I'd be able to tell the difference between mesmer/assassin and ranger/necromancer. I prefer Gordan's colors over these.  --68.142.14.19 17:10, 23 July 2006 (CDT)
 * Good point, several of the ones I copied from the henchman article are so close that the muted variants of them are almost identical. My main complaint about Gordan's colors is that they are, in some cases, too bold; and in some cases they become muddy / brownish.  I'll play with some of the colors and propose some middle ground options. --- Barek (talk • contribs) - 18:29, 23 July 2006 (CDT)
 * Here's a revised variant:
 * {| border="1"

! Profession !! Border lines !! Header background !! Body background
 * - align="center"
 * Warrior || style="background: #FFFF0F" | FFFF0F || style="background: #FFFF88" | FFFF88 || style="background: #FFFFE1" | FFFFE1
 * - align="center"
 * Ranger || style="background: #97FF2F" | 97FF2F || style="background: #CCFF99" | CCFF99 || style="background: #F2FFE5" | F2FFE5
 * - align="center"
 * Monk || style="background: #6FBFFF" | 6FBFFF || style="background: #B8E2FF" | B8E2FF || style="background: #EDF7FF" | EDF7FF
 * - align="center"
 * Necromancer || style="background: #2FFF97" | 2FFF97 || style="background: #99FFCC" | 99FFCC || style="background: #E5FFF2" | E5FFF2
 * - align="center"
 * Mesmer || style="background: #972FFF" | 972FFF || style="background: #CC99FF" | CC99FF || style="background: #F2E5FF" | F2E5FF
 * - align="center"
 * Elementalist || style="background: #FF2F2F" | FF6A3D || style="background: #FF9999" | FF9999 || style="background: #FFE5E5" | FFE5E5
 * - align="center"
 * Assassin || style="background: #FF77FF" | FF77FF || style="background: #FFBBFF" | FFBBFF || style="background: #FFEEFF" | FFEEFF
 * - align="center"
 * Ritualist || style="background: #2FFFFF" | 2FFFFF || style="background: #99FFFF" | 99FFFF || style="background: #E5FFFF" | E5FFFF
 * - align="center"
 * Dervish || ||  ||
 * - align="center"
 * Paragon || ||  ||
 * - align="center"
 * }
 * For comparison, here's User:Gordon Ecker's from GuildWiki_talk:Style_and_formatting:
 * {| border="1"

! Profession !! Border lines !! Header background !! Body background
 * - align="center"
 * Warrior || style="background: #666600" | 666600 || style="background: #FFFF00" | FFFF00 || style="background: #FFFF99" | FFFF99
 * - align="center"
 * Ranger || style="background: #336600" | 336600 || style="background: #99FF00" | 99FF00 || style="background: #CCFF99" | CCFF99
 * - align="center"
 * Monk || style="background: #000066" | 000066 || style="background: #9999FF" | 9999FF || style="background: #CCCCFF" | CCCCFF
 * - align="center"
 * Necromancer || style="background: #006633" | 006633 || style="background: #00FF99" | 00FF99 || style="background: #99FFCC" | 99FFCC
 * - align="center"
 * Mesmer || style="background: #330066" | 330066 || style="background: #9900FF" | 9900FF || style="background: #CC99FF" | CC99FF
 * - align="center"
 * Elementalist || style="background: #660000" | 660000 || style="background: #FF0000" | FF0000 || style="background: #FF9999" | FF9999
 * - align="center"
 * Assassin || style="background: #660033" | 660033 || style="background: #FF0099" | FF0099 || style="background: #FF99CC" | FF99CC
 * - align="center"
 * Ritualist || style="background: #006666" | 006666 || style="background: #00CCCC" | 00CCCC || style="background: #00FFFF" | 00FFFF
 * - align="center"
 * Dervish || ||  ||
 * - align="center"
 * Paragon || ||  ||
 * - align="center"
 * }
 * That's all the effort I'm putting into this for now. Color pallettes are a very subjective preference, so I doubt that we'll get a large amount of concensus.  But at least now there are at least three possible pallettes available here for people to consider and/or use in articles. --- Barek (talk • contribs) - 19:42, 23 July 2006 (CDT)
 * Make that four. I have to say I didn't like either of these palettes. Your first was way too bring in the backgrounds (I'm all for bright backgrounds, but there are limits). Same goes for the second. If we're supposed to have colors, atleast let them show. As for Gordon's, I didn't like the strong saturation on them. It's like the colors shine, and imagine header backgrounds for Elementalists. Also, the monk background didn't quite fit in my opinion. As such, I also have a suggestion found at User:Galil/Sandbox. Bright, but not too bright. Only gripe I have with my own colors are the similarity between warrior, paragon and dervish, but I don't think that can be helped too much, considering I wanted consecutive brightness/saturation. &mdash; Galil  19:47, 5 August 2006 (CDT)

I'm not sure why MRA brought this up here, since the link he gave at the beginning (GuildWiki_talk:Style_and_formatting) is where it should stay, in one spot. The profession S&F is supposed to be dealing with articles like monk. --68.142.14.89 20:12, 5 August 2006 (CDT)


 * At some point I have listed the colors I used in the icons, but I have no idea where. As far as the prophecies icons and colors go, this was the first time colors were used in background tables and those colors were taken from the palette I used for the icons themselves. Maybe you could use this as another reference?  &lt;LordBiro&gt;/&lt;Talk&gt; 05:57, 6 August 2006 (CDT)

I'd like to propose that we select a set of standardised profession colours. Here are my preferences.
 * }

I'd rather go with the ones that use the 216 colour pallette. I'm also okay with the x11 pallette, but as new professions get new colours, the x11 pallette could get pretty crowded, I'm already running into Ranger / Necromancer, Monk / Ritualist and Mesmer / Assassin colour conflicts. So does anyone else have any opinions or alternate pallettes? -- Gordon Ecker 19:10, 8 May 2006 (CDT)


 * I support the movement of standardizing colors. No opinions so far on the choice -PanSola 20:30, 8 May 2006 (CDT)


 * I don't understand what exactly you're trying to show with the table. Take the Warrior colors for example, The two on the top and the bottom look (IMO) like crap.  Much more brown than gold/yellow which in my understanding is what the warrior's color was.  The Monk on the other hand looks better using the top 2 colors and for the Ritualist, I like the bottom 2.  So I guess what I'm trying to figure out is, are you asking us to base a choice on one row of colors, or what exactly?  --Rainith 20:37, 8 May 2006 (CDT)


 * Skills by capture location uses one colour for the profession names at the top of the columns and a second, paler colour (so pale it barely shows up) as the background colour for the rest of the columns. Skill Quests uses a single paster colour for each profession. Skills by Campaign and the various Unique Items and Armour pages use one colour for the background and another, much darker colour for the table borders. Okay, I've updated the table to make it clearer. The X11 pallette is currently the only one on the wiki's list of preferred colours. The 216 pallette is the pallette of 216 'web-safe' colours that I'm trying to get added to the list of acceptable colours. -- Gordon Ecker 23:32, 8 May 2006 (CDT)
 * I see no problem with using websafe colors. But as an addition to your propsal, I would like to suggest the use of more colors. Perhaps even truecolor (16,777,216 colors). It's not like many players' computers only allow 256 colors, or even the X11 colortable. Most run with at the very least 16-bit colors (65,536 colors) and I would be surprised if these are more than 10% of the players. So why lock ourselves on 216 colors? &mdash; Galil  10:44, 3 August 2006 (CDT)
 * I like the idea of standard colors, but I agree with Galil in that I doubt many GW players are playing the game in 256 colors. And with the new profession colors (Paragon especially) are already going to appear close to the warrior's colors, a larger selection would be preferrable so that as even more professions are added, we don't run out of suitable color choices. --Thervold 10:54, 3 August 2006 (CDT)
 * Choosing colors is hard, and choosing more than necessary is asking for trouble. Why do we need different bg colors for heading and body text? And when exactly do you use the various border colors? Plus, the second row in "general background" are quite muddy, see how they look in Armor types. I took the following colors off an RGB color wheel, they are more or less "pure" colors, meaning reasonably pleasantly looking. They are sufficiently distinctive from each other, but the contrast against foreground is still hard to get right. What do you think?


 * bgcolor="#bf7fff" | sample skill broken
 * bgcolor="#ff3f9f" | sample skill broken
 * bgcolor="#ff9f9f" | sample skill broken
 * bgcolor="#ffff7f" | sample skill broken
 * bgcolor="#bfffff" | sample skill broken
 * bgcolor="#7fbfff" | sample skill broken
 * bgcolor="#5fffb0" | sample skill broken
 * bgcolor="#00ff00" | sample skill broken
 * }
 * -- Ledrug 13:37, 3 August 2006 (CDT)

Take a look at Sandbox/colortest2 where I set up a sample for the suggestions here. If you take a look at the source, it'll be apparent how to add your own sample. (You can also set border or header colors with, for example wh and wb, but I don't think how they work in my template is how Gordon meant. I think he meant those for standalone tables rather than something like in my template.)  I think there's definitely a contrast issue with the brighter reds and purples with unvisited and visited link colors, at least with Firefox's defaults. The broken link colors probably don't really matter. --68.142.14.106 17:35, 3 August 2006 (CDT)
 * These colors may be fine for a header; but for the body, the text contrast is very poor. Also, in large fields (see the colortest2 link above), the colors seem to overwhelm the content.  Muting the colors would help, but then it becomes harder to differentiate between professions. Wait, I see now there are multiple color tests on that page - will post back here again after I figure out which is which.  --- Barek (talk • contribs) - 18:20, 3 August 2006 (CDT)
 * You are certainly right about colors being subjective, but I think at least something should be done to maintain a level of consistency across different pages. I don't think we can ever have a perfect color scheme that a) fits the in game boss colors; b) contrasts well with all possible foreground text colors, but we should have a color system such that in a large page, users are more than likely to jump to the right section by using the colors alone. I think at least this is possible. -- Ledrug 18:38, 3 August 2006 (CDT)
 * In case people missed it, here are more colours: GuildWiki talk:Style and formatting/Professions. --Ab.Er.Rant (msg Aberrant80) 18:47, 3 August 2006 (CDT)
 * Added in Barek's from the professions S&F page and fixed where I screwed up Gordon's. I used the wrong colors as backgrounds for his X11.  I added in his border/header colors since he does use them that way on armor types (which is where I ripped the table from).  --68.142.14.106 19:41, 3 August 2006 (CDT)
 * Added in Biro's colors used in elite skills list. --68.142.14.89 11:54, 6 August 2006 (CDT)

Are we looking for any consensus on profession colours? Or are we still at the stage where we used whichever scheme we like? --Ab.Er.Rant (msg Aberrant80) 21:07, 6 August 2006 (CDT)


 * I think we're still looking for concensus. The thing I really dislike about a lot of the colours being used is that they seem extremely arbitrary. Why B8E2FF for the monk border background? Why not B9E1FF or B6E5FF? Why 2FFF97 for the necromancer border lines, why not 1FFF92? Those colours are pretty much impossible to remember. Right now I'm in favour of using either the 216 colour pallette, hex triplets (requiring only 3 digits to remember instead of 6, and providing a 4096 colour pallette) or using the easy to remember X11 web colors. Anyway, I've got a new proposal with only background and border colours, using the regular background colours for the headers. I've included some skill icons for comparison.


 * - align=center
 * style="Background: Wheat; Border: 1px solid SaddleBrown;" | [[image:Warrior-icon.png]] [[image:Dolyak Signet.jpg]] [[image:Wild Blow.jpg]] Wheat SaddleBrown
 * style="Background: PaleGreen; Border: 1px solid OliveDrab;" | [[image:Ranger-icon.png]] [[image:Antidote Signet.jpg]] [[image:Comfort Animal.jpg]] PaleGreen OliveDrab
 * style="Background: LightBlue; Border: 1px solid Blue;" | [[image:Monk-icon.png]] [[Image:Signet of Devotion.jpg]] [[Image:Deny Hexes.jpg]] LightBlue Blue
 * style="Background: MediumSpringGreen; Border: 1px solid SeaGreen;" | [[image:Necromancer-icon.png]] [[image:Signet of Agony.jpg]] [[image:Defile Enchantments.jpg]] MediumSpringGreen SeaGreen
 * style="Background: Pink; Border: 1px solid Medium VioletRed;" | [[image:Mesmer-icon.png]] [[image:Signet of Disruption.jpg]] [[image:Diversion.jpg]] Pink MediumVioletRed
 * style="Background: LightSalmon; Border: 1px solid Red;" | [[image:Elementalist-icon.png]] [[image:Glyph of Elemental Power.jpg]] [[image:Fire Storm.jpg]] LightSalmon Red
 * }


 * - align=center
 * style="Background: Thistle; Border: 1px solid Indigo;" | [[image:Assassin-icon.png]] [[image:Signet of Shadows.jpg]] [[image:Black Lotus Strike.jpg]] Thistle Indigo
 * style="Background: Aqua; Border: 1px solid Teal;" | [[image:Ritualist-icon.png]] [[image:Signet of Creation.jpg]] [[image:Boon of Creation.jpg]] Aqua Teal
 * style="Background: Orange; Border: 1px solid OrangeRed;" | [[image:Paragon-icon.png]] [[image:Signet of Synergy.jpg]] [[image:Anthem of Flame.jpg]] Orange OrangeRed
 * style="Background: LightGrey; Border: 1px solid Gray;" | [[image:Dervish-icon.png]] [[image:Signet of Piety.jpg]] [[image:Mystic Twister.jpg]] LightGrey Gray
 * }
 * I think all of them match the profession colours pretty well except for Dervish, which appears to have three different profession colours, and can't really be assigned a final colour until we've seen the Dervish boss auras. -- Gordon Ecker 22:07, 17 August 2006 (CDT)
 * Anyway, I don't think we should make a final decision until we see the colours of the Paragon and Dervish boss auras. -- Gordon Ecker 00:39, 27 August 2006 (CDT)
 * Heh, nobody should need to remember any color values anyway, since this is really the job for CSS. Of course it would require modifying the overall stylesheet (monobook?), but once it's done, all you need to do to make a table is write something like  {| class="prof_monk" (blah blah) : beats writing  style="Background: LightBlue; Border: 1px solid Blue;"  any time. -- 128.148.60.60 19:31, 1 September 2006 (CDT)
 * This is a pretty good idea. Instead of CSS, we could also use templates in the manner of Template:STDT right? But first, we need to make a decision on the actual colors first. --Ab.Er.Rant (msg Aberrant80) 09:34, 2 September 2006 (CDT)
 * For my personal taste, the warrior color needs to be way more yellow and the ranger and necro colors are to close to each other. -Xeeron 09:58, 2 September 2006 (CDT)
 * I've added two more colour schemes to Sandbox/colortest2, these ones are based on the boss auras rather than the skill icons. And I agree that we should handle this with templates like the profession icons (or with CSS), which would make changing the background and border colours (and adding background and border colours for new professiosn) a lot easier. -- Gordon Ecker 17:56, 27 September 2006 (CDT)
 * I think templates named wc, rc, moc, and so on would be best. I think CSS would make it a little more difficult to see what's going on (seeing id="monk" as opposed to style="background: "), but maybe that's just me.  --Fyren 18:06, 27 September 2006 (CDT)
 * Just a note on the color tables at GuildWiki:Sandbox/colortest2; I've modified my color sets that I use. The colors that I use now can be found at User:Barek/notes.  Note that for the purposes of what you're looking at, only the border and header colors are relevant.  The background color is an accent color that coordinates, but for the most part would be unlikely to be used in most tables.  For your use in examples, I would call my header color the background color. --- Barek (talk • contribs) - 09:40, 3 October 2006 (CDT)

Table Templates
I would like to add the html command: rules="all" to several templates that include a table, because the inner lines are not drawn in the Opera browser. I have tested it with IE6.0, Firefox 1.0.7 and 1.5, and it seems there is no harm in adding this. --Trilo 11:44, 19 May 2006 (CDT)
 * lovely. - 12:25, 19 May 2006 (CDT)
 * I have changed it for the armor art and function template. If there is no negative post about it, I will continue with the other templates. --Trilo 12:49, 19 May 2006 (CDT)

Use of the article in self references
Is it "GuildWiki" or "the GuildWiki"? I notice that User:Tanaric, the original author of many of the style and policy pages, prefers the latter, but the former is the more prevalent usage. Koyashi 07:59, 25 May 2006 (CDT)
 * The site is called GuildWiki, so I always refer to it as just GuildWiki. It's kind of different from "The New York Times", though I'm sure some ppl would just call that "New York Times" anyways... - 08:07, 25 May 2006 (CDT)
 * Of coures, if you are referring not to the entity GulidWiki, but using it as a qualifier, like referring to admins or whatever, then I'd use "the GuildWiki administrators" or "the GuildWiki server" etc. - 08:11, 25 May 2006 (CDT)
 * Sorry, I didn't ask for an English lesson. Is there no set policy on this? Koyashi 08:17, 25 May 2006 (CDT)
 * Sorry, I didn't intend to give you an English lesson (and I make no claims that my personal preferred usage above are grammarically correctly in English). There's no declared policy on it, I was describing how I personally saw the issue. - 08:18, 25 May 2006 (CDT)

the untouched question: Prefix vs Suffix
This should've been hammered out a while ago, but we never got to it. I think all the categores that says "Factions blah" should be renamed to "Blah (Factions)". The "Blah" is the more important part of the information, and I see Factions as additional supplemental to distinguish this Blah from the Blah of other campaigns. It also eliminates the use of sortkeys for some of the categorization process. If I see no discussion, I'll do a crusade two weeks from today. If there is discussion, then we'll see how it goes. - 13:51, 27 May 2006 (CDT)
 * Plz do, and a lot of the Factions quick reference etc needs to be Canthan quick reference etc imo Skuld  13:56, 27 May 2006 (CDT)
 * That I disagree, but that's a different discussion for a different section. - 13:57, 27 May 2006 (CDT)
 * I would say that unless an object is specifically named "Factions Sword" or something within the game, then certainly (Factions) should be used to distinguish items from Prophecies and Factions.  &lt;LordBiro&gt;/&lt;Talk&gt; 19:52, 27 May 2006 (CDT)


 * Quick bump since there have been quite some distractions. I'm not going to bother with last day reminders or anything. - 23:34, 31 May 2006 (CDT)

Going on a lunch break. Will start the crusade when I get back. - 14:04, 10 June 2006 (CDT)

& vs and
Let's make it consistent. Either rename "Style and formatting" to "Style & formatting", or rename "Slang & terminology" to "Slang and terminology". Is there anything else that would be impacted?

For previous discussion, see, GuildWiki talk:Style and formatting/Archive 1. - 07:56, 8 June 2006 (CDT)


 * Software_&_Technical_Issues/Bugs &mdash; Skuld  08:35, 8 June 2006 (CDT)


 * Skuld, could you be a bit more specific? I can't seem to figure what you're referring to. --Bishop (rap|con) 08:39, 8 June 2006 (CDT)
 * Unless... you're trying to point out the use of ampersand there... I see... you may want to be a little less convoluted in your replies, it makes it easier for us slow folks. :P --Bishop (rap|con) 08:41, 8 June 2006 (CDT)
 * I thought Pan was looking for stuff with &s in, am I wrong? &mdash; Skuld  08:43, 8 June 2006 (CDT)


 * Nope, not wrong. If you had said: "Here's one:" I would have gotten it too. I'm slow that way. (Often, when responding with just a link people, especially you, mean to say "read here" so that caught me off guard.) ;P --Bishop (rap|con) 08:48, 8 June 2006 (CDT)


 * I'm in favour of completely avoiding the ampersand in article titles because they're reserved characters (or whatever the term is). -- Gordon Ecker 00:39, 27 August 2006 (CDT)

Double spaces after periods
There is one thing that has been irritating me for quite a while: The inconsistent use of double spaces after periods/full stops in GuildWiki articles. Most people don't use them, but some few regulars use them all the time. What's the deal? I'm not a native speaker, so others should explain. I wouldn't have said anything, but since some of the regulars here are very nitpicky about grammar, spelling, capitalization and such, I thought it's about time that somebody asks for clarification. Shall we define a standard or let everybody do as he prefers? -- 06:51, 23 June 2006 (CDT)
 * P.S: Full_stop --[[Image:TurningL sml.gif|Tetris L]] 06:55, 23 June 2006 (CDT)


 * I have noticed this as well. I see it only as a very minor issue though, since the only time you'll even get aware of it is when editing articles. HTML can't display multiple contiguous blanks (as long as you don't use no-break-spaces) so everything is displayed single-spaced once the article is saved. It would be nice of course if we had conformity here, too, but it's nothing where I would see the need of a written policy or something like that. :) --84-175 (talk) 07:08, 23 June 2006 (CDT)


 * Yeah, on the              wiki, it  doesn't                                                        matter how    many spaces     you   use, after a     period   or  not.                                                                                                                    - 07:26, 23 June 2006 (CDT)


 * LOL, nice PanSola. I agree that it doesn't need to be as a policy. There's nothing stopping me from getting rid of the double spacing too :P -:- Ab.Er.Rant (Talk)  07:41, 23 June 2006 (CDT)


 * I'll admit that I use them, mostly out of habit. You learn to type on something other than a computer/word processor and the general rule is you use two spaces after a period.  I could care less if people use them or not, as has been stated above it doesn't make a difference in the display, but there is no way I am going to try to break myself of the habit.  :P  --Rainith 10:25, 23 June 2006 (CDT)


 * I agree. It's a tough habit for either to change.  Either you were trained to use them when first taught to type; or you weren't trained to use them.  That training establishes habits that both groups would find hard to change (either to start double spacing or to stop).  As it makes no difference in the final displayed article, I don't see a reason to make a requirement one way or another on this (and for the record, I double space - learned on a typewriter, pre-pc).  --- Barek (talk • contribs) - 10:29, 23 June 2006 (CDT)


 * Yar. It really doesnt matter to me. And nice example pansola =P. However spaces do matter inside pre tags

I like pancakes.

I like pancakes.

I    LLLLOOOVE     PANCAKES!

outside pre tags:

I like pancakes.

I like pancakes.

I    LLLLOOOVE     PANCAKES!

--Draygo Korvan 10:31, 23 June 2006 (CDT)

Capitalization
I searched but could not find anything on this subject. How do we capitalize? Eg, profession types? So far I've capitalized it Elementalist only if it's the first word of a sentence, elementalist if it isn't, but it also seems I'm the only one. &mdash; Galil  19:12, 25 June 2006 (CDT)
 * First rule of thumb: use proper Engligh. Second rule of thumb: use proper nouns as desginated by the game (if something is capitalized in the game, we capitalize it too).  Elementalist is desginated as a proper noun in the game, at least for the great majority of the time I believe. For the actual policy, refer to GW:case. - 19:40, 25 June 2006 (CDT)
 * In other word, as I have always done. Thanks. ^^ &mdash; Galil  19:47, 25 June 2006 (CDT)
 * Um, the other way around. Proper nouns should always be capitalized. - 21:17, 25 June 2006 (CDT)
 * Hmm, think I misunderstood your first response. Then I better change my habit of not capitalizing profession names.. Thanks again. :p &mdash; Galil  21:23, 25 June 2006 (CDT)


 * Do not capitalize profession names, they are not capitalized in-game when they come in the middle of a sentence, and they would not be capitalized in regular English caps rules. --Karlos 23:10, 25 June 2006 (CDT)
 * Then I'm reverting to not capitalizing profession names in the middle of sentences. Thanks for clearing that up. &mdash; Galil  22:33, 1 July 2006 (CDT)


 * Umm... actually, they are capitalized in-game, most easily seen from dialogues and quotes. Example? Here's one of Cynn's lines to Jamei after your Tyrian characters arrive in Cantha: "Listen lady, he may not be much, but that Monk is mine!" And this isn't the only instance. There are alot of dialogues where profession name captilization occurs. Really? Yea... I'm kinda guilty of removing the capitalization of the profession name from sentences... :P I guess I should try to revert when I come across some of them again... --Ab.Er.Rant @ User:Aberrant80 (msg) 00:09, 11 July 2006 (CDT)

on Characters being "Tyrian"
When you create a new character, the game doesn't offer the choices of "to be born in Cantha" vs "to be born in Tyria", the choices aren't "Tyrian" vs "Canthan". Thus I want to push for standardization on the wiki that uses the phrasing "Prophecies Campaign characters" vs "Factions Campaign characters", versus "Tyrian characters" or "Characters born in Tyria" etc etc. A very specific semantic beef I have with "born in" is two native Ascalons could have gone to Cantha, and a kid there, then brought their kid back to Ascalon. The kid would have all the "racial" markings (or character creation options) inherited from the parents, witness the Searing, yet be "born in Cantha". This is on the nit-picky extreme, but I want to illustrate the issue of using "flavored text" not from the game. Because the roleplayer character creation does offer choices based on Campaign and not on continent (and when you log in, character selection also doesn't say "Tyrian" but says "Prophecies Campaign", I think we should stick to that. It's fine to call them Tyrian or Canthan in casual conversation or talk pages, but for technical stuff it's different.

Another issues is what if a future campaign takes place on multiple continents, or if a particular continent ends up being the main location of multiple campaigns? - 00:43, 12 July 2006 (CDT)


 * Yep, I kinda thought about that "multiple campaigns on the same continent" thingy for NPC categories, so I'm agreed to the standardization. I'd also suggest that the "Campaign" part be dropped to make a shorter bit of text, so it'll be " Prophecies characters " and " Factions characters ". --Ab.Er.Rant @ User:Aberrant80 (msg) 02:31, 12 July 2006 (CDT)

the ranger profession icon template
Can we put something in here about using lowercase for profession icon templates (,, , , and ) by default to prevent the problem with template:r? -- Gordon Ecker 04:58, 22 July 2006 (CDT)
 * We could... but isn't that a bit drastic? How about simply deleting the template and then recreating it? Maybe it'll solve whatever's wrong with it. --Ab.Er.Rant (msg Aberrant80) 05:07, 22 July 2006 (CDT)
 * Deleting and recreating the template was already tried. This is seemingly something that can't be "fixed" because it is not really a glitch, but instead now a reserved character (in uppercase at least) in the new mediawiki version. There is previous discussion of the topic on the template's discussion page, Skuld's discussion page, and the Software and technical issues/Bugs page. --Kwisatz 23:21, 22 July 2006 (CDT)
 * We could incorporate it into the profession ondering section. -- Gordon Ecker 20:27, 24 July 2006 (CDT)

Please stop floating TOCs to the right!
Guys, I understand that, on some pages, on some browsers, a right-floated TOC looks nice. However, If somebody wants to float the TOC, they can do so on their user CSS page (I'm doing this now: User:Tanaric/monobook.css). Shoving stylistic information into our pages adds needless complication. Forcing the right-float mucks up things for some people. It's confusing to browse on pages and have to find the table of contents each time. Finally, whether the right-float is better or not is a personal opinion, and forcing it on everybody isn't the thing to do.

If the consensus is with me, I'll start reverting right-floated TOCs as I find them. &mdash;Tanaric 23:34, 9 December 2005 (UTC)


 * If we're going to do this, then I request that each page starts with a section (for the text part at least). That way we don't get pages with a half dozen lines of text and then a TOC, then the rest of the article.  See Academy training quests for an example of what I'm talking about.  A Table of Contents should be at the top of the article.  Or we could just get rid of the altogether.  --Rainith 23:52, 9 December 2005 (UTC)
 * Apologies, I right float TOCs because I saw other ppl doing it, so just assumed it's the "right" thing to be doing. I agree with Rainith though.  Having the TOC buried at an unknown location vertically is worse than looking for it at the top of the page not knowing if it's gonna show up on the right or left. -PanSola 00:04, 10 December 2005 (UTC)
 * As an addition, I don't care if we have them on the right or left or none at all. I've stated before that for things with a box on the right side (Bestiary entries, Items, Skills, etc...), a TOC looks bad on the right.  In those situations I don't like it on the right.  Other pages I have no problem with it being on the right.
 * If you can't find it when it's on the right... just how big is your monitor? Or how high do you have the resolution set at?  I run at 1280x1024 at home and have no problems finding the TOCs on the right or left.  --Rainith 00:27, 10 December 2005 (UTC)

I've revived this somewhat old discussion because this trend is continuing&mdash;actually, it seems to have become the standard. I'd like to reiterate that it's an extremely bad idea&mdash;the contents of this edit box is supposed to be the page's content, not the page's formatting. The wiki engine will format the page however it feels.

It has been noted elsewhere that forcing TOCs to float right on individual pages can cause them to render incorrectly on different browsers / small windows. I like the fact that I can use GuildWiki (on most pages) with a 400px-wide window or less. This allows me to run Guild Wars in a 400px window, side by side with the wiki.

More importantly, though, it's not asthetically pleasing to me. I prefer the standard MediaWiki TOCs. I can't even force them all to render on the left, since the local style commands in the TOCright template override user CSS. For such a questionable application of personal taste&mdash;especially when we've decided in the past that we're to emphasize content over presentation&mdash;I think that we need to remove TOCright tags.

&mdash;Tanaric 05:54, 2 August 2006 (CDT)


 * Back to the original replies to this: as long as all articles start with a heading, then I have no major problem with this - although I would like more discussion before a change is made (see below). I find that it's much harder to locate the TOC when it's buried under several lines, or even several paragraphs of text, rather than a right or left issue, so I would want to insist on ensuring that the TOC is always at the top.
 * On the issue of at the top ... I believe that the reason that most users force to right isn't an issue with their personal preference on right or left as much as it's a preference in how the article contents display. In the two browsers I've used, a TOC right results in the main text being at the top of the page along with the TOC also being at the top, with the article text wrapping around the TOC box much as it would around a thumbed image box.  With the default TOC on the left, you need to scroll down to reach the start of the article (ie: only the TOC starts on top, the  article begins after it).  I don't have a strong preference here (I need to think more about the issues here), but I can certainly understand a preference for the article text to be at the start of the article, and the TOC to be as well, just next to it.  If it causes problems, I would like a better understanding of those before we reach a decision here.
 * I'm curious about the browser issue you mentioned. With all of the pages that force to right (including this one), I'm surprised that the first I've read that some browsers have problems with this is here.  Can you point me to the discussions where it was brought up before?  Which browsers have problems with this command?  What, exactly, is the rendering issue it causes? --- Barek (talk • contribs) - 08:19, 2 August 2006 (CDT)


 * I don't like it on build pages, when I have to run 800x600 all the boxes show bits through the ToC &mdash; Skuld 08:28, 2 August 2006 (CDT)


 * Honestly, I don't know where I read that right-floating TOCs cause rendering issues at low resolutions. It's not something I felt the need to test. Nobody has provided a reason to float TOCs right besides "I like the way it looks better," and that alone is reason enough for me to argue against it.


 * What happens if an upgrade causes the Monobook style to do weird things with TOCs that floating right makes them horribly unusable? For that matter, how well does floating them right work on non-Monobook styles? There are too many questions, none of which have been asked by the editors who started this habit.


 * We've chosen to use MediaWiki software. If Gravewit wants to hack around with the source to change things, I'm totally okay with that. However, us changing things on a case-by-case basis like this in the content has the potential to lead to problems down the road&mdash;not to mention, annoying me at present. :) &mdash;Tanaric 11:25, 2 August 2006 (CDT)


 * To me, the ifs about the future are a non-issue (and borderline FUD - don't fear change; adapt). Afterall, it's done via a template; if some future MediaWiki change did come along that caused horrible, nightmarish things to happen when TOCright was used, no problem.  We would just need to neutralize the template and all pages would work again.
 * The bigger issue to me are any rendering problems that occur in the here and now. From what I'm reading here there are problems with it on anything that uses a table in an area that could intersect with the TOC; build pages, skill pages, etc.  I also agree, it looks horid on most item and weapon pages.  Those, to me, are reasons to argue against its use if you have a strong preference for it to always be in the same location for consistency (ie: always left instead of right on some).  Thus far, I have no preference on left vs. right, other than a strong dislike of orphanned text appearing above the TOC.  But I am trying to understand the issues more here. --- Barek (talk • contribs) - 09:01, 3 August 2006 (CDT)
 * on some pages (high-80s percent) with some browsers (mozilla, IE, firefox, Opera, pretty much everything except Lynx) right floated TOC looks better. getting the table out of the line of text is preferable on every page excepting pages that already have something float right, i.e. the skill box, etc. the text should be allign left, with extraious stuff, like pictures, TOC, skill box, item box on the right. pages flow better and read easier. --Honorable Sarah [[image:Honorable_Icon.gif]] 09:49, 3 August 2006 (CDT)
 * That's odd. When I read about browser issue I too thought about Lynx. For that reason, I tried it (running linux half of the time and it's invaluable to have installed). The result was actually surprising. It didn't render too bad at all. The TOC ended up above the contents, but that's it (tried this page: Community Portal).
 * Other than that, the issues I have with the way editors seem to want to make things are using tables for design. Tables are meant to contain data, not to move things around on the page. That's what layers (aka divs) are for. Also, I sometimes see tags that aren't even following the html/css/xhtml standards. If one were to validate the code used on every page on the wiki, I doubt either of them would turn out valid (but then again, I guess MediaWiki's developers are partly to blame). This isn't good for accessibility. But those are just minor problems at the moment. And I feel I'm going off-topic here, so I'll just stop it there.
 * Either way, I don't really care if TOC's are floating left, or right, or none at all, as long as there's consistency (actually, now that I think about it, and after testing, TOCs floating left doesn't look good). So in a way I do agree with Tanaric. But on the other hand, long TOCs tend to "dodge" page contents downwards, so I also see why this is necessary on some pages. Also, how would you solve it with pages like this? In short; I want consistency, but I also realize we cannot get it on all pages unless we modify all the styleguides and pages. &mdash; Galil  10:37, 3 August 2006 (CDT)
 * most pages of that size do not require a TOC, and pages that are long enough to require a TOC should be float right unless there is something already there, such as this page. --Honorable Sarah [[image:Honorable_Icon.gif]] 10:55, 3 August 2006 (CDT)
 * That's also how I was thinking. Though if we float the TOC to the right even when there is something there, I don't think it'd look horrible, as long as the TOC is on top of the other stuff. Granted it depends on what is to the right. &mdash; Galil  11:27, 3 August 2006 (CDT)


 * I'm sorry Tanaric, but I just plain don't agree with you. As far as I'm concerned, the TOC should be A) at the top, and B) in the place where it fits the article, be it left or right, according to the contents. Some articles, like skills and armor, we have a specific template that goes to the right. In such cases, having the TOC on the left -- or not at all -- makes the most sense. However, on many articles, especially long ones, it is a real pain to have to scroll simply because of the TOC, especially at low resolutions or in a small window. The solution to that, is to position the TOC on the right, where it floats nicely and the text flows around it. This placement conserves valuable screen real-estate, and is more aesthetically pleasing than the large chunk of blank space that is caused if the TOC is on the left. The issue of "not being able to locate the TOC" is bogus, especially since noone notices the TOC at all (except as a nuisance) unless they're actively looking to use it. And so is the issue of formatting in "some browsers we don't really know". All browsers are different in how they display things, and if actual, real problems crop up, then they can be handled at that time. There's no reason to change good practice because of problems that may or may not arise in the hazy future. -- [[Image:Bishop_icon2.png]] Bishop [ rap|con ] 22:08, 3 August 2006 (CDT)


 * Disagreed. You don't have to scroll to get around a large default-position TOC. You just have to click "hide."


 * The arguments against using the default TOC seem to be based around the opinion that it looks better on 80% of the pages. My opinion is that it doesn't. While I totally respect that you can have a different opinion than me, I don't understand why we're filling the pages with formatting code to make it look better under your opinion. Again, I go back to user CSS: you guys can force the TOCs right via user CSS if you like. However, if you force the TOCs right via the TOCright template, there's no way for me to force them left again.


 * There's a reason the TOC splits the text in an article the way it does. It's to provide an introduction, then the table of contents, and then the body. This is a standard that exists everywhere&mdash;books do this, as do text files and other websites (including the oft-referenced Wikipedia).


 * Additionally, there's the matter of consistancy&mdash;I abhor having the TOC be in a different place in different articles. Right now, only about 16% of the wiki uses right TOCs. This is low enough that I don't expect it when reading, and thus will very rarely ever actually see the TOC. It's human nature to follow the patterns you're used to. I've been around this wiki for 15 months with normal TOCs, and that's a tough habit to break when the gain is marginal (or totally negative, in my perception).


 * Also, there's the matter that it breaks absolutely the Simple skin and looks horribly with MySkin.


 * Any arguments I haven't fleshed out in this post I'm willing to abandon as trivial or borderline-FUD. If nobody is swayed by this response, I'll just grit my teeth and bear it, I suppose. &mdash;Tanaric 21:33, 5 August 2006 (CDT)


 * You know, in general terms, I very much agree with much of what you're saying. For example, I am a firm believer in content over presentation. And when you mention the short introductory text above the TOC on some pages, I have no problems with that. In the end, however, it really comes down to a matter of preference, and I still feel that dynamically placing the TOC according to what fits the article is preferable to forcing it left.


 * On a side note, I'm wondering if it really isn't possible for you to force the TOC left by using the !important css tag. My skills in css are rather limited, so I really couldn't say for sure. -- [[Image:Bishop_icon2.png]] Bishop [ rap|con ] 21:49, 5 August 2006 (CDT)


 * I believe !important affects only the precedence between user-defined style and author-defined style, not the cascade order within a document. The TOCright template sets the style at the element level, so something at the stylesheet level shouldn't override it, even with !important, as far as I know. That said, my CSS skills are pretty limited too. In any case, I think it's somewhat inappropriate to require users to tweak layouts themselves to get back to the default Mediawiki setting. Like it or not, MediaWiki's skin has become something users are accustomed to&mdash;not just at the GuildWiki, but across the internet. Subtle changing that default, and only on 16% of pages, is bound to confuse. &mdash;The preceding unsigned comment was added by Tanaric (talk &bull; contribs) 04:40, 6 August 2006 (CDT).

Categories: "tree" vs. "sort key" method
This discussion was sparked here, but moved here for general discussion and hopefully more people involved. Currently we have two different methods of organizing sub-categories if there is more than one criterion to sort by:


 * 1) The "tree" (a.k.a. "bla by bla") method, used for example here.
 * 2) The "sort key" method, used for example here.

The "tree" method has the advantage that it is self-explanary, with a simple tree structure. It is well established, commonly used in Wikipedia and most other wikis. The big drawback is that it adds an additional level for each branch of the tree, requiring the user to click through multiple levels of sub-categories before he reaches the entry he is looking for.

The "sort key" method is (correct me if I'm wrong) an idea by PanSola. It keeps all subcategories on the 1st level, allowing to see them all without additional clicking. It is "flat", as opposed to the multi-level structure of the "tree" method. The big drawback is that it isn't quite as self-explanary, and the structure isn't obvious.

I think we should preferably use only one method, thoughout this wiki. So I'd like to make a decision, if necessary by vote. Please voice your opinion. Thanks! -- 07:33, 11 August 2006 (CDT)


 * While the sort-key method is better for those who are more familiar with the game to get them where they want to go quicker; I think the tree method will be better for newcomers as it's more easilly understood and intuitive. More clicks are involved to drill-in to where you want to go, but I still prefer the tree method on the basis that newcomers to the game and/or the wiki will find it easier to understand how to find the data they want. --- Barek (talk • contribs) - 09:35, 11 August 2006 (CDT)


 * As I said there, I prefer category trees. Categories aren't meant to be pretty, user-facing pages.  If you want to present the user with some kind of elegant display, make an article.  --68.142.14.39 13:26, 11 August 2006 (CDT)


 * I don't really agree with the sort key method. I agree with 68.142.14.39. If you want to create such a list use an article.  &lt;LordBiro&gt;/&lt;Talk&gt; 15:17, 11 August 2006 (CDT)
 * I prefer the tree method as well. To me it seems a touch simpler, and simpler is usually better in my book. Whenever I find one of the sort key pages I have to look twice to figure out where I'm heading next (i.e. Monk Skills isn't under "M"). With the tree method I don't. --Zampani 16:28, 11 August 2006 (CDT)


 * To be fair, Monk skills will still not be under "M" under the tree method. It will be in a subcategory of "Skills by Profession", that will either be under "S" or under "P".  So it's either look twice and click once (sort key), or look twice and click twice (tree). - 16:55, 15 August 2006 (CDT)
 * Touche. Perhaps that was a poor example. In the end consistancy is the most important factor for me, so as long as the same is used all around I'm not one to complain. Still, I find the tree slightly easier to understand at first glance. Then again, I eat breakfast for dinner sometimes as well, so I could just be confused easily.  --Zampani 01:31, 16 August 2006 (CDT)


 * I too prefer the "tree" method style. As mentioned already, if a flat list of links is desired, an actual page should be created rather than relying on categories. I see categories more of an index off the important aspects of each page. While the "sort key" method is also quite user-friendly, it's not very edit-friendly. --Ab.Er.Rant (msg Aberrant80) 11:32, 13 August 2006 (CDT)


 * I agree with everything pro-tree stated here. &mdash;Tanaric 13:55, 13 August 2006 (CDT)


 * Yup, tree is better imho. --[[Image:Gem-icon-sm.png]] (talk) 05:49, 15 August 2006 (CDT)

The result of the discussion is pretty clear so far, so I don't think we need a vote, unless PanSola insists. The majority favors the tree method. I'll take that as a permit to roll back any category from sort key to tree method when I come across one. PanSola, do you remember which categories you changed to sort key? -- 01:56, 16 August 2006 (CDT)


 * Triggered by the new Nightfall skills for core professions I have finally updated all the skill categories according to the result of the vote. --[[Image:TurningL sml.gif|Tetris L]] 04:12, 21 September 2006 (CDT)


 * Oops missed the aug 16 message. Anyways, the ones I touched would've been armor, skills, locations, weapons, and maybe some parts of the bestiary.- 09:08, 21 September 2006 (CDT)

Here's my stab at how to arrange it. Users shouldn't be directed at Category:Skills, only various subcategories (from appropriate places).
 * Skills
 * Skills by type (skills of type "skill" go directly in here)
 * Spells
 * Enchantment Spells
 * Hex Spells
 * Skills by profession (professionless skills go directly in here)
 * Monk skills (attributeless Monk skills go directly in here)
 * Divine Favor skills
 * Skills by campaign (campaignless skills go directly in here)
 * Prophecies skills (professionless Prophecies skills, not that there are any, go directly in here)
 * Monk skills (Prophecies)
 * Elite skills
 * Special skills
 * Skill stubs
 * Skill sub-classes
 * Elite skills
 * Special skills
 * Skill stubs
 * Skill sub-classes
 * Skill stubs
 * Skill sub-classes

Category:Skill types goes somewhere else since it doesn't contain skills. Right now it's in skills by type, I think. The above organization makes each "Skills by X" subcategory tree contain exactly the same leaf articles: each skill once. Right now "by profession" is sort of doubled up, which confused me. Category:Skill sub-classes isn't a bad idea, but some of the choices are strange. Grouping together by our own external classification is good. I think a name that better indicates this would be a good idea, though I can't think of one. But "mantras" is useless. "Storms" is okay but the name isn't really helpful unless you already know what the skills share in common. I'd rather call it "DoT, AoE spells" or something. --Fyren 23:55, 21 September 2006 (CDT)

Skill/Attribute bar
The current combination of and  to show a build combines two different looking tables and stacks them on top of each other resulting in an ugly presentation. Example. I've been working on a combined table to get around that and the use of two different templates for builds. See User:Chuiu/Skill bar for the format and an example. I propose we use this template for whenever there is a need to show both the attributes and skills and keep the current two templates intact for other uses (like showing alternate attribute distributions or skillsets for builds). The only problems with the template I setup is that it extends past 800x600 resolution. I don't see that as a problem though since most of the pages that use a skill or attribute bar look horrible with overlapping tables in 800x600 anyway. (T/C) 21:53, 21 September 2006 (CDT)
 * They can be in the same template and be different tables. I think they look better separate so there's not a ton of empty space for the attributes.  (Also, GuildWiki talk:Style and formatting/Builds.)  --Fyren 22:02, 21 September 2006 (CDT)
 * I'm not against combining into one template; but I think the current multi-template / multi-table appearance is cleaner and better looking that the new proposed combined version. Too much empty space and ugly dotted lines everywhere in the new one. --- Barek (talk • contribs) - 22:20, 21 September 2006 (CDT)

Section 0
I added a note saying section 0 of an article should contain intro matter. I went through and did quick/dirty changes to the S&F pages that had a == General == or == Description == as what should begin an article to remove the headings. But in general the S&F are woefully out of date anyway. --Fyren 07:55, 10 October 2006 (CDT)
 * You pointed Rainith to this talk page, but you haven't explained why an article should not begin with a section heading? I know Wikipedia encourages the presence of a leading section. But I think the General/Description section more appropriately provides that. On pages with a long table of content, that lead section at the top just makes the page look weird (imho).
 * Having a lead section was never part of any s&f, so being outdated doesn't really matter. The s&f pages are not woefully out of date. Do check the date for the NPC s&f and check the NPC articles. I'm also still awaiting feedback for the Towns s&f. -- Ab.Er.Rant (msg Aberrant80) 20:28, 10 October 2006 (CDT)
 * MW and WP are tied together in some ways since the main goal of MW development is to support WP. In this case, that's how they designed it to work weven if the root is in WP's style choice.  The software is designed such that intro text is supposed to be at the top, followed by the TOC, and then the rest of the article.
 * Stylistically and organizationally, given how MW displays headings and articles, I think this is the correct choice (especially compared to the alternative of a section beginning an article). In the context of this being a guide (or a reference, or an encyclopedia, or whatever), pages aren't floating in limbo.  They're meant to be liberally interlinked.  The topmost level heading of an article is really the title.  It's there on every page and has the horizontal rule that accompanies "normal" headings.  That's why we use second level headings and not first level headings for everything.  Adding a "general," "introduction," or "description" header is a waste of space (gap between the title's horizontal rule and the heading) and useless (is someone going to get confused if the heading isn't there? does the heading help organize anything?).  --Fyren 21:49, 10 October 2006 (CDT)

In reply to Abberant above: about being outdated, most of them are. --Fyren 21:49, 10 October 2006 (CDT)
 * NPCs, builds, materials: They're fine.  NPCs are mostly due to your own large effort in going through all the articles and applying the existing S&F.  Builds is the same but through the effort of many editors.  Materials also match, though they're also probably one of the smallest set of articles.
 * Bestiary: Looking through a random selection of bestiary articles, while they often share the same order, headings are often arranged differently so some sections are subsections while in the S&F they're all second level headings. There's no mention of how to display drop rate data.  There's no S&F describing how to layout species pages even though we have a ton of very old species pages.
 * Items: No mention of collector sections for collectable drops. Mentions there are only four images for salvage items, which has been out of date since the Factions PvE preview (or at least since Factions).  There's not really much to say in the S&F I guess, since most items fall under the other, more specific types.
 * Armor: I don't want to say these are useless since they do describe the templates, but otherwise they are. If I wanted to make a new armor page, the only way I'd figure it out is looking at the mesmer armor page and styling it after that.
 * Weapons: A ton of weapons are missing sections. This is either because they're actually optional or because no one has bothered adding hem (perhaps a problem for "boring" items like Wooden Buckler).  This is still a problem, since you shouldn't write a S&F that no one wants to implement.  The item stubs category is huge.
 * Uniques: The "counterpart" heading has a zillion different names across the articles. The S&F doesn't help with picking a consistent set.  The intro line is a single sentence saying what drops the unique, which is not followed by most articles.
 * Towns: You're putting effort into this now, which is great, but a lot of the formatting (especially of the lists) varies from article to article.
 * Halls: For such a small set of articles, it's suprising the S&F doesn't match. They all use the location box template.  There's the same issue with items where lots of stuff is missing, though in this case it's more clear that no one really cares whereas for items getting the information for the non-option sections the S&F requires would be a massive undertaking.
 * Missions: Most articles don't follow the organization/headings in the S&F. This S&F has received an incredibly low number of edits given how popular the mission articles are.  It went without an edit for nine months, when someone changed it but didn't change any of the Prophecies articles to match.  A lot of Factions articles, probably written before this change, don't match it.
 * Professions: Doesn't reflect changes to our secondary profession articles. The rest is fine, at least, though I think that's mainly because the rest hasn't been touched in forever.
 * Quests: Mostly right, probably through Tetris' efforts (not to discount a lot of other people). It's lacking in describing optional sections/alternative walkthroughs as it only prescribes two sections: overview and walkthrough.
 * Skills: In flux and I plan to rewrite it after updating the skill box template. The template use is out of date and, depending how you look at it, always out of date.  Acquisition is particularly bad, since it's incredibly vague and led to a zillion different formattings across the articles.
 * General stuff: A lot of stuff doesn't obey GW:ULC. A lot of things like when to use subpages for species/quests/collectors/skill trainers, what to put in the subpages, how to format articles for trainers and collectors (as in, beyond the general NPC S&F) aren't described.