Template talk:Bug

Marking Bugs

I believe confirmed bugs or bugs needing verification should be marked somehow (with an image?), so it's easy to distinguish between them within an article. What do you think? --Roger (talk) 20:09, 23 March 2013 (GMT)

In theory, those that are fixed are being moved to the top or bottom by our editors. I think different editors have been doing different things, so that might be something we need to address at some point. As for confirmed or VN'd, I've toyed with the idea of adding actual {{VN}} tags to the VN'd bugs, as I think there should be some indicator of those that are more iffy. It wouldn't be hard to add something like a check mark or question mark to the display instead, though. – Robin Hood  ^(talk) 21:13, 23 March 2013 (GMT)

Perhaps something like ? this? Jeancey (talk) 21:16, 23 March 2013 (GMT)

I agree with Jeancey's proposal. {{VN}} tags might get unnecessarily long in a list full of bugs. --Roger (talk) 12:07, 24 March 2013 (GMT)

What if we make it superscript too, so it looks sort of like the {{huh}} tag? Or just mimic that template, but replace the link with the hovertext? Vely^►t►e 16:26, 24 March 2013 (GMT)

If we can mark it as Jeancey suggests (the question mark thingy) then I’m all for it. As long as the tag doesn’t ruin line spacing or otherwise disrupts the layout. --Krusty (talk) 16:31, 24 March 2013 (GMT)

* There is a bug with this quest, I think.^?

* There is a bug with this quest, I know!

(edit conflict) Here is an example of the template change. I made it Superscript, per vely's suggestion. Jeancey (talk) 16:33, 24 March 2013 (GMT)

(←) Yeah, seems alright. It'll help figure out what needs testing without having to edit the page first. Silence is Golden^{Break the Silence} 16:34, 24 March 2013 (GMT)

Ok, I added an example of a confirmed bug too. Is there any other possible additions that might mess with the formatting? Jeancey (talk) 16:41, 24 March 2013 (GMT)

I don't see anything out of the ordinary with the confirmed bug. Was there supposed to be? The two other possibilities to consider are fixed bugs (already obvious by the "fixed by" bullet), and when neither vn or confirmed is used, but it's not a fixed bug. Since we've unintentionally developed a three-tier system there, I'd say just leave those unaltered. – Robin Hood  ^(talk) 18:02, 24 March 2013 (GMT)

I was just showing that the hover text wouldn't appear with a confirmed bug, but ONLY with a vn bug. Jeancey (talk) 18:03, 24 March 2013 (GMT)

Only bugs with vn=1 should be affected by this. As for Jeancey's example, I'd also add a space and style the question mark like this for better visibility: ^?. I have previewed it on several pages and it doesn't seem to break the layout. Besides, if it does, it's a simple revert. --Roger (talk) 22:13, 7 April 2013 (GMT)

I would have templated it or just edited my template to show the change. I'm not a fan of the space between the ? and the bug, but I agree, the stylized is better. Jeancey (talk) 07:13, 9 April 2013 (GMT)

Is it "bug" or "Bug"?

I do not know if it matters, but the template examples consistently uses "bug" but it seems most users use "Bug" and even corrects "bug" to "Bug" when they are formatting the bugs on pages. Should the template page reflect the usage? —MortenOSlash (talk) 21:02, 25 March 2013 (GMT)

It doesn't matter. The first letter of a page is autocapitalized. Just like User:jeancey and User:Jeancey both link to by user page. Jeancey (talk) 22:02, 25 March 2013 (GMT)

It seems I have not been very precise: I am not referring to the page title, but the capital letter or not in the usage of the template and the examples on the template page. As I see when "bug" is used it is frequently corrected to "Bug" with capitalised first letter by most users, and the examples used in the template page consistently not uses capitalised first letter. —MortenOSlash (talk) 22:20, 25 March 2013 (GMT)

It is actually the same thing. The page title is technically Template:Bug. The {{ just transcludes the page, and adds the Template namespace by default. Thus, either bug, or Bug will work. No idea why people are capitalizing it when it isn't, aside from consistency. It makes no difference. Jeancey (talk) 22:30, 25 March 2013 (GMT)

Quite simple, then. As long as it is a matter of taste, then consistency is as good reason as any — at least for me. —MortenOSlash (talk) 22:55, 25 March 2013 (GMT)

vn=1 is deprecated?

It's extraordinarily common as a usage. If it's really deprecated, there needs to be a whole lot of editing done out there.

I only use a separate {{vn}} tag when I have to link to a discussion section, as in {{vn|section=vn=1 is deprecated?}} --Morrolan (talk) 00:51, 13 April 2013 (GMT)

It isn't deprecated. And it should still have the vn=1 param if it needs verification, no matter what, because it adds it to a category. Jeancey (talk) 01:02, 13 April 2013 (GMT)

The theory was it was going to be deprecated, but people kept on using it anyway, leaving us with three groupings instead of the intended two. We now have confirmed bugs (confirmed=1), outstanding bugs (nothing), and unconfirmed bugs (vn=1). I've brought up the issue a couple of times, but there's been very little comment one way or another, so it's been allowed to drift. The new question mark on VN'd bugs is probably the most action we've had on the issue since implementing the confirmed parameter. :) – Robin Hood  ^(talk) 02:05, 13 April 2013 (GMT)

Yeah, just as a note, I'd love it if the section code from the vn template made it into the bug template, so we could do stuff like {{Bug|This is awful!|vn=1|section=Discussion of the awful bug}} :) --Morrolan (talk) 14:44, 13 April 2013 (GMT)

That's an interesting idea. Would we want to do it for just the VN or maybe for confirmed ones as well? Sort of like a "Want proof? See this section." If we did that, we'd have to display something linkable for the confirmed bugs as well, whereas if we only do it for the VN'd ones, we've already got the question mark. – Robin Hood  ^(talk) 18:40, 13 April 2013 (GMT)

Eh, I think it would probably normally be used with the vn=1 tags but from what I understand of template coding it would be hard to make it dependent on vn=1, unless we changed vn=1 to vn=section name which would require us to put in some extra code to support all the vn=1 tags out there. --Morrolan (talk) 19:47, 13 April 2013 (GMT)

It's actually easier, the way it's written, to make it vn dependent. Should be implemented now. Gotta go for a few, I'll update the docs later. – Robin Hood  ^(talk) 21:06, 13 April 2013 (GMT)

Thanks :) Here's an example of the new template feature in action: Skyrim:Quest all Beggars Have I'll be going through my contribution history looking for more bugs to recode. --Morrolan (talk) 02:57, 14 April 2013 (GMT)

Outstanding Category

I don't think we need this category anymore, it was mostly used when the template was new, but now we're down to just a handful of Oblivion pages and quite a few Skyrim pages. I think it should be put in the vn category if the template lacks the confirmed tag from now on because if they lack the tag, they still need verified. With everyone having become accustomed to the template even Dragonborn lacks any outstanding bugs now, as well as 10 other categories that are empty and mostly tagged with {{empty category}} when it is highly unlikely that a bug will stay in this category from now on. Also, is it possible to make a capitilised Confirmed work too, there's been a recent proliferation of this hastily changed to decapped, and it also led to a few wrongly categorised pages when left unchanged. Silence is Golden^{Break the Silence} 06:19, 10 January 2014 (GMT)

Confirmed in caps doesn't work? Let me take a look at it. Jeancey (talk) 06:26, 10 January 2014 (GMT)

Okay, that should do it. Let me know if any strange problems crop up. I only fixed it for Confirmed param specifically, so if you want the others too, let me know. Jeancey (talk) 06:32, 10 January 2014 (GMT)

Removed. I know I've brought it up before, but I don't remember there being a lot of feedback on it. Since someone's actively requesting it be removed now, I have. :) – Robin Hood  ^(talk) 07:22, 10 January 2014 (GMT)

Thanks, small issue though, the unconfirmed mark appears on any bug entry not marked confirmed, even those marked by their fixes (e.g. these ones). Silence is Golden^{Break the Silence} 21:00, 10 January 2014 (GMT)

Oops, I'll go fix that. – Robin Hood  ^(talk) 21:22, 10 January 2014 (GMT)

Add official Online patch?

Shouldn't this be extended to cover Online patches now? In order to prevent confusion with Oblivion, maybe "ONP" or "OONP" (or even "ESOP") should be the abbreviation, rather than "OOP". Quantheory (talk) 02:56, 13 May 2014 (GMT)

I was thinking that ESOP made sense, though ONP works too. Whatever works for the most people. If we want, we can even used all three (like MPP and UMP are synonymous), though I tend to think it's less confusing for people if we pick one and stick to it. I'm off for the night, so I've added the coding for ESOP for the moment, but that can be changed if desired. – Robin Hood  ^(talk) 03:34, 13 May 2014 (GMT)

No, there shouldn't be the patch added at all. When a bug is fixed, it can be removed from the page completely. It is impossible to play without the latest patch, you can't even log in, so we don't need to list bugs forever. They can just be deleted. Jeancey (talk) 16:07, 13 May 2014 (GMT)

No need at all, there wasn't even a need to create the categories for them, just confirmed and unconfirmed. Bugs that transcend the game may deserve a more prominent mention somewhere so that they are noted as fixed but there have been no reports of any yet so its unlikely at this point. Silence is Golden^{Break the Silence} 17:45, 13 May 2014 (GMT)

If you can't even log in with an older copy, then I would tend to agree with Jeancey and Silencer. In that event, the only argument I can see in favour of listing them is that in some cases, people may have adapted their play-style to compensate for a bug and may not be aware that it's been fixed. That's probably not a big reason to keep them, though. – Robin Hood  ^(talk) 17:51, 13 May 2014 (GMT)

I disagree, for a few reasons:

• Mentioning a patch disambiguates between bugs that were never listed on the page, and bugs that are known to be fixed. One case where this matters is where it prompts the reader to change strategy or spec (as Robin Hood mentioned). Another case is where a bug is wrongly marked as fixed, but this goes unnoticed for a while, or it comes back in a regression. It may be better to remove the "fixed" tag than to rewrite the description.
• A few bugs end up being interesting historical/cultural curiosities in and of themselves.
• There's little actual harm in keeping the mention of a bug with a fix. (I'm assuming that there will rarely or never be so many fixed bugs on one page that you get unacceptable clutter.)

All that said, I at least agree that the patch version is not that important. You may not be able to verify whether something was fixed in a patch or simply hotfixed anyway, nor does it matter from a practical perspective, since all you care about is whether the bug is still there now.Quantheory (talk) 07:15, 14 May 2014 (GMT)

Handy Links

To mark the platform for the bug: {{pc22}}, {{ps22}} and {{xbox22}}. Hopefully this helps someone. — Unsigned comment by Timeoin (talk • contribs) at 23:38 on 3 October 2017‎

Note, however, that platforms should generally not be marked unless it's known that the bug affects only that platform. In general, bugs on one platform will affect all of them. – Robin Hood  ^(talk) 05:40, 4 October 2017 (UTC)

Thank you. That is a very good point. I had not considered that. Timeoin (talk) 05:46, 4 October 2017 (UTC)

Platform Icons

I noticed on one of the added USSEP bug notices on the Rubbish Retrieval quest that it has a PC icon next to it. That implies that it's only fixed on PC. For the USSEP, it's possible for things to be fixed on up to 3 platforms for the same bug report. Shouldn't that icon be left off by default? Arthmoor (talk) 04:03, 3 July 2023 (UTC)

I think that's just a case of the various unofficial patches being historically PC-only and we just never thought to change it. For now, I've just removed the icon, but I think there's a good argument for having a USSEP-specific icon, if you have anything like that, just to flag that the fix isn't universal. – Robin Hood ^(talk) 19:07, 3 July 2023 (UTC)

In that particular case, it looks like Imperialbattlespire did that. I know I've seen some pages where they have the default name but it's commented out to avoid the red link. It's possible he meant to do that and just didn't notice, or maybe for some other reason? In any event, I can either blank it or comment it out fairly easily. Which one works better for you? – Robin Hood ^(talk) 19:18, 3 July 2023 (UTC)

I was actually referring to what DarthVitrial had added to the quest page for Rubbish Retrieval. It had a PC-only icon on it. USSEP is probably a bit unique in this regard since it's cross-platform unlike the older USLEEP/USKP entries and the older games. All of the previous patches were understood to be PC-only because you couldn't mod on consoles. Now with SSE the possibility does exist for platform specific fixes to exist. I don't know what you did to address this but the icons are gone now so thank you. Arthmoor (talk) 20:09, 3 July 2023 (UTC)

Oops, sorry, I was responding to the wrong thread for the second reply. Just ignore that bit. – Robin Hood ^(talk) 20:22, 3 July 2023 (UTC)

Potential Rewording?

This bug is fixed by the Unofficial Oblivion Patch.

This bug is fixed by version 1.5 of the Unofficial Oblivion Patch.

This issue has been addressed by version 1.5 of the Unofficial Oblivion Patch; paintbrushes no longer have collision.

The wording of this template is in passive voice and front loads less important information. It would read more succinctly to say:

The Unofficial Oblivion Patch fixes this bug.

The Unofficial Oblivion Patch version 1.5 fixes this bug.

The Unofficial Oblivion Patch version 1.5 addresses this issue; paintbrushes no longer have collision.

There's the added advantage of more flexibility with the wording. If you look at how the template works now, there is an internal "preposition" variable that switches for OpenMW.

Since this template is high use, I don't want to change anything unless someone else agrees. —Dillonn241 (talk) 05:19, 17 January 2024 (UTC)

Great changes, I'm all for it. -Dcsg (talk) 06:28, 17 January 2024 (UTC)

Done. I was also able to simplify the template to lose two local variables. —Dillonn241 (talk) 02:44, 18 January 2024 (UTC)

A little late to the table, but that works a lot better. Great idea! – Robin Hood ^(talk) 16:02, 18 January 2024 (UTC)