Template talk:Tooltip

List of Archived Talk discussions

 * Template talk:Tooltip/Archive01: Up to and including June 2007.
 * Template talk:Tooltip/Archive02: Up to and including May 2008.

Arena rating
What's the option for: "Requires personal and team arena rating of XXXX"?


 * Abuse |req= for now, I think. -- foxlit (talk) 20:53, 11 June 2008 (UTC)


 * Made it |rating=. Just give it a number value and it'll print the rest. 22:01, 12 July 2008 (UTC)

Double-quotes in name messing with float/font
I saw this problem with "Gigantique" Bag. Apparently using  instead of "-mark works. -- Fandyllic  (talk · contr) 9:48 AM PST 23 Jun 2008

Cooldown format
There should be a standard format for the Cooldown= entry, perhaps a template like cost. I've seen Cooldown= nn min and Cooldown= nn minutes. I think both work because they are transposed as text, there is no interpretation, but standardizing would be better. Madkaugh (talk) 21:20, 8 September 2008 (UTC)

Non PNG File Extensions
Seems in past discussions this was brought up, but still appears to be unresolved. For example, if you take an icon from wowhead, you'll have to convert it from JPG to PNG, yet the file uploader will take many non-PNG formats. It seems like such a popular template should be congruent with the upload feature. Howbizr (talk) 02:51, 21 September 2008 (UTC)
 * We intentionally use .png for all of our in-game icons because it makes the rest of our templates/page-creation bots that use wow icons a lot easier to deal with.
 * The file uploader takes all kinds of images because we use more than just WoW icons... -- k _d3 05:38, 21 September 2008 (UTC)

Achievement Tooltip Ideas
  Shafted!   Shoot 10 players with the.   Criteria:  - 10x Silver Shafted Arrow.   

  Fool For Love </li>  Complete the Love is in the Air achievements listed below. </li>  <strong class="selflink" style="color:gold;">Criteria:

🇨🇴   Heartmender</li>  Shafted!</li>  Flirt with Disaster</li>  Lonely?</li>  Nearest and Dearest</li>  The Rockets Pink Glare</li>  Nation of Adoration</li> </ul> 🇨🇴   Fistfull of Love</li>  Perma-Peddle</li>  Sweet Tooth</li>  Be Mine</li>  My Love is Like a Red, Red Rose</li> <li style="color:goldenRod;"> I Pitied the Fool</li> </ul>

</li> <li> <strong class="selflink" style="color:gold;">Rewards: </li> </ul>
 * Title Reward:

I had some ideas. Just wanted to share, if you want to adopt into the stylesheet / template. Here's an example of a regular achievement, as well as an achievement made up of other achievements. -Howbizr (talk) 20:04, 21 October 2008 (UTC)
 * This should be made into a new template if created at all. This template is strictly for items. -- 20:08, 21 October 2008 (UTC)

Best current practice for usage
I notice that there's some inconsistency between common usage, the example at the top of this page, and the boilerplate. On this page, we have: {{{{{tpl|tooltip}}} Help:Item articles/Preload has: {{ {{{tpl|Tooltip}}} ... }} The boilerplate definitely needs some tweaking so that it works more reasonably with subst (currently the onlyinclude wrapper and standard setup for mode and arg are lost in the subst). The item pages have a mixture of styles, a few of them are even missing onlyinclude/noinclude, causing breakage when used with, e.g. {{t|item}}. Some use noinclude around the rest of the page, some wrap the tooltip with onlyinclude. I reckon onlyinclude is the better style, as it's less prone to someone less experienced incorrectly putting something outside the noinclude block. But what about  vs. . I can see the utility of the latter, allowing an alternate template to be used when transcluding the page. Is that meant to be the standard, and should we be changing the existing articles to that standard?
 * mode={{{mode|}}}
 * arg={{{arg|}}}
 * mode={{{mode|}}}
 * arg={{{arg|}}}

I've got all the necessary framework and regexps available with MurphBot, from standardising and fixing the {{t|achievementbox}} usage, and it is very easy to adapt that to that to this template (although I do realise the scale of usage is significantly larger). Would it be desirable to have a bot standardise the usage to best practice (ensuring there's an onlyinclude wrapper, removing old noinclude wrappers, and ensuring that the required minimum parameters are present in standard form)? If so, does the following represent our desired standard usage? {{{{{tpl|tooltip}}} ... }} --{{User:WoWWiki-Murph/Sig}} 11:46, 24 December 2008 (UTC)
 * mode={{{mode|}}}
 * arg={{{arg|}}}


 * What I've understood so far is that  is for Foxbot to easily change the tooltips. The   has mostly been used in tooltips from older items. I don't believe that newer items has been using noinclude.   is what should be used.
 * On using bots to eliminate noinclude in favor of onlyinclude: I think that's very hard to do since there's articles that aren't items but use noinclude anyway. I'd let someone who knows more about bot editing to comment on that, thoug. {{User:Gourra/Sig2}} 12:07, 24 December 2008 (UTC)


 * Thanks. As far as restricting the elimination of noinclude to item pages, that's easy enough, as long as it is sufficient to restrict it to pages which actually include usage of {{t|tooltip}} (and not pages which transclude pages which have the template).  The python regexps which should achieve that are:
 * '(?msi)(?<={{{{{tpl\|tooltip}}})(.*?)</?noinclude>' -> '\1'
 * '(?msi)</?noinclude>(?=.*{{{{{tpl\|tooltip}}})' -> ''
 * Are there any examples of pages which are not items, but do have {{t|tooltip}} in them?
 * And not wanting to produce a controversial tangent here (if it's to be discussed, somewhere else would be more appropriate), but this is something that would be made more certain (ensuring that you're only processing items) if the items were in their own namespace or pseudo-namespace.
 * --{{User:WoWWiki-Murph/Sig}} 12:31, 24 December 2008 (UTC)


 * Just to clear things up:  was inserted by Foxbot, but the actual use is as Murph described: allow a different template to receive all of the tooltip arguments on transclusion. The syntax is desired behavior, and I've now updated the preload page to reflect this. -- foxlit (talk) 10:34, 27 February 2009 (UTC)

Feral attack power
Inspired by something on the Village Pump I noticed way too late, and ultimately Wowhead's new way of displaying Feral attack power, I used my basic wiki skills to come up with a suggestion how to implement that on our tooltip template here (for Staves/Polearms/2H-Maces over 54.8 DPS only)

I'd just be bold, but I'm unsure about just copying Wowhead's 'design'. (As a European, I expect just about anything from the US legal system ) Plus, others might not like it/have better ideas.

The previous FAP weapons need to be updated anyway, new DPS, Strength to AP, I'd do that as soon as I hear a 'yes' here. Hopefully Google helps me find all of them. ~ Nathanyel (talk) 14:16, 22 February 2009 (UTC)


 * Gourra made a point on the Village Pump that WoWWiki tooltips should look like ingame tooltips, and not like Wowhead ones. So another option would be to simply have FAP displayed as ingame, though the green might confuse non-druids. Then again, who can't read "in Cat, Bear, Dire Bear, and Moonkin forms only"? Anyway, I'd hope for at least a "go for it" before I get going ~ Nathanyel (talk) 17:57, 2 March 2009 (UTC)


 * If the goal is to "make wowwiki tooltips look like in-game tooltips", then you're going to need to know the race and class of the viewer, and what weapons he can wield. Those things are taken into account when the in-game engine renders the tooltip ("Mace" will be in red or white, depending on whether the character can wield a mace).  But you don't make any attempt to do that in wowwiki, because the viewer is not in-game, and those decisions don't apply.  Thus applying that rule to the Feral Attack Power rating isn't sensible either.  I like how wowhead uses an orange color to make it stand out; it's clear that it's something that is not done in-game.  I see no problem copying their style, as long as you don't copy their code.  The old "Look & Feel" argument was settled long ago in courts, when Apple lost their lawsuit against Microsoft.  There is nothing illegal about copying "use orange text to indicate that feral attack power is different and only applies to druids".  Please do copy wowhead. Markkawika (talk) 20:35, 2 March 2009 (UTC)


 * Now that's good feedback, never thought of the "mace in red" thing - I guess what WoWWiki (or Wowhead) should/is trying to display is the item from an omniscient point of view, level 80 character of all classes, with all weapon and trade skills maxed out. Anyway, will get to it after lunch. ~ Nathanyel (talk) 10:11, 3 March 2009 (UTC)


 * Oh wait, I can't edit tooltip myself... Would someone with the proper rights do that please? Here's the diff with what needs to be added. Gonna go ahead and update the former feral weapons already. ~ Nathanyel (talk) 12:50, 3 March 2009 (UTC)


 * This edit has an error, and causes "Expression error: Unexpected &gt; operator" to appear in every page that uses this tooltip. Would some kind soul with the proper authority fix this please? --Hops Splurt (talk) 15:34, 3 March 2009 (UTC)


 * Which article are you talking about? I don't see any errors so far with the tooltip. -- 15:41, 3 March 2009 (UTC)
 * Should be fixed now. -- 16:06, 3 March 2009 (UTC)


 * And done, at least with those weapons Google came up with. Searching for others soon. Would you believe how many distractions can come up during the course of an afternoon? Noticed some &plusmn;1 AP disparities on some green Outland random-stat staves plus, but 1 AP is virtually nothing in Outland content and upwards. ~ Nathanyel (talk) 18:58, 3 March 2009 (UTC)

There are also one-handed and main hand weapons that has feral attack power - while they are obviously not suitable for Druids, shouldn't they show the feral attack power too? This is what I thought about changing in the specific part of the template. The changes starts and ends with.

-- 15:31, 10 March 2009 (UTC)


 * If you're thinking about the Vanilla 1H maces like End of Dreams, they don't have Feral AP anymore, as this is computed solely by weapon DPS now. For newer 1H weapons with >54.8 DPS, the Feral AP gained from them doesn't matter, as no Feral uses 1Hs anymore – and the FAP display should be (mostly) for weapons that a Feral of appropriate level would use – I'd even supress FAP for staves with spellpower (Atiesh would need a special fix, though) ~ Nathanyel (talk) 18:30, 10 March 2009 (UTC)


 * Well of course The End of Dreams doesn't have FAP, it has lower than 54.8 DPS. While 1H weapons aren't suitable for feral druids, we should show the FAP for those anyway for consistency.
 * I've just noticed that the FAP value on items is 1 higher than the value on Wowhead, should this be corrected? I'm not reallyy fluent in the math coding, so it would be appreciated if someone else fixed this. -- 10:57, 16 March 2009 (UTC)


 * Yeah I noticed the &plusmn;1 discrepancies, too, as mentioned above, could be that the actual formula is even more complicated than, but hey, it's just 1 AP max *shrug* If someone finds a better formula, just change the one we use.
 * I don't know about showing FAP on 1Hs, I'd vote against it, but if more people want it, why not. ~ Nathanyel (talk) 13:06, 16 March 2009 (UTC)


 * The thing though is that it should be, which rounds it up or down (506.4 -> 506, 506.6 -> 507 etc) and with no decimals. I'll let some other admin change it though and create the HUEG job queue. -- 15:01, 26 March 2009 (UTC)


 * Re: the &plusmn;1 discrepancies.
 * Sometimes, the problem lies right in front of you yet you cannot grasp it until at some point you just "ding" and get it. The thing is, we're calculating the FAP from the "dps" value, which is already a rounded value when it's displayed in item tooltips. This value is calculated from ((mindmg+maxdmg)/2)/speed or (mindmg+maxdmg)/(2*speed) - new problem, the template doesn't get the raw mindmg A and maxdmg B values, but instead a string in the shape of A - B or A-B. Would it work to replace the - with a + and then have that string evaluated to get the mindmg+maxdmg value? Still not fit enough in the wiki code to attempt this, not that I had editing rights to this template anyway (also: sleepy) Just throwing it here, maybe someone wants to take care of it, with a really low priority, though. ~ Nathanyel (talk) 00:45, February 28, 2010 (UTC)

No level requirement
I've run across items with no level requirement having level=1 in the WoWWiki tooltip. This is indirectly correct, but is really not the same thing as no level requirement - the tooltip display is different. Am I correct that if the item does not have an explicit level 1 requirement in the in-game tooltip, these should be removed, per note above, "make wowwiki tooltips look like in-game tooltips"? For this particular bit of data, The Armory should be a reliable source. Madkaugh (talk) 01:17, 3 March 2009 (UTC)
 * Yes, that's correct. -- 02:21, 3 March 2009 (UTC)

False positives for Pages which may need their tooltips updated
This template has a mechanism for detecting out of date tooltips, mostly from the change from +healing and +damage to spellpower. The out of date items get put into Category:Pages which may need their tooltip template updated. With transclusion, this category currently contains over 3,200 articles. Of the first 50 I checked, less than half were erroneous, the others were included because they included the word "healing" (mostly from alchemy trinkets). Would it be possible to increase the sensitivity of the detection to minimize the false positives?

Items that had +healing and +damage said: "Increases healing done by up to X and damage done by up to X for all magical spells and effects." Items that increased healing and damage by the same amount had: "Increases damage and healing done by magical spells and effects by up to X."

Perhaps expanding "healing" to "healing done" or a check for "for all magical spells and effects." (not sure if that is still used) would eliminate many of the false positives. This might make a project to go through the templates and update them somewhat less daunting. -- <span style="font-size: 0.85em; padding: .2em .3em; border-top: 1px #504c50 solid; border-bottom: 1px #504c50 solid; background-color: #2C2C2C"> Wige  ( Talk -  Contribs ) 18:51, 12 March 2009 (UTC)
 * It also gets placed on pages that use item or itembox that contains the item that needs updating. So if Item A is linked using those templates on 5 different pages, 6 articles will appear in that category. 00:27, 13 March 2009 (UTC)


 * There is a section in the template that applies only when the template is being called from the item's own page. Would it be possible to either add the check to that section, or wrap the check in a similar restriction so other pages don't get included? -- <span style="font-size: 0.85em; padding: .2em .3em; border-top: 1px #504c50 solid; border-bottom: 1px #504c50 solid; background-color: #2C2C2C"> Wige  ( Talk  -  Contribs ) 13:59, 13 March 2009 (UTC)
 * Fixed that a few hours ago; transcludes will slowly disappear from that category as the job queue catches up. -- foxlit (talk) 15:26, 13 March 2009 (UTC)


 * Also, the check appears to check a variety of things: "effect" contains "spell crit", "spell hit", "spell haste", "dismiss" (for mounts?), "healing" (for the change to spell power), or "ignore". If some or all of these were put into sub-categories it might make it easier to break down the workload and knock them out one by one. -- <span style="font-size: 0.85em; padding: .2em .3em; border-top: 1px #504c50 solid; border-bottom: 1px #504c50 solid; background-color: #2C2C2C"> Wige  ( Talk -  Contribs ) 13:59, 13 March 2009 (UTC)


 * My plan is just to have a bot go over the remaining pages in the category once the dust settles and update the tooltip, then remove the current "need an update" matches from the template -- foxlit (talk) 15:26, 13 March 2009 (UTC)

Finished; there's a list of items you need to examine manually at Template talk:Tooltip/Pages that might need an update. -- foxlit (talk) 22:48, 16 March 2009 (UTC)

Template:Tooltip/doc
Would like to see this template use the /doc format for the documentation to be displayed on the template page. The documentation for this is extensive, and I find it a bit awkward to have to go to the top of the talk page to find it. Would not cause more than one-time disruption of the template page. --Eirik Ratcatcher (talk) 20:58, 10 April 2009 (UTC)
 * Done. Enjoy your 34k jobqueue. -- k_d3 02:29, 11 April 2009 (UTC)
 * Others are willing to upset the entire category schema to implement a new one. I'm willing to alter templates that are used everywhere.  Everyone has to have a hobby. :) --Eirik Ratcatcher (talk) 19:06, 16 April 2009 (UTC)

Token refund
I noticed that now you can be refunded your Dalaran Jewelcrafter's Token if you haven't learned the pattern yet. I propose adding tokenrefund. -Howbizr (talk) 19:18, 25 April 2009 (UTC)


 * Nah. It's not always there in-game. It should just be a note in the article. -- 19:31, 25 April 2009 (UTC)
 * That was one of the changes made in 3.1. Any alternate-currency-purchased items (outside of things that reward achievements or are stackable -- like orbs) can be refunded within a two-hour window. I agree with pcj that such a statement needs to be in the relevant article itself...
 * Patch 3.1.0: "Players can now return items purchased with an alternate currency back to the original vendor within 2 hours of the purchase time for the original cost of the item. Stackable items (such as Frozen Orbs and gems) and charged items that can be purchased with an alternate currency are not eligible." -- k_d3 01:54, 26 April 2009 (UTC)

Bug: Mail (armor items)
I admire that someone put the effort into making the value of "slot" and "type" into links, but I think that the audience would be better served if they were to link to static pages (i.e. Equipment Slot and either Armor or Weapon). Currently, Plate is a redirect to Plate Armor, Mail discusses mailboxes. I imagine that leather and cloth redirect to the armor types. Specifically, my current complaint is about the Mail link.

I could also live quite easily if those two items were NOT links... --Eirik Ratcatcher (talk) 20:17, 28 May 2009 (UTC)


 * I fixed the "type" problem for armor types at tooltip/Dev. Maybe you can test it a bit and then I'll move it to tooltip. I did a few tests at Template_talk:Tooltip/Dev and it seems to work fine. -- Fandyllic (talk &middot; contr) 2:17 PM PST 28 May 2009
 * Did you also find/correct any problems with "type=(some weapon type)"? I don't know of any, but since you've got the template up on blocks anyway... :) --Eirik Ratcatcher (talk) 21:47, 28 May 2009 (UTC)
 * Okay, one potential issue. type="Held in Off-Hand" requires a high degree of precision, to link to somewhere useful, IMO.  Just sayin'... --Eirik Ratcatcher (talk) 22:11, 28 May 2009 (UTC)


 * |type= has been fixed for every case I can think of. Are there any slot issues? -- k_d3 00:10, 26 June 2009 (UTC)

Jewelcrafting
Unique equip needs to support more than a number. For Thick Dragon's Eye, it's "Unique Equipped: Jeweler's Gems (3)." 3:00 PM, 6 Jul 2009 (EDT)

item level
Was there a reason the display for item level was changed? Zurr (talk) 00:44, 25 July 2009 (UTC)
 * Patch 3.2. -- 00:46, 25 July 2009 (UTC)

Support for transmute spells
<ul><li><li>Requires Alchemy (450)<li>Tools: <li>Requires: , <li>Creates: Transmute the element of shadow and a Monarch Topaz into an Ametrine. Cooldown: 20 hr 5 sec cast</ul>

They don't fit the current template very well - stuff is missing, or doesn't look right. There are several transmute pages that already need written, plus now we're getting more discoverable transmutes.

Here's my suggestion. If this looks good, I'll work on the template in a sandbox. Otherwise, can you give feedback about what you'd like transmute tooltips to look like instead? 8:13 PM, 31 Jul 2009 (EDT)


 * The issue here is that you're trying to use an item tooltip template for what isn't actually an item, and finding that it doesn't quite fit. This is the intended design -- undefined, despite its name, isn't meant to be a catch-all template for all tooltips WoW can display, but rather only supports items (perhaps we should... *horror*... change its name to reflect this purpose).
 * What you should do is to create another template in the style of embroid or enchant – or, better yet, see if those three can generalize to some sort of trade skill tooltip template. -- foxlit (talk) 01:25, 1 August 2009 (UTC)


 * I'm down for that. You're right - the name keeps tripping me up. Do you have any other spells I might try to support (going with the generic idea)? Or any name ideas? (prof?) 5:40 PM, 31 Jul 2009 (EDT)


 * I'm leaning towards calling it Proftip. Here's my sandbox and some examples. 3:13 AM, 1 Aug 2009 (EDT)


 * Looks okay to me; your next step is probably to move it into the proper namespace and request some more comments -- assuming nothing comes up, we can then mark enchant/embroid as deprecated (or replace them with versions that call your template). -- foxlit (talk) 11:01, 2 August 2009 (UTC)

Support for unique equip types

 * Test of


 * Regression

Anyone see any problems with this change? See Tooltip/Dev. 9:43 PM, 14 Aug 2009 (EDT)
 * The top one has the parameters   and   and the bottom one does not have the parameter   and still displays the 3 with no item shown. --  01:59, 15 August 2009 (UTC)
 * Maybe it was a bad example, but I was trying to show (regression) that the old behavior isn't broken, just because I added a new feature. I couldn't think of any items that have a unique quantity of more than 1, except gems. 12:07 AM, 15 Aug 2009 (EDT)
 * Moved to the main space. 9:49 PM, 16 Aug 2009 (EDT)

Using Template Tooltip to categorize

 * Moved from User_talk:Howbizr 9:52 PM, 16 Aug 2009 (EDT)

I was wondering if making Tooltip auto categorize what can be categorized thru it would be a good idea? Over at Template:Tooltip/Dev I have made a copy of Tooltip and added some  then categorize statements, of the parameters that I know to be used as categories. Take a look, play with and see if it looks doable or not?

I did seperate the Classes= into class1, class2, class3, class4 class5 parameters, so that it will categorize the items into each class that can use the item and made the  go into a non-existant Category:Deprecated classes= paramater to find the pages that used Classes= and can be changed over to class1, class2, class3, etc. --  01:41, 17 August 2009 (UTC)


 * I'll look at it. Basically, as long as you tread carefully, it might not be a bad idea. 9:55 PM, 16 Aug 2009 (EDT)
 * Don't split classes into more parameters, you can use to good effect here.  Also the category names you have are wrong, they are items, not sets. -- 02:10, 17 August 2009 (UTC)
 * I used the same categories that was used for pre-existing items look at Category:Hunter sets it lists the individual pieces for Tier 1, Tier 2,...,and the Tier 9 I added - and there is no such category as Category:Hunter items -- 20:46, 17 August 2009 (UTC)
 * I do not know about / never heard of so I can not use / will not use it. --  21:46, 17 August 2009 (UTC)
 * Where are you guys looking? I don't see anything in the history for Tooltip/Dev. 10:58 PM, 16 Aug 2009 (EDT)
 * See Tooltip/dev. -- 03:06, 17 August 2009 (UTC)

The problem with auto-categorization is that the Slot gets messed up: we have categories such as Category:World of Warcraft epic guns and Category:World of Warcraft epic trinkets. Then there's also quality that clashes with other categories, such as Category:Epic gems and Category:World of Warcraft rare quest starting items.

Then there's the issue about the classes= parameter doesn't mean that it's a set item; for example look at Codex of Defense.

In total I'm against this change. -- 07:26, 17 August 2009 (UTC)
 * I fixed the classes so that it will not put items into classes unless they have a Type and a slot ( meaning they have to be worn - with the class restriction ) before it would put the sets category. --  20:46, 17 August 2009 (UTC)
 * As a side note, I moved Morph's stuff to Tooltip/Dev. 5:56 AM, 17 Aug 2009 (EDT)


 * I believe the categories have just gotten too complex to allow parameters in a template dictate the category it belongs in. 19:04, 17 August 2009 (UTC)


 * I must agree with Gourra and Coobra. Having a template add categories limits what you can do with the template.  Some templates (eg Questbox) do autocategorization; we later on had to retrofit with a parameter to allow blocking that behavior.  I would be more in favor of a template that specifically added categories.  But by the time you get through with that, you've done 90% of the work you would have done anyway, what with customizing (for instance epic guns and not epic main hand swords). --Eirik Ratcatcher (talk) 20:03, 17 August 2009 (UTC)
 * I semi agree with these statements - It is beyond my Template knowledge to make it do every category properly -- but by the same token - I refuse to try to remember every category an item can possibly goes into (There are just TOO many - I was just wanting to get the main ones). I will just add a few basic (easy to remember) and you all can go behind me and add all the proper (exacting) categories. -- 20:46, 17 August 2009 (UTC)

The DEV template now will only categorize the most common Categories:


 * If  is set, it will place the item into the Category:World of Warcraft socketed items
 * It will auto categorize the item by the items quality: Category:World of Warcraft poor items, Category:World of Warcraft common items, Category:World of Warcraft uncommon items, Category:World of Warcraft rare items, Category:World of Warcraft epic items, Category:World of Warcraft legendary items, Category:World of Warcraft artifact items and Category:World of Warcraft heirloom items
 * If  is set, it will auto categorize based on the items quality: Category:World of Warcraft epic quest items, Category:World of Warcraft rare quest items, Category:World of Warcraft uncommon quest items and  Category:World of Warcraft common quest items or Category:quest items if it does not fit those specific categories. --  18:19, 18 August 2009 (UTC)

As a side note I also added the the  parameter to make it show all 5 alliance races and   parameter to make it show all 5 horde races as a shortcut instead of typing out    and it does NOT interfere with pre-existing items that have |races= already set - so could you add that (it would come in handy for future mounts and such that are Horde/Alliance only items), and its associated documentation to that section. -- 20:53, 17 August 2009 (UTC)


 * How's the tip handling (eg) "Dwarf, Gnome" (from old mechanostrider) these days? --Eirik Ratcatcher (talk) 21:35, 17 August 2009 (UTC)
 * All I did was add to see if you put Horde or Alliance (if so then it put all 5 races for you) if you put anything else it shows what you put - so all previous settings will not be affected -- ( go to Template:Tooltip/Dev and see what I mean) change races= to Dwarf  Dwarves  Alliance Horde Forsaken undead etc. --  21:41, 17 August 2009 (UTC)

I'm still not really sure if it's worth it to auto-categorize every item that used the template.
 * 1) If the /Dev categorize everything by the item quality, how will it check for the previous categories? (Epic guns, Epic trinkets, Common quest items etc) An item tagged as rare and quest item will get both "... rare items" and "... rare quest items" categories, of which the first one is redundant.
 * 2) Removedfromgame requires all the applicable categories to be removed, how would that be handled?
 * 3) While you like to make it apply for the major categories, I wouldn't implement it until all categories would be handled by this.
 * 4) I understand that this would be alot of work for you, but I can't help to wonder if it's worth it - I sure wouldn't pick up a project this big. -- 21:05, 18 August 2009 (UTC)


 * I can add switch as to the epic gun, trinket items and not place them into the epic items. As to the redundant Rare item and rare quest item - I can put 1 more if - on the rare item (checking if it is quest) (yes then do nothing / no then categorize by quality) so it would be rare item or rare quest item ( not both )
 * As to the removed from game - I can look at the achievementbox or others and see how the |doc= to remove categories - I am guessing another If statement to make it not show category if doc= is set.
 * I can not do.
 * With your requirements then your right it cant be done (not by me) and then we are back to what I said above - I will only put the minimal of all categoies (for I refuse to try to remember your Categorical mess I have looked at in the Item categories as they are **ps you have DUPLICATION there already **) and you all can go behind and fill in whatever specific categories you think they should be in (I was just trying to make all existing items have teh bare minimal of similar categories - I have seen some items with 6-10 categories (some I never knew existed) then I seen other items with just 3 of the 6-10 and another item have a different 3 categories of those 6-10 (and the 2 items were the same type just a different tiers) so many inconsistancies but you are Admins and know you best.
 * -- 23:12, 18 August 2009 (UTC)
 * Never mind project scrapped -- 23:13, 18 August 2009 (UTC)

Picking it back up
So I'm taking a look at it now, taking a different approach from morph.

To get some categories like " quest rewards" and the gem categories to work we're going to need to add some new parameters.


 * qreward: just a quest reward flag. No display
 * key: just a 'this is a key' flag. No display
 * gem: needs to be one of "Red", "Yellow", "Blue", "Green", "Orange", "Purple", "Prismatic", "Meta". Tooltips can be generated using |gem= instead of the flavor line.

I'll come back and edit this when I work through the rest of the categories. -- k_d3 01:08, 19 August 2009 (UTC)
 * Okay. I've reached a stopping point for the night. Poke holes in what's been implemented so far. I'm not touching classes/races yet. -- k_d3 02:52, 19 August 2009 (UTC)

With what Blizzard is doing to all (if not 90%) of the gear, this is probably the best time to make the tooltips autocategorize the items. This way the corrections can be made at the same time we clean them up. This will also allow for the renaming of the item categories if we so wish. 19:46, 26 August 2009 (UTC)
 * Expecialy the Cateogory:World of Warcraft can be placed in the Category:WoW . --  19:59, 26 August 2009 (UTC)

I'll take the opportunity to point out, adding parameters to tooltip only adds marginally to reliability on categorization, in that it shifts the responsibility on the part of the editor from "add/edit categories" to "add/edit parameters". Sure, it makes it greatly easier to do simple category renaming (by changing the category used by this template). But that is not really a common occurrence, is it? More often, categories are new, or subdivided or combined, which would require editing the individual pages anyway.

"Previous pages provide specific tooltip examples" < -- > "previous pages provide specific category examples" Same with boilerplating.


 * shrug* --Eirik Ratcatcher (talk) 20:39, 26 August 2009 (UTC)


 * People using the templates fill in more of the Parameters ( problably because it is easier to see all of the paramters used on 1 page ) then add categories ( problably because all of the POSSIBLE categories are not known for the article ) so if you cateogries as much as possible baised on the parameters then the items will be more fully and consistantly categorized - untill recently I put all Cloth items in because I did not know there was, ,  , etc... thus a discrepency in how items were categorized not to mention the Plate, Leather, and various Weapons type items that do not fit any pattern in how they are categoriezed ( that I can see yet ). This is the best closest way to being consistant across the board (you can always add MANUAL categories if you feel the auto categories do not add enough categories) but at least the BASIC categories will be hit for all items with template auto-categorizing! --  21:18, 26 August 2009 (UTC)


 * Sure you can add categories. How do you *remove* categories? --Eirik Ratcatcher (talk) 23:38, 26 August 2009 (UTC)


 * The idea is to add the known Correct categories 1st - so ther should not be a need to reemove them unless it is a patch # item that requires all categories to be removed. Thiscan be implemented just like the achievements do now (you add 1 more parameter that encompasses ALL categorizations. If  is set then no categories are added, or any other main parameter name for this function. This ability is added last, after the auto-categorization is known to be working and just before it is made live on the main template. --  00:05, 27 August 2009 (UTC)


 * If there's an issue where the template adds a category it shouldn't.... the template won't mess with the category at all. Since we're going to have to update pretty much every item in the game come 4.0, now's as good of a time as any to get the edge cases fixed so they won't be a problem in the future. /Dev hasn't been messed with in a few weeks... what other cats do we need? -- k_d3 19:05, 31 August 2009 (UTC)


 * Added a location request parameter option... although this could just be handled independently if it would just be easier. This also might lead into not just items categories, but also items categories (like The Barrens items) for non-world drops of course.... which just put a thought in my head,   22:57, 31 August 2009 (UTC)


 * As mentioned above, would not this be the time to make the categories Category:WoW instead of Category:World of Warcraft ? Then we could go and remove all of the World of Warcraft categories with a bot or such (in preparation for the 4.0 changes - so we will not have the 30,000+ currently on file and any future items between now and 4.0?) -- 00:13, 1 September 2009 (UTC)
 * Added a set request option. -- 00:39, 1 September 2009 (UTC)
 * These aren't sets, they're items. -- 02:23, 1 September 2009 (UTC)
 * Then call them Tier #  (instead of Tier # sets) - you are disagreeing over semantics (words) but they idea of them being group together still remains the same - Since they are already Grouped that way now. --  08:56, 1 September 2009 (UTC)
 * No, I have a problem with the size of the category more than the name, we should have the sets be categories and within those have the set items. It would make it much more navigable.  Hopefully I explained it well enough. -- 12:28, 1 September 2009 (UTC)
 * That does not make sense to worry about the size of Arena 1, Dungeon set 3, or Tier 9 (because tier 9 will only be as big as Tier 9 only, it will not have tier 10 or tier 1 items in it). Every ITEM type category we have will need to be reworked, if you are worried about their SIZE. --  17:07, September 1, 2009 (UTC)
 * We would have to break down every Simple Category, Armor/Weapons category, Gems catagory, Quest category and Profession category currently listed as active by k_d3, because not ONE of them is getting any smaller, each one grows with each and every new Tier set and Arena season. -- 17:18, September 1, 2009 (UTC)
 * The more specific the category, the greater the need to be able to identify individual items in it. We do indeed have general categories with thousands of pages per category.  And they are not amenable to 'browsing'.  Yes, we're concerned with size of categories.  The larger they are, the less useful they become, the more likely breaking the category down into subcategories would be a useful change.  Thus, "poor weapons" instead of just "weapons", for instance.  Or "Green gems" over "gems".  --Eirik Ratcatcher (talk) 17:26, September 1, 2009 (UTC)
 * My recomendations were specific and easily identifiable and easily grouped, with the exception of the Class items. Tier 1 items would only have tier 1 items, the same same with Tiers 2, 3, 4, 5, 6, 7, 8 and now Tier 9, as well as with the Arena items (they can NOT grow larger unless Blizzard adds to them later and still they can not get too much larger because. Blizzard adds new Tiers / Arena seasons every patch or two, so the size complaint has no merit in this case, other than the Class items. -- 17:42, September 1, 2009 (UTC)

Categories already added to /Dev

 * Simple categories
 * Category:Bags
 * Category:World of Warcraft book items
 * Category:World of Warcraft conjured items
 * Category:Keys
 * Category:Lockboxes
 * Category:World of Warcraft socketed items
 * Category:<Faction> rewards (of Category:World of Warcraft faction rewards)
 * Armor/Weapons
 * Category:World of Warcraft <cloth-plate> items
 * Category:World of Warcraft (bows|crossbows|fist weapons|guns|neck items|polearms|staves|trinkets) Note: Neck items not supported fully.
 * Category:World of Warcraft <cloth-plate> items
 * Category:World of Warcraft items
 * Category:World of Warcraft items
 * Gems
 * Category:<Quality> gems (of )
 * Category:<Color> gems (of Category:Socketable gems)
 * Category:<BoP/BoE> gems
 * Quest
 * Category:<Quality> quest items
 * Category:<Quality> quest starting items
 * Category:<Quality> quest rewards
 * Profession
 * Category:World of Warcraft items

Categories still to be added to /Dev

 * Location
 * Category:<Zone> items
 * Category:<Quality> world drops
 * Category:World of Warcraft finger items (of Category:World of Warcraft finger items)
 * Category:World of Warcraft neck items (of Category:World of Warcraft neck items)

Categories that will be ignored by /Dev
?

Parameter |doc=
I added the parameter |orange=.


 * This will keep the template from adding any categories other than the hidden (Category:Item pages). This will keep the template in line with any policies governing the template Removedfromgame. -- 04:43, September 6, 2009 (UTC)

Events
Should probably add an event parameter as well. I'm still trying to figure out exactly where its placed in the in-game tooltips...

Seems to be somewhere after the slot type and before ilvl. Currently we've been using either |instancebind (which comes before things like BoP) and |skill (which comes after ilvl). 23:57, November 6, 2009 (UTC)

1 Charges
I've made this edit, to /dev, to remove the 's' when items have only one charge. It's a simple edit, and the testcases appear to work correctly. Is it suitable for inclusion in the real version? RoadieRich (talk) 23:51, February 16, 2010 (UTC)

Tooltip/Dev - categories
Tooltip/Dev shows that (among other things), Tooltip does not pass the "doc=" flag to Settip. --Eirik Ratcatcher (talk) 23:20, February 18, 2010 (UTC)

Bag= appears to be broken...
See Deviate_Hide_Pack as an example. I suspect this is the cause of most of the 153 broken links to Bag Drazisil (t/c) 23:39, May 15, 2010 (UTC)
 * Will it update on it's own, or does each page need to be re-saved to update the transcode? [[File:IconSmall_DrakeAzure.gif]]Drazisil (t/c) 00:22, May 16, 2010 (UTC)
 * Works perfect now! :) [[File:IconSmall_DrakeAzure.gif]]Drazisil (t/c) 00:27, May 16, 2010 (UTC)

Tooltip item and semantic data moving forward
So tooltip item is in a stable-enough state at this point, and once we get the go-ahead from the server guys (I'd rather not get killed in my sleep for grinding all of wikia to a halt, kthx), I'm going to promote it to live. That should be in a week or two when the new SMW-specific database hardware comes online. And when the job queue is fixed.

As it stands, tooltip item is backwards-compatible (would Wikia ever get the hint and do the same with their "features"?) but there are new-and-better ways to define some attributes now that we care what they mean, not just what they look like. Said parameters are listed on tooltip item/doc. The bot herders, myself included, are going to be busy doing updates once tooltip item lands. Search-and-replaces, mostly. Thankfully.

Once the job queue settles, the next step is to update the rest of the tooltip-data-consuming templates (item/itembox/settip among others) to use the semantic data now getting defined instead of just transcluding the page.

So... where do we go from here? There's plenty more valuable and useful data about an item than that which appears in it's tooltip. Do we want to define hidden parameters for such data, like |source=Crafted, |itemid=12345? Extend the templates we're already using, like elinks-item? Create new templates so there's a standard way to define things like source?

Source information I would really like to see semantically tagged, whether or not it's defined in the tooltip. It'd make maintaining the " loot" pages, not to mention the loot tables for individual bosses, so much easier.

Thoughts? Ideas? The sky's the limit with regards to what kind of data we can use and how we can access/collect it. We just need to be sane about it. -- k_d3 03:05, July 31, 2010 (UTC)


 * Just an fyi: |source and |itemid have previously been used. |source was removed at some point, while |itemid (possibly |id) still exists in usage. We'd have to check the db to see whether itemid or id is in greater use.
 * I'm not quite sure how best to utilize something like |source. How specific do you make it? Do you use bosses or the dungeon names? "Engineering" or "Engineering 325"? If it's a world drop... is it a world drop? Or is it a world drop specific to a certain zone? How do you call that a world drop?... I mean, we have categories for world drops... What about quest drops? ~Musings
 * I'm wondering about other data that we could include. --Sky (t · c) 03:57, July 31, 2010 (UTC)
 * I'd guess itemid, as that's what I've been putting in my page-generation scripts. For source, see Instance drop as a hastily-created example. Other templates would be needed for things like crafting, vendors, quest rewards. -- k_d3 04:02, July 31, 2010 (UTC)


 * While you're here, consider renaming the template. undefined is annoyingly generic; it'd be better to steal something like (wowitem? itemtip? itemtooltip? itemdata?) for it. -- foxlit (talk) 20:24, July 31, 2010 (UTC)


 * Might as well roll it out now if we want to do that, along with a couple other changes such as the removal of arg and co. I would suggest, myself. --Sky (t · c) 21:14, July 31, 2010 (UTC)

Mana Gems
Wowhead calls out that Mana gems are a unique type of their own - you can possess only one (of any type) at a time. 1) they are not "equipped", so the unique-eq parameter would not generate the correct description. 2) a quantity of *1* for unique-eq fails to cause the unique-type element to display.

I do not personally know the accuracy of mana gem uniqueness. If true, though, we cannot currently display the correct state. --Eirik Ratcatcher (talk) 22:03, August 31, 2010 (UTC)

Categorization
What is the reason for categorizing all articles that use this template in Item pages? This prevents being able to see if there's any item articles that are missing proper categories, or if they have any categories at all. -- 14:12, September 7, 2010 (UTC)
 * Probably for bot work, I believe Special:Whatlinkshere/Template:Tooltip includes everything that includes the pages Tooltip is on. -- 13:14, September 8, 2010 (UTC)
 * Wouldn't mind if it's helping for a bot (which would it be, by the way?), but since it gives otherwise uncategorized pages a category, it's impossible to find out by Special:UncategorizedPages if item pages are missing the proper categories. It would be helpful to have the hidden category removed until at least the end of the week. -- 13:21, September 8, 2010 (UTC)

Patch level
Proposal: Include an attribute, optionally displayed, for the patch level of the game that the tooltip/settip reflects. If we're going to update all 20,000 armor pieces with their new armor, vendor, durability and/or stat values for 4.0 we need a way to quickly tell the ones that still need to be done. e.g. (see source here)

Vs. the new tooltip

. We could filter against that patch value and find outdated items right away given the known historical and future re-itemization patches Drolfeir (talk) 06:54, 31 October 2010 (UTC)

Skill vs Prof Attributes
I am attempting to develop recipe templates, and noticed that tooltips are displaying "Requires ____" whenever the prof= attribute is defined. My understanding from the documentation is the generic tooltip runs of of skill=, leaving prof= for use by proftip. Is this behaviour intended, and if not, can it be removed to enable use of proftip meta-data? D.D. Corkum (T / C) 14:21, 27 November 2010 (UTC)

Feral Attack Power Part 2: Rest in Peace
Well since 4.0.x, FAP no longer exists, as feral druids now benefit from the weapon's DPS directly. Can someone with editing rights remove that part from the template? ~ Nathanyel (talk) 12:01, 1 December 2010 (UTC)