Guild Wars 2 Wiki talk:Community portal/Archive 23

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.

Exclusive appearances pages are too complicated and should be simplified

I would like to attract the attention on https://wiki.guildwars2.com/wiki/Physical_appearance/Exclusive_asura and others exclusive pages? Indeed, a lot of space is used without sense to put as example all the picture of the colors of the accessories, can't those be cropped and squished to occupy only a few line? What is the useless point of precising the Hue and so on? Just put a line with all the colors, and under it the name of the parameter/the icon in the UI corresponding to it, example given: Red color accessory, a red square. Same with eyes and hairs. In fact, it can even lose players because the appearance aren't even corresponding to the race! Why putting human pictures on everything? It is a question of space, as I said earlier, merge every picture into one long one. For the hair style it is okay.

But for the look of the page overall, you should uniform the style between exclusive pages and normal ones https://wiki.guildwars2.com/wiki/Physical_appearance/Sylvari this page is perfect as example and exclusive should look the same one, see, for normal appearance, it is done the way I said earlier, pictures of colors and square of colors/dyes under.

I really urge to clean up those exclusive appearance pages because frankly, currently, for me and several of my guildmates it is way far better to use the in game aesthetician than the wiki. The exclusive page are mess and easy to lose yourself in it, the accessory, eyes and hairs colors takes so much space that even the possibility to reduce it like if it was marked as a spoiler would make it better.--46.193.17.3 21:34, 26 May 2021 (UTC)

Pages look OK to me, but the color palettes are missing the names of the colors at the moment, they can easily be added with title="xyz"... the hard/annoying bit will be typing the names out. -Chieftain Alex

22:34, 26 May 2021 (UTC)

I agree that the pages are way too long. I've made the first 3 tables expandable so they don't take up so much room. --BuffsEverywhere (talk) 23:02, 26 May 2021 (UTC)

For the record I eventually finished the colour palettes prior to EOD release. -Chieftain Alex

23:59, 27 March 2022 (UTC)

AFK farming

Should we consider making a page for this kind of farming ? With the rules , places and everything around it ? Sure its somewhat banable but as wiki we should consider making a page about it . Warning others of what they shouldnt been doing and gathering as much information about the subject as possible. If you will disagree just delete my question ;) --DiegoDeLaHouska (talk) 13:43, 1 June 2021 (UTC)

We are 100% not putting ways to cheat on the wiki. - Do_odleplex 02:40, 2 June 2021 (UTC)

Its not cheating. There are rulles to follow but its not cheating. You cant use any other programs to farm for you .. and you need to be active in the game. That means that you can be standing still farming but you need to answer when someone will write you . That is why it would be nice to write it down on wiki as well. Even you see it wrong . Most of the players do. --DiegoDeLaHouska (talk) 02:47, 2 June 2021 (UTC)

It's not happening. It's cheating and a banable offense. It's not going to happen, we're not making an article for it. - Do_odleplex 03:29, 2 June 2021 (UTC)

Show me a confirmation that its illegal to do. I want to see where it is. All I know are those 4 rulles they have and those doest say that its illegal. --DiegoDeLaHouska (talk) 03:39, 2 June 2021 (UTC)

Diego/Sw0rly, the wiki is not making the page. Drop it. - Do_odleplex 03:40, 2 June 2021 (UTC)

The issue is that it's incredibly exploitable. The "rules" are really just guidelines and laying these out complicates matters for players more than it helps. True AFK farming is not allowed. Semi-afk farming might be allowed, but the mitigating circumstances surrounding it and the chance that the wiki "misleads" someone into doing something ban-worthy is too high to allow a page. Just adding more of an explanation as to why it's a bad idea even if it's "not against the rules." It's just a liability.--Rain Spell (talk) 04:23, 2 June 2021 (UTC)

(Reset indent) We should not facilitate AFK farming. ~~I don't want people coming to my farm spots.~~ --BuffsEverywhere (talk) 04:54, 2 June 2021 (UTC)

Not even telling them that its somewhat illegal ? Based on non prove so far. --DiegoDeLaHouska (talk) 04:59, 2 June 2021 (UTC)

I personaly belive that any mechanics/system in the game should be documented no matter the morals behind it. We learn about natzi even tho they were bad. And the fact Im been denyed even before the conversation started just based on my name really pisses me off. Im not saying to make a guide with how to do it and where. Just to make a page that inform players about it and the rules. The same way Anet has on their pages. --DiegoDeLaHouska (talk) 08:13, 2 June 2021 (UTC)

AFK farming can get you banned. There's nothing to be said about it other than "Don't do it." That should be obvious. I would oppose it no matter who is suggesting it. --BuffsEverywhere (talk) 16:27, 2 June 2021 (UTC)

You can find the gameplay policies here [1], including Policy: Unattended Gameplay that has written in bold "ANY form of unattended gameplay is prohibited in Guild Wars 2". If we were to ever create an afk farming article, it would merely be an external redirect to that support page.

Only letting logged in members to Undo pages changes using History or editing pages.

Recently, I wanted to edit the Timeline page and noticed an IP doing a mess, removing last user addition before it added a reference (mine), removing someone else edits without asking, Ip starting by 98. , very recent. And I got a spark in my head. Over time I saw many conflicting edits, non registered users shooting bullets in each others feets. I have enough. Only logged in users should be able to use history and undo a page or restore a former version. Same for editing. Or at least, some pages should be simply LOCKED. Timelines, races, personal story or living season pages.. All of those, i would lock them. When a person wants to add something, they create a section in discussion page, wait for an admin and then get the green light. I am very angry because it is not the first time that me or other users are annoyed by IP users editing switfly not caring, not asking. IT IS THE MINIMUM to ask the user who made the last edit if you can edit and what is wrong and what should be fixed. If those ip users aren't able to behave correctely, they should be prevented to edit. Sure 1 wrong edit or 2 or 3 vandalisms aren't that bad and i agree with the vandal report page, but when you have 10 new ip that do crap on a page, it is annoying. I can totally get that peoples should be free to edit even if not signed in, but no, they shouldn't be able. Really. Nobody apart admins should have access to history page for any page. --Inquest Overseer Ezrielia (talk) 16:23, 27 June 2021 (UTC)

Being able to undo anything by anyone is the main feature of the wiki, disabling the history action would make no sense. I understand that some specific high traffic pages can be subject to more amendments + we may not always agree with every edit, but that's really a minority.

Also quality control of content is supposed to be the realm of regular editors, not specifically admins. -Chieftain Alex

21:19, 27 June 2021 (UTC)

That's awful and disgusting to hear. I totally agree that it may not be the job of the admins, but as you said "quality control of content is supposed to be the realm of regular editors" however it is the total opposite. Tha's only Logged users should be able to change anything. It wouldn't ruin anything. That way we know who edited and can take more easily actions than let's say 15 IP trolls. I'm okay with not agreeing on every edit of course; but it is not a minority. Since I'm on the wiki I discovered how awful peoples are, searching to nickpick, removing something added by others and so on, everyone having their vision of the thing. I will ask one thing, isn't moderation part of admin job? If not apologies, but then moderators should be recruited. I already saw badly made pages with erroneous informations but If i listed them here, it would never end.

Really, important pages such as Timelines, Race pages, Gemstore pages or Living seasons one should be LOCKED. I saw locked pages on other wiki I'm used to visit, and believe me or not, they run better. Less trolls. Less persons to ruins articles. A wiki shouldn't be a place of elitism and nitpicking persons like this one is currently but a serious place, where anyone can contribute and not being harassed or its edit removed a second later. It is hard to difficult? Do humans have only one brain cell? No offenses toward anyone, but the least when you want to contest an edit is to send a message to a editor nope? Not like i received recently "I assume you don't have counter argument so i will remove it" name of the user is Nightsky. What CRAP is that?

Everyone would ruins each others edit, it will never end, what is the goal?

At this point I prefer stopping participating in the wiki. Good luck with this mess.

Ezrielia --88.163.127.2 15:03, 19 July 2021 (UTC)

For what it's worth let me point out that "I assume you don't have counter argument so i will remove it" is not how what i've written on your talkpage (Now at User talk:Inquest Overseer Ezrielia/Archive 1#Your additions to Timeline.) is meant to be interpreted. I was merely informing you of the fact that i will remove what you added based on the reasons i provided there to inform you that the way you're using the sources in is flawed; unless you respond with any good arguments against this thus stopping me from removing it, explicitly informing you of this condition (that i will not remove it given any good arguments from you), implicitly asking you to provide them. Nightsky (talk) 00:29, 20 July 2021 (UTC)

Proposal for a notice template

Following up on this conversation User talk:Nightsky#Spirit Vale unnamed dialogue, I am moving Nightsky's proposal here for community discussion.

Several articles in the wiki have fan-given names or simply Unknown as a name because the object or NPC in question does not have an in-game name. The unknown solution makes sure that the reader knows that the object/npc does not actually have a name, but leaves us with an obscure article name. While the fan-given name makes for a descriptive title but may confuse readers into thinking that that is the name of the object/npc.

For these reasons, I believe Nightsky's idea would be an excellent addition to the wiki. In essence, we would write a descriptive title for our unnamed object/npc, but then include a notice-like template to make it apparent that the name was given by wiki editors and is not official, but merely descriptive. Something along the lines of "Note: this object or NPC does not have an in-game name. An unofficial descriptive name has been provided by the wiki for ease of identification."

Discuss. --Warming Hearth (talk) 09:43, 12 July 2021 (UTC)

Many other wikis use something similar for pages without an official/known name, and it is better than having dozens of "Unknown" pages that do not tell you anything about the article. So I am for it. ~Sime 09:49, 12 July 2021 (UTC)

For what it's worth by "{{notice}} like template" i only meant the box itself and not the text. (That is i would have left away the "Note: " bit and changed the image to a question mark.) Also, i would have retained the names mostly as they are and only had the template add a clear indication of the item/object/npc/skill/effect not being named in game or being named <insert actuall name here (such as Unknown if named literally Unknown in game)>, including the source of the name if deviating from the Unnamed <entity type> (<location>) scheme such as for Globolla Marbles name being taken from an associated achievements description text which is why it's named differently from the scheme. Retaining the scheme like that i figured would help prevent naming conflicts like gravestone vs. tombstone by only naming things described elswhere like the bandits being refered to as bandits and them being dead being seemingly obvious. Though only seemingly and i also couldn't come up with a wording for the text of the template that i liked and have given up on it. Nightsky (talk) 20:56, 12 July 2021 (UTC)

Proposal: Screenshots of each individual piece of armor

We pride ourselves on the thoroughness of this wiki, but one big gap in our documentation is that we don't have screenshots showing what all individual armor pieces look like, specifically the ones in armor sets. This is one of the few areas where the Guild Wars 1 wiki still offers more than we do. For example, check out the gallery of female elementalist Obsidian armor, where the chest and boots are shown on a separate screenshot to the gloves and pants.

The Gallery of swords article is a great catalogue if you want to go sword shopping. But we don't really have anything comparable for putting together a custom outfit, despite the mix-and-match high-end cosmetic focus of the game's reward systems. The armor set galleries are useful, but it's often difficult to distinguish where one piece ends and other starts. Other times, overlapping pieces obscure details. What do Vigil's Honor Leggings (medium) look like? You can't find out on this wiki right now. You can find out in game in the Wardrobe, but the two limitations there are you need to be logged in and you can't see them all side by side as thumbnails. And, of course, being able to research something within the game does not preclude us from documenting it.

I propose that we take steps toward a system where there's a place for screenshots of individual armor piece articles, collated into an automatically-generated gallery like the swords one above.

Actually taking this many screenshots is unquestionably a massive undertaking. BuffsEverywhere reports that there are 2285 armor skins in the game! And what about differences by race and gender? Vigil's Honor Leggings (medium) on a male human are just three-quarter pants. On female human, they're something else entirely. I don't pretend that getting these screenshots would be trivial or immediate. But what I seek is the structure so that we can slowly grow this collection.

Felix Omni points out that if articles suddenly had a ton of red links, that would be ugly, and I completely agree. It would also put undue expectation that this was something to be completed quickly. Could there be a way to suppress display of a screenshot table on relevant articles until the specific screenshot existed, at least until such time as the endeavour was nearing completion? Red links are inherently an implied invitation to contribute, which is usually a good thing, but until we got the groundwork in (for example via On Wiki of Gold), it might be better to only show the images when they exist.

I'm interesting in hearing your thoughts. I am sure the immense scale of this mountain is off-putting. What challenges do you foresee? -- Dashface 15:15, 3 August 2021 (UTC)

Multiple API Keys for Collection table

Is there any way to modify the {{Collection table|notes=false}} API field to hold multiple lines of a 2-column data (name, API Key) to allow multiple account APIs to be retained? --Separ (talk) 16:27, 8 August 2021 (UTC)

Upcoming maintenance

Hi all. There's a wiki update coming on this Thursday 03:00 PST (more job queue schenanigans). The job queue needs to be basically empty when this update hits, so any planned edits for infoboxes templates, notice templates, nav templates, multiple image uploads, editing semantic properties.... don't bother on Wednesday through to until the maintenance is complete. It'll fuck up the wiki for everyone else. Thanks. -Chieftain Alex 20:36, 9 August 2021 (UTC)

Making collections tables sortable by location?

I understand this would add some extra bit of tedium to the collections even after we've had it be simplified, but looking at this talk page, I think it would be a small quality of life change. We could limit it to legendary collections as well. I've tried looking at different mediawiki guides and I gotta say, I have no clue how any of it works. Would it be possible to add an extra (optional) "Area" parameter to the collections template (the header and line ones.) and then making it a sortable table? I was also looking at the other collection template, and this one seems to have the requested feature. I assume that there was a problem with the hints not showing up correctly on the original and the manual one was adopted instead? Hope this makes sense. Thanks, --Rain Spell (talk) 01:49, 21 August 2021 (UTC)

Basically yes, its possible. The table would need the "sortable" class added into the header, and we'd need a new column stating the location.

Modifying the header is simple and would be a case of modifying {{collection table header}} to allow a css class to be fed into the header.
The rows each have their own template, and we'd either
- (a) edit {{Collection table row}} to add a location column with its own parameter (note: avoid clash with existing parameter names for maps) so we could manually enter the location,
- (b) edit {{Collection table row}} to add a location column and feed it with SMW - I don't think this is realistic as the majority of our item pages don't directly identify a location, some items are dropped by npcs appearing in multiple maps, or events crossing multiple areas,
- or (c) just specify the area as a column directly on the achievement page after each row (e.g. {{collection table row | Test Subject Captivity | Clear out [[Vexa's Lab]] in [[Fireheart Rise]] }} || [[Fireheart Rise]] without modifying the row template.

Afaik we use option c in a whole bunch of places. -Chieftain Alex

08:06, 21 August 2021 (UTC)

I just want to say that I agree with the proposal, being able to sort by location to see how much of the collection you can do in one map would be extremely useful. ~Sime 14:15, 21 August 2021 (UTC)

I think option A would be the better option for flexibility. Most collections won't need that feature. It's mostly the legendary ones, since they involve traipsing across tyria, yet to the same 6-8 maps. I don't believe "area" is a parameter on either template, though a parameter like "mapname" or "mname" could be ok? I agree that B doesn't seem feasible. Would C work without adding an extra space to the header template?

Can I literally just add "sortable" to the template code for the header and it will be sortable?

Like from this:

{| {{STDT|mech1}}
! style="min-width:12em" | Collectible
! Type
! Subtype {{#ifeq: {{{map|false}}}|true|{{#vardefine: collection table map|true}}<nowiki/>
! Map }}{{#ifeq: {{{location|false}}}|true|{{#vardefine: collection table location|true}}<nowiki/>
! Location }}
! Notes

To this:

{| {{STDT|sortable mech1}}
! style="min-width:12em" | Collectible
! Type
! Subtype {{#ifeq: {{{map|false}}}|true|{{#vardefine: collection table map|true}}<nowiki/>
! Map }}{{#ifeq: {{{location|false}}}|true|{{#vardefine: collection table location|true}}<nowiki/>
! Location }}
! Notes

--Rain Spell (talk) 02:23, 22 August 2021 (UTC)

Yes you could have done - I'd prefer if sortable was optional though, that way we can somewhat track where we've added these extras. I've made the template edit, see this.

Example at Meteorlogicus III: Storm.

Is this roughly what you wanted? (and yes, making a table sortable will move the lines around too unfortunately - you can either remove the lines completely but that'll destroy any logical grouping that makes sense prior to sorting it) -Chieftain Alex

08:53, 22 August 2021 (UTC)

You can make the line follow the row you want, see this edit. --BuffsEverywhere (talk) 09:18, 22 August 2021 (UTC)

This is perfect, thank you both! I'm going to see about updating some more collections now. :) --Rain Spell (talk) 16:29, 22 August 2021 (UTC)

Regarding sortable, the automatically generated template {{collection table}} is sortable since May 2021, so in my opinion to we can make {{collection table row}} sortable by default too. However, ~~in order to be able to revert the table to its inital state~~, I have added an index column (which is also handy to get an overview of how many there are, etc...). Edit: The index column should definitely be the in-game order not the wiki order (which are not necessarily the same). Sorting twice again (after sorting once) however resets to the initial order, see sorting hover text: Sort ascending -> Sort descending -> Sort initial.

Regarding adding additional columns outside the template, I personally do not recommend to use this at all, it can break so easily (undetected!). One template edit, for example changing the line management, even when the template editor is aware of the full template behaviour, these cases are so hard to track that they slip through so easily.

So how would I address this topic? The location parameter/column is already taken for location images (object location screenshot, compare to map parameter/column that gives a map screenshot), so we can't use this. Furthermore, a location is kinda specific and not needed everywhere.

So what about an additional unspecific parameter ~~information~~ (Edit: added parameters col1 ...col3) where

in the collection table header it is set to the wanted column name, for example "Zone", "Nearest waypoint", "Enemy" etc...
and in the collection table row it is set to the wanted value, e.g. "[[Lion's Arch]]", "{{waypoint|Trader's Forum Waypoint}}" or "[[Rabbit]]s".

This gives the template full control over this column but allows the wiki editors some degrees of freedom to customize it.

The template code would be the following:

{{collection table header|col1=Zone}}
{{collection table row | Test Subject Captivity | Clear out [[Vexa's Lab]] in [[Fireheart Rise]] | col1 = [[Fireheart Rise]] }}
|}

--Tolkyria (talk) 13:48, 24 August 2021 (UTC)

I have added the parameters col1 ... col3 which allow any custom content (see example directly above). The columns are activated by setting the parameters col1 ... col3 to the wanted column title in the header template. --Tolkyria (talk) 07:36, 25 August 2021 (UTC)

List of fansites

News and info needs to be updated -- Dragon Season is disconnected, GuildMag out-of-date/discontinued, and the section should be alphabetical in accordance with the rest of the page. Page is protected. -Suchalameo 22:25, 22 September 2021 (UTC)

Updated. Thanks for pointing it out. Myriada (talk) 14:27, 24 September 2021 (UTC)

Damage type

Hi, would it be OK to create [[Property:Has damage type]] and an associated template that would add the property to a page? I was thinking about a text template that would result in a link to Damage type so that it could be embedded in a paragraph. I think it's better to avoid duplicating the information in different parts of an article. Kumiponi (talk) 15:51, 3 October 2021 (UTC)

Presumably this would only be going on weapon pages? I would suggest instead adding a parameter (maybe damage type = ?) to Template:Weapon infobox + then checking if that parameter is set before setting the property. Property name looks ok though. -Chieftain Alex

16:43, 3 October 2021 (UTC)

Weapons and weapon skins, since the effect depends on either one. There other relevant infobox is Template:Skin infobox. Kumiponi (talk) 18:25, 3 October 2021 (UTC)

wouldn't it be skin infobox only? -86.131.94.157 21:12, 3 October 2021 (UTC)

That's the tricky part, based on the wiki informations, namely Damage type and List of weapons with an unusual damage type, it's not enough to set it in the skin infobox but also it's also required to set in the weapon infobox (starting with HoT weapons where their transmuted skin does not carry over the damage type).

For me this raises following questions:

Should we set the damage type property in general to all pages or only in special cases to a few pages (i.e. only if the damage type is not physical)? Should it default to physical if we set it to all pages?
Follow-up question: Should we also display the damage type in the infobox? Based on how we set this property, when should we display it? The problem I see here is that unlike other games the damage type is purely cosmetical. Actively listing the damage type in the weapon infobox may suggest something different for users that are not aware of this concept yet. See also e.g. Peak Performance/history or Whirling Axe/history, until they came up with the term strike damage, the term physical damage was sometimes used even by the devs to describe plain (non-condition-damage) damage.
Why does this edit on List of weapons with an unusual damage type mark it as outdated and which weapons are meant by this edit?
If we set this visible in the weapon infobox, how do we point out the current note: "Damage type is choking. Damage type for the skin is physical." (e.g. Arkhalos) effectively? Are we keeping the note? How would the according skin infobox look like (depending on #1 and #2)?

So far it seems that we should set it to skin infobox and weapon infobox, but I'm not sure of what extent. --Tolkyria (talk) 08:15, 4 October 2021 (UTC)

(Reset indent) I think it's not really a good fit for the infoboxes because of the explanation that's required. That's why I think that an explanation template could set the property, but I'm fine with infobox + a possible explanation note. Physical is the default so it could be treated as "none", i.e. wouldn't need the property set, because it actually has no such visual/cosmetic effect. Kumiponi (talk) 15:59, 5 October 2021 (UTC)

Okay, but I would still set the property silently in the weapon/skin infobox: 1. it's an additional check that avoids a wrong property declaration on an incorrect page (which could happen with an inline text template) and 2. we can switch it on anytime and show it in the infobox without many edits if we want.

Please go ahead, implement it. Just ask here if you need any help. --Tolkyria (talk) 20:20, 6 October 2021 (UTC)

Skin infobox has now an implementation. I have to check later if it actually works as intended. Currently it allows setting the property for any skin, not just weapons, but I'm not sure if that's wise. Kumiponi (talk) 23:24, 7 October 2021 (UTC)

Looks good! The wiki editors are also responsible for correct infobox edits, I think there's no need to take care of each possible case and thus no need to disable it internally if necessary. --Tolkyria (talk) 11:51, 8 October 2021 (UTC)

I did some testing with various weapons that have the Choking damage type in the base weapon instead of the skin (see List of weapons with an unusual damage type). They don't actually produce the choking effect, and the in-game information pop-up doesn't show any damage type for them. It's probably a bug or an oversight. As it stands, the skin's damage type is the only one that matters. We could list it in the weapon infobox too, but those are already pretty crowded so I would leave it out for now. About the Choking effect, it's mainly noticable on playable race characters and some HoT enemies like mordrem trolls, because they have a special "throat grasping" death animation. Kumiponi (talk) 10:50, 9 October 2021 (UTC)

As the primary guy making notes on damage type over the years, I can tell you that it depends on the skin, the weapon, and the skill used, as the final type applied appears to be dependent on them in increasing order. If the skill has a non-physical damage type, it tends to take precedence. When skins and weapons have a non-physical type, that is the one that is generally seen. I didn't have any examples of competing types in skins and weapons, and even with Kumiponi's example below, there's not enough data to say definitively how it works when there is. But if you're going to track damage types, then skins, weapons, and skills will need consideration. SarielV

07:02, 2 December 2021 (UTC)

Moreover, the damage type of Forged weapons is Choking while their skins have Fire, and the death animation is always Fire, not Choking. Kumiponi (talk) 17:36, 9 October 2021 (UTC)

Mini pages to link to their origin creature

I would find it a nice little QoL feature if I could just click over from a mini's page to its "parent" creature without having to use the search box. My guess is that this can be done either by modifying the Template:Item infobox to automatically parse the creature name from the mini page name, and add a link to it, or have a bot add a link to the Notes section of mini pages. I can't do either of those, so asking here 😄 -- kazerniel (talk | contribs) 10:02, 10 October 2021 (UTC)

~~Belongs in the notes section.~~ Most pages should have this already... -Chieftain Alex

14:03, 10 October 2021 (UTC)

I haven't seen such a link on any mini pages I checked over the years. Could these be added in an automated way? -- kazerniel (talk | contribs) 14:07, 10 October 2021 (UTC)

Best done by hand I should think due to variance in how the pages will be formatted. Someone will need to figure out if there's an equivalent article for whatever the mini is based on in the first place. On second thoughts this would be best placed in the lead sentence of the article before the first heading. -Chieftain Alex

14:24, 10 October 2021 (UTC)

Not all minis have the same name as an existing NPC, even if they share model, so I think adding this with a bot would not really work. Also yeah Alex, some pages already have it: we have been doing it inconsistently though, sometimes the mini has no link, sometimes it is in the intro, sometimes in the notes. ~Sime 23:53, 10 October 2021 (UTC)

What if it was part of the infobox? Like how it by default looks for an image with the same name as the page, but you can also tell it to link to a custom image. So we could manually handle the exceptions. (Wanted to see the scale of the missing links, so randomly clicked through ~25 minis on Miniature, and couldn't see any minis after HoT that has a link to its creature.) -- kazerniel (talk | contribs) 09:10, 11 October 2021 (UTC)

I am not sure infobox would be a good solution, considering sometimes the mini is named differently from the NPC. I quite like to have the name in the intro, so each page would read "Mini X is a miniature of <Relevant NPC Name>. ~Sime 17:20, 30 October 2021 (UTC)

Updating the Wikipedia article for Guild Wars 2

Hi guys. I've slung a copy of w:Guild Wars 2 (wikipedia article) on User:Chieftain Alex/sandbox6. Since the main wikipedia article has a level of protection on it, the gw2 article on wikipedia doesn't often get updated. Some sections are rather out of date (Hello Mac OS).

I'll copy over any changes made to my sandbox copy some time next week - anything you want to amend, please feel free to do so (bear in mind I will review what is changing to make sure it is still impartial). -Chieftain Alex 20:22, 13 October 2021 (UTC)

Made some more edits today as prompted by Sime. -Chieftain Alex

15:58, 17 October 2021 (UTC)

Wikipedia article now corrected. Link above changed to a revision id instead of my live sandbox. -Chieftain Alex

19:09, 21 October 2021 (UTC)

Tango icons

As already mentioned on the Necromancer talk page, tango icons are somewhat outdated and the rationale for their use doesn't really fit in my opinion since we have valid ingame counterparts that could just as easily be used. Alongside this, the tango icons take time and effort to create, sometimes taking up to a month or two after a release comes out to be created. If we used the ingame icons, we could both be more faithful to the source material of the game, and also get more immediate ways to show that something belongs to a certain profession or elite spec. For example, take the necro tango icon vs. a recoloured ingame version.

The discrepancy between the two is clearly noticeable with the tango icon having a less accurate shape (alongside imho a worse palette). Sunlion (talk) 01:05, 28 October 2021 (UTC)

Totally agree that tango icons should see little use overall and especially with profession icons. We have the 64px official versions that we can colorize (and spend more than 2s as I did for an example) and shrink as needed (just like the blurry 20px tango versions) as well as 32px official versions which we can color and shrink as they are used in game. Can see examples of the Large official icons and small below. Dak393 (talk) 01:19, 28 October 2021 (UTC)

One of the advantages of tango icons is that we can design and colour them as we wish, without having to change Anet's property and pass it off as their work. I.e. at first blush, I'm not comfortable with the legality of the above approach. Greener (talk) 01:47, 28 October 2021 (UTC)

That's a good point and we can get Anet clarification on the recoloring but we do already edit official icons and give proper credit for them. Also there are official colored versions already used in say PvP for small icons in use and we have official larger icons. If the recoloring is fine we can use the official versions or color based on them. I don't see this as an issue assuming proper licensing is used but wouldn't hurt for an Anet comment. Dak393 (talk) 01:52, 28 October 2021 (UTC)

I like the tango icon because of the clear outline. It looks better. --BuffsEverywhere (talk) 02:52, 28 October 2021 (UTC)

It is an option to add an outline or use the small icons which already have outlines as well. Dak393 (talk) 03:03, 28 October 2021 (UTC)

(Reset indent) Lets get some more examples:

First 3 are the current tango icons scaled down to 20px (3rd being 20px by default). Fourth is a colored official 64px with no cropping. Fifth is that same icon scaled down to 32px with cropping (as we have on the tango icons anyways). And the 6th and last quick example is the official small white icon with the white color shifted. Dak393 (talk) 04:20, 28 October 2021 (UTC)

Personally I think the sixth is better than the others, seeing as it clearly shows the intended shape with definition and is clearly visible. Sunlion (talk) 04:25, 28 October 2021 (UTC)

I like the tango icons, but mostly when I say that I'm actually talking about the Event and Map icons. They're designed with one purpose in mind, and are capable of clearly representing whatever hugely detailed icon arenanet produced at small scale.

I'm not so keen on the Profession tango icons, but I suspect the more recent tango icons are less good than the originals produced for the core game (in particular I think Harbinger is a bad example to use). Just to be clear here, Soulblydd has come up with really faithful interpretations of the full size profession icons for EoD, but there's no reason we can't modify the tango icons further if we think they're clearer with further changes. What used to happen with the 48px and 20px tango icons is that they'd be simplified versions of the 200px SVG version (in each smaller icon you absolutely need to beef up the width of the border to compensate for the reduced size) - you can't just resize an icon and expect it to be as clear (which is why the first three icons above appear identical when resized, I strongly suspect the same svg has just been exported at 20px). The Harbinger icon is just a green blob when shrunk to 20px.

I think if done well, recolouring the "white" icons could work. However if we want to redraw the icon in tango style with SVG + make it visually identical but of a higher quality, I don't see why we couldn't support that. -Chieftain Alex

08:23, 28 October 2021 (UTC)

Edit: Just noticed we don't have the tango SVG versions on the wiki (well for everything except revenant which I did [badly]), that would be helpful imo. Also the reduced size EoD icons have been uploaded by other users which guarantees they're just scaled png files. -Chieftain Alex

08:26, 28 October 2021 (UTC)

However, I don't think we need the large (200px) or medium (48px) versions of the tango icons used anywhere in the main space. We should be focussing on the small (20px) icon since that's the ubiquitous one. -Chieftain Alex

08:27, 28 October 2021 (UTC)

There are several aspects that irritates me in this discussion:

Noone mentioned the historical aspect. Wiki users are used to the core profession tango icons for nine years, Heart of Thorns specialization tango icons for six years and Path of Fire specialization tango icons for four years. Please keep that in mind when suggesting such a drastic change that overthrows a well-established system. In my opinion the wiki should stand for consistency (and obiviously availability and completeness but these two don't come into play here) by keeping the same colour schemes, the same icons, the same overall format. Of course this doesn't not mean that changes are not allowed, but, as I already said, when overthrowing an complete approach the new own should be pretty damn good, in order to let all wiki users learn and memorize a complete new format.
The whole discussion is based on showing two icons out of 36 (currently 2 End of Dragons icons are still missing), where the harbinger icon (the currently used tango icon may not even be the final version) probably fails to emphazise the inner black part. For me this has a touch of choosing the weakest icons and try to demonstrate something that doesn't hold for the majority of the other icons.
This discussion mentions the lack of new End of Dragons tango icons and how long they take to be created. Please keep in mind that End of Dragons is still around four months away, so this is not available in-game content (beside four days of beta for each specialization that was on a separate account and any progress is deleted afterwards), all articles have the future tag... we have time. Also one can always upload a quick and dirty tango icon until one uploads a better one. Also, the End of Dragon tango icons can still be improved, adapted, changed.
What's the purpose of showing six different icons from one End of Dragons elite specialization (again might not even be the final version) and commentating which one is better? This is completely out of context as crucial questions are not answered with such comparisons, for example how does the new icon look like compared to the core profession icon and other HoT and PoF elite specialization icons of the same profession, how does the colour scheme compare to other profession tango icons.
On the one hand this discussion suggests using in-game icons and avoid using wiki editor made tango icons but on the other hand then these in-game icons are scaled, cropped and recoloured. In my opinion this are basically just tango icons again, with all the positive and negative aspects.
Last but not least, I want to point out how well-made the currently used tango icons are, independent of how much the individual icons match the in-game counterpart. The currently used tango icons are clear and sharp icons, they match their colours between the elite specializations of one profession extremely well, overall being a great addition to the wiki.

So far I can't see how this suggestion should improve the wiki and the wiki user experience. --Tolkyria (talk) 09:03, 28 October 2021 (UTC)

I'm not sure what's so controversial about using in-game icons. The map ones (vistas, PoIs, waypoints, etc.) have been updated not too long ago and it seemed like users didn't think too much of the change. As for the clarity, when it was brought up briefly in Discord I assumed it would use the Small icons, as the medium and large tango icons are rarely used anyways, and they already come with more clearly defined lines. If anything these would simplify a lot of the work required as then users only need to agree on the color scheme instead of the whole shape. Myriada (talk) 12:09, 28 October 2021 (UTC)

I'd like to mention that the images that i've uploaded (

,

and

) are indeed merely resized versions of the full icon; specifically

[[File:Harbinger tango icon 200px.png|48px]], [[File:Harbinger tango icon 200px.png|20px]], [[File:Willbender tango icon 200px.png|48px]] and [[File:Willbender tango icon 200px.png|20px]]

. (Consequently the first and third icon listed a few comments above should be exactly the same, and the second one is likely close, though i'm not sure how the scaling behaves on it.) I've merely uploaded them for the templates {{harbinger}} and {{willbender}} to work and would have done the same for Bladesworn if the template wouldn't be doing it automatically already. Since it does i didn't and if i'd have thought of it i'd have changed the other templates instead of uploading the - by the wiki resized - images separatelly too. Nightsky (talk) 16:47, 28 October 2021 (UTC)

In my opinion, we should use official icons whenever possible. I also think fan-recoloured official icons (if allowed by Anet) are a great idea. I think official icons are a million times better than tango icons which, to put it bluntly, are fan art.Warming Hearth (talk) 18:03, 28 October 2021 (UTC)

(Reset indent) @Tolkyria If you want more examples, sure. Also, yes, I am keeping in mind the historical use, and that is the main reason I'm starting the discussion. Given the range of opinions demonstrated here, it is most definitely something needing discussion.

For example, see

. Not to insult anybody's work here, but to my point of view, the tango icon version just looks like it's made out of rubber.

. The placement of the fuse is just inaccurate, the bomb is too small, it looks like a mortar and pestle was placed on top of it.

. The borders of the flame make it look like it's some sort of crystal formation instead of a fire. Way too sharp, overall the shape is subtly off. Sunlion (talk) 20:42, 28 October 2021 (UTC)

Okay, maybe I wasn't precise but examples aren't needed for me. Obviously the core profession icons could use some tweaks, no need to prove this, I think some pixels could be rearranged but the overall idea of the tango icons could be preserved (and also should be preserved, see my point historical aspect, providing a consistent wiki experience for the wiki users). However, in my opinion, there are other wiki methods to handle this (for example put an image request or use the file talk page) rather than going to community portal and completely questioning the whole tango icon idea.

As I already said, the examples are kinda biased, e.g. by comparing 20px tango icons with 32px in-game icons (cropped to ~25px), that are much more pixels for this considerable small size, allowing to show a lot more details, in the end a pretty unfair matchup.

Nevertheless, regarding your examples, 1. I can't see any reason to adjust the scrapper icons, in general the HoT and PoF icons are perfectly fine for me and 2. I already said that the core profession icons could use some minor adjustments but in my opinion within the current framework.

Yet, I'm still not sure how these examples justifies to throw the current profession tango icon concept over bord and introduce a completely new one. Yet, nothing had been posted on how this would provide consistent content presentation. Yet, it hasn't been pointed out how and why this would improve the readability. --Tolkyria (talk) 22:10, 28 October 2021 (UTC)

So hold up here. Are we only talking about profession icons? Or all of the tango icons? All of the event icons, all of the dialogue icons, etc.? Because if it's all of them, speaking strictly as a graphic/UI designer, I really can't get behind that. The tango icons we have and use were specifically made for the wiki and are wiki friendly, whereas the in game icons are made for the game and suit the game environment. Those are two different applications, two different purposes, and icons being used for a application/purpose they were not intended for is never a good idea. If the issue is "they don't look official" I can fix that(yeah, some of the core icons need some touching up), I can mimic the official ones so they match better but are still wiki-friendly. Otherwise, I largely agree with Tolkyria, I don't see any benefit to this: we're trying to reinvent a wheel that's been spinning just fine for over a decade. - Do_odleplex 23:49, 28 October 2021 (UTC)

@Doodleplex Just to be clear I think we should focus the discussion and conversation right now solely on the profession icons. Also, from my stance it's never the goal to remove all user/tango icons. There will always be cases where there are no official options or the official options would not work. We have many cases of that right now with examples on event progress icons and the like as you rightfully mentioned.

@Tolkyria A lot of the above points seem directed at me so I feel the need to respond

Personally don't see that as relevant, we've had wrong and bad images up here for years too and that doesn't stop us from updating or fixing them. I think we also did keep in mind that this would be a large scale change and that's why the discussion is happening here in the proper channels first. Would be nice to see constructive comments and suggestions on it all and propose options. So in that regard, no I don't have any issue changing something because it's old, look at how we swapped away from the tango boon and condition icons, no complaints there. The wiki should, to the best of it's ability, be factual and accurate which these are not at all. As a side note, the chronomancer icon was changed, no issues there. Was inaccurate for a long time, was changed, no problems. Honestly I think it's really bad that we've fooled many people all this time into thinking those icons are at all official.
Well you have the necro icon above so I went with the recent EoD one for a quick example. If you think the Harbinger icon is bad that also says something about it being updated. I'm currently rather busy so I didn't want to devote that much time to mocking up more examples (and trying to make them at least decent, wanted to try and make sure the color choice was close to official options and it looked ok). If you think the solution is to make more mock ups I can do that, not a problem. Admitting that several of this icons could be better is just kind of proving the point.
I don't have any issue with this, though the wiki lacking icons and them showing up in main space right now is a bad look. And while yes, anyone could upload an icon even for temporary use no one has for about a month and a half and it seems like all responsibility has been pushed to one user (which is a large burden). And yes they could be changed/fixed/updated but by who and when. Many still have large discrepancies and see few changes besides fixing mistakes (wrong profession, scrapper update, transparency, etc).
I mean the first 3 were really there for looking at all the tango options but as Alex rightfully pointed out that turned out useless for the example I picked so that really could have just been the 20px tango icon alone. The other 3 were different options and examples I felt I needed to present being the full official icon (colored), the cropped and shrunk version (as we already do on tango icons... this is not new to crop icons in general or even official icons), and what is, in my opinion the best option, the colored white icons for small icons. These should, I feel, replace the current 20px uses when applicable. But again, that's the point of a civil discussion and post on all this, to discuss it. You state as well that it's "unfair" to show a cropped version, but I feel like I need to restate that we already crop the icons and that's really no excuse. They are all shown at the same final resolution, the one often mentioned as a problem so if you think we can improve the current tango icons so it's more "fair" then maybe that's precisely something we should do and you're in favor of improving them.
I guess I'll say again that we already crop and edit official icons and images, we are not making any substantial changes (though yes in this case I would consider coloring a substantial change to talk about), and this does not make them any less official. There are valid opinions to be brought up here and still options to discuss. It seems like the 3rd option (small white) is the best but I wanted to hear other opinions and possible issues. This is still an open discussion and no one is going forward with any changes. And honestly maybe the community decides that we don't want to use the official icons, we can still have a discussion on possible improvements to the current tango icons, many issues have already been brought up here on inaccuracies and ones that could be improved (such as bladesworn coloring, harbinger color/design, willbender diamond, even things like the older chrono and revenant icons, ele, scrapper, engie posted above, etc, etc.)
There is a lot of effort and work put into the tango icons and I don't want to downplay that at all. The people that have worked on them and contributed to the wiki are all great and I really appreciate the labor of love to make these and provide them publicly. That said, as explained and shown above they are not all that faithful and take many liberties including with color schemes and designs. This isn't necessarily a bad thing but something that we can and should talk about here and decide if that's what we want. Nothing is permanent on a community wiki like this, just because we did things by hand before or in one style (or no set style in many cases) doesn't mean we can't change things, make new templates, redesign pages, set new standards, and improve the wiki and continue to make it more accurate.

Lets have a civil discussion on this, I think many of the points have been addressed and many are not relevant to the improvement of the wiki. Before this gets too long I'll cut it here and wait to respond to more points. Dak393 (talk) 02:27, 29 October 2021 (UTC)

If I were to remake the tango icons to nearly mimic the official ones but still be tango icons that are more readable for the wiki, would that address most of the issues? I have no issues with doing so(heck it's what I do for a living anyway). - Do_odleplex 03:15, 29 October 2021 (UTC)

If you're okay with doing it, I have no objections. My main concern is that we credit ANet properly and try to be as faithful to their work as we can (within reason, of course). Sunlion (talk) 11:53, 29 October 2021 (UTC)

~~Unfortunately that's an untenable desire.~~

If I'm following the conversation properly, there's a wish to create 20x20px icons from existing 32x32 Anet icons. The new images would only have 40% of the original pixels, so some squishing and blurring of details will occur. The problem exists with any further touching up that is done. If blurred details are removed because they cannot be clarified on the 20px size, or if the outlines of the images have to be sharpened, or if we go and colour the images, we're left in copyright limbo. We cannot release the image under the GFDL, nor can we claim that what we made was produced by Anet. As artists, they have standards for what their work should look like, and we cannot rubber stamp inferior renditions as their own.

The desire to be faithful to their work is wonderful, and I think everyone is on board with that. What we cannot do is have an image which is substantially similar to Anet's icons. A good example of being faithful yet distinct is the scrapper icon. . Both are bombs in the same style—i.e. round ball with a fuse—but they're distinct enough for us to release our version under the GFDL license.

If the community wishes to update our user created icons, that's fine. What we need to avoid doing is making user created icons directly from Anet's icons, because that brings us into an uncomfortable legal grey area. At this point some of you may ask, "Why don't we get clarity from lawyers?" and I would caution you to be careful what you wish for. I've seen it said above that we're already modifying Anet's icons and passing it off as theirs; I'm sure Anet's lawyers would love to take a look at those. By asking for a ruling from a group of people known to be risk adverse, we could lose more than we thought was originally on the line. Greener (talk) 16:34, 29 October 2021 (UTC)

It seems as though my words above have come across far stronger than I had intended. My apologies. I am not the wiki by any measure, and it is the wiki community that chooses its own direction, in this case whether to use tango icons or recoloured icons from Anet. My intent was to speak of caution from my personal, non-legal perspective. I'll further add that I have zero artistic taste, and therefore have no notion as to which route would look better.

Again, my apologies. Greener (talk) 19:02, 12 January 2022 (UTC)

Tango icons (bump)

(Reset indent) I would like to wrap this up before EoD launches. User:Dak393 made colored small icons which I used to prototype an updated Professions nav (compare to {{Professions nav}}). Overall I really like them, I would like some feeback about the colors e.g. are they distinct enough? User:Chieftain Alex mentioned we can change Guild Wars 2 Wiki:Color schemes if needed - the recolored icons use "Profession template colors#Medium". —The preceding unsigned comment was added by Kvothe (talk • contribs) at 18:50, 12 February 2022‎ (UTC).

I'll just recall my points:

Comparation: We are again comparing suggested 32x32px icons with our currently used 20x20px icons, as I already said, considering this small size this is an incredible unfair matchup. Obviously the 32x32px can display so much more details (1024px versus 400px in total) that in my opinion an objective decision isn't possible. Furthermore, your linked preview completely misses HoT and ~~PoF~~ (Edit: My bad, the core ones are missing) elite specialization icons (where the currently used ones are of extremely high quality), while the currently used EoD tango icons might need some adjustments (some of the haven't been scaled down yet). Again, how should this allow an objective and fair decision?
Consistency: The wiki uses the current tango icons for nine, seven or five years (depending on the expansion), all wiki users are used to it, such drastic visual changes should be avoided at all cost. Assuring a consistent representation is on of the main strength of the wiki. No matter when a wiki users tunes in, this way they are immediately familar with it (this also applies to table color schemes, these shouldn't be changed unless really necessary).
Quality: The currently used tango icons are of extremely high quality, even other content creators are using them in their guides or videos outside of the wiki. These tango icons perfectly combine all the possible variations into one icon, for example from the smallest icon in the character selection to the largest highres promotion icon.

So I clear vote for keeping our current high-quality tango icons in order to provide a consistent wiki user experience. --Tolkyria (talk) 19:24, 12 February 2022 (UTC)

I really like those new icons. Colours can be improved. I think elementalist should be more bright red, and thief and rev are too alike. Other than that, I'm all in for this change. About time we use official icons. Warming Hearth (talk) 20:08, 12 February 2022 (UTC)

Dak393 offered to make the missing recolored icons once we decide on colors to use and if we actually want them. Color changes are only on the table to make them more distinct (as in slight changes - not a redesign of the whole colorways). With the current icons we suffer the problem that someone has to create them from scratch which is not as straight forward. I can understand your stance on consistency but then I want to raise: Why are we not using the official icons? —Kvothe (talk) 20:30, 12 February 2022 (UTC)

What's this stance on official icons? We are going to recolor them, we most likely have to scale them (because I guess we still want 20x20px icons as everything is based on this size on the wiki) and after this we might want to tweak a few pixels. After all this adjustments they are still "official" icons? I would them call tango icons, so basically we are replacing tango icons with other tango icons (which are of lower quality in my opinion).

Regarding the creation, they need to be created exactly once, then it's done forever. We are missing two icons, for an experienced icon specialist that's probably one hour work, e.g. Doodle mentioned above that she could look into the older icons; you, Kvothe, already created some nice icons, so is there really noone that could theoretically try to create one of these two icons following the current icon color scheme? But honestly with all this hate on the current tango icons I understand why nobody wants to upload the missing ones (the EoD icon creator uploaded their last icon one day before this post, might be coincidence though). As an example: It took me 20 minutes to create the catalyst icon, obviously because I really lack any image creation skills it was way too edge (I didn't want to tortue the wiki with it), but given a little bit more skill this shouldn't be any problem at all. Overall I don't get the creation argument, the new "official" icons also have to be created somehow, especially time-wise there shouldn't be any difference between creating the last two missing icons (they should be actually way faster to create) and creating 36 new tango icons.

Despite Greener's legal issue drawback, I still think we somewhere have to draw the line, and while it might not be illegal it might get really, really gray.

We extract the icons from GW2.dat which is already a gray area.
We list the GW2.dat id and lie by claiming that it is obtained from the api render service.
We recolor the icons.
We rescale the icons.
We might tweak the icons.
We still claim that these are official icons?!

Wierd take in my opinion that the currently used tango icons completely avoid. We are not using official icons because there are no official colored icons available in the requested size (20px). --Tolkyria (talk)

Edit: Another point: On what are we actually agreeing? On these 18 out of 36 required icons listed User:Dak393/Sandbox4#Colored Small that are even in the wrong size (32px instead of 20px)? Is it too much to ask for a proper complete set of 36 out of 36 icons in the correct size that is properly represented? Wierd stuff how people already jump on this train without having even seen a single usable icon. --Tolkyria (talk) 21:52, 12 February 2022 (UTC)

The wiki logo looks like a variation of the official GW2 icon, so I'm not sure what's so different in this case. As for content creators using tango icons, I'm pretty sure it's because they're readily available from the wiki. I'm not sure what would be the correct legal way to tag these, but overall they sound like an improvement to me. Myriada (talk) 21:29, 12 February 2022 (UTC)

Let's create the full set of colorized small icons for a proper comparison. Please use a mainspace file naming scheme (based on the assumption we'll probably like them). -Chieftain Alex

23:58, 12 February 2022 (UTC)

I actually prefer the slightly bigger size that Kvothe used on their Profession nav mockup. It's easier to see the details of the beautiful official icons. And it's not like size is a problem, anyway. We can always make that nav slightly wider if needed. Warming Hearth (talk) 10:34, 13 February 2022 (UTC)

Profession icons are not only used in navs, they are also used in inline text or in lists. Tango icons should be usable universally and should be compatible with other icons on the wiki, which is fully designed for 20px icons. --Tolkyria (talk) 17:46, 13 February 2022 (UTC)

If anyone wants some fun playing with profession colours (I realise we're more likely to use a mixture of colour, not just one - but gets us thinking): User:Chieftain Alex/sandbox3. Feel free to add your submission there. -Chieftain Alex

21:11, 13 February 2022 (UTC)

So your still creating extremely biased examples by using 32px icons? A 32px icons has ~250% more pixels than a 20px icon (1024px versus 400px), of course certain details can be pointed out much more detailed. This is like the fourth time I'm asking to avoid biased examples; but no, we continue to compare only certain icons (by picking the weak ones from one set) or to compare different icon sizes.

Furthermore, now instead of a single colour icons (a colour that matches the Guild Wars 2 Wiki colour scheme) as initially proposed we should use a mixture of colours? Like the ones we are currently using, aren't we just reinventing the wheel? Also looking at your example the borders are pretty week (Core and HoT), so after recolouring, resizing now we would have to redraw/strengthen the icons? Are those still "offical" icons, aren't we just replacing tango icons with tango icons (of lower quality)?

I'll keep my opinion, the currently used profession tango icons are of much higher quality: they have better colours, sharper borders, better fleshed out details; the new proposed icons do not improve the wiki user experience at all. --Tolkyria (talk) 10:07, 14 February 2022 (UTC)

I've done a quick test of coloured versions of 20px game icons on my user page (been casually following the topic since the missing EoD icons got mentioned on Reddit, and had 30 minutes spare to play around!). Some pixel tweaks to improve sharpness, and all of them are scaled an equal amount so some take up the full 20x20px (such as Reaper and Herald) whereas smaller icons take less space, which means that a number of the icons could be redone a pixel or two larger to fit in more detail, but thought it might help discussion to at least throw what I had on the wiki :) Fam (talk) 02:56, 16 February 2022 (UTC)

(Reset indent) Those look great, nice work! IMHO much better than the current tango icons in pretty much every way. Sunlion (talk) 03:58, 16 February 2022 (UTC)

Seconded. I also really like the color scheme used, it looks very pleasing, although it might not technically be the most accurate. The ones suggested on Chieftain Alex's sandbox (Warming Hearth and Alex's round 2) look better in that regard. Myriada (talk) 08:17, 16 February 2022 (UTC)

Thanks for the feedback! File:User_Fam_Profession_Icons_20px_Example.png Quick test of the icons in-situ using the wiki's 'medium' colour palette to match existing design. My main thoughts on these:

I like the Tango icons, but I favor having icons that match the in-game ones as closely as possible (be those single-colour or redrawn tango) rather than players having to learn 2 sets of outlines.
Tango icons can be more 'detailed' than single-colour icons like these, because tango icons have many more shades to work with (especially for borders), but I personally think these single-colour icons are adequately 'readable'.
As previously mentioned, some of these icons end up being 16x16px because of relative sizing of the source icons, and a couple could benefit to being slightly bigger (Virtuoso, Mirage, Weaver, Renegade). Entirely possible to increase their size by a couple of pixels.
Both these single-color icons and the Tango icons are currently blurry on high pixel-density displays. I have no idea if it is possible for the wiki software to be coaxed into srcset images using different sources, instead of just downscaling (as is done with stuff like ).
Following from the above, a larger version of single-color icons would probably be needed.
I would prefer if the colour scheme of ranger had a tiny hint more yellow. :)

Fam (talk) 00:12, 20 February 2022 (UTC)

Fam, do you think you can produce another version of File:User Fam Profession Icons 20px.png with the colours per User:Chieftain Alex/sandbox3#Proposed Final Version? -Chieftain Alex

22:54, 23 February 2022 (UTC)

No problem; Uploaded as a new version of File:User_Fam_Profession_Icons_20px.png (zip download of sliced icons and source PSD at https://www.dropbox.com/s/c3eiwr3hfhv689b/profession-icons-20px-2022-02-24.zip?dl=1 if needed) Fam (talk)

Brilliant, you're the best. If nobody beats me to it, I'll upload them individually tonight/tomorrow/weekend to ensure we have small icons ready to go for EOD launch. We will still need to implement a common approach with respect to Category:Profession icon templates (as a generalisation, default to the new icons, but have tango available if we want them - probably want a replacement for Template:Tango icon sizes) -Chieftain Alex

07:39, 24 February 2022 (UTC)

They look nice :) Warming Hearth (talk) 17:12, 24 February 2022 (UTC)

So what about the rest of the tango icons that we are using (+the large profession icons), since now they heavily clash with these new ones? And technically the race tango icons are an unofficial representation of the races not based on any ingame icon, unlike the profession icons. EDIT: Also yes, I did not read most of the messages above :( ~Sime 00:55, 27 February 2022 (UTC)

The race tango icons are based on the original city icons for each race from either the beta or pre-release afaik (see File:Rata Sum map icon.png and File:Hoelbrak map icon.jpg) - they might not have made it into the final game but as symbols they're very useful to us and have been around for a long time. There's less of a case for retaining the tango profession icons as the ingame version exists and is used extensively ingame + is recognisable. For the moment I think we'll keep the discipline/race icons. -Chieftain Alex

07:43, 27 February 2022 (UTC)

Actually, regarding the race tango icons, they could at the very least be updated as we do have proper official versions to base an upgrade off (see the Racial Summit Banner guild decorations). Sunlion (talk) 20:36, 27 February 2022 (UTC)

(Reset indent) Another set of issues: crafting profession icons. We have better ingame versions (see for example and ) that could be easily cropped down to 20x20. Sunlion (talk) 23:16, 27 February 2022 (UTC)

For reference: File:Asuran Summit Flag.jpg, File:Charr Summit Flag.jpg, File:Human Summit Flag.jpg, File:Norn Summit Flag.jpg, File:Sylvari Summit Flag.jpg.

They are completely different from our current icons, but they are official. These icons are seldom used in-game so, in this case, the "historical" argument about our current tango icons does have more weight. I don't mind the change. Warming Hearth (talk) 23:25, 27 February 2022 (UTC)

Naming convention

Options (feel free to add more):

<profession/specialization> icon.png
<profession/specialization> icon small.png
<profession/specialization> small icon.png

I like option #1 but I'd have to amend many userpages to move the existing core icons, so I propose option #2. -Chieftain Alex

18:45, 24 February 2022 (UTC)

Definitely option #2. #3 is a crime against nature (and much worse for autocomplete/search cases). - Felix Omni 19:30, 24 February 2022 (UTC)

Ok files are now uploaded, see Guild Wars 2 Wiki:Profession icons#Small colorized icons. Need to think about templates next. -Chieftain Alex

20:48, 24 February 2022 (UTC)

Categorizing tonics and other novelties

Here's a couple of problems I see in current categories.

1. To my understanding, all novelties are gizmos and not consumables, and hence Category:Novelties should be moved from Category:Consumables to be a subcategory of Category:Gizmos.

2. Category:Tonics contains both gizmos (= novelties) and single-use consumables. I would split this category into "Endless tonics" (or "Novelty tonics") and "Single-use tonics" (or "Consumable tonics"), and create a new Category:Tonics with both as subcategories.

An alternative would be to just put Category:Tonics into both Category:Consumables and Category:Novelties. This would, however, keep it impossible to query just the tonic consumables, because of Semantic MediaWiki limitations. (You can't query for pages that are not in some category or don't have some property.) Kumiponi (talk) 20:21, 27 November 2021 (UTC)

There's no reason things can't be in two categories. At the moment we do this on quite a few of them, but it is a bit inconsistent, see the following table.

Context	Category set 1 (Novelty type)	Category set 2 (Original item type, consumed when added to Novelty UI)
Chairs	Category:Chairs > Category:Novelties > Category:Consumables > Category:Items > Category:Guild Wars 2	also Category:Gizmos > Category:Items > Category:Guild Wars 2
Musical instruments	Category:Musical instruments > Category:Novelties > Category:Consumables > Category:Items > Category:Guild Wars 2	also Category:Gizmos > Category:Items > Category:Guild Wars 2
Held items	Category:Held items > Category:Novelties > Category:Consumables > Category:Items > Category:Guild Wars 2	also Category:Gizmos > Category:Items > Category:Guild Wars 2
Toys	Category:Toys > Category:Novelties > Category:Consumables > Category:Items > Category:Guild Wars 2	n/a
Tonics	n/a	Category:Tonics > Category:Consumables > Category:Items > Category:Guild Wars 2

I can't see there being anything useful we'd want to query with SMW for tonics so don't worry about that.

I don't think there's going to be much interest in sifting through consumables and gizmos - I suspect they are coded as the exact same thing ingame and its completely arbitrary (edit: well maybe consumables are single use, and gizmos are multiple use?).

In my opinion, the grouping for novelties shouldn't be at all related to "items" (as soon as you add it into the novelty panel it ceases to be an item and functions similarly to the finishers UI) + novelties should probably be a top level category within Category:Guild Wars 2 (or, on second thoughts a Game mechanic). Therefore I would suggest:

Create the new category "Category:Endless tonics". Add that category into "Category:Novelties".
Endless tonics would have ~~both "Category:Tonics" and~~ "Category:Endless tonics" assigned. This would be done via the item infobox.
Add each "Toy" to "Category:Gizmos" via the item infobox.
Change "Category:Novelties" from being within "Category:Items" to within "Category:Game mechanics" (where Finishers and Mastery tracks live on the wiki).
Modify "Category:Endless tonics" to also be a sub of "Category:Gizmos".

Then we'd end up with:

Context	Category set 1 (Novelty type)	Category set 2 (Original item type, consumed when added to Novelty UI)
Chairs	Category:Chairs > Category:Novelties > Category:Game mechanics > Category:Guild Wars 2	also Category:Gizmos > Category:Items > Category:Guild Wars 2
Musical instruments	Category:Musical instruments > Category:Novelties > Category:Game mechanics > Category:Guild Wars 2	also Category:Gizmos > Category:Items > Category:Guild Wars 2
Held items	Category:Held items > Category:Novelties > Category:Game mechanics > Category:Guild Wars 2	also Category:Gizmos > Category:Items > Category:Guild Wars 2
Toys	Category:Toys > Category:Novelties > Category:Game mechanics > Category:Guild Wars 2	also Category:Gizmos > Category:Items > Category:Guild Wars 2
Tonics	Category:Endless tonics > Category:Novelties > Category:Game mechanics > Category:Guild Wars 2	Category:Endless tonics > Category:Gizmos > Category:Items > Category:Guild Wars 2
Non-endless tonics	Not applicable to novelty UI	Category:Tonics > Category:Consumables > Category:Items > Category:Guild Wars 2

Thoughts? Chieftain Alex

10:15, 28 November 2021 (UTC)

Edit, having taken a look at the api entry for a single use tonic and a multiple uses endless tonic, I suppose single use tonics are consumables, and multiple use tonics are gizmos. Therefore endless tonics shouldn't really be in both "Category:Endless tonics" (sub of gizmos) and "Category:Tonics" (sub of consumables) categories. This is a bit confusing. -Chieftain Alex

10:26, 28 November 2021 (UTC)

Sounds good. I'll implement this if there are no alternative suggestions. Kumiponi (talk) 17:33, 28 November 2021 (UTC)

Changes done. I think all toys are already in Category:Gizmos or Category:Costume brawl toys which is a subcategory of Category:Gizmos, so I didn't change them. Kumiponi (talk) 14:44, 30 November 2021 (UTC)

Thanks, appreciate the help. -Chieftain Alex

16:32, 30 November 2021 (UTC)

The Baelfire page needs updated re: the mastery insight there

The Baelfire currently says the mastery insight in the area isnt available as its tied to an upcoming release in The Icebrood Saga Episode 5: Champions, but the page for the insight itself Champions Insight: Fireheart Rise says its available

i'd update it myself but i havent gotten the mastery and i havent edited the wiki before and dont want to mess anything up :) —The preceding unsigned comment was added by 73.154.95.240 (talk) at 09:39, 7 December 2021 (UTC).

Never a bad time to learn, can look at similar pages for an example of how we are doing it and I've updated that page now. We also have a bunch of Help pages and a discord to ask questions. Dak393 (talk) 09:53, 7 December 2021 (UTC)

Regarding disabling chat links tomorrow

Hi guys, I've just updated the sitenotice to reflect a performance test that is planned for tomorrow. The period of interest to be reviewed will be "10 AM to 2 PM Pacific" (18:00 UTC to 21:00 UTC). In order to facilitate this test, a few hours earlier (I'm thinking at 12:00 UTC), I will be changing Template:Game link to output "disabled" instead of providing a valid output.

To provide some context, the server-side compiled widget files are recalculating at least every second for high-traffic widgets (blatantly a bug, but we need some proof of the problem this causes). This is believed to be the cause for poor server performance at peak hours. This test will therefore compare server response for the test day vs a normal day.

Game link is by far the most used widget on the wiki - there's a few others (Infobox map, Account achievements, Account skins, News, Filter table, Tp total calculate) - but we suspect disabling Game link for starters will prove or disprove the hypothesis. Therefore this test is to effectively disable the widget by removing all occurrences of Widget:Game link within Template:Game link. -Chieftain Alex 13:20, 3 January 2022 (UTC)

Screenshots on (individual) armor pages

In my opinion, all individual armor pieces should have a screenshot on their item and skin page (ala Seer Coat (skin)). Having the picture only on the Armor preview page just adds unnecessary clicking and basically hides the information, while it should be readily available. Of course there is the thing that the screenshot is currently of the full armor, which is another problem (stated few paragraph above by Dash and previously by some other people), but having at least some screenshot is absolutely better than none and having to open another page to see it. Alex confirmed it should be easily done via a bot so implementation should not be a problem. ~Sime 16:42, 12 February 2022 (UTC)

Using the full armor picture on item pages so people do less clicking? Sounds helpful, and I like helpful. I'd put maybe a link to the full gallery page under the image, like "Click here for all races" or something, but otherwise I say go for it. - Do_odleplex 16:54, 12 February 2022 (UTC)

Yes, exactly. And good idea with that full gallery link. ~Sime 16:59, 12 February 2022 (UTC)

No bots required for this, it'd purely be a template level edit. Would need to edit skin infobox and armor infobox, and pickup the "Has appearance" property from the set page. Should be trivial to implement. -Chieftain Alex

17:47, 12 February 2022 (UTC)

Sounds good to me aswell. —Kvothe (talk) 17:51, 12 February 2022 (UTC)

Done. Had to do a bit more thinking with the armor piece pages than the skin pages, as some armor sets don't have "has appearance" property set - e.g. Mhenlo's armor. -Chieftain Alex

18:27, 12 February 2022 (UTC)

Infobox coordinates

Hi all, I thought this was worth a section for general information.

General

When the API is re-enabled (which is anticipated within the next 24 hours), all of the wiki's maps with hardcoded coordinates (typically recorded in an infobox as coordinates = [1111,222] etc) will very likely appear wrong with respect to the displayed background map tiles. This will occur because the world map size has changed ingame, and the origin from which these coordinates were all previously recorded has shifted. If you go ingame, you'll see that the world map is now enormous (noticeably extended west and south - that_shaman's post).

Infobox maps (NPC, Adventure, Heart, Object, Event, and Location infoboxes)

I consider the effects of temporarily disabling/hiding the infobox maps to be less problematic than presenting false information, and on this basis I've just started a chunky size bot run (circa 8500 pages - ETA 3 hours to completion) to temporarily rename all of the infobox map coordinate parameters, appending a suffix of "_old" on them. This has the effect of the infobox thinking there is no coordinate parameter given, so the map won't be shown.

We can then go through at our leisure and correct these old parameters (probably by adding an x/y offset pair) some time in the next week/month, or implement a backwards compatible offset option where it does some maths and adds the same x/y offset pair.

Other templates (Interactive map, World map, others)

The same problem will occur on any other template or widget which uses hardcoded values for markers. We might want to disable those widgets on the wrapper template pages (I'm not yet sure if they will throw JS errors or not). -Chieftain Alex 19:41, 1 March 2022 (UTC)

Personally I would be in favour of disabling the feature, short term. I know that this is something that is used quite often, but I think it is more frustrating to project knowingly incorrect data. If it's possible, I think we should add a small notification as regular users may perhaps not know where this feature went (either as a general placed notification or a smaller one on each disabled page). Venom20

19:49, 1 March 2022 (UTC)

By way of an update, Widget:Infobox map has been patched, as well as Widget:Marker map. The widget used for zones still requires an update; I'm working on something that might be a credible alternative. I've also run a bot to convert the old coordinates/path/bounds as far as I can.

Some of the marker map pages still need updating (75-ish) - this is being done by hand. -Chieftain Alex

18:33, 8 March 2022 (UTC)

So {{Interactive map}} has been patched for the moment to utilise Widget:Zone map v3 in most instances. This is reliant on wiki-side tiles and wiki-side data. The caveats are:

(1) wiki-side tiles only exist for floor 1. If stuff isn't on the default floor (e.g. multiple layers of Bloodstone Fen, The Grove, Draconis Mons) then those tiles are not available, and the sectors will look a bit fucked up since the floors have been squashed together.
(2) I've intentionally limited the number of tiles uploaded to the wiki. The wiki is not designed to be a tile server, and the hack to use the local tiles is really ugly (md5 function and tile whitelist). There has been a suggestion that I've been a bit minimal with the number of tiles uploaded (if you zoom in where there is not a map, some tiles disappear at zoom level 3) - I'll need to tweak the tile whitelist generator if I upload those.

I've also updated {{Infobox map}} - this will now use wiki-side tiles and wiki-side waypoint data too. The caveat is similar; it only works on floor 1.

I'm planning on adding in the custom markers from "Template:Marker map" into zone map v3 at a later date.

Long term the plan is to use ArenaNet's tiles, but until they update them then the above updates mean that we can display most maps sufficiently well. -Chieftain Alex

12:43, 20 March 2022 (UTC)

End of Dragons wiki theme

Per Talk:Main Page/editcopy#Updating Banner & Background color for EoD Update: "Hey guys, shouldn’t we update the wiki theme to fit the new EoD release? It’s about time, I guess?"

If anyone wants to identify and propose some suitable artwork (banner being the left/right images on the main page, and potentially also the wiki top-left background), please feel free to do so.

For reference the current images are:

-Chieftain Alex 18:37, 8 March 2022 (UTC)

Seeing as the QAL background is recolored Charr for Icebrood Saga, maybe a sea green recolor of the human art for the new QAL?

For the main page backgrounds, maybe the left and right sections of this image?

For the skin header, I think this one and this one have the right visual flow and could be cropped well. If we want something simpler and more abstract, this image from the End of Dragons website might work? Aqua_[talk] 22:35, 20 March 2022 (UTC)

I love the idea of File:End of Dragons launch concept art.jpg left/right. I wonder if we can get a version without the foreground characters.

Header has been updated since my original post (even if the image cache is preventing latest version from appearing), but yeah the shop image could work too. -Chieftain Alex

23:13, 20 March 2022 (UTC)

Not sure if you are aware of it, but if I remember correctly we got the left and right background images directly from ANet (even with instructions on how to place them). Maybe you could ask Stephane for new ones? --Tolkyria (talk) 10:14, 21 March 2022 (UTC)

I asked Stéphane. He started the process (2022-03-14), but he does not know where it will take him. —Kvothe (talk) 15:48, 21 March 2022 (UTC)

File:Main page background left (End of Dragons).png - left side cutout, will do right tomorrow unless someone beats me to it. -Chieftain Alex

00:23, 28 March 2022 (UTC)

.mainpage-background-wrapper {
  overflow-x:hidden;
  background:url("/images/2/26/Main_page_background_left_(End_of_Dragons).png") bottom 0px left -300px/auto 1080px no-repeat,
    url("/images/e/e8/Main_page_background_right_(End_of_Dragons).png") bottom 0px right -250px/auto 1080px no-repeat,
    #FFF;
}

File:Main page background right (End of Dragons).png - hrm ok I have both images. Not sure if I like it, might be my background positioning/scaling. -Chieftain Alex

07:41, 28 March 2022 (UTC)

I've now moved Stephane's new images to replace the ones above. -Chieftain Alex

17:49, 29 March 2022 (UTC)

Previously, Quick access links displayed File:Quick access links background (Icebrood Saga).png directly in the center, now we are using only the left main page image. What about using the right main page image too in the class quickaccesslinks-background-wrapper? --Tolkyria (talk) 19:48, 29 March 2022 (UTC)

I think we can probably just reuse the same assets on both pages, I've swapped the class on "Quick access links". I'll get around to updating the CSS when the image cache clears on the correct filenames. -Chieftain Alex

21:10, 29 March 2022 (UTC)

Arborstone PoI as semi-areas

We tend to not add NPCs, objects and such on Point of Interest pages as they belong on the area page. In my opinion, however, since Arborstone lacks areas and only has PoIs and it can be hard to nagivate, I propose we should make an exception and list NPCs/objects/etc on the PoI pages in Arborstone to help with navigation. Club Canach and Arborstone Inn are already formated similarly to areas, and we do make exceptions for instanced PoIs; Arborstone is a semi-instance as well, basically. To answer a concern of one of our editors posed on Discord, nothing would change on the main Arborstone page nor NPC pages, and we would continue to format them as usual. ~Sime 21:38, 23 March 2022 (UTC)

I agree with Sime. Sunlion (talk) 21:46, 23 March 2022 (UTC)

I'm on board with this too. With this many important NPCs it is hard to navigate this area. This should stay an exception though. —Kvothe (talk) 12:35, 25 March 2022 (UTC)

Arborstone has an area (technically two). It's named Arborstone as well. (See here.) In that way it's similar to the EotN, which only has one area (that is named differently from the zone/map), the Hall of Monuments. (See here.) Nightsky (talk) 21:25, 25 March 2022 (UTC)

Which...doesn't help anyone and doesn't help us with the problem at all. Also making Arborstone and Arborstone (area) is just nonsense, just adds unnecessary clicking and confusion. The big difference with EoTN is that everything is next to each other whereas Arborstone is quite massive and hard to navigate. ~Sime 21:31, 25 March 2022 (UTC)

It's meant to be of informational nature. The only thing i could come up with for this would be "poi area" section headings; keeping everything on the same page (either Arborstone (area) or Arborstone) but under different headings. Not sure how that would do though. Nightsky (talk) 22:02, 25 March 2022 (UTC)

I tried something similar: having headings based on the mastery unlocks. Well, it looked really messy and very inconvenient for the services. I would personally love having the services on the interactive map, though. ~Sime 22:11, 25 March 2022 (UTC)

I suspect you will still want to use a static non-interactive map for the NPC location overview, however I have updated Widget:Zone map v3 to support custom markers/lines/polys. -Chieftain Alex

00:19, 26 March 2022 (UTC)

Recommendation: Archival of Season 1 articles for upcoming re-release

With the upcoming re-release of Season 1 beginning in 2 weeks, I'd like to recommend the wiki to discuss a form of archiving the old style of the content. This would primarily go to the release pages that share the same name (e.g., Flame and Frost and Battle for Lion's Arch based on the article), but also for missions, events, and dungeons that get changed. As we saw with the Visions of the Past missions, there were some changes that can confuse new readers, and editors as well - Canach's Lair being a prime example of such. According to this article, the visions will be removed from the game as the related releases go out and the missions are added to the story journal.
The last time ArenaNet made major changes to story instances, some things weren't archived properly for years. Side rant: the wiki has far too heavy a push for "if it's historical, toss it out" in general making it near impossible for players (and developers) to see this stuff (see: Infoboxes wiping all other categories if status = historical).
TL;DR - I recommend moving the release page Flame and Frost, to a subpage so as to preserve the original form (with or without updated formatting to bring it on par to S2 and later release pages), and the same might be necessary for any returning content that gets changed as we might have a Canach's Lair dungeon -> VotP instance situation, specially for the other four S1 "dungeons" like Molten Facility. Konig (talk) 10:52, 1 April 2022 (UTC)

I find myself agreeing with Konig on this. Sunlion (talk) 11:01, 1 April 2022 (UTC)

We have:

Category:Historical content with subcategories splitted by game context
List of historical skills
List of historical traits
All infoboxes with status = historial continue to set all smw:Semantic Mediawiki properties, so Special:Ask is always an option (it can be used with Property:Is historical or Property:Has availability to target specific pages based on their status).
Templates like {{Contained in}}, {{Sold by}} or {{Skin list}} consider historical content.

So in my opinion there are plenty different methods to find historical content in general. But sure, for a specific historical page it matters a lot on how the pages linking there are edited. --Tolkyria (talk) 12:18, 1 April 2022 (UTC)

Tolkyria, that is a completely different topic (and a conclusion I thoroughly disagree with - most readers don't know those links exist, and even then they're just long, no context lists that doesn't help at all when searching through content-related stuff).

This is about what we should do for pages that cover things that are being fundamentally changed in the upcoming rereleases, such as the release pages themselves. I am trying to prompt a discussion for that to get others' ideas (or agreements), while making the suggestion that we archive them as a subpage. Konig (talk)

I absolutely agree with archiving of the old release and main content pages in the way they were presented upon their first release. ~Sime 12:53, 1 April 2022 (UTC)

Totally up to you, then to be honest don't add a "side rant" with in my opinion unjustified claims if you want a focused discussion. Categories tend to bury pages, no matter if we include or exclude historical pages. So I think the current idea of splitting them properly by their status is the best approach to keep the categories usable. --Tolkyria (talk) 13:14, 1 April 2022 (UTC)

I think this is a good idea. I'd be very surprised if S1 gets reimplemented into the game completely unchanged. I'm sure significant tweaks will be needed to even get it into the story journal to begin with, but it's also possible they'll modernize some aspects of it while there- telegraphs, boss skills, health, etc. It would be a real shame to risk those original pages being overwritten with the re-release. I don't know if this would ever be considered for release pages/chapter pages? but the biconic characters dialogue sections having their archive section in the sidebar seems to work really nicely and it keeps it in an easy-to-find location for those that might be searching for that old content. Maybe having the archived release articles linked below the infobox of the new pages could be an idea? Gwylen (talk) 14:16, 1 April 2022 (UTC)

There are quite a few pages that link to Flame and Frost, and while a lot of those come from nav templates where it's correct, many of them specifically talk about the original releases from season 1. Things like "North Nolan Hatchery was added post-launch in the Flame and Frost update back in March 2013" that don't make sense to have a link to a release from 2022. It might be a good idea to run some sort of bot or something to change the links to lead to Flame and Frost/archive instead (and when we do this again for more of the repeated stuff), to make them connected better, and then just repair the places where it made sense anyway?

22:42, 14 April 2022 (UTC)

Modify API Key template to handle multiple accounts

The API key template (example: Treasure Hunter#Collection items) that allows a user to check their inventory against a collection page can only handle a single API key.

Would it be possible to modify this template to a 2-column table that holds multiple api keys along with a text column for an account identifier? Separ (talk) 22:27, 5 April 2022 (UTC)

You already asked that but to be fair noone answered. In my opinion such optional boxes should take up as little space as possible such that the readability and actual content representation do not suffer. So I'm against a vertical expansion of the box, probably something like a dropdown menu could be possible.

What's the percentage of wiki users that actually needs this? I'm assuming that an overwhelming majority of wiki users is only interested in one account and thus has only one API key (for example there wasn't a single respond that supported your idea in the last discussion in August 2021). Therefore I think making the API box setup and usage more complicated in order to support multiple API keys is not the way to go. Keep it simple and straight forward to use.

Might be a stupid question, but what about using different browsers for different API keys? Or what about using gw2efficiency.com which seems to support several keys? --Tolkyria (talk) 08:03, 6 April 2022 (UTC)

Visually it need not take any more space - it could be you click on empty/existing API key + it changes into a dropdown to allow selection of stored tokens. Personally I'm not that motivated to code the idea into js, but if there was a demand then it could be done. -Chieftain Alex

15:17, 6 April 2022 (UTC)

Added to Guild Wars 2 Wiki:Projects/To do list. -Chieftain Alex

20:36, 28 July 2022 (UTC)

Where to list certain EoD dialogues?

Examples are dialogues from allied Jade Mechs (Gretings, CIVILIAN.Inform me if you are in need of aid.) or the noodle stand proprietors (Peddlers: Our Seitung Noodles are spicier than torment.). Those are not greetings in the traditional sense of occuring after interacting with the NPCs, but are more specific to the NPC type than the area's ambient dialogue - especially since which specific mech type spawns seems randomised. Basically, what page(-s) should those go on?

Although ambient dialogue goes on the location page (and in the case of map-wide dialogue, on the map page), we also sometimes make an exception, like for the Suspicious Traveler, the Vigil patrol, or recently Mi-Rae. If a dialogue can be said my a random character, se usually write something like "<Random Awakened NPC>"", so for the mechs it would be like "<Random Jade Mech NPC>:". The distribution, I would probably solve it with a template to avoid having to constantly update several pages at once: first, collect all the possible dialogue (on their pages or on the template already, for example), then make two templates (one for the Peddler dialogue and one for the Jade mechs) and then I would add a transclution of both to the areas where the npcs appear. ~Sime 23:06, 15 April 2022 (UTC)

Adding redirects to community websites

Similar to how we can use the /wiki ET shortcut to go to the event page, I thought about adding shortcuts to community websites e.g. snowcrows.com -> /wiki SC.

So one question is about this idea in general and the other question is which websites to support.

The GW2 Subreddit for example links to a bunch: GW2Efficiency, GW2Crafts, GW2Skills, TacO, BlishHUD, Snow Crows, Lucky Noobs, Discretize, GW2Mists and Metabattle.

Additionally also addons are linked: DX12, Radial, ArcDPS and the addon manager.

I put the ones I personally find most relevant in bold. - DeltaxHunter (talk) 18:21, 20 June 2022 (UTC)

We already have List of fansites and this is more of something for user guides to handle. Not to mention many abbreviations (like SC) are already in use for other things. We try not to just link to off wiki sites in pages too (with the external sites section on items the biggest exception). -Dak393 (talk) 18:46, 20 June 2022 (UTC)

I have a hard time imaging us redirecting to external pages that are completely out of our control. Who knows what will happen to these websites tomorrow? The /wiki chat integration is a feature we were trusted with. Before even thinking about going to external resources, I believe we should get ArenaNet to sign this idea off.

But even then, it doesn’t really feel right to openly link and promote external websites that do not have a permissive content license like our own. For example, Snow Crows has a very restrictive license. GW2Skills even has their own “wiki”…

I wouldn’t mind us making our List of fansites maybe a bit more organized and easy to navigate, and then adding a short redirect for that to allow players to go to that page quickly and then move to one of these sites. But redirecting directly to these third-party websites doesn’t feel right. poke | talk 18:49, 20 June 2022 (UTC)

I am against this suggestion as well because of the already stated reasons. To add to that, even the List of fansites (+discords) page can be sometimes problematic when people try to promote their own communities and projects no matter how useful they actually are to the GW2 community as a whole, so that's (+ the relevant External links in the infobox, mentioned by Dak) enough "promotion" for unofficial GW2 sites here imho. ~Sime 19:00, 20 June 2022 (UTC)

Without my admin hat on, I'd like an ingame method of navigating straight to GW2Efficiency and Metabattle, but perhaps "/wiki metabattle" isn't the most intuitive way of getting there.

With my admin hat on, I concede that linking to external websites from ingame is probably a slippery slope. It would be hard to judge which are "worthy" of inclusion, and I don't know what ArenaNet's stance would be (or if they would even care).

fwiw, technically this request would be very easy to implement (step 1: Add an interwiki (doesn't even need to be prettily named e.g. externalmetabattle:x), step 2: create a redirect page to the interwiki (e.g. "metabattle" with content #redirect [[externalmetabattle:x]])). -Chieftain Alex

19:57, 20 June 2022 (UTC)

Side note: I did a first overhaul pass on List of fansites. —Kvothe (talk) 20:18, 20 June 2022 (UTC)

To make it easier which sites should be linked, maybe officially partnered sites only. That being Snow Crows, GW2Efficiency and Mists to begin with. - DeltaxHunter (talk) 20:23, 20 June 2022 (UTC)

I could get behind the idea of partnered sites only. -Chieftain Alex

20:56, 20 June 2022 (UTC)

I'm pretty thoroughly against the wiki having hard redirects to external sites, even without the game integration side of it, let alone with it. That being said it would be reasonable to create some redirects for, e.g. snowcrows, gw2efficiency, etc, to our own List of fansites, anchored to the correct sections. So you could /wiki snowcrows, you go to a wiki page (which is expected behavior for /wiki), but you're just one click away from actually visiting the snowcrows site. - Tanetris (talk) 22:13, 20 June 2022 (UTC)

Remove non existing vendors from templates for item acquisition

This rune still lists Valiant Saeraquel as a vendor, even though Valiant Saeraquel was removed from the game. Is there a way to add a tag to Valiant Saeraquel and similar NPC's wiki page, so that their offered items won't be included in current acquisition methods? —The preceding unsigned comment was added by Lantanar (talk) at 02:31, 23 June 2022‎ (UTC).

This wiki is trying to document every aspect of the game, this also includes historical pages that are no longer part of the game as well as preserving historical crosslinks. For example your mentioned historical vendor, please note that it is always listed after the currently available items as grayed-out entry. Answering your question: by template design changing a "tag" in the NPC infobox won't have any result, the parameter "status = historical" is the intended one. --Tolkyria (talk) 06:56, 23 June 2022 (UTC)

Wouldn't it be better if on the rune page there was an extra section for historical acquisition methods? As it stands if you are a new player looking to get this rune, you will see a different way with a possible unknown currency. If you click on the link you will land directly at the "Items offered" section and miss any notes that this merchant doesn't exist anymore. This leads to unnecessary time spent researching and or trying to find the merchant ingame. Lantanar (talk) 13:27, 23 June 2022 (UTC)

In theory probably yes, in practice we would have to maintain it somehow. The wiki currently lists 8000 vendor entries that are marked as historical and 4000 items that are sold by historical vendors (or are no longer available from the current vendor). In my opinion dealing with those manually is nearly impossible and would result in missing and incomplete acquisition sections, so we somehow have to deal with it automatically. I'm not really fond of the idea to add an extra historical table automatically via the sold by template (for example in the rune case this would mean an extra section heading and an extra table header just to display a table with one historical vendor row).

But what about the following: currently, the historical vendor row displays "Vendor currently unavailable" or "Item currently unavailable" when hovering the table row, however given that you are not hovering a wiki link, which to be honest is pretty easy to miss.

I would suggest to move the hovering text and display it as a small suffix next to the vendor (then in your example on the rune page the table row would say: "Valiant Saeraquel (vendor currently unavailable)" in the first column), at the cost of redundancy for some items that have only historical vendors. --Tolkyria (talk) 14:48, 23 June 2022 (UTC)

I think having (vendor unavailable) or (historical) would be a good solution, since it is what we already use for Gem Store items: the first for temporarily unavailable items, and the second for items that are permanently out. Could work for the merchants, too. ~Sime 15:29, 23 June 2022 (UTC)

That sounds like a good solution if that is possible. It would be nice if keywords like that were consistently used across the wiki. I don't know how one would go about implementing that, so someone else would have to do it, or instruct me how. Lantanar (talk) 15:42, 23 June 2022 (UTC)

Totally possible, and now done. -Chieftain Alex

16:19, 23 June 2022 (UTC)

I think we need to address the execution a little bit more:

The currently unavailable gemstore has the canonical name "Gem Store (currently unavailable)", so the displayed result is "Gem Store (currently unavailable) (vendor currently unavailable)". That's a little bit too much, I guess we have to remove the suffix from the page Gem Store/unavailable. The Gem Store/historical with the canonical name "Gem Store (historical)" is fine though I guess, to clearly indicate that it won't come back, or maybe change it to something like "retired".
Regarding the Lantanar's consistency across the wiki, for example {{contained in}} and {{gathered from}} are using the availability terms: "current" (suppressed), "historical", "future" and "unimplemented" (the last two doesn't really matter for vendors). However, the terms "vendor currently unavailable" and "item currently unavailable" are more meaningful in this case so I would stick with them, see also the gem store implementation above.
There's a discrepance between the hover text and the displayed suffix, namely if the vendor table row is set to historical but the NPC has the status current. Then the suffix shows "vendor currently unavailable" and the hover text "item currently unavailable". I think these two should match.
Should we apply this also to the template vendor query table (for example used in "currency for" sections)?

P.S. Maybe we should move this discussion to Talk:Sold by at one point such that we can find it later on. --Tolkyria (talk) 17:30, 23 June 2022 (UTC)

Quick edit summary, I added the suffix split "vendor currently unavailable" (historical NPC) and "item currently unavailable" (current NPC but historical vendor item) to {{sold by}} and {{vendor query table}}, removed the hover text as it is already shown, adjusted the gem store pages. --Tolkyria (talk) 20:07, 23 June 2022 (UTC)