Template talk:BugNotice
template preview
'bug' is apparently shortcut for an actual language so for the preview of this template on the Template:Bug page {{pagelang}} is giving language as 'bug' instead of 'en'. This is issue only on this template page and not sure what to do with it because the template will work properly anywhere else Nescius (talk) 17:01, 21 July 2024 (PDT)
(tested in: ???)
This breaks so much things. (tested in:ICON) also looks very inappropriate in most cases. It should be optional and should not be displayed if tested= is unused. Please, fix. MyGamepedia (talk) 19:36, 05 September 2024 (PDT)
- If it was optional nobody would use it and it’s good info to have where the bug was encountered. If there are some visual bugs post links here so I can fix that. Some pages like ambient_generic have so many bugs that it’s not very useful anymore. It’s not required to use icons, only text is fine like l4d2, csgo etc. —-Nescius (talk) 09:48, 5 September 2024 (PDT)
- I don't need such thing in pages about ents, shaders, other stuff which is available only in Black Mesa (newLight_Point, env_lensflare, etc), it's already clear that it was tested in Black Mesa game. The same I can say about other games/soft. If I'll add tested= it will look pretty stupid due to the above mentioned reason. —-MyGamepedia (talk) 14:11, 6 September 2024 (PDT)
- You clearly haven't read the documentation and I never said to add bms icon. From Template:BugNotice/doc.
- {{{tested}}} – Provide what game/software was the bug observed in. If this is a bug known to be present everywhere or it's a bug on a page about single game/software you can use {{{hidetested}}} (shortcut for hidetested param use: {{Bug*}}) --Nescius (talk) 04:39, 6 September 2024 (PDT)
- Found this bug today in env_cascade_light page. —-MyGamepedia (talk) 10:40, 8 September 2024 (PDT)
-
- Closing curly brackets were simply put in wrong position. I fixed it. Gameplayer (talk) 01:07, 8 September 2024 (PDT)
- I noted this issue in the documentation Template:BugNotice#Issue. It's problem with all notices but more noticable with this one. The issue was there before adding the tested parameter meaning expand was outside despite being placed inside the bug notice --Nescius (talk) 03:50, 8 September 2024 (PDT)
- It would be nice to come up with something for such cases. Somebody put all the light_environment's bugs in one table to make the page less cluttered, but we can use (tested in:) only for the last bug. —-MyGamepedia (talk) 18:57, 8 September 2024 (PDT)
- I noted this issue in the documentation Template:BugNotice#Issue. It's problem with all notices but more noticable with this one. The issue was there before adding the tested parameter meaning expand was outside despite being placed inside the bug notice --Nescius (talk) 03:50, 8 September 2024 (PDT)
- Closing curly brackets were simply put in wrong position. I fixed it. Gameplayer (talk) 01:07, 8 September 2024 (PDT)
- I don't need such thing in pages about ents, shaders, other stuff which is available only in Black Mesa (newLight_Point, env_lensflare, etc), it's already clear that it was tested in Black Mesa game. The same I can say about other games/soft. If I'll add tested= it will look pretty stupid due to the above mentioned reason. —-MyGamepedia (talk) 14:11, 6 September 2024 (PDT)
tested in suggestion
If i may suggest, "Tested in" only means it has been tested. It doesn't actually mean if the bug has been observed in that game. So it would be in my opinion better to create two OPTIONAL addons, such as "Appears in" and "does not appear in" (or simply "IN" and "Not in")
See the bug on Func_areaportalwindow for example. Looks odd to make it look like that.
And i suggest it to be an optional tag because lets face it, there are bug notices from over a decade that will most likely never get that "Todo" to be done. So there will be endless pages that show this todo, at all times.--MrFunreal (talk) 03:24, 28 October 2024 (PDT)
For such scenario you can use hidetested=1 param and start the notice with for example "In "Actually I see what you mean. The name may be misleading in that sense but it's meant to imply that the bug was observed when tested in the given game. If it's not in some game it's fine to just add something like (not present in whatever). If it were to use param "in" that could imply that it's only in that game which would also be misleading. --Nescius (talk) 06:43, 28 October 2024 (PDT)- We could argue about the actual wording of what these options should be. But in the end, I believe we either have both, or none.
Because why only have one parameter for where the bug is known to be, but not have a parameter for the equally important notice of where the bug does not appear in?
If its fine to just write out in the bug text itself where the bug is not present, we might as well just write out where it is present like we did already.
I just don't understand why we'd go through the effort of making a parameter for only one of the options, with a dubious name that doesn't even mention if the bug actually exists or not. I understand what the parameter means, but its choice of words does not convey the meaning of it.
Hence why i propose the parameters "Bug present in:" and "Bug absent in:"--MrFunreal (talk) 03:05, 6 November 2024 (PST)- The point of the parameter is to make people include the game they found the bug in by having the green "todo tested in" text when the parameter is not specified. If they find a game where the bug doesn't apply they will most likely naturally add it to the text itself --Nescius (talk) 03:41, 6 November 2024 (PST)
- We could argue about the actual wording of what these options should be. But in the end, I believe we either have both, or none.