Guild Wars 2 Wiki talk:Practices and processes/Archive 04

Sign your comment link in "Please note"

Please note:
* If you do not want your writing to be edited mercilessly or redistributed by others, do not submit it. 
* For testing, please use the sandbox instead. 
* On talk/discussion pages, please sign your comment by typing four tildes (~~~~). 
* See our editing guide for more information on editing. 
* Please use the Show preview button before saving changes to reduce the number of edits shown in the recent changes list.

When a users clicks on "sign your comment", he/she is taken to Guild Wars 2 Wiki:Policy instead of Help:Signatures#When_to_sign. Can this be fixed? Yoshida Keiji (talk) 13:57, 31 August 2012 (UTC)

That text is defined at MediaWiki:Edittools. Link updated. —Dr Ishmael 14:07, 31 August 2012 (UTC)

Armor Page and image formatting

Perhaps I've just missed this somewhere, but I can't find this anywhere, only a weapon Page and image formatting guide. Can we have one please or at least an example page? Thanks! --Sir Biggus of Aggro 12:46, 23 September 2012 (UTC)

I don't believe there is one. A discussion on this topic has been started here: Guild_Wars_2_Wiki_talk:Projects/Armor_skins - LordEhzed 16:49, 25 September 2012 (UTC)

Edit Summaries

Unless I'm blind, there's no encouragement to leave a Summary when editing pages? I think there should be, but as I'm having trouble just stringing sentences together at the moment, so someone else may like to do it. --Nighty 04:25, 13 October 2012 (UTC)

It's not required. Some people use them to hint at what they're doing, some people use it as a TL:DR of a long post, some people use it as a field to put snarky comments in, and some people don't use it at all. -Auron 03:47, 13 October 2012 (UTC)

I realize it's not required. When used properly, even a short summary is very useful when viewing history/diff. --Nighty 04:25, 13 October 2012 (UTC)

Right. The point of this page is to document what's commonplace - established practices and processes for various aspects of the wiki. While edit summaries can be useful, not everyone uses them, and not everyone who does makes them useful. It's not "a common practice" that "has been agreed upon," and thus it doesn't really belong on the page. -Auron 05:11, 13 October 2012 (UTC)

Consider this a request to make it "agreed upon" then? --Nighty 05:25, 13 October 2012 (UTC)

Actually, I'm not even sure why suggesting people leave a useful summary needs to be made into an "issue" -- it's clearly a good thing. Perhaps I should have found a better place to bring it up. --Nighty 06:02, 13 October 2012 (UTC)

Right. This page is to document what the collective userbase already does, so new users can glance over it and get a feel for how things already work without having to trudge through years of policy discussions like we had on GWW. It's just documenting consensus, in essence. What you're trying to do is change consensus - which is fine, if you feel the goal is worthy enough, this is just the wrong page for it :p -Auron 07:41, 13 October 2012 (UTC)

Feel free to move it! --Nighty 08:09, 13 October 2012 (UTC)

Skill challenges

So, after attempting to add multiple skill challenges, to no avail, I can't seem to determine one uniform style/guideline for skill challenges. It seems very piecemeal, which is in part because of the sheer number, and because each skill challenge is different than the others. But I think that we need to create some uniform style specifically for skill challenges, and then stick with it. Something that will handle skill challenges for battling an NPC, yet also for communing; something for performing actions (see Deputy Crackshot), yet also for consuming a glob of paint. Is there some guideline in existence, and if so, please point it to me; otherwise, could we start a specification for one? --Jyavoc 02:28, 5 November 2012 (UTC)

See the tl;dr that is Guild_Wars_2_Wiki_talk:Projects/Cartography#Denoting_non-fighting_Skill_Challenges for this among other things--Relyk 02:35, 5 November 2012 (UTC)

Holy— that's really long. But has anything come out of it? I read through the first number of posts before I realized just how long it was. But it seems that even if something did come out of this, I'm not the only one confused, because the existing skill challenges appear to me to have no semblance of uniformity, so there really isn't a standard practice for doing skill challenges anyways. --Jyavoc 03:01, 5 November 2012 (UTC)

No, that discussion isn't going to be helpful - it was mostly one person hung up on insisting that every single instance of a god statue should have its own page, even when they are visually and functionally identical. So don't bother reading the rest of it. —Dr Ishmael 03:45, 5 November 2012 (UTC)

So, if that isn't a useful conversation, could we work on creating one? I think it would be important for skill challenges, and wouldn't be a bad precedent to start. --Jyavoc 06:36, 5 November 2012 (UTC)

I don't think it will be possible to create a single standard for all skill challenges, instead we need a standard for each of the 3 different basic types:

1. Defeat creatures (event)
2. Interact with object
3. Consume item

The events, especially, require a different format because they will use {{event infobox}}, and the other types will not. —Dr Ishmael 14:04, 5 November 2012 (UTC)

I agree, looking at this, that there won't be some universal standard for every skill challenge page. There exists a [[Template:Skill challenge infobox]], though; should we make this part of the standard layout for every skill challenge page? I don't know of any pages off the top of my head on here or on GWW that have two infoboxes on their page, but there are hundreds of examples on Wikipedia, and most of those don't look bad in terms of being overloaded with information. And having that on every skill challenge page would be, in my opinion, a good idea — commonality, uniformity, and one change to the infobox (e.g. "let's sort them into smaller categories") requires no botwork to be done. But then past having the infobox on every page, we would have different formats for different types of skill challenges. Also, just a note for making sure it's brought into conversation: interact with object/NPC. --Jyavoc 15:02, 5 November 2012 (UTC)

Oops, ignore what I said about the event infobox then, I wasn't aware of the skill challenge one (it's only used on 8 pages, that's probably why ....wait, I edited it? o.O graaaaagh). It does need some changes, however, to make things more clear:

• Add parameter type with possible values:
  • battle for defeating NPCs
  • commune for object interact -> "Commune"
  • consume for object/NPC interact -> Get item -> Double-click
  • special for unique challenges
• Combine object and npc parameters into initiator - the distinction between object/NPC is irrelevant to the challenge itself.

Do those sound good? Since it's only on 8 pages so far, making these changes now won't require a lot of re-editing. —Dr Ishmael 15:42, 5 November 2012 (UTC)

Although I disapprove of his previous comment about a user, Ishmael's system works as a uniform system. The only objection I personally have is the term special, but that is one rooted in different situation that shouldn't affect the wiki. I say go for it and make a set of prototype articles. - Infinite - talk 15:53, 5 November 2012 (UTC)

I have development versions at User:Jyavoc/Sandbox2 (the skill challenge infobox sandbox) and User:Jyavoc/Sandbox (the infobox testing page). Please feel free to modify these as you see fit. --Jyavoc 18:15, 5 November 2012 (UTC)

You can get "Place of power" on one line if you create an extra css definition, i.e. div.infobox.quest.wider dt { width:85px; } - this way the first column of the infobox takes a width of 85px instead of 78px (the 7px difference stops the word taking two lines). (or you could just make an entirely new css but waste of time imo :p ) Chieftain Alex 20:54, 5 November 2012 (UTC)

(Edit conflict) @Infinite: What's wrong with "special"? What would you use instead?

@Jyavoc: Looking good, I was going to suggest moving the icon into the title bar, and you've already done that. I don't like the long descriptions of the types, though; those need to be more concise, ideally fitting on a single line. Also, using the different labels "Challenger"/"Focus"/"Distributor" seems unnecessary, especially since there are some cases where a battle is initiated by an object (I remember one I did last night, Defeat the ancient oakheart and its sapplings in Gendarran Fields, and there are some statues in Orr that start a battle) and "distrubutor" doesn't really make sense if the initiator is an inanimate object. —Dr Ishmael 20:58, 5 November 2012 (UTC)

@Alex: I tried with CSS originally, but there was also the fact that no other infobox necessitated a change in size, and so I didn't want to make this be something special

@Ishmael: We can change it so that it doesn't have all of the different labels for initiator, but I thought it would be a bit more logical for a commune with a place of power to have "Place of Power: [NAME]" than "Initiator: [NAME]". That was just my opinion, and I'm flexible with that; as well because labels have so little room. And we can change the descriptions to be more concise. I actually made them longer on purpose because I couldn't originally think of short phrases to use for them. I can change that when I have a free moment. Also, I allowed "special" to be a valid type, but the primary value for that type of parameter is "unique." Unique requirements, as in requirements that don't fit into a specific category we've listed from above. I thought that might be a bit less... whatever-the-feeling-is.

And finally, skill challenges has a couple of types that haven't been mentioned from above, such as mob battles. Also, what I've done so far is just with the infobox — which we'd need to finish up, naturally. But I'd also like to see if we could put together a standard skill challenge page layout, like what has been done with NPCs and the like. --Jyavoc 21:43, 5 November 2012 (UTC)

(Reset indent) Good practice is for the displayed label to match (or be similar to) the name of the template parameter for the value. (This obviously doesn't apply to derived values, but we're dealing with direct values here.) Having a label that changes based on the value of a different parameter would be very unusual. I'm not stuck on "initiator" being the term we use, though, so if anyone comes up with a better one, that's fine.

"Unique" implies that this specific challenge is the only one with its functionality. This doesn't work for all non-standard challenges, however, because I'm pretty sure there are at least 2 where the challenge is simply to click through a serial dialogue chain (read the book at the end of Vizier's Tower and talk to the villager in Mellaggan's Grotto), so they're not unique. That's why I used special instead.

As for the "mob battles" - is there a need to differentiate single-foe battles from multi-foe battles within the infobox? That would be better described in the article text.

I don't really have any opinions on page layout, which is why I've only been commenting on the infobox. —Dr Ishmael 21:59, 5 November 2012 (UTC)

Good point regarding all of those. After a couple hours away, I came to the same conclusion about having a static text label. I do like the parameter "initiator," because it's concise and means exactly what it appears to mean. So unless someone comes up with a god word for the matter, my vote is in favor.

As for "unique," there are two more words that came to mind after reading your response: "custom" or "other." I doubt we will ever reach a perfect word here; granted, "unique" does have that interpretation in consideration of the whole, which I wasn't thinking about. But I'm not sure that "special" would be a better word, especially if we have, in your example, skill challenges which are just a dialogue chain (which is not very special at all).

Also, we might want to keep in mind that we can — and probably should — expand our list currently to define more types of skill challenges; the infobox wouldn't be too helpful if only 50–100 skill challenges had something that wasn't "unique." "dialogue" would be one other type of skill challenge, naturally. I'm trying to think of other types off the top of my head, and am drawing a blank, but I'll take a look in the wiki after a moment. --Jyavoc 01:12, 6 November 2012 (UTC)

There are probably 3-4 skill challenges that involve "reading multiple lines of dialogue." (There's vizier tower and the dwarf one in dredgehaunt cliffs or something). Aside from perhaps a couple, all skill challenges fall into the main three categories. Having a special parameter will be more than sufficient.--Relyk 02:32, 6 November 2012 (UTC)

Agreed with Relyk, I think we're fine on types of challenges for now. If we end up having more than 20 or so (10% of the total) with special/other as their type, then we can look for any commonality among them to define a fourth type. Also, I'd be fine with other as the catch-all term instead of special. —Dr Ishmael 04:05, 6 November 2012 (UTC)

Sooo, with all of those changes made/reflected in the sandboxes now and no more features having been suggested, should we check over the infoboxes, move onto a list idea for what a page should have, and then roll out something? I can put together a template page for skill challenges, if we generate a list of what we would actually want on them.

I would imagine for the pages, we would want the following:

• Location
• Dialogue
• Walkthrough (if "other")
• Enemies (if mob battle)
• Notes (optional)

What other things should we have? Also, feel free to reorder my list. --Jyavoc 15:16, 6 November 2012 (UTC)

For the third test case in your sandbox, you link the same thing twice... wouldn't it be better to just link to it once? (i.e. remove the consumable parameter since it seems redundant.) Chieftain Alex 17:33, 6 November 2012 (UTC)

The third case I designed is kind of... poor. I included that for situations when the skill challenge is something like "Charr Shaman wants you to drink her Magic Potion." Where initiator = Charr Shaman, and consumable = Magic Potion. --Jyavoc 19:29, 6 November 2012 (UTC)

Does anyone have any input for this? Sorry, I don't like to bump topics, but I'd like to start standardizing skill challenges on the wiki and can't yet. --Jyavoc 19:17, 8 November 2012 (UTC)

Item formatting

Link to Guild Wars 2 Wiki:Item formatting then have subsections for:

• Weapon Formatting
• Armor Formatting
• Accessory Formatting
• Upgrade component formatting
• Inventory formatting

To go along with each of the item formatting templates instead of having a page for each one.--Relyk 03:01, 20 November 2012 (UTC)

Instances/dungeons/personal storyline formatting

Doesn't seem to be a guide for what to do with these, but somehow the personal story seems to have morphed into its own accepted format. My problems:

1. Instance/Dungeon articles are still largely a mess, and are mostly incomplete at any rate
2. The "accepted format" for personal storyline articles places bug notes way at the bottom, in the "notes" section, where no one will ever see or read them; I would prefer they be moved into the walkthrough section, or at least be above the largely not important dialogues

The former I can't really do anything about since I have no dungeon experience, but I'm willing to go through all mission articles and move bug notes - as long as there isn't some good reason not to do it, like a consensus that was formed somewhere else that I haven't seen. (And if there was, consider this my bid to change it.) Vili 点 07:47, 21 November 2012 (UTC)

For now, dungeons can be left alone because they are incomplete. I don't really want to mess with them until all the information is there. Bugs are fine on the bottom unless they affect progression of the story or instance, otherwise they are just that, notable. I'd definitely prefer significant bugs noted in the walkthrough section because they are relevant to the actual walkthrough. Simply describing the bug in text would be better than sticking bug template in there; people can check the Notes section for a more explicit description of the bug if needed.--Relyk 08:17, 21 November 2012 (UTC)

Right, those are the kinds of bugs that I'm talking about - game breaking ones that prevent mission completion and either need a non-intuitive workaround or force a restart. There is no reason not to have them in the main walkthrough; I like having a glaring red BUG template to announce them, but I'll admit it is rather intrusive in a text-based format. Vili 点 08:22, 21 November 2012 (UTC)

I guessed you were talking in part about Temple of the Forgotten God since I worked on that page :P. The simple reason to keep bugs in the notes section is that its standard for all pages, even people who use the wiki casually can navigate to the notes section from the table of contents. Even better than having bugs listed in or near the relevant section is to have it in text where its needed. Of course, a note at the start of the walkthrough like "There are bugs associated with this instance/storyline, see the Notes section" would be a simple solution and it keeps the walkthrough focused on actually being a walkthrough.--Relyk 08:37, 21 November 2012 (UTC)

I guess that works. We could even write some fancy code that automatically adds a warning message if a notes/bugs header exists...! Vili 点 09:44, 21 November 2012 (UTC)

That kind of check would not work if there is a Notes section with bugs that are considered significant, there can be bugs that aren't really important. It would be good practice to list bugs by importance. Anyways, copypasted the notice template to {{bug notice}} as a simple proposal.--Relyk 00:56, 25 November 2012 (UTC)

I have been into some storylines. The ones I have been into use NPCs/Enemies rather than NPCs/Foes which is common elsewhere. As consistency is a virtue, should the Enemies be changed to Foes? Thanks Claret 14:30, 31 December 2012 (UTC)

I'm for "foes", mostly because it is Anet's preferred term - I remember when they changed all instances of "enemy" to "foe" in skill and trait descriptions after the first beta weekend. —Dr Ishmael 15:07, 31 December 2012 (UTC)

Thanks, if that's your read of the consensus, I'll change them when I come across them. Claret 15:13, 31 December 2012 (UTC)

I prefer foe as well. If the page is consistent in using "enemy", you don't have to bother changing it.-- _talk 15:23, 31 December 2012 (UTC)

I meant that I would change them if I was on the page for other purposes. Having looked at a few more, there is a mixture of Enemy and Foe - so, if Foe is preferred, I'll change when changing other stuff. Thanks for feedback. Claret 16:26, 31 December 2012 (UTC)

Question on formatting

Just curious as to the reaon behind redirecting all of the weapons galleries I added (i.e. Gallery_of_Scepters to Gallery_of_scepters). Is there a reason for it? Was I incorrect in capitalizing the weapon type? Just curious, thanks. --Souldonkey 20:47, 3 December 2012 (UTC)

From Guild Wars 2 Wiki:General formatting#Capitalization: "Page titles and section headers use normal sentence case, capitalizing proper nouns only." Weapon types are not proper nouns, thus they should not be capitalized in page titles. —Dr Ishmael 21:02, 3 December 2012 (UTC)

Gotcha, thanks. I tried looking for that, but couldn't find the bit about capitalization. I'll keep that in mind in the future, thanks. --Souldonkey 21:44, 3 December 2012 (UTC)

question about <-code>

don't know how trivial this will be but, i've noticed specifically for skill pages that has healing power benefit, the respective (fixed or not) information gets converted over to being inside <-code> tags. at the moment, it feels like a (nonsense) summary until we as wiki'ers find the progression between levels instead of just the lv 80 point. the base amount healed is already listed via our preset requirements of lv 80 and matching in-game text, so why read that and modify the extremely concise "gains #% benefit"? p.s. excuse the minus in front of the code tag, it wanted to have fun. 67.233.98.18 00:42, 15 March 2013 (UTC)

I think I understand what you're talking about, but the "gains #% benefit" phrasing is pretty terrible. Listing the healing formula is perfectly sensible to me.--Relyk ~ talk > 02:05, 15 March 2013 (UTC)

guess just feels lacking despite clearer via all numbers. we'll have to wait or ask for people to test for level to level progression in distant future to complete the code strings. sorry if i'm tripping over my own words. 67.233.98.31 02:13, 15 March 2013 (UTC)

We display the coefficient (the % benefit) directly in the template now, so you still have a clean way to show how the skill scales.--Relyk ~ talk > 02:18, 15 March 2013 (UTC)

noticed that was being done to damage (power), glad i can do it with healing too. however it seems now we need to keep those noted full calc info in order to explain the game and co-eff together. i'll try to follow through with these changes for consistency. 67.233.98.18 16:23, 15 March 2013 (UTC)

This sounds a lot like CP talk on coefficients. So, we should be coming to a solution soon (hopefully!). You might want to check out the current ideas and chime in. --JonTheMon 16:29, 15 March 2013 (UTC)

Vandal created (talk) pages, blank or delete?

Since there's a back and forth going on recently, what do we do with (talk) pages that were created purely for spam/vandalism? Do we

• tag them for (speedy) deletion, or
• blank them?

I personally prefer the former as it leaves less cluttered nonsense behind (both in the database and edit history), though I have no problem with the latter, as long as we don't constantly keep undoing one for the other. I demand this settled. This back and forth between tagging and THEN blanking recently is annoying :P --zeeZ (talk) 21:01, 6 July 2013 (UTC)

I'd go with deletion. If you're using one of the monobook extensions you can quickly tag the pages and it will be much cleaner. Is there a way to delete without leaving the deletion log (as if it never existed?) -- Karasu (talk) 22:01, 6 July 2013 (UTC)

My answer is A or Yes (and by "yes" I mean "A and B"). So, either tag them, or replace the content with the delete tag. But blanking after tagging is just poor form. Have you reached consensus that the delete tag should be removed? Nope. --JonTheMon (talk) 22:24, 6 July 2013 (UTC)

My personal opinion: Please do not blank them, but just tag them for deletion (keeping the invalid content). Administrators are expected to check the page history before deleting pages, to make sure that the deletion is justified. Having the page content still on the page makes the process faster and simpler. poke | talk 23:43, 6 July 2013 (UTC)

Ditto what poke said. Spam pages are better off deleted - bots seem more willing to spam the same talk page with sections than create it over and over. -Auron 00:19, 7 July 2013 (UTC)

Ditto. Blanking the page simply hides the spam content, anyone can look at the history and see the spam (although I can't think of why anyone would bother, that doesn't change the fact that it is there). Deleting it, however, makes it completely inaccessible (except for sysops) and, as Auron said, decreases the likelihood of repeat spam. —Dr Ishmael 03:04, 7 July 2013 (UTC)

Where do images go?

OK, maybe I'm missing it, but what is the process for uploading images for use in pages? Do we use an external image host, or is there a specific process to uploading them locally so you can refer to them simply? I did a search on this but saw nothing useful as a result of it. :-/ 68.101.73.125 03:26, 11 July 2013 (UTC)

First you need an account to upload images. then you go to Special:Upload, which is linked in the Toolbox on the sidebar. If we want to upload an icon for Quartz Crystal, we would select the the source filename by either browsing or drag-in-dropping the file name. Go down to "Destination filename" and name it "Quartz Crystal.png", we use this naming convention to display the icon automatically. Do not include the "File:" portion. Select "Icon" in the Licensing dropdown list then upload the file. You will be given a link to File:Quartz Crystal.png. You can now display this image on the page as [[File:Quartz Crystal.png]]. See Guild Wars 2 Wiki:Image formatting for some more information, most files will be .jpg extensions.--Relyk ~ talk < 03:52, 11 July 2013 (UTC)

icon files will be .png, and all other files will be .jpg. -Chieftain Alex 08:11, 11 July 2013 (UTC)

The other approach would be to first create the article with a link to an image (most of our infoboxes do that automatically). Clicking the link then will automatically bring you to a pre-filled upload form. poke | talk 10:14, 11 July 2013 (UTC)

Living story and historical content

I see some inconsistency in the use of the historical category tag when it comes to living story content. Also I'm wondering if the historical tag is the apropiate thing to use or if we might need a new template for this. Two examples first The Mad Engineer was a meta event at Halloween 2012. The looking ahead article on GW2 has stated that hollidays will return and Colin Johanson stated that some parts of living story's would be re-used. So it is very possible that this content becomes non-historical in the feature. The Lost Shores (meta event) was a meta event during the lost shores. Colin Johanson used this specifick event to explain that this content will never be repeated. However this page doesn't have a historical tag. To make matters more complicated, Arenanet have announced to give us much more living story content in the future, but with more permanent impact (but not always).

First off all, if we stick with the current historical tag usage, I would like to ask to do it consistent and go through all the existing living story content.

On the gw1 wiki the living story could easily be identified as GW beyond, which was treated as a campaign. With currently only the main game and all the living story bits that would become a mess. My idea is to add an option to most infoboxes called 'Release'. This can either be 'GuildWars 2' to indicate that this was introduced with the release of the game or e.g. 'lost shores' to indicate it was part of that release. You can argue then what to do with e.g. fractals. The most fractals where released during The lost shores, but some are being released in the future.

the historical template can still be used for historical content (e.g. an npc that only existed during the beta). But for the living story I would suggest to use a special template for each release. This means it can be shown or hidden on command and tracked down more easily.. For example, the mentioned mad engineer event would have template saying:'This page is bout content only available during Halloween'. The lost shores meta event would say 'This page is bout content only available during The Lost Shores'. When it is halloween (or approaching through a preview weekend). We can easily go through the list of all halloween articles (identified by the release infobox) and if it is recurring then do nothing, if it is not recurring then we replace the halloween template with the normal historical template.

To summerize: 1: Introduce an infobox category called release to indicate when the content was released. 2: use a specific living story template for all living story content currently unavailable. 3: Only when a specific living story chapter is repeated and content is not recurring, it gets the historical tag.

Please lemme know what you guys think, and maybe someone more clever then me with wiki code can make a sandbox-template (if you agree with me that is). 195.240.63.18 08:38, 24 July 2013 (UTC)

I think you raise a fair point about the historical tag, and I definitely agree that it is used very inconsistently, and unfortunately also rather confusingly due to the tag being just far too unspecific. Just slapping the template on everything that has been before but is gone now just messes up huge parts of the wiki. This is mostly due to the fact that “historical content” is automatically removed from any automatical categorization.

I think a separation between real “historical content”, for example removed skills or traits, and release-dependent stuff should be made. Putting it in the infobox could work, but I think it’s not that simple (plus it would again make the infobox more complicated).

Maybe we could introduce a “related to release”-tag that would show a quick message like “This content was available during <release>”, just as a short notice. And for actually recurring content, we could parameterize that template to show something like “This content was first introduced with <original-release> and has been made available for the following releases <further-releases>”. That way we could quickly tell visitors that this is not around now but was related to a certain release and/or if it might come back again for some other release. (Btw. we can’t really use a generic release name like “Halloween” because the release was actually called Shadow of the Mad King – of course in this case we could call it Halloween, but this probably won’t work for releases that are not a recurring festival) poke | talk 16:01, 24 July 2013 (UTC)

I agree, the historical content is rather cumbersome, especially when it is release-related info. IIRC, some infoboxes don't even have it and you have to use the standalone tag to put it on. We added something to the Personal Story infobox (which already needs a rewrite, I believe) that allows us to put in the specific release, but we do need a method to note that certain NPCs/events/pages are related to a specific release that has passed. Vahkris (talk) 14:47, 26 July 2013 (UTC)

"Seasonal Content" ? --Alad (talk) 16:07, 26 July 2013 (UTC)

I just made this account but I am the ip that started this discussion. Thanks all for giving your opinions. I made this account with the idea to give some nice sandbox examples but unfortunately I am failing. I'm a wiki code noob. So I try to explain what I mean in words (and my English is bad). I answer mostly to Poke cause he has to most concrete idea. I am against having too many boxes on top of a page and where it can be avoided it should. That is why I want in what is called e.g. 'event info-box' to the right an extra option called 'release ='. This can either be Guildwars 2 (indicating it was added before the first living story Shadow of the Mad King or the release it was included in. Any official release on Release will do. Things that where added (not updated) to the game in the timeframe of a release will be categorized as being part of that release. So for example the info box at Skritt Burglar will say 'Release : Shadow of the Mad King, even if it has nothing to do with Halloween 2012, it was added between 22 October 2012 and 15 November 2012 (the 16th the lost shores was released). Some release pages should be updated to reflect the timeframe, but for the rest they work. Almost all new things added to the game where added on a release page, but for the expectations we can take the the release that was last introduced. An example would be Champion Karka (the release page directs to this page while she is not out of date but defending the orichalcum ore). She wasn't included in the lost shores update but she was introduced before wintersday 2012. This will give the reader the ability to know when something was added to the game

The second thing is to indicate content only available during a certain living story or holiday. This content will also get the infobox to the right 'Release : name of the release', but on top it gets an extra box indicating that this content is/was only available during (e.g.) The Lost Shores. This will be easy to change the template on all pages when an event is repeated/re-used. It is also easy to track down all pages belonging to a temporary event like Halloween to check if it needs to be polished, or if not recurring to change it to historical.I am avoiding the term seasonal content, it sounds nice, but in my opinion it doesn't cover the possible things. Arenanet said something like the lost shores event will never come back so its a release but not seasonal.

how to move on. First off all I would like to succeed in putting my things into good sandbox examples cause visuals work so much better. The only name that pops into my mind is Ish, but I know he is considered the gw2 code guru, so I'm a bit scared to ask him for something that's prolly kids work for him. The second thing is giving more room for consensus. Cause I think the amount of work involved means we need a project, I'm not sure if this is the right place to discuss this. If we reach consensus the next step would be to get the infoboxes updated and the new templates ready. After that it is bulk work to go through every page on the wiki to update the infobox and check if it needs a template. I can help (with my limited knowledge) with the first few steps. For the bulk work I got bout 1-2 hours a day available at the moment. Sorry for again a long post.Ranique (talk) 21:52, 29 July 2013 (UTC)

Any special event content like Halloween and Wintersday that we know is only available during the event can be a case where we categorize the article into the event page. Any permanent content from a release doesn't need to be identified, but any temporary content from the release (pretty much living world content, although there are other articles) needs a flag for being temporary content from the release. We would need a flag to identify special event content that repeats and release content that's only available for a limited time. We can reuse the historical parameter because removed content, special event content, and temporary release content don't overlap.--Relyk ~ talk < 02:12, 30 July 2013 (UTC)

I don’t think permanent content needs a special notice in the infobox. As said above, including this in every infobox would be not so trivial. For new permanent content, we usually mention its release somewhere, either in the introductory paragraph, or in the notes section. I think that is enough, and adding it to the infobox would only confuse readers (because it might not be clear, that it is permanent).

For temporary content we definitely should have some kind of informational note. As mentioned above, I don’t think the {{historical content}} is appropriate for that as it’s far too unspecific. We should just use that template for general content that is really removed from the game. For actual living world content, I have something like this in mind (I went ahead and just created the template after my drafts). We probably then want to categorize all that temporary content into appropriate release categories too (but I would disagree with keeping the historical content behavior of disabling all the other categorization). poke | talk 12:09, 30 July 2013 (UTC)

Being a nitpicker, saying something was available during an event, the word "temporarily" seems superfluous. Otherwise, seems a good idea. --Claret (talk) 12:23, 30 July 2013 (UTC)

Proposal for resolution

I have a idea to make things display better this will require changes to multiple infoboxes. I will be creating multiple additional templates to be used in other templates. The templates will be as follows and add the following parameters:

living world

Required. A yes or no flag on if the content was part of a living world release. Defaults to n.

chapter

Optional. If part of a multi-part release the name of it's chapter.

release

Required: what release the content was part of.

other-release

Optional. If the Living World chapter is part of a multi-part release name type in link format the release names here. Example: [[Flame and Frost: Retribution]]

seasonal event

Optional. The name of the special event that the content was part of.

temporary-image

Optional. This is used for the {{temporary}} template. If you are specifying a image for the temporary content flag put the file name of the image here.

removed release

Optional. If the content is historical what release the content was removed in.

The idea behind these changes is two fold. One to change the notice at the top of the screen for living world releases. See here for a example. If it is part of a recurring release then it will add something to the infobox of when the content is available see User:Anzenketh/Sandbox/Page/3 for example.

What does everyone think about these changes. Anzenketh (talk) 15:59, 17 May 2014 (UTC)

I would just have everything optional. Question: how much would these show, or would the be more for categorization and SMW properties? --JonTheMon (talk) 23:16, 25 May 2014 (UTC)

Technically Living world is not required as it defaults to no. As for what would show only chapter and seasonal event will show in the infobox. If it is marked as historical then using the {{temporary}} template the full release names will show in that box along with the image. I was thinking of modifying {{historical content}} to show for what release something was removed in(optional of course) that is what removed release is for. Anzenketh (talk) 03:24, 26 May 2014 (UTC)

Please see here for context for the purpose of the changes. Anzenketh (talk) 05:34, 2 June 2014 (UTC)

(recent indent) It turns out before we talk about a solution the discussion must be made on if we are even going to use the {{temporary}} template or not. Please discuss that here. Anzenketh (talk) 13:48, 6 June 2014 (UTC)

Template:game link, map link for example

Separate template

{{#show:@@@|?Has game id|format=template|template=map link|default=(''Map id not defined'')}}

Area only

{{game link|map|{{#show:@@@|?Has game id}}}}

Combined (one way)

{{game link|map|{{#show:@@@|?Has game id|default={{{1|0}}}}}}}

Should the template take an article as a parameter instead of the actual id? I like having a template generate the link from an id and then a separate template generate the link for an article. We can also code it to take an article or id in various ways.--Relyk ~ talk < 22:15, 21 August 2013 (UTC)

Yeah, we could go a number of different ways. I'd prefer having a separate template, making up a name on the fly let's say {{page2chatlink|<pagename>}}, which can lookup the page's Has game id value and perform some other logic to determine the page's type, then calls the existing game link template passing those results as the parameters. —Dr Ishmael 02:14, 22 August 2013 (UTC)

The page type is a problem since there isn't a property to identify it. A solution would be brute-force like {{item type}} where you check the page for a property unique to the infobox to identify the type of page.--Relyk ~ talk < 02:40, 22 August 2013 (UTC)

Nothing saying we can't implement a pan-asset property that gets assigned a different value by different infoboxes, e.g. {{Location infobox}} sets Has asset type=map —Dr Ishmael 03:26, 22 August 2013 (UTC)

Has infobox type? poke | talk 00:58, 23 August 2013 (UTC)

First name I would go to, but that doesn't make sense for a property name; you want to identify the type of page not the type of infobox used on the page. Has asset type would work.--Relyk ~ talk < 22:22, 23 August 2013 (UTC)

Has semantic information type? ^^ poke | talk 19:17, 25 August 2013 (UTC)

Weapon set formatting

• User:Chieftain Alex/Templates/Weapon family stats table
• User:Relyk/sandbox/weapon table

Discussed some options with alex for generating the weapon set tables automatically. We already have {{weapon set gallery}} for generating the galleries. The goal is the same any which way. We can include the chat link of course.--Relyk ~ talk < 01:48, 27 August 2013 (UTC)

Weapon strength is a pointless stat, for the most part. It doesn't make sense to compare between different weapon types, and it's always relative to level and rarity. That's why I removed it from the crafted weapon set tables today, replacing it with a preview chat link. —Dr Ishmael 02:13, 27 August 2013 (UTC)

We can display level and rarity instead.--Relyk ~ talk < 05:28, 27 August 2013 (UTC)

Those are uniform for the entire weapon set, and for some weapon sets (especially fine/masterwork crafted sets), there are multiple possible values. They should be noted outside of the weapon overview table. —Dr Ishmael 12:33, 27 August 2013 (UTC)

Leave a description of strength in the summary; for crafted sets, description of available prefixes, crafting recipe, and display berserker prefix of highest level and rarity. Probably an acquisition section summarizes where the weapon set is typically obtained.--Relyk ~ talk < 14:06, 27 August 2013 (UTC)

Every Personal Story Mission In Video

← moved to Guild Wars 2 Wiki talk:Community portal#Every Personal Story Mission In Video

Gallery implementation

• {{item infobox gallery}}
  • {{item infobox}}
  • {{weapon infobox}}
  • {{armor infobox}}
  • {{dye infobox}}
  • {{trinket infobox}} (Backpack)
• {{event infobox gallery}}
• {{Infobox map}}

The gallery for these can be presented the same in a template like {{gallery}}. It should also handle setting Property:Has appearance and Property:Has caption for all the infoboxes. As for format, I already have a proposal with {{item infobox gallery}} with the use of #arraymap. People seem fine with {{achievement table row}} and the tiers. I don't mind using enumerated parameters for the galleries.--Relyk ~ talk < 00:54, 11 November 2013 (UTC)

Ambient scenes

So, I stumbled upon this thing (my pictures). How do we document that? I can add the ambient dialogue to the respective area pages but there would need to be some link between all of them (the quotes in-between pubs are random). This is not a one-of-a-kind thing, Fyr Raggedfur goes through a similarly long route albeit with fewer lines of dialogue. And then there's stuff like Captain Underheim, the scene at least takes place on a single spot but the NPCs still do more than just to talk to each other (another one is group of kids playing hide and seek near at the Priory dig site). I think something like an instance page could work (perhaps in a subpage of the zone/area it takes place in). What do you think? --Sialor (talk) 11:33, 17 February 2014 (UTC)

Bugs and references

I got a proposal to make a policy of asking a reference (link to the forum) when putting up a bug in an article. I got several reasons for this. The first is that some bugs are hard to verify (someone says that sometimes event x or y stalls, but for us it is pretty hard to verify if it is on rare occasions). The second reason is that the official forum is the place to report a bug (besides the ingame function). If anyone find it important enough to make a bug section on the wiki, there should be a thread going on, on the forum as well (imo). That way Arenanet will and should know bout it. The final reason is that having the forum users give input in the thread helps us to verify and follow progress on bugs. Off course, to get this (good) habbit into use I would ask you all to do this from now on, and more importantly, to aks people that don't to do so. What's your opinion?? 195.240.63.18 21:20, 1 June 2014 (UTC)

I don't use the forums at all, and I'm not going to bother double-documenting bugs by making a new thread there if I happen to find one. But in general it's probably a good idea. Vili 点 23:37, 1 June 2014 (UTC)

Contributors reference bug threads and related discussion all the time. If someone wants to discuss a bug they happen to see noted on the wiki, they can do so. People can also bring the bug up directly on the talk page. The wiki isn't going to require or suggest people make forum posts, they may be hesitant to document the bug as a result.--Relyk ~ talk < 00:07, 2 June 2014 (UTC)

Story infobox

• User:Relyk/sandbox/story infobox

Merge {{personal story infobox}} and {{living world infobox}} into a {{story infobox}}. The infoboxes were separated mostly because the living world didn't have a clear format. This is being amended by ArenaNet with the Story Journal and we can use this format for Season 1 once ArenaNet have added it to the Story Journal. With this, having one infobox to address all the items in the Story Journal is ideal.

I'm rewriting the personal storyline infobox to update it along the lines of the Story Journal. The background parameter was a convolution of describing at which stage the player is in the the personal story. It makes more sense for the parameter to be choice and describe which choice the player takes in a certain section of the story. The Story Journal does not describe which portion the player is in for a particular section, so I've excluded it for now. The main purpose of the episode parameter is to describe the episode of a Living World season, which is a collection of sequential Living World instances. This makes sense to use the episode parameter to describe where the player is at in a particular section of the personal story as well. The prev and next parameters will use #arraymap and set Property:Has game icon to the icons for the story instances can be generated automatically.

The storyline parameter will differentiate the Living World and personal story. We may have a Special event value to describe festivals and special events instead of using the {{event infobox}} since these used the same format at Living World. The section parameter will address the particular season as that is how the Story Journal divides up the story. The episode parameter corresponds to the release since this is how the content is delivered and we don't need a disambiguation.--Relyk ~ talk < 23:54, 12 July 2014 (UTC)

Yes, do this. Is that a good response? :D I'm not sure the best way to handle the previous background/choices setup, and they're unlikely to add much more in LW. Vahkris (talk) 13:35, 18 July 2014 (UTC)

Sounds good to me. The only question I have is that story instances have icons? Anzenketh (talk) 13:49, 18 July 2014 (UTC)

On header spacing

Is there any reason why header spacing is forced by some people here? By header spacing I mean "== Header ==" vs "==Header==". Literally every single wiki out there, even wikipedia itself, use no spaces. It's a waste of space, and it's pretty distracting if you have a programmer background, where those kind of things are heavily discouraged since they don't let the eye catch lines as easily.--Lon-ami (talk) 10:35, 3 April 2018 (UTC)

Only speaking for myself, but I do it for readability, even if the DOS-era coder in me cringes at the wasted bytes. With my display setup, no spacing leads to perceived bleed over and difficulty reading. -Azure Fang (talk) 11:19, 3 April 2018 (UTC)

I prefer no spaces, but since Doodle has been 'fixing' them with added spaces, I've begun using spaces to ease her job. Still forget to space them out sometimes though. —Ventriloquist 11:24, 3 April 2018 (UTC)

If you're used to coding, the space makes it less readable, since you're processing it as two/three different words, which is exactly what you don't want to do with styling tags, they should be part of the word. I mean, compare these two:

He llo

He llo

He llo

Versus:

Hello

Hello

Hello

It's just like using "<b> Bold text </b>" vs "<b>Bold text</b>". The spaces make it harder to read the information with a quick glance. Again:

<b> Hello World </b>

<b> Hello World </b>

<b> Hello World </b>

Versus:

<b>Hello World</b>

<b>Hello World</b>

<b>Hello World</b>

There's a reason why no mainstream wikis leave spaces.--Lon-ami (talk) 11:49, 3 April 2018 (UTC)

You see, to me, <b> Hello World </b> is easier to read. It's got distinct separation, each piece (format open, content, format close) framed in their own logical cluster. It seems more an argument of personal perception and preference. -Azure Fang (talk) 12:01, 3 April 2018 (UTC)

I do it for readability as well, and my editing style floats a lot based on that. Sometimes I leave a line between my comments and the previous comments; sometimes I don't. Sometimes I leave a space after a bullet; sometimes I don't. When I did more copy/pasting of patch notes, I found that adding spaces in the titles helped me better perceive where the sections were while creating the initial page. It was a couple extra button presses, but it helped me.

Just do you as you edit. Given the number of people who work on this wiki, there will always be a wide variety of habitual / preferred editing styles. G R E E N E R 13:24, 3 April 2018 (UTC)

I prefer the spacing for the reason Azure Fang stated, it's easier to read. Additionally when I started editing, I was confused as to which way the wiki was doing it initially because it was really inconsistent and as soon as Alex said he did the spacing, and the guideline templates use that spacing as well, I just went with that so that there was consistency. - Do_odleplex 15:47, 3 April 2018 (UTC)

I like spaces in titles, and especially like blank newlines before new titles. I also like spaces after indentation colons. Saving bytes isn't a valid reason to choose one or the other - the main problem wiki's have is editor retention and encouraging new editors. Making it less like a formula goes a long way towards that imo. -Chieftain Alex 17:45, 3 April 2018 (UTC)

The bytes comment was more a self-deprecating joke - of course it's ridiculous to consider the storage space used by spare whitespace in a project like this, and nitpicking over what boils down to the existence, or lack thereof, of two whitespaces in a hypothetical line is equally as ridiculous. I did, however, want to at least point back to the "all other wikis" rationale. Wikipedia mainstreamed wiki usage, and as such its standards flow out to similar project types. But short of making a "if all your friends jumped off a bridge" crack no wiki needs to conform to any other. The overstandardization of Wikipedia is what tends to make it the butt of so many jokes and leads new users there to feel out of their depth. When I make my edits, I'll use spaces. When someone edits my edits, they'll probably be removed. When an anon comes in and spouts nonsense about something unrelated to the article, they'll re-add them. And the cycle continues. It's something so small that it shouldn't need to be standardized or policed. But again, personal (and unexpectedly long winded, sorry) opinion. -Azure Fang (talk) 04:26, 4 April 2018 (UTC)

On page tense regarding dead characters

Popped into Traehearn's page after that rather colorful vandalism earlier and noticed that the header for the page is mostly present tense, even though there are no spoiler collapses to hide his death. I was going to unify the header to past, but decided to check another story death first and found Tybalt Leftpaw's header to be in present and future, with his death summarized in the header. I know GW2's time representation (a zone is supposed to be locked in the time period of its story involvement, except Kessex Hills and Lion's Arch) muddles things a bit, but is there wiki standard? I was under the impression that articles are generally written toward the most recent unspoilered content release, but would love a clarification if I'm missing something (of if I'm flat out wrong). -Azure Fang (talk) 11:00, 4 April 2018 (UTC)

From what I've seen (unless I've missed something over the years of browsing the wiki), there hasn't been any hard set wiki rule on how to write for dead characters. I personally add a spoiler warning tag to the top of the article, try to avoid spoilers in the introductory paragraph of an article (before the Biography section if such exists for the character) and write the text in the intro in the present tense as if the character was still alive (see e.g. Zhaitan) while I write the text in the actual Biography section in the past tense with spoilers galore. I haven't gotten to editing the mentor articles like Tybalt in detail yet, so that's why you'll notice the "different styles" of tense and use of spoilers there. Exceptions to this "rule" of mine have been long dead characters (e.g. Zinn) and borderline cases of well-known "dead" historical figures who make spoilery appearances later on in the game (e.g. Saul D'Alessio) who are described in the past tense from the very beginning. One of the cases I'm not sure of but haven't really touched after folks' additions to it is the article for Livia which, if I followed the Saul template of writing for historical figures with spoilery appearances, would be writing about Livia in the past tense due to her being seemingly long gone whereas the current edit of the article writes about her in the present tense in some places due to her involvement in recent stories. Admittedly cases like Livia can be tricky to solve in a satisfactory manner due to their spoilery nature unless articles are divided between their alias and true self (Kerida and Livia; currently Kerida links to Livia) which may potentially introduce their own problems with spoilers (those looking at Kerida's page before finishing S3E6 will be spoiled to her identity) and excessive articles (exceptions do exist, though, such as having separate articles for Glint's Egg and Aurene although that's also because of the egg technically being an object even if it's deeply connected to the character). So, in summary, I feel like the method I've been using (add a spoiler tag to the top of the page, write in present tense for the introductory paragraph without spoiling too much to give a brief overview of the character, and write all the juicy spoilery and death stuff in the past tense in the actual Biography section) has its merits for reader enjoyment without worrying about being exposed to spoilers. But that's just my two cents on the subject. :) --Kossage (talk) 18:34, 17 May 2018 (UTC)