Guild Wars Wiki talk:Formatting/General/A1

This page is an archive. The contents have been moved from another page for reference purposes only, and should be preserved in their current form. Discussion on this page is not current. Any additions you make will probably not be read.

Speculative or unknown information

The following discussion has been moved here from Guild_Wars_Wiki_talk:Formatting#General_formatting_conventions_first

What's our stand on speculative or unknown information? Do we remove all unfounded rumors and unproven statements? Should then enforce that all empty sections (except notes and trivia I suppose) be kept and have a "None" specifically stated? --ab.er.rant 02:30, 14 February 2007 (PST)

If you are talking about...

== Skills used ==

*None

How about None known. This does not mean to speculate that a creature has no skills, it just means that a creature has no skills that have been documented yet. — Gares 09:10, 14 February 2007 (PST)

Edit: I do think that in such rare cases, that a screenshot may be needed to ensure we are not documenting misinformation. — Gares 09:12, 14 February 2007 (PST)

Remove it, we document the game as is and archive how it was, we don't guess how it will be. Only exception would be pages for campaigns not yet released but for which some facts are known (so before Nightfall we would've kept the Nightfall article, with a mention of Heroes in it, but deleted the Heroes article). --NieA7 02:11, 15 February 2007 (PST)

I think rumors and unknown info shouldn't be placed in the article. Omit the section and place the page in the 'needs confirmation/research' category (IF we're gonna have that). Or simply discuss it on the talk page until it's confirmed, that's what they're for, right ?

@Gares: I'm sure you know there're some creatures (bosses) that have no skills. That's when you specifically state "None", otherwise people may think it's missing while it's not. If it's not been documented yet, just omit the section.

Are we actually going to archive articles about the game how it was ? I know GuildWiki does, but what real purpose do those articles have ? To me, it's like keeping all the unused images because maybe some day it could be useful. --Erszebet 06:23, 15 February 2007 (PST)

There are monsters that may have a single skill they use, but the condition in which they use the skill has not been used, thus the skill has not been seen to document. Changing None to None known does not misinform a casual reader into thinking a monster doesn't have any skills, the user gets suprised when the monster uses a skill when Wiki said the monster had no skills, and start to think Wiki isn't a reliable source for information. The only subsections that need to be omitted if empty would be trivia and notes, the rest are valid and important subsections to educate users.

Rumors and speculation are not welcome in any case. We document what is found in the game, not what we think is in the game. This does not happen as often as you might think, but it happens on occasion. Yes, if something is considered speculation, proof and a discussion on the talk page is the best recourse. — Gares 07:14, 15 February 2007 (PST)

About the skills: I see your point now. Still, in this particular case, I think we shouldn't place "None known". If it isn't documented yet just omit the section and place the 'incomplete'-tag on the page (see discussion below). The tag and Formatting guide should take of the rest :) --Erszebet 07:04, 16 February 2007 (PST)

Capitalization of section headings

The following discussion has been moved here from Guild_Wars_Wiki_talk:Formatting#General_formatting_conventions_first

The "use lower case" rule. Are we keeping that? I've always preferred that all the words used in headers should have their first letter capitalised but if we retain this, it needs to confirmed. --ab.er.rant 02:30, 14 February 2007 (PST)

ULC unless it's a noun, capitals mid-heading serve no purpose - BeXoR 08:32, 14 February 2007 (PST)

ULC. It took me a while to get used to it, because in German all nouns are allways capitalized, but now I'm all for it. --Tetris L 00:49, 15 February 2007 (PST)

If it's not in game we should use title case for article titles - the clue's in the name (if it is in the game we should use whatever capatilisation is in place there). The single advantage ULC had was that due to the overly-restrictive policy on redirects at Guild Wiki it gave you a clue as to what you should be searching for if you want any results. It appears that GWW will have a much more realistic policy on redirects, allowing us to use grammatically correct headings with redirects for variants. --NieA7 02:10, 15 February 2007 (PST)

I don't think title case suits a wiki's presentation of information. "Capitalization Of Section Headings" is too formal, and very old fashioned. I think only proper nouns should be capitalized ("Doing things with Prince Rurik" not "Doing Things With Prince Rurik"). We don't need to emphasise every word. - BeXoR 04:38, 16 February 2007 (PST)

If it doesn't then personally I don't like a wiki's presentation of information. I don't think title case is old fashioned, if you look at pretty much any formal publication it'll be what's used. While I'm not saying we should regard all this as formal, I don't see why we should insist on using lower case (it's a personal annoyance of mine over at Guild Wiki, title case is much more natural for titles). Sub-headings can be noun capitalised, but main headings should be big and punchy - that's why they're main. --NieA7 04:54, 16 February 2007 (PST)

I don't see why we should insist on capitalizing headings. It serves no purpose at all, because the text is already emphasized. - BeXoR 05:46, 16 February 2007 (PST)

I agree with ULC. LordBiro 05:50, 16 February 2007 (PST)

Something for your information to consider at this link - I prefer the German Method personally - Joseph 06:30, 21 February 2007 (PST)

I think using German grammar in the English language is only a road for confusion myself. My biggest beef with title casing is all the ambiguities it presents. Conversely, proper nouns are a well defined language element that people should have learnt already in low grades of education, so capitalizing using sentence casing should be easier to adopt to properly. -- Jonas N 04:57, 18 April 2007 (EDT)

(reset indent) My personal preference is capitalise every word. But this isn't about personal preference, it's about reaching consensus and consistency. I can live with ULC. --Erszebet 09:28, 22 February 2007 (EST)

Use lower case. --Rezyk 00:17, 23 February 2007 (EST)

Profession order

The following discussion has been moved here from Guild_Wars_Wiki_talk:Formatting#General_formatting_conventions_first

Are we retaining the profession ordering used in GuildWiki? --ab.er.rant 02:30, 14 February 2007 (PST)

Use profession ordering as it is when you unlock skills at the balth guy (same as log in screen I recall) - BeXoR 08:32, 14 February 2007 (PST)

Tetris uploaded the Bally profession listing here. I think we should order based on this image. — Gares 09:21, 14 February 2007 (PST)

Oh! Dervish comes before Paragon?! Darn it... I've been arranging stuff P, D. --ab.er.rant 18:37, 14 February 2007 (PST)

Agree that in game order should be used. --Rainith 19:55, 14 February 2007 (PST)

I prefer alphabetical order, either of all professions or all professions within a campaign (e.g. Elementalist, Mesmer, Monk, Necromancer, Ranger, Warrior, Assassin, Ritualist, Dervish, Paragon). --NieA7 02:06, 15 February 2007 (PST)

Same as NieA. --Xeeron 05:02, 15 February 2007 (PST)

I prefer ordering as is when you create a new character - which is practically the same as on the Balth. picture EXCEPT that Paragon does indeed comes before Dervish... But I can live with the change :p --Erszebet 05:24, 15 February 2007 (PST)

It should be Prophecies > Factions > Nightfall. Within a campaign I don't care much, but if I have to pick an order I'd use the order that is used in most places in the game. There are the icons of the Priest of Balthazar, but there are other places too: Profession changer, Skill trainer, Hero skill trainer, etc. Let's check those. And the manual too. --

TETRIS L 07:52, 15 February 2007 (PST)

Alphabetical order becomes confusing later on as the order will change with later added professions. Definately agree with the way its done at Balth. --TigerWolf 16:38, 15 February 2007 (PST)

While I'm opposed to alphabetical ordering (since I used to the profession ordering), I fail to see how adding new professions will be confusing. New profession? Just slot it in alphabetically... -- ab.er.rant -- 23:32, 15 February 2007 (PST)

I think it's more of a visual/habit thingy. I'm kinda used to having prof listing starting with 'Warrior'. Looking at that Balth picture I'd say the guys at ANet had the same discussion :p They kept ordering for core professions and added new professions alphabetically. --Erszebet 09:36, 22 February 2007 (EST)

In game, the sorting in the Skills and Attributes window for choosing your secondary is W, R, Mo, N, Me, E, A, Rt, P, D. This is the same order that rune traders sort their offerings. While the hero skill trainers seem to show theirs in a mostly random order: A, Me, N, E, Mo, W, R, D, Rt, P

I looked in the manuals, and all three campaigns list the professions in different orders (C1 = W, R, Mo, E, Me, N ... C2 = A, Rt, W, E, Mo, R, Me, N ... C3 = D, E, Me, Mo, N, P, R, W).

My preference is to maintain the list as shown in-game for Balthazar or Rune traders. Although as long as they're sorted first by campaign, then second by an alternate means, I could learn any pattern. --- Barek (talk • contribs) - 10:57, 22 February 2007 (EST)

Same here. Since Anet didn't really establish an ordering, it's better to go with the most frequently used view. -- ab.er.rant 22:05, 25 February 2007 (EST)

Actually, I seem to prefer the character creation screen ordering... hmmm... can we have a closure on this? Since most seem opposed to alphabetical ordering, it all boils down to

or

. -- ab.er.rant

20:21, 4 March 2007 (EST)

I prefer the character creation screen order too. I won't die if we use the Balthazar order though. --Rainith 21:37, 4 March 2007 (EST)

Flip a coin because I'm sure that it really does not matter as evidenced by A-Net's own mixed usage. There are pros and cons for either ordering based on where it is used or alphabetical order or your personal sensibilities. I picked one to update the page with because I think that it is an arbitrary decision certainly one that needn't take up a lot of discussion time, not because I had a personal opinion either way (I even got the balth order wrong when I posted!). --Aspectacle 21:49, 4 March 2007 (EST)

Character screen order seems to get used in the game more than the Balth order. I say just stick with char screen ordering. Also, most of the work done around here is following it already. - BeXoR 05:01, 5 March 2007 (EST)

The rune trader lists common runes first, and when skills are sorted by profession, common skills go before primary or secondary profession skills. -- Gordon Ecker 04:06, 7 March 2007 (EST)

Introductory text

The following discussion has been moved here from Guild_Wars_Wiki_talk:Formatting#General_formatting_conventions_first

Introductory text. Some on GuildWiki are opposed to the idea that a section header starts of each page. Do we require introductory text before the first header (barring special reference-type pages of course)? --ab.er.rant 02:30, 14 February 2007 (PST)

Fyren always told me it was bad to start an article with a heading. I don't remember why. - BeXoR 08:32, 14 February 2007 (PST)

Here is the discussion about it: see fyren's reponse to aberrant's question - BeXoR 00:24, 15 February 2007 (PST)

I don't see why we need a guideline on that, just do whatever is most appropriate for the article in question. --NieA7 02:05, 15 February 2007 (PST)

There should be no rule on it, stuff like this can be decided on an article by article basis. --Xeeron 05:02, 15 February 2007 (PST)

Agreed, not always needed. --Erszebet 05:26, 15 February 2007 (PST)

Disagree. I'd rather it not be on a article-by-article basis. It should be on a type-by-type basis, which is why we have formatting guidelines. I believe Fyren wanted the introductory text to serve as a summary of the article, which means introductory texts shouldn't be longer than just a couple of lines. I'm thinking that introductory text can also serve as our no-spoiler part of a spoiler article. Like Kormir, for example, the introductory text could just introduce who she is and how she relates to the NF campaign at the start. I think some form of non-spoiler text is much better than the GWiki style of declaring that the entire page is spoiler content, allowing the user to at least have some basic info to look at if they don't want to get spoiled. -- ab.er.rant

23:18, 25 February 2007 (EST)

I think the concern here was that the toc was at the top of the page. As long as there is something in front of it, it should be fine? Whether that is a description or a spoiler notice, etc. - BeXoR 04:46, 26 February 2007 (EST)

Stub template locations

The following discussion has been moved here from Guild_Wars_Wiki_talk:Formatting#General_formatting_conventions_first

Stub template locations. At the top or at the bottom? I've noticed both. --ab.er.rant 02:30, 14 February 2007 (PST)

stub - at the top for newb users to see that an article isn't complete and there may be missing info - BeXoR 08:32, 14 February 2007 (PST)

I agree with keeping it at the top. Bexor's reason is basically my reason for it. Even the newest contributors will see the stub at the top. It's just more contributor-friendly. — Gares 10:35, 14 February 2007 (PST)

I support stub template at the top of the page. --Barek 11:03, 14 February 2007 (PST)

I think it should actually be at the very bottom of every page (maybe one level higher than the categories). From a usability point of view, less important information should be further down a page, and more important information should be higher up. When a reader opens a page about Charr Shamans, it seems to me more logical that the first thing he should see is ... information about Charr Shamans. The stub tag message if of secondary importance, since it's mostly there to invite the user to add to that page, which after all is something that should be implied when using a wiki. A stub tag is just a reminder of that for articles that seriously need some more content; it basically means "Look, this article needs a lot more meat, if you have something to add to it, by all means do". The purpose of an article is to present a particular piece of information to the reader; a stub notice changes that by shifting the focus from the information to the article itself. This same convention is used in Wikipedia, I believe, stub templates go at the bottom. It's not a huge issue either way though, I won't lose any sleep if the stub notices stay at the top. :P --Dirigible 11:36, 14 February 2007 (PST)

I am strongly opposed to placing stub tags on the top of article pages. The comment about noob users is silly. You are thinking of wiki articles as being written for other wiki users, when they are actually written for people who will never click the edit button. Some of them might even be in-game if this wiki is ever integrated. Such a non-editor does not need a warning that the article is too short. Secondly, noob users will not see a stub tag and suddenly write a comprehensive encyclopedic article (with notable exceptions, as always). They will correct typos and grammar to get a feel for wiki editing, then possibly write a stub or two themselves before contributing anything substantial. Even if we grant that users need to be warned that the article is short, this should be self-obvious. If all you can see is a paragraph, then it's a stub, stub tag or not. If it is more than two screenfulls, it is not a stub, stub tag or not. (Let us not repeat the dreary guildwikian mistake of merging the meanings of "stub" with "not policy/guideline compliant".) Therefore, stub tags are maintenance tags, intended chiefly to categorize short pages to aid in subsequent editorial passes. They are not informative in any way about the topic, only about the article, and it is editorial common sense to structure articles so that the most informative bits come before the less and non informative bits. S 12:42, 14 February 2007 (PST)

Disagree with you there. Stub may not mean "Edit me!" to the average (not "noob") wiki browser, but it does act as a warning against assuming that the article is complete (short does not necessarily mean incomplete). Much better to have it at the top and visible than tucked away at the bottom here nobody but editors will see it. --NieA7 13:41, 14 February 2007 (PST)

But all wiki pages are perpetually incomplete! Why do users need to be warned? And "stub" does not mean incomplete. Please do not repeat this mistake here. Stub means: "very short article". Nothing more. If we need to tag large incomplete articles where the stub tag is not immediately visible, we need to (a) remove the stub tag, and (b) use some other cleanup process. And no one has still convinced me that users need to be warned in such an in-your-face manner. S 13:53, 14 February 2007 (PST)

If users need to be warned it should be in-your-face so they get the warning. As to what a stub actually is, does you definition mean that pages like green weapons would be perpetually tagged as stubs because they're innately short? If not what are the criteria for short, non-stubby pages? --NieA7 14:01, 14 February 2007 (PST)

Why should they be warned at all? Why are you thinking of stub tags as warnings? And no, of course not, common sense should dictate when something is a stub and when something isn't. If an article can never become more than a paragraph or two, it won't be stub-tagged. We are not machines here. S 14:06, 14 February 2007 (PST)

(Edit conflict) They should be warned that what they're reading is known not to be definitive, unlike the other information we are presenting. Stub's are a warning because the GuildWiki tag (and I assume we're talking about a similar kind of thing) linked to wikepedia with a definition of a stub as "an article that is too short to provide encyclopaedic coverage of the subject, but not so short as to provide no useful information." In other words, "Warning, partial info ahead!". I know we're not machines but it's not like we don't have policies for everything else under the sun, I don't see why stubs should be an exception if there has to be a degree of judgement in their usage. --NieA7 14:23, 14 February 2007 (PST)

For reference, we can also view Wikipedia's article on stubs. First, their definition:

A stub is an article that is too short to provide encyclopaedic coverage of the subject, but not so short as to provide no useful information. To qualify as a stub it must at least define the meaning of the article's title. Often that means three to ten short sentences, but less text may be sufficient to qualify as a stub for articles on narrow topics, and complicated topics with more than ten sentences may still be stubs. However, in reality, many articles which are labeled as stubs are much longer than that. You can help Wikipedia by removing inappropriate stub notices.

Another way to define a stub is an article so incomplete that an editor who knows little or nothing about the topic could improve its content after a superficial Web search or a few minutes in a reference library. An article that can be improved by only a rather knowledgeable editor, or after significant research, may not be a stub.

In Wikipedia, their conventional usage is to place the stub at the end of the article. The question is if their definition and their usage should match ours. Personally, I can accept their definition, but I feel usage is more informative to the user at the top, letting them know up-front that the data they are viewing is incomplete and should not be totally relied upon for their farming / quest / mission / build / what-not. --Barek 14:19, 14 February 2007 (PST)

I still support the stub at the top of the page, but I would like to point out here that Guild Wars Wiki is not Wikipedia. We are a separate entity, related only by certain carried-over policies and the MediaWiki software. We were allowed to create this wiki due to ANet's kindness of allowing us use of their hardware and not the Wikimedia foundation, though their hard work and efforts allowed us to create sites such as this.

Let us not forget that and strive to make Guild Wars Wiki, not an exact copy of Wikipedia, but a place all its own. — Gares 14:38, 14 February 2007 (PST)

Note that no arguments I have made have been "because Wikipedia does it so". A counterpoint is that we should not do something because GuildWiki does it so. S 14:40, 14 February 2007 (PST)

I was just pointing out a fact and there have been places already in which it has been said that we are not GuildWiki. Even I have said this is not GuildWiki, though I have used it as a reference, much like Barek did with Wikipedia regarding stubs. I made no mention of GuildWiki and what is commonplace there, just that we are a community of our own and that our opinions and ideas should not be persuaded, either way. — Gares 15:01, 14 February 2007 (PST)

When you say that "usage is more informative to the user at the top", do you claim that a stub tag has any informative content about the topic of the article, or do think that it is informative only about the condition of the article and this is still important enough that it is the first thing the user reads? Is it likely, do you think, that someone will be making life-or-death decisions based on stubby articles, here understood as "very short article that is too short to provide [reasonable] coverage of the subject"? S 14:40, 14 February 2007 (PST)

If anyone makes "life-or-death decisions" based on content of this wiki, the stub status of an article is the least of their problems. I find it informative to have the stub status at the top as opposed to the bottom. --Rainith 19:07, 14 February 2007 (PST)

Can you clarify in what precise way you find stub tags informative? S 19:17, 14 February 2007 (PST)

I find the ones at the bottom of the page blend in, if they are at the top of the page it is easily noticeable that the page is a stub. And yes, I do find that that is something I like to know first thing when I look at a page. --Rainith 19:30, 14 February 2007 (PST)

Are you speaking from the perspective of an editor or that of a reader? Additionally, do you think the stubbiness of an article is not self-evident? Would you be able to judge an article as a stub if it didn't already bear the stub tag? Finally, since you want stub tags to stand out, are you treating them as warnings? S 19:36, 14 February 2007 (PST)

To answer your last question first, they are an invitation, an invitation to hit the edit button and add to the article. They do however also serve as a caution that the article may not be complete. Articles can certainly be completed, as this is a game with certain finite entities. An example would be a page that lists the elite skills in a campaign. There are a finite number of elite skills, and once they are known and added, any other edits will be either formatting or vandalism.

Stubs can also be important to readers too, if a boss page has a stub tag, you may take that as an indication that the skills listed for that boss may be incomplete. That could change the way you make you build to farm the boss's green. A stub tag at the top of a mission article could indicate that the tactics/walkthrough may be incomplete. --Rainith 20:10, 14 February 2007 (PST)

Do you consider incompleteness and stubbiness to be equivalent? Or can an article be incomplete without being a stub? And if so, should {{stub}} be also used for articles that are incomplete, but not stubs? S 20:16, 14 February 2007 (PST)

If the key elements of a page are incomplete, then in my mind it is a stub. Using a bestiary article from GuildWiki as an example: If it is lacking in Description, Location, Skills used, Items dropped, picture or Beastbox info, then IMO it is a stub. Missing notes/trivia or drop rate data do not affect the stubbiness of the article. --Rainith 21:17, 14 February 2007 (PST)

You are using a definition of "stub" different from: article that is too short to be of any real use. If stubiness and incompleteness are essentially synonymous, then we should do away with {{section-stub}} entirely. We should also rename {{stub}} to {{incomplete}} and change the wording to something like "Note: key elements of this page are incomplete. Use at your own risk." Let us be clear in our usage of jargon. I will now make this change. S 07:43, 15 February 2007 (PST)

I was surfing the wiki, and I found it odd to have it at the bottom of the page--although I believe it is better suited there for this reason: It makes the page look more imcomplete without being too obtrusive. I vote for the bottom of the page--a visual aid to make it feel like there should be more to the article. Jack 19:09, 14 February 2007 (PST)

For me the stub is both an invitation to edit and, at the same time, a warning that the article is less complete than the user is accustomed to from other (non-stub) articles in the wiki. As such I prefer the stub at top. --Xeeron 05:02, 15 February 2007 (PST)

I noticed that the question of how a reader vs. editor came into play. As a reader myself looking for information, a one line sentence, barely noticable at the top of a page, does not obstruct my search for the information I am seeking. This reasoning is not solely based on my current wiki experience, but it has been that way since I first started playing Guild Wars and had no education regarding wikis, inculding what stubs were or what they were used for. The same goes for the members of my guild, that are not editors on the wiki, and for the alliance members that I know search the wiki for information, as I asked some of them last night to get readers perspectives. Yes, they thought the questioning was a little odd, but the small survey seemed to help clarify what readers think of stub placement. — Gares 06:59, 15 February 2007 (PST)

I noticed the rewording of the {{stub}} tag. I'm fine with most of the revised wording, but I disagree with the word "Warning" right at the start. The argument that the stub tag can go to the top and not be a distraction is totally thrown out the window by forcing that word in which screams "pay attention to me". In the discussion above where re-wording was proposed, the comment was that it should say "Note", which is far less in-your-face; although I would argue that neither word needs to be in the tag. --Barek 08:03, 15 February 2007 (PST)

For me, the primary question isn't where to position the stub tag, but rather if we should use stub tags at all! I'm questioning this because the way we used them on GuildWiki they were pretty much meaningless, and not helpful at all. They were all over the frickin' place! Everybody plastered them on everything, and very few people bothered to remove them, even if an article was well elaborated and far from a stub. I guess that more than 10'000 articles on GuildWiki still bear a stub tag of some kind. Because of this the stub categories are not helping to find the articles that really need work. Let's not repeat this. This system needs a rework, badly. --

TETRIS L 08:22, 15 February 2007 (PST)

How are you going to herd cats? I gave it my best shot to have stubs defined as very short articles, but everyone wants to be warned that the article is incomplete. Discussion now is pointless, because people have shown up to voice their supports. S 08:40, 15 February 2007 (PST)

I just went over to GuildWiki to count the stubs. Looks like I overestimated the number, by far. There are "only" 3037 stubs on GuildWiki. Not as bad as I expected. --

TETRIS L 08:51, 15 February 2007 (PST)

An option would be that admins could help keep watch over stubs as another duty. I know some regular contributors remove stubs on occasion, but the majority of the populous don't. I think it can be pretty managable. — Gares 09:12, 15 February 2007 (PST)

I guess nobody read what I posted in the section below, so I'm gonna copy-paste it here. I'm also in favor of not using stubs as we know it. Here goes:

To tell the truth, I'm against using stub-tags in the first place. Period. They start to sound rather negative. Why don't we place something saying "This article needs more research" - or something along that line - on articles that are incomplete or in dispute (or 'stubs') ? Followed with a link guiding the reader how he can help. To me it's informative, a warning and an invitation, plus it'll look silly at the bottom of the page, AND it's different from GuildWiki :p Seriously though, any thoughts ? --Erszebet 05:49, 15 February 2007 (PST)

The stub message has been reworded {{stub}}. I think that may take care of some of your concerns without creating a new template. — Gares 10:31, 15 February 2007 (PST)

As I said above, I disagree with the stub starting with the word "Warning".

If we use the stub tag, I prefer it at the top of the page. However, I also strongly support having a guideline on what makes an article a stub. --Barek 11:23, 15 February 2007 (PST)

I like the current stub tag idea and to make it a warning that the article may not have been researched and that it needs help. Aslong as it donesnt stand out - it looks great at the top. --TigerWolf 16:22, 15 February 2007 (PST)

Currently if we take all the opinions of everyone in this section we have a concensus. It looks like more people support having it at the top. We have 8 people (not including me) who would like it at the top and 3 people who would like it at the bottom. We have 1 that would like to get rid of stubs altogether. Correct me if im wrong. --TigerWolf 06:11, 16 February 2007 (PST)

For the most part I agree with Stabber's argument so far. I realise I'm in the minority here, but I will make the following suggestion: If it is community consensus that stubs should indicate incompleteness then I recommend we do not use stub tags and instead we use 'incomplete' tags. LordBiro 06:19, 16 February 2007 (PST)

That is a likely option - and could possibly go in another discussion section if enough people agree. If we do have stubs or warnings etc though - it looks like they will be appearing at the top. The best place for the wording is probably in the other discussion. --TigerWolf 06:24, 16 February 2007 (PST)

I don't mind moving the wording found in {{stub}} to a new template {{incomplete}} sans Warning. Starting it off with just Key elements... or something a little less harsh like Notice or Attention. Warning conveys a danger or some risk found in the article, though a less commanding word would suggest to a reader just to be made aware of the wording found in {{stub}}. — Gares 06:50, 16 February 2007 (PST)

Let's get it over with and move 'stub' to 'incomplete', I'm all for that. About the wording; I think 'Attention, this article needs more research' is about as neutral as it can get. --Erszebet 06:57, 16 February 2007 (PST)

I just noticed that the current stub tags don't have links to the right formatting page. I added a link to Guild Wars Wiki:Formatting/Missions on the mission-stub template and left a note on it's talk page because that one is presumably ready. I guess when formatting guides are done all the stub tags will have those links, right ? --Erszebet 08:53, 3 March 2007 (EST)

Unreliability warnings

A claim has been made that users need to be warned that an article is incomplete, and that stub tags are the way to convey that warning. I am ambivalent about the first, but decidedly against the second. If users are to be warned that an article is unreliable, I suggest we adopt other means such as {{unreliable}} or {{disputed}} to be placed at the top of articles in a prominent location. This subheading should not be treated as a continuation of the stub tag placement debate just above, but rather should decide the question of how to warn users about unreliable articles. S 14:44, 14 February 2007 (PST)

If we have such a thing separate from the stub tag (still considering that as an idea) it should be {{incomplete}} - what we're trying to convey is that while what is presented is accurate it is not comprehensive. --NieA7 14:51, 14 February 2007 (PST)

Unfortunately, it is the nature of a wiki article that it will never be complete. As long as an edit button exists and there is another fresh pair of eyes, an article can still potentially be improved. Moreover, incomplete articles are still useful, and indeed might not be harmful at all. The points raised above have been that articles that are too short are in some form dangerous enough that readers need to be warned. This danger surely comes from the unreliability of the article rather than its completeness. S 14:58, 14 February 2007 (PST)

Point taken about perpetual incompleteness, however the warning I envisage {{stub}} conveying is "What is here is good but there's a fair bit more important stuff to know about this that isn't detailed below." Unreliable or disputed implies that what is there may be incorrect, which is not the idea. --NieA7 15:09, 14 February 2007 (PST)

At the end of every page is a general disclaimer. Does that not already convey the message you are trying to convey with {{stub}}, and much more besides? S 15:13, 14 February 2007 (PST)

If anybody takes the time to follow the teeny-tiny link at the absolute bottom of the page and read everything therein, then yes it probably would. I think we need something more obvious for the more obviously flawed stuff though. --NieA7 15:20, 14 February 2007 (PST)

(Resetting indent) In that case, I would propose making the stub tag much more visible and rewrite the text to read like a warning. Currently it reads as an invitation to edit, not as a warning against relying on the material. S 15:24, 14 February 2007 (PST)

I'm also disagreeing that stubs are warnings. Stubs are invitations to expand the article. A warning about unreliable/unverified/disputed information should be a separate notice. The former is not-so-important, the latter is important. --ab.er.rant 18:41, 14 February 2007 (PST)

To tell the truth, I'm against using stub-tags in the first place. Period. They start to sound rather negative. Why don't we place a box saying "This article needs more research" - or something along that line - on articles that are incomplete or in dispute ? Followed with a link guiding the reader how he can help. To me it's informative, a warning and an invitation, plus it'll look silly at the bottom of the page, AND it's different from GuildWiki :p Seriously though, any thoughts ? --Erszebet 05:49, 15 February 2007 (PST)

I really like that idea - something small and simple at the top of the page and with a little link - nothing that will interupt the flow of the reader. Its an helpful notice for readers and potential editors that the information might not be complete or reliable and can be used in either situation. --TigerWolf 16:35, 15 February 2007 (PST)

If we had some user CSS, I would move all tocs over to the right just like I do on wp. Fine, toss it. I actually agree with you that it looks ugly for short TOCs, but sometimes the TOC is really ugly. See Hero, for instance. What do you propose to do about the TOC there? S 20:37, 7 February 2007 (PST)

I agree with Stabber, I hate the TOCs on pages like Hero, that said, they are useful so I don't wish to disable them altogether for myself, nor will they work well if I were to move mine all to the right (if I could, no CSS) and we were to have "boxes" that are right justified like they are on GuildWiki. TOCright is useful and should be kept for some pages. --Rainith 20:42, 7 February 2007 (PST)

There's a hide link for a reason. As long as we use MediaWiki software, we're stuck under default MediaWiki conventions. I'd rather all of us deal with the default in our own way then have each of us deal with random hacks across the wiki. Besides, no page on any MediaWiki installation is particularly good-looking... that's just the way this is built. :)

I like the long ToCs on pages like Hero, because then I can easily see everything on the page before I read it. Floating it to the right ruins the point. —Tanaric 20:44, 7 February 2007 (PST)

I hate that huge whitespace that appears with long TOCs on the left, so I'm also of the opinion that the TOCright does have its place on certain pages. The important thing is to be consistent for different types of pages. Ab.er.rant 00:07, 8 February 2007 (PST)

Tanaric, you say that it's a bad thing because we shouldn't be making things look different for users than the default is. A ToC reaching from the top of the article one or two screen heights down is making articles irritating to read. Even if we don't use fancy layout stuff we should try to minimize the harm caused by certain features. Being un-user friendly isn't exactly the idea of a wiki. --Gem (talk) 00:49, 8 February 2007 (PST)

I have to say I hate the TOCRight template the most out of any template on GuildWiki. It's not that it's not default, it's that not every article uses it. As Tanaric pointed out, there's a hide button. There is no "harm" or "unfriendliness." --Fyren 02:39, 8 February 2007 (PST)

For example I don't want to keep the ToCs hidden as I use them, but they are really distruptive and hard to use on long pages with a lot of headings. --Gem (talk) 03:05, 8 February 2007 (PST)

They're only disruptive if you don't care about them, in which case you can hide them individually as you pass. If you do care about them, probably because you're looking for some specific piece of information in the article, you want them to be first. Floating them to the right accomplishes nothing, since you can't read both columns at the same time. —Tanaric 13:52, 8 February 2007 (PST)

This is an example of a trend that is really starting to bother me. ToC Right is being depricated? Says who? Tanaric and Fyren? The overwhleming majority of users on GWiki liked them. I personally found them extremely useful. They did mess up a few articles' formatting, but that was always easily fixable. I am open to debating them or whatever, but I think you are moving too fast and trying to ensure that certain things you were against get done quick. --Karlos 14:11, 8 February 2007 (PST)

TOCRight started when a few users who wanted to impose their stylistic vision on articles that everybody reads added it without consensus or even discussion. I honestly don't care if 99% of the users on the wiki prefer it, aesthetically -- indeed, if I myself preferred it, I'd argue against its implementation. It's completely unnecessary formatting code that breaks the default behavior of MediaWiki for no reason other than "I like it this way." If we allow individual editors stylistic jurisdiction on articles, all of a sudden the Main Page will have a black background, because it's leet yo, and the PvE builds will be written in pink text because only n00bs play pve lolzz. —Tanaric 17:48, 9 February 2007 (PST)

In terms of usability... The most common use for it is for long articles with mutiple sections, like the Storyline article or that big DoA build I posted on GWiki. Basically, you are able to start reading the article and get into the topic and yet at the same time, glance on the side to see the upcoming sections. This is when I find it most useful. When there's lots of text and section, not just sections (like collector lists) and not small articles. --Karlos 14:18, 8 February 2007 (PST)

I was just thinking, we could change the global CSS to float the TOC to the left. I don't know if this would be more appealing to the rest of you. I don't really like TOCRight myself. --The preceding unsigned comment was added by User:LordBiro .

I could accept float left, but there are places where it would look plain ugly. The right floating ToC is the best looking thing as long as there aren't any images floating on the right or info boxes like items and monsters had on GuildWiki.

Maby we should make this a style article, discussing when this a right floating ToC should be used an when not. That would adress Tanarics worries on random layout decisions made by random people. --Gem (talk) 23:43, 9 February 2007 (PST)

I think floating left defeats the purpose of floating it in the first place. You want the TOC easily seen, yet don't want to disrupt the reading of paragraphs that always start on the left. I still don't understand how the position of the TOC inspires hatred from users, and yet the huge amount of whitespace and forcing scrolling isn't also forcing the style of the page onto readers. Does that mean __NOTOC__ is yet another form of impose a certain style on articles? Going even further, S&F guidelines the way it's written on GuildWiki seems to fit into the "impose their stylistic vision on articles" part. --ab.er.rant (talk) 09:26, 10 February 2007 (PST)

Style and formatting articles on the GuildWiki were reached via community consensus. See the talk pages of those articles for plenty of evidence to that effect. TOCRight never underwent a similar process.

I think it's sad that bad design decisions that became etched upon our cultural consciousness in the bad web design days of the 1990s are so vigorously defended here. Imagine opening a textbook and having the table of contents pushed into the right margin of the preface -- it'd be ludicrous! While I'm well aware that wiki is not paper, the aesthetic effect is arguable and subjective. That ought to be sufficient to leave it well alone! Designing by committee only works when the committee members, by and large, are able to separate their own personal subjective assessments from the objective decisions they're supposed to be making.

As an aside, if, in the next version of MediaWiki the Monobook skin is updated to make all the ToC's float right by default, I'll have absolutely no argument with that. All I'm campaigning for is to leave the default behavior alone in subjective situations.

—Tanaric 16:11, 10 February 2007 (PST)

(EDIT: I've removed a very inappropriate personal attack against Gem, because it has no bearing on this discussion. Details can be found in article history and my talk page) —Tanaric 00:31, 14 February 2007 (PST)

So, by that last argument of yours Tanaric, we shouldn't have any of the MediaWiki extensions added on because they were not part of the MediaWiki design to begin with? --Rainith 19:25, 10 February 2007 (PST)

Tanaric, I really do understand your point, I'm just not sure why TOCright is being singled out and reject. This whole reasoning just seems to imply that all non-default rendering behavior should be rejected, encompassing other magic words like __NOTOC__, __TOC__, __NOEDITSECTION__, and even controlling font sizes on specific pages. But I'm willing to accept that the TOC should not be positioned and altered in any way (for now anyway, until a good example comes along). --ab.er.rant (talk) 20:41, 10 February 2007 (PST)

I personally prefer it to the right and I think it looks so much better, but I do think there is something wrong with forcing it on users who don't want it. If we could have some sort of css to change our default preference, that would be great, and probably the best solution to the problem for everyone concerned. It should be allowed on userpages though if the user wants it, or in situations where it is deemed necessary to complement page formatting, whatever situation that may be (I can't think of any situation where the float is absolutely necessary). - BeXoR 02:18, 11 February 2007 (PST)

That's an extremely sensible suggestion BeXoR. Those users who want the TOC floated to the right can use this CSS:

#toc { float: right; margin: 0 0 1em 1em; }

LordBiro 07:06, 11 February 2007 (PST)

As I suggested earlier, we should make a style guide for ToCs. That should make everyone happy whose argument is "because it wasn't discussed". --Gem (talk) 11:34, 11 February 2007 (PST)

Hero was a perfect example of when TOCright should be used. It has a long TOC. The TOC was not at the top of the page.

There were quite a few paragraphs not in a topic at the beginning that moved the TOC below them, and nearly off the page at 1280x1024 resolution. If anyone believes that this was a good situation, I have to question the reason. If you look that the recent history of that page, there is one revision with TOCright used, where the TOC is easily seen, and with no huge whitespace on the page. The last revision (as of this writing) removed TOCright, but I put the first paragraphs in a topic. This allowed the TOC to appear at the top again, only now there is a huge whitespace to the left.

"Our job is content."
Yes, and part of our job is also easy access to that content.
"I actually agree with you that it looks ugly for short TOCs, but sometimes the TOC is really ugly."
Exactly. An absolute rule of "NEVER use TOCright, in fact, delete the template." is a bad decision. Sometimes you need to to make the page more presentable, and at the same time, easy to access the content.
"Being un-user friendly isn't exactly the idea of a wiki."
Yes, see #1.
"I honestly don't care if 99% of the users on the wiki prefer it, aesthetically -- indeed, if I myself preferred it, I'd argue against its implementation."
Huh? What? Anyone, when talking about asthetics, saying they don't care if 99% of the wiki users prefer something is the same as saying "I want it my way, and no other way will suffice."
"It's [TOCright] completely unnecessary formatting code that breaks the default behavior of MediaWiki for no reason other than "I like it this way.""
No, it's reason is to make the page more user-friendly and readable, specifically in the case of the Hero page.

If anyone has a way of making a long TOC show up without a huge whitespace, and always at the top (or just always available), without using the TOCright template, I would like to see it in action (sandbox, or anywhere). I know that in Firefox you can use "body>div.controlPanel" to make a part of the page always at top (without the use of frames), but I am pretty sure Explorer (and possibly other browsers) can not use this feature so it should not be used. EMonk 15:51, 11 February 2007 (PST)

I like the the floatleft option as shown in the image on the right. This means that you can have a paragraph of the most important information at the top and the have a TOC with test to the right of it. Anyone have problems with this way of doing it? There is no whitespace and there is still a TOC since this is an important part of quite a few pages. --TigerWolf 16:28, 15 February 2007 (PST)

My own personal opinion is... have a TOCright template, but only use it on long TOC's. I personally prefer TOC to the right and not left. Yes, there is a "hide" feature, but I still think it's more presentable to the right. Joseph 07:05, 19 February 2007 (PST)

No TigerWolf. The same way you have people hating TOCright, you'll have people hating the way the left TOC pushes the left margin (like for for example). The problem with left TOC is that the width of the TOC is not fixed - it depends on section headers. And some section headers are half a dozen words in length, pushing my left margin all the way past the middle of the screen. Which looks really irritating for me. I'd rather have a long white space than left TOC with paragraphs wrapping around it. -- ab.er.rant 16:56, 19 February 2007 (PST)

I prefer allowing right-aligned TOCs personally because I find it make better use of the article pages, without messing with the left margin as you're reading a page. Still, sure, I'll go along with whatever is decided here. But for God's sake, don't enforce _NOTOC_ if it's in a long article. That's exactly when a TOC is most needed for navigation! If it's "in the way", well, that's what I think TOCright is for. -- Jonas N 13:36, 27 February 2007 (EST)

Feeding the fire - the TOC discussion continued

TOC-related questions that doesn't seem to have answers from reading the above section:

Do we want to, on a per-page basis...

allow TOCright?
allow TOC to be displayed at a location other than the default (above first heading, below all text/tables/pictures prior to the first heading)? (
- example: a page that has too much stuff before the first heading, so users would have to scroll down to find the TOC, because info boxes or policy decisions prevent the TOC from floating right.
allow __NOTOC__?
allow TOCs that only display up to a certain depth?
- example
allow manually-created "fake TOC hacks" to help navigation within a page, when the options available by direct MediaWiki means are unattractive?
- example
allow manually created collections of links that help navigation within a page, but does NOT pretend to look like TOC (basically just visually formatting the previous bullet point's example differently)?

- PanSola 07:04, 17 April 2007 (EDT)

I would say:

Yes for ToCright
Yes for slightly altered position of ToCright from the default position, but only slightly
Probably yes for NOTOC if the article is really short, eg most boss pages. Not too sure about this though.
I wouldn't disallow ToC hacks, but adding one would certainly need approval on the talk page. -- (gem / talk) 07:16, 17 April 2007 (EDT)

I'm only interested in the NOTOC:

Yes for NOTOC, since if there are 4 headings on a skill page Mark of Rodgort the silly TOC gets onto the page without a need for it. -- CoRrRan (CoRrRan / talk) 07:45, 17 April 2007 (EDT)

I would say:

No
No
Yes, in certain instances (i.e. the Main Page)
No
No
Maybe :P

If the question were on a per-user basis I would, of course, have no objection at all. But personally I don't want to see a hacked TOC. Even on pages with huge TOCs, I think this should be up to the reader.

I think that adding your suggestions to a stylesheet and allowing other users to import them, in the same way Smurf has done with his GuildWars.com stylesheet, is an excellent idea, but I can't support putting these hacks into common.css, because I don't agree that editors should decide how the article should look if it alters the default MediaWiki behaviour. LordBiro 07:47, 17 April 2007 (EDT)

Yes on TOCright. Look at Game updates, having that TOC on the left would just be a pain to the readers, pure and simple. Making good use of screen real estate at the benefit of usability is a very good thing in my book. The fact that it's not the default for MediaWiki somehow doesn't bother me at all, since most software comes with a "vanilla" version which the users can then customize to fit their particular needs better; modifying MW to best fit our purposes is alright with me. Why can't I just change it in my monobook.js/css files? What about the fact that most of the wiki readers can't customize how they want the TOCs to look with those files, since they don't even have an account in the majority of the cases, they're only readers. Once again, making the pages usable is definitely more important than sticking with the vanilla MediaWiki settings.
Yes, but I personally would like the TOC to be always as high near the top of the page as possible; if you need to scroll down to even find the TOC then that's missing the point of having one at all, I think.
Yes. Very many pages fit in one screen, having a TOC there is a waste of space that only pushes the real content below that first screen.
Yes to the three hacks, but as Gem said, they should have a good reason (I wouldn't go as far as needing approval for them).

So yes to all for me, on a per-page basis. --Dirigible 07:53, 17 April 2007 (EDT)

The only case where I would ever want to make the TOC at its non-default location, IS when the default location requires scrolling down to get to (ie, there's too much text/pictures/tables before the first heading). d-: - PanSola 08:02, 17 April 2007 (EDT)

I've given this a little more thought, and I still don't think we should alter the behaviour of the TOC, and that it should be per-user rather than per-page, but I think there are some situations where I would accept adjusting the depth of the TOC. Just thought I would mention that :P hehe LordBiro 08:19, 17 April 2007 (EDT)

I'm sorry, but I find "No, because it alters default MW settings" a terrible reason. MediaWiki is just a piece of software. It's not a holy book of some kind, it's just code. Tanaric says "It's completely unnecessary formatting code that breaks the default behavior of MediaWiki for no reason other than "I like it this way"", and I completely disagree with him. "I like it this way" should be a perfectly good reason to change the default behaviour of MediaWiki. We already are coming up with all the content that's in these pages, why shouldn't we also be allowed to make that content usable? "As long as we use MediaWiki software, we're stuck under default MediaWiki conventions" ← disagree. The reason we're using MW is to make our work here easier, so we don't have to code our own wiki from scratch; we can just use this one and modify it to best suit our interest. MediaWiki is released under a GPL license a.k.a. "take this and change it to your liking, you have full right to do so". We're not stuck with anything. Furthermore, they are called "default" values for a reason, they're simply the preset ones, not the only ones. __NOTOC__, for example, we didn't come up with that, it's part of the options offered by the software. MediaWiki comes with the default timezone set as UTC, this was changed to EDT, why not oppose that change too?

Heck, MediaWiki was designed with Wikipedia in mind, and yet Wikipedia still has more MW hacks than we will ever have (and yes, WP also use TOCright). Web software of all kinds (phpBB, Drupal, Mambo, etc) have all been built with the assumption that the administrators will customize them, and they always do. Look at all the specialty Linux distros based on customised versions of the vanilla Knoppix/Debian/Gentoo distros. Go to any university's computer labs and find them customised with software/bookmarks/settings that the students would most likely need. Bottom line is that customising software around your content and audience is not only acceptable, but it's the way it should be.

We're not even talking about taste here, about what's pretty and what's ugly. We're talking about usability, about making the content that we are producing here more usable. I'm sorry for repeating that word so much, but there's not much I can do about it, it's what this discussion revolves around. Deciding whether the text in a paragraph should be justified or left-aligned, that's about personal preference and taste; but deciding on whether to force our readers to scroll through two pages of TOC only to get to the actual content when 50% of the right side of the page is blank and wasted, that's about usability. --Dirigible 09:48, 17 April 2007 (EDT)

You don't have to apologise because you think my reason is terrible, or for repeating words.

Of course MediaWiki is just a piece of software, but I think that software should have a predictable behaviour. Isn't that part of usability engineering? I am very much a fan of usability, but I don't agree that shifting the TOC to the right is necessarily more usable than TOC left, even when a TOC is large.

PanSola asked for opinions and I gave mine; I'm opposed to altering the TOC on a per-page basis, but that by no means prohibits the implementation of such a system.

Making alterations to the behaviour of the TOC (or any behaviour) on a per-page basis does not seem very usable to me. If the TOC was being altered site-wide then I would have less of a problem with it. This has nothing to do with default MediaWiki behaviour (at least as far as I'm concerned, I cannot speak for other contributors), but it has everything to do with site-wide behaviour. I don't think we should be making decisions like "well, on this article the TOC would look better below the second heading" - that is not usability, that is confusing users who are unfamiliar with wikis, in my opinion.

I hope I've made my explanation clear; this has nothing to do with MediaWiki being altered, I am quite happy to do that provided the result is a predictable experience for the reader, and as long as we don't stray too far from expected web behaviour. As such your license argument doesn't really apply to my thoughts on the subject. But for the record, I do oppose the change to EDT, since I have no idea what that time is, and I prefer Debian. LordBiro 10:46, 17 April 2007 (EDT)

I don't think that the position of the ToC is something that falls under 'people expect the software to do it just like this so we shouldn't change it'. That argument works with link colors, but definitely not with the position of the ToC. The default ToC makes so many pages hard to use, there just isn't a good reason not to float the ToC. Ofcourse there is the option to have the default ToC to float in the right like Pan has said below, in which case the behavior is predictable like you want it to be, but I see that as an almost bad idea than forcing all articles to use the default ToC like it is now. --

(gem / talk) 15:28, 17 April 2007 (EDT)

On the per-user idea, I suppose I will not oppose strongly, if we keep Template:TOCright, but instead of having it say style="float:right;", let it be class="tocRight", so that the floating right behavior only happens if the user specified it in his/her own CSS. That way advanced users can still have TOCs floated to the right on a per-page basis while the general users will still see default TOC behavior. The one potential pitfall is we'll get people confused as to why certain pages have a {{TOCright}} that doesn't appear to do anything, and we might have to revert good-faithed edits (or answer "noob questions") of uninformed people who assumed the template simply does nothing at all and removed them. My position on the TOC limiter is similar. I will not accept a per-user All-pages-TOC-float-right proposal, which I feel is worse than disallowing TOCright (due to existence of infoboxes that float right). -PanSola 08:30, 17 April 2007 (EDT)

Once again, the vast majority of the wiki readers do not have accounts, they cannot modify their monobook files, they cannot be expected to either register an account simply to be able to make these changes or know how to make these changes. Since when are we the editors of the wiki also the main audience? If it sucks for them but looks good for us, how is that acceptable? If anything, the TOCright should function properly, but include a class="tocLeft" for those who are arguing so strongly against it. --Dirigible 09:48, 17 April 2007 (EDT)

I like the suggestion to use the ToCright template on a per page basis and include a class="tocLeft" to the template for those who don't want to see the ToC on the right. --

(gem / talk) 19:11, 18 April 2007 (EDT)

The TOC float-right sub-issue, an alternate choice

We can make all TOCs float right by default, and that if there are right-floating infoboxes, manually make the TOCs non-floating (since this is usually the situation where the TOC looks bad floated right).

This produces a relatively simple behavior pattern where:

The TOC will in generally float right automatically.
The TOC will not float if something is in its way.

I'm not making any claims judging whether I feel this qualifies as sufficiently consistent, or if it will still be too confusing.

Alternately a fully automated Javascript solution is also possible, which detects whether there are other objects floating right on the page, and adjust the TOC accordingly. In this case, the behavior when Javascript is off can be configured by CSS to go either way (if you want it to float right, then probably also want to make it do clear:right).

By stating this alternative, I am not expression support. I'm merely letting ppl know this choice exists (in case they wish to support it, or if this inspires them to think of other ideas that will eventually work into certain acceptable compromises for multiple parties of interest). -PanSola 13:55, 17 April 2007 (EDT)

I personally would prefer the toc to be changed on a page by page basis. TOCright is good on talk pages, update pages, notoc is great on really short pages, etc. On other pages it doesn't really matter to me if the toc is right or left - if it gets in the way I hide it anyway. - BeX 15:35, 17 April 2007 (EDT)

Wiki links

I suppose this is the right place to ask: what's the general thought on the use of wiki links ? Personally I find them quite annoying in dialogues / quotes, as part of section headers and in descriptions. See THIS example to know what I mean. Maybe it's just me but they look so out of place there. Links are useful and all, but then again you can almost link every word in a sentence. Should there be some form of guideline how to use them or keep it at common sense ? --Erszebet 07:42, 16 February 2007 (PST)

I find them useful, and see nothing wrong with having internal wiki links embedded in the dialogs. Wikify the first occurance of a particular reference in an article regardless of where it's at in the article - no need to wiki-fy every occurance.

I do think that links to other sites (including other wikis) should not be in the dialogs. Those should be placed at the end of the article in an "External links" section.

Link the first occurance in the article, and then again only if it's a page scroll or so down the page. - BeXoR 06:35, 17 February 2007 (PST)

Link the first case only, a page scroll down means different things to different people (resolutions/browsers etc). --NieA7 02:24, 19 February 2007 (PST)

The simplest guideline to follow is to just link the first occurence. A repeated link is allowed, but only if sufficiently further down the page. Sufficient being a page scroll (yes, different, but as a guideline, not a hard rule) and it has to be in a different major section. I don't like links in headers, but I have no problems with links being in dialogue and descriptions. I'm not sure why it looks out of place in dialogues yet not in normal paragraphs. But if you don't link, and a particular term or name appears only in the dialogue, you'd rather not link at all? -- ab.er.rant

23:24, 25 February 2007 (EST)

Imo, the reason why they look 'wrong' in dialogues is because you're always quoting somebody. Using wiki-links in dialogues makes it look like the original text was highlighted as well. Besides, there's always the 'search' box if the term only appears in the dialogue.

I guess it's just one of those visual thingy's you get used to after a while. For example take the standard creature description-syntax on GuildWiki: <creature name> is a <species> <profession> who can be found in <location>, like this one. Since 'Species', 'Profession' and 'Level(s)' are automatically linked in the BeastInfobox it feels natural to also wikify the values you enter (like 'Ranger' for prof.).

Same for 'Locations'-section. Normally you use unordered lists so I'd link every occurance in that list - just looks nicer that way. Although most of those values first occur in the Description-section, I don't wikify 'em there 'cause I know they're 'better' wikified in the other parts mentioned.

But don't worry, I'm well aware that it's ridiculous to make extended guidelines on 'how to wikify', so I'll stop now before people start calling me 'Erszebitch' :p --Erszebet 06:55, 28 February 2007 (EST)

Dialogues

Me again. I'd like to know what the general guidelines (if any) on formatting dialogue will be. Many NPC-, quest-, mission- etc. pages can have dialogue. The way it was formatted on GuildWiki works if the dialogue is limited. For more extreme cases (like Turai Ossa f.i. things get ugly (pun intended). I had a brief discussion with another user over there (Rubikon) who had some neat ideas - see his Sandbox - but I haven't seen him around here yet. I'd say keep the italics/quotes ("text"), but anything else (indenting, pointing out which NPC says what line,...) is open for discussion I guess.
Also, we've now officially got a use for Content over Presentation :p ... To think it was right under my nose the whole time...
With all the above I'm assuming we're actually allowed to add dialogues in the first place of course. --Erszebet 05:59, 21 February 2007 (PST)

Currently we are waiting for confirmation from ANet's lawyers that we can use quotes from in game. See User talk:Gaile Gray# Copyright, GFDL, and in-game content. Until we have an answer on that, I'm not even going to think about this. --Rainith 09:07, 21 February 2007 (PST)

Well I guess it's confirmed we can use in-game quotes, so any thoughts, anyone ? --Erszebet 06:57, 28 February 2007 (EST)

I suppose I'll stick with how I do it in GuildWiki until someone proposes a better alternative. I'm not sure how else to change it. -- ab.er.rant

19:57, 5 March 2007 (EST)

On my mission-update crusade at GWiki I've been adding cutscene dialogues using a table, which limits the space needed somewhat (see this for example. Only problem with tables is proper coding (column width seems to mess up sometimes for no reason, use of {{clear}} needed or not...) + it can be hard to include new dialogue lines. --Erszebet 07:25, 18 March 2007 (EDT)

Skill page formatting

⇒ Moved to Guild Wars Wiki talk:Formatting/Skills#Skill page formatting

Guild Wars Wiki talk:Formatting/Skills ;) - BeXoR 22:54, 26 February 2007 (EST)

Use of Shortcuts

Very minor item - so one I hope we can resolve quickly ... currently, we have a group of shortcuts to pages in the "Guild Wars Wiki" name space listed at Category:Shortcut redirects. Originally, shortcuts were only being created for entries that were adopted as official site policy, and has started to spread. For the most part, this doesn't concern me. But, I disagree with having a shortcut like GWT:TECH which links to the talk page of GWW:TECH. I could be talked into keeping such shortcuts if others argue for them; but if we do decide to keep shortcuts to the talk pages, I would prefer the shortcut be standardized with the prefix "GWWT:" rather than "GWT:", as the two W's is more accurate. --- Barek (talk • contribs) - 10:52, 27 February 2007 (EST)

I don't see why we need talk page shortcuts, they're only ever one click away from any other shortcut so they seem somewhat redundant. --NieA7 12:12, 27 February 2007 (EST)

I agree - but if others find it useful, I won't fight having them. However, I do feel that the prefix should be denoted as GWWT rather than GWT. The simple reason being that just having the one W results in GWT, and because of what GW refers to in many people's minds, the current prefix would denote either "GuildWiki Talk" or "Guild Wars Talk"; while this redirect is intended to point to a "Guild Wars Wiki talk" page. I just find the GWWT to be more accurate. --- Barek (talk • contribs) - 13:15, 27 February 2007 (EST)

I agree with you, Barek. I don't think we need them, but I don't think they are a problem. If they're useful to even one person then what's the harm? I do feel that it should be GWWT. GWT is confusing. LordBiro 13:17, 27 February 2007 (EST)

I don't think that talk page shortcuts are necessary at all. The shortcut to the main page can be used to easily access the talk page. If it is enought that 'they're useful to even one person', then I seriously want to make Gem redirect to my user page. That would make my life soooo much easier. I haven't done this or even thought about doing this before as I don't think that we should have a redirect and shortcut for everything that users come up with. --

(gem / talk) 13:44, 27 February 2007 (EST)

Gem, redirects don't use up much disk space at all, and help performance by reducing needs for searches and add convenience to users. I support LordBiro, if users find it useful, keep it. But, there are limits. Redirects to the User or Guild namespaces are notable exceptions, to me those should never exist from the main article namespace. The main question to me on this one is what prefix should be used as the standard. --- Barek (talk • contribs) - 14:04, 27 February 2007 (EST)

Sigh. This is a depressing brand of control freakishness. It is no wonder at all that everything is a mess around here. Ray McCooney 13:59, 27 February 2007 (EST)

It may also have something to do with this wiki not yet having all policies and guidelines in place, or the fact that it's not yet officially announced, or that not all required extensions have been installed yet. The wiki is less than a month old, you can't expect a smooth operation yet. Please use constructive arguments. --- Barek (talk • contribs) - 14:04, 27 February 2007 (EST)

Redirecting an article from the main namespace to a user namespace is something totally different. Gem, if you wanted to make U:GEM redirect to your user page then I seriously would not care, and I don't see why you would either. But really, it's besides the point.

I agree with Ray on the subject more than anyone. I really think that this is a silly discussion. I don't see the problem with having shortcuts to talk pages and I'm not going to support the removal of them. LordBiro 14:08, 27 February 2007 (EST)

I know when to give up. Seems like I'm the only one thinking like I am. :) Shouldn't probably be trolling here when I'm still ill. --

(gem / talk) 14:13, 27 February 2007 (EST)

*sigh* - deletion of the shortcuts is a silly discussion, and wasn't the intended reason for this thread. I would just like to see a standard format, and I would prefer GWWT over GWT. That is the sole reason that I brought this up. I honestly wish I had had not questioned their value, as that off-topic theme keeps pulling this from the intended discussion. Yes, I don't see a lot of use in them, but I have not argued for their deletion. If others want to argue that, please take it to another thread. So ...

For shortcuts to Guild Wars Wiki talk, what standard should be used for the shortcuts? GWT or GWWT? For reasons buried in the above talks, I support GWWT. --- Barek (talk • contribs) - 14:29, 27 February 2007 (EST)

GWWT. --

(gem / talk) 14:34, 27 February 2007 (EST)

My comment was meant to be more along the lines of "why bother having them, and if we have them why bother making a fus over them", but for what it's worth - GWWT. --NieA7 15:28, 27 February 2007 (EST)

Finalise

If there's not much discussion on this left, I will finalise it in another day or two and make it an accepted guidelines before the public announcement. -- ab.er.rant 22:08, 19 March 2007 (EDT)

Profession icon templates

Can someone edit them so the default behaviour is the Profession-icon-small.png and if you specify <code>{{w|big}}</code> or large, it uses the bigger one instead? I could do it easily if the large icons were named Profession-icon-large.png, but they aren't and I don't know how to use if. :( - BeX 07:47, 25 May 2007 (UTC)

Done :)

-- ab.er.rant

10:32, 25 May 2007 (UTC)

TYVM! <3 - BeX 11:28, 25 May 2007 (UTC)

Any profession versus unknown profession

I remember some talk a while back regarding the use of different icons for these two cases. I would like to propose that be used for unknown professions, and a modified for any profession. -- ab.er.rant 12:33, 21 June 2007 (UTC)

Reminds me of the "anyskill" icon on guildwiki, which proved very useful. Support. --Xeeron 14:20, 21 June 2007 (UTC)

Can you provide examples of where you feel each should be used over the other? I'm not sure I understand the benefit of two icons for this. --- Barek (talk • contribs) - 14:45, 21 June 2007 (UTC)

It was proposed a while back for the "common" armor bonuses. The blank circle better represents that any profession can use it, rather than an x signifying no profession. - BeX 01:30, 22 June 2007 (UTC)

I agree that blank better conveys in that situation ... but in what situation would "x" better convey the real meaning? If there's not one, then to me it seems simpler to just replace the "x" with the blank icon. --- Barek (talk • contribs) - 01:41, 22 June 2007 (UTC)

Yeah, unless there is something with no profession then. Maybe just pre-Searing Gwen hehe. - BeX 01:47, 22 June 2007 (UTC)

I wouldn't mind replacing the "x" with the "o", since I always find it funny to have a red cross mark before some NPC's name. It's like saying those NPCs are wrong or something. As for examples, I would've said that the "x" be used for those NPCs whose professions we don't know, and the "o" be used for equipment and skills where the profession doesn't matter. So it's a case of "don't know" versus "don't care". But since you mentioned it, I think it would be fine to just use the "o" for both cases. -- ab.er.rant

07:27, 22 June 2007 (UTC)

It could make a difference if you want to convey that there should be no secondary profession as opposed to any secondary. E.g. henchmen are Mo/x and not Mo/o. --Xeeron 13:49, 26 June 2007 (UTC)

But I could also say that henchmen are just Mo, and not Mo/something. -- ab.er.rant

06:06, 27 June 2007 (UTC)

So... are we good to go for replacing the x with the o? -- ab.er.rant 08:39, 6 July 2007 (UTC)

For the reasons mentioned above, I'd be happier if the o would not replace the x but be uploaded separately. Even with the o around, I still see uses for x. --Xeeron 10:10, 6 July 2007 (UTC)

I agree, they have two separate uses. Maybe Biro will make us a tango x too. :) - BeX

10:58, 6 July 2007 (UTC)

Self-linking to bold titles

This is a lightweight post. Why should we use '''Kenshi Steelhand''' instead of [[Kenshi Steelhand]] to bold the title of an article inside that same page. Here's the reasons I see: a) Because it's convention that most other MW wikis use. Should we do it simply because they do it? Dunno, but I'm not sure I'm happy with the idea of deviating from traditional usage for no actual reason. b) Because it is expected behaviour. In MediaWiki syntax ''' ''' means "Bold that for emphasis!", and [[ ]] means "Link the reader to somewhere else he can go!". Using the latter to mean the former seems incorrect and potentially confusing. A similar discussion has already taken place on this wiki, regarding how different notations can imply different contexts, and should thus be used appropriately.

I'm aware that these reasons are probably nowhere convincing enough for me to demand that others care about them; just mentioning them here with the hope that other editors at least don't go around "fixing" those uses where the syntax is used correctly, even if they themselves keep using self-links to bold titles. --Dirigible 10:05, 26 June 2007 (UTC)

I thought it was just me that thought linking to make bold made no sense... :P It makes sense in articles which are going to be included, since when included you want the link, it's not the bold part that's important. But in articles in general I never saw why we used self-links instead of bold. - anja

(contribs) 10:25, 26 June 2007 (UTC)

I've always edited any selflinks away and put bolding instead and I think that's what everyone should do. --

(gem / talk) 11:44, 26 June 2007 (UTC)

MediaWiki renders selflinks with <strong class="selflink"> instead of <b> which can help distinguish the subject of the article from other bold text if the user has a custom css or the browser renders it differently (although most don't). Also IMO, [[subject]] is more intuitive since you usually link to every new subject you come across, and if you are already here and don't need a link, then it emphasizes it. It's what I've always used. -Smurf 13:38, 26 June 2007 (UTC)

There is a small advantage for normal bolding in such that it is more intuitive while looking at the code. On the other hand, link-bolding has the advantage of the code working perfectly if you ever copy parts of code from one to another page. Tbh, neither reason seems important enough for me to change one or the other. --Xeeron 13:47, 26 June 2007 (UTC)

An argument that has been made in the past is that using [[self linking]] in articles means that if that article is included anywhere then the link works. LordBiro 16:15, 26 June 2007 (UTC)

Yep, which is why I'm the opposite of Gem's edits - I changed the bolds to self-links. The way I see it is that these are not for emphasis. They're highlighting the fact that this page is about whatever is being self-linked. So I look at them as being different than emphasis. (and I use italics for emphasis, which kinda explains why I don't see it as an emphasis). -- ab.er.rant

00:42, 27 June 2007 (UTC)

I think this issue is trivial enough to not deserve this much discussion, but I'd rather not leave this ending with three self-link supporters in a row, because someone is inevitably going to draw the conclusion that this is the right way and they'll come change my quotes to brackets again and I won't like it. My fault for opening a can of worms which we could have skipped, but I guess now we got to close it again.

Biro, I agree that this is a good example of how self-links can be useful, but we're not talking about pages in the Template namespace here. The articles in question would never get transcluded elsewhere.

Xeeron, when is the last time you copy/pasted the description of a boss to anywhere else on the wiki? For a similarly feeble reason from the opposite side, consider that if a page using [[ ]] to bold is moved, this mechanism would fail. Both of them are unlikely/rare enough to be dismissed as non convincing.

Aberrant, two questions: 1) What's the difference between emphasis and highlighting in this context? Note that bold is an universally accepted method of emphasizing text, together with italics. 2) Why are you using links to highlight? Doesn't that strike you as semantically weird?

Smurf, I can accept that using self-links may be more practical, but they're most certainly not more intuitive. In every wiki editing reference, you'll find that triple single quotes mean "Bold" and double square brackets mean "Link". How can something that doesn't behave as expected be more intuitive? Look at self-links turning to bold text as an example of failing gracefully, only to avoid having a cyclic link that points to itself (which would be even more confusing), not something to be used purposefully.

I also disagree with this practice of "linking to every subject you come across"; you use links to show the reader other subjects of interest, instead of applying them mechanically on every keyword. And if you are using links to show other subjects of interest, why would you point the reader to the page where he already is? Again, semantically it doesn't make sense.

I know people will keep using these self-links to bold; they keep doing that everywhere else, including Wikipedia where it's explicitly written in their Manual of Style not to do so. But at least don't revert those of us that do use this syntax correctly, that's all I'm asking for. --Dirigible 04:06, 27 June 2007 (UTC)

Hmm... rather than trying to argue which is better or more appropriate, is there any reason why we need to bold the name of the article in the first place? I started using the self-link because of all the [[{{PAGENAME}}]] strewn all over GuildWiki. --The preceding unsigned comment was added by User:Ab.er.rant .

I do it because of gwiki and wikipedia, but I know theres a history in dictionaries and encyclopedias to do it. - BeX

04:33, 27 June 2007 (UTC)

I do not support or oppose the use of either method, but I was not talking about templates in my post. While it is less widespread here, there are instances on GuildWiki where articles are included into other articles. With DPL we might start including sections into other articles. In these instances using links would make more sense. LordBiro 10:29, 27 June 2007 (UTC)

In response to your question, I do remember copying parts of articles over. Not 10 times a day, but every now and then. Of course not boss descriptions, but mostly policy articles or guides. --Xeeron 11:22, 6 July 2007 (UTC)

Reviving an old talk, I know, but since it seems to be agreed on ... I will try to go with the consensus as I currently do. Also, a point I want to bring up. It seems like on the wiki as well as others that they all prefer . I think and to believe the reason to this is to keep from having any 'self links'. This article [w:Self_link here] was a rather interesting one to read. It seems there, they're more into the bolding and not the 'self linking' either. This was a good discussion and I do agree with the consensus that was made up here. --

riyen ♥ 04:26, 2 December 2009 (UTC)

Credits in articles

As mentioned at GWWT:GUILDS#Credits on Guild pages ... it seems appropriate to add an entry on the guide here whicht mentions something along the lines of "The History tab provides all contribution credits for the page, do not include them in the article text." As Rezyk pointed out in the other discussion, doing so provides visibility and more solid acceptance. --- Barek (talk • contribs) - 04:15, 12 July 2007 (UTC)

Concur.

(Aiiane - talk - contribs) 04:16, 12 July 2007 (UTC)

I agree the history tab is enough. --Sktbrd341 04:34, 12 July 2007 (UTC)

One sticky point is that history doesn't always cover all the credits. This would be especially important when getting technical with the license. For example, one might copy text from another GFDL source without properly attributing it in the edit summary -- not to be encouraged, but how is it fixed? A basic solution might be to point to the talk page as a secondary place to note proper credits when history does not cover it. --Rezyk 04:40, 12 July 2007 (UTC)

Thats a good point with copying from another source. Also the solution to put it on the talk page is the only logical solution as of now. --Sktbrd341 04:47, 12 July 2007 (UTC)

Citing a reference in the article (ie: (much like is done on Wikipedia - having a reference number next to the material in question, and a reference section at the bottom of the article with a link to the source) is another solution. --- Barek (talk • contribs) - 14:51, 12 July 2007 (UTC)

The formatting guideline should make clear the distingtion between a reference (attribution to someone else for material already avaible elsewhere) and a credit (attribution mainly to oneself for creating new material here). --Xeeron 15:12, 12 July 2007 (UTC)

Things for a new revision

No credits in articles, unless referencing an GFDL source (how to do this?)
Self bolding/bolding first instance of the article name
Remove the capitalization stuff because GWW:NAMING is official
Article descriptions should not repeat information that is included elsewhere in the article
Add mention of {{sic}}
Allow additional wiki-link repetitions if it is separated from the first instance

Anything else that anyone has noticed? - BeX 04:47, 15 July 2007 (UTC)

Add mention of {{sic}} and for wiki links, might want to allow for a second link to the same article if it appears several sections aways from the first link. -- ab.er.rant

02:44, 16 July 2007 (UTC)

Remove the profession stub, it's currently up for deletion. :P - anja

09:11, 16 July 2007 (UTC)

Should a note about blanking talk pages go here or elsewhere, because it's more of a policy thing? - BeX

04:56, 30 July 2007 (UTC)

Because the general feeling seems to be that talk page content must be retained, I feel they fit better into GWW:CONTENT than in a formatting guideline. -- ab.er.rant

06:24, 30 July 2007 (UTC)

Flavor text

What is everyone's opinions on the "flavour text" being used as section 0 on most pages? Some prime examples are Azure Remains and Mursaat Token. I think those two examples are well written and creative, and definitely more interesting to read than nothing or repeated information. However, I'm unsure of whether they should be there or not. I think any writing like that should have some sort of reference in official canon if it is going to presume things about other people or NPCs, etc. So what is better to have: flavour or accuracy? Can a balance be found between both? - BeX 09:35, 16 July 2007 (UTC)

The flavour stuff is pretty cute, even if it may not be canon - I'd be in favour of keeping it so long as it doesn't hurt in some way (scamming comes to mind). --NieA7 10:41, 16 July 2007 (UTC)

I'm a bit biased since I really like those flavor texts : P But I agree with what Rangerjherek said - as long as the text does not hint on something that would have a gameplay impact (he made an example of how he would write that Azure Remains are fragile, but then he realized how people would then think they would risk spontaneously breaking), I think it's ok to take some "artistic freedom". If anything, the section 0 of most pages is too bland, this kind of thing helps to make them more pleasant to read. Erasculio 11:04, 16 July 2007 (UTC)

Are you asking whether we should specifically mention them in the guidelines? I certainly don't mind the stuffs that Rangerjherek so nicely worded, but I think we don't need to specifically mention "flavour text" in the guidelines. We can have a section about the introductory text that just says a short description, explanation, or summary of the topic in question is needed (and leave it at that). -- ab.er.rant

11:48, 16 July 2007 (UTC)

Well its more about speculated content than anything else. - BeX

11:49, 16 July 2007 (UTC)

Personally, I think an article feels more polished when the intro says something more interesting than "Hamish is a merchant, an NPC who sells items." or something like that. The infobox already tells us he is a merchant, any link that points to the article looks like Merchant: Hamish, at the bottom of the article is the category for Prophecies merchants, and the reader probably just saw the words "Hamish [Merchant]" in the game before searching for the article. Also, anyone who doesn't actually know what a merchant does will either figure it out from the article body or click on the link to the merchant article. So I try to say something a little less mechanical.

That being said, it is important to stop short of actually trying to add information to the game. With the Alpine Seed, I was tempted to open with something like "Plant creatures across Tyria reproduce by dropping seeds in fertile ground. In some cases, they may carry these seeds inside their bodies for some time before dropping them. If killed during this time, they will reflexively drop their seed upon their demise." and then go on to the alpine seed specifics that are there now. While probably harmless (since no one could draw false conclusions from this, as with the Azure Remains point from before), it crosses the line between an interesting read and false/speculative information. There is no indication in game canon that this is why (or how) plant monsters drop seeds, nor is there any explanation for the plants' reproduction, so I left it out. (It probably would have made the section too long anyway.)

As far as speculation goes, I do try to use existing information to draw some logical conclusions. I've added some comments to the code in the article on Viggo, if anyone would like an example of what I mean. Another example is Kegai: I wrote his intro based entirely on his in-game dialogue.

The Mursaat Token was a special case: the intro text is far longer and more speculative than should be the norm, but I figured that's okay since the item has no in-game use, and none of the information is actually misleading. The article just seems more complete this way. If some use for Mursaat Tokens is introduced later, I would recommend shortening the intro text considerably, and changing it to reflect the change in the item.

I also agree with ab.er. I don't think there needs to be rules for this stuff in the formatting guide. At the most, maybe a comment to avoid simply rehashing the technical aspects of the item/NPC/whatever. Maybe a short article giving advice on writing the intro text would be okay too, but I'd stay away from any hard-and-fast rules.

Man, I talk too much! :) Jherek out.--Rangerjherek 15:17, 16 July 2007 (UTC)

I personally really like those kinds of less laconic descriptions, but there's certainly users that don't. See User talk:Fox/Archive 2#Style and Edits for some arguments against them. Some examples of the well written intros in question are Dragon's Gullet, Tar Behemoth, Diessa Lowlands (all of these descriptions have been removed from the current revisions of these articles). --Dirigible 15:38, 16 July 2007 (UTC)

As a die hard roleplayer I love stuff like this! --

(gem / talk) 16:55, 16 July 2007 (UTC)

It's probably the DM in me that compels me to put this stuff in in the first place. BTW, I just edited all three articles Dirigible cited just above. I know that wasn't the point he/she was trying to make, but there you go.--Rangerjherek 20:21, 16 July 2007 (UTC)

(reset indent) Okay, I should restart this section because it's not the flavor text that is the problem at all, it's just the speculation. We don't have any policy or guide that says speculated content isn't allowed (it can lead to problems like 100 instances of unconfirmed trivia on the Inscription article). I once suggested that a project be set up for confirming trivia, so that only confirmed instances would be put into an article (confirmed by an ArenaNet employee whether on this wiki or somewhere else). See Talk:Inscription#Trivia. If I were to find a piece of flavor text that had clear and obvious speculation in it, I could remove or reword it, but I have nothing that backs me up on my reason for removing or rewording it, which is what I am really looking for. - BeX 02:38, 17 July 2007 (UTC)

Given that most flavor text would be pure speculation, we'd need to first confirm that we do allow flavor text. I think we need a bit more feedback on that. After that, we can try to define exactly what sort of speculation are allowed. -- ab.er.rant

02:44, 17 July 2007 (UTC)

But if you can base your flavor text on collector dialogue (the ones that actually say why they are being collected) or other dialogue like the Chefs from the Festival of the Pig, then it wouldn't really be speculation. It just depends on phrasing and source. - BeX

03:00, 17 July 2007 (UTC)

I would suggest adding a "soft" note against speculation (something like "Try to avoid filling articles with speculation - when possible, confirm speculated trivia through official sources") and then go on a case-by-case review of what would be allowed and what wouldn't. Again, I'm being a bit biased here (I really like those small bits of text, and personally I don't mind some speculation if it couldn't lead a player into making in-game mistakes), but that kind of statement would open a way for edits removing speculation without completely forbidding it. Erasculio 03:10, 17 July 2007 (UTC)

I'm with Erasculio. There's no need to make a big deal about this. Just write an intro that describes the item (or whatever), stay on topic, and use a little imagination to spice it up if it's too dull or mechanical. Just be sensitive to spoilers, and be careful not to say anything misleading, even if it seems harmless. Saying that Azure Remains are prized by collectors for their exquisite beauty is okay; saying that they are so delicate that they must be handled with care is not. Also, don't be too quick in assuming that what you are reading is speculation. My whole point in linking to Viggo and Kegai was to show that what might seem like unfounded speculation at first may actually be well-supported within existing game literature.

The purpose of the intro is to describe the noun in question, and that requires a certain amount of "flavor text." A placeholder like "Daved Logsdon is a collector, a type of NPC that exchanges trophies for weapons" says nothing about Daved Logsdon (although it does summarize what a collector is, a topic already covered by this article), and ultimately leaves the article as unfinished as it would be if nothing was there at all. Remember, we're not writing legal documents, we're writing reference documents. If saying that "Daved Logsdon gathers Abnormal Seeds from around the lakes in the Tears of the Fallen" counts as speculation, then I think the definition of speculation we are using is too narrow; after all, Daved Logsdon is collecting Abnormal Seeds in the Tears of the Fallen, and is standing next to a lake. (BTW BeX, I'm not trying to start a feud with you or anything; your recent edit of Daved Logsdon just makes an obvious talking point. For real. Not a fight :)) If we were to take that extreme position (not that anyone is, that I know of), then I would argue that we don't need an intro section at all, since there would be nothing of value to put there.--Rangerjherek 23:22, 17 July 2007 (UTC)

Putting his location and what he collects is a repetition of already listed information, which makes the subsections redundant and is generally discouraged. Explaining what a collector is, while boring, isn't included in that article, which makes it slightly better to include than redundant information. That being said, any sort of "flavor text" is much superior to both to read, but only as long as it is not based on speculation. And no worries about a feud, I know what we have here is just a slight difference in opinion - as I've said before I do like your descriptions and they are a hell of a lot more interesting than what I put, but I'd rather the wiki be accurate and boring than speculative. I just don't know how to find a balance between the two, hence needing more opinions on the subject. :P - BeX

05:02, 18 July 2007 (UTC)

Flavour good. Making up 'facts' bad. My opinion. Backsword 19:40, 20 July 2007 (UTC)

The advancement of user created speculation in wiki articles seems very worrying to me. I have nothing at all against nice introductions, as long as they are based in ingame facts. There is a lot in there (for example in the texts you get when talking to collectors) which could be used, but I am strictly against "making stuff up" to spice up the intro. --Xeeron 09:32, 30 July 2007 (UTC)

Profession-stub

The {{Profession-stub}} template is not currently in use, and (as there are no new professions coming out in GWEN) will never be =P Can we remove the Profession stubs section? That template is up for deletion, but I didn't want to add another link to genform when I did so. MisterPepe talk 06:45, 18 July 2007 (UTC)

Anja made a note of that in the section above. :) - BeX

06:55, 18 July 2007 (UTC)

Trivia

I was pointed here by Kurd who suggested that i register and make my argument here, instead of a random skill's page. The argument goes as follows:

Look, i have a serious problem with people and their 'need' to give everything a trivia reference to whatever. Now even though people 'may not have heard of the sum of all fears', doesnt mean they want to know, afterall this is a wiki for guild wars where people want information on said game. If any other people feel the same way and want the trivia bit in this section removed, speak up. Now i know i making a big deal out of one page, but i am hoping this will start to wake people up and remember what this wiki is all about.

Now i was talking about this on the skill Sum of all Fear's page, but i stress that i am talking about ALL pages in this wiki! i also stress that this is NOT a wiki about films/ other games/ culture and their references in guild wars, but a wiki about guild wars and guild wars alone. I wish to hear what people feel about my point, and if you do feel the same way, i would like a formatting rule to be passed about strict placing of trivia and removal of completely unnecessary and irrelevant pieces of trivia. Man of Steel 08:41, 25 July 2007 (UTC)

I think I heard this argument before... can't recall where. My thinking hasn't changed yet. But I'd like to ask you to clarify this: "about strict placing of trivia and removal of completely unnecessary and irrelevant pieces of trivia". What exactly are you saying? I don't understand that part about "strict placing". All trivia go into the trivia section... how's that not strict? And if you're suggesting total removal of all trivia, I'm against it. Remove vague and hard-to-believe trivia? That doesn't involve changing the guidelines. -- ab.er.rant

10:18, 25 July 2007 (UTC)

Okay,i see that i may have been too aggressive, and i see that im not going to get trivia removed forever, but i at least ask whether people would want to see the removal of the trivia thats vague and hard to believe, as you mentioned. I'm fine with the trivia that is confirmed (i.e. sum of all fears) but im not so happy with the trivia pieces that start off with 'This MAY be a reference' in which case it could be a reference to absolutley anything. —The preceding unsigned comment was added by Man of Steel (talk • contribs) 10:53, 26 July 2007 (UTC).

Then you have the same problem as I do: I don't like speculation on the wiki! I once suggested a project where the Anet team can confirm trivia for us, and then only confirmed trivia gets included in articles, but it never got off the ground. :P - BeX

08:55, 26 July 2007 (UTC)

Such trivia is already removed when spotted. As an example, ovserve the removal of the claim that one of the EotN skills name was based on a song by some obscure band here. Backsword 10:37, 26 July 2007 (UTC)

In my opinion trivia should stay, and if there is a claim of uncertainty of its source, we go to Emily. If it is confirmed, it stays, if it is denied, it's removed. Usually Emily is quite quick to answer questions on trivia, so having the incorrect trivia on the page will only be a matter of days.

I do agree that really vague or obscure trivia can be removed and a reason for removal placed on the talk page (to circumvent a revert war). I do realize that some people have different opinions on really vague and obscure, but we can't have it all I guess. --

(CoRrRan / talk) 10:46, 30 July 2007 (UTC)

→ moved from Guild Wars Wiki talk:Formatting/Skills

Due to the recent ~~arguments~~ discussions about what is/isn't a reference (see Talk:"Finish Him!"), I propose that barring word from an ANet employee that if the community comes to a conciseness about a skill being a reference to something that it may be included until disproven.

Discuss. - HeWhoIsPale 20:32, 15 August 2007 (UTC)

How about don't include until proven? ~ Kurd

21:27, 15 August 2007 (UTC)

I'd rather have it included, it's fun to read about and doesn't really do any harm. Besides, it may take long before Emily has time to confirm. - anja

21:30, 15 August 2007 (UTC)

I think we should include any trivia deemed plausible by rough concensus on the talk page. -- Gordon Ecker 21:40, 15 August 2007 (UTC)

I agree with Gordon. As long as the language used matches the certainty of the information (i.e. don't use language that states something as a fact if it's not a near-certainty), there's absolutely no harm in allowing it. In fact, even if the reference isn't something that ArenaNet states is intentional, it's quite possible to include unintentional references, and there's no reason not to mention similarities to pop culture or the like.

(Aiiane - talk - contribs) 21:49, 15 August 2007 (UTC)

There are three types of Trivia:

Curiosities, Easter eggs, etc...
Obvious References, like many quotes in dialogs, quest names, shouts, inscription names, boss names, etc...
Shadowy references. This one is the type we shoud avoid. They are things like "it reminds me of" or "it is very similar to".

MithranArkanere 22:08, 15 August 2007 (UTC)

Agreed. It's the shadowy and vague ones that are usually the points of contention, so if it's nowhere near borderline obvious, then it should be removed. But only remove them if you yourself are familiar with the subject in question. I would oppose any removal of trivia simply because you haven't heard of it or don't know about it. Like Anja, I find certain trivia nice to read about too. What I find a bit weird is that we're actually bothering Emily to confirm things as ... well... as trivial as trivia. -- ab.er.rant

02:23, 16 August 2007 (UTC)

She did offer a while back to confirm trivia if she had time to. :) - BeX

03:32, 16 August 2007 (UTC)

Perhaps a special page with unconfirmed trivia would facilitate that? As a parallel to unanswered questions for lore. Backsword 04:35, 16 August 2007 (UTC)

The common use of "weasel wording" in trivia sections bothers me tho'. I'd prefer if we stuck to the known facts. If the facts are not enough to warrant a mention, it shouldn't be listed at all. Normal editorial practise is enough otherwise. Backsword 04:42, 16 August 2007 (UTC)

Profession capitalization

What's the official word on professions, capitalized or not? I'm guessing not, but it's capitalized in lots of places. --Heelz 06:21, 30 August 2007 (UTC)

As a general rule capitalize only proper nouns (a noun decribing a unique entity, such as a name or a city). - BeX

08:54, 30 August 2007 (UTC)

Well, there's lots of capitalized professions that need a-changin'! --Heelz 10:01, 30 August 2007 (UTC)

Have fun with that! :P - BeX

10:14, 30 August 2007 (UTC)

PC Gamer information

Does anyone have any idea about what to do with the information coming from the PC Gamer magazine about GW? From what I have read mentioned in forums and alikes, the article has many bits of information, including things that would be better suited for new articles (as opposed to just adding things to the current ones). I would guess that we would be allowed to make those articles as long as we don't quote directly the magazine, but should information about GW2 features be in the same page as the GW1 information? Say, the news about the fate of Ascalon - should that be in the article about the current city? I'm asking mostly thanks to a vague talk, months ago, questioning whether it would be better to use this wiki for both games or to have two wikis, one for GW1 and one for GW2. Erasculio 22:44, 23 September 2007 (UTC)

Maybe it's time to bug ArenaNet about that GW2 wiki again? --Dirigible 22:45, 23 September 2007 (UTC)

Thanks for the link, I was trying to remember where that discussion took place but I couldn't find it : D Erasculio 22:55, 23 September 2007 (UTC)

Guild Wars Wiki talk:Formatting/General/A1

Contents

Speculative or unknown information

Capitalization of section headings

Profession order

Introductory text

Stub template locations

Unreliability warnings

Table of Contents

Feeding the fire - the TOC discussion continued

The TOC float-right sub-issue, an alternate choice

Wiki links

Dialogues

Skill page formatting

Use of Shortcuts

Categories

Finalise

Profession icon templates

Any profession versus unknown profession

Self-linking to bold titles

Credits in articles

Things for a new revision

Flavor text

Profession-stub

Trivia

Profession capitalization

PC Gamer information

Navigation menu

Page actions

Page actions

Personal tools

Navigation

Search

support

Tools