Guild Wars Wiki talk:Formatting/General

Archive

---

Archive one
Archive two

Underlinking in Zaishen quests

I generally like the idea of reducing the number of links to the same article. That said, in the Zaishen challenges, shouldn't we link at at least the first instance after the ToC? Especially in the bounties, the initial link appears above the TOC and is almost invisible. The first after-TOC link will always say, Kill [the boss] in [the zone] and reads more prominently than the link above the TOC.   — Tennessee Ernie Ford (TEF) 03:55, 7 August 2009 (UTC)

I agree (and came here to post something similar). IMO, that line in the guideline should read For each section, it is preferable that only the first instance of a particular term or name be made a wiki link. That way we still avoid the multiple links line after line, but you don't have to scroll up to find where the previous instance was actually linked. I wouldn't limit the change to the Zaishen quest pages, though, as in longer articles you can see how it would be an issue if something were linked at the top, then had another reference in the Notes section. --Freedom Bound 18:10, 7 August 2009 (UTC)

I don't mind this change as it would it appears to be the case on many pages already anyway. -- ab.er.rant 14:30, 12 August 2009 (UTC)

I agree, though resetting it every section would be a bit too much. I think it's fine to reset it after longer visible breaks (such as tables or TOCs). poke | talk 15:37, 12 August 2009 (UTC)

I like Poke's idea, but I think FB's suggestion is easier to implement/maintain. The nuanced policy might look something like...

• all pages: the first link in the opening paragraph, the first link after a TOC
• dialogue: the first link after any dialogue section (as those can occupy an entire screen)
• tables: the first link in a table; for tables longer than 10 rows, the first link after the table

So, I prefer something simple (e.g. first link after each section) and then review later to see whether it needs tweaking.   — Tennessee Ernie Ford (TEF) 17:05, 12 August 2009 (UTC)

Of course that would be easier, but it would basically destroy the actual purpose of that rule.. We have many articles with multiple short sections, by linking everything in each section you could just drop the rule at all. So I would prefer something that's more like the current for, just with minor exceptions. And as this is a guideline, it is not needed to give a step-by-step ruling for this. Changing the current for to something like this would be enough in my opinion: "[...] Subsequent linking of the same term or name should be avoided, unless it would ease the text flow. [...]" poke | talk 17:14, 12 August 2009 (UTC)

should be avoided...unless... works for me.   — Tennessee Ernie Ford (TEF) 17:58, 12 August 2009 (UTC)

Works for me, I think that adds a reasonable amount of flexibility. --Freedom Bound 18:32, 12 August 2009 (UTC)

Works for me also. --Silver Edge 20:06, 12 August 2009 (UTC)

Change done. poke | talk 07:33, 13 August 2009 (UTC)

Rather than per section it should be less tied to technical limits and thus more like per text that will be read as a together. Backsword 18:09, 13 August 2009 (UTC)

I don't see why these pages should be treated any differently than any other quest page (consistency across the wiki), ie. only link the first instance of a term on the page. If the link is being lost because of the TOC, I'd prefer to see the TOC removed, considering how short most of these pages are anyway, a TOC is simply unnecessary. -- Wyn talk 23:23, 26 August 2009 (UTC)

I would be in favor of removing the ToC on short articles generally or just the challenge articles alone. However, I prefer a link-once policy that leaves room for editorial judgment; wikis should never ask readers to search for a link. This prevents the need for policy exceptions for individual or categories of articles in which the links might be less prominent.   — Tennessee Ernie Ford (TEF) 01:11, 27 August 2009 (UTC)

I linked this discussion on Talk:Zaishen_Bounty#proposition:_see_above_section since they are somewhat related, and I wanted more input. -- Wyn talk 01:32, 27 August 2009 (UTC)

Here's my input, then: This (too few) is wrong - the first and most obvious usage after ToC is not a link but the out-of-the-way usage under Walkthrough is instead, for some reason (in fact, the only non-over-ToC link isn't even directly to the accident). This (too many) is wrong - it's lousy with linkage even though with 5 there, the 2 or 3 least obvious will never be followed. This (golden standard) is right - no link is doubled except the first most obvious use below ToC. This (justified exception) is right - Poisoned Outcrops is linked twice, but referring the reader to the location, not the boss, I think warrants not going back up to a link which is not also the article name... I may have worded that wrong, but try it without the link in Walkthrough and I think you'll agree it's unwieldy.

I can rewrite that in "rule" wording if you like. - 72[evolved] {U|S|T|C} - 02:07, 27 August 2009 (UTC)

No, I just want people to be aware that 5 links to the same thing on a page is too much, and doesn't really follow the guideline even as it's written now, and wanted to bring up the option of removing the TOC on the short pages, (since that is a standard practice that seems to have gotten lost on the Zaishen pages). And we were all talking about the Zpages. -- Wyn talk 02:15, 27 August 2009 (UTC)

What do you think of Verata_(Zaishen_quest) without the TOC, and the first instance bolded? -- Wyn talk 02:24, 27 August 2009 (UTC)

Not really sure I think the bold is necessary, but it does look a lot better without the TOC. I don't think the policy even really allows for those obviously overlinked one, at least, that was not my intention above. I just wanted there to not be a necessity to scroll half way up/down a page to find where the last linked instance was. -- FreedomBound 02:34, 27 August 2009 (UTC)

It works well enough. I assume there might be exceptions (say, if the walkthrough says, "See the [ [thatboss#notes|Notes] ] page"--though it shouldn't often). There is a bit of probably negligible scrolling on that one, and I predict moreso on longer articles too. (Shorten them all via replacing 70 duplicate dialogue sections with links to ZB Dialogue section? :P) - 72[evolved] {U|S|T|C} - 02:38, 27 August 2009 (UTC)

Having now read Freedom Bound's post, I note that I like the replacement bolding - in fact I'm pretty sure that's cloesr to our policy on bolding the first usage of the subject of the article in the article (not sure, though). - 72[evolved] {U|S|T|C} - 02:40, 27 August 2009 (UTC)

Well, you will see on the Verata page, I left the links in the walkthrough notes. I'm not wanting to strip everything, I just don't see it needed in every section, on every instance (like Admiral Kantoh's page), and bolding the first instance of the subject of a page is a standard practice as well, just normally that instance would not show as a link, simply bold because it would be the page name. (example Royal Chef Hatundo) -- Wyn talk 03:01, 27 August 2009 (UTC)

That's bolded because it's a self-referential link, in an NPC page. The link on these pages doesn't necessarily have to be bold because it's linking to a different page. In looking at a few random quests (like Faded Memory or Identity Theft) there doesn't seem to be a pattern on whether the first instance of an NPC is linked or if the first instance in the objectives is linked, but in most cases, it's never linked both times, and I haven't seen one that's bolded. -- FreedomBound 12:07, 27 August 2009 (UTC)

(As far as I understand it, bolding wouldn't occur in those unless it used the article's title (in any form) in the text. "Identity Theft" is not technically an article about Shatam, but it might say that he was "complaining of a case of identity theft." Breath of Fire for some reason bolds it accordingly, but Fire Storm doesn't under the exact same conditions (probably just an inconsistency). - 72[evolved] {U|S|T|C} - 13:48, 27 August 2009 (UTC) )

(Reset indent) If the Zaishen quest pages started out "Complete <ThisBoss>_(Zaishen Quest)", it would make sense to have them self-referential, which is where the auto-bold comes in (just like your signature will have a bold, black statement rather than a link to your talk page if you sign on your own talk page). These don't, it's a link to a separate article, so I don't think it needs to be bolded. That being said, I have no particular objection to bolding it, if that's what most people think would be useful. Since it is a different article being linked, though, the formatting still won't really match other, self-reference articles, since that text, by virtue of being a self-referential link, is also non-hyperlinked, and thus, black text. -- FreedomBound 14:01, 27 August 2009 (UTC)

Trivia

Would it be possible adding something along the lines of:

"Trivia sections may be added to articles as long as there is a verifiable source, or if the reference works within the context on which it revolves. Trivia based only on name similitude should be avoided."?

This, as to prevent the many "added because i looked on google and this was the first result" trivia that pop from time on time.--Fighterdoken 22:38, 15 September 2009 (UTC)

Regardless, the only way to really decide (short of asking the devs, which is lolgoodluck) is to discuss it, so I don't really see the point of adding such a provision. – Emmett 22:44, 15 September 2009 (UTC)

You mean, besides the fact that people don't discuss, add, and then others remove, and then a revert war begins? I would love it if all trivia could be "discussed" before being added, but that is hardly the case.--Fighterdoken 03:20, 16 September 2009 (UTC)

"If only we all had the same upbringing and common sense!" ... not. Sadly, everyone's high-familiarity-level is both with the mainstream and the unknown, and we (they?) can't distinguish between two things that make equally strong impressions on us; on the other hand, some devs have the same issue and we end up actually getting obscure references as weird as the ones we claim are in there. :( | 72 {U|T|C} - 11:43, 16 September 2009 (UTC)

What good would it do? Those that add such trivia would not read guidelines first, anyway. Just revert with a request for source: they won't have one. Backsword 11:50, 16 September 2009 (UTC)

There are no rules, trivia is based on, so it would be bad to have rules what is required to add such trivia information. Same with everything else: Make your edit and discuss if necessary. poke | talk 16:51, 16 September 2009 (UTC)

I think it would be useful to have some guidelines. I don't mind that some trivia is, well, trivial. I mind that sometimes it's not even trivia. This creature might be named after... seems to waste the space. What about something along these lines:

• Use a brief, assertive sentences to describe the reference. Do not comment on developer intent, unless you can site a reference (or have outside confirmation of the association).
  • Good: An Aneurysm is a localized blood filled bulge in a blood vessel; most commonly found in the artery at the base of the brain.
  • Good: Tesla was named after the wiki user of the same name.
  • Bad: Sparkfly Swamp might be named because of the fireflies (made from sparklers) that inhabit the swamps in the Disney ride, "Pirates of the Carribbean."

I don't have a preference for the details of the guidelines. I do want to make it easier for those who read the formatting articles to use language that will stand the test of time. Also, I hope that examples and guidelines will help resolve the inevitable disputes that seem to arise (perhaps because a trivia bullet is frequently a newer user's first contribution).   — Tennessee Ernie Ford (TEF) 10:34, 17 September 2009 (UTC)

Trivia is just that, Trivia. It has no bearing on the functionality of anything. I would agree with a single revert and a request for a source, especially if it indicates developer intent, however if it gets put back without a source, rather than some stupid revert war, just put a disputed tag on it and try to find a source. As Backsword said, people who put meaningless trivia on pages don't read guidelines, so having them won't matter. -- Wyn talk 10:44, 17 September 2009 (UTC)

Reverting someone adding trivia just because they don't have a source credit is overly ridiculous. It isn't like whoever posted it is intending that it be taken as game gospel. Many times, they might not even have a source for the information because the "source" might be nothing more than their own memory. Just because there is no attributable source doesn't mean it isn't valid trivia.

I have gotten into discussions with people in real life, and had some weird (but accurate) information that was only slightly related to that particular discussion. I don't always remember the specific book or story, or whatever I got that information from. It doesn't automatically mean that information is incorrect, just because I can't quote source specifically.

Besides, we cannot (unless the person adding the trivia is the one who made the name for example) tell for sure what the particular person was thinking of when that name was made. The "possibly" remark in the trivia post could be there, and the actual programmer/designer/etc could see that and edit that comment. Without it there, they wouldn't think to post it. Or, someone else who does know a source reference could see that, and add that. Once again, if the comment isn't there, they might not think to add that themselves. 42 - talk 04:03, 10 December 2009 (UTC)

Shouldn't this wiki still have a standard for deciding whether something is accurate enough or likely enough to be in the trivia section? I'm a huge fan of trivia, in real life and in game...which is why I strongly believe that it's important to have a source...or to phrase it so that sourcing is unimportant. I prefer, for example, Tennessee Ernie Ford is the name of a famous gospel singer over TEF might have taken the name from the fantabulous gospel singer of the same name — the first is a fact from which readers can draw their own conclusions; the second is an unverified (and sometimes unverifiable) guess. The first kind is also easy to source; the second kind only gets sourced if the particular group of people involved in naming (or creating) are available to sate our curiosity.

I'm pretty much okay if sometimes the source is going to be second-hand (e.g. I heard Gaile say it in-game, but I didn't take a screen shot). I'm happy to assume good faith unless someone has counter-evidence of some sort.   — Tennessee Ernie Ford (TEF) 07:25, 10 December 2009 (UTC)

Time Zones

Having just run afoul of an apparently oft-discussed topic (which as a newbie, I didn't realize — sorry), perhaps some sort of clause should be added here? Something along the lines of: Times (e.g. Festival events, etc.) should be given in twenty-four hour format in Pacific time – PST or PDT as appropriate – and in UTC. No other time zones should be given, nor should any sort of conversion chart be added. perhaps? --DryHumour 17:34, 31 October 2009 (UTC)

I concurr. I thought we added it last time, but i guess we all forgot about it.--Fighterdoken 17:44, 31 October 2009 (UTC)

Rephrasing: "Times, such as those for festival events and bonus weekends, should be presented using the twenty-four hour format and only in Pacific time (PST or PDT as appropriate) and UTC. The following information should not be included: other time zones, time zone conversions, explanation of time zones, explanations of daylight savings time. For events that have hourly or 3-hourly schedules, the article should include use of the {{Event Timer}} template.".

If it's appropriate, we should include the reasoning, "This policy helps keep event pages clean, so that the details of the event are not hidden behind explanations of time zones that are available elsewhere. We use UTC as a universal standard; we use Pacific Time because ANet uses it."   — Tennessee Ernie Ford (TEF) 17:56, 31 October 2009 (UTC)

Both of those suggestions sound pretty reasonable to me. --DryHumour 17:58, 31 October 2009 (UTC)

I have created Help:Timezone conversion chart I think linking to there on event pages while maintaining the two standard time zones should be enough. Not everything needs to be spelled out in a guideline or policy, if it is common practice, based on community discussion and consensus. -- Wyn talk 15:18, 1 November 2009 (UTC)

The problem isn't so much the conversion — for which we should probably just link http://www.timeanddate.com/ given the vast number of different civil jurisdictions involved — but that newer users will have no idea that the outcome was the result of some form of consensus. (That's actually what got me into this whole mess in the first place, and apparently it happens every festival.) Also, judging from the discussion below and on the Talk:Halloween 2009 page, the remaining issues are now revolving around formatting (colours and so on). I'd strongly suggest that some sort of guideline be provided and an HTML comment pointing at it be added prior to each festival table. Better still, perhaps roll the whole thing into a template (preferably with auto-updating for periodic activities, which would obviate the need for anything more than an ?action=purge rather than repeated edits). --DryHumour 16:49, 1 November 2009 (UTC)

(Reset indent) I've put together an example of what I was thinking of at User:DryHumour/Sandbox/Event timetable. --DryHumour 23:48, 22 November 2009 (UTC)

I personally think it's brilliant, though the colors leave something to be desired :P -- Wyn talk 08:27, 1 December 2009 (UTC)

I don't have any strong feelings about the colours (or any shred of artistic talent, for that matter ). I used the lightgreen and lightgray lightgrey row colours which had apparently been used historically; using the event's predominant colour for the headline was my – probably failed – attempt at promoting visual page unity. (Did I mention I have no artistic talent?) I'll add a plain white example for comparative purposes. My main motivation is to provide something that will provide trouble free timetables without the need for continuous editing (and the inevitable enthusiastic addition of time zones by poor misguided fools like me…). --DryHumour 15:35, 1 December 2009 (UTC)

I should also note that, anticipating the need to make the colours easy to change, the template was explicitly written to make it easy to change the colours: they are all defined right at the start. --DryHumour 15:42, 1 December 2009 (UTC)

(Reset indent) I've updated the Wintersday example to use the same colour scheme as that in Wyn's sandbox. (There's still the question of what to do for the row colours. The ones there now are just the historical ones.) --DryHumour 23:31, 14 December 2009 (UTC)

I actually prefer the timetable to not be "colored" I like the plain white header version the best and would recommend it be used universally on event pages, rather than have different colors for different events. While the main page might get "decorated" for various festivals, I don't see a need to carry that to articles. -- Wyn talk 23:56, 14 December 2009 (UTC)

I like the white one the best. I think we should also keep to consistency and not use those others, however they are 'cool' looking, but not 'appropriate'. -- riyen ♥ 00:03, 15 December 2009 (UTC)

I'm certainly fine with that if that's what folks would like. I propose leaving the variables and whatnot in place, though, but hardcode them to be plain white header with black border. I'll leave the multi-coloured examples in my sandbox for now to allow any other interested parties to comment. --DryHumour 05:08, 15 December 2009 (UTC)

(Reset indent) I've implemented {{Event timetable}} based on the feedback received here. Thanks to everyone who participated. Further improvements can, as always, be discussed on Template talk:Event timetable. --DryHumour 16:12, 17 December 2009 (UTC)

Final Tables Format

Time Zones

Read: GWWT:GF#Time_Zones

Colors

Each holiday we use the same foramt for the final table:

• lightgreen = a.m.
• lighblue = p.m.
• lightgray = done (will change to white after the event for cleaning).

--Itay Alon 18:15, 31 October 2009 (UTC)

Look at previous ones. Lightgray has never 'changed' to white. -- riyen ♥ 18:18, 31 October 2009 (UTC)

Since the current GWWT:GF#Time Zones proposal calls for 24h format, the AM/PM distinction is probably unnecessary in any case. If it is retained, perhaps there be a table caption mentioning the meaning: it wasn't immediately obvious to me, at least. --DryHumour 18:22, 31 October 2009 (UTC)

someone changed it, it was white... see Wintersday finale tables. --Itay Alon 18:25, 31 October 2009 (UTC)

I saw tables that were lightgray, but what's the problem with the distinctive colors? -- riyen ♥ 18:39, 31 October 2009 (UTC)

In general, I'm all for distinctive colors, when they make sense. In this case, the main problem is that they require more work (as they're not automatic), and do not add information. Am/pm is quite clear for the US, and 24 hr clock quite clear for the rest of the world. 76.164.111.57 22:02, 31 October 2009 (UTC)

May be worth to note that (at least on IE) "lightgray" = "dark hot blue" and "lightgrey" = "black+white", so you may want to use "lightgrey" as color.--Fighterdoken 08:13, 1 November 2009 (UTC)

Not sure why colour-coding night and day is important - using am/pm and/or 24 hour format is enough, as 76.164.111.57 says. I think the colours add unnecessary confusion. I had no idea what the colours meant until I saw it explained on the talk page; even if it was explained near the table, it'd still be useless. -- pling 16:12, 1 November 2009 (UTC)

Content

PDT: 12 hours foramt (including a.m / p.m), UTC / GMT: 24 hours foramt. Including date only when it's not the day that mentioned before the table. --Itay Alon 18:23, 31 October 2009 (UTC)

I tend to prefer 24h format. While we're at it, given the international character of the audience, I would suggest YYYY-MM-DD for dates, per ISO 8601. --DryHumour 18:26, 31 October 2009 (UTC)

I would suggest that dates stay as full dates, such as 1st November and so on. This is how its always been done and it's more inclusive due to the multinational readership of the wiki. 11.01 is somewhat annoying/confusing to europeans in that it's the 11th January. Actually to be completly honest I would suggest that the times format doesn't need changed from what they are currently. As it's perfectly functional and most users are familiar with it. -- Salome 20:14, 31 October 2009 (UTC)

I suppose any use of pure numerics will confuse one party or the other, regardless of how standard (or not) the usage is. --DryHumour 20:50, 31 October 2009 (UTC)

Use of Capitalization

Speaking as someone who has tried to use proper English capitalization ("Normal English capitalization is preferred" I think that either the section here needs to be edited to properly reflect current accepted standards (which do not follow normal English capitalization) or else, the people who attempt to follow it should not be given any flack over doing so. 42 - talk 03:45, 15 November 2009 (UTC)

Normal English capitalization is a debatable point; it depends on context. Certain professions use capitalization as part of their jargon, newspapers differ in how they capitalize, and there's evidence of regional variations. Plus, not everyone understands instinctively what this wiki might mean by normal. So, I think it would be helpful to (a) include specific examples (e.g. pointing to GWW style guides and some obvious cases) and (b) offer some clear general guidelines (since we obviously can't set an example for every use). However, since the subject is grammar, I can guarantee that peeps are going to give each other flack no matter how clear the guidelines are; the best we can do is make it easier to resolve any disputes.   — Tennessee Ernie Ford (TEF) 04:02, 15 November 2009 (UTC)

As for normal capitalisation (or z, as you Yanks put it): unlike most elements of English, capitalisation is not a very highly disputed point, only one on which many people are uninformed. Capitalisation in context is just that; there are different rules for titles, prose, etc... everyone would agree that in normal English capitalisation, the title of this section is missing no capital letters. Only jargon, as you say, chooses to capitalise some words or phrases because it's a special element in their (non-communicative) workings, and in this case the jargon we're working under is GW's, which, as far as I know, has very little extra capitalisation from Basic English Capitalisation. (Yes, that was intentional.)

As for what we should do, we should not correct any of GW's mistakes except where it's inconsistent with itself, and for stuff coming out of our mouths, we should use the extant normal English capitalisation,.. I posit. | 72 {U|T|C} 04:34, 15 November 2009 (UTC)

For the purpose of understanding grammar rules, I consider "gamer's speak" to be jargon; rules of capitalization differ across games and gaming sites, and they differ from newspapers, library science, the music industry etc. So, for the purposes of this wiki, I think we can establish whatever capitalization rules we like. On the whole, I think the most important purpose of clarifying the rules is so we can spend time discussing the finer points of skillbars rather than whether to write, "Horns of the Ox sux" as opposed to "Horns Of The Ox is UP'd".  — Tennessee Ernie Ford (TEF) 04:46, 15 November 2009 (UTC)

By "normal English capitalisation", it means capitalisation that would be standard in normal text (i.e. sentences - capitalise proper nouns and beginning of sentences, lower case for common nouns). Saying "normal English capitalisation" isn't incorrect, and the explanations following that on the guideline seem to support this. I believe that was the original purpose behind it, as well. I think the page reflects practice, and the explanations get rid of ambiguity. Don't think there's a problem here. -- pling 17:41, 15 November 2009 (UTC)

I am not proposing to do any capitalization that is in difference to the game; where the game uses a certain way, only on the ones that are not specifically following the game manner used. I have seen many different styles in use in the pages, this is to clear up that issue.

The problem is, that "practice" is all over the place, and I try to correct it to actually follow proper English (which is to capitalize common nouns when used as a proper noun for example), and I basically get read the riot act (given flack) how I am not following guidelines. If there wasn't an issue, I wouldn't have brought it up Pling. 42 - talk 23:32, 7 December 2009 (UTC)

Related to "capitalization" discussion, ... So I thought it should be put here. In the guideline it says "There is no need to follow in game..." I thought this was supposed to follow the game naming style, phrasing, etc. 69.182.188.118 13:31, 13 September 2010 (UTC)

My position is that we should follow theirs--even when contrary to English--when they do it as a rule, but not when they do it arbitrarily.

For example (I don't know if this is actually the case) if they capitalized Human in cases like "It's a Human!" & we we wondered whether to treat it as our English noun or their proper name for a race, we should do theirs. But if they had a character named "Thomas The Destroyer" (and, say, only referred to him once) I would assume a typo, and lowercase "the" on the wiki. | 72 | 19:36, 13 September 2010 (UTC)

Bolding

Bolding the name of the page... Should this [[Example]] be used or should this '''Example''' be used? -- riyen ♥ 08:30, 2 December 2009 (UTC)

It's better to have them [[linked]]. -- Wyn talk 08:43, 2 December 2009 (UTC)

I agree. --★KOKUOU★ 08:47, 2 December 2009 (UTC)

It really doesn't bother me either way, but would like a consistency of one way or the other. Just not both as I've seen. -- riyen ♥ 08:53, 2 December 2009 (UTC)

I agree with square brackets too. Makes it noticeable when a page is moved that the text needs changing (since it would appear as a proper link rather than bold), and I suppose it would help when pages are transcluded. I've seen more square brackets than manual bolding, and I've also seen more instances of changing manual bolding to square brackets than the other way round. -- pling 10:38, 2 December 2009 (UTC)

I'm one of those. I also know a few other users who do the other way round, so a few articles may have gone back and forth :D -- ab.er.rant 14:17, 2 December 2009 (UTC)

4 brackets < 6 quotes anyway, over 18 000 pages we'll save like a kilobyte. Woo! | 72 (U|T|C) 14:30, 2 December 2009 (UTC)

It's way more than that when we keep switching it back and forth because of all the history it'll generate ;) so it'll be nice to finalise this. But then again, it's really a trivial thing. I just get itchy and change it when I'm editing something else. I don't bother saving an edit for the sole purpose of switching it. -- ab.er.rant 14:39, 2 December 2009 (UTC)

FWIW, I also prefer the self-link style, for the same reasons that others have already mentioned. --DryHumour 15:33, 2 December 2009 (UTC)

Brackets. Better for editors to easily see what is linked, what is not. Helps prevent multiple linkings. de Kooning 15:40, 2 December 2009 (UTC)

I was for bolding at first til someone mentioned the transclusion issue. That way, if it is linked and transcluded, it keeps the link to the original. I will not change it if it just that, but if there are other things I am in a file fixing, I will now make them links. 42 - talk 19:51, 2 December 2009 (UTC)

I'm guessing so far that everyone wants [[this]] done? Is this the consensus made up so far? -- riyen ♥ 06:16, 6 December 2009 (UTC)

Since it wasn't brought up, would it be preferred to have, for example, [[Tyria (world)|Tyria]] or '''Tyria''' . Asking due to this (which I accidentally undid when editing something else, woops) and the reasoning for using brackets over the quote marks was for size and how people do them, and I've seen article names in the article which are not equal to the article (due to the parentheses, for instance) to be done by ''' instead of the brackets. Want to figure which is preferred. -- Konig/talk 12:02, 6 March 2010 (UTC)

According to consensus up there - it was more towards using the brackets. That's why I did the brackets. Kaisha 12:13, 6 March 2010 (UTC)

Technically, the consensus only discussed using it without the rewording (using the |), so there isn't a consensus for doing said way. I'm more inclined for smaller text either way, so when the title page uses something not in the subject (such as "Tyria (world)"), then the ''' should be used. -- Konig/talk 16:07, 6 March 2010 (UTC)

Actually, doesn't matter if it has | in it or not. If there's ''' - the consensus is [[ as it was discussed on those type of "bolding", no matter the actual page name so I can see the [[Tyria (world)|Tyria]] being used instead of '''Tyria''' as per consensus above there. Also it was [[Tyria (world)|Tyria]] for a while, before it became '''Tyria'''. Kaisha 18:42, 6 March 2010 (UTC)

Wiki Links in articles/sections/headers etc

There is apparently disagreement on this. Although the links I have been adding to the pages follow the guideline here, some people have an issue because the first possibility for a link happens to be in a section header.

It has been suggested that links be placed on another instance of a word that is in the header, even if that word is after the header in the article. I do not have a problem with this, but sometimes the only time that word occurs in the article is in the header. 42 - talk 03:14, 10 December 2009 (UTC)

I just don't think it looks good, especially since the headings would be highly inconsistent on a page. --JonTheMon 03:18, 10 December 2009 (UTC)

I agree, I prefer them to be consistent and to fit to the formatting NPC examples, not edited for links. -- riyen ♥ 03:25, 10 December 2009 (UTC)

Link headers? ..We have headers at the tops of sections because the subject of the header is going to be discussed beneath. 'Nuff said.

(If it isn't discussed in the following section, add a line introducing the subject and link it there.) | 72 (UTC) 03:28, 10 December 2009 (UTC)

No links in headers. It looks like balls. --RIDDLE 03:38, 10 December 2009 (UTC)

It would just look bad, imo. I'd rather keep links in the main text. -- Wandering Traveler 05:14, 10 December 2009 (UTC)

I have no problem with linking them in the main text of the article. Sometimes that is not always possible, because the header is the only time a particular word shows up in that page (such as what happens a lot in the case of lists). Also, something that people are possibly not considering, this is an issue more of function than looks. I do not have a problem that some people think it looks bad. I don't agree, but that is not at issue here.

Shouldn't the greater purpose of the wiki be considered? A large number of users aren't the ones who sit in here all the time working on it. They are more concerned with playing the game, and they only look to the wiki occasionally. This is also an issue with that. I have brought up this point before on other issues as well, but how useful is information if you can't find it?

I think it comes down to an ease of use issue. Should we make intentionally make more work for people who want to look up information just because of how that information access looks, or should we sacrifice looks (I don't have a problem with how it looks with linked headers) for better usefulness? 42 - talk 05:26, 10 December 2009 (UTC)

I never thought I'd say this, but I think we need to sacrifice the utility for the sake of continuity and looks. Its not that large of a tragedy, as the search box to find the particular article is a convenient 1/2 to 14 centimetres (approx.) away from the word in the article. -- Wandering Traveler 05:29, 10 December 2009 (UTC)

(Edit conflict) Something else I just thought of. On the pages where this would be most applied, the NPC pages on the skill list, we could have the link connect to the list of skills for that particular profession. So it would provide more information than just linking to what a skill is, for example.

72 brought up that point before on another page as well, Wandering, but I don't feel it is right when the link can provide that same information access with less work (a small amount each time, yes, but over the course of time, if there were links, the savings would be huge overall). The other thing is that people might be trying to get in and out (in the case of in the middle of a fight ingame, and don't want to take the time to type in the search box). 42 - talk 05:32, 10 December 2009 (UTC)

I can agree with that. Though I still disagree with the formatting suggested, perhaps there is an alternate solution. If the only instance of a possible link is in the section header, should the main text in that section be re-written or changed to accommodate an alternate linking site? I can't think of much of an example where the link should not be repeated if the info is that important. -- Wandering Traveler 05:39, 10 December 2009 (UTC)

(Reset indent) It may be worth mentioning that this topic has come up before (e.g. GWWT:LOCATIONS#Headline links and probably others). I had suggested the compromise of using something like {{see}} as the first line of a section which would otherwise lack a natural link, but the idea did not gain traction. (This is particularly prevalent in situations like NPC lists, etc., which is the primary use case.) FWIW, the only technical (i.e. non-aesthetic) counter-argument that I'm aware of is for accessibility readers (this was at one time mentioned on w:WP:ACCESS but it seems to have disappeared) but I doubt that is a major concern for a video game wiki. --DryHumour 05:46, 10 December 2009 (UTC)

I think we should 'sacrifice' the ease for looks. Here's a reason, we have a search, if people really want to know what skills or missions mean? they can look there. We don't need to dumb down the wiki for the lazy people. We need to do actual document for the game, looks as well as ease. But looks should be a bit ahead of ease. -- riyen ♥ 05:46, 10 December 2009 (UTC)

Wandering, what about my example above, the skills list? There is really no reason to "word" the list to have the word "skills" anywhere in it other than the header. It doesn't come down to usefulness as an argument much, because people will still argue "well it isn't useful to me, so no one else should ever have a use for it." I added the second half of that point, because they won't say it.

Using search box instead of the link that would be right there, "still" more unnecessary work no matter how many times it is said. The main objective and I guess viewpoint that should be used is ease of use, if the wiki is to be the reference it is purported to be. It has little to do with if they know what a word means or not, Ariyen.

I would presume you know what the word "definition" (pick any word, I am not trying to put anything more into this) means, for example, but maybe you looking that word up means you find some more information about that word that you didn't know already. 42 - talk 05:56, 10 December 2009 (UTC)

Ouch, you got me there. (Not really). Seriously, If I wanted to go to a website where it's all about links and text and not showing the 'care' of sloppiness. I'd go to a site similar to this [guildwars.incgamers.com]. When I was first here, it was more about looks than ease. It still is to most part. That's what had me like it more, because though I wanted to make it 'easier' for people. You also want to make the place 'look' good and 'attract' the gamers and fans of guild wars, even newcomers. Because a poor looking place, dies quicker than those that has an ease, but good attracting looks. -- riyen ♥ 06:06, 10 December 2009 (UTC)

I would provide this link and tell you to read the paragraph after the first picture, but of course that article got lost in some server issues. --RIDDLE 07:07, 10 December 2009 (UTC)

(Reset indent) Ariyen, I wasn't trying to "get" you. YOU use whatever word you want, pick one, that way I am not "getting" you with it. My point is that, for that example, you click a link to a word or item you know well, and find out some more information about that word or item that you didn't know yet. If it is harder work to go look up that word, most people wouldn't bother to do so. I know in my case, it is mostly because of laziness. That is all I am saying.

If it looks tacky or sloppy or not isn't in dispute; you think it is, I don't. I believe that usefulness should take priority, especially when there is nothing wrong with having links, and this is not just for me. If I thought it was just for me, then I would link every single word, because I think it should be the most useful to the most people. They shouldn't have to go hunting for a link when it can be made right there.

I know quite well how to make use of the search box. I am reasonably well skilled in finding my way around computers; I have been working with them since about 82-83. In fact, the first computer I ever used (my family owned it) was a Timex Sinclair (if I remember properly) that had a tape drive to store programs on, and a (HUGE) 16K memory module. 42 - talk 07:58, 10 December 2009 (UTC)

Is this it, riddle? If so, love it! -- riyen ♥ 08:19, 10 December 2009 (UTC)

Yes, thank you Ari. So ^ that link, the first paragraph after the picture. --RIDDLE 08:30, 10 December 2009 (UTC)

I remember that link. I read it back when I was first doing my sites, more as 42 is doing here. A professional webmaster, sent me the link. I changed my pages a great deal to look better and he complimented on it. Had over 50 hits after that. As, I and others say, It's more about 'presentation' than 'useful' . You may want to be helpful and useful, but see each page has to look and have the information pertaining to that page. Not links to every little thing. You want it to have the feel as others are asking for, as per the formatting guidelines as that's what they're there for, along with other policy and guidelines that if you read them, you wouldn't be linking as much. I don't see every other word linked in wikipedia. Not to mention, as others have said, if someone wants to know what the simple word pertains to or means, there's the search engine. If they have time enough to take time out to do a mission or quest, to look on here at all; they can take time out to search up a word. Not every word that can be linked, needs to be linked. -- riyen ♥ 08:43, 10 December 2009 (UTC)

To return to a more basic part, 42, you ask How useful is information if you can't find it? ; however, in the case of a header, the fact that it's significant is no longer buried in a lot of similar text (like, say, the word "wikipedia" in Ariyen's post). Now it's a large, bold, partially uppercase announcement, sitting at the top of a wall of text. If there is any text easier to identify as important on the wiki, I don't know it. Furthermore, putting a link in the header says "While the subject of the header is discussed below, it's not comprehensive," which only detracts from the header's purpose of acting like a billboard for people skimming the page. Now two people have suggested it: if a section below a header is unclear or inadequate on what the basic thing is (say, a header titled "Quests" on an NPC page), a short line below with a link and introduction is more appropriate. | 72 (UTC) 13:33, 10 December 2009 (UTC)

I agree with keeping the links out of the headers. As for this little line under the header linking to the appropriate page, I would be against that if it's for something as basic as skills but if it warranted a {{main}} tag, that would be fine (i.e. Heroes page). Having something to a main tag beneath every skill section would seem over-the-top. As for that link with the blog with every second word highlighted- that's what I was talking about earlier. ~Celestia 13:48, 10 December 2009 (UTC)

(Reset indent) I find it amazing how many people seem to have a problem (they basically ignore it) with me giving a ridiculous example (to show how ridiculous their argument/point is) and then go and do the same exact thing. That page is a worse case scenario, and I doubt that many (if any) pages on this wiki would be linked that extensively by following first occurrence.

I do not have an issue with people using that as an example (saying this before someone tries to put words in my mouth).

It is not my intention to have that extreme number of links, and linking the first occurrence of words in the articles on this wiki wouldn't be anywhere close to that example. It isn't like there is the depth of information like there is on the Wiki where actually linking that many words would even be possible. 42 - talk 06:19, 11 December 2009 (UTC)

Obviously, you don't know this wiki. We only detail what is needed and what is avaliable. It's not as simple as the main wiki to be that detailed, but does not give one the right to go through linking every simple word like mission, boss, etc. Only linking the important words that's not throughout a lot of the npc pages. I suggest reading on those npc pages you haven't touched and taking notes. As shown via that link, too many links can make a page look bad. We value on looks as well as information, but we don't want excessive links that shows one does not know about pages that has done this, that .. It looks more immature is what I am saying and I don't know if others would agree on that or not, but that's not the type image I think we'd want for this place. I appreciate your interest, but I'm hoping you'll respect and appreciate other people's oppinions too. As always, the majority rules and that's consensus. -- riyen ♥ 07:12, 11 December 2009 (UTC)

Ariyen, obviously, you still need to stop trying to speak for people, and stop telling them what they know and don't know. I suggest you stop doing so before you start to piss people off.

72, that comment was directed more at the general mindset that seems to be shown on items and issues similar to this. It wasn't the best example if someone is going to think that point applies only to the "skills" header, for example. However, it has been my observation that many people try to use something similar to "well this is somewhere else, why do we need it here?" sort of thinking, which to me is akin to "hiding" something when there is no need to. And it also happens that many people seem to take a general example, and try to say "well it doesn't work in this specific instance, so the whole idea is crap." 42 - talk 07:25, 11 December 2009 (UTC)

Mark your own words 42. I speak for what is known about this place as I have been here a bit longer than you, use to just do an ip (moved twice, till I am where I am) here and there, until I felt that I could do more. Also, pissing people off? I think you're doing the same, by arguing points that has 5 or so against you in one area, or two or three or so against you in another. That's also calling the kettle black. Stop dramatizing me. You'd do better to get off being a push over and work with people. Take Materials for example - that is me helping, but not being a pushover. I do not see an example from you. Thanks. -- riyen ♥ 07:43, 11 December 2009 (UTC)

Sadly, I think Ariyen has a point. You can be right and because this wiki is run by and for people capable of contributing to discussion, if they disagree then your idea still shouldn't be implemented. Probably no one is going to convince anyone holding the opposite opinion on a largely opinion-based issue ("Is x extra convenience worth y worse appearance?"), which means that at a standstill the majority decision goes.

Similarly, one of my first ideas when here was to add in one line below each zbounty walkthrough, "This boss has the elite [[Elitename]] and drops [[Uniquename]]", at least the first of which I really wanted right there when I did the rounds. The idea was rejected by the majority on the same grounds as yours is being contested now, but I let it pass (mostly because of one particularly obnoxious debater... cough cough), though I still think it was and is a good idea. | 72 (UTC) 16:22, 11 December 2009 (UTC)

Event page colors

Should we select a single color to be used as an accent on all event pages? -- Wyn talk 16:53, 5 February 2010 (UTC)

The color of Wintersday is #FDA, and the Halloween has is own #DDD.

I think it's better than all events will look the same, it made the difference in each event. --Itay Alon 18:10, 5 February 2010 (UTC)

I think a single color for events will help to identify pages as event pages and add continuity across the wiki in general. -- Wyn talk 18:16, 5 February 2010 (UTC)

So what color do you suggest?--Itay Alon 18:27, 5 February 2010 (UTC)

Coding styles.

I don't know has there been any discuss about this before, but some people have their concerns about edits i've been doing lately. The thing is about spaces in articles.
Should we decide which style we use with section headers and bullets:

==This==
*Text goes here
or
== This ==
* Text goes here

Or something between the two? I see both of these alot in articles. The second one makes the code better looking and easier to look at, in my opinion atleast. And yes, i know these have no difference what the article itself looks like. - J.P.Talk 14:43, 17 February 2010 (UTC)

I'm less concerned about the edits you have been making, but more about the time wasted on trivial matters like spacing in the wiki code. I was mainly just trying to point out the futility of what you were doing. If you really, really, want to add those spaces, then by all means knock yourself out. Though I really suggest getting a bot to do it. -C2Talon 14:58, 17 February 2010 (UTC)

Ah, one of the many proposals by 42...Discussion can be found here- think I was the only one that didn't like it. Also it was only on the NPC page for some reason, /shrug. Personally I don't see the point in editing a page just to add the spaces, sure if you were adding something else in then fine, but to ping people's watchlists for adding spaces... ~Celestia 15:03, 17 February 2010 (UTC)

Actually, I'm going to have to take some of that back. I don't think you should be changing any pages just because of the spacing in the code. Maybe if you were doing that in addition to changing some of the content on the page, it would be justifiable. But editing the page just because of spacing in the code? Really? -C2Talon 15:05, 17 February 2010 (UTC)

(Edit conflict) I'm not here because of me. I brought this up because i'm confused since both of these are used and i think it would be best to stick with one formatting style. I'm happy with whichever outcome.

I've been going through skill pages adding skill IDs and doing the spacing at the same time. It was only a few skill pages where i only did the spacing. This was before i got the idea of ID edits.

But what can we say about skill pages if people like spacing in NPC pages? - J.P.Talk 15:15, 17 February 2010 (UTC)

The problem is many pages right now are still following the guidelines where no spaces were present, so a lot more pages will not have spaces. It makes no difference to the page when viewed (which is the main thing). If it's decided that we need to add space, then that's fine, I'll have to learn to overcome the habit on not leaving a space. I guess it's more of a personal preference than a guideline (similar to using '''bolding''' or [[bolding]]). ~Celestia 15:21, 17 February 2010 (UTC)

I think it was decided to rather use [[bolding]]. - J.P.Talk 15:25, 17 February 2010 (UTC)

(Edit conflict) I feel Celestia is right in regards to spacing. It's basically a matter of preference.I wrote the Weapons formatting guide using the *Text & ==Text== styling. With me, it's the same as writing or reviewing another's code. As long as it's separated into relevant blocks, line breaks are correct, and comments are clean, any compactness is not an issue. All in all, I don't feel a strong pull in either direction. — Gares 15:26, 17 February 2010 (UTC)

So i can do spacing? But i agree with doing some real edits at the same time. - J.P.Talk 15:35, 17 February 2010 (UTC)

I would agree strongly with the sentiment that this sort of change only be made in conjunction with real, substantive changes – if it must be done at all – in order to avoid RC thrashing. --DryHumour 16:13, 17 February 2010 (UTC)

Adding code which (to a novice like myself) appears as though it has an effect on the article but actually doesn't, for me, hurts clarity, rather than adding to it. | 72 (UTC) 16:34, 17 February 2010 (UTC)

Totally agreed with Dry tbh. If you're going to make an actual edit to the page, feel free to add spaces, but since it doesn't even have a visible effect on the page I'd strongly prefer you not break RC and people's watchlists (again). – Emmett 21:10, 17 February 2010 (UTC)

General formatting - Categories

I think it would be nice to have in the General formatting section a list of general categories in the order of which they should appear if present, because I noticed that Notes, Trivia, See also, External links and References, are usually in any order.

I would suggest this order :

• Notes
• Trivia
• See Also
• External links
• References

Also could add any recurrent categories, if there is any others I didn't think of. Milène 142.78.8.4 16:56, 21 February 2011 (UTC)

GWW:ULC new consensus

See Guild Wars Wiki talk:Formatting/Article names#GWW:ULC. – Tennessee Ernie Ford (TEF) 19:02, 14 November 2011 (UTC)

Profession capitalization

This format states that professions should be lowercased. Firstly, I've seen many cases where they are capitalized. Secondly, I think they should be treated the same way as creature types/species - capitalize on the wiki because they are capitalized in the game (there was a discussion on the capitalization of races a while back due to GW2 lowercasing them but GW1 capitalizing them and it ended with "just go with how the game treats them"). Konig/talk 20:12, 9 February 2012 (UTC)

I concur. I've always capitalized them. ~FarloTalk 20:16, 9 February 2012 (UTC)

These formatting guidelines haven't changed much in a very long time. Not that I'm using this as a reason why things like professions should stay lower case - just pointing out that, if you have seen them capitalised, that was contrary to the guidelines (and, as far as I can remember, the many discussions that upheld that consensus). I prefer to treat professions as normal English would: lower case. The species stuff would probably be better in lower case too.

"There is no need to follow in-game capitalization where it does not make sense" - making sense is preferable to just following the game, which often doesn't make sense. pling 18:57, 10 February 2012 (UTC)

A reasonable exception to that quote, imo, would be "except where not following in-game capitalization creates constant inconsistencies" - e.g., when we have almost every dialogue and {{quotation}} saying Assassin, but every walkthrough, introduction paragraph (outside of quotations), and so forth being assassin, it gets confusing on "what's right."

Same goes for species, which was the reason why we kept/returned to capitalization. Konig/talk 19:53, 10 February 2012 (UTC)

Hm, that is a good point. A formatting guideline is supposed to facilitate consistency in articles, so perhaps some things should be capitalised. I'd like to RfC this though, because it would be quite a significant change, involving page moves as well as article content. pling 15:57, 11 February 2012 (UTC)

Yes, please. I'm always in favor of making it easier to distinguish ANet jargon from ordinary English. It's easier for readers to understand wiki content if we always use Assassin to mean Assassin and assassin to mean a trained killer (who might be of any prof). – Tennessee Ernie Ford (TEF) 01:10, 6 March 2012 (UTC)