Guild Wars 2 Wiki talk:Community portal/Archive 15

From Guild Wars 2 Wiki
Jump to navigationJump to search

Vista-file-manager.png
Archive

This page is an archive. The contents have been moved from another page for reference purposes only, and should be preserved in their current form. Discussion or voting on this page is not current. Any additions you make will probably not be read.
The current version of this page can be found at Guild Wars 2 Wiki:Community portal.

Skill history pages

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

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

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

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

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 GuildWars2.com or the official forums) by using Cronos Pro instead. We're already using the same font as the forums and GuildWars2.com 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

...is 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? --81.103.238.198 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: https://forum-en.gw2archive.eu/ https://www.reddit.com/r/Guildwars2/comments/75abh9/release_old_forums_archive/ --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://*.guildwars2.com 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://*.guildwars2.com. –Santax (talk · contribs) 19:47, 16 October 2017 (UTC)
For anyone wondering, the forum results start here: https://wiki.guildwars2.com/index.php?title=Special:LinkSearch&limit=500&offset=29091&target=https%3A%2F%2F*.guildwars2.com -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?

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

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

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

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

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 (map 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

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

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

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 gw2archive.eu. 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
to
Of course, it would be better if the archives were hosted by ANet; who knows how long gw2archive.eu 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 = gw2archive.eu, which replaces the old guildwars2.com and could in the future be replaced by e.g. wiki.guildwars2.com, if forum-en.wiki.guildwars2.com 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 gw2archive.eu 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

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:
* https://wiki.guildwars2.com/wiki/Desert_Armor_Box - 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 Piñata.png. Seems like setting up item tooltips would only require a bit JavaScript. --Blackice (talk) 20:48, 19 March 2018 (UTC)

Further reaching out to the GW2 community

Hi folks, an idea has been rolling through my mind for nearly a year now, and I admit it's my mistake for not bringing it up earlier. I've been hesitant because I know it may be a sensitive topic, but that shouldn't mean we avoid it.

The Guild Wars 2 community at large is vast and varied, and the wiki constitutes just a portion of what's out there. We have focused on providing players with useful information in text or picture form as that's the medium we have at our disposal. We know though that some information just cannot be captured by words or single images, and that's the subject I would like to bring up now.

Previously, there was a small discussion around a "Life in Tyria" video featuring devourers on the devourer page. I had mentioned that I'd be interested in seeing this expanded, but I did not push the topic further as the discussion garnered little interest. After seeing this video showcasing Auric Basin, I'd like to open the discussion again in a more open forum. Mainly, how do we feel about including high quality overviews of topics which add to the information the wiki is trying to provide? Obviously judging such things is subjective and prone to disagreements, but would we be willing to consider such additions at all?

Do feel free free to express your thoughts, and I fully admit that I'm not sure where I stand on this topic. I've learned though that this community has a habit of taking a small idea and refining it in surprising ways. G R E E N E R 00:46, 28 March 2018 (UTC)

Part of me worries about this being a slippery slope -- I've seen trivia sections on other wikis get bloated with cringy crap because people kept adding dubious links that only made sense in their own minds -- but in fairness, I don't think I've ever really seen "external videos" sections suffer the same fate, and our trivia sections are pretty clean compared to some other wikis anyway. So, as long as we're clear and open about what sort of content we're okay with adding, I'm not against this idea. --Idris (talk) 02:26, 28 March 2018 (UTC)
I don't think the discussion is about what we put in the trivia section. Most of the time, that tells me the video serves no purpose for the article.
Videos of panorma shots of areas over in-game would be super easy to add to articles. There aren't any roadblocks for adding that kind of content to the wiki. Most of discussion related to videos was for jumping puzzles, and I feel that we overcompensated at this point with settling for general Youtube links and that sets the precedent for the rest of the content.
Video guides and walkthroughs are much harder to sell on the wiki and I don't think we will provide a place to have those ultimately leave creative control to the creator. Those are hot spots for bikeshedding and requiring additional moderation that we either can't or shouldn't handle. Other sites like the forums, guild websites, Youtube, or Dulfy do a much better job and I haven't seen that situation change in the years the wiki has been up.
Stuff that is on the table to me would be panorama shots, in-game dialogue audio and/or video, animations, in-game cutscenes, and other content that doesn't require an authorative or personal view to present.--Relyk ~ talk < 04:32, 28 March 2018 (UTC)
"I don't think the discussion is about what we put in the trivia section. Most of the time, that tells me the video serves no purpose for the article." -- To clarify, I didn't think we were talking about the trivia section; I was drawing a parallel to it because, like external videos, trivia tends to be quite subjective, and sometimes people will add things like "this NPC said "I'll be back", which is a reference to The Terminator <link to imdb page for the Terminator> <link to youtube clip of that scene from Terminator> Also, the NPC is muscley like Arnold Schwarzenegger. <link to Arnold's Wikipedia article>" -- but it'll turn out that the NPC was just some norn announcing that he was going out to market and there's no intended reference whatsoever. But because that dubious trivia was added to the page, other editors would feel emboldened to add dubious references their own favourite canons or memes. Like I said though, I don't feel like there's a huge risk of that sort of thing happening in this case. --Idris (talk) 11:58, 28 March 2018 (UTC)
My main concern with adding videos is that videos are hard to maintain. They're tougher to make quality videos compared to text or images, so the bar is higher for entry which feels counter-intuitive to the wiki's purpose. If the content the video is representing changes, the video is less relevant and would need updating, and that could easily mean making a whole new video. There's also the matter of the quality control itself, similar to what Idris brings up - making sure those videos added actually are accurate and of good quality to reflect the wiki. And there's a risk of "picking favorites" among editors - some may view Video A of Content X to be a better quality than Video B of Content X, but other editors think the reverse or even Video C is better - what would be done then? Link just one (how to choose?) or link them all (where does it end? the 10th video?). That last bit is why we made {{youtube}} and I rather prefer that over the hassle of the rest. Konig (talk) 17:32, 28 March 2018 (UTC)

Achievement blow up

So I don't have an issue adding related achievements to pages where applicable, but I do have an issue when it starts to blow up the pages to nearly double the size due to the {{tl|achievement}} template being used, and on mobile devices, the template doesn't even work right at all and just breaks(which is probably fixable on the template I imagine). I was wondering if perhaps we could avoid using that oversized template on things other than the acquisition section on item pages and story page's achievements and perhaps just do a text link instead which would leave space for a short explanation or maybe add a "related achievement" section in infoboxes. Not to mention, a giant box doesn't really provide much help when the link to said achievement can be a tad obscure, I've come across a few things where I was honestly confused as to why there was an achievement template there and had to dig around, which isn't particularly helpful for your average user to have to do. - Doodleplex 21:08, 31 March 2018 (UTC)

I like the amount of information a full template box provides compared to a simple link, but if it's causing bloat and display issues then yeah, we should probably swap it out for something else. My screen is small enough that wide templates like that one tend to create a lot of whitespace, which I'm not a fan of. Maybe we should redesign the template to be more compact? --Idris (talk) 21:14, 31 March 2018 (UTC)
@Doodle, can you give us some examples of where you feel its currently taking too much space, and tell us what type of device - can you take a screenshot? Help us find out what's broken and we can assess what can be done. -Chieftain AlexUser Chieftain Alex sig.png 21:26, 31 March 2018 (UTC)
Alex, if I knew how to take screenshots on my phone I would, I honestly don't have a clue because the darn thing has a mind of it's own. =< Basically it either hits the side of the page and the table sort of looks like the ending column of tiers and such is all mushed together or it just gets cut off and I can't make the page scroll sideways. (Additionally [[Template:Bags nav]] is even worse, it covers the side navigation completely and goes off page on the other end.) 5 Bauble is the only thing I can think of where it's taking up a lot of space, it went from being a page that didn't even have a scroll bar to where all of the related achievements is half of the page's size.
Idris, it wouldn't be a single link, it would be more like maybe :'''[[Link to achievement page/achievement category pate|<achievement name>]]''' - <brief explanation>". So if there was an achievement involved feeding a muffin to a moose, on the moose page it could be :'''[[Community#If you give a Moose a Muffin...|If you give a Moose a Muffin...]]''' - Feeding any moose one muffin. Gives the name of the achievement, goes to achievement category page, gives brief info on why the moose is involved. - Doodleplex 21:41, 31 March 2018 (UTC)
I dunno. A lot of walkthroughs for achievements show up on the articles for related events/objects/etc because the achievement is too complicated for a note on the category page, but too straightforward for a dedicated article. I'm not keen on removing easily identifiable markers on such pages that say "This is what you're looking for! Achievement walkthrough here!". Yeah, that's the TOC and header's job, but people still tend to scroll blindly anyway. --Idris (talk) 06:20, 1 April 2018 (UTC)
Achievement template was meant primarily for achievements that had specific pages since the objects are stored at the achievement category. The template is overkill for most other places where you don't need to dump all the information. We never identified a succinct version for general use. It's particularly distracting on acquisition sections for items, world boss pages, and some other places.--Relyk ~ talk < 07:01, 1 April 2018 (UTC)
That's why I suggested a compact redesign, or a new template that's specifically intended for Related Achievements sections. --Idris (talk) 15:40, 1 April 2018 (UTC)
Well if we want to start with a few examples of the current layout, both good and bad.
  • A Family Heirloom - an achievement guide page. Probably the original intention of the template. Good.
  • Pylon Attunement: Blue - a short page, the box tells us there's an achievement associated. Seems okay.
  • Time Trial - Width of descriptions misaligns everything. Ugly.
  • Bounty#Related achievements - Quite a lot of them. Could be combined or linked as a bulleted list to the achievement pages? Borderline bad.
  • Sniper Volley - a skill page for an object. I would only expect to find this template on the related event page. Bad.
  • Plush Armchair - a decoration page. Imo the achievement template is out of place here. Bad.
-Chieftain AlexUser Chieftain Alex sig.png 18:06, 1 April 2018 (UTC)
Out of what the template currently shows, the only important things I think would be needed/would want to know about in regards to an achievement are the name of the achievement, the category it's in, and whatever the reward is(if applicable); I wouldn't add the description because often those are fairly vague and don't really help. Perhaps for effects, the infobox could have an achievement parameter since there are a decent number of effects that track achievements. As for what the new template would be, not entirely sure, it sounds like we need two new templates not one, i.e. one for item acquisition(since that gets bulky fast for some stuff) and another for related achievements for just about everything else. - Doodleplex 21:55, 1 April 2018 (UTC)
So after messing around a bit, I think the Effect infobox should get rid of the "story chapter" part(it doesn't seem to work anyway), add in an optional achievement parameter to go to a walkthrough for an achievement/the achievement's page if it exists, and leave the instance part as is mostly but tweak it to go to the achievement section of a story instance(done by [[{{{story}}}#Achievements|{{{story}}}]]). My thinking is nearly all achievement related effects are linked to story instances, and the only one I could think of that isn't is Key Hoarder which is part of Open Skies: Sunspear Wisdom, and those tweaks would cover both things. This way people would pretty much go directly to a page using the achievement template in the way it was meant to be used and get a lot a information about the achievement instead of being a bloated box that may not be very clear on an otherwise tiny effect page. - Doodleplex 16:02, 8 April 2018 (UTC)
(putting in the same indentation because continuing the above, just at a later time) Also, I have an idea for something I've been trying to get figured out for a while now and might have the answer. What if for item acquisition, instead of using the achievement template, we have something similar to how the "Dropped by" template, except it would be called "Rewarded by" and only list what source that rewards the item and the source type. It would list anything that rewards an item, which would cover pretty much nearly everything that we've had to write in manually, aka: dungeons, story rewards, activities, adventures, and events as well as achievements. So something like this:
Source Source Type
Kill the megadestroyer before it blows everyone up Dynamic event
Setting the Stage Personal story
Honor of the Waves Dungeon
Lion's Arch Exterminator Achievement
On Wings of Gold Adventure
Southsun Survival Activity
Also it would collapsible like the Drops table is, preventing an item like the from bloating up pages. Additionally, "Template:Rewards" isn't being used and would fit nicely for what would populate the "Rewarded by" template. As for the how, well, pretty much the same as the "Dropped by" template except perhaps use the property "Gives item" which already exists and make a new page property called "Has source type" or something for the second column. If it's not too much a hassle, maybe do the same thing as the vendor list having historical NPCs grayed out except grayed out for things that are historical like some achievements and such, but that's not really a must have imo. - Doodleplex 23:16, 8 April 2018 (UTC)
The more I think about it, the more I think that achievements on NPC/Object/Item pages should just be a section called "Achievement involvement" and either use a template similar to the {{event}} or {{heart}} templates(maybe called {{tl|achieves}} or something and goes to either the achievement's guide page or achievement category page perhaps?) or a text link(whichever is easier). Consistent, clean, and wouldn't cause mayhem. - Doodleplex 23:02, 12 May 2018 (UTC)
That's a pretty good idea, actually. --Idris (talk) 23:26, 12 May 2018 (UTC)
Glad to hear. Would you mind if I used my bot to at least change everything on NPC and object pages into a text link until either somebody makes a template or we all just get used to using the text setup? The rest I'll try to do when I have proper computer access and not just limited borrowing of computers(and when I'm not still kinda sick). - Doodleplex 22:12, 4 June 2018 (UTC)
The proposed template sounds pretty straightforward, so would you mind if I mocked one up first? Then we can just directly use the new template instead of having to do two sets of mass edits. --Idris (talk) 22:28, 4 June 2018 (UTC)
Be my guest. And if you could do the rest, I'd be grateful. I really, really, really hate not having reliable computer access. =< - Doodleplex 22:30, 4 June 2018 (UTC)
You can already do source type for page properties related to items if they have a context type. That's the whole point of describing the property on the page that is the source of the item. Properties like "Gives item" and "Dropped by" aren't very good names unfortunately because those are generic enough to apply to multiple source methods. If semantic properties actually worked with subtypes, we'd be subtyping all those properties as [[Property:Has item source]].--Relyk ~ talk < 05:34, 5 June 2018 (UTC)

(Reset indent) Finished mocking up the proposed template on my sandbox (Edit: Now has its own page on {{achiev}}). I don't have much experience with SMW-heavy templates so this needs polishing, but the basic idea is:

Justice of the Blade.png Justice of the Blade: Informed Politics — Investigate posters in Kryta's towns and villages to stay up to date on public opinion. (11Achievement pointsSatchel of Poster-Making Supplies)
Justice of the Blade.png Justice of the Blade: Bounty Hunter — Complete 3 daily bounty orders from the Shining Blade. (5Achievement pointsRepeatable (AP is capped at 30)Shining Blade War Supplies)

What do we think? --Idris (talk) 06:01, 5 June 2018 (UTC)

I'd put icon tags before prose like the description so icons don't get wrapped to next line or something. You can add a fixed indent of the like 4 spaces to fill in applicable icons.--Relyk ~ talk < 06:08, 5 June 2018 (UTC)
Hm, I can't really get them to look good when I clump them all together at the start. The trouble with adding whitespace to make them align nicely is that there's a number thrown in there in a variable-width font, so they're pretty much always going to be misaligned unless we use a dorky fixed-width font. I don't think achiev descriptions are usually long enough that they'd be likely to spill onto another line, anyway; and sticking the AP at the end helps it resemble the format we already use for {{heart}} and {{event}}. --Idris (talk) 06:36, 5 June 2018 (UTC)
I like it. Nice, simple clean, gives all the information without being over sized. - Doodleplex 22:25, 7 June 2018 (UTC)

Update on achievement templates

So we've had some discussion on the wiki Discord:

  • The old "Template:Achievement" has been moved to "Template:Achievement box" -- this is the one that provides a box with information on one achievement.
  • "Template:Achievement box" now uses only the "name" and "category" parameters -- parameters 1 and 2 were combined with name and category as part of the bot cleanup.
  • The new "Template:Achieve" has been moved to "Template:Achievement" -- this is the one that is to be used in a bulleted list and provides information on one achievement.
  • The new template has two parameters "1" (unnamed) and "category".

Kinda related:

  • "Template:Achievement infobox" has been entirely replaced with "Template:Achievement box" -- it wasn't used much and presents the same information.
  • "Template:Achievement list" has been removed where it was only used to return one achievement with the "reward" parameter with "Template:Achievement box"

You are now all free to change any "achievement box" usage to "achievement". -Chieftain AlexUser Chieftain Alex sig.png 10:19, 9 June 2018 (UTC)

Thank you for doing all this clean-up work! My suggestions for where we should use "Template:Achievement" (bullet) vs "Template:Achievement box" (box):
  • Related achievements sections on NPC/object/item/event etc articles should obviously use the bullet variant, since that was the original goal for this new design. We can possibly move that section further up the page now that it doesn't take up so much space.
  • Achievement sections in story/fractal/raid walkthroughs could use the bullet variant, since they're very prone to bloat as it is. Edit: This looks terrible though.
  • Articles whose focus is an achievement (eg, Speedy Reader) should use the box.
  • I'm not sure how to handle acquisition sections on item articles. I'm leaning towards bullet since we don't put huge amount of information in there for other types of sources box because it doesn't seem to bloat those types of articles. The only problem is for items granted by multiple achievements, in which case {{achievement list}} is the best option, but afaik there are so few cases like this (if any?) we don't really need to rely on SMW or worry about long lists of boxes.
--Idris (talk) 10:55, 9 June 2018 (UTC)
I'm wondering whether we should dumb down {{achievement list}} so that it doesn't calculate the total AP at the top. This would reduce the size of those tables. -Chieftain AlexUser Chieftain Alex sig.png 11:08, 9 June 2018 (UTC)
God yes, I've always hated that enormous header. --Idris (talk) 11:16, 9 June 2018 (UTC)
For NPC/Object/Item pages, I'd rather it be "Achievement involvement" for consistency. For Story stuff/dungeons/achievement pages I'd rather leave the box as is. For effects, I'd much rather use the infobox itself since that was already half set up to start with. - Doodleplex 14:42, 9 June 2018 (UTC)
"Achievement involvement" could end up being less consistent in the long run, because we have quite a wide variety of articles that have "Related achievements" sections but never have "Heart/Event involvement" sections -- adventures, events, other achievements, etc, which Alex pointed out on discord are probably better off with having "Related achievements" down near the bottom of the page, like a sort of specialized "See also". If we're going to use that approach for some pages, I'd rather we used it for all of them. --Idris (talk) 03:56, 10 June 2018 (UTC)
Just wanted to chime in too and thank everyone involved for the discussion and change. :) The more simplified Related Achievements listing will be useful for NPC pages in particular (see e.g. Taimi who has quite a few achievements linked to her), and I'll go ahead and start updating the achievement sections on the relevant NPC pages that I come across. I tried to glance at Discord conversations but couldn't find whether a decision was made to place Related Achievements between the Notes and Trivia sections on NPC pages from now on or keep them between Drops and Notes sections as the "NPC formatting" page currently suggests. Any update on the matter? --Kossage (talk) 15:29, 17 June 2018 (UTC)
The current consensus seems to lean towards treating achievements sections as a specialized "See also" and placing it immediately above the see also section. (The formatting guides haven't been updated yet; they were designed with the big space-filling boxes in mind.) Someone will probably use a bot at some point to switch achievement boxes to the new template en masse, and the exact positioning of the sections can be sorted out then,(Edit: I'm a jerk who doesn't understand bots) so go ahead and start making changes if you like. :) —Idris User Idris signature.png 16:59, 17 June 2018 (UTC)

Hyphens in time adjectives

I don't know where else to ask this. Is it preferred to say something like "10 minute event" or "10-minute event"? It seems from my (quick) searching there should be a dash or hyphen in the amount, but since most people don't do it, what's the convention here (new to wiki)? Does anyone care if I go and change these? --Notme (talk) 03:08, 17 April 2018 (UTC)

Here's what our general formatting guide has to say. As you can see, it doesn't really address your question; I think on the whole we don't really care so much about cases like this. If you're editing a page for some other reason and happen to spot a missing hyphen, then fix away, but I don't think it's worth flooding the recent changes with a hundred "(+1 byte) added a hyphen" edits for. --Idris (talk) 22:31, 17 April 2018 (UTC)
the dash looks really weird to me, I'm not sure its worth changing tbh. -Chieftain AlexUser Chieftain Alex sig.png 17:55, 18 April 2018 (UTC)

Widget code review request

→ moved from User talk:Chieftain Alex

Hey Alex, per the discussion on Greener's talk page, can you please look at Widget:Game mode buttons and tell me if that widget is okay to use for non-userspace pages? —Nefastu 18:31, 7 April 2018 (UTC)

Why does this introduce a dependency on jQuery UI? Also, could we keep the button styles inside the Template namespace? Otherwise we could probably have this toggle functionality easier and cleaner with CSS rules.
Do you have an example of this in action? poke | talk 23:06, 7 April 2018 (UTC)
Ah, found one on User:Nefastu/Projects/SVH template rework/Demo1. There appears to be a bug when you switch quickly between the modes. The button press seems to be ignored when it’s still transitioning. Also not really a fan of those borders inside a border. Removing the border and setting the default background to transparent looks a bit better to me. poke | talk 23:12, 7 April 2018 (UTC)
Hey poke, more links can be found on User:Nefastu/Projects/SVH template rework.
I'm using jQuery UI for the highlighting effect, since (at least to my knowledge) jQuery does not have a nice way to highlight specific elements.
Regarding the unresponsive button: This is due to the highlighting effect introducing a bug if one is switching game modes too fast: multiple game modes would be displayed.
Regarding the CSS/design: This is not my strong suit at all - if you have a better design, feel free to replace the current. :D Moving that section to the mediawiki css would be a better place for that as well, I agree. —Nefastu 00:04, 8 April 2018 (UTC)
So you're using jquery solely to apply a different colour with :hover/:active, and apply a 2px border?
Would using this require rewriting all the skill infoboxes to have separate pve/pvp/wvw facts? (triple workload?) -Chieftain AlexUser Chieftain Alex sig.png 00:44, 8 April 2018 (UTC)
If we want this flashing effect, then we should probably roll our own instead of depending on a rather big library which main purpose is actually interactive components :D
Before going that route, I would recommend bringing this idea up with the community though. Right now, split skills are physically split over multiple pages. While this may seem wasteful when the skill versions are that similar, I do think that it’s still a bit easier to grasp and also easier to track. Having this all mixed in a single page might be a bit too confusing. I also fear that eventually ArenaNet will go the route they did with GW1 where they started completely changing the skills in PvP. So just switching the skill facts might not be enough, and we might need to replace even the skill description or need some place to put trivia.
I’m not saying that your idea is bad or that your work is wasted. No, I think it’s a very cool idea! But we should probably look at this problem together so that we can make sure we are not missing things that will be difficult to handle later. poke | talk 10:36, 8 April 2018 (UTC)
(Edit conflict) To switch skill facts and infobox facts between modes, I'm using jQuery as well:
  • Select all elements within the mw-content-body div (or one that is given via parameter, so pressing a game mode button on a /history page does not switch game modes for all entries on that page)
    • From that selection, select elements with classes that need to be hidden for the selected game mode.
    • From that selection, select elements with classes that need to be shown for the selected game mode (and play the highlighting effect to have an easier time seeing what has changed).
    • From that selection, update the active state of the buttons.
To have this widget working the way it currently is, I have copied the following templates to my userspace and modified them:
  • {{Game mode version}}: Now calls the widget to create buttons instead of links to other game mode pages.
  • {{Version history}}: No longer links to other game mode history pages. Includes a text to press a button to select a game mode if a skill is/was split.
  • {{Skill fact}}: If the game mode parameter is set, wrap the output within a div with the css classes set to gamemode {{{game mode}}}.
  • {{Skill infobox}}: Diff with all my changes, {{Trait infobox}}: Diff with all my changes.
    • With these changes, I'm adding another template that will be called if a skill or trait is split: Skill infobox/subobject and Trait infobox/subobject. These two templates basically set all properties (just like it currently works with other game modes being put on separate pages) for subobjects. Maybe not the best solution, but I don't need to completely rewrite the infoboxes themselves. This also allows for querying just like the old system: Example query (User talk:Nefastu/Projects/SVH template rework).
    • For split things that are displayed in the infobox, I simply check for three more parameters: <<parameter>>-pve, <<parameter>>-wvw, <<parameter>>-pvp (initiative, upkeep, energy and recharge for the skill infobox, recharge for the trait infobox).
    • The infoboxes now include {{Game mode version}} via the split parameter.
  • {{Skill infobox/historical}} and {{Trait infobox/historical}}: Same as the non-historical infobox, except for: no subobject call and calling the {{Game mode version}} template includes the scope={{{date}}} parameter.
Yes, there is more work to be done within the templates, however, it greatly reduces the amount of work to be done if a skill has been split, which basically is the most recent balance patch:
  • Currently, you need to update the main skill/trait page and copy the changes to the /history subpage AND create a separate game mode page with the changes for that game mode only, as well as copy these contents to the game mode /history subpage.
  • With this project, you only need to update the skill/trait page with the split param and add maybe recharge-pvp to the infobox or game mode to some skill facts. Then, you only need to copy that to the /history subpage.
Pages to edit: from 4 (or 6, if a skill/trait is split between all game modes - Panic Strike, [[Panic Strike (WvW)]], [[Panic Strike (PvP)]]) back to 2. —Nefastu 10:55, 8 April 2018 (UTC)
@poke: I've taken the jQuery UI code, stripped it down to only include highlighting mechanics and minified it, resulting in a script size shrink from 248kb to 8kb. Maybe that's okay too? :D
Regarding your comment about ANET eventually changing more things to a skill, here's a dev comment on how far ANET is willing to split things, posted 5 months ago. I'd say ANET does not want to split skills and traits like in GW1, so skill/trait splits will always be very similar, with just some numbers tweaked. —Nefastu 14:47, 8 April 2018 (UTC)
(Reset indent) I'd like to push this topic again, since there are still some pages left to update for the 2018-03-27 patch and I don't want to create unnecessary work prior to the (dis-)approval of my widget/project. The changes I've made so far:
  • I replaced the dependency to jquery-ui with another one: jquery-color. background-color cannot be animated by jQuery alone, so this dependency allows me to animate the background to have the highlighting effect for an easier time spotting changes between game modes.
    • With the new dependency, the cooldown on the buttons is no longer needed. So buttons should switch as fast as your browser can handle.
  • From poke's suggestion: The borders now have no borders and inherit the background-color unless active or moving the cursor over it. I added a border-radius as well, but again—I am not at all a designer. If you have a better design, feel free to update the css directly.
With that, my questions are: Is the widget okay to use for non-userspace pages? Am I allowed to push all my changes of the project templates to the main templates, so I can start updating all the skills and traits? —Nefastu 17:55, 21 April 2018 (UTC)
I moved this conversation from my talk page because I don't really care about WvW or PvP versions, and since I don't think my opinion necessarily reflects everyone elses, I thought this would be a better place to discuss it.
  • I'm not convinced that using buttons to change the displayed page content is intuitive.
  • Differences are normally minor between versions, so I wouldn't be opposed to documenting all versions on the same page separately without CSS gimmicks -- i.e. no separate PAGENAME_(WvW) and PAGENAME_(PvP) pages for the different. (i.e. infobox data contains PvE mode, and PvP and WvW differences would be captured in a notes section). The split pages just annoys me.
  • Likewise for reading skill update history, I think its fine with keeping the PvP and WvW notes in the minor changes section.
  • Going through the history to update pages to use any new agreed format is not to be underestimated.
  • I'm aware we have loads of complicated templates, mostly by me, so this is going to sound nuts (pot-kettle), but this diff looks like its going to be hard to read later.
You've done a great job with the /historical pages, but I do wonder if we could make a bot to clone the old version updates every month instead of doing it by hand. -Chieftain AlexUser Chieftain Alex sig.png 13:12, 22 April 2018 (UTC)
Hm, I do care about the WvW and PvP versions, so I wouldn't just put something like "this skill has a 60 second cooldown in WvW/PvP" in the notes section. An easy way (with css gimmicks) to view the pve/wvw/pvp versions—at least for me—is much more interesting, since that is not possible without loading screens in-game.
Regarding your other points:
  • Intuitive design: What other options are there? These are the ones I currently see:
    • Separate pages: This needs to go.
    • Single page, wvw/pvp changes in the notes section: I don't know how we would correctly set subobject properties. I'd like to keep the wvw/pvp versions as subobjects. This would put wvw/pvp game mode versions as less important than the pve version, which I don't like.
    • Single page, API-like approach—list all game modes all the time: With some css styling (slightly colored backgrounds for wvw/pvp facts), this could be decent. Though for more than one or two split facts, this could get bloated (Restorative Illusions API entry).
    • Single page, buttons to switch between game modes: My current proposal.
  • wvw/pvp changes as minor changes for /history subpages: Not sure about this. While I'd like to keep the infobox even if the change is for wvw/pvp only (and is hidden by default), it would "clutter" the /history subpage. Though, after all, it's the /history subpage and I guess that page is allowed to repeat information. Maybe a parameter to set the selected game mode on page load within the skill/trait infobox/historical would be interesting.
  • Updating all the pages to the new format: To be honest, I've already spent too many hours on the skill version history project, so this is a minor time investment :D
  • Complicated templates: Yes, that's a problem. Possible solution: Move the pve/wvw/pvp detection for recharge, upkeep et cetera to the template call ({{recharge|{{{recharge|0}}}|pve={{{recharge-pve|}}}|wvw={{{recharge-wvw|}}}|pvp={{{recharge-pvp|}}} }}). Would keep the infobox template a little cleaner.
  • Updating /history subpages via bot: Should be possible, since all information is already on the main page. I'd probably only need to list the pages that link to a specific Game updates/YYYY-MM-DD page and has a /history subpage that does not link to it, then using regex to select the infobox and the correct version history table row content and format the output on the subpage. —Nefastu 19:37, 22 April 2018 (UTC)

(Reset) A card layout for the different game modes of the skill is perfect to me. Doing separate parameters inside the same template isn't a good idea. It's not very utilitarian for users to add or edit. The template needs to reflect the API and create a subobject for each game mode version. You don't need to make any changes to /history, add the game mode the change applies to as a column.

The template doesn't need to create separate subobjects unless there's multiple versions specified. The convention for templates will be to default to PvE mode for viewing. We know that certain attributes won't change, like name and skill type. The template should take advantage of that and provide an interface to add overrides for specific attributes. Then we'll have a multi-valued [[Property:Has game mode]] for the list of modes that version of the skill applies to. 

{{skill infobox
| name = 
| icon = 
| description = 
| split = 
| variables = 
| activation = 
| initiative = 
| energy = 
| upkeep = 
| recharge = 
| profession =
| mode = {{skill infobox/mode|pve
         | id =
         | variables = 
         | activation = 
         | initiative = 
         | energy = 
         | upkeep = 
         | recharge = 45
         }}
         {{skill infobox/mode|pvp
         | id =
         | variables = 
         | activation = 
         | initiative = 
         | energy = 
         | upkeep = 
         | recharge = 60
         }}        
}}

Example of different recharge:

Default create one subobject with Has game mode:<PvE, WvW> with id: <skill id>
{{skill infobox
| name = 
| icon = 
| description = 
| split = 
| variables = 
| activation = 
| initiative = 
| energy = 
| upkeep = 
| recharge = 45
| profession =
| id =
| mode = {{skill infobox/mode|pvp 
         | id = <!-- PvP override will create second subobject with Has game mode:<PvP> with id: <PvP skill id> -->
         | recharge = 60
         }}        
}}

The template can do the hard work of working out how to create the subobjects. Any time a skill id is specified, the template knows we are talking about a completely unique skill object and we want to create a subobject for each one.--Relyk ~ talk < 21:49, 16 June 2018 (UTC)

Eh? Nefatsu did all this ages ago. -Chieftain AlexUser Chieftain Alex sig.png 08:42, 17 June 2018 (UTC)
So move this to a new section or something? Good feedback though. The subobjects are missing a couple properties like Property:Has recharge time, Property:Is for race, combo finisher properties, and Property:Is historical. All the skill infobox templates are now tightly coupled to the game mode split code. The templates have missing or limited documentation, especially how the widget interacts or the subobject construction. I don't know how users would figure out how to add split skills. There's more duplicated code to handle both PvP and WvW than is necessary. The widget is still loading code from userspace at User:Nefastu/Projects/SVH template rework/Game mode version/script.js even though it's inlined in the widget. Most of this is probably only an issue for me since there's maybe 2-3 people that will ever look at and maintain the template and widget code. I can't complain too much since Nesfatu got this magically implemented.--Relyk ~ talk < 05:30, 19 June 2018 (UTC)
Now that is excellent feedback. I've removed the duplicate userspace loading, and this has also resolved the JS error in the console "r is undefined". Yeah the code is clunky, wanna rewrite it? -Chieftain AlexUser Chieftain Alex sig.png 06:20, 19 June 2018 (UTC)

Discord

So, hm. Since everyone is so crazy about Discord nowadays... do we need/want one, perhaps? Might help with coverage, publicity, transparency and the likes. IRC is so yesterday, you know. User Incarnazeus Signature.pngtalk 11:50, 26 April 2018 (UTC)

>: - Felix Omni 15:08, 26 April 2018 (UTC)
I'm not opposed to the idea. I know the French wiki already has one, and most people don't even have a clue the IRC exists. - Doodleplex 15:13, 26 April 2018 (UTC)
So I have limited knowledge of both, but here's where I'm at:
  • IRC offers a text-based medium which can be accessed through various clients, including web-browsers as seen on our own wiki.
  • Discord offers... ? (I honestly don't know, and would love to be informed)
Some details would help if you wouldn't mind. G R E E N E R 17:14, 26 April 2018 (UTC)
Most people know about Discord these days and very, very people know or use IRC(or at least the wiki's IRC). You can read catch up on chat in Discord, IRC once you leave, it poofs. Discord has a bunch of cute emotes, and you can post pictures and stuff which IRC doesn't have. Also you can have audio channels in Discord, though that might not be very useful for wiki purposes? I dunno. Almost forgot, you can use Discord via an app or web client. - Doodleplex 17:44, 26 April 2018 (UTC)
So as a more serious response, I've generally not loved Discord in the past- their primary audience is memelord teenagers and they take every opportunity to remind you of it. However, it is true that it's very popular among Guild Wars players, and since it's free (as far as I know) I've gone ahead and created a server which (as far as I know) you can join with this link. We'll take it out for a test run and if people like it and use it regularly, we can make a promo page for it similar to GW2W:IRC. - Felix Omni 20:44, 26 April 2018 (UTC)
I've migrated to Discord for personal use. My experience with the gitter.im/arenanet/api-cdi has been positive and I'd like the something similar for the wiki that Discord can provide. Mostly for hotlinking wiki articles, images, rich text wikicode, and some other things that are common wiki activities.--Relyk ~ talk < 23:42, 26 April 2018 (UTC)

(Reset indent) I'll be honest IRC seems weird to me, and I've never used it. My guild uses Discord, as do a few social groups I'm in. You can have voice and chat rooms. Link and file embedding can be disabled on a channel by channel basis, as well as by rank. You can receive alerts on your phone, or just mute the entire channel completely. While the Discord marketing platform is cringy and we all hate it, it's a fantastic solution to offline organization, scheduling, communication, and sharing. Some ideas for how the Discord could be utilized:

  • On-Demand help center. Need some pages deleted? Broke some code somewhere and you can't find the goddamned colon? Just leave your message on Discord and you'll probably get a response within the hour, without having to worr about sticking around to hear it if noone is currently "online."
  • Planning chat: For big pages or large sets of pages when major patches hit. Multiple people can chat and coordinate at once without constant page refreshes, overwriting and reediting.
  • General chat (of course)
  • Technical chat: For technical questions like widget uses and macros and bots.
  • Help Wanted: Want a friend to go help you scale up an event? Want to test out stolen skills with a friend? Can you not afford that fancy guild decoration but someone else, who doesn't like taking pictures already has it? Ask here!

Just some ideas. While Discord can run the risk of "splitting" a community between "in-game" and "offline" (in our case, "talk page users" and "discord users"), I think that used carefully, it's a good idea.--Rain Spell (talk) 03:58, 27 April 2018 (UTC)

Personally I'm all for it, love the damn program. I would caution the use of it with regards to important wiki-wide conversations though. It's easy to get carried away and come to a conclusion on a chat panel and not bring it back in writing here. Given however that this isn't a thing happening on a regular basis on the wiki, I don't see why it would be an issue. I know I'm not present as much these days here, but I think a chat of the sort would be useful. I've yet to see an offline chat bring *down* a community, if anything it just stays stagnant at worse (the chat, not the group). -Darqam 04:25, 27 April 2018 (UTC)
Assuming Discord works the same as Slack (messaging and collaboration software that literally everyone in tech uses), users who join a channel can see what was said there even before they joined it, so that's one advantage it would have over IRC- though not exactly public, conversations are never really hidden. - Felix Omni 14:58, 27 April 2018 (UTC)

So Guild Wars 2 Wiki:Discord is now a thing, and anyone who cares to may join https://discord.gg/C4RMwPN and, y'know, be Discording socially. I'm there, I may listen to you. Not that it was hard to get me to listen to you before. To the degree that I will unofficially endorse any unofficial official wiki Discord, I officially unofficially endorse this one. - Tanetris (talk) 14:40, 16 May 2018 (UTC)


Proposal: Guild Chat transcripts

ArenaNet's Guild Chat video series is an abundant resource of official developer interviews and insights. However, due to being in a video format, it's also very difficult to search previous episodes to find information as a source for documentation or discussion. While the wiki is primarily for documenting the game itself, we have previous made exceptions for other official videos. How would you feel if I were to prepare transcripts of some previous episodes of Guild Chat, possibly starting with the most recent episode and working backwards? Due to the length of these transcripts, each would require its own article and could be linked from the primary Guild Chat article. -- Dashface User Dashface.png 16:49, 1 May 2018 (UTC)

Intriguing idea. My first concern would be the vetting of the transcripts. When we copy statements from ArenaNet staff, we've gone out of our way to do it {{verbatim}}. The Guild Chat episodes have Anet's seal of approval as being their word; will we then be needing their consent that our transcriptions are accurate? Would we need to add a caveat at the top of the page to say that the transcription has not been vetted by Anet staff?
I do like the idea, but before it gets going, we should reach out to Anet to get their stance on how best to handle a (non)-endorsed transcript of their words. G R E E N E R 17:10, 1 May 2018 (UTC)
I wouldn't be concerned about somehow misrepresenting ArenaNet- as it says at the top of the main page, the wiki is written and maintained by players. If anything, a simple disclaimer like "These unofficial transcripts were produced by players and may not be perfectly accurate" should suffice. As to the idea itself, I think it would be a valuable addition if we could provide this kind of resource. It would certainly be a time-intensive project, but for any contributor who wants to I say go for it. - Felix Omni 05:09, 2 May 2018 (UTC)
I agree with Felix's stance. So long as we add a disclaimer making it clear that these are unofficial transcriptions of an official source, along with a link to said official source, we should be fine. I like this idea and I'd probably contribute. --Idris (talk) 11:36, 2 May 2018 (UTC)
I'm fine with adding a disclaimer. Making a high-quality transcription can be time consuming, but it's something I've previously done professionally, and I think a lot of issues can be addressed by just being accurate. I'm presuming we'd need to start from scratch, though YouTube does provide subtitles for each episode that look automatically generated. Does anyone know if it's possible to extract these to use as a starting point? -- Dashface User Dashface.png 12:26, 2 May 2018 (UTC)
I Googled "YouTube caption extract" and got lots of results, so it seems pretty possible! I gave the first hit a spin and the results were a formatting nightmare, but it's better than nothing, I suppose.--Idris (talk) 12:57, 2 May 2018 (UTC)
Alright, if it's going to be understood to be "messy" no matter what we do, then a disclaimer will always have been needed. Best of luck with the transcribing, and thanks in advance for taking this on. G R E E N E R 17:06, 4 May 2018 (UTC)
Unnecessary If it's impossible to misrepresent ArenaNet through a proper transcription, then a disclaimer shouldn't be necessary. See other wikis, even though it's a live broadcast. I've never seen a disclaimer for any transcript, on a wiki or not. — Cronos 21:17, 14 July 2018 (UTC)
I don't think anyone said it was impossible to misrepresent them, just that the risk of misrepresentation wasn't so great that we needed ANet's written consent before we got started. But there's still a risk. I've seen quite a lot of folks assume that the wiki is written by ANet because it says "OFFICIAL WIKI" up in the corner, so I feel the disclaimer is worth keeping. —Idris User Idris signature.png 12:10, 15 July 2018 (UTC)

(Reset indent) Hi everyone, I saw that discussion and noticed that we may be able to help you on that! I double-checked and we can access subtitles that are automatically generated by YouTube for all the past Guild Chat shows. We wouldn't release those publicly because we've noticed in the past that these subtitles contain errors and inaccuracies, and we didn't have the time to go through them and make them good enough. However these could come in handy for this project, as it would provide a good base to create transcripts from?

One thing to note: for current and future Guild Chat episodes, we've already started looking into ways how we could create better transcripts of Guild Chat. We haven't finished exploring this avenue, but I'll keep you updated if and when we know more!

Let us know what you think and, if you're interested, where you want to start from. Thank you! --Stephane Lo Presti talk 23:00, 4 May 2018 (UTC)

Although I'm not part of the people who will be doing this much, I can say that correcting a text with inaccuracies is waaaaaaaaay faster than typing something out from scratch. So so long as those texts are somewhat accurate, they would most likely be very useful. It would probably require a trial run to see how accurate those auto subtitles are.
As well, if this is a project that will go on, I would also recommend making these transcripts in an SRT format so that it could be taken up by most video players (online or offline). There's a real quick overview of those files here to give people an idea.
It might be a bit more work, but if people are doing the transcripts, and presumably youtube would output them similar to this. It is infinitely easier to go from SRT to plain text (for wiki) than the opposite way around. These files could then also be available to the public; which could be expanded on (at a later point) by anet if they release the videos in raw form or decide to straight up use those srt files themselves.
Anyway, just a thought. -Darqam 04:24, 5 May 2018 (UTC)
Stephane, would I be able to ask if you could e-mail me the automatically-generated subtitles you have for a recent episode of Guild Chat? I will put together a sample article and present it back to the Community Portal for appraisal. It's okay if the best we have to start from is a big wall of text. Like Darqam says, correcting will be much faster than starting from zero.
Darqam, making a subtitle file would require timestamps, which would be a million times harder than what I'm proposing. If someone wants to turn the corrected text into a properly-timestamped file, I have no issue with that, but only someone experienced in this would be able to do it efficiently. For example, someone who performs a similar role for foreign-language fansubs. For anyone else, I would predict many afternoons of anguish per episode. -- Dashface User Dashface.png 17:00, 5 May 2018 (UTC)
I guess I suggested srt files because of how I assumed YT would output the subtitles. I am assuming that it would be a similar thing to SRT files, but yeah if it's not than I agree going from raw text to timestamp would be very painful. -Darqam 17:08, 5 May 2018 (UTC)
So that everyone is on the same page: I've sent Dashface the first .srt file for Guild Chat episode 60. Let me know if there's any other way I can help! --Stephane Lo Presti talk 16:03, 8 May 2018 (UTC)

(2)

@Stephane, would you be able to mail me one of these srt files? It doesn't seem like Dashface has had time to play with it, and its been two months now. We can get this rolling. -Chieftain AlexUser Chieftain Alex sig.png 23:29, 1 July 2018 (UTC)

So Dashface sent over the single SRT file, and hoo boy is it annoying and slow to salvage anything useable out of the subtitle files. It took me about 3 hours to do half an episode. Guild Chat - Episode 60 I got bored and have given up for the moment. -Chieftain AlexUser Chieftain Alex sig.png 16:44, 8 July 2018 (UTC)
I've started a new section for this below. -- Dashface User Dashface.png 17:48, 11 July 2018 (UTC)

GWW tag

→ moved from Talk:Skill

I'll confess to the mass GWW tag changes on skills earlier while I was on my cell phone. I see most of these are in the process of being reversed.

  • My case for this is:
    • The tag is small, making its addition easy.
    • A standard, graphical element is instantly recognizable, as opposed to the repeating text string which always has to be read to be recognized.
    • It was replacing an element that already existed, so it wasn't a matter of clutter.
    • The GW Wiki has much of the GW2W tag in place, so it made for a nice mirror of the two.

I'll concede that it made some formatting difficult, had 3 possible behaviours depending on where you clicked, and there is an inconsistency in whether its placed in Notes or Trivia.

I await your feedback. Turbo404 (talk) 01:13, 1 June 2018 (UTC)

Template:Gww is really meant to suggest that a certain subject matter is covered on gww in a different context, ie two articles describing the same entity. Two skills sharing a name are not the same entity; it's just a little nod from the developers, which is why it only merits a trivia bullet point. The Guild Wars skill template only exists to standardize that trivia a little bit, since it's fairly common. - Felix Omni 02:08, 1 June 2018 (UTC)
I'm pretty much going to echo Felix here. The wiki is meant to be a source of useful or relevant knowledge for the GW2 game. When there's a gw1 piece of information which can help the reader, such as providing context, then either an inline link or {{gww}} can help. A good example of this being used is on the Sunken Droknah page (note the inline and template usage). As the relevance diminishes, so too should the flagging of the reader's attention. For example, the reader gains little more than possible nostalgia by finding out that Mending was a gw1 skill, so we relegate the information to an unobtrusive piece of trivia. G R E E N E R 04:40, 1 June 2018 (UTC)
I agree with what was said above. As for the inconsistencies in notes/trivia, GWW/Guild Wars skill should always be placed in trivia (I noticed a few cases where this wasn't true yesterday), so feel free to move them from notes to trivia, if you happen upon it. —Ventriloquist 06:55, 1 June 2018 (UTC)
I don't think we actually have a standard as to where {{gww}} should go. Some folks think it belongs in Trivia; others think it should go in whatever section is at the bottom of the page. Frequently, it'll get stranded in the middle of an article because it was originally added to the bottom but new sections have since been added below it. Always putting it in Trivia makes sense from an ease-of-editing standpoint, but it's a terrible choice aesthetically if Trivia is otherwise empty. --Idris (talk) 07:17, 1 June 2018 (UTC)
My personal sense of aesthetics is not offended by a trivia section only having one item. (I now realize you meant gww alone in trivia, which is indeed weird since the header would appear to be empty.) So to address one of Turbo404's points, how would people feel about adding the GWW icon to the Guild Wars skill template? Something like
Gwwlogo.png A Guild Wars skill bears the same name as this skill.
where the icon takes the place of the bullet point. - Felix Omni 15:17, 1 June 2018 (UTC)
I like it! --Idris (talk) 15:58, 1 June 2018 (UTC)
I was thinking exactly the same this morning. For those of us that look for it, it’s nice to see.Turbo404 (talk) 17:22, 1 June 2018 (UTC)
@Idris A slight misunderstanding - I meant that if there is an existing trivia section, it should go there. If not, then at whatever the lowest section is, yes (because of the align-right). Sorry for the misunderstanding! As for the suggestion, I like it, it looks clean and hopefully solves the issue that was brought up. —Ventriloquist 17:00, 1 June 2018 (UTC)

(Reset indent) Fair enough, Vent! I think we should add a useage guide to both of these templates to help reduce misunderstandings in the future. How's this for {{gww}}?

Pretend this is a proper header titled "Useage"
  • Place at the top of the article's Trivia section. If there is no Trivia section, place it at the top of the lowest section on the page instead.
  • This template's purpose is to provide a link between elements which appear in both games, such as: Sunken Droknah, Glob of Ectoplasm, Celestial Compass. It's preferred not to use this template for elements which are merely inspired by elements from the original Guild Wars, such as: Sunspear Outfit, Sight beyond Sight, [Insert third example].
    • Use {{Guild Wars skill}} instead of this template for skills which share a name with Guild Wars skills.
    • Write your own Trivia line for other elements, for example: This outfit resembles the armor worn by [[gww:Order of the Sunspears|Sunspear]] NPCs in the original ''Guild Wars''.

--Idris (talk) 01:01, 2 June 2018 (UTC)

Might be an idea to create an icon template so custom trivia lines can use the GWW icon too. Edit: Or we could just tweak {{Guild Wars skill}} so it allows custom text while still displaying the icon, as I've mocked up on my sandbox. This whole idea is dumb. {{icon}} works just fine for this. --Idris (talk) 04:18, 2 June 2018 (UTC)
I think it would still be reasonable to use gww for skills that are clearly based on gw1 skills, for example Fireball (Both Elementalist Fire skills, same name, both are a projectile and deal splash damage). Mending would be one case where I think it wouldn't apply, Sight beyond Sight would be a difficult example being somewhat different but sharing the anti-blind mechanic.--Soulblydd (talk) 07:01, 2 June 2018 (UTC)
I'm not sure such distinction is necessary, Soulblydd. If anything, it might cause more confusion for wiki contributors. I think sticking to the GWW tag for anything other than skills/traits is perfectly fine, with perhaps adding an icon, as discussed above. —Ventriloquist 14:04, 2 June 2018 (UTC)
I'm not a fan of that idea. Two skills functioning similarly are still not the same entity. Let's keep it simple and consistent, and use {{guild wars skill}} for skills. - Felix Omni 14:26, 4 June 2018 (UTC)
Since nobody's commented on my useage section idea, I've gone ahead and added it to gww. Feel free to tweak/remove any elements you don't like about it. --Idris (talk) 18:50, 4 June 2018 (UTC)
A bit late to the party, but I'm wondering if it's necessary to move the gww tag to the Trivia section if this or that page already has a "See also" section (see e.g. the page for Balthazar). I feel that in those cases it'd be more natural for the gww tag to be placed under the "See also" subheader as it does technically take us to a relevant article in GW1Wiki, hence thematic ties to the phrasing "See also". Thoughts? --Kossage (talk) 20:45, 23 June 2018 (UTC)

I mean, it looks like we're using {{Guild Wars skill}} for traits too (which I guess Idris just added) and already going out of scope. This can totally be a generic template shorthand for common content like skills, traits, NPCs, locations, items, and objects. Both templates do the same exact thing as far as how we use them. If we want a template whose purpose is to indicate GWW provide additional context and information and a separate template that indicates a trivia reference, we should make explicit templates for those use cases. And maybe abandon the design of a right-aligned text box to avoid trivia sections that appear to have no content...--Relyk ~ talk < 06:24, 5 June 2018 (UTC)

Yeah, that was me. I don't see traits as going out of scope, since they're very similar in nature to skills (compared to things like NPCs and locations, anyway) and they're always named after Guild Wars skills, which, I mean. Is exactly the name of the template. --Idris (talk) 06:46, 5 June 2018 (UTC)

Pet locations

I have just updated each of the individual pet articles to use the same file naming scheme and layout. I'd now like to collate ideas for how to present List of pet locations in a useful way.

The current layout is basically copied from each pet page (albeit old revisions). It has an indented bullet point list of locations, then a separate gallery section.

Sime has already proposed tables for each pet. Can we get some more suggestions?-Chieftain AlexUser Chieftain Alex sig.png 23:30, 20 June 2018 (UTC)

I've added expanding gallery images using {{gallery widget}}. Since I wrote it from scratch some stuff will probably break. -Chieftain AlexUser Chieftain Alex sig.png 22:51, 21 June 2018 (UTC)
Also moved the images above the locations and added lines after headings. -Chieftain AlexUser Chieftain Alex sig.png 23:22, 21 June 2018 (UTC)
The widget doesn't work very well on small mobile devices. The max height is respected, but the image hangs off the right hand side of the screen - and scrolling isn't allowed. --5.65.85.217 23:00, 22 June 2018 (UTC)
Retrieved from "https://wiki.guildwars2.com/index.php?title=Guild_Wars_2_Wiki_talk:Community_portal/Archive_15&oldid=2380395"