Guild Wars 2 Wiki:Community portal

From Guild Wars 2 Wiki
Jump to: navigation, search

Community Portal

Lost in a sea of projects, formats, and debates? Look no further! These are the current hot topics, and you can find previous topics here.

To begin a new topic on this page, use the "+" button at the top of the page.

If logged in, you can also add this page to your watchlist to track any changes and stay on top of things!

Old topics are archived to these subpages.

Newsletter of the week[edit]

This newsletter is maintained on User:Relyk/Wiki Newsletter and might not objectively reflect what happened on the wiki.

  • When Alex is on vacation, Relyk still doesn't get asked template or SMW questions.

The skill lists should describe the skill facts[edit]

Over time, the skill descriptions began to not really describe what a skill does - that's now described in the skill facts that accompany the description. This has made the wiki skill lists somewhat obsolete, in that, in order to really see what a skill does, reading the lists isn't enough - we have to click on the skills one by one.
For example, the Firebrand skills:

  • Core Cleave is described as "Cleave at your enemy with a physical and a magical axe". Nowhere in that description it mentions the skill applies bleeding.
  • Chapter 2: Igniting Burst is described as "Ignite the air around you in an expanding burst". No mention to how it causes weakness.

There are multiple other examples, including many of the Revenant and Mesmer skills.
I think the skill lists should be changed to include the skill facts. This would make them more comprehensive, and the total size of the lists wouldn't be bigger than the skill lists we had in the original Guild Wars (in which there were a lot more skills per profession). Erasculio 10:47, 28 August 2017 (UTC)

I agree with this a lot. In reality the descriptions often fill more of a role of flavour text, rather than truly describing what the skill does. I was thinking about whether we should show the skill facts in the lists even before the game launched, but at the time the descriptions were much more comprehensive so I didn't push for it. However, you're absolutely right that these days the lists are mostly a hub for links with the information people are actually looking for.
However, I'm still slightly afraid the resulting lists with the facts would get quite long and difficult to read. I tried making a very dirtily coded example at one of the longest lists we currently have (ele skills) to see what it would look like (it can take a while to load, I imagine the servers not being very happy about it :P). I don't know enough about semantic properties to know whether this would be feasible technically, but I hope so. I personally think the appearance is not that bad, and while it might take a while to get used to, it does make the list page much more useful. At the same time, I can imagine someone thinking it's a bit too long – I wonder, would it be possible to add a bit of local storage widget magic to add a checkbox at the top of the pages that would allow you to toggle the skill facts appearing, similarly to the settings in Event timers? Because if so, that should make both sides happy. ^^ User Noxx Sig.png 17:20, 28 August 2017 (UTC)
Adding the facts adds about 13 seconds to the processing time (unacceptably slow imo). Part of this is probably that {{skill fact}} invokes {{effect}}, which then invokes {{effect icon}}, which then tries to lookup the SMW icon even if it isn't needed (we specified the icon in the top level template!) There's a few things we can start to do to make this workable. -Chieftain AlexUser Chieftain Alex sig.png 20:32, 28 August 2017 (UTC)
Bear in mind that the example I put together was looking up the skill facts with {{#dpl: | title = {{{1}}} | include = {Skill infobox}:variables }} inside of the row format template. Wouldn't an implementation with properties be faster? Or would that not be possible to do for whatever reason (a property couldn't hold that data, it would take too much space, it would be too slow anyway, or something like that)? User Noxx Sig.png 21:05, 28 August 2017 (UTC)
Since this is somewhat related, I want to add some properties for skills/traits, as seen here: User:Nefastu/Projects/Skills and traits. Maybe Applies condition/Applies boon would be interesting for the solution of this problem (if we don't want to include all skill facts)? —Nefastu 21:47, 28 August 2017 (UTC)
@Noxx, I'm thinking we just store the variables parameter as a text property, such that we can query for the output markup. Last time I proposed this it was argued that we couldn't ask for specific skills which apply bleeding etc, but bluntly that's a problem for another day.
DPL is slow only because template:skill facts is slow. Storing the output wikitext avoids the template speed issue I mentioned above. Also we're trying to slowly eliminate all dpl usage because it's no longer maintained as an extension. 22:39, 28 August 2017 (UTC)

(Reset indent) The {{skill fact}} template if for defining the skill fact subobjects on the the skill page. The template isn't meant for looking up and formatting a skill fact. Skill facts semantic properties (Guild Wars 2 Wiki:Semantic MediaWiki/Skill facts) aren't finished yet and haven't even started implementation, we were primarily waiting on the skill API. One of my goals with cleaning up skill facts to prep for skill fact subobjects.

We'll be creating subobjects no matter what. Here's the current strategy we have for lists:

  1. What we will probably first do if semantic lookups are an issue is store the semantic lookups in the subobject. We did this for recipe tables and lists.
  2. For lists, we can also store the initial look up for effect icons and canonical names in #variables so the page only pays for the initial lookup. I don't think we've done this yet with recipes as it's not needed, but would be the next step.
  3. If we have a use case where that's too slow because we want to list 300 skills with skill facts, we have to store a wiki markup representation as a text property like Alex said. This requires way more maintenance and work and should be last resort.
  4. 13 second processing time for edits is acceptable for sparsely edited pages. For pages doing a large number of lookups and having long edit periods and short page loads onced cached, we can create subpages. Currently, used for Gem Store.

Before we ever hit the need for optimization, we would probably switch to a tooltip widget that generates a tooltip on-the-fly. The places where we list all skill facts on all skills is mostly reference tables that aren't edited often.--Relyk ~ talk < 02:54, 31 August 2017 (UTC)

I'd like to avoid having to split the lists into multiple pages if at all possible. The whole reason we'd be doing this is so that the information is available on a single page (obviously, it would still be better to have it, say, spread across 2 pages than 100, but still, it seems somewhat unnecessary), so I'd say that that should be the last resort. My knowledge of properties and subobjects is admittedly a bit limited, but if it was possible to dump the wiki markup for all the skill facts into a property and then just paste it in the lists, shouldn't that be easier to maintain than having to split the properties and queries into more sophisticated structures? I realize it's a bit crude solution, and I can imagine a couple reasons why it might not be the best option, but ease of maintenance doesn't seem to me to be one of them. I wonder, though, could we perhaps try to save that property for now, to see how fast or slow it would be? I don't think we should really consider the 13 seconds, since DPL is definitely not one of the options we'd want to use.
Anyway, do I understand it correctly that you'd want to make a property based on each individual skill fact and then reformat them in the skill lists? If it worked that way and it was fast enough, I can certainly imagine making a more concise version, perhaps only showing a row of icons for conditions, boons, CC and other effects, either without durations or perhaps even while having them on tooltip. That should definitely help with the description bloat a full list would cause... Or did I misunderstand you completely? ^^ User Noxx Sig.png 18:19, 31 August 2017 (UTC)

Scream test[edit]

So I did a quick "let's see what happens" test, created Property:Has skill facts and annotated the skill infobox... and I saw a SMW warning triangle on the first page I encountered. I've quickly reverted it for now, but here's a sandbox version. My initial guess is that it doesn't like a parameter called "property", but I'll investigate. -Chieftain AlexUser Chieftain Alex sig.png 18:58, 31 August 2017 (UTC)

Okay found the issue. Skill facts are now generating. -Chieftain AlexUser Chieftain Alex sig.png 19:01, 31 August 2017 (UTC)
Quoting the Transclusion expansion time report times in the page source:
List of elementalist skills (pure SMW) User:Noxx/Skill list (old) (SMW + DPL) User:Noxx/Skill list (new) (pure SMW with facts)
3128 ms 14715 ms 6006 ms
It's not quite finished generating the skill facts yet, but this looks promising. -Chieftain AlexUser Chieftain Alex sig.png 19:14, 31 August 2017 (UTC)
I'm not quite sure which number were you reading, and I'm also not sure what the page was loading at the time, but when I looked at it, half the skills didn't load the facts at all and the other half still used DPL. ^^
Anyway, I updated all the templates used in the example to SMW properties, and the Parser profiler Real time usage times I'm currently getting in the edit window for cache reload are around 4.9-5.4 seconds. However, I'm not entirely sure if that is an acceptable time, if we could further improve it or go with a different route entirely. One other problem is that the skill fact properties categorize the lists according to combo fields and finishers. User Noxx Sig.png 17:56, 2 September 2017 (UTC) In firefox at least, you can right click inspect element on the main div#mw-content-text container, right at the bottom are some HTML comments you can view. Anything around 5 is acceptable. 30 is the max, beyond 30 the wiki rejects it with an error, beyond 15 I've already closed the tab and gotten bored. -Chieftain AlexUser Chieftain Alex sig.png 18:12, 2 September 2017 (UTC)

Combo skills[edit]

Hmm apparently this would cause any page querying for "Has skill facts" (if the subject has a combo finisher fact), to be added to the combo finisher category. This is unfortunate. -Chieftain AlexUser Chieftain Alex sig.png 20:39, 27 September 2017 (UTC)

Skill history pages[edit]

So with that pre-patch notes fix to skills, realized that most of the new skill pages don't have history pages. I'm going to get started making them, but it's a big job. Also, do we want to differentiate beta version vs launch version in the history?

--Rain Spell (talk) 22:21, 21 September 2017 (UTC)

Hit with what we can on launch, I'd say. We're may have skill patches soon after the release, so if we can decrease the number of histories to generate by just one (i.e. drop the beta), that may ease the workload. I'm going to be getting in late tonight, but I'll try to keep this project in mind. G R E E N E R 23:04, 21 September 2017 (UTC)
That sounds like a plan. Tried out having the beta version on 2 of the soulbeast auto-attacks, but it's imprecise and time consuming. I figure someone can go through later and add it if it ever becomes significant.--Rain Spell (talk) 00:08, 22 September 2017 (UTC)

The wiki has a credibility and accessibility problem when it comes to lore[edit]

I haven't been editing the wiki actively for a while, but I was disappointed to read this thread on the GW2 subreddit the other day. Choice quotes include: "Well the wiki is written by the players mostly, I'd trust this article more personally... Especially given the fact that the wiki doesn't link to its sources of informations.", "But yeah, I'd really like to see what certain users on the wiki are citing when they write up stories about the lore.", "Discussing with wiki people never leads to an agreement.", "Devs mightve wanted to leave Tyria ambiguous but players tend to interprete things in the way they want to, so wiki articles can be misleading.".

Going by this thread, the wiki is no longer considered a reliable source of information as far as lore is concerned. This seems to stem from the perception that lore editors misinterpret sources of information and then edit the wiki to reflect that misinterpretation. It is impossible to challenge these edits without contacting the editor directly because the changes have not been referenced - the reader usually assumes that the source was obscure and moves on (or just doesn't want the hassle, and moves on), and the project becomes unreliable as a result.

I'll give a recent example that I've seen: the lede on Elona was updated to say that another name for Elona is the "United Kingdom of Elona". An IP (full disclosure: that was me, lurking) added a {{citation needed}} tag because that's a significant lore fact and I hadn't seen it mentioned anywhere, but the tag was removed with the reason "Called such in PoF. We dont reference tag the game." (which as far as I am aware, is not a wiki policy). I did a search on the wiki for "United Kingdom of Elona", and the only mention I could find was on Dishwasher. So to say that "Elona is also known as the United Kingdom of Elona" is misleading - it's only known as such by a single NPC (that we have found) who is loyal to Palawa Joko. This is emblematic of the problem outlined above, and could have been challenged much more easily if the statement had simply been referenced. It's important that the wiki is accurate, not least because the devs sometimes use it to check the lore as well. Another very similar recent example is the claim that Tyria is sometimes known as Central Tyria, which as it turns out is actually pretty debatable - the only NPC to refer to it as such is the Black Lion Greeter. Had the statement been referenced, this error could have been caught earlier, or at the very least readers could decide for themselves whether they agree based on the evidence presented to them. With PoF out and people at various stages of completion, this problem is likely to crop up over and over again, and unless we are diligent then inaccuracies could easily slip in.

A more distant example is Elonia, an article that has been on GWW since 2011 and has been linked to throughout that wiki and GW2W. But the only mention of "Elonia" in or out of the game (ever!) is the dialogue with Hehmnut's Bones and Nahtem's Bones Those two dialogues were probably written at the same time, and there's every chance that "Elonia" is a typo of "Elona", which is mentioned many more times in the Crystal Desert, but you wouldn't know any of that from reading the article (which I will say again, has been on the wiki since 2011!!!), which is much more certain of Elonia than is warranted. Yet another example is the GW2W article on Druids, in which references for obscure/disputed lore were actually removed.

Another problem, one that I had thought about a while back, was that new lore editors seem to be put off by the perception that you are required to have an encyclopaedic knowledge of GW/GW2 lore knowledge in order to contribute to lore-related articles on the wiki. A barrier to whether or not someone edits is currently how much lore knowledge they believe themselves to have. I raise this now because I believe both problems have the same solution: implement a proper policy on referencing. The options as I see them are:

  1. References should be used as sparingly as possible.
  2. Any statement about GW2 lore that isn't supported by in-game content (e.g. dev comments on forums, interviews, etc.) should be referenced. Otherwise, we don't need to reference anything that can be found in-game.
  3. Any statement about GW2 lore that is obscure, is likely to be challenged, or has been challenged should be referenced (similar to WP:PROVEIT).
  4. All statements about GW2 lore should be referenced (as the criteria for #3 are subjective).

I think the current de facto position is somewhere between #1 and #2, but if we want the wiki to be considered credible and to be accessible to new lore editors, it needs to be somewhere between #3 and #4 as a matter of urgency. As far as I can tell, the only objection people have to using references more is aesthetic (people feel that they're cumbersome and they look ugly), but if there are any other objections then I'd be interested to hear them. Santax (talk · contribs) 18:38, 23 September 2017 (UTC)

I think we should use a mix of 3 and 4, leaving writer discretion on whether an item should be referenced. In text references, (i.e. In the Shattered Observatory completion dialogue, we learn...) are a good way of introducing citations without creating too many reference links. Still, lore pages should be verifiable, and I think it's a necessary evil to be "ugly" and "correct", rather than succinct/pretty.--Rain Spell (talk)
I wholeheartedly agree with a more involved use of cited references to in-game stuff in GW2Wiki, and I've already been using that approach when editing articles for this exact reason (see e.g. how well such an approach works in Xera when it comes to clearly citing Justiciar Bauer's involvement from his in-game memoirs). I've lately been in talks with a couple of GW2 content creators (some more famous than others) who all agreed that cited sources in wiki would be useful as reference points especially when it comes to obscure/ambiguous/disputed points in lore so one could find reliable information without worrying about taking wiki editors' potential headcanon interpretation as fact. Having cited sources would make the job of the more lore-focused content creators in particular easier and thus benefit not only them in the creation of content but also their viewers who may be relying more on the content creators for lore than hunting down dev replies/playing through every branch of the story/browsing the wiki for answers. As mentioned above, there are even cases where devs refer to the wiki for lore (e.g. looking for inspiration/references from wiki for Halloween lore in GW2 as revealed in one of the Guild Chats).
I don't personally view references as ugly, and the pros of using them far outweigh the cons. They not only help people (editors and visitors alike) find more information about subjects that interest them but also clearly show the context of the cited lore which helps differentiate hard facts from sentences written by this or that editor (which may or may not be accurate in the end). That way any potential dispute between editors about how to express this or that lore etc. fact in an article also has a clear canon reference point without having to guess (or recall) the exact wording in question or spending quite a while googling/wiki browsing to find the reference(s). Embracing the citations for in-game stuff would thus make the wiki more credible and accessible source for all, and everyone (visitors, content creators, editors, devs) benefits in the long run. :) --Kossage (talk) 06:11, 25 September 2017 (UTC)
Honestly, with the amount of fanfiction currently in the lore pages, I'm torn between trying to redo most of them from scratch or just giving up and keeping them as they are. Erasculio 04:05, 26 September 2017 (UTC)
If you wanted to, you could always start a project for it. Takes a bit to get organized, but after that it's easy for other people to come in and join, and there's a center ground for how things are expected to be done everywhere. -Darqam 04:10, 26 September 2017 (UTC)
If this proposal is accepted, then I think a WikiProject to comb through existing lore articles and fact check/add references would be a really great idea. Santax (talk · contribs) 07:07, 26 September 2017 (UTC)

(Reset indent) I think this edit shows exactly why referencing every single thing is a bad practice. Santax had provided reference tags for less than one third of an article, while also adding citation needed notes (5 of them), and the list is rather lengthy (18 lines, with 6 lines having multiple calls; one of which is called on ten times for such minor things, because it was referenced practically every other sentence in a few paragraphs). No casual reader is going to want to sort through such a thing. Even a small article, like the one first tested with reference tags became nearly twice the length because of that - in fact, small articles suffer more than large ones, since they tend to be filled with more "obscure lore" than the larger ones. It was for that reason it was decided not to do it (there were other discussions over on GWW, which built the basis for the current standard which is #2 of Santax's list, but they're more obscure to find - unfortunately, I do not believe GWW ever had an official reference policy page).
The notion of only referencing obscure lore also has major faults, because it's debatable on what is "obscure" based on the individual perception. For example, in this edit Santax added a citation needed tag to the line "Forgotten are devour to the Six Gods". However, anyone who talks to any Forgotten in the entirety of Nightfall and is even a main plot point in Path of Fire (which, honestly, should include Santax) would know that to be the case.
Utilizing reference tags is, quite simply, not the answer to any issue of "certainty of lore". Especially since so much of the lore is intentionally vague by ArenaNet.
P.S., I am not lost on the "coincidental" nature of your cited articles of issues. Konig (talk) 00:42, 14 October 2017 (UTC)

Druids are a good example - the GW2W article, not the GW1 one. With references, a section reads, "The physiological nature of the druids is unclear. Some sources say that they were once humans,[1][2], whereas others suggest that the druids met far from any humans[3] and that the humans chased the druids from the jungle before the Forgotten had even left the world, in 174 AE.[2]". After references are removed, that same section reads, "The druids were originally humans that originated from Kryta". Before, the reader was presented with all information available and left to make a decision based on what there is. After references are removed, one interpretation is stated as fact, with all reference to in-game content that might contradict that interpretation removed.
On the Forgotten page, I removed the citation needed tag a few edits later because I realised that it was actually quite common knowledge. I don't see the problem?
On the Six Gods page; there's no obligation for casual readers to look through all the references. All it means is that everything on the page is verifiable, which serves to minimise content disputes. As the page currently stands, with you having removed the references, there's a list item that states that Abaddon has an unnamed precedent. That's huge! Is there any other information available? How does a reader know that's true - unless they remember a particular side quest in GW: Nightfall over a decade ago, they won't. Should they just trust the wiki? What if they want to edit the wiki? They then can't edit that piece of information, because they have no way of knowing whether they'd be making it inaccurate. Wikis are collaborative, and verifiability is an important part of that. If readers/editors have to run every edit to content by the person who originally added that content, you have a fiefdom, not a wiki. Santax (talk · contribs) 01:09, 14 October 2017 (UTC)
That druid is not an example of with references versus without, nor "being presented with all information" versus not. It's a case of someone thinking a vague line meant that druids weren't human while other clear lines stated they were. It's a case of concision in known lore. But that's an entirely different matter, not relevant to reference tag usage. It's a discussion of "should we be lengthy and include every single tiny little detail on every single article that remotely brings up the topic, or should we keep things concise except when the article is supposed to focus on that topic?"
"there's no obligation for casual readers to look through all the references" No, but casual readers aren't going to want to read sources to ensure something is accurate. They should be able to trust the wiki, and not be put off by a long list of obscure links (one of the original restated complaints about the reference tags, as I recall).
"Should they just trust the wiki?" The wiki is here to be trusted, so yes they should. We common editors should always strive to be accurate, and remove inaccuracies. If you're unsure of something, dig a bit and find out if it's true or otherwise ask the editor for a source. Most people already "just trust the wiki", anyways.
"What if they want to edit the wiki? They then can't edit that piece of information, because they have no way of knowing whether they'd be making it inaccurate." Honestly, I would say that having to reference everything is more off-putting to new editors than not. One of the major concerns I see from new editors is "I'm afraid to mess things up". Having a requirement to add reference tags for lore articles only expands on that issue.
And I think you're missing the main point of my comment. I'm not saying "as things are is perfect". I'm saying "requiring a reference tag to every lore sentence to link to other articles is not how we should do it". I do think the ability to quickly verify something is good. But utilizing the reference tag system to do that - in its current state at least - would be too off-putting to new editors and casual readers. Unfortunately, we do not have a better system.
As an aside, since you felt like defending yourself you had re-added that citation note and it was still present when I had removed it. Which is why I brought it up, because I didn't see that minor edit that you undid yourself. Konig (talk) 01:59, 14 October 2017 (UTC)
@Konig: "No casual reader is going to want to sort through such a thing." By this, do you mean "Casual readers won't want to wade through citations, so there's no point in including them" ? Or is your point more "Lots of citations put casual readers off, so we should avoid using too many?" If the former, well, if they're going to ignore citations anyway, there's no harm in including them for the benefit of less casual readers. If the latter, I see your concern, but walls of what looks like fanfiction can have a similar effect. This issue is better solved by improving the quality of the writing and formatting, not eschewing sources.
"Utilizing reference tags is, quite simply, not the answer to any issue of "certainty of lore". Especially since so much of the lore is intentionally vague by ArenaNet." This vagueness, to me, is exactly why we MUST use more references. Consider the discussion we had yesterday regarding Elonia: My conclusion, based on the evidence, was completely different from yours. Which one of us interpreted correctly is immaterial: the point is, we have no way of being sure what ANet intended, so both of our conclusions are objectively valid. When you choose one interpretation and pepper it about the wiki like it was undeniable fact, you're misleading readers.
The wiki is a resource. Our duty is to supply the facts for our readers so they can draw their own conclusions. Our priority is to make this as easy for them as possible. Induced facts, while fine, must not be allowed to take precedence over the evidence. --Idris (talk) 02:22, 14 October 2017 (UTC)

(Reset indent) To explain my concern, which has been brought up before, please go to this edit, and scroll down to the === Arrival === section. Once there, please ask yourself how comfortable you are in editing those paragraphs if you felt it wasn't properly worded? How comfortable would the average user be? I know I couldn't contribute to it. I'm not joking.

Lore is like everything else on this wiki: It's going to come with errors. I believe Darqam's suggestion of making a project is a great one. How do we know what contents are in a bag? We ask the community. How do we know what NPCs look like? We ask the community. Will they ever be wrong? Of course, but we accept that, and do our best.

Wiki code stops editors from adding information. Templates stop them from knowing where to put information. References are just as debilitating. We shouldn't avoid them, but we need to use them well, or contributions can only come from those with special knowledge of how to contribute. G R E E N E R 17:27, 14 October 2017 (UTC)

@Idris: I meant the latter - too many citations may put casual readers (and editors, as Greener brings up) off. Walls of text are no better, but that's why we began putting images (usually related concept art) to space out the paragraphs of text. Konig (talk) 22:52, 14 October 2017 (UTC)
I think maybe we're focusing too hard on reference tags, here. Like I said before, the best solution to this (imo) is to improve the quality of the writing and formatting. Inserting pictures to split the page up visually is a good example of what I mean. To address the need for sources, it helps a lot that we're a wiki: interwiki links are easy to insert, and most of the evidence for any given claim is in another article on this wiki or gww somewhere. If we step up our wikilinking game, we can solve the issue of poor sourcing without flooding users with overly complicated code. I'll illustrate using some of my own recent edits:
  • Good example: Added an intro to Spearmarshal's Lament. I've used zero links here because I describe nothing that can't be immediately checked by someone standing at the point of interest being described. I refer to seekers by their ingame title, so readers can quickly figure out that they can click on the NPC links below to check their motivations.
  • Good example: Added a link to support a claim in the intro for The Sanctum. Pretty straightforward. The line claims that the Sanctuary "contains the sum of all knowledge", so I linked to a book in the library that contains the evidence for this.
  • Bad example: Added a sentence to the intro of Domain of Vabbi describing Vabbian culture under Joko's rule. This is pure opinion with no sourcing to support it. This opinion can be supported by evidence, but it's scattered out over many sources (I think I'd need about 4 links at minimum) and there's no reasonable way to seamlessly fit them into the sentence. As enamoured as I was with this idea when I added it, in retrospect, I think it could stand to be cut.
Note that "good example" doesn't necessarily mean I did these well, but they should give you an idea of the sort of thing I'm thinking of. --Idris (talk) 03:15, 15 October 2017 (UTC)
Greener, do I understand your point to be that when in the editing window, a large number of references breaks up the flow of text and makes a paragraph difficult to edit? I can see that, particularly with the example you cite. In that case I guess the thing to do would be to have the article open in one page (or a preview), and the editing window in another - far from ideal, I know. We could introduce the concept of a bibliography, where a list of sources are defined somewhere near the bottom of the page and then just referenced with a short piece of code as and when required, but then that butts up against your other point, that every additional piece of Wiki markup we introduce is another barrier to potential editors.
I'm sympathetic to that point - I believe that the Wiki should be as accessible to potential editors as possible. In fact, I think it's vital for the Wiki's survival, particularly where lore is concerned. But I think walls of unsourced and often obscure lore can be just as big a barrier to potential editors, if not moreso. Without references, if you saw something that didn't seem right or that you hadn't heard before, how could you go about challenging it? I know that most users just assume that whoever wrote the article must know better than them, and stay away. When I've tried to get people on reddit or on the GW2 official forums involved in editing lore on the wiki in the past, the number one reason that people cite for not getting involved is that they feel like they don't have enough lore knowledge. If statements made about the lore on the wiki are referenced, however, no special knowledge of the game's lore is required to be able to change or challenge content on the wiki's many pages on the subject. Then we aren't relying on just a small handful of users to create and maintain pages on all the lore for a series that contains four games and three expansions released over 12 years. Because when we have that, not only does it become impossible to keep up with the pace of releases (let alone all the lore from the initial release of the game in 2012 that has yet to be documented on the wiki - there's a lot of it, believe me), but also there's a perception that what is on the wiki is actually filtered through the interpretations of those small few lore editors.
Idris: I agree with what you're saying, but as a matter of personal preference I tend to use references rather than sourcing in the body of the text when I feel like it breaks the flow of the text (e.g. by breaking the fourth wall). So when I write wiki articles, something like "According to Devona, blah blah blah..." is fine, but something like "According to page 873 of Edge of Destiny by J. Robert King, blah blah blah..." I would tend to source with a reference instead. If we're going to proceed with things this way I guess we need to settle on a consistent approach for this as well. Santax (talk · contribs) 13:54, 15 October 2017 (UTC)
Oh, I wasn't suggesting we use awkward references like "According to page 873 of Edge of Destiny by J. Robert King, blah blah blah..." -- in that particular example, we'd have to use a ref tag anyway, since the referenced page doesn't exist as a wiki article. I was suggesting that we try to make as many of our references use the format "According to Devona, blah blah blah..." as possible. It'll be challenging at times, but I think it's worth the effort. And I like your idea of introducing bibliographies -- if we can get the template nice and small and simple, it might make for a good compromise. --Idris (talk)
I'm not sure a bibliography would be any form of improvement, really. Wouldn't it still add a long list at the bottom? Wouldn't it still break up a lot of text with wiki coding that new editors wouldn't be familiar with? Unless I'm picturing what you mean wrong, it feels like the same issue with a different coat of paint.
I think the best methodology would be to simply link the source in the paragraph. This does not require saying "According to such and such", but could be something like "Kormir promised her faithful that they would one day see this new world, a garden [...] that Tyria was supposed to be for humanity." No break in flow or the like, links to the source of the lore, no addition to a list at the bottom (and it occurred to me, the bottom could be solved by making the reference list collapsible - sadly this doesn't fix the issue Greener brought up, for wiki editors). Konig (talk) 18:32, 15 October 2017 (UTC)
I don't think long reference lists are all that bad when they're at the bottom of the article, shuffled out of the way where nobody needs to interact with them unless they want to. The problem, like you say, is with confusing code breaking the flow of the text in the edit box. When I gave the thumbs-up to bibliographies, I was imagining a template that would be no more complicated to use than {{skill icon}}, but after brainstorming on how that could be accomplished, I'm starting to think there isn't a way to make it that simple. So now I agree that a bibliography would be little more than a palette-swap for ref tags. --Idris (talk) 18:41, 15 October 2017 (UTC)
(Edit conflict) Yes, a bibliography would have a list of sources at the bottom, but I don't understand why that's a problem. For an article of its size, I think Forgotten has a good number of references - I don't think the list is long or unwieldy. Same with Six Human Gods - for an extremely long and text-heavy article, 19 references isn't too many at all.
The problem the bibliography solves is that, while in the Wikitext editor, you don't have paragraphs broken up by things like <ref name="Varra Skylark">[[Varra Skylark]] in [[The Ruined City of Arah (explorable)]] [[jotun]] path believes that [[the Mystic Telescope]] shows the last rise of the Elder Dragons to be about 10,000 years ago.</ref>; instead you can just use <ref name="Varra Skylark" />, which is much less disruptive to someone trying to copyedit from that particular interface.
I think using inline wikilinks to link to sources that are on the Wiki is a good compromise if people really hate the idea of using the referencing tool that already exists - it's certainly better than content on the wiki being unverifiable. To my mind though, it feels inconsistent and arbitrary - we'd be using a tool specifically built for citations when the source is hosted on an external site, and Wikilinks, which historically have primarily been used for entirely different reasons in mainspace, when the source is on the Wiki. We'd still have to use the referencing tool in some places, so it's not like there's more code to learn - it's basically just the same bit of code over and over again. Santax (talk · contribs) 18:54, 15 October 2017 (UTC)
Yes, Santax, that is the other side of the coin. I appreciate the growth of a middle-ground that you folks are building. I have faith in this discussion being fruitful for all of the community, from readers to editors. G R E E N E R 01:37, 16 October 2017 (UTC)
How possible would a bibliography be, technically? I'm thinking some kind of template placed at the bottom of the page that defines a list of references with each reference having a user-defined ID, which are then called out to by some kind of {{cite}} template that takes the reference ID as a parameter. It would differ from the way we can currently do things by replacing HTML-like syntax with template syntax, so it might be a bit more familiar to most editors, and it also means that references are entirely defined outside of the main article (currently, a reference has to be defined in the first part of the text body that uses it).
The other thing is that this would actually be more of a pain if there's only one or two references to include on the page, because for consistency's sake you'd probably still have to define the bibliography and then call out to it. For an article with only one reference, this might be not be an obvious thing to do. Santax (talk · contribs) 07:58, 18 October 2017 (UTC)
It's 100% possible. Even I could probably make such coding. However, I'm not sure it would solve any issue. To use your reference tag example, editors would still have to put in that long sentence of [[Varra Skylark]] in [[The Ruined City of Arah (explorable)]] [[jotun]] path believes that [[the Mystic Telescope]] shows the last rise of the Elder Dragons to be about 10,000 years ago. somewhere so that it may be appropriately cited (though I would say that sentence is needlessly long and could and should be shortened to simply [[Varra Skylark]] in [[The Ruined City of Arah (explorable)#Jotun|The Ruined City of Arah]] which would be much easier for newbie editors). It's potentially more confusing, since the cited note wouldn't be in the area that newbie editors would think of editing; unless I'm still misunderstanding your intended style of a bibliography template. It would ultimately just be changing using <ref></ref> to {{cite|}} and little to nothing more.
If the idea is that what's cited wouldn't be where editors would be editing for their addition, I'd say the reference tag is superior in regards to new editors adding new information. Konig (talk) 18:52, 18 October 2017 (UTC)
Agreed. The downside of having to add the source to a completely different section outweighs any benefits a bibliography has over <ref>. We could consider making a "cite" template anyway, that automatically formats the citation into <ref> tags, so users don't have to learn how to use html tags when they're already used to templates. It might make them simpler to use, even if it doesn't do much to reduce edit box bulk. --Idris (talk) 21:19, 18 October 2017 (UTC)

Ability to /wiki to the Game Release Notes forum section[edit]

I think it would be very useful if we could type '/wiki grn' or '/wiki GRN' in chat and be sent here as a result.

It doesn't seem to me like this would be a hard thing to set up, but it would involve an "external redirect," so I don't think I can do it myself. I assume more privileged, trusted users should be able to get it working, right?

It would go along quite well with the other shortcuts the wiki provides (like 'psna' and 'fl'). Ideka (talk) 01:11, 27 September 2017 (UTC)

I understand what you're asking, and whilst its doable, I'd suggest that we shouldn't do this. If we go down the route of allowing external redirects from the wiki, where would we stop? (/wiki google: xyz... /wiki dulfy: xyz). We document most of the release notes on the wiki already, and if you type /wiki Updates, the first link on that page is to the forum game release notes. -Chieftain AlexUser Chieftain Alex sig.png 19:10, 27 September 2017 (UTC)
That's a slippery slope argument.
But I did forget about the updates page already in the wiki, which looks really good. My main conern however is that I don't know how quickly that page is updated, and I imagine the main use cases of such a shortcut would involve using it right after a new update becomes available. Is the updates wiki page really updated fast enough that it could be used instead? --Ideka (talk) 23:34, 27 September 2017 (UTC)
In many cases, we're provided with patch notes in advance so we can format them, add article links etc, before the update goes live. So we often have them posted here within minutes, if not seconds, of the official patch notes going up on the forums. I'd say it's generally pretty reliable. - Felix Omni 19:45, 2 October 2017 (UTC)
Game updates are linked on the main page. Someone can type "/wiki" and click the update notes, without having to remember an obscure acronym--Relyk ~ talk < 03:28, 10 October 2017 (UTC)

Area maps[edit]

Hi guys. A question. Currently we add white area boundaries onto the area maps within zones (example)- it's something we've traditionally done since Dr ishmael did the first maps, but I'm not sure it's necessary since we have the locator maps (black, white and red svgs - example) anyway. Do we want to continue this tradition, or revert to using the world map as it appears ingame (example)? -Chieftain AlexUser Chieftain Alex sig.png 17:49, 11 October 2017 (UTC)

I like the white borders. The svgs are lovely, but they don't provide the same context as a white overlay on the actual map. --Idris (talk) 17:56, 11 October 2017 (UTC)
I'm going to second that, I like the white borders as they provide more context due to being directly on the map. - Doodleplex 17:58, 11 October 2017 (UTC)
^ Context. Granted, I'm also unaware as to how long it takes to get all of lines done. G R E E N E R 18:13, 11 October 2017 (UTC)
Fourthed. What they said. Konig (talk) 18:26, 11 October 2017 (UTC)
Well I'd still be doing the lines for the svg maps, so time saving isn't even on the table. -Chieftain AlexUser Chieftain Alex sig.png 18:27, 11 October 2017 (UTC)
Once again, very much appreciated. I'd buy you a nice pair of shoes, but apparently we can't gift across servers. G R E E N E R 18:32, 11 October 2017 (UTC)
I really like the white borders as well. Windshear Scarps is a great example of how they can give you an idea of the actual space. --Rain Spell (talk) 20:55, 11 October 2017 (UTC)

Wiki font[edit]

User Santax CronosPro screenshot.png

At the moment we use Arial for body text, as we did on GWW. We could bring the Wiki visually further in line to other parts of the official site (like or the official forums) by using Cronos Pro instead. We're already using the same font as the forums and for headers (Eason Pro), so why not do the same with body text? It's accessible through the CSS; I already use it on my user page and in my signature using <span style="font-family: CronosPro; font-size: 16px; color: #494b4d;">. Santax (talk · contribs) 14:54, 15 October 2017 (UTC)

I don’t think Cronos really works well for larger bodies of text. It only becomes readable at sizes above 16px and even then it’s not really easy on the eyes. I wouldn’t like that as the default font for our texts. If we change our font, it should be one that’s clearly designed for screen text bodies. poke | talk 07:37, 16 October 2017 (UTC)
I've just had a mess around in the browser CSS, changing article body text as 16px CronosPro, and it doesn't look too bad at all to me. Have a look on the right. Santax (talk · contribs) 12:50, 16 October 2017 (UTC)
I agree with poke here, it's just not a nice font for body text. -Chieftain AlexUser Chieftain Alex sig.png 17:28, 16 October 2017 (UTC)
I think Cronos looks alright as body text, tbh. It's got slightly more vertical whitespace, which might make bulky paragraphs more readable (albeit at the cost of making already-lengthy articles even longer, which may not be worth it). Btw Santax, your timing was pretty bad in making the "bringing it in line with the rest of the official site" argument, since the forums recently shifted away from Cronos in favour of what looks like Arial. --Idris (talk) 04:29, 18 October 2017 (UTC)
I just had a look at the forums; it's still CronosPro for me (except on the mobile site)? It might be that it's Cronos Pro Regular? Santax (talk · contribs) 07:45, 18 October 2017 (UTC)
It's definitely not Cronos Pro Regular. Cronos uses the "double loop" g, whereas what I see on the forums uses the "hook" g, same as the wiki. They are using a serif font of some sort for headers, though, which might be Eason Pro. --Idris (talk) 15:20, 18 October 2017 (UTC)
The new forums use the Cronos Pro and the Eason Pro families. Cronos Pro Regular is used for body texts, Eason Pro Regular and Eason Pro Display Caps for most headings. poke | talk 02:28, 19 October 2017 (UTC)
Guess it's buggy for me then, cause there's no way that what I'm looking at is Cronos. --Idris (talk) 03:30, 19 October 2017 (UTC)

(Reset indent) What browser are you using Idris, maybe that's causing it? And I'm not particularly a fan of it either, it doesn't read as easy for me. Out of curiosity though, what fonts do the other three wiki's use? Spanish most likely uses the same font as us, and if the French and German do as well, I'd prefer to keep the font consistent from wiki to wiki. - Doodleplex 03:34, 19 October 2017 (UTC)

Internet Explorer (I'm scum, I know), so it wouldn't surprise me if something broke. Glancing at the other three wikis, it looks like they're using Arial as well. --Idris (talk) 03:56, 19 October 2017 (UTC)

Archiving links to old official forums and GW2 Guru before they close down[edit] this something we're doing, or should be doing? Santax (talk · contribs) 15:21, 15 October 2017 (UTC)

I've seen people going through quite a few forum links. I'm not sure if there's a project, but there's definitely people working on it. --Rain Spell (talk) 02:57, 16 October 2017 (UTC)
Is it something that a bot could do? -- 07:44, 16 October 2017 (UTC)
Note that we unfortunately cannot legally host archived content from those forums on the wiki due to our licensing terms. So we would have to find a different way or figure out a way to make some archive that is explicitly not covered by the GFDL. poke | talk 08:08, 16 October 2017 (UTC)
Not sure if helpful or not, but see: --Tera (talk) 16:00, 16 October 2017 (UTC)
Very helpful! - Felix Omni 16:03, 16 October 2017 (UTC)
Am I doing it wrong, or do we only have ~30 links to the forum across the whole wiki? I'm trying to use Special:Linksearch http://* only has like 30 results for the forum. -Chieftain AlexUser Chieftain Alex sig.png 17:41, 16 October 2017 (UTC)
Yeah, I get the same result, guess that’s all then? – That link is super helpful Tera, thanks! poke | talk 19:38, 16 October 2017 (UTC)
You're doing it wrong 😛 try Special:Linksearch https://* Santax (talk · contribs) 19:47, 16 October 2017 (UTC)
For anyone wondering, the forum results start here:* -Chieftain AlexUser Chieftain Alex sig.png 19:52, 16 October 2017 (UTC)

(Reset indent) There actually might not be too many. I remember seeing somebody going through and changing links to the waybackmachine's website for some forum posts, but unfortunately I have no idea who it was nor when they did it. Additionally did ArenaNet say they were going to get rid of the old forums or are they keeping them as archived? - Doodleplex 19:52, 16 October 2017 (UTC)

I calculated there are 1223 HTTPS links plus 30 HTTP links. Personally I don't give a damn if it linkrots.. -Chieftain AlexUser Chieftain Alex sig.png 19:54, 16 October 2017 (UTC)
If we want to make content on the wiki more verifiable, not archiving forum links could be a mistake as many of them are in references, linking to developer comments. On the licensing front, a bot edit to just change the URL of the links to match the old forum archive link would work, right? We don't have to host the content ourselves. For Guru, we'd have to use Webpage archive or something similar, but we only have a couple days to do that. Santax (talk · contribs) 14:41, 29 October 2017 (UTC)

Anyone looked at how CUTE the Halloween themed French wiki is?[edit]

Their Halloween theme is adorable. And the top left picture changes too!--Rain Spell (talk) 20:06, 24 October 2017 (UTC)

They usually have some pretty awesome seasonal designs that I'd love to do too, but don't know if people would be alright with that idea(and I would usually forget to ask...derp). And I didn't even notice that it rotates, neat! =D - Doodleplex 20:09, 24 October 2017 (UTC)
Seasonal skins are always fun. It's not too late (or early) for us to start thinking about what we could do for Wintersday... --Idris (talk) 20:57, 24 October 2017 (UTC)
I do know we have a Wintersday setup for the wiki, but if we have anything else, it's news to me. - Doodleplex 21:01, 24 October 2017 (UTC)
Let's take a look at those Wintersday assets, then. We can't let those frogs show us up again! --Idris (talk) 02:10, 25 October 2017 (UTC)

Template for event npcs[edit]

Not sure if this has been brought up before, but I was wondering how likely it is that we could get a template for NPCs and events that works similarly to the contains/contained in templates and then retroactively apply it to all incidental articles? For example, for an event article we could have {{event npc|[npc name]}} and then for npc articles just have {{npc events}} under event involvement.

I understand that this is a large undertaking and can be troublesome to retroactively implement, but once implemented updating event npcs will be both easier and faster because you don't need to cross-apply updates to both articles. Sythe 04:14, 31 October 2017 (UTC)

While a neat idea, I'm afraid it wouldn't be too intuitive for new users, seeing as we had complaints about the wiki being too automatic already. —Ventriloquist 10:00, 31 October 2017 (UTC)
That's new to me, where are these complaints you speak of? We can do that, but it's a lot of work for little gain. Most NPCs are 1-1 with events and can generally be weakly related by the area they're located in.--Relyk ~ talk < 05:43, 14 November 2017 (UTC)
Most ally NPCs are 1-1 with events, yes. But foe NPCs (mordrem/risen/icebrood/etc.) are common in many events. Though, I do agree that it is a lot of work. Sythe 19:04, 14 November 2017 (UTC)

Point of Interest pages[edit]

So I think it might have been brought up before, I'm not sure. But basically I think we need some sort of guidelines or something for point of interest pages, since recently they've started to look more like area pages (ex: Throne of Pellentia, Junundu Hatchery, Godslost Sandfalls) than a mere "this is a cool box/spot/thing" and in general seem to be somewhat inconsistent due to really nobody knowing for sure what's what. I'm thinking perhaps we should only list NPCs/objects/etc if the point of interest is an instance, like Knut Whitebear's Loft or Queen's Throne Room (which I believe currently are the only two point of interests that are instances) to make it simple and to make sure the area pages are being properly documented. - Doodleplex 02:15, 14 November 2017 (UTC)

If we do that then the PoI articles will be utterly barren, and I'm rather opposed to that when we could use those (and landmark pages) for specifying "it's in this part of an area/sector". The main things that area articles have that PoI/Landmarks don't is map objectives and ambient dialogue. And I feel that's fine.
On an aside: Seraph Headquarters, Blood Tribune Quarters, Ash Tribune Quarters, The House of Caithe, The Dead End, North Nolan Hatchery, Captain Kiel's Office. Off the top of my head. Irrelevant in grand scale of things. Konig (talk) 02:40, 14 November 2017 (UTC)
I can see where you're coming from, Doodle, and I do think we could improve the situation. I would be inclined to tweak the area pages, though -- like Konig said, PoI pages are barren enough as it is. We could start adding (In <point of interest>) next to NPCs/objects on area pages?
On a (vaguely) related note, I'd like to praise User:Blackice for their initiative in adding directions to object locations on area pages (example) -- this sort of information is really useful and I can't believe we hadn't thought to do it already. --Idris (talk) 04:46, 14 November 2017 (UTC)
It's more useful to describe things on the area page and use the PoI as reference. Resource nodes and generic NPCs/objects tend to be ambiguous unless the PoI is a specific space like a structure or house. The PoI article should highlight information of why it's of interest (Many of which are not and are fine as empty pages). I don't care what we add as long as the same information is aggregated on the area page, which is our base unit for describing the locations of objects.--Relyk ~ talk < 05:33, 14 November 2017 (UTC)
Huh, looks like there are some instances that need to be categorized then. Anyway Idris, we have actually done that before, adding descriptions, but that's normally just for chests or rich nodes since otherwise the location should be described on the object or NPC's page so for the Pile of Sand objects that probably works well. And it also appears that for the most part the general consensus is the main content should be on the area page, use the PoI as a refence there if needed, and most point of interest pages, excluding those that are instances, should be primarily just a description of what they are and occasionally how to get there if it's needed, but that's it? - Doodleplex 01:11, 15 November 2017 (UTC)
Hi guys, I wanted to chime in on this topic. I'm kinda guilty of adding too much stuff to some PoI pages, and I agree that a sort of DRY KISS approach would be preferable. On the other hand, having pages like this one is just sad, especially if there are 60 something links to it. If a reader ends up there and misses the area link, he/she will just be confused and/or annoyed. I suggest using sections like Notable NPCs nearby and Notable objects nearby, both with a {{main}} link to the area page's section. Additionally, Crafting resources only for rich nodes, and maybe an automated Events starting nearby. Thoughts? -- Blackice (talk) 23:34, 23 November 2017 (UTC)

Icon swap[edit]

With the most recent hotfix (today's), the icons for Antique Hairpin and Cosmetics Palette were swapped. I was wondering if an admin had the ability to swap names for each icon, or if you have to manually create a temporary page just to swap them like anyone else. Sythe 04:55, 14 November 2017 (UTC)

I'm not an admin, but I do have the power to create a temporary page that will be automatically deleted once I've completed the move. That said, is there any reason why we can't just swap them by uploading new versions of each? --Idris (talk) 05:04, 14 November 2017 (UTC)
Done, but as Idris said, you can just as easy reupload the new icons over the old one, especially if you can't get somebody who can move the files around easily like Idris or I can. =) - Doodleplex 05:43, 14 November 2017 (UTC)

Waypoint links[edit]

I've seen a lot of pages with either incorrect or missing waypoint links on this wiki, the worst offender currently being Jumping puzzle. I'd imagine that's because some users here are unsure how to handle these links. So, what's the preferred way to link to waypoints?

  1. No link at all: Commons Waypoint
  2. Waypoint template:
    Waypoint (tango icon).png
     Commons Waypoint
  3. Area page link with id: Commons Waypoint (i.e. District Promenade#Commons Waypoint)
  4. Using redirects: Commons Waypoint (note that this specific redirect currently just links to the area page without an id)

Option 2 looks weird in running text, option 3 is is error-prone to typos (the link appears blue even if there's a typo in the waypoint id), and option 4 has some (minor) performance issues and a lot of new redirects would have to be added. I guess option 2 could be improved by adding a parameter to the template to hide/suppress the chatlink, so it'd look a bit better in prose/running text. --Blackice (talk) 13:29, 4 December 2017 (UTC)

  1. Links should be used where possible unless it confuses the prose.
  2. Imo, the icon template with link should only be used in bullets or tables.
  3. Linking to the area page is unusual - I've never seen that.
  4. I'd be surprised if there were many waypoint redirects missing. I created loads for the core game ages ago. Category:Map redirects. Linking to the redirect would be my preferred option
-Chieftain AlexUser Chieftain Alex sig.png 13:44, 4 December 2017 (UTC)
Ok, thanks for clarifying that. I'll use the redirects and add some missing ones. :) -- Blackice (talk) 14:08, 4 December 2017 (UTC)
I will say for #2/waypoint template, in terms of things like finding items for achievement collections and such, it's more preferred to have the chat link on the same page because then all the info for finding/getting the item is on one page. I think I've done 3 in a few places since I'd rather link directly to things than use redirects, but that was more likely just for scout NPCs, so if it's elsewhere, that (probably?)wasn't me. - Doodleplex 17:14, 4 December 2017 (UTC)
I've definitely altered some collection/tricky to find story npc locations to feature the chat code link. It's just so much more convenient, even if it messes up the prose. It'd be cool if we could work in waypoint locations in the npc infobox. I don't know how feasible that is, but it would solve the "issue" (however minor) entirely I think. (And it'd be even more convenient!)--Rain Spell (talk) 20:19, 14 January 2018 (UTC)

Sigil/rune overview pages[edit]

These are mostly pointless - should we keep them? Most people will be searching for the Superior version, and there is a naming conflict between PvP sigil/runes and the overview pages.

I would like to create the pvp sigil/rune pages using their precise ingame names (result of User talk:Chieftain Alex#Templates and icons), and either (i) move the overview pages to "Rune of <name> (disambiguation)", or (ii) delete the overview pages entirely. -Chieftain AlexUser Chieftain Alex sig.png 18:14, 6 December 2017 (UTC)

Vendor lists involving profession masters[edit]

The Snowflake page highlights a pretty obnoxious problem with how named profession master NPCs are handled. Namely, that they all have the same inventory, and any item that they sell will be listed a million times if you try to make a vendor list for an item they sell, or in this case, a currency they use for an item. The items sold by them seem to all use a convention where they just link to "Master X" rather than making a vendor list to avoid this issue (which isn't ideal to begin with), but Snowflake in particular can't do that because it's used for some things that aren't sold by profession masters.

Unless there's some way I don't know about to make Snowflake's page ignore all the duplicates from the numerous named profession masters, my solution would be to blank the inventory of all the profession masters and just refer them to the generic page to see the list. Though from what I remember this kind of action can leave phantom entries from some of the previously-listed NPCs lingering some of the time

Thoughts? Solutions? --Gimmethegepgun (talk) 00:36, 22 December 2017 (UTC)

I'm mobile atm, but I believe that table can be simplified to just be anything that’s not the inscription, and just add "Any master x, x, and x for y amount." Look at Mithril Logging Axe as an example. - Doodleplex 03:10, 22 December 2017 (UTC)
Ugh, now that I'm not mobile, I see it won't work, because one of Fion's item's has the same Snowflake cost as the inscriptions. Alex is on vacation, when he get's back he might know a way to set up the vendor table to exclude certain item types (since that's easier than vendors), so in the meanwhile the "easiest" solution I can think of(since there's less than 10 items), is just to list everything that's not an inscription manually via a table on the Snowflake page. - Doodleplex 19:26, 22 December 2017 (UTC)
Would it be possible to group vendors together by the service they provide? We could have a list of vendors that always share their inventories and whenever they have an item list them as Any Master Leatherworker? J.Tesla (talk) 20:06, 22 December 2017 (UTC)
Most (if not all) vendors have the Has service property set. It may be possible to modify the Template:Vendor table to list vendors by service, but I doubt I could do this without making an ugly, complex, convoluted mess out of this template. Creating something like Template:Vendor table by service is a better option, I guess.
I kinda like Gimmethegepgun's original suggestion where you'd move the master craftsmen's inventories to pages like Master Armorsmith and use these as sort of generic NPCs. This should work without modifying any templates.
Also, regarding to what Doodleplex said previously, excluding individual items from the vendor table is a simple one-liner like:
{{#arraymap: {{{exclude items|}}} | ; | @@@ | [[Sells item::!@@@]] | }}
Just my two Copper coins. —Blackice (talk) 10:10, 25 December 2017 (UTC)
Uhhh, vendor table is not the place to do that... Create a template to query all NPCs that sell the item and use a formatting template to group by NPC service.--Relyk ~ talk < 06:30, 30 January 2018 (UTC)

Updating links to archived forum[edit]

Hey folks, I received the following message via the forums a while back, but only recently did I log in to read it. I find the idea intriguing, and would love to hear the community's thoughts.

As you know, ANet has allowed the the old forums to wither away. Fortunately a kind player is hosting an archive of them at I am wondering if you can invoke the made coding skills of Chieftain Alex or Dr Ish to create a bot to fix any links/citations on the wiki that refer to the old forums.
The steps would be something like
That will work for 90% of them, except in some special situations, for example:
  • 'forum/support/account'
That folder got merged and the correct one is
  • forum/support/support
I can't imagine that there are many wiki cites that go to other folders that have been merged, but if I were a coder, I'd probably double-check the reformed URL to see if it's a 404 error. So far, the new paths haven't been hard to figure out.
For example, I just fixed a cite on the /world#transferring article from
Of course, it would be better if the archives were hosted by ANet; who knows how long will be maintained. I confess I don't understand why ANet couldn't maintain the database in closed format, as the hoster managed to do. But, well, it doesn't cost me anything, so I can pretend it's easy and cheap.
If the wiki uses a template for forum citations, then the archives can be moved and only the template would need to be adjusted. The downside would be that only template-using citations would work that way, so folks would have to make sure that new citations use the template.
Something like var site =, which replaces the old and could in the future be replaced by e.g., if was used in the future
tl;dr do you think it's worth updating the wiki citations & other links to the forum archive, so that they aren't lost?

From my perspective, saving information from obscurity is a good thing. We've been slowly moving links on the gw1w to Anet's own archived website for years now. While the may not be owned by Anet, it would serve a similar useful purpose. Also, if I missed such a conversation on the wiki before, my apologies for bringing it up again ; ). G R E E N E R 20:37, 20 February 2018 (UTC)

Alright this sounds like a good idea I've started the bot run (it's only 312 non-talkpage non-userpage unique pages with forum links). -Chieftain AlexUser Chieftain Alex sig.png 22:22, 20 February 2018 (UTC)
1Yes Should be done in the mainspace and non-talk non-user pages. --Chieftain AlexUser Chieftain Alex sig.png 22:42, 20 February 2018 (UTC)
Did most of the talk/user pages too. I was lazy and missed out the /tech ones -Chieftain AlexUser Chieftain Alex sig.png 23:42, 20 February 2018 (UTC)

Boxes in Boxes and Pages in Pages[edit]

Hello everyone, I'm here to shake-up the current version of the Wiki which I find extremely frustrating, hard to use and especially a pain in the ass to edit due to the "rules" that you have here. There were multiple threads on Reddit regarding Wiki and a lot of complaints came from the fact that information is not easy to find and it requires multiple clicks.

One of the main issues that I personally have with our wiki is the fact that I am required to click and click in order to get to what I'm interested instead of having the relevant information directly available instead of having it on different pages for "archiving purposes".

It's been a while since I've edited anything on a wiki, so bear with me.

Things that need to change:

Containers such as reward boxes should have all the contents listed and if any armor / skins are available, have them directly displayed on the page of the main box. Every other box can be displayed in a tree structure but the main rewards should be directly available.
Collection items should have the means of acquisition directly on the page. No more pages to click just because one is an item and the other one is an item of the collection. That's pointless. If a user wants to find a collection item he should be able to do so with a simple /wiki and no other clicks.
Skin / Armor codes are useless outside of the game on a wiki page. If a page has codes but doesn't have images, images should be added next to the codes.
Improvements to "galleries". Larger images, set location for screenshots, etc.

tl;dr, no more pages in pages. Markus Clouser User Markus Clouser signature img.jpg 10:37, 6 March 2018 (UTC)

Could you perhaps give examples of what you're describing so we can better see the changes you are asking for? E.g. you ask for reward boxes to have all their contents listed, yet I believe we strive to do exactly that. A bit more clarity would help me pin down what you're unhappy with, and what adjustments you're hoping to see happen. G R E E N E R 16:25, 6 March 2018 (UTC)
Happy you asked. I will be making a list here of all the pages that I have issues with. I will keep on adding but I can assure you that I will NOT be making any edits to any of the pages.
Let's begin:
* - No gallery for armor.
Markus Clouser User Markus Clouser signature img.jpg 00:23, 7 March 2018 (UTC)
We don’t usually have galleries on container pages like that(would blow the page up I think is why), but links to the armor overview pages where the galleries can be found wouldn’t be a bad idea and could be added. - Doodleplex 00:30, 7 March 2018 (UTC)
I added links to the top of the page. G R E E N E R 03:42, 7 March 2018 (UTC)
Part of the problem here is people's lack of inclination to upload gallery images themselves. -Chieftain AlexUser Chieftain Alex sig.png 07:45, 7 March 2018 (UTC)
Regarding what Markus Clouser said initially: I think it's true that this wiki currently has a bit of an issue with item data split up over too many pages. I'm not saying this is "wrong" or overly complex per se (I mean "Boxes in Boxes" is not a wiki issue; it's the game's issue), but I can acknowledge that other users might find the wiki confusing. One long term solution would be to add mouseover/hover tooltips to item links that show the item's stats, and maybe a gallery image, at a glance. I guess this "solution" has been discussed previously, and I doubt it plays well with MediaWiki, but I just thought I'd mention it. --Blackice (talk) 23:29, 10 March 2018 (UTC)
Update: Just noticed that the tooltip framework qTip2 is currently used on this wiki as part of the Semantic MediaWiki extension. Example:
I'm a fancy tooltip! Mini Maraca Choya Pinata.png
. Seems like setting up item tooltips would only require a bit JavaScript. --Blackice (talk) 20:48, 19 March 2018 (UTC)