Template talk:Contains

Item IDs

Would it be possible to adapt this template to use item ids? That way we could use specific IDs for items that share names. MithTalk 23:19, 21 September 2014 (UTC)

Adding a quantity parameter

It would be nice to be able to pass the quantity to this template so {{contained in}} can show it as well. --BuffsEverywhere (talk) 04:20, 24 January 2020 (UTC)

It's clear how to store two corresponding properties such that they can be asked and received together: subobjects. However, there are some unclear points for me:

1. Property — there are currently several ways how the quantity is displayed:
   • empty, interpreted as (1),
   • single value, e.g. (2),
   • list, e.g. (1, 2, 5, 10), or
   • range, e.g. (3-8).

   We would have to define a property that is able to store all these different types of quantity representation. The following two property are available:

   • Property type "number": can easily store any list of numbers, can also sort the numbers numerically! However, it cannot store the range.
   • Property type "string": can store all of the displayed ways, however can only sort alphabetically, i.e. (1, 2, 5, 10) will be sorted as (1, 10, 2, 5).

2. Pages — the template contains is used ~22000 times on ~2700 pages and the template contained in is used on ~11500 pages. This will take some time to update, e.g. 7 days while updating 400 pages per day, this will lead me to the next point
3. Procedure — develop a procedure that maintains the functionality of contains and contained in during the update process.
4. Format — while the template contains is straight forward, how should the template contained in represent the quantity? Is it clear by context what these numbers stand for? Namely, that it is the contained quantity and not how many bags are needed to get 1, whatever... Will this format clash with the suffix (historical) and (discontinued)? E.g.
   • Big Loot Bag (1, 2, 3)
   • Small Loot Bag
   • Old Loot Bag (2, 5) (historical)
5. Templates — are there any other templates that uses the property "Contains item" and therefore must be adjusted?

--Tolkyria (talk) 15:51, 24 January 2020 (UTC)

Sorry for not following up on this for so long. To answer your points,

1. I believe using the text property type like Property: Has rewarded item quantity would be the best to be consistent. I think we don't need to worry about sorting the given quantities as they can be manually sorted at the input if necessary.

2-3. We could keep the current Property:Contains item active while adding a new subobject with new properties to this template. After the new subobjects are created, we can make edits to contained in and the other templates to use the subobject.

4. Your example here looks good to me.

5. Is this all of them?

I wonder if it's possible to bot edit to replace all of the current quantity suffixes with this new quantity parameter.

Also it was just brought up on Discord to add a chance parameter to this template, which will be simple to add once we've converted this template to create subobjects.

--BuffsEverywhere (talk) 07:27, 4 February 2022 (UTC)

Not sure how I came up with the numbers above or if they increased that much in the last the two years, but currently based on parameter check the template contains is used ~38500 times on ~3150 pages.

So in the end it comes to these three questions:

• Are we able to turn ~38500 quantity suffix (e.g. {{contains|Mithril Ore}} (1-3)) into a quanity paramter qty (e.g. {{contains|Mithril Ore|qty=1-3}})?
• Do we really want ~38500 new subobjects that stores 4+ properties?
• Last but not least, leaving technical details aside, basically the whole idea of this discussion: Do we want to display the quanity in the query template contained in?

Assuming we answer these questions with yes, then I would suggest to the following plan.

1. Add the quanity parameter qty and move the suffix.

2. At this point the required property types should be clear (text property to store the quanitity, as you said), however we have to decide on the property names. Currently we (probably my fault) have some unnecessary overspecialization in these property names, using different property names for each acquisition type. The best would be to take this opportunity and clean up these by merging them into more universal names, probably use the term "rewarded".

	Currently used property names			New unified property name
Template	Vendor table row	Drops table row	Rewards item
quantity	Has item quantity (number)	Has dropped item quantity (text)	Has rewarded item quantity (text)	Has <???> item quantity (text)
chance	-	Has dropped item chance	Has rewarded item chance	Has <???> item chance
id (subobject)	-	Has dropped item id	Has rewarded item id	Has <???> item id
collection	Is purchasable during collection	Is dropped during collection	-	Is available during collection
event	-	Is dropped during event	-	Is available during event

3. Identify the pages that need to be changed and list them. Simply looking at WhatLinksHere is not enough. For example check this search.

• There are queries with property printouts ?Contains item (used in mainspace and templatespace). What's the new property prinout term to get the page and not the subobject? Obviously we would have to use the property chain ?-Contained in.Contains item to get the related page. However, will this trigger the duplicate property chain bug (that omits duplicate properties after the first duplicate one, see our wiki bug page)?
• There are queries searching for Contains item::<page> or the inverse -Contains item::<page>. How does these query strings translate from a page into a subobject property?

4. Develop a solution for all the identified pages and perform the switch.

Note that this transaction is way harder than rewards item (which was simply designed from scratch) and drops table row (which already had the complete infrastructure), in fact it should be doable but definitely requires much more work. --Tolkyria (talk) 10:28, 4 February 2022 (UTC)

I do not want to meddle into this technical discussion since I barely understand it, but since I am the one who proposed the idea on discord I want to add some things: the idea for this came when someone had asked where does x drops, and although we list several containers, without opening every single page they would have no idea if the drop is guaranteed or not, so this idea is to fix that. I know it would be a lot of pages to change and fix and ofc I am willing to help with that (no idea how far would botting be helpful). Aslo as I said I am leaving the technical stuff to people who understand it, but I think at least 3 different "values" for the drop chance should be displayed, based on the rewarded template:

"random chance" - when the drop is random, "guaranteed drop" - when you are 100% guaranteed to get the item, and "possible choice" - when you can pick from multiple options.

Thanks Buffs btw for starting the discussion while I was gone, the sooner we can solve it the better. EDIT: Ofc if this can be just solved with the quantity parameter then sure, just that this was my original idea. ~Sime 15:20, 4 February 2022 (UTC)

Don't worry, right now this is more a brain-storming than discussing explicit technical methods (which should be probably split into own discussion subsections to keep the overview), so all opinions are welcome. It's definitely better to think through several ideas/requests better sooner than later.

Your described drop chance is either step 1b: added after or with the quantity parameter qty or step 5: added after everything is done. Your keywords could be renamed to "choice", "guaranteed" and "random" (rewards item uses "possible", not sure which is better, but I think it should be consistent); note the nice alphabetic order that might be handy later.

How do we want to represent the chance in the result query template contained in?

1. As a suffix, probably small. But this might be too much information in one spot, especially when it's a long list, e.g. in combination with an additional "(historical)" suffix. The output code would look like this: {{item|Heavy Loot Bag}} (1-3) <small>(random)</small>.
2. With an intro where the alphabetic order comes into account. However for single outputs these method might feel a little bit redundant. This method also requires a set chance value for each template usage, preset default value is allowed (probably "random"). The output code would look like this (different intro wording obviously; containers are examples):

* Chosen from one of the following containers:
** {{item icon|Crafting Material Coffer}} (10)
* Guaranteedly contained in:
** {{item icon|Chest of Ore}} (1-5)
* Randomly contained in:
** {{item icon|Heavy Loot Bag}} (1-3)

So, summing up, it comes down to two essential questions:

• How to move the quantity into the contains in a consistent way such that we don't miss anything? We might need someone to do it automatically with a bot, as moving the quantity by hand could easily be an incomplete task (beside the insane amount), e.g. how to track the remaining 10% if 90% had been adjusted.
• How to add a chance parameter to all contains templates? A new parameter can be easily tracked, so missing one isn't the problem there, instead the sheer amount of contains usages might be one as it can't be really done automatically.

Also with less then one month till EoD we are kinda limited in time. Again, quite a huge task but with incredible wiki improvement potential. --Tolkyria (talk) 16:49, 4 February 2022 (UTC)

From looking at the suffixes of lines using contains (in main space only), there seemed to be 1182 different suffixes over 38686 occurences on 3044 pages. While i'm not sure how difficult it would be to extract and move the relevant parts to a qty parameter, there do seem to be some unusual ones i'd not even know weather to move, alter or leave them. (The question marks specifically. (Although also uses of text; if unresolvable. (And i suppose also combinations of different notations, e.g. ranges and comma denoted or relations used together. (All of which, i suppose, could be answered by the question of if the value for the qty parameter is intended to be free form or not? (Either way, i hope the suffix list table is at least a little usefull.))))) Nightsky (talk) 19:47, 9 February 2022 (UTC)

Incredible nice list!

Quantity would be stored as pure text, e.g. something like {{contains|Mithril Ore|qty=1-5, 10 or 25}} is allowed and stored as a single text property entry.

Looking at your list, on a few pages we are using outside plural, e.g. {{contains|Mithril Ore}}s (1-3), after moving the quanity to the quantity parameter qty, would result into the incorrect parsed text "Mithril Ore (1-3)s". Probably these plural forms should be simply removed, if I'm correct in general we should use singular anyways. --Tolkyria (talk) 20:05, 9 February 2022 (UTC)

Thank you!

Sounds good.

Not using the second unamed parameter for plurals is what the template documentation would suggest as well. Though if the template's used in prose, which presently seems to be the case at least for Trade Contracts, allowing plural use would seem beneficial. But i don't know if the template is meant/intended/suited to be used in prose, so not quite sure if this argument applies. Nightsky (talk) 23:28, 9 February 2022 (UTC)

As Tolkyria wrote: Incredible list, Nightsky! Writing "(1-3)" vs. "(1–3)" should be decided. While "Provides 20 Trade Contracts upon consumption." reads more naturally in the note section, I would be fine with "Provides Trade Contract (20) upon consumption." Contents sections should use singular anyway. —Kvothe (talk) 01:50, 10 February 2022 (UTC)

Well, I should have read the documtenation, actually unnamed parameter 2 says: "Do not use this to pluralize the name." I cleaned up lots of plural forms, both adding the suffix "s" outside and inside using unnamed parameter 2; furthermore, I got rid of redundant quantities like "(1)".

Given how easy usable and convenient a hyphen "-" is, compared to how hard to actually get an actual en dash, there's only one answer: continue using the hyphen, like 99% of the currently documented quantities do (I tried to get it 100%). With a quantity parameter we could modify the displayed output with a #replace, but the input should always be as easy as possible. --Tolkyria (talk) 10:24, 10 February 2022 (UTC)

As i wrote: Thanks; again!

I'm with Tolkyria on using the hyphen. I wouldn't want to always go to Guild Wars 2 Wiki:General formatting#Hyphenation and dashes (to copy the en dash from there (or elsewhere (Only listing this one location here as it's where i've gotten one from the last time i've used them.)) all the time) if i'd want to add a quantity somewhere.

After working around an issue (Which might just be a block of my user agent, the headers, a combination of things or something else? (Which would render the bot inoperable; at least in the way in which i've been operating it so far. (For which i might have to reach out to Justin; if only i knew how and where, as the talk page seems to be used a sandbox?))), i could update the backing data and re-run the script and update the table to what now seems to be 1140 different suffixes over the same amount of {{contains}} occurences on the same amount of pages. Nightsky (talk) 21:20, 10 February 2022 (UTC)

And the list is outdated again, I couldn't resist and cleaned up some strange suffix. It looks definitely doable right now, either hardcode the most common quantity suffix in order to move them or dynamically use regex, e.g.:

\{\{contains\|(.*)\}\} (\([0-9\s\-,or]*\)) --> {{contains|$1|qty=$2}}

Furthermore, for example the ~13 champion bag pages listing the quantities in tables could be easily done by hand.

Email, talk page or even the bug page, I guess there are several ways to reach him, however not sure how much time an anet dev has right before EoD. --Tolkyria (talk) 22:40, 10 February 2022 (UTC)

Fair. I've updated the table again. 1127 different suffixes; with the rest still the same now.

See; i wouldn't even be sure how to best replace those (at least i'd guess it's those, not quite sure how many there are nor if some of them look any different (See the end for an example i've included of those i mean to enable verification of if it's the same type(s) of table(s) you mean or not.)) tables formatting wise. Like how to deal with the two columns; without using tables. Or multiple tables next to each other; without tables. Would seem like it might make things less easily readable. E.g. on Box of Lab Equipment and related.

I'll have to see about which one to use. Though i don't think it's a bug but instead possibly something specifically introduced so i'll probably have to go with/will end up with going for the talk page. And about the time, since things worked fine just the other day, undoing it would probably take no longer than it did to do it in the first place; for which there seemed to be time; so.. maybe it'll work out, maybe not. Not gonna find out now though as i've been meaning to play since for a while now and i'm not feeling like writing anything anymore at the moment either. Nightsky (talk) 23:31, 10 February 2022 (UTC)

We might want to postpone this; I'm not sure how much duplicate property chain bugs we probably could get (e.g. containers are sharing same icons, could be bypassed with item icon though, but also in general for queries outside the main templates), furthermore EoD is there in two weeks (time to slow down a little before it rather than full committing to such a large project), your bot might need some time (haven't followed the bug discussion in full detail) and there's a wiki update tomorrow. So overall, somewhen after EoD has settle seems to be a better spot. --Tolkyria (talk) 17:21, 14 February 2022 (UTC)

I would merely like to add that i'm sadened that i did not know of your comment untill now (i was meaning to link here when putting up a bot request just about now) and that i'm in agreement with it. Nightsky (talk) 17:55, 24 February 2022 (UTC)

(Reset indent) Would you agree with me when i'd say that things have settled down enough for this to be tackled? Or should it still wait? Nightsky (talk) 15:43, 3 May 2022 (UTC)

I would still prefer to consider my listed tasks before performing any mainspace or template edit (manual or botted), namely:

• Property names: Use unified property names for item subobjects that are acquired from a certain source (rewarded by, dropped by, now contained in, probably in the future gathered from), decide which names to use. See also table above.
• Related pages: Identify the that are related to this topic (mostly, pages that are using the property Contains item) and write down the new needed wiki code or the required wiki code changes.
• SMW property chain bug: There's still no fix (or even an update) for probably the most disturbing SMW bug ever, property chains are still suppressing duplicate values (see our bug page). To which extend will this bug affect this property restructure? Right now I think the following properties will be accessed as property chains and are likely to contain duplicate values:

• Canonical name (Contained in.Has canonical name) as two containers can share the same name
• Game icon (Contained in.Has game icon) as two containers can share the same icon
• Status (Contained in.Has availability) as more than one container can be e.g. historical

The first two property could be solved with a #show (or calling it with item icon), the last one by setting this property directly in the subobject for non-current items only (lightweight version that allows displaying only but not asking for it).

So yes, things have settled down after EoD, the task is to find time and motivation to go through and decide all these points. --Tolkyria (talk) 08:01, 4 May 2022 (UTC)

Sure. One thing i could think of as a substitude for the <???> part in the property names above would be "yielded", so i could suggest that. The property chain bug still being around certainly doesn't help on the querying side of things, i'm not quite sure i can see how it would prevent the parameter from being added with the bot now already; though i suppose i don't have to, simply put up a bot request for it once the time has come and someone will probably do it. (I was thinking to do it since it's about half way done already; but i also was thinking to stop botting soon too. (It's rather time consuming and stressfull. And i think Alex's doing a much better job at dealing with upcoming tasks fast as seems to be wanted anyways.) Was thinking i'd do it after this, but since it's been so long already now i'm not sure i'll be doing it for long.) I just made the mistake again to do most things already so i could tell if it would be possible to do with a bot and tell how many pages would be affected, so really this is on me. (On the other paw i've done not a lot more than propose and explain what i'd want to do for the file id setting bot task, so i could abandon that (and adding file ids to files in general) fairly easily; even if i'd hate to do so, as that seems rather helpfull for people and should be rather simple on the bot end too.) The best thing would probably be to have BuffsEverywhere answer your questions here, since after all it's their idea and i could do nothing more but speculate what they had in mind. Though they don't seem to be around a lot anymore, though maybe the ping will do the trick? Nightsky (talk) 15:33, 4 May 2022 (UTC)

guaranteed/random/choice

(Reset indent) I just want to bump this topic and return it a bit to one of the previous points, because I still think the info about if an item is guaranteed/random/choice from a box is a crucial information that should be displayed. ~Sime 14:31, 4 July 2022 (UTC)

To implement this bit, we'll need a property name, agree on the names for the options, a new parameter for this template, some edits to add the new parameter - probably only to the "guaranteed"/"choice" options - I suspect >90% of the containers are possible/random chance, so we should default to possible/random (whatever we call it).

(a) a property name - suggest "contains item chance" (just the current property name for this template with _chance on the end)

(b) suggest it prints as "guaranteed", "selection", "possible"

(c) a parameter name - suggest "chance", and values suggest options as "guaranteed" "

(d) suggest "chance" defaults to displaying "possible/random".

Probably need to go through by hand identifying the selection/choice container items and the guaranteed ones (probably pvp/wvw/meta-event-pve rewards mostly?) afterwards. -Chieftain Alex 20:11, 7 July 2022 (UTC)

Incidentally, adding this is probably much easier than quantity, so I suggest we split these two requests out from each other. -Chieftain Alex 20:12, 7 July 2022 (UTC)

What I can do myself only, unfortunately, is helping later with fixing the pages/adding the stuff there, so I'll leave the technicalities to people more suitable for it. ~Sime 15:28, 8 July 2022 (UTC)

You're totally qualified to chime in on suggested parameter value options and displayed text :P -Chieftain Alex 15:33, 8 July 2022 (UTC)

This change is now live. I've created [[Property:Contains item chance]], and updated Template:Contains to use a subobject. Template:Contained in, Template:Contained in/result format, Template:Account unlocks list, Template:Account unlocks list result format, Template:Item tp table and Template:Item tp row‎‎. I did choose to re-use the property Has item data object previously only used by recipes, I may regret that but for now it seems it will work once the pages are updated. -Chieftain Alex 12:22, 9 July 2022 (UTC)

Big thanks to User:Sunlion for helping with the updates to the container pages, we've done a decent chunk of the page updates together already. -Chieftain Alex 13:54, 9 July 2022 (UTC)

Well, I have to say I am a bit disappointed since I was looking forward to helping since it was me who had proposed it. Anyway, feedback: would it be possible to not have the parameter show on the box pages with the contains template? It looks weird to see for example "Choose one of the following: Commander'S Greaves (choice) (light)" and I think it should show only on the item pages. Also: technically I did propose the names in the discussion above. ~Sime 14:26, 9 July 2022 (UTC)

(Reset indent) Full list of templates which required update as below:

• Template:Contains - subobject added
• Template:Contained in - querying the data object of the subobject, instead of the item
  • Template:Contained in/result format
• Template:Weapon set contained in plus Template:Armor set contained in - this asks about containers with a set of interesting, chance is set at individual item level, not bulk container level, so couldn't use share with "contained in/result format"
  • Template:Weapon set contained in/result format
• Template:Salvaged from - salvage template doesn't set the chance property, so couldn't share with "contained in/result format"
  • Template:Salvaged from/result format
• Template:Item tp table - used on bulk contains item tables, needed a way of passing chance into individual items
  • Template:Item tp row‎‎
• Template:Account unlocks list - used on bulk contains item tables, needed a way of passing chance into individual items
  • Template:Account unlocks list result format
• Template:Category contained in - inverse properties chained to find the containers of items (with item context apparently used to avoid picking up gem store combo's containing items)
  • Template:Category contained in result format
• Template:Recipe sheet unlock table - recipe sheet containers
• Template:Gallery - subobject

-Chieftain Alex 18:39, 12 July 2022 (UTC)

Unfortunately, there was a missed chance to unify the whole item acquisition backend, see:

Property value/Property name	Drops table row/Dropped by	Rewards item/Rewarded by	Gather/Gathered from	Contains/Contained in	Notes
subobject name	#dropX	#itemX	#GatherX	#ContainsX	Different capitalization, would be nice to start all with, let's say, a small letter, rewarded by doesn't match the others.
context	- (currently) Dropped item (suggested)	- (currently) Rewarded item (suggested)	Gathered item	Container item	The first two could also use a context.
item	Drops item	Rewards item	Gathered item	Contains item
parent	Dropped by	Rewarded by	Has item data object (currently) Gathered from (suggested)	Has item data object (currently) Contained in (suggested)	The most straight forward way would be to name this property after the result format template name, i.e. Dropped by, Rewarded by, Gathered from, Contained in.
quantity	Has dropped item quantity	Has rewarded item quantity	Gathered item quantity (currently) Has gathered item quantity (suggested)	- (currently) Has contained item quantity (suggested)	Inconsistent "Has" suffix usage, I would prefer "Has gathered item quantity" and "Has contained item quantity". The quantity for contained in was the main motivation of this discussion.
chance	Has dropped item chance	Has rewarded item chance	Gathered item chance (currently) Has gathered item chance (suggested)	Contains item chance (currently) Has contained item chance (suggested)	Same problem as quantity, would be nice to have a consistent property naming scheme, either keep the "Has" or dismiss it.
chance value	Possible	Possible	Chance	Chance
id (subobject)	Has dropped item id	Has rewarded item id	-	-	Very specific property, no sure if needed for the last two.
collection	-	Is dropped during collection	-	-	Could be unified to "Is available during collection" for all four if necessary.
event	-	Is dropped during event	-	-	Could be unified to "Is available during event" for all four if necessary.

--178.191.22.97 12:41, 30 August 2022 (UTC)

Thank you for your comment. I agree with unifying the property names. How about dropping the "Has" suffix so the related properties start with the same letter/root word and for a better grouping in Category:Item acquisition properties? Although, that would make these property names inconsistent with property names elsewhere in the wiki. Hmm.

For completeness, I've added a row for the item link to your table. I've also added a row for the inconsistency of the chance value. --BuffsEverywhere (talk) 16:16, 30 August 2022 (UTC)

I knew that I copied a wrong property, thanks for fixing that one.

At least for me the core idea of semantic mediawiki is to use "sentences" for property declarations (<page> <property name> <property value>, e.g. "Mithril Ore" "Has context" "Item") to get straight forward property names that are unique and understandable. While it's totally valid to drop the verb, like for example the (oldschool) runescape wikis are doing it, the sentence style is an extremely interesting approach that I personally wouldn't abandon that easily (especially when almost all properties on this wiki are using it). A notable example for another large wiki also using verb phrases is liquipedia.

Renaming property could be easily done by "duplicating" them in the declaration (old and new property name), switching the result format to the new name and the removing the old one from the declaration. Renaming subobjects is kinda tricky, maybe "duplicating" and restricting the queries with wildcard subobject search (e.g. [[~*#Item~]] to exclude [[~*#item~]]). Totally up to you guys, just trying to give some ideas to consider. --178.191.22.97 20:34, 30 August 2022 (UTC)

I have edited the properties and templates based on the recommendations above. --BuffsEverywhere (talk) 07:28, 11 September 2022 (UTC)

These renames made sense, thanks that's quite a lot of effort for doing that. I found a few of the templates I'd linked above hadn't been updated - fixed these, and did an insource search to locate a couple more related to Template:Contains. I'm going to go out on a wild limb here and sugget that Template:Gathered from doesn't have nearly as many weird corner case pages. -Chieftain Alex 08:15, 11 September 2022 (UTC)

Now this is quality content, Mr. BuffsEverywhere, thanks for taking care of it. --91.114.172.79 19:28, 12 September 2022 (UTC)

bug reports

go here. -Chieftain Alex 20:39, 28 July 2022 (UTC)

All weapons for the Drakkar's Hoard (container) are listed as chance instead of choice (on the individual weapon pages). On a related note, maybe the template could also support currency (if it doesn't already), i.e. in this case the 1g from the hoard container + the selection of weapons? ItVictor (talk) 06:38, 29 July 2022 (UTC)

Fixed the items. Sunlion (talk) 06:51, 29 July 2022 (UTC)

Adding account or soulbound parameter

It would be useful if Acquisition sections could list if an item obtain from a specific source (e.g. a Reward Track chest) is account-bound or soulbound. Otherwise, unless specifically stated, this information is not visible on the items page e.g. Berserker's Volcanic Stormcaller Greatsword. Adding the information to the Contains template would be the first step in implementing this feature. -- Karasu (talk) 14:48, 4 July 2022 (UTC)