Template talk:Item infobox

Archive

---

• 2011-2013

Miniatures

Would it be reasonable to add a parameter to denote whether a miniature works underwater? Currently, we maintain that data poorly. It's not always documented on the mini's page, especially when it doesn't work u/w and miniature only covers the specials...and I'm not sure whether that's updated as new minis are introduced.

What I'd like to be able to do is maintain the data on each mini's article and then use an appropriate query to populate the relevant table(s) on the generic page. Perhaps mini aquatic with parms of yes, no, and (by default) tbd, accounting for the ones for which we haven't documented whether it's been tested yet. As new minis are added (I smell Set 4 coming up), it's easy to add the articles and automatically update miniature. Plus, it will also remind people that some do work underwater and some don't.

At least, I think it's worth noting, because it's annoying realizing I'm missing a mini after "stepping" briefly into a lake (you know, when the special physics of Tyria decides that Newton's law should be expressed as "for each minor action when crossing from land to water, there is an unequal and more powerful reaction" and you end up 12 feet under). In particular, my decision to get the Mini Chickenado was influenced by whether it swims (alas, it doesn't).

On the other hand, this template is getting complicated and so perhaps there's an alternative method to maintain the data. – Tennessee Ernie Ford (TEF) 02:16, 23 July 2014 (UTC)

Multiple rarities

Each champion loot bag may drop in all rarities excepting ascended and legendary, but the rarity parameter does not allow multiple values. If the parameter is left empty, then chat link search will stop working. And multiple pages for rarities would be insane, as there's countless versions of each one. Any way around that? MithTalk 23:17, 14 September 2014 (UTC)

Leave both rarity and id blank in the infobox and use {{item variant table row}}. —Dr Ishmael 00:09, 15 September 2014 (UTC)

Collection information

I think it would be nice to link if a item is part of a collection in the infobox. As this is a widespread change I will attempt to discuss this first before adding it. Anzenketh (talk) 18:31, 15 September 2014 (UTC)

I think that's a good idea. We'd have to add it to the various type-specific infoboxes, including weapon/armor/trinket/back item/... any others?

In terms of integration, I'm thinking we'll set Property:Is part of collection and then query that to build the lists on the collection page. Example: Shattered Lockpick would be [[Is part of collection::Trash Collector]]; then on Trash Collector we query {{#ask:[[Is part of collection::Trash Collector]]}} to get the list of all items in the collection. —Dr Ishmael 19:28, 15 September 2014 (UTC)

like collection = ...? -Chieftain Alex 19:52, 15 September 2014 (UTC)

For the input parameter to the infobox, yes, exactly. —Dr Ishmael 19:59, 15 September 2014 (UTC)

Nourishment effect ID

Are there any consumables that share the same exact effects? If not then we could add a second ID parameter for nourishment effects, so using the /wiki command with the effect brings you to the consumable directly as it already includes the icon and description of the effect, and we'll save making individual pages for those effects so they get shown in chat link searches (e.g: Player linking another player's effect to see what consumable gives that). In case there's consumables that share effects, would it be possible to make it so multiple pages appear in search? There's lots and lots of consumable effects. Linking directly to the consumable would save a lot of time of making effect pages. MithTalk 18:34, 21 October 2014 (UTC)

The API doesn't return a skill ID for nourishment effects (like it does for sigil effects or "special" equipment bonuses), so I can only compare the effect descriptions.

• All "Extended" potions have the same effect as the "Powerful" version, but with a 2 h duration instead of 1 h. Since the duration is a distinct field, it seems like these would still have the same ID.
• There are 8 different items with the effect +20 Power<br>+10% Experience from Kills

There are numerous examples in between, with a total of 173 items sharing 67 effects out of 382 unique effects. And that doesn't even count Feasts, because they don't have an effect description (they create an interactive object rather than directly bestowing the effect). Also, because the API doesn't give the IDs, it would be difficult to document in the first place. —Dr Ishmael 19:16, 21 October 2014 (UTC)

Collections now have hints.

A lot of collections now have hints. Would the item infobox be the best part to put this as the hint is usually how to obtain said item? This is different then description as description is value only as collection. Anzenketh (talk) 21:15, 3 November 2015 (UTC)

The hint is not a property of the item, it is a property of the item's entry in the collection. The hints should appear on the achievement/collection page (verbatim), but the item's page should have a complete description of how to obtain it (i.e. not a hint). —Dr Ishmael 21:45, 3 November 2015 (UTC)

(Edit conflict) Some (short) previous discussions on the topic here and here.

As I mentioned in the discussions above, the item's descriptions on the wiki should reflect what is in the game. Nothing less, nothing more. However, it clearly is an issue when they're included on collection pages, most notably the various legendary collections that have multiple steps which can be rather confusing without a guide. All of those pages use SMW to easily pull the information from the existing pages, which worked in the past because all of the collection items had descriptions that either hinted at the acquisition method or had a flat out description on how and where to get it.

Now, there could be several solutions here, which would both honor the existing formatting, and the way the information is presented:

1. Change the item's generic description ("This item only has value as part of a collection.") to the hint shown in the achievement panel.
2. Add the {{flavor}} template under the generic description for all of the hints shown.
3. Use {{STDT}} tables, as seen on this collection page.
4. Tinker the item infobox to allow both hints and the item description to stay, without one obstructing the other.

In terms of personal taste, the third option fits best, as it allows users to add additional information that might not be shown in the in-game hint. I'm not sure if the fourth option is possible or not, but it might be the best objective option out of the bunch. —Ventriloquist 21:46, 3 November 2015 (UTC)

I support option 3, it fits well with my argument above. —Dr Ishmael 21:51, 3 November 2015 (UTC)

I was thinking a variant of 3. It is also a good idea to make sure that people are aware on the item page that something is used in a collection that way they don't get rid of something that might be useful for them. If I am not mistaken all collections are collections of items. This is different from the achievement like Lion's Arch Exterminator while simular to a collection is not strictly one. I was thinking maybe we could use a template and SMW. Have the collection page list Item, description, and Hint. The description could be pulled via SMW and Item would be what it typed in with something simular to the way we type in rows in {{vendor table row}}. We can then use SMW to pull if is part of a collection and put that information wherever. Comments, concerns? On a side note I agree that a hint is not a item property but neither is it being part of a collection. Anzenketh (talk) 22:14, 3 November 2015 (UTC)

But why do you need the item description if the hint is more useful? Omit the description, skip any templates, and just write a table with columns "Item" and "Hint." —Dr Ishmael 22:32, 3 November 2015 (UTC)

You don't need the description if the hint is more useful. The purpose of the template(with SMW) has more to do with updating the item page that the item is used in a collection then updating the collection. Anzenketh (talk) 22:42, 3 November 2015 (UTC)

There's already a parameter in this infobox for that. —Dr Ishmael 22:46, 3 November 2015 (UTC)

Yes I was thinking of updating that "parameter" from the collections page instead of from the infobox page. A item being part of a collection is a property of a collection. Not a property of the item. Anzenketh (talk) 23:00, 3 November 2015 (UTC)

Interesting thing. In game the description "This item only has value as part of a collection" from what I have seen does not appear in game. Also There are some items that appear in multiple collections due to this we can't reuse the description field either. If we decide to just go with simply option 3 no more no less then what is the point of the "Is part of collection" property. I also don't think putting it into directly in the infobox is the best place due to some items can be part of many collections like Auric Sharpening Stone making the infobox rather ugly.Anzenketh (talk) 15:21, 5 November 2015 (UTC)

I altered Template:Default item parameter to remove "(achievement)" from the displayed text, which makes that page look less messy. —Dr Ishmael 18:47, 5 November 2015 (UTC)

Recent changes

...have added whitespace underneath descriptions. Need a brave warrior to shoo it away. —Ventriloquist 22:53, 11 November 2015 (UTC)

Fixed by removing the display of {hint} and just setting the property. I'd like to know why the hint needs to be documented with the item anyway, when the only place it appears is on the collection. What's the point in setting the value here, then querying it on the collection page? Why not just put it on the collection page directly? —Dr Ishmael 00:42, 12 November 2015 (UTC)

I don't know, and I'm still against having hints on the page. It's just a repetition of the acquisition section, especially when the hint is "talk to X to buy Y". —Ventriloquist 09:58, 12 November 2015 (UTC)

The only reason I saw to have it listed here, is simply because the hint text exists in game. As far as I was concerned, the hint wasn't being documented here because it was helpful and it was needed to locate the item, but because it was text on the item description (the collection "version" anyway), just like in-game description and flavor text. I didn't know a better place to document it. I'm fine with removing it from displaying, as long as we keep the property so it can be queried elsewhere. ~Mervil 09:54, 13 November 2015 (UTC)

Oh, in regards to putting it on the collection page. I felt it would be easier to have the hint text set as a property here so that it would be associated directly with the item, and so that it could be queried along with other properties of the item. I'm making a template that hopefully can be used on collection pages that queries for items that belong to a collection and displays them in a list, so that the long lists don't have to be hard-coded individually on the collection pages, when all the data already exists on the wiki, and so that they will all have uniform appearance. Example of my template in use. ~Mervil 10:17, 13 November 2015 (UTC)

Right, but... why does it need to be a property at all? Just hard-code it on the collection page, since that's the only place it needs to exist. —Dr Ishmael 15:46, 13 November 2015 (UTC)

Well, again, my thoughts are this. Some items' only in-game description IS the hint (Dierdre's Perspective, Tribute to Ancient Haivoissen). This hint text is displayed on this wiki as the item's "description", but it is clearly hint text. I feel we either display the hint text, or we don't. If we collectively decide to not display the hint text, then we need to decide how to handle the trophy items that don't have anything but hint text. My preference would be to just display the hint text in the in-game description, or somewhere on the page under a heading such as "Collection", say "As part of a collection, this item has collection hint text: "Talk to Dierdre in the Hidden Garden jumping puzzle upon its completion." ~Mervil 20:37, 13 November 2015 (UTC)

There's nothing wrong with items without descriptions. I usually add a basic intro sentence (e.g. Tequatl's Eye) while mentioning other relevant info in the other sections. Hints do not offer anything to the page that cannot be mentioned in the acquisition or the notes section. —Ventriloquist 20:46, 13 November 2015 (UTC)

Exactly. Instead of the (usually) vague hint, we'll have an Acquisition section that tells you exactly how to get the item. The hint is redundant and useless in that case, and since it's very clearly not part of the item's actual description, there's no need to display the hint anywhere on the item's page. —Dr Ishmael 22:14, 13 November 2015 (UTC)

So Dr. Ishmael. What recommendations do you have for being able to query for Is part of collection, generate a list of those items, and hard-coding the hint text so it appears only there rather than the item's page? I'm trying to find a solution for this hint thing without putting "unnecessary" information on the item's page. What about like what Ventriloquist suggested (and I suggested above him)--putting the hint text in the notes section or acquisition section, that way the text is there and can be set as a property to be queried by my template? ~Mervil 06:20, 14 November 2015 (UTC)

You might be getting ahead of yourself on the semantic properties. We haven't decided on formatting the collection articles. If you want to technically implement it, we would do {{collection item|<item>|<hint>}} in a list on the achievement subobject template. Even then, I don't think we'd semanticize it because any way we store the information is terrible the way we have it, the hint text isn't useful, the text is relatively static, and we won't be using the hint text in any queries. I'd say the best approach is to treat the hint text as trivial information and list it manually on the achievement pages in its own section after major sections.--Relyk ~ talk < 06:57, 14 November 2015 (UTC)

(Reset indent) If you are looking at the hint text as a hint that is unhelpful for locating an item, sure, it's trivial. However, how ever unhelpful you feel the hint actually is, it is still text and a property of the collection item. I don't find the flavor text or in-game description very helpful for locating the item either, or its icon. I cannot locate the item in-game by looking at its icon, no matter how long I stare at it. However, be that as it may, it has been documented on this wiki. What for? does it serve a purpose? Does documenting the in-game description actually serve a purpose? No, it doesn't. It too is trivial, and only listed on the item's page (and nowhere else). But, it is listed, probably for sake of completeness, and stored in a property. It is a part of the item. People are documenting these things on the wiki. The hints are being recorded. They are here. What are we going to do with them? I don't know how to hard-code the hint text onto the collection items' pages without hard-coding everything else related to the item including the item name, icon, description, etc. I feel that if the data is already stored on the wiki (via infoboxes), why re-type everything out? It just seems logical to make a template that can gather the data and then display it, much like the [[Template:Achievement|achievement template]]. The ONLY thing missing for these templates to show all the collection item information, is the hint text. Will the hint text be listed anywhere else? Probably not (but neither is the item's description). But it would make pulling data onto a page with a template so much easier if it was stored in a property. ~Mervil 07:24, 14 November 2015 (UTC)

We document the icon and the flavor text because they are clearly part of the item as they appear directly in the item's tooltip when you have the item in your inventory. The hint only appears on the tooltip in the collection screen, so it's NOT part of the item - the only thing it's associated with is the collection.

"I don't know how to hard-code the hint text onto the collection items' pages without hard-coding everything else related to the item " You do it exactly like Relyk suggested, by having a template {{collection item|<item>|<hint>}} where you hard-code the item name and hint text as inputs, then it queries the item's icon and displays the icon, name, and hint in a table row. We can even invert the current Property:Is part of collection that points item→collection and have this new template set a new property (name TBD) that points collection→item, then set up this infobox to query for which collections the item belongs to. —Dr Ishmael 15:59, 14 November 2015 (UTC)

Building a table one row at a time was one option I considered, and the only way to hard-code the hint text onto the page and draw in already coded item properties, but I was trying to avoid doing each item individually, but rather to query all items "propertied" as belonging to a specific collection, and then draw them into a table.

Anyway, what do you guys think would be the best way to accomplish what Relyk and Dr. Ishmael suggested? #1) Build the tables one row at a time with a {{collection item}} template on the collection page, #2) code in a series of {{collection item}} templates into the achievement table row template that assigns each collection item to the achievement, but also sets the hint into a Has collection hint property, or #3) put the template onto each items individual page, and sets the hint into a Has collection hint property? (the latter wouldn't necessarily have to display the hint on the page, just set it). ~Mervil 17:31, 14 November 2015 (UTC)

I don't want to do any of that. We need to decide on how we format collection achievement pages first. Semanticizing content comes later.--Relyk ~ talk < 17:40, 14 November 2015 (UTC)

There is absolutely no reason to annotate the hint at all. It only needs to appear in one place - on the collection page. The only reasons for annotating something are a) so that it can be used as a semantic query condition or b) so it can be displayed on other pages by returning the property from a semantic query. These hints obviously can't be used for a), and since there's only one place they need to be shown, they don't qualify under b) either. —Dr Ishmael 18:13, 14 November 2015 (UTC)

Playing devil's advocate here... Was there a reason to annotate the item's description? It gets displayed by the infobox, but by so doing, gets stored into a property. The in-game description is never used for a query, and only appears on the item's page. The in-game description doesn't meet either of your reasons above, but it gets "propertied" anyway. In regards to the hint text, perhaps it does qualify for your b) reason above. For example: we added a Has collection hint property and a {{#set: function to the item infobox template. Currently, I think the only item that utilizes this hint property is Destroyer Jar. It's not displayed anywhere on the page, but is used to populate a template I've been working on. Just to show it's use, I updated the Frostfang_I: The Experimental Axe to utilize this template. Please take a look. the appearance of the table generated can be changed of course, but the benefit of this template is that now, lay editors can just plop the template onto the collection pages and a list is generated. However, the hint text isn't included unless there is a hint property set for the item. It may not be ideal, but it works well. ~Mervil 19:59, 14 November 2015 (UTC)

What part of "it only needs to be shown in ONE place" is difficult to understand? Annotating it on one page where it's not displayed, then querying for it and displaying it on one single other page is inefficient and pointless. —Dr Ishmael 00:57, 15 November 2015 (UTC)

You point out "inefficiency". You see, I think its more efficient to type this:

{{collection list}}

than this:

{{collection item|item A|Hint=Hint: do this to get item A}}

{{collection item|item B|Hint=Hint: do this to get item B}}

{{collection item|item C|Hint=Hint: do this to get item C}}

{{collection item|item D|Hint=Hint: do this to get item D}}

{{collection item|item E|Hint=Hint: do this to get item E}}

{{collection item|item F|Hint=Hint: do this to get item F}}

{{collection item|item G|Hint=Hint: do this to get item G}}

{{collection item|item H|Hint=Hint: do this to get item H}}

{{collection item|item I|Hint=Hint: do this to get item I}}

{{collection item|item J|Hint=Hint: do this to get item J}}

etc. for 15-31 entries. And if you are referring to inefficient use of the wiki server by storing the value in a property...what's the difference? It's already being done all over the place (again, I am referring to properties such as the in-game item description that continues to NOT meet either of your 2 reasons above for being semanticized. And yet, there it is, using up wiki server space. At least with hint text, theres a purpose behind it...efficency ~Mervil 03:46, 15 November 2015 (UTC)

Has nothing to do with server space. {{collection list}} implies a query template, which means storing the hint text across 15-31 articles and using a query to format the result, which needs to be formatted correctly. It also means you now have a page with more queries, with all the baggage that comes with semantic queries. That all takes resources for the wiki and editors.--Relyk ~ talk < 05:10, 15 November 2015 (UTC)

Well, OK then. But I thought the whole purpose of semantic wiki was to make such queries. My understanding was that it made overall less baggage, and less repetition. Whole pages can be created with templates that can be accessed over-and-over, without creating and storing each individual page. I was not under the impression it was inefficient with lots of baggage. Admittedly, I am no expert here. I defer to you guys in what's efficient vs inefficient when it comes to back-end stuff. In any case, I think the consensus is to not have hint text on item pages. It seems appropriate to keep it localized to the collection pages. So, where and when do we start the discussions on format of the collection pages? ~Mervil 05:22, 15 November 2015 (UTC)

What makes more sense: 1) storing a bit of text on the only page where it is displayed, or 2) storing a bit of text on a page where it's not displayed, then displaying it somewhere else? Seems like an easy answer... so why did we waste all this time arguing about it? —Dr Ishmael 05:52, 15 November 2015 (UTC)

(Reset indent) I'll be honest, it wasn't that simple in my mind (kind of still isn't). To me, the simplicity increases by putting the hint text on the item page, so a single template can call all of it. It seems like more work to create a collection table row by row. In either case, a bit of text is being stored. But in one method, you have to type a bit of text out on every row along with at least one existing property to call a template on every row, or you type a bit of text on every infobox, and use a single template to pull it all together. Lastly, you were making arguments against adding properties, but they weren't holding water because precedent had already been set--properties have been made and stored (ie: in-game description and flavor text) that are not being used. I guess it depends on what part of all of this you focus on. Which is more important: simplicity in where the text actually is, or simplicity in how the text gets there. FYI: my statements here are ONLY to answer your question about why there was an argument, and not to further the debate. ~Mervil 06:15, 15 November 2015 (UTC)

Simplicity was never the issue in the first place. And I'll be honest, I'm not sure what you're getting at because you are using simplicity in multiple contexts. The single template design you are referring to is a parameterized query template and the reason for designing it that way is because of its elegant and ease of use. The template itself is quite complicated. We could wrap the series of row template calls in a single template, but that doesn't make the design any simpler.--Relyk ~ talk < 07:06, 15 November 2015 (UTC)

Just to throw in my 2 cents here... Being an object-oriented programmer, I can't help but think of modularity. According to the principles of modularity in object-oriented programming: we should have {{items}} that contain an id and description (for simplicities sake), then we would have {{collection item}}, which is a subclass of {{items}} that would contain id, description, and hint. This is true of database designs as well. An object should never contain more than what others need of it (you don't ever just create 1 big database table, you create many little tables). Therefore, I would have to agree that an item should not have a hint as a property of it. A {{collection item}} IS-A {{item}} with an extra property called hint.
Although, after saying all that, this isn't programming... this is a wiki. And I can't help but prefer that the hint be a property of an item. Hekela (talk) 04:08, 16 November 2015 (UTC)

Moving forward

I've created Template:Collection table row as the first step in getting this moving. I converted Astralaria I: The Device to use it, as proof of concept, and then edited Ponder the World to show how the item pages should be structured. In this case it was as simple as rephrasing the hint and making it obvious that "Ponder" is referring to the /ponder emote, something that people who've never played Mad King Says may not realize. I'm sure that in many other cases, the acquisition won't be so simple, making even more of a distinction between that and the hint.

The next step will be to remove the {collection} parameter from this infobox and decide how we want to use [[Property:Collects item]] (WIP name), which is set by the collection row template, to dynamically generate the list instead. I'm thinking that we may not want this collection list in the infobox anymore - some items, like Auric Sharpening Stone, are a part of many collections, and it tends to bloat the infobox. On the other hand, most items only belong to a single collection, making the ASS (unfortunate acronym...) an outlier.

Also, if the query is in the infobox, it would have to run on every single item page on the wiki, including the thousands of items that aren't part of any collection. On the other hand, the infobox already has a query to find the crafting disciplines that can use an item, so maybe it wouldn't be that bad.

In any case, it would be possible to create an analog of Template:Contained in that we can put in the article itself only on the pages that need it. I'm not sure which way is better - baked into the infobox or standalone template in article. —Dr Ishmael 19:45, 17 November 2015 (UTC)

Should we even keep the term "hint" in the table if it's explicitly listing the acquisition method? Hints are ambiguous, whereas our information is pretty clear.

How would the collection items display their collections, if we remove them from the infobox? Often times editors will (unnecessarily) add the collection to the notes section, unaware it's already listed in the infobox. Would this remedy that problem or cause more issues?

However, I'm all for making the infobox a tidier place - especially when you have items with nine collections... —Ventriloquist 21:25, 17 November 2015 (UTC)

I think you might be confused? The collection table has the hint; the item's page has an explicit acquisition. I'd be fine leaving the hints off of the wiki completely, but it seems like a lot of people think the hint is important enough that we need to display somewhere, thus the long argument above about where to put it.

If we put the collection on the page, that would almost certainly stop people adding it to the Notes, I'd think. —Dr Ishmael 22:06, 17 November 2015 (UTC)

Oh, the hints in the tab in your example confused me, didn't realize they were actual in-game hints. Other than that, the idea sounds good. —Ventriloquist 00:32, 18 November 2015 (UTC)

The way we did achievements wasn't designed for appending achievement properties to the achievement page. You need two queries, one for the achievement subobject and one for the collection list. Doing queries will also suck because you have to remember the collection items aren't located in the subobject and have to query if there's an achievement page defined every time. Given I don't see us doing much beyond listing the vendor cost, Alex will probably write some spaghetti code once someone asks. I'd still prefer storing in the subobject or finally creating a page for every achievement.--Relyk ~ talk < 05:14, 18 November 2015 (UTC)

Good start. Two thoughts. 1) the collection table row template gives the item name and hint, but what about the "in-game description"? Many (most) of the collection items don't just have hint text, but also some other in-game description. Please see Frostfang I: The Experimental Axe to see a collection table with each item's description and hint text for an example of what I mean. 2) Ponder the World is an interesting item, because it's one of the several "items" for these precursor collections that doesn't actually have an existing in-game item, and the only text on this "item" is the hint text. I believe the consensus above was to NOT display the hint text on the item pages. I would prefer to be consistent. Either we display the hint text on all the collection items, or not.

Oh, another thought. Rising Stars is a "collection item" for Astralia I, however, this "item" is not an item at all, but simply requires you to interact with an in-game world object (different from items such as Ponder the World, because Rising Stars existed in-game before these collections were released, and therefore already has a page). That page doesn't use the item_infobox. Do we handle these differently, or just leave em alone? Should we create a different page for [[Rising Stars (collection item)]]? ~Mervil 09:55, 18 November 2015 (UTC)

@Relyk: Bah... I give up, let's just make all collection stuff static.

@Mervil: Is it really useful to have it on the collection page? I think it's just more clutter, the same way that putting the hint on the item page is clutter. As for that Frostfang I table specifically, it's crap. Rowspans are crap - the entire point of a table is to have one row per "thing", and rowspans completely screw that up. Making the hint text a pale color just to match the in-game color is crap because it makes it hard to read, especially when the hints are all mashed up with the descriptions, which are black and easy to read. The hint is the more important bit of text there, so why make it harder to read than the non-important text?

@Mervil 2: If we can't get an item ID, then I say they're not items. Of course, that means someone will have to go and delete a crap-ton of pages that people have already created for these pseudo-items. —Dr Ishmael 14:56, 18 November 2015 (UTC)

(Reset indent)

My thoughts:

• Achievement pages:
  • Collection stuff should be static ingame (they generally don't get added to) so the achievement pages should be safe enough to have as static tables. We can enter the hints manually here
  • Hints should appear in black.
  • Descriptions aren't needed on collection pages. Fluff.
• Item pages:
  • Hints don't appear on items = they shouldn't be in the item infobox.
  • I don't see a problem with putting an acquisition section on each item page which may or may not be an exact transcription from the ingame hint (preferably our description should be better than ingame, otherwise what is the point in checking the wiki).
  • I like having a collection parameter in the item infobox, there aren't many items appearing in multiple collections.
• Collection "items" which aren't items:
  • These probably shouldn't be pages if we can't get IDs.
  • Accordingly I've updated {{collection table row}} to check for the page existing before using item icon - this should prevent people from reaching a page that shouldn't exist..

-Chieftain Alex 16:07, 18 November 2015 (UTC)

What about flavor text? We changed the color of flavor text to match in-game.

Are you suggesting that the pages for "items" such as Ponder the World should be removed all together? or just changed from item type? Just because they're not actual items doesn't mean they shouldn't have pages. They are after all still part of the collection. You can't have pages for 18 of the collection pieces and not have pages for the other 2. I think we should just keep them the way they are. We still need to figure out what to do with pages such as Rising Stars.~Mervil 18:48, 18 November 2015 (UTC)

Agreed, they should still be pages, absolutely. Just because they aren't items, doesn't mean they aren't in-game content. Side note, I greatly dislike flavour text; drives me nuts. Hekela (talk) 18:51, 18 November 2015 (UTC)

(Edit conflict) Flavor text color is still bright enough, and it's always against a plain white background, which means it's still readable. In your table, the background row-color and the borders make the hint coloring even less readable. To be blunt, your table is very poorly designed. —Dr Ishmael 18:57, 18 November 2015 (UTC)

Geeze. The table was not final. I had planned to continue making it better, but I scrapped the project after the discussion above. But thanks for your...critique. ~Mervil 19:15, 18 November 2015 (UTC)

For things that are part of collections but aren't items, maybe we can have a {{collection task}} or something to that effect? That way it's clear, it's not an item, but it is part of a collection. Hekela (talk) 19:25, 18 November 2015 (UTC)

Don't mind ishmael, he can get grumpy sometimes. "You can't have pages for 18 of the collection pieces and not have pages for the other 2." We definitely can. After all, that's exactly what we're doing with achievements. Just don't add a wikilink.

For pseudo-items like Ponder the World, there isn't a point in having pages. It's the same reason we don't create pages for the personal story items (I hope). The pages are just pretty much a description of what the pseudo-item is related to or acquistion. The item properties is superfluous information users don't care about.--Relyk ~ talk < 22:51, 19 November 2015 (UTC)

While I know quite a bit about how various things in the game actually work (e.g. there's no distinction between effects and skills, they're all contained in a single enumeration), I don't know anything about how collection achievements work. However, it seems very likely that the collection entries are a distinct type of "game thing" from everything else - they already cover two pre-existing "thing" types, items and skins. Thus, if they are indeed their own thing, then Relyk is right that we shouldn't treat them as if they were something else (i.e. items). —Dr Ishmael 02:19, 20 November 2015 (UTC)

Against creating not-really-items as well. The only thing I'm sad about is the icons they use. Could we integrate those into the table, without creating an item page? If we're going to be listing them, might as well, right? —Ventriloquist 15:57, 20 November 2015 (UTC)

Yes, just put the icon and name like normal. We don't have a generic icon template thanks to lolwiki, so we'd use {{icon}}.--Relyk ~ talk < 03:42, 21 November 2015 (UTC)

Just hard-code the file link. We don't have to use templates for everything. :P —Dr Ishmael 03:54, 21 November 2015 (UTC)

Tooltip structure: Automate "Double-click to consume", yes?

With the addition of Anguished Tear of Alba, a nourishment consumable with a non-blank description, the structure of tooltip is more "transparent" – transparent enough to recreate it via code. "Double-click to consume.\n" isn't actually part of the description that can be extracted via the API (see https://api.guildwars2.com/v2/items/70596).

1. Should we automate the addition of "Double-click to consume.\n" (found on all "consumables" on the wiki) via the infobox?
2. If we're not doing automatic inclusion of such text to replicate the in-game tooltip, how do we format Anguished Tear of Alba using {{{description}}} and {{{variables}}} when the nourishment text appears in between "Double-click to consume." and "Grants 10 agony resistance. Does not stack with other sources of agony resistance."?

The case where automation is not useful is probably Black Lion Trading Contract (tooltip looked like http://i.imgur.com/dDAJC.jpg), although I'm wondering what a more current tooltip would have looked like if anyone still has access to this historical item. --BryghtShadow (talk) 13:06, 12 November 2015 (UTC)

Another consumable that I overlooked with a similar structure is Experimental Mordrem Extraction Device (https://api.guildwars2.com/v2/items/67818). --BryghtShadow (talk) 14:20, 12 November 2015 (UTC)

I've always felt that it's pointless to include the "Double-click to consume" since, as you discovered, it's an automated part of the in-game tooltip rather than part of the item's actual description. It's also redundant when the item's type is already listed as "consumable." —Dr Ishmael 15:51, 12 November 2015 (UTC)

If we're excluding that blurb, then that makes formatting the consumables easier: {{{variables}}} (nourishment, etc) before {{{description}}}. --BryghtShadow (talk) 19:28, 12 November 2015 (UTC)

If we did it correctly, we would have specific parameters for gemstones and nourishment instead of {{{variables}}} so we don't have ambiguous formatting.--Relyk ~ talk < 12:54, 13 November 2015 (UTC)

Support for Consumable subtype: Service or Immediate

Could we add support for the type "Service" or "Immediate"? The API contains Immediate consumables, which have the localized tooltip type "Service" and have the blurb Takes effect immediately upon receipt.<br> before the actual description. Aetherium Production Boost (1,000 Influence) for example is "description":"Converts 1,000 influence to 10 minutes of boosted aetherium production." --BryghtShadow (talk) 05:06, 29 December 2015 (UTC)

Decoration processing time

When the item is a decoration, the processing (i.e. cooking) time after crafting it would be a useful stat to list. This varies by item. -- Dashface 08:57, 2 January 2016 (UTC)

Yeah, I already posted a simular question at User talk:Dr ishmael#Separate_infobox.3F. —MatHack (talk) 23:20, 2 January 2016 (UTC)

No need for a new infobox imo, but I don't know if these belong on Template:Recipe or on Template:Item infobox - I'm unfamiliar with scribing but the assembly time + resonance cost sounds like something better fitting in the recipe template. Schematic type is an item infobox thing I expect.

Not all parameters need to be semantically annotated either, i.e. where would you usefully display each bit of information in queries?

• Property:Has schematic type - 1 okay
• Property:Has assembly time - 0 meh
• Property:Has resonance cost - 0 meh

By all means add these 3 parameters though, make them display at the top under the

Afterwards, if you want me to add the parameters to the pages with an editing bot, and you have all the data in a table, then I can do that. -Chieftain Alex 00:13, 6 January 2016 (UTC)

API fields

I need to add some entries to this infobox for the API stuff, but I need some second opinions on them (since editing this infobox rebuilds the entire wiki and I'd like to not have to do it more times than necessary).

Skin unlocks

Does this look reasonable for showing skin unlocks? I'd prefer to use "Skin unlocked" but there's not enough room for it without it wrapping. Note that the skin infobox (at Princess Wand in this case) already uses "Unlocked", but that's on an infobox dedicated to the skin, not to the item that unlocks the skin.

{{Armor infobox}}, {{Weapon infobox}} and {{Back item infobox}} have the same problem. Here's the armor infobox: https://i.imgur.com/7MKolRp.png. (Any other templates I missed?)

Mini unlocks

Same deal as skin unlocks, but this is more annoying because minis can also be items, so we also have a "You have" row for them: https://i.imgur.com/TTqGiDA.png. I'm ok with this personally, but maybe it's confusing if you don't realize the item/wardrobe split. The problem here is that the "You have" row is added by {{Default item parameter}} so we'd have to pass extra params in to modify or hide it, and also that the JS for "You have" will end up pretty messy if it needs to handle minis too.

Recipe unlocks

I plan to add this for recipes: <span class="api-unlockedon api hide" data-recipeid="{{#ask:[[Learned from recipe sheet::{{PAGENAME}}]]|?Has recipe id#=|mainlabel=-}}">…</span> which should work ok even when the sheet has different variations (Recipe: Gift of Blades) or teaches multiple recipes (Box of Recipes: Tooth of Frostfang).

-- Dagger (talk) 04:04, 8 January 2016 (UTC)

The infobox shouldn't be handling this in the first place. Like poke said in the discussion, the information needs to be visually separated and that should all be handled in separate templates. I also don't think people need the information on every page they visit and hence make unnecessary API calls. That's why a form would be appropriate, just like we do we base ingredients. A similar solution is to add a "personal" tab at the top.--Relyk ~ talk < 04:37, 8 January 2016 (UTC)

Yeah, I disagree. This stuff is useful because it's right there on the page. All the data is cached after requesting anyway, so it's not like there's that many API calls. -- Dagger (talk) 10:47, 8 January 2016 (UTC)

Forms aren't applicable for this purpose.

Miniatures. Pass a parameter to {{Default item parameter}} to allow you to not process the "you have" line if a value is set. Example: {{Default item parameter|hideapi={{#ifeq:{{lc:{{{type|}}}}}|miniature|true|false}} }} on item infobox, with {{#ifeq: {{{hideapi|}}} | true | | <span class="api-unlockedon api hide" ... </span> }} on Template:Default item parameter. whatever, show both.

Recipes. Fine, but {{pagename}} needs to be {{PAGENAME}}. (Corrected in your line given above)

Have you got a sandbox copy of the infoboxes that you're working on? (I have some other questions which I'll ask here. -Chieftain Alex 14:03, 8 January 2016 (UTC)

The number of API calls is probably the part I least care about.::@Dagger, I don't know what part you are disagreeing with. Being right on the page doesn't mean it is useful or that we put it in the infobox template.

@Alex, why not?

There's literally no discussion about why we should add account information to the item infobox or why that's the best way to do it. If that's all this discussion is going to be, I won't bother and you guys can do whatever you want.--Relyk ~ talk < 15:34, 8 January 2016 (UTC)

The entire point of Dagger's API additions are that you can check your ingame stuff vs the wiki stuff at a glance. Going to another page (which the user will probably have to follow a link to, or find themselves) isn't very user-friendly either. Also, I don't think you've checked dagger's js code, but afaik it queries the account API a maximum of once every 12 hours for each of the endpoints (5 endpoints, so 10 calls a day). -Chieftain Alex 15:53, 8 January 2016 (UTC)

That's pretty much it. The cache time is actually set to 5 minutes at the moment for development, but that's just a config knob. -- Dagger (talk) 16:00, 8 January 2016 (UTC)

The number of API calls is probably the part I least care about. "The entire point of Dagger's API additions are that you can check your ingame stuff vs the wiki stuff at a glance". What does that have to do with the item infobox? Why can't people go to a page that does just that?

I didn't say anything about going to another page either, the form/link can simply reload the item page with the account information. Going to another page is actually user-friendly though because the account information isn't confused with the rest of the information about the item itself. It's a way to separate the information and avoid using caching as a solution. That also doesn't explain to me why we need to put the account information in the infobox.--Relyk ~ talk < 11:25, 10 January 2016 (UTC)

I'm not sure if it has to be in the main infobox, but having the info somewhere on each page would be really handy, especially for skin and dye unlocks. It's a "don't worry, you already have this" indicator. -- Dashface 15:56, 10 January 2016 (UTC)

This info is most useful when it's available, as Alex puts it, at a glance. That means it should be available directly on the item page, not hidden behind a link you have to manually invoke. And I put it in the infobox because that's where other info (like the TP price) goes.

I don't really see how there can be much confusion about where the info comes from. The fields stay hidden unless and until you set an API key. It should be fairly obvious that the info they show comes from using that key, especially if the page where you set the key explains what you'll get by setting one (which is obviously a thing it should do). -- Dagger (talk) 00:15, 11 January 2016 (UTC)

The problem with miniatures is that's also possible to have them as items too. But maybe it's okay to just hide the item counts anyway and ignore that?

I haven't made any sandbox copies. I tend to rely on DOM Inspector to make local mockups (and lots of time with the preview button to make sure the edits I make are sane). How do you normally make mockups of these things -- a full copy of the template, or just recreating the markup? Copying the template seems like it's going to leak SMW properties everywhere. -- Dagger (talk) 16:00, 8 January 2016 (UTC)

You could display miniatures in the inventory if you wanted to, I guess there is no harm in displaying it too...

I usually make a full copy of the template in my userspace, tinker with it (I'm a terrible editor so I make loads of mistakes), test it, then tag it for deletion when you're done with it. -Chieftain Alex 16:41, 8 January 2016 (UTC)

Alright, let's do it. I can always move them up in JS locally if it bugs me so much. -- Dagger (talk) 23:43, 27 January 2016 (UTC)

Hints Again

So above, I think we all agreed that (at the very least) item pages shouldn't display the hint (and some suggested that infoboxes shouldn't even have a hint property). However, not only do infoboxes have the hint property, but they are also being displayed. Can someone hide the hint, at the very least? Hekela (talk) 22:27, 3 June 2016 (UTC)

Should bound be specified for service items? Tooltip vs API

I've coded the service type to be tradeable=no by default, so that it doesn't look up TP prices. The API has flags like AccountBound which are never seen in the tooltip. Should bound be specified on the pages? e.g. https://api.guildwars2.com/v2/items/68565 = ["AccountBound","NoSalvage","NoSell","Unique","AccountBindOnUse"] --BryghtShadow (talk) 08:41, 13 September 2016 (UTC)

Schematics are trophies

Schematics are trophies. They are products of crafting, not ingredients. The recipes on the wiki with schematics as ingredients should be corrected to guild upgrades. e.g. https://api.guildwars2.com/v2/recipes/11563 --BryghtShadow (talk) 10:20, 15 September 2016 (UTC)

Some schematics are Crafting Materials. e.g. https://api.guildwars2.com/v2/items/70982. How should the trophy schematics be handled? --BryghtShadow (talk) 10:27, 15 September 2016 (UTC)

Trophy schematics:

• Schematic: Airship Defense
• Schematic: Armored Dolyaks
• Schematic: Assault Roller
• Schematic: Centaur Banner
• Schematic: Chilling Fog
• Schematic: Cloaking Waters
• Schematic: Dragon Banner
• Schematic: Emergency Waypoint
• Schematic: Gate Turrets
• Schematic: Hardened Gates
• Schematic: Hardened Siege
• Schematic: Invulnerable Dolyaks
• Schematic: Invulnerable Fortifications
• Schematic: Iron Guards
• Schematic: Minor Supply Drop
• Schematic: Packed Dolyaks
• Schematic: Presence of the Keep
• Schematic: Sabotage Depot
• Schematic: Speedy Dolyaks
• Schematic: Turtle Banner
• Schematic: Watchtower
• Vault Transport

Crafting Material schematics:

• Guild Banquet Schematic
• Guild Experience Banner Schematic
• Guild Gathering and Swiftness Banner Schematic
• Guild Gathering Boost Banner Schematic
• Guild Gold and Magic Find Banner Schematic
• Guild Gold Gain Banner Schematic
• Guild Heroes Banner Schematic
• Guild Karma and Experience Banner Schematic
• Guild Karma Banner Schematic
• Guild Magic Find Banner Schematic
• Guild Road Marker Schematic
• Guild World Event Schematic

--BryghtShadow (talk) 10:42, 15 September 2016 (UTC)

Preview

Should we have a 'preview' parameter to indicate if an container can be previewed? Now some containers have a preview, but there's a few more that contain skins that also have a preview with the skin even though the item itself is a container for a skin. MithTalk 15:35, 2 November 2016 (UTC)

Hmm, late on this but that sounds like a nice idea, not sure how it would work though. --Txon Atana - (talk) 02:38, 26 July 2017 (UTC)

Adding the API

Is there any particular reason why we shouldn't add/haven't added the link to the API for items like we do for skills & skins? Seems like it would be very handy thing to have here. - Do_odleplex 04:49, 28 June 2017 (UTC)

Great idea Doodle, I look forward to you adding it!--Relyk ~ talk < 05:19, 28 June 2017 (UTC)

Changes to Storage tabs classification

Ok, after trying to edit an item I followed links and reached this template, I thought about updating stuff but then I saw it would cascade to a lot of changes around. Then, before I would mess something I'm bringing this up. How would the wiki reflect the changes to the new Storage tabs classification? As stated in patch notes: "The Common, Fine, and Rare Materials collections have been renamed to Basic, Intermediate, and Advanced, respectively.". The Crafting material article would be affected, with the sections being changed to reflect that change, however, if that article is changed this template can become broken.

Additionally, out of curiosity, what's the reason for having two "rarity" fields (one for the "item"(?) another for crafting material)? I just can't see how, let's say, an item showed as Rare in inventory would have a Fine material rarity. The fields "material type" and "material storage" seems redundant to me (unless it's used in some semantic though, the "material storage" field doesn't seem to generate any visible info in the infobox). --Txon Atana - (talk) 02:35, 26 July 2017 (UTC)

material type is due to the crafting infobox originally being separate from the item infobox. We identify a crafting material by type = crafting material and then provide information related to materials such as the actual type, crafting tier, crafting disciplines, and material storage categorization. The wiki crafting type is a misnomer because it may or may not match the canonical type, which tends to be a generic CraftingMaterial type.

The reason is we use the type parameter for wiki categorization, which provides much more granular and useful organization and categorization. We use the material storage categorization as the material type because it's an existing crafting type rather than a wiki-level type. Although that has some drawbacks since we don't, say, group all the ores together as a material type. We can probably pull out the material types into material storage to avoid redundancy, which would be much more work.

The changes affect the material storage categorization only, so it would be a 1-to-1 change for existing types. If we wanted to update it properly, we could pull out the material storage categorization completely from the material type i.e. set both parameters as the same and update the material type to whatever we want later.--Relyk ~ talk < 03:18, 26 July 2017 (UTC)

I got it, thanks. Yeah, since I didn't see any "Material Storage" entry in the generated infobox I guessed it would be used for some internal classification. Well, I don't know how it could be done or how much work would involve but I feel some areas like mainly the Crafting material article needs to reflect the change. But apparently changing only that article might break this template somehow, as it links to sections to that article. --Txon Atana - (talk) 03:30, 26 July 2017 (UTC)

Consumable Type

I’d like to discuss if it’s necessary to have a consumable type parameter instead of addition item types. If we compare the API item types to the parameters for this infobox we can see that many of the consumable variants have their own type already. Consumable: Booze is alcohol, Consumable: Food is just food , Consumable:Immediate is service. I think we need to decide on which style to keep to avoid labeling conflicts in the future. J.Tesla (talk) 14:50, 7 October 2017 (UTC)

I would say I think it a reasonable idea. If we could get it in sync with the API somehow it might be easier to classify stuff. However, I can't opine much since I'm not much familiar with the ways the API shows info, but more and distinct info in the wiki sounds good. --Txon Atana - (talk) 02:54, 9 October 2017 (UTC)

Removing "mount skin = Category:Mount skins"

There is redundancy in the mount skins categories. The Banded Mystic skin, for example, is within the categories "Mount skins" and "Jackal skins", but that's redundant - all Jackal skins are mount skins. The "Jackal skins" category is due to manual input, but the "Mount skins" category comes from this infobox. I suggest removing the automatic "Mount skins" categorization from this infobox, so those articles are categorized by the type of mount they're a skin of. For example, the jackal skins would be within the "Jackal skins" category, which would be within the "Mount skins" category. Erasculio 00:39, 18 November 2017 (UTC)

I've added the option to include "mount type = <jackal/griffon/whatever>" to the infobox to auto categorise it properly. Example If no mount type is set then it defaults to the "Mount skin" category. J.Tesla (talk) 12:46, 18 November 2017 (UTC)

Nice! Thanks. Erasculio 12:53, 18 November 2017 (UTC)

Why is there no way to mark an item(resource) that can go into material storage?

Or is there, and it's just not used? (Or maybe I missed it?) It is something that IMO is sorely missing, maybe there is a pattern, but I don't see it, so I'm constantly overwhelmed by the amount of information (and crafting resources) in the game/wiki.

Point in case: Pile_of_Pumpkin_Pie_Spice and Pile_of_Cinnamon_and_Sugar . Can you tell which goes into storage?--Cyberman 16:38, 4 February 2018 (UTC)

Well we already silently store whether it can be stored or not. Added. -Chieftain Alex 18:08, 4 February 2018 (UTC)

Great! Thank you, that's perfect.--Cyberman 16:39, 5 February 2018 (UTC)

Linking to the item a recipe sheet makes

I think the infobox should display what item the recipe sheet creates. We already have that information from the API and Property: Learned from recipe sheet, and just need to add it to the infobox. We currently only show this information as prose which is isn't a very good method imo. --BuffsEverywhere (talk) 21:00, 17 June 2021 (UTC)

I assume that you want to do add this infobox line automatically by a query. While in probably 90% (caveat, I assumed a percentage) of the cases this will be fine, since the recipe unlocks one item, the remaining 10% will cause some trouble. These are recipes that unlocks several items to craft, extremely blowing up the infobox. For example:

• Recipe: Sigil of Serpent Slaying unlocks minor, major and superior sigil, that's quite common, kinda hard to fit these three items nicely into the infobox.
• Cymbel's Baby Book Notes unlocks 13 (!) recipes, sure this is a rare exception but nevertheless an implementation have to take this into account.

Not sure how to solve the 10%. --Tolkyria (talk) 23:11, 17 June 2021 (UTC)

We could use Alex's idea for showing default dyes (see here) and only show item icons if there are more than 2(?) unlocks. --BuffsEverywhere (talk) 00:31, 18 June 2021 (UTC)

Sure it's the worst case, but 13 icons placed next to each other, that's not wiki user friendly at all, just cluttering the infobox. Also please don't mix up different contexts: In the skin infobox is clear what the dye icons are (if understood once), this are always dyes which are primarly seen as color and not read as text. In the item infobox, the unlocked crafted item can be anything: crafting components, weapons, armor, gizmo, consumable, etc...; having to interpret it simply by the icon without any supporting text is kinda hard, again not user friendly.

Other alternatives:

• Display e.g. up to three items, but three runes/sigils may take up to 9 lines. Still too much in my opinion.
• Display one item, make the rest expandable. Again, when expanded the infobox is way too long.
• Display one item, otherwise state Several - see below. Well, here we would need to identify those pages and make sure that the unlocked crafted items are actually listed.
• Display one item, otherwise ignore. Kinda inconsistent, making the wiki user ask why it's used here but not there.
• Display all items but allow to deactivate it by hand. Still, those pages needs to be identified, also inconvenient for wiki editors being forced to deactivate something.

To be honest, none of these options sounds appealing to me. Sure, for the 90% one recipe <-> one item is sounds like a great idea, but I think the remaining 10% makes it kinda hard to implement it in general.

What about an own section below Acquisition using an own template:

== Acquisition ==
<!-- acquisition -->

== Teaches recipes ==
{{Teaches recipe}}

Not sure about the name though (Unlocks, Unlocks crafted items, etc...), but the template will state: Teaches the following recipes: (Allows to craft the following items, etc...) and then lists the unlocked recipes. There it can be nicely presented by taking up as much space as needed. --Tolkyria (talk) 08:35, 18 June 2021 (UTC)

Brilliant, I like the idea of giving it its own section. But it may make the intro text above acquisition a bit redundant (eg Recipe: Corrupted Jar). Should the intro text be deleted? Or maybe just turn the intro text into a template? Not sure. --BuffsEverywhere (talk) 09:03, 18 June 2021 (UTC)

Yes, the redundancy might be a problem for others (see the classic r/Guildwars2: What a descriptive wiki), but honestly I don't mind duplicate mentions. For me the intro text gives a quick summary that may already include some crucial information (with a personal touch depending on who created it, so I wouldn't add a template there) while the following sections (e.g. acquisition, the new recipe section, etc...) are standardised with templates to include the full information consistently.

It's a little bit more work to set up and add a new template, but once implemented it's a nice and also consistent addition to the wiki. --Tolkyria (talk) 21:32, 20 June 2021 (UTC)

I am in favor of implementing the idea. How much could be automated with a bot task? —Kvothe (talk) 09:19, 15 August 2021 (UTC)

(Reset indent) I created Template: Teaches recipe based off of Tolkyria's idea. I'm open to suggestions for the template name and text. --BuffsEverywhere (talk) 09:58, 15 August 2021 (UTC)

For the text i would suggest "Unlocks the ability to craft:" or we could just list the recipes under the section heading "Teaches recipe(s)". I would place it after the "Contents" section of Guild Wars 2 Wiki:Item formatting. I am not sure if we want to have the distiction of singular and plural section headings. —Kvothe (talk) 14:01, 15 August 2021 (UTC)

Did a small test and changed pages in Category:Precursor recipe boxes, Ahamid recipes and Recipe: 20-Slot Equipment Pact Box. The last recipe lists the same item 3 times since the item page contains 3 different recipes. And Perfected Sword had the issue that the name parameter in the {{recipe}} was set to have the suffix (Exotic). Other than some presumably small fixes - a bot should be able to add the section. —Kvothe (talk) 10:24, 21 August 2021 (UTC)

My entry for text would be "Unlocks the crafting recipes for the following items:".

As for the bot task; a rough search (on potentially outdated data) yields about 3512 pages with an item infobox with type set to recipe sheet.

These total the following sections (with pages included where the section count is less than (or equal to, technically, while not applicable here) a dozen):

• Achievement x1
  1. Recipe: Banner of the Dauntless Commander
• Achievements x2
  1. Recipe: Tengu Blade
  2. Recipe: Prismatium Ingot
• Acquisition x3511
• Contained in x221
• Gathered from x61
• Historical x11
  1. Recipe: Plate of Spicy Herbed Chicken
  2. Recipe: Bowl of Refugee's Beet Soup
  3. Recipe: Mushroom Loaf
  4. Recipe: Plate of Frostgorge Clams
  5. Recipe: Spicy Marinated Mushroom
  6. Recipe: Bowl of Zesty Turnip Soup
  7. Recipe: Carrot Soufflé
  8. Recipe: Bowl of Garlic Kale Sautee
  9. Recipe: Bowl of Sweet and Spicy Butternut Squash Soup
  10. Recipe: Potent Superior Sharpening Stones
  11. Recipe: Ring of Blood
• Notes x430
• Other x2
  1. Recipe: Sunset Jewel
  2. Recipe: Zehtuka's Harrier's Inscription
• Recipe x5
  1. Recipe: Gift of Spiders
  2. Recipe: Gift of the Moon
  3. Recipe: Superior Sigil of the Night
  4. Recipe: Major Sigil of the Night
  5. Recipe: Superior Rune of the Mad King
• Related achievements x1
  1. Recipe: Banner of the Commander
• Rewarded by x2
  1. Recipe: Brandspark Jewel
  2. Recipe: Sunset Amulet
• See also x30
• Sold by x203
• Teaches recipe x11
  1. Recipe: 10 Slot Ogre Bag
  2. Recipe: Ahamid's Soldier Insignia
  3. Recipe: Ahamid's Breastplate
  4. Recipe: Ahamid's Greaves
  5. Recipe: Ahamid's Warfists
  6. Recipe: Ahamid's Visor
  7. Recipe: Ahamid's Pauldrons
  8. Recipe: Ahamid's Tassets
  9. Recipe: Ahamid's Visage
  10. Recipe: Ahamid's Leather Breather
  11. Recipe: Ahamid's Cloth Breather
• Teaches recipes x28
• Trivia x1
  1. Recipe: Invar
• Usage x2
  1. Recipe: Toxic Focusing Crystal
  2. Recipe: Toxic Sharpening Stone

If you let me know on Guild Wars 2 Wiki:Bots in which way to add it exactly once it's been hashed out i can see if i can do it. (Adding the section should generally be possible. Small fixes i'm not sure about.) Be aware though that if the wiki's still so slow as to only process ~10 bot edits per minute by then it would take a minimum of ~5 hours, 51 minutes and 12 seconds to perform all edits. Nightsky (talk) 16:26, 21 August 2021 (UTC)

Oh, if the text is going to say "unlocks", would it be more natural to change the section heading and template name to "Unlocks recipes"? --BuffsEverywhere (talk) 19:24, 21 August 2021 (UTC)

At least i'd say so. That is if you change it to my suggestion; which you don't have to if you don't want to. Nightsky (talk) 23:38, 21 August 2021 (UTC)

Eliminated some ouliers and corrected formatting (updated the collapsible section). Since the section will not be that common for items in general I would place it after the "Salvage results" section of Guild Wars 2 Wiki:Item formatting. I am in favor of keeping "Teaches recipe(s)" as the section heading, but for the template I think the singular would be more consistent. While unlocks is more general there are other uses already, so I would like to keep the distinction that "teaches" provides. I was thinking of removing "Unlocks the ability to craft: " altogether.—Kvothe (talk) 12:02, 3 September 2021 (UTC)

Moved the template to singular. Updated all occurences. Added a bot request. —Kvothe (talk) 21:52, 3 September 2021 (UTC)

Undone changes to the collapsible section as less than or equal to a dozen wouldn't apply anymore and as it doesn't fully reflect all changes that happened since then and so wasn't current even after the updates to it either.

Here's a current list of the sections on the affected now 3513 item pages with type set to recipe sheet with pages listed for a section if 16 or less:

• Achievements x3
  1. Recipe: Banner of the Dauntless Commander
  2. Recipe: Tengu Blade
  3. Recipe: Prismatium Ingot
• Acquisition x3512
• Contained in x221
• Gathered from x61
• Historical x11
  1. Recipe: Plate of Spicy Herbed Chicken
  2. Recipe: Bowl of Refugee's Beet Soup
  3. Recipe: Mushroom Loaf
  4. Recipe: Plate of Frostgorge Clams
  5. Recipe: Spicy Marinated Mushroom
  6. Recipe: Bowl of Zesty Turnip Soup
  7. Recipe: Carrot Soufflé
  8. Recipe: Bowl of Garlic Kale Sautee
  9. Recipe: Bowl of Sweet and Spicy Butternut Squash Soup
  10. Recipe: Potent Superior Sharpening Stones
  11. Recipe: Ring of Blood
• Notes x430
• Other x2
  1. Recipe: Sunset Jewel
  2. Recipe: Zehtuka's Harrier's Inscription
• Recipe x5
  1. Recipe: Gift of Spiders
  2. Recipe: Gift of the Moon
  3. Recipe: Superior Sigil of the Night
  4. Recipe: Major Sigil of the Night
  5. Recipe: Superior Rune of the Mad King
• Related achievements x1
  1. Recipe: Banner of the Commander
• Rewarded by x2
  1. Recipe: Brandspark Jewel
  2. Recipe: Sunset Amulet
• See also x30
• Sold by x203
• Teaches recipe x16
  1. Recipe: 10 Slot Ogre Bag
  2. Recipe: Toxic Focusing Crystal
  3. Recipe: Toxic Sharpening Stone
  4. Recipe: Ahamid's Soldier Insignia
  5. Recipe: Krait Tuning Crystal
  6. Recipe: Hylek Maintenance Oil
  7. Recipe: Ahamid's Breastplate
  8. Recipe: Ahamid's Greaves
  9. Recipe: Ahamid's Warfists
  10. Recipe: Ahamid's Visor
  11. Recipe: Ahamid's Pauldrons
  12. Recipe: Ahamid's Tassets
  13. Recipe: Ahamid's Visage
  14. Recipe: Ahamid's Leather Breather
  15. Recipe: Ahamid's Cloth Breather
  16. Recipe: Fried Banana Chips
• Teaches recipes x28
• Trivia x2
  1. Recipe: Invar
  2. Recipe: Fried Banana Chips

Nightsky (talk) 17:15, 4 September 2021 (UTC)

Gallery1 for armor skins

Any reason why we do not show gallery1 for "skin type = armor skin" on default if it exists? —Kvothe (talk) 16:24, 22 August 2021 (UTC)

This edit removed it in 2016 but I'm not quite sure what Alex means by it so I'm reenabling it :P --BuffsEverywhere (talk) 08:17, 23 August 2021 (UTC)

I do. With it working, it created/creates a lot of infoboxes to require images where they weren't needed before, especially if say they have a gallery somewhere else on the page(Cat-Ear Hood Skin) or were full armor pieces(Blossoming Mist Shard armor) where we don't do individual shots. So I'm with Alex, not a good idea, needs to be removed. - Do_odleplex 17:47, 23 August 2021 (UTC)

Oh yeah, that makes sense. I've changed it back. The gallery can still be displayed with the gallery parameters so it is fine. --BuffsEverywhere (talk) 18:18, 23 August 2021 (UTC)

Thank you! =) - Do_odleplex 18:22, 23 August 2021 (UTC)

What I initially meant was to only show existing images not adding red links to a million armor pages. —Kvothe (talk) 11:18, 3 September 2021 (UTC)

Skin template code

This template currently uses two different skin separators in its code. First, the intended "," (documented) used in:

[..]
 | armor skin
 | weapon skin = {{#if: {{{skin|}}} | {{#if: <!-- checking if there are multiple skins that share the same canonical name: if yes, then add weight class suffix -->
   {{#if: {{#pos: {{{skin|}}}|,}}
    | {{#vardefineecho: skin0|{{#ifexist:{{#vardefineecho: skin|{{#explode:{{{skin|}}}|,|0}}}} (skin)|{{#var:skin}} (skin)|{{#var:skin}}}}}}
      {{#vardefineecho: skin1|{{#ifexist:{{#vardefineecho: skin|{{#explode:{{{skin|}}}|,|1}}}} (skin)|{{#var:skin}} (skin)|{{#var:skin}}}}}}
      {{#vardefine: show weight|{{#ifeq: {{#show: {{#var: skin0}}|?Has canonical name}} | {{#show: {{#var: skin1}} |?Has canonical name}}|true}}}}
   }} }}
;[[Skin]]
:{{#arraymap: {{{skin}}} |,|@@@|{{#ifexist:@@@ (skin)
 | {{cname|@@@ (skin)}}{{#set:Has skin=@@@ (skin)}} {{#if: {{#var: show weight}}|{{#if: {{#vardefineecho: weight|{{lc:{{#show: @@@ (skin)|?Has skin weight class}}}}}}|<small>({{#var: weight}})</small>}}}}
 | {{cname|@@@}}{{#set:Has skin=@@@}} {{#if: {{#var: show weight}}|{{#if: {{#vardefineecho: weight|{{lc:{{#show: @@@|?Has skin weight class}}}}}}|<small>({{#var: weight}})</small>}}}}
}}|<br>}}
}}
[..]

and second, the separator ";" (not documented, probably copied from an equipment infobox) used in:

 | skin id    = {{#if: {{{skin|}}} | {{#arraymap: {{{skin|}}} |;|@@@| {{#vardefine:skinName|{{#ifexist:@@@ (skin)|@@@ (skin)|@@@}}}}{{#show:{{#var:skinName}}|?Has game id#|limit=1|default=}} |,}} }}

As a result, if multiple skins are set then the skin game links are not displayed, for example: Heavy Zephyrite Lightning Helm Skin.

Furthermore, the #ifexist check, unnecessarily creates hundreds of nonexisting pages in Special:WantedPages if the page {{{skin}}} (skin) does not exists; thus why initially the template ifexist was used which suppresses an WantedPages entry (see also Category talk:Pages using DynamicPageList3 parser function, trying to get rid of dpl functions).

I know I'm repeating myself, but my credo holds also here: "Shortcuts never pay off" and we pretty much reached this point here. To be honest in theory nothing speaks against getting rid of the ifexists check (in whatever form) and specifying the correct skin name exactly. Well, in practise there's a big if: if it was done this way from the beginning and not after 9 years, now it's a tedious work to go through it and add the missing (skin) suffix if necessary. But - and this is a big but - if it is done, it will definitely pay off.

So summarizing my suggested changes:

1. Identify the pages where multiple skins used and replace the separator "," with ";" to match the equipment infoboxes and adjust this template.
2. Identify the pages where the (skin) suffix is missing for the parameter skin and add it there, remove the ifexists check (in any form) from this template. Please note that the this suggestion should also be implemented to the four other equipment infoboxes (armor, weapon, trinket, back item).

I know, an extremely tedious task which I can't pull through alone, maybe we can bot it somehow, but at least I want to start a discussion about it. --Tolkyria (talk) 15:43, 21 September 2021 (UTC)

I've got a day off tomorrow, that might be a good time for me to take a swing at part 1 to update from commas to semi-colons. -Chieftain Alex 17:31, 21 September 2021 (UTC)

Regarding part 2: I have checked the categories Armor skin consumables, Weapon skin consumables and Gathering tools (including subcategories) and added the suffix (skin) to the skin parameter if the skin parameter on its own would not be a skin page (i.e. the ifexists <skin parameter> (skin) case). Unless I have missed a category, all skin parameters are exactly set to a skin and need no ifexists check anymore.

Thus, I suggest to remove the ifexist skin check and allow exact skin values only. What will happen if I missed one? We can use the query {{#ask: [[Has skin::+]][[Has skin.Has context::!Skin]]}} to check stored skin values that are not a skin page; however this would require an infobox which sets the context, pages without context would still be undetected. --Tolkyria (talk) 08:26, 28 September 2021 (UTC)

Go ahead and remove it. -Chieftain Alex 08:36, 28 September 2021 (UTC)

Done. --Tolkyria (talk) 09:05, 28 September 2021 (UTC)

As a follow up to this (Special:Diff/2340708), I have also removed the same ifexists check from Template:Armor infobox and Template:Weapon infobox. --BuffsEverywhere (talk) 11:08, 25 September 2022 (UTC)

Unfortunately, some weapon pages are linking to the item pages rather than the skin pages. E.g. Iron Shield is bad, while Entropy is correct.

Given how the wiki seems to be struggling to refactor many weapon pages right now, I'm hesitant to suggest making another change to a widely used template so quickly. Greener (talk) 13:49, 25 September 2022 (UTC)

"I have checked the categories Armor skin consumables, Weapon skin consumables and Gathering tools (including subcategories) and added the suffix (skin) to the skin parameter if the skin parameter on its own would not be a skin page (i.e. the ifexists <skin parameter> (skin) case). Unless I have missed a category, all skin parameters are exactly set to a skin and need no ifexists check anymore. " Issue is this didn't happen for weapons and armor, so all pages that have not been updated like this will be broken. Personally I would be for first reverting this change, adding the (skin) where applicable, then applying this change only after all is done. DJemba (talk) 14:04, 25 September 2022 (UTC)

If its broken, revert it, don't worry about the job queue. -Chieftain Alex 15:45, 25 September 2022 (UTC)

Don't revert it, I'll fix the skin links. --BuffsEverywhere (talk) 18:45, 25 September 2022 (UTC)

Done, 22 pages edited. --BuffsEverywhere (talk) 18:53, 25 September 2022 (UTC)

Thanks for grabbing those. The problem seems to affect pages which have multiple variants sitting outside the main infobox (e.g. Kodan Warhorn for weapons and Mind of Koda for armour). I haven't notice the issue with skin links on the more normal weapon and armour pages, so far. Greener (talk) 19:43, 25 September 2022 (UTC)

Huh, I guess the wiki still wasn't done updating those infoboxes yet when I checked earlier. The following pages need to be fixed: Invader's Heavy Boots, Invader's Heavy Chestguard, Invader's Heavy Gloves, Invader's Heavy Helm, Invader's Heavy Leggings, Invader's Heavy Shoulders, Invader's Light Boots, Invader's Light Chestguard, Invader's Light Gloves, Invader's Light Helm, Invader's Light Leggings, Invader's Light Shoulders, Invader's Medium Boots, Invader's Medium Chestguard, Invader's Medium Gloves, Invader's Medium Helm, Invader's Medium Leggings, Invader's Medium Shoulders --BuffsEverywhere (talk) 19:59, 25 September 2022 (UTC)

Decoration descriptions

Currently this template adds the intro "Double-click to consume." to all decorations. However there are some decorations that don't have this intro ingame, such as Racetrack Curved Ramp, A Day in Kryta, Basic Fountain. I suspect it's because these are purchased from vendors and they have the "Gizmo" type in the api. --BuffsEverywhere (talk) 11:03, 10 November 2021 (UTC)

Fish item type

Putting 'Fish' in the item type should redirect to a separate page, let's say Fish (consumable), instead the creature type. Unlike containers, they don't always have the line "Double click to produce materials", as there's fish that give karma and fish with other effects, so there has to be a way to deal with that case too. Mith🌟Talk 02:43, 5 March 2022 (UTC)

Collapsing collection

Can someone please adapt the logic used to collapse the api on Template:Event infobox for the collection parameter. This should render infoboxes like Obsidian Shard more useful. —Kvothe (talk) 21:12, 7 February 2024 (UTC)

Yes please, currently those infoboxes are basically unusable due to the length. ~Sime 17:15, 10 February 2024 (UTC)

Nominate Sime and Kvothe to fix it. -Chieftain Alex 17:29, 10 February 2024 (UTC)

Done. Managed to break everything in the process. -Chieftain Alex 18:23, 10 February 2024 (UTC)

Thanks <3 Asuaka (talk) 18:31, 10 February 2024 (UTC)

Thank you! —Kvothe (talk) 20:09, 10 February 2024 (UTC)

Thanks. ~Sime 01:25, 11 February 2024 (UTC)