Template talk:Video game reviews

Edit request 28 March 2025

Description of suggested change:

To add new reviewers for Official Dreamcast Magazine (UK) and Official Dreamcast Magazine (US)

As follows

{ "''[[Official Dreamcast Magazine (UK)]]''", 'ODMUK' },
{ "''[[Official Dreamcast Magazine (US)]]''", 'ODMUS' }

— Preceding unsigned comment added by Coyg (talk • contribs) 06:58, March 28, 2025 (UTC)

Has this been discussed somewhere? If not I would suggest starting a discussion at WP:WPVG. * Pppery * _{it has begun...} 20:18, 22 April 2025 (UTC)

@Coyg: Is there any news? Est. 2021 (talk · contribs) 23:20, 28 April 2025 (UTC)

Mobile dark styles

While looking at a review table in dark mode on my phone, I saw that the Awards section will display the table with a white font on a white background color, which renders it unreadable. The other Aggregate and Individual review tables display properly. Is there an issue with the Award table's CSS? (Guyinblack25 ^talk 03:23, 16 April 2025 (UTC))

Please link to an affected page. When I look at Template:Video game reviews#Multi-platform/column layout in the Vector 2022 dark mode (using the option in the sidebar), I see near-white on #d1dbdf for the Awards header and near-white on black for the body cells in the Awards section. – Jonesey95 (talk) 13:58, 16 April 2025 (UTC)

I saw this in NHL Hockey#Reception and Time Gal#Reception. However, I should specify that this is within the Wikipedia iOS app and not a browser app. Could it be the vgr-awards class? Here's a breakdown of what I'm seeing:

• the text in the caption tag is black and the background is a dark grey
• the text in the TH tags is black and the background is white
• the text in the TD tags is white (unless it's linked then it's blue) and the background is white

Hope it helps. Thanks for looking into this. (Guyinblack25 ^talk 19:43, 16 April 2025 (UTC))

I don't have a way to test this, but it looks like this is almost enough information to report a bug. From what I am reading, the iOS app has at least three settings for the display mode: sepia, dark, and black. Which one of those, if any, do you have selected? Also, are you using the latest version of the iOS app from the Apple app store? – Jonesey95 (talk) 23:38, 16 April 2025 (UTC)

@Jonesey95 CSS and styling isn't my forte, but I think this should be fixed. Even on Desktop, I can see that the formatting for the "Awards" sections differ from "Aggregate Scores" and "Review Scores". I can't imagine any reason one section of the table should be formatted differently, so it should probably just be made to match. -- ferret (talk) 00:25, 17 April 2025 (UTC)

@Jonesey95: Regarding your questions, I am using the latest iOS and the latest version of the Wikipedia app from the App Store. I normally have it set to black, but I just tested it on all four modes: white, sepia, dark and black. Here is what I see:

• Caption - the text remains black while the background color changes with the mode
• TH content - the text is black and the background is a light grey (it looked white to me on the black setting before). This stays the same for all four modes.
• TD content - the background remains light grey for all four modes. The text is black for the two lighter modes and switches to white for the two darker modes (unless it is linked, then it is blue for all four modes).

Hope this helps. (Guyinblack25 ^talk 14:04, 17 April 2025 (UTC))

It does help. Does the sandbox version at User:Jonesey95/sandbox look any better to you? – Jonesey95 (talk) 14:45, 17 April 2025 (UTC)

Unfortunately, the mobile app appears to be optimized for article space. When I navigate to anything in the user or template space, the app opens it via a web browser, which is using different settings. Not sure how else to test it, and I hate to suggest a live test with a template that is so widely used.

Also, I just noticed this. The "Reception" text with the "vgr-title" class remains black on desktop when I switch to dark mode via option sidebar. Oddly enough though, this text's font color switches just fine on the mobile app and in a mobile web browser. (Guyinblack25 ^talk 15:41, 17 April 2025 (UTC))

It sounds like the app is not as useful as just using a browser. I have reported this as T392246. I think the iOS app's dark mode should mirror the Vector 2022 dark mode. We'll see what the developers have to say. – Jonesey95 (talk) 16:55, 17 April 2025 (UTC)

Cool. Thank you very much for your help with this. And to be fair, the app is much better for reading and navigating articles than a mobile browser; editing isn't too bad either. But yes, there is certainly room for improvement. Thanks again. (Guyinblack25 ^talk 19:16, 17 April 2025 (UTC))

Unsupported parameter detection needed

This template would benefit from detection of unsupported parameters like |rev 1= and |rev1score=, both of which are in use at this writing or were recently in use. They currently fail silently with no message to the editor, which is not ideal. Because there are so many possible combinations of supported parameter names, this detection should probably happen in Lua code rather than on the Template page, as would usually be done. The standard category name would be Category:Pages using Video game reviews with unsupported parameters, and should be applied only to pages in article space. I hope that someone has the time and ability to implement this improvement. – Jonesey95 (talk) 21:41, 6 May 2025 (UTC)

@Jonesey95: Thanks. And that problem is because of case sensitivity, so maybe it would be worth changing the manual to more explicitly state that. Another item is that I guess the manual is mistaken, saying that the template only supports 10 custom reviews, but all 11 of them are rendering on Star Wars: Return of the Jedi (video game)#Reception! lol. Should that sentence be deleted from the docs or what? — Smuckola(talk) 00:00, 7 May 2025 (UTC)

I have updated the docs. – Jonesey95 (talk) 03:50, 7 May 2025 (UTC)

Averaging out detail scores

The current instructions state that "If a review scores components of a game separately (but does not give an overall score) e.g Graphics 3/5, Sound 4/5, Gameplay 5/5 etc, add all the components together to reach a single score like 12/15, and add a footnote listing the individual scores."

Similar to how this was discussed with averaging out Famitsu scores, we should not be doing this per WP:STICKTOSOURCE which states " Source material should be carefully summarized or rephrased without changing its meaning or implication. Take care not to go beyond what the sources express or to use them in ways inconsistent with the intention of the source, such as using material out of context. In short, stick to the sources.". By averaging out a score, we are implying that the magazine gave a game an overall rating, which would be false. I would suggest simply removing this statement from the instructions page. Andrzejbanas (talk) 18:37, 12 June 2025 (UTC)

100% agree TarkusAB^talk/contrib 18:03, 7 July 2025 (UTC)

Agree completely, yeah. — ImaginesTigers (talk) 19:36, 7 July 2025 (UTC)

The problem becomes how to show the scores in the review table, because for the older games where this type of scoring was common, we'll run into layout problems with long tables. At least with Famitsu, we have other RS that tell us the summation approach is the most common means of aggregation, but I don't know if that can said for reviews of this scoring style. Masem (t) 20:16, 7 July 2025 (UTC)

Well, the table is not a requirement, it's an aid to collect the scores from prose to summarize for readability. So if the details of a score cannot easily by summarized in the table, then just keep those scores in prose. TarkusAB^talk/contrib 20:45, 7 July 2025 (UTC)

@Masem:. I've taken a stab at this for some older games already. Depending on the scale of the table, I've adjusted them for games like Otogiriso, Donkey Kong Country and Super Mario World. I'd keep in mind that people will be reading this in various formats (i.e: text siE and scale on Wikipedia, on their phones over on a wider computer screen) so it's probably difficult to find one that works for all possibilities. I would just try to apply it as it best fits depending on the scale and scope of the article. Andrzejbanas (talk) 02:52, 9 July 2025 (UTC)

That has some weirdness to it. First, Famitsu in reliable sources is normally suammrized as the sum of the scores, so breaking that apart is weird. But when you compare that format like "10/8/8/8" for one review source and have that next to a "90/100" that looks to me like the "90/100" is two scores, a 90 and a 100. I don't think you can use that same format that way. Masem (t) 04:58, 9 July 2025 (UTC)

Often I hear the argument when we do something new or transitional on wikipedia that it looks "weird". The original source has published it score from four unique reviewers for decades. I did leave a hat note on some sources that explains their rating scheme. Otherwise, it is a transitional period and we can find a best fit.

Combining the material makes us lose the out on key information. For example, Super Mario World reads as 9/10, 9/10, 8/10, 6/10 instead of 32/40. As we're supposed to only use reviews in the infobox with prose (something I rarely see with Famitsu reviews), we lose out on the key detail that one Famitsu reviewer gave the game a relatively lukewarm rating, which has been the only non-overtly enthusiastic review to the game I've found at its release. Currently the set-up for Famitsu in the infobox standards is to not average them out. Andrzejbanas (talk) 12:21, 9 July 2025 (UTC)

I'm not saying to average them but to sum the Famitsu scores because that's how I've seen it most commonly done in reliable sources (with the prose to discuss the breakdown if that was the case).

but for others, its the use of the "/" in one case to distinguish between scores and to represent a x out of y score, that makes it confusing, trying to view this from someone that would not be familiar with how review scores are normally presented. If you have multiple scores without a published overall score, it may be better to do something like "8/10, 9/10, 9/10, 7/10", which at least tells me that there are four different scores, each some portion out of 10, and would make a solitary "90/100" also consistent. Masem (t) 12:41, 9 July 2025 (UTC)

Masem is right that there's an implementation concern IMO. It's not simply that the core idea is unworkable – it's that this way of presenting the information looks confusing when the slash is also used to detonate fractional scores (e.g., 8 out of 10 vs an 8 and a 10). — ImaginesTigers (talk) 12:57, 9 July 2025 (UTC)

I retain my usual stance of indifference in these situations. I don't really see the shuffling around of number values in these instances to be that big of a deal, but I also have no problem with stopping it either. Bigger fish to fry, forest before the trees, etc. Sergecross73 msg me 20:48, 7 July 2025 (UTC)

Edit request 8 July 2025

Description of suggested change:

The "notheme" class (currently at line 232) was a temporary measure, and is no longer necessary. Can we please remove it, which will improve/fix the presentation of the table on mobile apps. Dmitry Brant (talk) 13:51, 8 July 2025 (UTC)

 Completed. P.I. Ellsworth , ed. ^{put'er there} 16:12, 8 July 2025 (UTC)