Template talk:Infobox video game/Archive 14

Archive 10

←

Archive 12

Archive 13

Archive 14

Archive 15

Archive 16

PEGI / ESRB ratings?

Including age and content ratings from some major rating boards would be very useful information for a reader. Using the same symbols the rating boards use is probably informative enough for an infobox. — Preceding unsigned comment added by 88.114.37.11 (talk) 09:11, 7 August 2015 (UTC)

Search the talk page archives above to see why we don't have this – czar 09:19, 7 August 2015 (UTC)

Template-protected edit request on 21 August 2015

Could there be a new field for 'Community' to include community managers? Also sound effects and buisness managers??

Thanks, 37.157.39.26 (talk) 10:08, 21 August 2015 (UTC)

• I've disabled the edit request as per the consensus on this template to discuss before addition.

  Regarding the actual request: Community managers, are they actually notable? Perhaps one or two may be, but I can't see that warranting a field in a template that covers 20,000+ articles. Sound effects, ?? In what way? The effects themselves or the people who make them? Business Managers: Same as community managers, are they really notable and is their enough of them (with reliable coverage) to warrant a field, I doubt it. - X201 (talk) 10:18, 21 August 2015 (UTC)

• No, no, and no. How are any of these positions notable? You almost never even see these roles mentioned in the article itself, even in the well written and expansive ones. Sound effect designers are the only one that could even get close to being included, as the other two are public relations/marketing roles that have no effect on the game's design itself. ~ Dissident93 (talk) 11:16, 21 August 2015 (UTC)
• Agreed with nope. CMs are a dime a dozen for those most part; the others likely to be also. --Izno (talk) 16:08, 21 August 2015 (UTC)

Credit fields under discussion at WT:VG

FYI Wikipedia_talk:WikiProject_Video_games#VG_infobox_credit_field_oversights.3F and elsewhere on the project talk page – czar 04:12, 27 September 2015 (UTC)

Ports and platforms

What's the verdict on specifying Virtual Console, PlayStation Network, XBLA in the infobox? It seems like it's the type of specificity that is best left for prose. (I'm also not 100% clear on when such a port counts as a separate release—the availability of the PS2 Deus Ex: The Conspiracy becomes available on PSN for PS3 so we put it in the infobox with a PS3 release date? Or PSN? Banjo-Kazooie isn't listed as Xbox One game because it's a backwards compatible Xbox 360 game, but does it get listed once the Rare Replay compilation releases? It would be nice to have more explicit guidance in our "Platform" documentation.) – czar 10:42, 13 July 2015 (UTC)

In my opinion, like Salvidrim! said here, the platform field must only have the console/OS the game was developed for, not the platforms where the game is playable. Virtual Console, PlayStation Network, and XBLA are not platforms, but digital distribution services, so they should not appear as platforms. The Rare Replay compilation must have the Xbox One console listed as a platform because the compilation (and most of its games) are currently being developed/ported to the Xbox One.

According to the template guidelines, platforms can be included in the release date field, but there is no documentation about whether distribution services should also be included, so the guidelines need to be updated. Personally, I would only include the very first release date of the game for the sake of simplicity (no localization, no platforms, and no distribution services); Template:Infobox album only includes the original release date and the original record label (you can think of it as a distribution service).

As for the Xbox One backward compatibility, that's a bit complicated because, technically, it is not exactly a backward compatibility, but an emulation. Microsoft just use the term "backward compatibility" as marketing speech. As far as I know, when you insert an Xbox 360 disc into the Xbox One, a "wrapper" for the game is automatically downloaded, but the game itself is not modified. Once the game is wrapped, it can be played using the Xbox One's Xbox 360 virtual machine. That's the reason why the Xbox One does not support every single Xbox 360 game, because Microsoft would need to create a wrapper for every single one. Right now, they are only interested in creating wrappers for their 1st party games. Anyway, I think the Xbox One backward compatibility should not be listed as a platform because it is technically an emulation. --Niwi3 (talk) 09:15, 14 July 2015 (UTC)

Small comment to add, but OnLive is sometimes used in a similar way as well. I've seen it listed as both a platform and within the release dates in a few places. -- ferret (talk) 11:40, 14 July 2015 (UTC)

@Niwi3, is something like the PS3 Deus Ex mentioned above in a PSN wrapper or a separate port for the platform (from PS2)? Are games on the Virtual Console "modified" or aren't they just running in emulation too? Are the older Rare Replay' games actually receiving ports or are they merely running in modified emulation? – czar 18:35, 14 July 2015 (UTC)

@Czar: Sorry for the late reply as I was on holiday earlier this week. Here are the answers to your questions:

A) Deus Ex was not developed/ported for/to the PlayStation 3, so the PlayStation 3 name should be removed from the platform field in the infobox of the game. It was simply released on the PSN as a PlayStation 2 Classic, which is emulated on the PlaySTation 3 system (check this).

B) According to the Wikipedia's Virtual Console article, all Virtual Console titles (exclusing GBA titles on 3DS) run in their original forms through emulation, so they should not appear as platforms in the infobox.

C) We still don't have details about whether the games will be emulated or ported. Some games, like the XBLA versions of Perfect Dark and Banjo-Kazooie, may use the Xbox One's X360 virtual machine because they were originally ported to the X360, but I guess some other games, like Jet Force Gemini or Conker's Bad Fur Day, will be ported to support the Xbox One controller and other Xbox Live features. --Niwi3 (talk) 22:09, 19 July 2015 (UTC)

I will agree that the storefronts are not platforms and should be removed. Onlive is a storefront for "Streaming/Cloud" platform in that manner. I would not list Xbox One BC/emu releases of 360 games in the infobox if all they are is a special wrapper otherwise running the same game, as opposed to a true HD remaster/remake like Amplitude or Shadow of the Colossus. --MASEM (t) 14:27, 14 July 2015 (UTC)

I suppose what I'm really asking here is whether something counts as a port if it's running in emulation. It's one thing to remove "Virtual Console" from the infobox, but then was EarthBound "ported" to the Wii U at all or is it in emulation (a wrapper)? Should "Wii U" not be removed in that case? Alternatively, the original Mother receives its first English release via the Virtual Console and it too might just be in a wrapper, but it constitutes a new "developed for" release. I think the documentation needs clarification. – czar 18:35, 14 July 2015 (UTC)

I think at the very least Mother needs to have its only official English relase acknowledged in the infobox.--67.68.29.1 (talk) 18:44, 18 July 2015 (UTC)

Platforms doc proposal to exclude emulation

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

• If I can get a read of the room, does everyone agree with what Niwi3 said above? If so, I'd propose a documentation change from the following:

The console or operating system the game was released for. Do not abbreviate names in this field as to avoid confusion for readers unfamiliar with the subject.

to:

The unabbreviated console or operating system for which the game was specifically developed. This includes dedicated ports, but not games in emulation or services. E.g.:

Deus Ex was ported specifically for the PlayStation 2, but was emulated on the PlayStation 3

EarthBound was not ported but emulated on the Wii U Virtual Console

Microsoft Windows, not Steam

Xbox 360, not Xbox Live Arcade

Wii U, not Wii U Virtual Console

Open for workshopping. – czar 23:40, 19 July 2015 (UTC)

• I have no problem with this. ~ Dissident93 (talk) 01:03, 20 July 2015 (UTC)
• Comment Based on the example text mentioning Earthbound, what about in a case like Mother? It's release after two decades in English on Wii U Virtual Console is quite a big bit of news, within the scope of that article. (If I'm incorrect in thinking that Mother is emulated, versus ported, disregard) -- ferret (talk) 01:05, 20 July 2015 (UTC)

@Ferret, mentioned this above, but even though Mother is (I believe) on Virtual Console and then likely emulated, it is a confusing exception because it is the first dedicated release/port of the English localization (it was more or less "specifically developed" for the Wii U). – czar 01:45, 20 July 2015 (UTC)

That's a bit complicated. Mother was localized, but not ported or developed for the Wii U. Personally, I would not include the Wii U as a native platform in the infobox. However, if you feel the need to include it, you should add a note. --Niwi3 (talk) 10:50, 20 July 2015 (UTC)

@Niwi3, do you mean add a note in the documentation, or add a footnote in the infobox? I don't feel strongly about including Wii U or not, but the above was my logic based on the proposed change. – czar 16:04, 20 July 2015 (UTC)

I mean a footnote in the infobox. I think adding a non-native platform in the infobox should be fine as long as there is a good reason for it, which should be explained in the footnote. Personally, I wouldn't include the Wii U for the sake of consistency and simplicity. --Niwi3 (talk) 16:41, 20 July 2015 (UTC)

• I support this documentation change. In simpler words, the platform field must only include platforms where the game natively runs. I also think we need to update the documentation of the release date field. --Niwi3 (talk) 10:22, 20 July 2015 (UTC)

• Well done all for biting the bullet on this. Its been the elephant in the room on WP:VG for far too long. One addition I'd like in the above is clarification of streaming service too, i.e do not add Gaikai, OnLive or PlayStation Now as platforms. - X201 (talk) 11:36, 20 July 2015 (UTC)

@X201, would "The original platform, not PlayStation Now or OnLive" work? – czar 16:04, 20 July 2015 (UTC)

• Support But still slightly concerned about certain edge cases like Mother. I'd rather Mother slightly 'suffer' though than other pages continue to do this behavior. I also agree with X201 about streaming platforms. -- ferret (talk) 11:57, 20 July 2015 (UTC)

Question, would this mean we can exclude OnLive? I don't quite understand it, it sounds like it's streaming games off an existing platform? Darkwarriorblake / SEXY ACTION TALK PAGE! 17:59, 20 July 2015 (UTC)

OnLive is not a platform, but a service that allows you to remotely play games. The games actually run on the OnLive servers, which are essentially computers running different versions of OSs like Microsoft Windows. Video games are developed for platforms (Microsoft Windows, NES, PSP, etc.), not online services that grant you access to them. Therefore, OnLive should not be listed as a platform. --Niwi3 (talk) 11:27, 21 July 2015 (UTC)

• Support as long-needed clarifications to the field that is growing increasingly cluttered as games are ported, re-released, emulated, etc. It should only list native platform. When in doubt, I support only listing original platforms (unless it's in active development). Re-release/port information can go into its own section. —  HELLKNOWZ  ▎TALK 18:42, 21 July 2015 (UTC)
• Support Darkwarriorblake / SEXY ACTION TALK PAGE! 18:54, 21 July 2015 (UTC)
• Support - Favre1fan93 (talk) 19:00, 21 July 2015 (UTC)
• Support, and support X201's addendum. If Mother wants to be an exception, that's up to the editor's of that page- there's not a whole lot of games getting 20-years-later releases in a new language. --PresN 00:53, 25 July 2015 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

• Okay, done. Is it worth going further to restrict the infobox to the original release and platforms, as some have mentioned? Wouldn't be my own proposal, but I saw it mentioned a few times. – czar 23:07, 26 July 2015 (UTC)

Alright, this is what I propose: I would personally restrict the release date field so that it only includes the first public, official, release date for each of the platforms the game was developed for. This excludes any kind of localization; if the game was first released in Japan, then the Japanese release date should be the only one present (for that platform). Localization can be explained in the body of the article if it is relevant. Note that this change also excludes release dates on digital distribution services. Some examples:

• Final Fantasy XIII: December 13, 2009 (PS3); March 9, 2010 (X360); October 9, 2014 (PC); April 10, 2015 (iOS & Android)
• Red Dead Redemption: May 18, 2010
• Super Metroid: March 19, 1994
• Deus Ex: June 17, 2000 (PC); July 7, 2000 (Mac OS); March 26, 2002 (PS2)

So basically, in a worst-case scenario, the release date field should have the same number of release dates as platforms listed in the platform field. The same applies to other fields like developer or publisher; Banjo-Kazooie was developed by Rare for the N64 and by 4J Studios for the X360. I'm aware that this is a big change because it would make the Template:Video game release useless (actually, we could edit that template so it had platforms instead of regions). However, it would simplify the infobox a lot and avoid things like this. In my opinion, an infobox should only contain essential information, not a database of all the release dates. Anyway, feel free to agree or disagree. --Niwi3 (talk) 14:04, 27 July 2015 (UTC)

I'm going to have to disagree on that localization part, at least for Japanese games to Western markets, as this is a rather critical piece of data. One can tell when localization is included whether a Japanese game was ever released for the West at a glance, and that helps to set the idea of tone for the article (a Japanese-only release is likely to have less documentation on its development and reception relative to one with a Western release). The release of games in the three primary markets: US/NA, EU, and for Japanese-based games, in Japan, are key data to track. --MASEM (t) 14:26, 27 July 2015 (UTC)

The way I see it: I think we are, and correct me if I'm wrong, the only WikiProject that uses regional release dates in the infobox. Even things like Wikipedia:WikiProject Anime and manga and Ghost in the Shell only use original Japanese release dates in their infobox, ignoring other markets. And while I agree that having regional release dates helps set the tone for the article, the first line in the lead, which should contain the title in its original language, also gives readers an idea of the article. So, why should template:infobox video game be any different? --Niwi3 (talk) 18:25, 27 July 2015 (UTC)

The primary difference that I can think of is that compared to any other field of international commercial publication, there are nearly no technical barriers to anyone accessing a work from a different nation after release (outside of region locks); language and cost of acquiring might be high, but once a film is released in one part of the world, for example, it's considered released all over the world, just maybe not in the preferred language of choice, for example. Video games remain a field that does have hard technical limitations on games published in one area to be playable in others, and not just a limitation of localization or the like. So like a game that is published in Japan without Western release generally is hard to get any English coverage of unless those limitations don't exist (case in point is the Ouendan games, which at the time, the DS did not have region locking on the hardware hence why it gained popularity in the West without a Western release). Thus, an important data point is, primarily, when a Japanese game hits the West. I do note FILM project does suggest additional release dates as deemed important, and I would agree that we could adopt their language for the infobox film to isolate secondary marker release dates primarily to Japan and then to the West (it is rare for there to be importnace on en.wiki of the release of Western games to Japan). --MASEM (t) 15:18, 28 July 2015 (UTC)

Although you raised a fairly good point, I still personally think that having multiple release dates for each platform does more harm than good to the infobox. Just because something is important does not necessarily mean it needs to be included in the infobox; it is also important the fact that some online games like Diablo III have an ongoing development cycle that involves constant updating, yet we don't show that in the infobox with latest release or stable release fields like in Template:Infobox OS or Template:Infobox web browser. We have to find a balance between importance and simplicity here. We could also change the field name to "original release" to avoid confusion. --Niwi3 (talk) 15:16, 29 July 2015 (UTC)

I'm not keen on this "restrict the release date field so that it only includes the first public, official, release date...". with the way release dates happen at the moment, for most games this is akin to saying "Only record the North American release date" - X201 (talk) 14:35, 27 July 2015 (UTC)

• I'll also add for posterity that most reliable sources list release dates by major region (JP/US/EU/AUS) and not just the original release date. Not opposed to the proposal, but wanted to note the reliable source precedent. – czar 04:16, 27 September 2015 (UTC)

Budget field in infobox

I think there should also be a Budget field, like in movie infobox. What are your thoughts? Video game budgets are usually not as widely known as film budgets, but usually are possible to obtain, especially with big productions. --Marcos [Tupungato] (talk) 14:08, 9 October 2015 (UTC)

I'm not so sure. In my experience, video game budgets are quite difficult to obtain, and when information is found, it's usually in the form of expectations or approximations. Most studios aren't particularly willing to openly share their budgets. Besides, I don't think it's important information, anyway; if the budget really is relevant to the development/game itself, it will be mentioned in prose. – Rhain1999 ^{(talk to me)} 14:12, 9 October 2015 (UTC)

Agree here; unlike the film industry where film budgets are readily tracked, game budgets are not. Where it is known, it can be documented in prose. --MASEM (t) 14:28, 9 October 2015 (UTC)

"Previous" and "Next" parameters

Hi guys. I just wanted to pop in and ask what you guys think of adding "previous" and "next" parameters for use on video games that are part of a series, like the FIFA series, the Halo series or the Call of Duty series. I think it would be a good idea and make navigating between video games in a series a bit easier/convenient, or make it easier for someone to know which game was the previous/next title in the series. Davykamanzi → talk • contribs • alter ego 20:38, 15 October 2015 (UTC)

It's been a perennial idea here, and a problem to include because while it's clean for some series like FIFA, when you get into some series such as Halo, should "previous" or "next" be based on the game's release or on the chronology of the games (eg where you do put Halo Wars relative to the #d titles)? And then you will get into issues when you have main titles and then the offshoots that may or may not be part of the main game's story. It's a mess waiting to happen to include it. Instead, we recommend that you use navboxes at the bottom of the article, and if there's a need to discuss previous or following works, that can be included in prose. --MASEM (t) 20:55, 15 October 2015 (UTC)

Why wouldn't it just be chronologically based, like albums are handled? But I don't think it should be added anyway, since any notable game series is going to have a template that's better fit for this sort of thing. ~ Dissident93 (talk) 21:24, 15 October 2015 (UTC)

Likely because unlike a musical group which generally work on one album at a time, so a chronological order of their albums as released makes sense, video game series may have multiple titles in the works developed by different studies, and featuring different aspects of the franchise (eg Halo Wars compared to the numbered Halo games). And while you can absolutely go by release dates, we will have editors complaining that an offshoot title is listed "next" after a main title instead of the next main title, for example. Because of this naunce, we should keep to clear navboxes that make it easy to navigate this. --MASEM (t) 22:44, 15 October 2015 (UTC)

Yeah, I meant the original release date would be the only factor that would matter, but it's still not a good addition to the infobox regardless. ~ Dissident93 (talk) 23:47, 15 October 2015 (UTC)

Question on downloadable Wii games on Wii U

Just for the curiosity, the "platforms" field says that it should not include platforms for games in emulation – like the Virtual Console games, or PlayStation games emulated on PlayStation 3. While the Wii U is backward compatable with physical Wii games, there are also Wii games – like Super Mario Galaxy and Metroid Prime: Trilogy – that are downloadable through the eShop and are not ported to the Wii U. Does downloadable Wii games via eShop count as emulation, as far as the "platforms" field is concerned? Just wondering. -- Hounder4 19:54, 24 October 2015 (UTC)

Pretty sure they do, but I can see an exception being made for them. ~ Dissident93 (talk) 22:02, 24 October 2015 (UTC)

Those games were not released for the Wii U—they are available in emulation, so we wouldn't include them in the infobox. Feel free to note their Wii U compatibility in their Development sections, though. czar 04:36, 25 October 2015 (UTC)

Ratings

{{Infobox video game Ratings = Teen, ESRB=RG, Mature 17+ }} --— Preceding unsigned comment added by 201.69.149.11 (talk) 18:10, 18 November 2015 (UTC)

Your post is a little vague. This parameter was removed and I doubt it will be re-added to the template. --The1337gamer (talk) 20:18, 18 November 2015 (UTC)

Regional release dates by publisher?

If you read the details under release dates, it says that only those of English regions (hereby North America, Australia, Europe, United Kingom, etc.) and the developer's region, each if available. But in some cases, e.g. games published by Square Enix (Japanese) and developed by another, other-national studio (e.g. Crystal Dynamics from the United States, for the Tomb Raider series) sometimes get released earlier in Japan than in other regions. Note that, on some Tomb Raider games, the Japanese release is even noted down against the conventions of this template. Therefore I think it might be a clever step to correct it to non-English game releases defineable by developer's and publisher's region. Lordtobi (✉) 11:49, 31 December 2015 (UTC)

Publisher is inconsequential. Japanese dates should only be listed if the developer is Japanese, otherwise the date is irrelevant to the audience of this wiki. Darkwarriorblake / SEXY ACTION TALK PAGE! 16:10, 31 December 2015 (UTC)

Agree with Darkwarriorblake, current instructions are fine. Note that lots of infoboxes are out of line with instructions, should just fix as you find. (I've corrected one of the Tomb Raiders.) -- ferret (talk) 16:30, 31 December 2015 (UTC)

Self-publishing and publisher field

Jungle Rumble
Developer(s)	Disco Pixel
Designer(s)	Trevor Stricker
Artist(s)	Luigi Guatieri
Composer(s)	Richard Gould
Engine	Unity
Platform(s)	iOS, Android, PlayStation Vita
Genre(s)	rhythm game, real-time strategy, puzzle

Geneforge
Developer(s)	Spiderweb Software
Publisher(s)	Spiderweb Software
Designer(s)	Jeff Vogel
Programmer(s)	Jeff Vogel
Artist(s)	Andrew Hunter
Series	Geneforge
Platform(s)	Mac OS, Microsoft Windows
Release	Mac OS NA: December 12, 2001 Microsoft Windows NA: March 19, 2002 (Online) NA: November 3, 2011 (Steam)
Genre(s)	Role-playing
Mode(s)	Single-player

Jazzpunk
Developer(s)	Necrophone Games
Publisher(s)	Adult Swim Games
Engine	Unity
Platform(s)	Microsoft Windows, OS X, Linux, PlayStation 4
Release	WW: February 7, 2014
Genre(s)	Adventure, Art game
Mode(s)	Single-player

Should we include the |publisher= field when the |developer= is the same as the publisher, in other words, the game is self-published? Is there any other way we need to signify self-publishing? —  HELLKNOWZ  ▎TALK 13:11, 19 December 2015 (UTC)

Examples for the simple scenarios: Jungle Rumble (self-published developer only); Geneforge (self-published both fields); Jazzpunk (different publisher)

• Once. It's redundant to list the same entity twice, because it is implied the game is self-published if we omit the publisher. Same way, the distributor field currently works -- if omitted, the game is distributed by the publisher. If there were other lesser-role fields, this would be similar - marketing, testing, etc. Publisher is only significant if there is one. To me, it's extra information that doesn't add anything. Notable publisher relations or lack thereof would be discussed in prose anyway. I've personally always removed such double-entries (and was prompted to ask this after a recent removal), but I can't find it discussed before. I assumed it was common practice, but there's quite a few games that list both, so I'm not so sure anymore. —  HELLKNOWZ  ▎TALK 13:29, 19 December 2015 (UTC)
• Only include once per Hellknowz, though I think the publisher is important and should be included in the infobox if it is different from the developer. Most games are published by a different entity than the developer so I think it is implicit that a game without a listed publisher is self-published. It is rare where we know the developer and do not have any name of a publisher since this is usually given on the catalog page of whatever storefront is selling the title. --MASEM (t) 15:39, 19 December 2015 (UTC)
• Disagree - I think the template looks empty/incomplete when we don't list the publisher for these types of cases. Would all first party Nintendo games would just omit Nintendo as a publisher? Maybe this works for indie titles, but for AAA type games? ~ Dissident93 (talk) 20:18, 19 December 2015 (UTC)
• Disagree - I agree with what Dissident93 said, the template does look somewhat empty without it. Furthermore, if you have different publisher for just one platform (e.g. Microsoft Game Studios often publishes indie games for the Xbox Live Arcade), it would seem weird that the game "only has one publisher for one platform". On top of that, there is the officiallity of things, most developers that self-publish their game give away that they do explicitly say that they published their game, while others (e.g. Team Meat) don't. Lordtobi (✉) 08:53, 20 December 2015 (UTC)
• Disagree: I don't think we need to imply the game is being self-published if we can simply make it obvious by listing them in the publisher field. AdrianGamer (talk) 09:16, 20 December 2015 (UTC)
• Disagree: As others have said. --The1337gamer (talk) 11:40, 28 December 2015 (UTC)
• @Hellknowz, maybe some examples would be in order? czar 17:41, 31 December 2015 (UTC)
  • Sure thing, included examples for the simple case scenarios above. —  HELLKNOWZ  ▎TALK 20:03, 31 December 2015 (UTC)
    • As far as I am concerned, most self-published games list the developer as publisher as well. In the example of Jungle Rumble given, there were lots of other issues that have now been resolved by me on its article. In fact, all three infoboxes have minor to major issues. Lordtobi (✉) 02:57, 1 January 2016 (UTC)

Infobox scope re: release dates

WT:VG#Release_date_reform czar 01:11, 24 December 2015 (UTC)

WT:VG#Release_date_proposal czar 04:47, 3 January 2016 (UTC)

Regional publishers

We don't list release dates for non-English speaking regions, so is there a point listing regional publishers? For example, Bandai Namco Entertainment publishing Just Cause 3 in Korea or E-Frontier publishing The Witcher in Japan do not sound like something readers want to know, especially when we already neglect the game's Korean/Japanese release date. Should an additional guideline "Add publishers for English-language regions and the developer's region." be added? AdrianGamer (talk) 11:28, 28 December 2015 (UTC)

Agree - In my opinion, we should either allow regionality outside the developer's region and English regions, or cut it entirely. Additionally, I've seen ocasions {{efn}}'s in-use to note down additional publishers, though I am not sure if that is thought through. Lordtobi (✉) 11:36, 28 December 2015 (UTC)

(edit conflict) I think we should us the same convention that is used for release dates. English-language regions and the developer's region. Unless it is notable, listing publishers for regions which we don't include release dates for seems inconsistent. --The1337gamer (talk) 11:38, 28 December 2015 (UTC)

Publishers in general are 'barely' consequential as they are, they either provided some money or in some cases harvested up the products of someone else like some digital vulture. So itemised publishers by region is definitely not something that should be happening. Darkwarriorblake / SEXY ACTION TALK PAGE! 11:56, 28 December 2015 (UTC)

Agree - Use the same instructions as release date. English-language regions and developer's region. -- ferret (talk) 17:13, 28 December 2015 (UTC)

Agree - Pretty sure this is what was intended with the recent change anyway. ~ Dissident93 (talk) 21:17, 28 December 2015 (UTC)

Question - Not sure, but maybe the same should be applied to regional distributors? Lordtobi (✉) 16:13, 31 December 2015 (UTC)

Agree - Agreeing with my own question since there aren't any other participants with their opinion. Lordtobi (✉) 22:47, 1 January 2016 (UTC)

It should apply to every value in the infobox, don't see why we'd make an exception. ~ Dissident93 (talk) 00:29, 2 January 2016 (UTC)

Distributor parameter should just be scrapped imo. Not really sure why it is there in the first place. --The1337gamer (talk) 01:31, 2 January 2016 (UTC)

I wouldn't be against that. If the distributor is notable, it could just go in the article body. ~ Dissident93 (talk) 22:28, 2 January 2016 (UTC)

developer

The popular name or names of the game developers. This field is for the game development company (e.g., Nintendo) or, if confirmed by primary sources, the name of the team that developed the game (e.g., Nintendo EAD). In the case of a game made entirely by one person, use the designer field instead. The names can be wikilinked. Individual development tasks handled by different companies (e.g., scenario, programming) and ports should not be mentioned in the infobox but in the article text instead.

publisher

The popular name or names of the video game publishers. The names can be wikilinked. Use the {{video game release}} template for regional publishers. If there are many publishers or if the list grows too long, use the {{Collapsible list}} template, fill the field title= with the primary publisher, and also include the field titlestyle=font-weight:normal;font-size:inherit;background:transparent;text-align:left.

• Our guidance for these fields is borderline ridiculous. Why are we saying to use sub-teams if we can verify in a primary source? If a secondary source doesn't say the sub-team made the game, it is less useful for our readers to say it was made by Ubisoft Montréal or Nintendo EAD1 because everything else will say the game was made by Ubisoft or Nintendo. But, to the question, rather than making regional stipulations, should we not just be using the primary dev and publisher, regardless of the regional releases? And if the publishers are weighted exactly the same (and they rarely are), then you can get in the weeds of {{collapsible list}} on the article's talk page? There's really no need to list anyone but the primary dev/pub in the infobox—this is supposed to be easy access, not a list of everyone who participated in the game. That's supposed to be in prose. czar 01:03, 2 January 2016 (UTC)
  • Off topic, but I've tried multiple times to get community consensus on a re-write of the entire infobox guidelines, but they eventually go nowhere. ~ Dissident93 (talk) 22:27, 2 January 2016 (UTC)

    One section at a time is the best way to get consensus—everything at once is too much to consider czar 04:48, 3 January 2016 (UTC)

Announced platforms

In a recent change yesterday I was clarifying in the platforms= field, that officially announced platforms should be inserted if they are not officiall canceled. This edit was reverted, however, by Czar, so I put it up for discussion. Lordtobi (✉) 11:07, 2 January 2016 (UTC)

Really there are two categories here, games pre-initial-release, and games post-initial-release. For games in pre-release, every announced platform should be included in the platform section because all the information on the page is future tensed. For games that have already had a release on one platform it does not make sense to add further platforms if they have only been announced not released. There is a section for release date for future releases of games, and the new to-be-released platform should be listed there. This also cleans up google searches where google aggregates data into the result set making it look like unreleased platforms are fully supported. Arwineap (talk) 15:54, 2 January 2016 (UTC)

That still doesn't change the fact that the platforms were announced and are coming soon. (The Linux/Mac ports are supposed to release before the Xbox One version in February, according to Psyonix) I don't think this has ever been an issue in the past, and highly doubt you will get anybody here to agree with you. Using this same logic, should we not include any yet to be released games/films/albums because they aren't available yet? ~ Dissident93 (talk) 22:20, 2 January 2016 (UTC)

Adding to Dissident93, if this logic would be a real thing, and a game is announced for 4 platforms (e.g. Win/Mac/Lin and PS4) pre-release and is likewise presented on the Wikipedia article; then, one day, it releases for the 3 PC platforms with the PS4 version scheduled for just a week later, should we remove the PS4 reference for a week just because it was not released yet? I don't believe that anyone will say anything against the inclusion of this clarification. Lordtobi (✉) 22:35, 2 January 2016 (UTC)

@Czar: I would like to hear your opinion on this, as you are the one who reverted the edit. Lordtobi (✉) 13:19, 3 January 2016 (UTC)

I don't see this as an edge issue in need of explication. Even when the whole game is in pre-release, we still put the platform in the infobox as long as it's in development. (Also any change greater than a comma replacement or something similarly uncontroversially minor should not be marked as a minor edit.) czar 17:18, 3 January 2016 (UTC)

Well, it is not for most people, but due to the ongoing issue with Arwineap's opinion about that topic, I wanted to clarify that so we have unmasked facts for them to understand. Lordtobi (✉) 17:24, 3 January 2016 (UTC)

Is it agreed that it's misleading to casual readers, both in the platform section and in google results (which aggregate infoboxes), when it states that OSX as a platform despite being unable to be run on OSX? Given both the common definition of platform, and the one linked to by the infobox. Arwineap (talk) 18:51, 3 January 2016 (UTC)

Czar is an experienced user and I agree with him, that it is, apart from correct, common sense. And that is the issue: Because it is common sense, Czar does not feel the itch to get it stated explicitly, which is the reason you disagree with what we, a group of three, are trying to bring to your attention. Lordtobi (✉) 18:56, 3 January 2016 (UTC)

The distinction between the platforms for which the game has been released and those that are still in development should be clear by both the release date section of the infobox or/and the lede. The platform= field is meant as a quick overview of what the target platforms the game was/is planned for. --MASEM (t) 18:00, 7 January 2016 (UTC)

@Masem: Now that this discussion seems to have closed, would you be so greatful to implement it as third-party? Thanks. Lordtobi (✉) 16:32, 18 January 2016 (UTC)

Template-protected edit request on 18 January 2016

"Platforms" should be changed to "Platform(s)" as there are also instances with only one platform they are available on. Lordtobi (✉) 16:30, 18 January 2016 (UTC)

Done [1] Seems like a straight-forward non-controversial change to match the other fields and the actual use by video games, i.e. some have only one, some have multiple. —  HELLKNOWZ  ▎TALK 16:51, 18 January 2016 (UTC)

Template-protected edit request on 25 January 2016

Per the previous regional publisher discussion, an extra line "add publishers for English-language regions and the developer's region" should be added to the Syntax guide in the part about publishers. AdrianGamer (talk) 10:58, 25 January 2016 (UTC)

Per the same discussion, the same guideline applies to distributors. Lordtobi (✉) 10:59, 25 January 2016 (UTC)

Not done: {{edit template-protected}} is usually not required for edits to the documentation, categories, or interlanguage links of templates using a documentation subpage. Use the 'edit' link at the top of the green "Template documentation" box to edit the documentation subpage. - Template:Infobox video game/doc isn't protected. Bazj (talk) 13:49, 25 January 2016 (UTC)

Nor is Template:Infobox video game/doc/syntax guide protected, the to-be-edited page. --Izno (talk) 14:01, 25 January 2016 (UTC)

Digital distributors

What is not explicitly stated in the documentation, is whether or not to include digital distributors. If would have to do so, we would have to add Valve Corporation (for Steam), GOG Limited / CD Projekt (for GOG.com), Humble Bundle, Bad Juju Games (for Desura), etc. for those games that were released digitally, which, in my opinion, makes little sense. What makes sense however, is to add retail distributors, such as Koch Media, are only there once, or once per region and take up little space as well as being good to read. Opinions? Lordtobi (✉) 15:00, 25 January 2016 (UTC)

Honestly? Distributor field is practically useless to begin with and we should consider just removing it. It's very very rarely sourcable and I can't recall EVER seeing it mentioned in prose. Almost every article omits it or has the placeholder about "Only use if different from publisher". Especially with the explosion in digital distribution and games being available from dozens of sites, this field just doesn't really make sense. -- ferret (talk) 15:04, 25 January 2016 (UTC)

Prime example of a valid use of distributor for physical copies is at Rock Band 3, where MTV Games were the publisher while EA was the distributor. 90% of the time, you're right that it is the publisher that is the distributor, but there are excepts where it should be used. It definitely shouldn't be used for digital distribution (I have yet to hear of such a case where the digital publisher didn't act as distributor to storefronts). --MASEM (t) 15:09, 25 January 2016 (UTC)

In other words, should we clearly state the field is for physical distributors? (Storefronts and retailers is definitely not what this is for. The term doesn't even apply to digital. It's supposed to be the 3rd party that gets the game from dev/publisher to the retailer.) —  HELLKNOWZ  ▎TALK 15:17, 25 January 2016 (UTC)

I would agree that if it is used it is pretty much only going to be physical distributors. I cannot envision where there would be an exclusive digital distributor that is not also acting as publisher for a title. --MASEM (t) 15:26, 25 January 2016 (UTC)

I agree with ferret, and don't really think these are needed anymore. Any notable distributors (the Rock Band games) can just be mentioned in prose instead. ~ Dissident93 (talk) 22:05, 25 January 2016 (UTC)

Agreed, but to deprecate a field, I believe we need a larger consensus (?). As long as that is, saying physical only might be a temporary solution. Lordtobi (✉) 22:09, 25 January 2016 (UTC)

I don't think we should remove it, because older physical games had those. It's the ones past the digital distribution age that don't. —  HELLKNOWZ  ▎TALK 23:08, 25 January 2016 (UTC)

True, but aslo newerver games like Goat Simulator have physical distributors. Koch Media in Europe, in this case. So I believe we should just note that physical-only? Lordtobi (✉) 23:10, 25 January 2016 (UTC)

It should be kept, not deprecated, but definitely noted that with rare exception (one that I can't think of but don't want to paint into a corner) that this is limited to physical-only distributors and never for electronic/digital ones. And it should only be filled in if the distributor is not the same as the publisher. --MASEM (t) 00:55, 26 January 2016 (UTC)

• I'm for deprecating the field as of now. (I think this stuff is always worth revisiting when it's more often used incorrectly than correctly.) I'd also be interested in a listing of the ways in which it's currently used, if someone wants to make a maintenance category. I'd like to see what their sources say about the importance of the distributor. czar 04:58, 26 January 2016 (UTC)

• Just as an example of where the distributor field is important: Song of the Deep , just announced today, will be digitally distributed by Insomniac Games (the devs and publishers for all purposes), but have physical copies that will distributed by GameSpot. [2]. So the field needs to stay, but again, limited to physical distribution only and only if different from the publisher. --MASEM (t) 19:57, 28 January 2016 (UTC)

I agree with you, but I'm not that good at phrasing things, could you make and example sentence how you would implement the physical-only guideline and put it up for consensus? Lordtobi (✉) 20:02, 28 January 2016 (UTC)

Because I think there's generally consensus to limit the use of this field, I've been bold and made the change directly to the doc for this. [3]. We can work from there if that's a problem. --MASEM (t) 20:10, 28 January 2016 (UTC)

As I've hit this situation twice this week, we need clarification here on the specific case of a game that is mostly considered as a digital release but where there is a partner that is not the developer that is handling, in addition, the physical release of the game. (The two cases are Song of the Deep and Superhot). While putting the physical distributor in the distribution field with "retail" makes sense, I think this sorta belies the fact that in both of these cases, this company's role is only to make physical products and distribute them; their name will not be attached with the online distribution. In both cases, I feel that the physical distributor should be in the "distributor" and not within "publisher", as we've come to define these above. --MASEM (t) 18:57, 1 February 2016 (UTC)

That depends. For example Goat Simulator was published to retail by Coffe Stain Studios themselves, but distributed by Koch Media, while Terraria was published into retail by Headup Games (different company than developer) and distributed by yet another company, Merge Games. As of Superhot (since I reverted the edit), IMGN.PRO is only stated to be the publisher for boxed versions, there is no statement on the given Gamastura article about the distribution comany, although it is likely to be IMGN.PRO themselves. Summing up, we cannot say that if a company "only publishes physically", it should only fill the distributor field, rather the opposite "only use distributor field if different from publisher." Lordtobi (✉) 19:06, 1 February 2016 (UTC)

That I can appreciate, and then with Song of the Deep, Gamestop is publishing and distributing (within their stores) that game, though hands off the electronic side. So in these cases, the publisher of retail should be mentioned separately as the "(retail)" version, and because it is implicit that the distributor is the same as the publisher for physical media, the distributor should be left empty. Only for cases like Goat Sim (where Koch is only taking the role of distributor for Coffee Stain) or with Rock Band 3 where EA took the role of distributor for MTV Games (when it was still that case), that's when "distributor" should be used. I'm going to add some examples to the docs to be clear for that. --MASEM (t) 21:58, 1 February 2016 (UTC)

Since when does GameStop have the ability to mass-press disks? ~ Dissident93 (talk) 22:16, 1 February 2016 (UTC)

I don't know, but it's also not something in Insomniac's house either (they've always used Sony or a big publisher too). But clearly physical disks are happening, with Gamestop being the side taking the cost of their physical production up. They could easily going to a third-party mass printer for this. --MASEM (t) 23:07, 1 February 2016 (UTC)

Developer field definition

The developer field documentation says "In the case of a game made entirely by one person, use the designer field instead." but in my opinion, this is rather nonsense considering games like Duck Game, developed by Landon Podbielski (a person), but published by Adult Swim Games. If this line was reasonable, the infobox would have to have a publisher, but no developer, since Podbielski would be in the designer field only. Another example is Ronin, where only one person (Waclawek) is credited as developer, although he had another artist and another composer. For me, it would make more sense to leave out the credits completely, if there was no outsourcing, and instead fill the developer field with, well, the developer. Opinions? Lordtobi (✉) 01:26, 23 January 2016 (UTC)

@Lordtobi, feel free to use discretion. These are guidelines, not law. The idea here is to keep infobox entry links notable (and thus to omit shell company names when the dev's personal name will suffice). If that isn't the case for that one game, do what's right and develop local consensus. czar 03:45, 23 January 2016 (UTC)

@Czar: It is true that a local guideline per-article makes sense for the examples stated above, but why develop a local cencensus for every article with that kind of style, if current or future. The only way the current guideline would make sense, is if the person is credited with his name (and not a pseudonym), did not perform outsourcing, and published the game themselves. This is why I am for a general change. Lordtobi (✉) 13:42, 23 January 2016 (UTC)

I find the above rationale by Tobi agreeable. I don't think an acceptable solution is "develop local consensus" when we have decided to have a general statement regarding what we believe is consensus. Speaking of which, who wants to go archive-diving to see if the statement actually has an active consensus? --Izno (talk) 15:57, 23 January 2016 (UTC)

I guess there's three issues here. 1) Video game designer is not video game developer. Design is the discipline of design, which does not include programming, art, audio, testing, etc. It is incorrect to call a one person developer "designer", because that implies they didn't do anything else. So one-person team is the developer. 2) When there are multiple key people, no one person is the developer, so we either use the team/company name or omit if there is none. Non-notable entries are fine, because developer's name is a key fact. 3) Developer field should not include multiple people, as it is not the credit field. It is the entity (company, studio, team, person) who developed the game. So additional names and values are only for the special cases with different versions, ports, etc. —  HELLKNOWZ  ▎TALK 16:23, 23 January 2016 (UTC)

@Hellknowz: I definetly agree on 1) as it supports my thesis, but I'd like to get an example to 2) & 3) (they are kind of one point anyway). There is Spirits of Xanadu, which released in 2015 and published by Night Dive Studios. The *developer* was credited to Allen Trivette and Lee Williams, although the game was made by 6 people, of which 4 were outsourced (artists and composer). So if it had a Wikipedia article, how could you define in the infobox that the main persons are Trivette and Williams, if you have to leave out the developer field as they are multiple people? It was recredited to "Good Morning, Command" sometime after. A similar problem which is more likely to support your 2)/3) is "Else Heart.Break()", which was made by "Erik Svedäng, El Huervo / Niklas Åkerblad, Tobias Sjögren, Oscar "Ratvader" Rydelius, and Johannes Gotlén", but with no actual group name defined AFAIK. This would definetly be a case to leave out the developer field. Lordtobi (✉) 16:37, 23 January 2016 (UTC)

Infoboxes are useful, because they are consistent. I think if the developer (other than one person) doesn't have a name, then the field should be left empty. We shouldn't fill it with something else. If a reader is looking for the developer name, they shouldn't see something else for whatever (good or bad) reason. Infobox isn't the main content anyway, that's prose. We would describe any such scenarios in prose, telling who did what and such. If we list individual people, we are side-stepping the consensus of role fields. —  HELLKNOWZ  ▎TALK 17:05, 23 January 2016 (UTC)

So, regarding your previous satements, we should change the line to "significant developer only (e.g. Scott Cawthon)" or similar? And "multiple significant developer without specified group should be put into their respective credit fields"? Lordtobi (✉) 17:09, 23 January 2016 (UTC)

I would say for |developer= something like, "If the developer doesn't have a separate name, only include a person's name if they are the sole author of the game, otherwise omit." That's already an exceptional case. I only support this because here the developer is synonymous with the author. But role fields as before -- they are not exhaustive credits, only primary key roles per previous consensus. When multiple people have a key role, neither has a key role, so to speak. —  HELLKNOWZ  ▎TALK 17:34, 23 January 2016 (UTC)

Makes sense, but I may just reissue Ronin, where Waclawek is credited as developer, programmer and designer, but other people did arts and music. Should that be the issue of a local consensus, or...? Lordtobi (✉) 17:48, 23 January 2016 (UTC)

I wouldn't put Wacławek as developer because he was clearly not the sole author, regardless of the amount of contribution. I don't think local consensus would need to override anything. I've seen this kind of case around before with small teams, but I haven't ever touched it. It was never a big issue and wasn't formalized in any way. And I don't know what others think about this. —  HELLKNOWZ  ▎TALK 18:24, 23 January 2016 (UTC)

Well, he wasn't put there because he made the most work, but because he is the officially credited "developer". Lordtobi (✉) 18:52, 23 January 2016 (UTC)

Well, if reliable sources say so. —  HELLKNOWZ  ▎TALK 20:23, 23 January 2016 (UTC)

Ok, good, could you make a clear sentence out of "it is ok if no other" "else credit" etc., post it here for a final check and then bring it to the documentation? Thanks. Lordtobi (✉) 20:30, 23 January 2016 (UTC)

I would first phrase clearly the proposed change and wait for input for a reasonable (week+) amount of time, then allow an independent party to close the discussion before we modify documentation for one of the primary fields in the infobox. I haven't even checked the archives as Izno notes. —  HELLKNOWZ  ▎TALK 20:39, 23 January 2016 (UTC)

It has been three weeks and no counter-argument has been said. Could you implement it? Lordtobi (✉) 08:52, 14 February 2016 (UTC)

I don't think that we should put individual people into the developer and publisher fields, no matter the case. The current guideline is fine, and like Hellknowz said, a video game designer is not a video game developer. And what's wrong with having a publisher field, but not a developer? That's exactly what the designer field is for. ~ Dissident93 (talk) 11:32, 14 February 2016 (UTC)

Exactly, Hellknowz said that designers are not necessarily developers, but what if e.g. Scott Cawthon for FNaF, also was the artist, the composer, the programmer, and, logically, the designer? If we only fill the designer field, nobody knows that other people could be involved, but filling all credit fields looks bad as well. Then, if I bring up the Ronin case again, where T. Waclawek is credited the developer, but had outsourced art and audio. Nehter the less, Waclawek was designer, programmer, minor artist, director. I'd like to quote Hellknowz on what you, Dissident93, seem to have gotten wrong "Video game designer is not video game developer. [...] It is incorrect to call a one person developer "designer", because that implies they didn't do anything else. So one-person team is the developer." Lordtobi (✉) 11:48, 14 February 2016 (UTC)

But that doesn't mean we have to add him to the publisher field as well. Cawthon uploaded the game to Steam, that doesn't make him the "publisher" even if he was the "developer". I suppose it's fine in this case where one guy did an entire game (which is really rare), but they should never be considered the publisher as well. ~ Dissident93 (talk) 23:01, 14 February 2016 (UTC)

where is the website field in this template?

Mountains of templates have a "website" field, but it's missing from this template in 2015, amazing! • Sbmeirow • Talk • 12:42, 27 November 2015 (UTC)

• I think most recent request was here. Video game website rarely have useful information beyond promotional material, especially in 2015. Before release it is usually fully promotional, after release it is primarily promotional, soon after video games websites just close, change to new versions, or redirect to company, which makes them useless for preservation. In other words, video game website external links are not encyclopedic. Not to mention localization, region-specific ones, etc. If there is valid information (usually indie games), it can be included in external links section (where links to game's wikis and such go). In addition, this infobox is already bursting with fields and consensus that we limit new fields to really defining ones (we've only recently cleaned it out). I also can't see website as being a defining property of most game, especially when so many games don't have one or it is near-useless content-wise. (I understand same can be said for something like {{infobox software}}, but I would have applied same arguments there.) —  HELLKNOWZ  ▎TALK 15:22, 27 November 2015 (UTC)

Agreed czar 15:43, 27 November 2015 (UTC)

LOL, this infobox isn't bursting when compared to other larger infoboxes on Wikipedia, so quit using it as a reason. Link rot is a problem for everything on Wikipedia, so that isn't a unique reason to not include it either. Manufacturers mess up links for all types of products, so that isn't a unique reason for games. • Sbmeirow • Talk • 18:49, 27 November 2015 (UTC)

How about WP:EL, which those other templates are questionably in violation of? Watch your tone. :) --Izno (talk) 19:08, 27 November 2015 (UTC)

Hello, I agree with Sbmeirow - Why isn't the website field available for use? This is literally going against comments I see in every single archived talk page regarding the video game infobox. The external links section is not a suitable replacement as, you may have noticed, Google/Bing doesn't populate knowledge graph data with info from the external links section - it uses most of the information coming from the infobox. I realize that some people don't want the website field to be allowed in video game infobox for fear of spammy use but I find it funny that the czar won't entertain the idea even though many, many people are asking for this change. Why not let the user decide what is relevant to click through to or not? Regards, Nbdwebdev (talk) 19:48, 12 February 2016 (UTC)

Because video game websites come and go as the publisher/developer moves on to other projects. There might be some that stay around, but there's many games that were released 2-3 years ago with now-defunct websites. The industry is far too flexible in how things happen that makes a website link unstable, which is the last thing that should be in an infobox. As an EL, that's different, as if it goes dead, it can be removed, or potentially retrieved by archive.org. --MASEM (t) 20:05, 12 February 2016 (UTC)

Yeah, I can see what you're saying. Although if a website ends up dead why can't editors just exclude this information (website field) from the infobox? I'm sure there are good reasons to not utilize the website parameter from the vg infobox however I feel the benefits of including the website parameter outweigh the ifs and thens of the arguments I've read in this talk as well as the archived discussions about this topic. Regardless, if this is once again put to a vote at some point in the future I hope to be a part of that. Regards, Nbdwebdev (talk) 20:24, 12 February 2016 (UTC)

A thing to keep in mind is that the goal of our Wikiproject is not to write articles to benefit players, but as a generalist encyclopedia, and 99% of the time, the website for a game is far less useful as a general source, compared to, say, the website for a business entity or here a game developer or publisher. Game websites are geared by players for players, and forget that random people may need to learn about the game from them. So it's not always a useful link that everyone needs to see, though it certainly is a link that we should include as EL to help those that want those details to find them. There's also the other issue that if you put a field in the infobox, editors are prone to fill it in with something regardless of our guidelines and documentation. And we've seen editors use fan-based websites as replacement for defunct official websites for these games, or even in cases where the game doesn't have an official website. I do note this approach is not consistent with other infoboxes, some like Film don't have website parameters, while Book and Television do. --MASEM (t) 20:34, 12 February 2016 (UTC)

Again I can totally see what you’re talking about and I pretty much agree with all of it. Honestly, yes these video game websites are used to help promote the sales of a video game. While ideologically this may go against the intent of this wikiproject, I think we’ve reached a time where these video game websites often times offer more than just shallow PR advertising. Yes, much of the information would be supplemental to what is often already in place on the Wikipedia page. However, regardless of parity between infoboxes, linking to the official website in a more prominent place I believe results in a better user experience. A few examples of good game sites (in my opinion):

https://www.halowaypoint.com/en-us - tons of information

http://streetfighter.com/ - media page - how to play

http://www.tombraider.com - Media - PC Specs

http://www.finalfantasyxv.com/index.php - Dev Team - Story/Characters

Anyway, thanks for your replies/time. Nbdwebdev (talk) 20:58, 12 February 2016 (UTC)

Just because a website MIGHT isn't a valid reason for excluding, because a person could also make the same argument about Millions of references that point at mountains of websites on Wikipedia. A link to an official website doesn't have any requirement to not be good or bad, or only provide information instead of sales promotion. If sales promotion is the main reason to exclude a website link, then you better get busy removing links from every Apple related article on Wikipedia. • Sbmeirow • Talk • 21:59, 12 February 2016 (UTC)

Note that there is no guidelines that prevents inclusion of an official site in the external links. It has only been excluded from the template by consensus. Masem's points are spot on. -- ferret (talk) 22:17, 12 February 2016 (UTC)

I agree with Masem's points to an extent but I completely agree with Sbmeirowl. Ferret, there is a large difference between the external links section and the infobox in relation to visibility, ux, search engine visibility etc. If this rampant exploitation of infobox links is destroying the integrity of wikipages all over the internet, then why is their use so prevalent? Just seems bizarre to me. Thanks Nbdwebdev (talk) 22:30, 12 February 2016 (UTC)

Why is search engine visibility important? That feeds into the idea that the field is wanted for promotional, rather than informational, purposes. Consensus differs from area to area, and the current consensus for WP:VG is to not have this field. What other projects do is not really relevant, and some of them agree with omitting it. -- ferret (talk) 22:42, 12 February 2016 (UTC)

Ferett if the intent of a wiki page is not to be found by a user then you are right - search engine visibility is not important at all.Nbdwebdev (talk) 23:03, 12 February 2016 (UTC)

External Links sections are indexed by Google like the rest of the article, in that rare case where someone wants to find a Wikipedia topic by it's website name... so I'm not sure what you're trying to get at. If you are talking about things like how Google will build an "infobox-like pane for primary results, that's not our problem to fix. -- ferret (talk) 23:07, 12 February 2016 (UTC)

All Wikipedia's links are tagged with rel=nofollow, so they don't affect search rankings anyway. —  HELLKNOWZ  ▎TALK 23:09, 12 February 2016 (UTC)

Yes, I'm talking about the knowledge graph in Google and Bing. I just thought that people working on this wikiproject would like their content displayed in Google/Bing so that more people would appreciate their work and be able to utilize their additions. I suppose I was wrong. ThanksNbdwebdev (talk) 00:17, 13 February 2016 (UTC)

The KG is going to use, if it does not already, Wikidata, vice Wikipedia. Using that as an argument leaves something to be desired. --Izno (talk) 01:21, 13 February 2016 (UTC)

Izno, people have made all sorts of arguments and they all leave something to be desired according to the people outed on threads like this. I made an effort at persuasion and failed. However I realized that people, including you, Izno, have no interest in changing your opinions no matter what the argument is. Regards 205.166.76.15 (talk) 17:35, 15 February 2016 (UTC)

I would say most of us are willing to change opinions. It's just that we keep replying to the same arguments and we present the same issues that proposers never resolve. Personally, I haven't seen persuasive arguments to overcome changing infobox's purpose, allowing external links of unencyclopaedic nature, moving them from standard external link section, selecting official sites over more useful resources, and using them when proper neutral references exist. Most proposals revolve around what would theoretically be "useful", like SEO, but don't explain why this particular case should go against the wide-accepted Wikipedia's purpose. —  HELLKNOWZ  ▎TALK 17:56, 15 February 2016 (UTC)

Firstly, avoid implicating motivations about myself. Secondly, I was making a comment specifically regarding one point. If you find the other comments wanting, that's your prerogative, but it is incorrect to think that your point somehow answers mine, as mine deals with the specific case of Google's Knowledge Graph and not in general with the case of having a URL field (for or against--only against-against).

But since you asked for my opinion so nicely, in brief, it has not changed from the previous time I commented: an external link is not appropriate content for an infobox. --Izno (talk) 18:02, 15 February 2016 (UTC)

Serial ID Of discs

Can not be added to game infobox template an line to tell the Serial ID of the optical disc (CDs, DVDs, GDs, NODs, UMDs, Laserdiscs, Blu-ray discs, etc) of games released on this media? like the example:

• ZSTH-0001 - Touhou Koumakyou - The Embodiment of Scarlet Devil, PC, JP
• SLES-52541 - Grand Theft Auto San Andreas, PS2, NZ
• GMSE-USA - Super Mario Sunshine, GC, USA
• GS-9037 - Sakura Taisen, SS, JP

etc...

well.. what do you think of this? Jose8122 (talk) 22:14, 15 April 2016 (UTC)

I can't see any reason we'd want that information in the infobox. We don't include it in the prose. It's simply not important information for an encyclopedia. -- ferret (talk) 22:33, 15 April 2016 (UTC)

This is out-of-scope—better suited for a vg database and not an encyclopedia czar 22:45, 15 April 2016 (UTC)

Virtual Console & other emulation

Recently there have been some users editing out info about Virtual Console releases in pages for Nintendo games, following the statement about emulation in the platform section of the template page. I just wanted to make sure that I got it right: Virtual Console releases should not be counted in the platforms field, but release dates should. Right? I think it should be this way, since I agree that it's confusing to find list of home consoles releases for arcade-only games that were only emulated in compilations for example, but on the other hand it'd be wrong to not indicate that a game was released on other platforms, even if emulated. Otherwise we'd be removing informations on the game's availability on other consoles over the technicality of it being emulated.--Kombatgod (talk) 19:52, 29 February 2016 (UTC)

VC releases should not be included in the infobox fields for all cases, even including release dates. That a title was released on the VC is fine to discuss in prose but its release on the VC shouldn't be included. --MASEM (t) 20:52, 29 February 2016 (UTC)

What Masem said. All Virtual Console information on a game belongs in prose, and only dedicated ports belong in the infobox, both platform and release dates. Somebody with editing access should amend the release section, saying that emulated ports should follow what the platform field states right above, just to avoid any more confusion over this. ~ Dissident93 (talk) 23:44, 29 February 2016 (UTC)

 Done Lordtobi (✉)

Ok. Though I must say that editors should be careful after removing informations from the infobox and add it in prose when not present, otherwise it simply goes lost.--Kombatgod (talk) 17:45, 1 March 2016 (UTC)

Getting rid of these ugly (s)s

These (s)s (Developer(s), Platform(s), etc.) look stupid. Whoever puts this template in a given article knows whether there's one developer, platform, etc. or multiple, so it makes no sense that at the moment this template inflicts this ugly notation in order to leave the grammatical number unspecified. I have therefore made an improved version of the template that has separate platform and platforms, etc. parameters with the view that articles will use whichever parameter is correct for the instance. This has been done previously for at least one infobox template, possibly several.

I realise that for existing articles this will cause the label to say "Platforms" in cases where there is only one platform, and "Genre" in cases where there are multiple genres, etc. But I think that this is less ugly than the needless use of the (s) notation, and moreover people who come across such instances can easily correct them. As such, I claim that existing uses aren't a reason not to apply this change.

• Test of the new version: User:Smjg/sandbox
• The template itself: User:Smjg/sandbox/template
• Documentation: User:Smjg/sandbox/template/doc
• Syntax guide: User:Smjg/sandbox/template/doc/syntax guide

Can we put these versions live? — Smjg (talk) 16:10, 17 April 2016 (UTC)

Best to get consensus first before activating the {{editprotected}} request czar 16:33, 17 April 2016 (UTC)

Also shouldn't it throw some kind of error (or category) when using both params at once? I don't have strong feelings about this change and am unfamiliar with how the other infoboxes handle it czar 17:08, 17 April 2016 (UTC)

I haven't really thought about that. When a parameter gets a new, more sensible name, and the template is kept backward compatible, how often is the logic implemented to generate an error when both the old name and the new name are used? What do people think – do we need logic to check for duplication such as this? — Smjg (talk) 22:26, 17 April 2016 (UTC)

If we're going to have multiple parameters that are nearly aliases of each other, absolutely we should have a check for duplication and subsequent error. However, I think that question is less important when Wikidata is full implemented in the infobox. --Izno (talk) 19:10, 16 May 2016 (UTC)

• Opposed To the suggested version, with duplicated distinct fields for singular and plural. #if can be used to change the label based on whether platforms (versus platform) is found, with "plural" forms overriding singulars. This avoids having two actual distinct fields that might conflict. However, this breaks under Wikidata, as there's not going to be an easy way to detect if the values from Wikidata constitute a single or multiple value... at least not without going full custom. Wikidata would display with a singular label without digging deeper. I will look into building the label logic into the sandbox. -- ferret (talk) 19:21, 16 May 2016 (UTC)

Engine variants

Should Void engine be listed in the infobox of Dishonored 2? It is a new engine, based on id tech, but the Void engine itself does not have its own article. @Hahnchen: argues that it is a variant, and that it should be listed, similar to how Source 2, CryEngine 3, Unreal Engine 4 etc. are listed. I brought the discussion here so that we can solve the problem at the page, and reach a consensus on whether engine variants (those without articles) should be listed. The guideline isn't clear about this. AdrianGamer (talk) 15:52, 20 May 2016 (UTC)

Unlike Unreal Engine or CryEngine "series", Void seems to be a new engine based on what is currently id Tech. Unreal Engines and CryEngines stay the same throughout development in things like usage and behaviour, and is just improved and has certain parts redone/overhauled to give it a fresher feeling and better/more performance, and then gets delivered in a new package. As far as I can see, Void will be a new engine based on the technology (e.g. the compilation and debugging functions), but will most likely get a very different design and usage scheme, wherefore this is no longer a variation/update of the engine, but a different one based on another, just alike Amazon Lumberyard, which is based "on the archtecture of CryEngine", but we don't call it a CryEngine variation either, do we? The source cited on Dishonored 2 as well says "[...] a new generation of technology—including a new engine, Void, based on id Tech 5 [...]" (emphasis added). Also, regardless of everything I have just said, we have no information on that engine whatsoever (the id Tech 5 and id Tech articles do not feature the word "Void" once), except that it is based off id Tech 5, and therefore its addition goes agains this template's rules. I'd rather suggest explaining the engine in the Development section, but to leave it out in the infobox. Lordtobi (✉) 16:11, 20 May 2016 (UTC)

That is a lot of conjecture. The source could have read, "a new generation of technology—including a new engine, CryEngine", and it'd still be correct - because the word "new" is comparing Dishonored 2 with its predecessor. Void is part of the id tech 5 family, in the same way that Source 2 is in the Source family. We wouldn't remove Source 2 from infoboxes, we shouldn't be removing Void. - hahnchen 19:52, 20 May 2016 (UTC)

As I expressed in my closing sentence, regardless of what Void exactly is (and we do not know what it exactly is, other than "based on id Tech 5"), we have no information on it whatsoever. Template guidelines go exactly against that. As a side note, the engine does not seem to be developed by id Software themselves, but supposedly by Arkane Studios instead. Therefore I'd say that we have a similar occasion as with Amazon Lumberyard. Lordtobi (✉) 20:10, 20 May 2016 (UTC)

Source 2 is the successor to the Source engine, not simply an update to the SDK like the others have been, so I wouldn't use that as an argument for it to remain. Could more info about Void be found and put into an article first? ~ Dissident93 (talk) 21:59, 20 May 2016 (UTC)

It's just idTech, unless it is its own engine it's not its own engine. That said, I question the necessity of it being in the infobox anyway, it's hardly notable information and barely any more relevant than the system specs table we did away with. Darkwarriorblake / SEXY ACTION TALK PAGE! 22:46, 20 May 2016 (UTC)

One of the reasons we tightened what goes in this field was to limit how many "custom engine" entries there were, or for people to have to hunt down without sourcing to state what the engine was. Here, on the other hand, is the case of a engine that appears to be a modification of id Tech 5 by Arkane that is being called "Void", and readily sourced to secondary materials. In the spirit of why we have this field, I think I could see its inclusion as something like "Void (modified id tech 5)", as long as this explanation is given further details in the development section of the article. --MASEM (t) 22:54, 20 May 2016 (UTC)

Unify selected fields with {{infobox software}}

All video games are application software, and thus have specific releases and versions that are released over their lifecycle (i.e. actual patches to the game software. Not referring to SKUs like "game of the year edition" releases). Additionally, many games (even outside of MMOs) are increasingly being treated as a "service" which can be updated over time (but may also end at any time or become abandoned, see specific MMORPG video games as notable examples), and models such as early access and closed/open beta testing environments have also increased in prominence over time.

I believe that it is nessecary to introduce certain relevant fields from {{Infobox software}}, specifically:

| discontinued           = 
| latest release version = 
| latest release date    = <!-- {{Start date and age|YYYY|MM|DD|df=yes/no}} -->
| latest preview version = 
| latest preview date    = <!-- {{Start date and age|YYYY|MM|DD|df=yes/no}} -->
| status                 = 

These fields would be used identically to how they are used on Infobox software, providing a sourced summary on the current status of the game's development and whether it is still being supported by its developer/publisher. This change will help increase the level of uniformity between our articles for video game and non-video game software.

Any objections or concerns? ViperSnake151  Talk  21:45, 15 June 2016 (UTC)

• Wasn't this suggested before, and failed? Majority of games still wouldn't have need for this info, just MMOs and mobiles titles. ~ Dissident93 (talk) 22:21, 15 June 2016 (UTC)
• I actually argued against this at the original template's talk page... Template talk:Infobox software/Archive 6#Latest updates czar 22:43, 15 June 2016 (UTC)
• I object, as being trivial information for the infobox, and in fact regarding versioning, trivial for the article in whole. As for discontinued, I believe we've had that discussion here (or WT:VG) already. Please provide information which makes this case for addition sufficiently different. --Izno (talk) 11:05, 16 June 2016 (UTC)
• I believe this has been discussed a lot. Video games are much less iterative and meaningful when it comes to version numbers. Most games don't even have this information. (In fact, I would argue software infoboxes should at most have 1 major version number, and only if it's relevant (i.e. multiple versions exist).) Finding reliable sources (non-self-published) for video games in nigh impossible for versions. —  HELLKNOWZ  ▎TALK 12:16, 16 June 2016 (UTC)

Certain games, such as League of Legends, do have prominent reports on their version numbers, mainly because each patch is used in a beta channel first, and may contain balance or other changes that can have major impacts on the game, especially in competitive environments. ViperSnake151  Talk  14:34, 19 June 2016 (UTC)

LoL, TF2, and a lot of online competitive games push out patches, which is the important thing - the game is unplayable if you don't have that current patch. The reason the software template has the patch is to let people know if they have the latest update, but for nearly all games patched heavily, you are required to have that patch, and in most cases, you have software managing the accessing and dling of the patch. That is to say, for nearly most of these cases, the end user will have no idea about the version number they are using, just that their game works. And that makes the version number useless for video games. --MASEM (t) 14:55, 19 June 2016 (UTC)

Wikidata - Artist

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

There was no property in Wikidata that represented a game artist. d:Wikidata:Property proposal/game artist is the proposal for a new one. Once it is completed (Consensus appears to be for), I will implement as it is a quick addition. -- ferret (talk) 11:02, 10 August 2016 (UTC)

And approved. Go forth and add. --Izno (talk) 15:30, 11 August 2016 (UTC)

 Done -- ferret (talk) 17:52, 11 August 2016 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikidata - Genre and Mode

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The use of "short names" is not implemented in Module:Wikidata. Doing so should be simple enough, but that's why it hasn't been done just yet for these two fields. Either the various getValue method wills have to be updated with a new parameter to switch from "full" label to "short names", or a new method added like GetValueShortLabel or something. Or if needed, we can build that out as a part of a module just for this template. I think it should be made available to all the infoboxes though so Module:Wikidata is the better place. @RexxS: I've done a test implementation in Module:Wikidata/sandbox. Thoughts? -- ferret (talk) 11:02, 10 August 2016 (UTC)

My general inclination is now not to increase the number of parameters of an existing function, but to create a new function (which may indeed duplicate much of the code of an existing function) for three reasons:

1. You don't disturb current uses of the existing function - even if you think you won't, with 60,000+ transclusions, it's too hard to test to exhaustion;
2. Having a named function - I'd suggest getShortName to fetch short name (P1813) - is easier for users to learn, and keeping the code for that function succinct will help others to understand what is happening, should they wish to improve or fork the code;
3. You'll have to get consensus to modify an existing function in Wikidata; but adding a separate, independent function shouldn't be problematical.

Otherwise, I think the algorithm you're using is fine. HTH --RexxS (talk) 15:50, 10 August 2016 (UTC)

@RexxS: Moved the logic for getValue to a local function, and created getValueShortName. Let me know your thoughts on this approach. If you're happy, I'll head to the module to note pending implementation. I'd prefer not to duplicate code, but if its a consensus issue to modify even this much, I can leave getValue unchanged. -- ferret (talk) 13:59, 11 August 2016 (UTC)

I know that the fashion is to create modular code that's easy to re-use, but these functions are only a couple of dozen lines of code each; the whole of Module:Wikidata is just over 1,000 lines and 35K in size. I honestly would discourage anybody from writing local functions unless they are going to be used multiple times in a big module. When you're working in an IDE that can display multiple parts of the code at a time, it's easy to trace what is happening in subroutines, but debugging code that jumps from place to place in Wikipedia's Lua editor is a PITA. I'd urge you to keep writing self-contained functions - it's kinder on yourself when something breaks, and kinder on others trying to follow what you've done. --RexxS (talk) 15:38, 11 August 2016 (UTC)

Good enough reasons for me. I've adjusted accordingly. -- ferret (talk) 17:58, 11 August 2016 (UTC)

Module:Wikidata has been updated to support this, will fix in infobox shortly. -- ferret (talk) 13:53, 19 August 2016 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

 Done Caveat: If you spot a genre or mode that does not have a short name, go add it in Wikidata. I hit a few genres myself, and took care of single-player and multiplayer modes. -- ferret (talk) 14:05, 19 August 2016 (UTC)

Wikidata - Dealing with redirects

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

This may belong more at Module talk:Wikidata than here. How to potentially deal with redirect targets? For example, Source 2 is in Wikidata, but redirects to Source on enwiki. Another I just hit at Space Run is that wikidata holds OS X as macOS, while enwiki redirects macOS to OS X. From a linking perspective, nothing is wrong, you still end up at the right article, but a display label point of view, things aren't quite right. @RexxS: Thoughts on this one? -- ferret (talk) 13:46, 11 August 2016 (UTC)

Well, on en.WP, we have a link to Wikidata when ideally we should have a link to the redirect (and subsequently the redirect target should be reachable). This is the problem I mentioned above at Source 2 has a redirect to Source. I don't think there's any way (besides using a Wikidata-side hack of a thing) to get that to display locally instead of the link to Wikidata. The question of engines (and their various redirects) deserve some discussion, I think.. --Izno (talk) 14:03, 11 August 2016 (UTC)

I see OS X was as simple as correcting the en label. That's a big one with widespread use, so good there was a quick fix. Still have to deal with "combined" articles like Source and Source 2 though. -- ferret (talk) 14:12, 11 August 2016 (UTC)

It's the d:Help:Bonnie and Clyde problem rearing its ugly head. :D --Izno (talk) 14:18, 11 August 2016 (UTC)

You either bite the bullet and create the article Source 2 on en-wp; or you do the redirect hack. Wikidata won't let you link to a redirect, so you create the article temporarily, create the interwiki-link on Source 2 (Q21658271), then restore the redirect. --RexxS (talk) 16:09, 11 August 2016 (UTC)

Appears to be a general issue with Wikidata for certain redirects. Initial concern about OS X label was fixed. If labels from Wikidata do not work correctly, a local value can be used as always. We can't solve the general redirect issue here. -- ferret (talk) 14:12, 19 August 2016 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikidata - Ugly "page missing" buttons

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

As an example, on Air Control (video game), there are these: [*]. Would it be a better idea to change it to a single asterisk? i.e.: Killjoy Games*, instead of Killjoy Games[*]. -- Anarchyte (work | talk) 04:47, 13 August 2016 (UTC)

This comes from Module:Wikidata and occurs on every infobox using the module. Would be better to discuss this one at Module talk:Wikidata. -- ferret (talk) 12:59, 13 August 2016 (UTC)

The point of the ugly "button" is to provide a tooltip when a mouse hovers over it indicating that the text is a link to the Wikidata item when there is no Wikipedia article. To that end it needs to be big enough for readers to notice and big enough that's it's not unreasonably difficult to hover a mouse over it. A single asterisk is a pretty small target for that, especially at the reduced font size in an infobox. Compare these:

• Killjoy Games*, Killjoy Games [*], Blizzard Games

I find it much, much easier to hover over the ugly button than to hover over the titchy star. YMMV, but I'm sure that if you have a better idea that retains the functionality, it would be welcome. --RexxS (talk) 14:10, 13 August 2016 (UTC)

I think the links should show an icon instead of an asterisk, like external links. SharkD  Talk  18:59, 13 August 2016 (UTC)

So it might look something like this:

• Killroy Games, Killjoy Games, Blizzard Games

I like that, even though Wikidata is a sister project, not really an "external link". I'll make a sandbox version and get some opinions at Module talk:Wikidata. --RexxS (talk) 20:23, 13 August 2016 (UTC)

Update: Discussion is at Module talk:Wikidata #Icon to indicate no Wikipedia article. Sandbox is at Module:Wikidata/sandbox2. --RexxS (talk) 21:00, 13 August 2016 (UTC)

Please follow discussion to Module talk:Wikidata #Icon to indicate no Wikipedia article, as this affects all infoboxes. -- ferret (talk) 14:20, 19 August 2016 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Preceded by

Can we have a field like this for games in a series like Resident Evil 2 so it is easier to click on what comes before and after without scrolling to bottom for a chart? 64.231.169.3 (talk) 01:33, 28 June 2016 (UTC)

It's been discussed several tmes before, and it's not a good idea, as the question with several games if you put it by order of release date or by order of story chronology, and do you include DLC, and the like. It's too tricky a field to use. --MASEM (t) 01:49, 28 June 2016 (UTC)

Also the predecessor/sequel tend to be linked in the lede too czar 01:51, 28 June 2016 (UTC)

Platform field order

We have discussed this before but haven't seen any resolution and the last convo seems to be 2013. Lately, I have been seeing changes to platform ordering in the infobox to be alphabetical regardless of any other circumstances, though at one point I though it was generally considered to be PC versions then consoles then handhelds then mobiles. I'm not against going alphabetically but we should make this a standard if we want to go this way, including if we alphabetize on "Windows"/"Microsoft Windows", "Nintendo 3DS"/"3DS", etc. Note that this should also apply to the Series infobox too. --MASEM (t) 14:13, 2 July 2016 (UTC)

• It's not something I'm particularly bothered by, but I would say list in chronological order, and then alphabetical for simultaneous releases (to match the order used in the release field). For old games, I think it would more logical for the original platform to appear first and rather than platforms the game was ported to years later. --The1337gamer (talk) 14:23, 2 July 2016 (UTC)
  • I thought about that, but that's what the release date field should be doing, making it clear on such ordering, so seems unnecessary to duplicate it.
  • There's also the case that I'm not sure about for a game that was came out exclusive for one platform and then later got ported across the board (eg Limbo for 360 for example). But again, if the release field is formatted correctly that should be apparent from a glance. --MASEM (t) 14:25, 2 July 2016 (UTC)
    • I definitely think that the best way to list them is to list the PC versions first, followed by consoles, followed by handheld, and followed by mobile. It just really seems odd to have Android listed as the first platform for Mortal Kombat X when the game is primarily known as a console game instead of a mobile game. Alternatively we can list the platforms they are primarily associated with, then the ports. If the PC game is going to be ported to consoles (like Elite: Dangerous), then PC should be listed first. If a console game was announced exclusively for a console then was announced for PC, then list the console first (like Quantum Break). AdrianGamer (talk) 16:05, 2 July 2016 (UTC)
• My understanding is that precedence has been to order first by release and secondarily by alphabet. If there is little difference in the release window, I would ignore the order by release and go for full alphabet—the difference of a week or even a month is usually insignificant but the idea is to avoid putting "Android" first in Doom's infobox, for instance, as that would be confusing for readers. But putting PlayStation first on an article narrowly first released on Xbox isn't a big deal.

I'll add that I think this is related to infobox bloat—the platforms field does not need to duplicate what we already see in the release dates field. WP has an idiosyncratic obsession with specific release dates, even in eras where the release dates were not specific nor actually enforced with strict street dates (see moral panic over the official release date of Super Mario Brothers). The benefits of seeing all release dates for Doom or Limbo in the infobox at a glance are minimal (especially as few infoboxes are actually fully sourced like Limbo's) and would be best covered in a separate Development section template, in my opinion. If we did indeed only list the original release date, like the film infobox, the platforms field could go back to simple alphabetization, which would be easier for readers to read, and they would be encouraged (as they should) to read the corresponding section in prose for more details, hopefully with real sourcing. czar 17:13, 2 July 2016 (UTC)

• • I do think that we need to encourage the use of the collapsed list for release if there's anything more than 2 dates. And I'm not against alphabitization as long as we are consistent (and stick to our guns about avoiding emulated game released like PS2 classics on PS4, while allowing remasters to be accounted for, ala the BioShock collection), but we do need to agree to be consistent here. --MASEM (t) 17:25, 2 July 2016 (UTC)
• It's supposed to be listed chronologically first, per WP:VG/STYLE, and only alphabetically if it was released the same day. ~ Dissident93 (talk) 22:59, 2 July 2016 (UTC)

Why is there no "Written in" field?

I was just wondering why this template has no "Written in" field that the software infobox has, as it seems like an appropriate field seeing how video games, by definition, are pieces of computer software and hence are written in at least one programming language. Brenton (contribs · email · talk · uploads) 02:23, 22 July 2016 (UTC)

• While games are software, some fields present in the software infobox are omitted in the video game infobox for not being as relevant to video games specifically. We don't include programming languages. But if a notable game engine was used, we do have a field for that. Reach Out to the Truth 02:40, 22 July 2016 (UTC)
• Because the game's engine is more important to know, and whatever language the engine was coded in is listed on the article for it, making this redundant. ~ Dissident93 ^(talk) 08:28, 22 July 2016 (UTC)
• Also, this information is very rarely sourcable reliably for video games and would require OR for almost every game. It's just not common practice in sources to focus on (or even mention) languages when games are concerned. —  HELLKNOWZ  ▎TALK 09:23, 22 July 2016 (UTC)
• Most importantly, it's out of scope. The infobox is supposed to be for quick access to key facts (sigh) and the game's technical details, including the language in which it was programmed, are not important to 99% of readers of a generalist encyclopedia. In a more technical wiki, sure czar 19:38, 22 July 2016 (UTC)

Wikidata

Does anyone know the status of Wikidata integration with infoboxes? It would be nice to leave most of the infobox data there, or to set an image once across all (participating) Wikipedias when a free use version is available... czar 13:59, 12 April 2016 (UTC)

Official status: Approved for use. Unofficial status: Inclusion of Wikidata in infoboxes is being only-slowly adopted. Template:Infobox telescope is the only one on en.WP using it of which I know. --Izno (talk) 14:03, 12 April 2016 (UTC)

There are a few more listed at Category:Templates using data from Wikidata. Is the idea that each infobox group starts experimenting on its own? Is anyone opposed? czar 14:44, 12 April 2016 (UTC)

Basically, I think that's what is happening. I wouldn't be opposed to experimentation here--VGs are pretty easy to handle. --Izno (talk) 15:25, 12 April 2016 (UTC)

• @Ferret, ready for your next project? czar 02:30, 26 April 2016 (UTC)

• Sure, I can tackle this when we're done with the review wikidata ideas. However this will be a little different... The reviews benefit from custom Lua code. Infobox convention is to rely on Module:Wikidata, which takes away some freedom. For example, in the review score module, an early issue brought up was how the systems were sorted, so I implemented a simple alphabetical sort. VG Infobox tends to have a lot of carefully ordered fields such as release date and what order to place writers or composers in, etc.... By default, these would be returned in the order they were input into Wikidata. I'm not sure Module:Wikidata provides a way to address that, though I know it currently doesn't look at rankings. Most of the data is there, but presentation may be nitpicked. -- ferret (talk) 11:38, 26 April 2016 (UTC)
• The released field in particular will be difficult, getting it to follow local project guidelines like "Only English, unless developer region" and grouping systems, etc. -- ferret (talk) 14:34, 27 April 2016 (UTC)

For the last example, couldn't we check whether the QID's developer is Japanese and then only display the date if so? I don't think we'll hit all the edge cases at once, but we should start somewhere. This might be the type of application that shows the Wikidata devs what kind of contingencies we'll need. Is it worth thinking about rewriting the infobox in Lua? czar 20:34, 27 April 2016 (UTC)

I'm wary of rewriting the infobox in Lua, as I suspect that would break typical convention of using Template:Infobox as a base. A better solution I think would be to have a "Template:Infobox video game/released" sub-template that wraps and hides the custom logic required. This lets the primary template keep normal format. -- ferret (talk) 21:29, 27 April 2016 (UTC)

That makes sense czar 22:56, 27 April 2016 (UTC)

@Czar and Izno: I've implemented a few easy fields on the sandbox: Developer, publisher, director, composer, series, genres, modes, engine and platforms. I'll add some more as I have time to dig up the right properties. The release date field still gives me the most concern but for most fields, the simple list format generated by Module:Wikidata should suffice. Plus it can always be overridden. To test it, visit any article, like Dark Souls III (I populated some of the properties for testing), replace the entire infobox with {{Infobox video game/sandbox}}, and press Preview (Don't save!). -- ferret (talk) 18:29, 16 May 2016 (UTC)

The first value popping out of genre and mode should probably be upper case first letter; not sure how to implement that in Lua, though there is a parserfunction at {{ucfirst:VALUE}} which probably has an mw API representation (or in the parserfunction API). I'll do some more poking later. --Izno (talk) 18:48, 16 May 2016 (UTC)

The genre call might want to check that the genres popping out are instances (P31) or subclasses (P279) of video game genre (Q659563) and display only those genres, since I'm aware of some genres on Wikidata video games items reference literary genres. I personally consider that a good thing in Wikidata, and it might be neat to start displaying that on our templates, but it's not what 'genre' exactly means in our context. --Izno (talk) 19:08, 16 May 2016 (UTC)

When more than one output is produced for a particular key, include "s" e.g. "genres", else "genre", per #Getting rid of these ugly (s)s below. --Izno (talk) 19:12, 16 May 2016 (UTC)

Upper casing first letter should be fine, ucfirst should work without issue. Checking for instance/subclasses may require a sub-template with lua module, as I do not believe Module:Wikidata will go to a second level to check values like that. I do not believe I can handle programmatically deciding if a field is singular or plural (Is "Microsoft Windows" plural? The template doesn't know the context, just that there's a space or comma or ends in s...etc.) -- ferret (talk) 19:15, 16 May 2016 (UTC)

Singular: Yes, I'm looking at the sandbox implementation and it's using the functions from Module:Wikidata rather than a module (e.g. Module:Infobox video game using Module:Wikidata and Module:Infobox rather than Template:Infobox video game using Template:Infobox and Module:Wikidata). @RexxS: Maybe it would be good for Module:Wikidata to provide a function to "count" the set of values e.g. getValueCount.

Regarding p31/p279: just a thought; I'm not particularly concerned about it. That's something for deeper discussion at Module talk:Wikidata, since it's non-trivial probably. --Izno (talk) 19:24, 16 May 2016 (UTC)

Counting the number of items is trivial from within Module:Wikidata: if you look at function getValues, it constructs a table of values called "out", so #out will be the size of the table, hence the number of items. Just duplicate that bit of code and strip out all the stuff about sitelinks and labels, then return #out -- or even just increment a counter as it iterates through for k, v in pairs(claims) do.

By the way, function getValues does look at ranks and returns only the best in cases where the value is not a linkable article. I have a sandbox function Module:Sandbox/RexxS/ImageLegend that demonstrates handling ranks for the image (P18) image property, but haven't included it in the main module because I get moaned at now when I add code to it.

By the way II, if you use the parser functions like this: {{ucfirst:{{lc:multi Case WORDS}}}} you get Multi case words i.e. sentence case, which we usually want. --RexxS (talk) 19:52, 16 May 2016 (UTC)

Sentence case implemented for genre and mode. I'd like to keep this template in typical (?) infobox format, using Infobox as a template base, but if we need to Lua-it-up I can go that route. That does provide for some possible performance enhancements. -- ferret (talk) 21:09, 16 May 2016 (UTC)

Hoping to come back around to this as most of the work on Template:Video game reviews is completed. -- ferret (talk) 00:51, 1 July 2016 (UTC)

I'm going to try to test the sandbox at Fallout 4: Far Harbor. @RexxS: A few thoughts you might be able to help with... {{ucfirst:}} doesn't seem to be working for genre and modes. I'm not sure why. They are coming out in all lower case currently. Second... The series should be italicized. Is there a way to have getValue do this? -- ferret (talk) 13:09, 1 July 2016 (UTC)

@Ferret: I've fixed the sandbox template so that it italicises the series if it exists - that's generally how we deal with returned values that need post-processing in Wikidata-enabled templates. I can see that {{ucfirst:{{lc:action role-playing game}}}} works (-> Action role-playing game), but {{ucfirst:{{lc:[[action role-playing game]]}}}} doesn't (-> action role-playing game), because the 'magic words' are too dumb to realise that [ isn't actually the first character of the name. I'll go and have a look for a string function in a Lua module that will do the job in a smarter fashion, otherwise I'll have to write one - we can see that there's a need for it. --RexxS (talk) 14:07, 1 July 2016 (UTC)

Ugh, didn't even occur to me that '[' is technically the first character. -- ferret (talk) 14:11, 1 July 2016 (UTC)

It turns out that I'd written Module:Sandbox/RexxS/String2 in 2013 - just chalk it down to senility (see update below). I've now updated it to find the first real letter and capitalise that.

• {{#invoke:String2|sentence|action GAME}}
• Action game
• {{#invoke:String2|sentence|[[action Game]]}}
• Action game

See if that works for you. If not, give me another ping. --RexxS (talk) 15:11, 1 July 2016 (UTC)

Update: I'd forgotten I'd actually created Module:String2, so that's available instead of my sandbox. --RexxS (talk) 15:25, 1 July 2016 (UTC)

Another update: @Ferret: I needed to also handle piped wiki-links. Now done.

• {{#invoke:String2 | sentence | {{#invoke:WikidataIB |getValue |P136 |name=genre |fetchwikidata=ALL}} }} in Fallout 4: Far Harbor (Q24807292) produces:

Hope that should be enough to solve your concerns above. --RexxS (talk) 22:58, 2 July 2016 (UTC)

 Done @RexxS: Between real life and working on Module:Video game wikidata I had not swung back around to this. String2 has been added to the sandbox and the first letter of genre and mode is now capitalized. -- ferret (talk) 13:00, 15 July 2016 (UTC)

Progress

I made some progress today. Here's some issues that need addressed, ignoring for the moment the released field, which has all kinds of arcane rules...

1. "Producer" has a property available, P162, however, Wikidata seems to have defined it narrowly as only for film and TV.
2. "Artist" has no suitable property, with the closest matches being creator P170 (Too generic) or cover artist P736 (Too specific).
3. "Writer" is implemented as P50, which is "author" in Wikidata. This should be fine, but in case anyone has concerns I've listed it.
4. Except for CPU, NONE of the arcade fields have suitable wikidata properties. In fact, the scope of the arcade fields seems so narrow that I almost think they should be removed. If we cannot wikidata-source all of them, I believe we should leave CPU out as well.

Thoughts in general? -- ferret (talk) 19:38, 15 July 2016 (UTC)

1. Nothing in the constraints restricts P162 to film and TV, so I don't see an issue there. However, what about d:Property:P272?
2. Yes, we'll need a property here, I think. Not sure how to make it sound sane to the Wikidata peoples.
3. No issue here.
4. Those are leftovers from Template:Infobox arcade's merge here. They seem fine to include specifically for arcade games. I'll look into what Wikidata properties are needed, though it sounds like "all" is the answer".

--Izno (talk) 22:09, 15 July 2016 (UTC)

P272 seems oriented towards companies/businesses rather than people. What bothered me about d:Property:P162 was the instance Of claims. Are those not soft constraints for usage? There appears to be no "Wikidata property for items about video games" item, though perhaps we should consider creating one. -- ferret (talk) 22:16, 15 July 2016 (UTC)

That's just people on Wikidata getting classification-happy (it's driving me nuts too ;D). The constraint on the talk page saying that all claims must be a subclass of "work" is more telling about the use of the property. --Izno (talk) 22:21, 15 July 2016 (UTC)

I've implemented d:Property:P162 for Producer. I've submitted a request for Artist. I believe its a sound enough rationale. (Though I just now found d:Property:P110, but it seem narrowly defined and doesn't really mean the same thing.) -- ferret (talk) 22:36, 15 July 2016 (UTC)

Just noticed cs:Šablona:Infobox_-_videohra, another Infobox video game that's already data enabled. They also had to leave Artist blank. At least they picked the same properties I did. :) -- ferret (talk) 22:53, 15 July 2016 (UTC)

• I agree—I'm not sold on the necessity of the Arcade parameters. They tend to be dubiously sourced and of little overall value. czar 19:09, 16 July 2016 (UTC)

Waiting on the artist property request to fail, then I will have to convert the entire infobox to Lua. Module:Wikidata doesn't have a method currently for handling sub-querying of qualifiers, so need a little bit more logic. I don't anticipate it being overly difficult, and it has some performance boons. -- ferret (talk) 12:53, 21 July 2016 (UTC)

• I commented there (finally). Still have to get to your talk page. ;D --Izno (talk) 13:23, 21 July 2016 (UTC)

• d:Wikidata:Property proposal/game artist - New discussion for a property to hold the (game) artist field. -- ferret (talk) 17:36, 3 August 2016 (UTC)

Release dates

This is going to be impossible to get exactly right for the expectations of the project, probably, but I believe we can get an approximate that works in most cases. Likely, release dates will be the most commonly overridden field in the end though. Please read the proposed logic and let me know your thoughts:

The documentation, for quick reference: "Add release dates according to the platforms field, for English-language regions and the developer's region. Use only general public release dates, not festival, preview, or early access dates. If possible, use the game's exact release date ("July 21, 2016"). Use the {{Video game release}} template: {{Video game release}}. If there are many release dates, enclose them all with the {{Collapsible list}} template[2] and add the field titlestyle=font-weight:normal;background:transparent;text-align:left; followed by title= set as the earliest release date. Platforms can be abbreviated to fit in one line and should be listed as bolded section titles without colons, separated with commas (e.g. PS2, NGC, Xbox)."

1. Pull all Publication date.
2. Pull the developer, and check for claim country.
3. On each, check for qualifier place of publication.
4. For each place of publication, check a table of languages. If not found, tried to populate by pulling official language. If it is English, or the country matches the developer's country, then store in a table. (The table above is necessary because good ol' USA has no official language to check)
5. At this point we have all of the publication dates that are from English regions or the developers country. (To best of our ability to determine).
6. For each publication date, pull the qualifier platform if available.
7. Group dates/regions by platform.
8. For each platform, sort publication date.
9. For each platform, output: Platform {{video game release}}.
10. If more than X total platforms, wrap the entire thing in {{Collapsible list}}.

Caveats: If one platform, exclude platform.

This is a very rough draft of the logic. It should produce something akin to typical displays, but there's going to be no way to make it perfect for the more nitpicky editors. -- ferret (talk) 13:53, 21 July 2016 (UTC)

Would this be easier by adding the region on the video game item? I think we'd need a new property for that, but it sounds like it would mostly fix the mess above. --Izno (talk) 13:56, 21 July 2016 (UTC)

Need more details on what you're thinking. Would region be a qualifier on the publication date? Note the diff of this edit, I adjusted the logic some because I got off in the weeds. We don't need the language of the developer, only it's country. Language is only needed to filter place of publications that do not match developer. -- ferret (talk) 14:11, 21 July 2016 (UTC)

Yes, a qualifier on the publication date. --Izno (talk) 14:21, 21 July 2016 (UTC)

Which would naturally (duh) publication location, which I believe exists presently. --Izno (talk) 20:29, 21 July 2016 (UTC)

Yes, place of publication. -- ferret (talk) 21:23, 21 July 2016 (UTC)

• I think a lot of this struggle could be for naught. More often than not, none of these dates are sourced in articles. We end up having a giant list of dates that are only off by a day or two that should really be explained better in prose. For the minimum viable infobox, I would think that you only need to have the first release date up, similar to how the film etc. infoboxes do it. You can try to code something that approximates the mess that we currently use but personally I don't see the use. czar 19:09, 21 July 2016 (UTC)
  • I agree, I don't really see the point in making this needlessly more complex. ~ Dissident93 ^(talk) 01:02, 22 July 2016 (UTC)
    • @RexxS: Is there a Module:Wikidata call that will pull the earliest date for a property? GetValue looks like it grabs everything. If not I'll whip something up quickly. -- ferret (talk) 16:34, 3 August 2016 (UTC)
      • @Ferret: There's no call written to do that filter; getValue is intended to return the list of values for a given property. You'll need to iterate through the property values and look for start date qualifiers. The values of those are time stamps which are strings, but they will still sort/compare cleanly, except that you'll have to watch out that some might be a year (["precision"] = 9) stored as something like ["time"] = "+2016-00-00T00:00:00Z" which sorts/compares "earlier" than 1 January 2016. You may also need to allow for the theoretical case when two values of the property have the same start date. Cheers --RexxS (talk) 18:24, 3 August 2016 (UTC)

Go forth?

While we are still pending final options for Artist and Release Dates, there's nothing to prevent moving forward with the rest. Is there any opposition to moving forward with this sandbox version? It is inline with other infobox implementations that use Module:Wikidata. We can expand and tweak from there. I would like to get this installed before looking into other requested changes such as the "(s)" labels. -- ferret (talk) 16:40, 3 August 2016 (UTC)

I will be implementing the version above today. There has been plenty of talk page traffic and no opposition voiced. -- ferret (talk) 11:15, 8 August 2016 (UTC)

Wikidata Go-Live

Please be aware that Template:Infobox video game will become "Wikidata aware" today. A basic guide to Wikidata editing is available at WP:VG/WD. If you encounter any major issues, please open a section at Template talk:Infobox video game. The implementation we are using is typical and relies on Module:Wikidata, which helps standardized retrieval and formatting of Wikidata properties.

Note that a blank template parameter will prevent Wikidata pulls. If you begin populating Wikidata and expect to see that data in the article, make sure you remove placeholders. This is by design based on the last RFC that allowed for Infoboxes to pull Wikidata. -- ferret (talk) 11:31, 8 August 2016 (UTC)

Live The template update is live. I've reviewed across some 40+ articles now and have not found any outstanding issues at this time. -- ferret (talk) 13:56, 8 August 2016 (UTC)

Could the release dates be put in a "Wikidata aware" template as well? SharkD  Talk  03:13, 9 August 2016 (UTC)

Because of all the arcane rules about the release field, as well as the on going discussion just above this one, I have not tackled the release date field yet. It will require a bit of custom coding to accomplish. It will however be included in the future. -- ferret (talk) 11:24, 9 August 2016 (UTC)

I'm not real familiar with Wikidata. Will each game have its own data "item" (not sure what to call pages at Wikidata), or is the data spread across multiple "items"? Can multiple templates pull data from the same item? We could generate a separate table for release dates as long as the data itself is stored in the same Wikidatabase. SharkD  Talk  01:46, 10 August 2016 (UTC)

"Item" is usually what it's called. Each item corresponds to an entity (fictional or otherwise), wherein we make statements about the entity (and not Wiki*'s description of such). Most of the Wiki*-notable games have an item, and all should. A separate template could pull that information (I'm against (re)moving that information from the infobox; the table is thin at-best and the infobox really is the place for it). --Izno (talk) 11:24, 10 August 2016 (UTC)

@Ferret: The "[Edit on Wikidata]" on the bottom of the infoboxes looks out of place - I'd suggest removing it. Also note that other infoboxes don't have such either. Maybe the pencil could stay (it should have a tooltip saying "edit") if it's moved out of the extra row to some appropriate place in the box. --Fixuture (talk) 21:13, 9 August 2016 (UTC)

(edit conflict) @Fixuture: It's sensible to indicate to editors that they may need to make changes by editing the associated article on Wikidata, and we should be encouraging infobox designers to include such links. The edit link as text was adapted from the Spanish Wikipedia - where it is common - and has been in use in {{Infobox person/Wikidata}} since June 2015. The updated {{Infobox telescope}} has been in use for several months and normally pulls all its data from Wikidata. You can see the [edit on Wikidata] at the bottom of the infobox of any telescope article. If you browse through Category:Templates using data from Wikidata, you'll doubtless find other examples. The pencil does have a tooltip that says "Edit this on Wikidata". If you're not seeing that when you hover over the pencil, please let us know your OS and browser and we'll look for a fix for you. --RexxS (talk) 21:50, 9 August 2016 (UTC)

Some first comments: I went to implement the below in Dota 2, and I got some interesting display:

{{Infobox video game
| title = Dota 2
| image = DotA2.jpg
| producer = Erik Johnson
| writer = {{Unbulleted list|[[Marc Laidlaw]]|[[Ted Kosmatka]]|Kris Katz}}
| released = '''Microsoft Windows'''{{Video game release|WW|July 9, 2013}}'''OS X''', '''Linux'''{{Video game release|WW|July 18, 2013}}
}}

• Where I expected to see only Valve in the publishing organizations (in an attempt to get to the same infobox as present), I see the other 2 institutions on the Wikidata item. Both Nexon and Perfect World are/were correctly publishers outside the main regions (China, Korea, and Japan; Nexon no longer publishes the game--to be qualified on Wikidata shortly--but Perfect World still does). How should we square that in the infobox?
• Single and multiplayer aren't getting/using the short names as previously discussed. I'm not sure if we implemented that, but that's a point at which to poke.
• Source 2 has a redirect to Source. I don't think there's any way (besides using a Wikidata-side hack of a thing) to get that to display locally instead of the link to Wikidata. The question of engines (and their various redirects) deserve some discussion, I think.

--Izno (talk) 21:47, 9 August 2016 (UTC)

The same infobox guidelines should allow apply to this, right? So Nexon and Perfect World shouldn't be listed there too. I also see other errors (Like Chet being a credited writer), but everytime I've tried to remove the info, it wouldn't let me. ~ Dissident93 ^(talk) 21:59, 9 August 2016 (UTC)

That's essentially my question. Nexon and Perfect World however are correctly distributors in those countries, so removing them from Wikidata is out of the question (also out of the question would be to use d:Help:Ranks to resolve the issue, since while we might prefer Valve, the Chinese WP might not). Let me know if you need help with it--you might have been edit-conflicting me. --Izno (talk) 22:03, 9 August 2016 (UTC)

Well, it needs a way to not show on the English Wikipedia then. Personally, I do not like the transition to Wikidata for various reasons. Is this a site-wide guideline shift, or something I've missed on WP:VG? Oh, and BTW, Nexon isn't the publisher in Korea/Japan anymore, Valve directly took over last fall. ~ Dissident93 ^(talk) 22:05, 9 August 2016 (UTC)

I know that it needs a way--that's why I asked to see if there's a way (besides RexxS's comment below). You should review Wikipedia:Requests for comment/Wikidata Phase 2 regarding your question. Lastly, regarding Nexon, please review d:Help:Qualifiers--they basically allow for that nuance. --Izno (talk) 22:11, 9 August 2016 (UTC)

From a three year old discussion? I wonder what WP:VG members would think now (assuming I haven't missed anything else), because to me, all this is doing is making editing and maintaining infoboxes more confusing for no reason. ~ Dissident93 ^(talk) 22:20, 9 August 2016 (UTC)

It's only 3 years old because no-one has implemented it yet :D. And as regards what VG members thing, that's a non-starter (though their feedback is welcome) per WP:CONLOCAL. You don't have to use a Wikidata infobox if you don't want, but I think most people will, for a number of different reasons. As it happens, I expect there will be a general tendency toward "let's improve the Wikidata version of this when we do our quality push for a particular article, of whatever level" (this is what inspired me to work on Dota 2 right now), but for now, there's obviously no requirement to do so. --Izno (talk) 22:24, 9 August 2016 (UTC)

(edit conflict × 3) @Izno: infoboxes aren't the place to expound the nuances of which publishers no longer publish. If the Wikidata doesn't match the consensus summary (just Valve displaying), then supplying |publisher=Valve is the most sensible fix. We could at a later stage make use of the qualifiers in Wikidata for publisher (P123), but surely we should be looking to implement a working wikidata-aware infobox before trying to fix all the edge cases? Incidentally, I don't think that removing claims from Dota 2 (Q771541) to force it to fit the en-wp idea of who publishes the game is a sensible way forward. --RexxS (talk) 22:07, 9 August 2016 (UTC)

I agree regarding your incidental. Will think on the rest. --Izno (talk) 22:11, 9 August 2016 (UTC)

@RexxS: Regarding your "shouldn't we shoot for working": I think it is working (besides video game artist, which will probably have its property approved shortly, and dates, per ferret's comment above). So I think now is the time for "let's talk about edge cases" and sometimes not-so-edge cases, as is the question with video game engines (which we generally redirect on en.WP).

Aside: Part of the problem, I think, is that we've gotten problematic on what isn't allowed in this infobox. I see little issue with displaying everything, or near everything, regarding publishers. Maybe dates and platforms will be a different question, but there are rarely so many publishers/distributors that we can't just list them all. --Izno (talk) 22:20, 9 August 2016 (UTC)

I'm not sure I'm content about the wikidata-aware infobox working, when the data that it's drawing on is almost entirely unreferenced. I'm working my way through Dota 2 (Q771541) adding references to get an idea of the size of the problem (and make an useful example to show off the new infobox). I'd be happy to look at implementing calls that filtered out unwanted information, e.g. publishers that no longer publish the game, but there's a broader set of issues about how to determine what filters to apply under what circumstances. I sympathise with Dissident93 and I'm not sure how we would implement filtering the Wikidata in infoboxes in a way that editors will not find it more effort than what they do now. If we can always 'hard-code' a filter into the infobox design, then it's worth doing; but as soon as we find we need one filter for one article and a different filter for another, we're never going to sell that to the editors who will have to implement it on an article-by-article basis. --RexxS (talk) 22:45, 9 August 2016 (UTC)

Regarding the specific case of referencing, it's a pain right now for any source which is not one we can re-reference over and over (as is the case with most video games). Citoid support for Wikidata will help fix that, but that's a ways away.

Generally agreed regarding filters. --Izno (talk) 22:53, 9 August 2016 (UTC)

Well, adding a few refs to Dota 2 (Q771541) wasn't too bad, Magnus' drag-and-drop-references gadget makes life easier (it's in your Wikidata preferences - see https://www.youtube.com/watch?v=jP-qJIkjPf0 if anybody watching this page hasn't seen it). I only had to manually add the archived refs that the gadget doesn't do yet. I had the article open on one monitor to search for words and references and the Wikidata entry open on the other. It's a productive way of spending a relaxing hour, and might even take over from editing Wikisource as a way of getting away from the battles on Wikipedia. --RexxS (talk) 23:14, 9 August 2016 (UTC)

Good evening. Lot of replies in a short while here... Izno and RexxS seem to have things well in hand as far as replies go. Just my quick few points:

1. We will never get this to pull from Wikidata and fully obey the various arcane rules this template has wrapped around some fields. The release date is the worst offender, of course. If the Wikidata format doesn't work for a particular field at a particular articles, we'll just need to use a local value there. See my subsection above about the release date where I tried to map logic that would obey the current rules.
2. WP:VG was asked a couple times for input on this effort, and it was developed over several months with discussion here. I believe enough notification was provided, and as long as there are no immediate issues caused by the template update, it should not harm any existing article infoboxes, which are fully populated with local values. Even empty local values prevent Wikidata pulls.
3. Wikidata being unreferenced is something we can easily fix. Presumably, our articles contain references already that cover the infobox. This can be added into Wikidata fairly easily. I've done it by hand without much trouble and as RexxS noted, there's a few gadgets to aid.
4. Regarding the publisher/distributor topic: From an encyclopedic point of view, why should Nexon be removed? It should be noted with a date range to show they are no longer publishing, but from a historic view point, they should be captured somewhere in the article. Thoughts?
5. We'll definitely keep working on this and refining it.

Just quick thoughts, been very busy IRL but am still watching over this for issues. -- ferret (talk) 00:35, 10 August 2016 (UTC)

"why should Nexon be removed?" - It's a lot of work and results in a lot of clutter. Not sure if that's a encyclopedic answer, but there you have it. SharkD  Talk  01:42, 10 August 2016 (UTC)

The article itself does say "In November 2015, Nexon announced they would no longer be operating servers for Dota 2, allowing Valve to take over direct distribution and marketing of the game in those regions." if that's what you mean. ~ Dissident93 ^(talk) 02:21, 10 August 2016 (UTC)

I think the issue is less that Wikidata contains Nexon, and therefore shows it, so much as the current way of pulling the data doesn't integrate the qualifiers and add necessary context. For example, Nexon should say "Nexon (JP, 2004-2007)" or something similar. This can be accomplished with a sub-template/module. I can create {{Infobox video game/publishers}} and have it format the Wikidata pull with further information like that. THis is likely what will be required for the Released field anyways, i.e. {{Infobox video game/released}}. -- ferret (talk) 10:31, 10 August 2016 (UTC)

Remove wikidata edit links

I can't imagine how a discussion on this tiny corner of the wiki was allowed to make changes to almost every VG article without some sort of announcement that contributors like myself would see. Instead, the echo chamber went ahead with this change with no input from the hoi polo, with a total of what, four people involved? It went from proposal to in-flight in a total of five days. It was only mentioned to the wider VG audience after it was turned on.

In any event, the change sucks. It adds whitespace to every VG infobox. That would be fine if it did something useful, but it doesn't. Quite the opposite, I can't imagine why anyone would want to visit another project to edit data that is actually primarily on this project. If this were information that was being transcluded back, like images from the Commons, that would be one thing. But in this case it's the opposite direction, there's literally no reason to ever want to edit there. And even then, Commons transclusion first links to a page here on en.wiki, specifically to avoid problems like this.

Turn it off and send it into the VG for a wider vote. This is a major violation of the trust of your fellow editors, and flies in the face of every policy and ad hoc rule we have specifically to prevent small groups from wielding undue power by hiding in corners and having private discussions.

Maury Markowitz (talk) 12:00, 11 August 2016 (UTC)

@Maury Markowitz: Here are some replies:

1. This has been advertised multiple times prior to turning on, and been socialized with (at least) WT:VG since 2013. That that's the only instance you were able to find doesn't mean other instances don't exist.
2. Adding whitespace is not categorically an issue, much less is it, in this particular case, an instance where I agree with you. However, I have just added a class to the template ("wikidata-link") which you can use to hide the edit link; you can add tr.wikidata-link {display:none} to your User:Maury Markowitz/common.css to remove the link, everywhere on Wikipedia.
3. I have suggested, just above, that the link to edit on Wikidata should be removed where the infobox is pulling no data from Wikidata. Does that satisfy your 'usefulness' concern?
4. The point is to get us to the Commons model. I can't point to a "big" article that uses the infobox in this way currently, but ferret can. Air Control (video game) uses it on a small level.
5. Commons transclusion first links to a page here on en.wiki, specifically to avoid problems like this. is not quite the true state of things, but that's an aside. There is work being done to make it easier to edit Wikidata from the client wikis (such as en.WP).
6. Please see the rather large RFC at WP:Requests for comment/Wikidata Phase 2. In no way is this a case of a small group wielding undue power by hiding in corners and having private discussions. Please do not make personal attacks on the editors who have contributed to this discussion.

--Izno (talk) 12:43, 11 August 2016 (UTC)

The discussion you link to has nothing to do with VG, and is three years old. I don't think it's a stretch to suggest that this does not count as a public airing of the discussion taking place here, three years later. Adding to the issue, that discussion concludes "this modification should be done carefully and deliberately, at least at first." Is this an example of careful and deliberate? I would argue no.

You suggest that there has been consensus, or at least reasonable discussion, in VG. As far as I can tell this is simply not the case. Over the last six months or so the topic has only come up in passing, with perhaps a dozen short posts in total, and nothing remotely like a full discussion. A somewhat lengthier discussion took place in VGR, but that's another lesser-traveled area and the discussion is by the same people, discussing technical issues. In total there's perhaps a half dozen people that have posted more than a couple of sentences on the topic, and the most recent of those is someone asking how to turn it off.

Sadly, finding any such discussion is extremely difficult, because the header now includes the post-facto notification string, so every single page in the talk area shows up if you search. So if I'm missing any sort of lengthy RFC decision making process that took place, mea culpa, please point me to anything recent on the topic in the main pages.

As to the suggestions: no, editing my display template is not a suitable answer for a problem that others are also complaining about, and no, removing the link if it's empty is not a solution to the problem. This entire concept is problematic, from transclusion of data the editor does not want and can't control, to all sorts of V issues, to the fact that there is little confidence in the data.

Maury Markowitz (talk) 16:12, 11 August 2016 (UTC)

Required to mention: I'm leaving for two weeks starting this afternoon. Maury Markowitz (talk) 16:13, 11 August 2016 (UTC)

I think I'll just disengage with you if your opinion is that the entire concept is problematic. --Izno (talk) 16:19, 11 August 2016 (UTC)

Have to agree with Izno. It does not seem your issue is about this infobox in particular, which follows established convention of other wikidata enabled infoboxes, but with Wikidata as a concept in general. The RFC Izno linked established the consensus as far as that goes. -- ferret (talk) 17:40, 11 August 2016 (UTC)

Izno, I tried using the above code on my css page to remove the link, and it hasn't worked. The link is still appearing. Any suggestions? Cheers. Bertaut (talk) 22:00, 11 August 2016 (UTC)

Bertaut The link is currently removed entirely pending discussion. If you're still seeing it, try purging the page in question. -- ferret (talk) 22:05, 11 August 2016 (UTC)

Thanks Ferret, that's done the job. Much appreciated. Bertaut (talk) 22:20, 11 August 2016 (UTC)

"Microsoft is just a disambiguator"

As changed by Czar ealier this morning, according to him, the "Microsoft" in "Microsoft Windows" is just there to disambiguate from the plural of "windows". It has so far only been him who is enforcing this way of using Microsoft Windows, as he is forcing this into the Microsoft Windows article as well. As far as I know there was no consensus on this. Windows truly is the common term, but if we consider it the term, we should get it moved to "Windows" instead of always having a redirect or a pipe. But first we would need to know, does everyone agree with this? All Windows logos up until Windows XP's included the "Microsoft", so it at least was the official, full title, and I do believe it still is, just cut off since Windows Vista's logo for whatever reason. So what do you think, leave or change? Lordtobi (✉) 15:02, 2 July 2016 (UTC)

All of our sources in the overwhelming majority of cases describe releases for Windows and/or PC, but never "Microsoft Windows". The latter terminology has been used and reused most likely because "Microsoft" is used as a natural disambiguator for the operating system's Wikipedia page (i.e., "Windows" was taken and "Microsoft Windows" is preferable to "Windows (operating system)"). Article titles on WP only occasionally go by their "official" title—more importantly, our use of terms should follow the precedent of reliable, secondary sources.

As for the other points: "Microsoft" as natural disambiguation means that it used and piped the same way that "(operating system)" disambiguates—it doesn't get special treatment or have special need to become the primary topic for the phrase "Windows". (I would think that physical windows are the primary topic here, but note that as of this comment "Windows" does redirect to "Microsoft Windows".) And as for official titles including the developer, I invite you took at Nintendo GameCube and Sega Dreamcast naming discussions. czar 16:59, 2 July 2016 (UTC)

I think this type of discussion is one that needs to be normalized with other software projects across WP. There is similar inconsistency within {{Infobox software}} whether to spell it out. My concern is that to anyone in computing "Windows" is crystal clear in context, but would not make sense to a layperson who has no idea about software. --MASEM (t) 17:33, 2 July 2016 (UTC)

Even if it's context-dependent, whether it's listed as a platform in the infobox or among other platforms in prose, I find it hard to consider contexts where "Windows" without "Microsoft" is any more ambiguous than any other operating system name. And this aside, context is a prose issue. I wouldn't introduce "Windows" the same way that I wouldn't introduce "Xbox" without context that it's a gaming platform. czar 06:35, 30 July 2016 (UTC)

I've considered making this change many times myself. It also seems clear to me that the "Microsoft" in Microsoft Windows' article title is there purely for disambiguating the common name, and can be piped-away like any other, especially given its context in a list of software platforms. – Quoth (talk) 11:15, 13 August 2016 (UTC)

Add abbreviation template to WW label for world wide release date

Would it be possible to add the {{Abbreviation}} template to the {{Video game release}} WW so that it appears as WW? Maybe even do this for all the country abbreviations, kind of like what {{Drugbox}} does for the legal status of drugs in different countries (see the infobox at Amphetamine for example). I'm not sure everyone reading the article is going to instantly understand what the abbreviations mean. Sizeofint (talk) 05:26, 16 August 2016 (UTC)

I've added it for "worldwide" to Template:Video game release and Template:Video game release as that is uncontroversial.

I'm not sure the links need them, as each of those carries a title attribute providing the title of the page linked. --Izno (talk) 11:25, 16 August 2016 (UTC)

Thanks! Somehow I completely missed that the other country names were linked. Sizeofint (talk) 19:06, 16 August 2016 (UTC)

Wikidata - On going

I'm creating a new section to discuss specific future enhancements and efforts. The above section was intended more to capture issues directly stemming from implementation. I am starting this section with three sub-sections that further work or discussion have already brought up. Please create a new subsection if you have concerns/ideas/thoughts on a specific field -- ferret (talk) 11:02, 10 August 2016 (UTC)

Publisher

In the above section for Go-Live there's a lot of discussion centering on the publisher field, such as displaying publishers for non-English regions or publishers who no longer publish. From a historic point of view this data is accurate and therefore should not be removed from Wikidata, which does not obey or honor the display rules of this template. For now, this means if Wikidata has more than you want, you'll have to use a local value like in the past. I suspect there's very few articles that lacked a local publisher value, so I don't think we're causing any trouble on current articles, but we need a solution to better integrate qualifiers here.

General suggestion: A sub-template like {{Infobox video game/publisher}} will pull publisher information along with their qualifiers, so that more concise data can be generated, such as "Nexon (JP, 2004-2007)". -- ferret (talk) 11:02, 10 August 2016 (UTC)

Any further thoughts on how to qualify/filter/display publishers from Wikidata? Otherwise I will look into trying to implement a "Publisher (region, startyear-endyear) format. -- ferret (talk) 14:07, 19 August 2016 (UTC)

Released

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

This is going to be impossible to get exactly right for the expectations of the project, probably, but I believe we can get an approximate that works in most cases. Likely, release dates will be the most commonly overridden field in the end though. Please read the proposed logic and let me know your thoughts:

The documentation, for quick reference: "Add release dates according to the platforms field, for English-language regions and the developer's region. Use only general public release dates, not festival, preview, or early access dates. If possible, use the game's exact release date ("July 21, 2016"). Use the {{Video game release}} template: {{Video game release}}. If there are many release dates, enclose them all with the {{Collapsible list}} template[2] and add the field titlestyle=font-weight:normal;background:transparent;text-align:left; followed by title= set as the earliest release date. Platforms can be abbreviated to fit in one line and should be listed as bolded section titles without colons, separated with commas (e.g. PS2, NGC, Xbox)."

1. Pull all Publication date.
2. Pull the developer, and check for claim country.
3. On each, check for qualifier place of publication.
4. For each place of publication, check a table of languages. If not found, tried to populate by pulling official language. If it is English, or the country matches the developer's country, then store in a table. (The table above is necessary because good ol' USA has no official language to check)
5. At this point we have all of the publication dates that are from English regions or the developers country. (To best of our ability to determine).
6. For each publication date, pull the qualifier platform if available.
7. Group dates/regions by platform.
8. For each platform, sort publication date.
9. For each platform, output: Platform {{video game release}}.
10. If more than X total platforms, wrap the entire thing in {{Collapsible list}}.

Caveats: If one platform, exclude platform.

This is a very rough draft of the logic. It should produce something akin to typical displays, but there's going to be no way to make it perfect for the more nitpicky editors. -- ferret (talk) 13:53, 21 July 2016 (UTC)

Would this be easier by adding the region on the video game item? I think we'd need a new property for that, but it sounds like it would mostly fix the mess above. --Izno (talk) 13:56, 21 July 2016 (UTC)

Need more details on what you're thinking. Would region be a qualifier on the publication date? Note the diff of this edit, I adjusted the logic some because I got off in the weeds. We don't need the language of the developer, only it's country. Language is only needed to filter place of publications that do not match developer. -- ferret (talk) 14:11, 21 July 2016 (UTC)

Yes, a qualifier on the publication date. --Izno (talk) 14:21, 21 July 2016 (UTC)

Which would naturally (duh) publication location, which I believe exists presently. --Izno (talk) 20:29, 21 July 2016 (UTC)

Yes, place of publication. -- ferret (talk) 21:23, 21 July 2016 (UTC)

• I think a lot of this struggle could be for naught. More often than not, none of these dates are sourced in articles. We end up having a giant list of dates that are only off by a day or two that should really be explained better in prose. For the minimum viable infobox, I would think that you only need to have the first release date up, similar to how the film etc. infoboxes do it. You can try to code something that approximates the mess that we currently use but personally I don't see the use. czar 19:09, 21 July 2016 (UTC)
  • I agree, I don't really see the point in making this needlessly more complex. ~ Dissident93 ^(talk) 01:02, 22 July 2016 (UTC)
    • @RexxS: Is there a Module:Wikidata call that will pull the earliest date for a property? GetValue looks like it grabs everything. If not I'll whip something up quickly. -- ferret (talk) 16:34, 3 August 2016 (UTC)
      • @Ferret: There's no call written to do that filter; getValue is intended to return the list of values for a given property. You'll need to iterate through the property values and look for start date qualifiers. The values of those are time stamps which are strings, but they will still sort/compare cleanly, except that you'll have to watch out that some might be a year (["precision"] = 9) stored as something like ["time"] = "+2016-00-00T00:00:00Z" which sorts/compares "earlier" than 1 January 2016. You may also need to allow for the theoretical case when two values of the property have the same start date. Cheers --RexxS (talk) 18:24, 3 August 2016 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The above is the original subsection for the Released parameter. I want to let the old section archive off so copied here. I think we have to wait on the general discussion about the Released field before we can do something "final here". General suggestion if we want something quick for now: A sub-template named {{Infobox video game/released}} that will pull and display only the earliest publication date. No region will be listed. This is simply to add some functionality, and would not be expected to be the permanent solution.

@RexxS: Regarding the dates, Module:Date is "Wikidata" aware now. Johnuniq updated it to understand their date structure recently in support of the review score module. -- ferret (talk) 11:02, 10 August 2016 (UTC)

Current discussion appears to support having Wikidata only pull "the earliest" publication date, at least to start. More advanced formatting would be done as a local value. Anyone got other ideas? -- ferret (talk) 14:08, 19 August 2016 (UTC)

I think we should bite the bullet on this one and leave it Wikidata-disabled for now, since a) there's not a lot of pull at present to implement it and b) the rules are pathological. We can revisit this in the future. --Izno (talk) 14:24, 23 August 2016 (UTC)

Distributor

Online

Can you hide Steam as the distributor? We don't include digital-only ones in the normal infobox, but it was showing. ~ Dissident93 ^(talk) 03:50, 11 August 2016 (UTC)

Another arcane rule set that will be somewhat difficult to implement right. How do I determine if a particular distributor is "digital-only"? Will require a special sub-template {{Infobox video game/distributor}} to filter either a set list of values out, or handle the data pulls to determine if a given distributor is "digital-only". -- ferret (talk) 11:22, 11 August 2016 (UTC)

I think "pathological" is more correct, since that rule is new from within the past year or two. :D --Izno (talk) 11:40, 11 August 2016 (UTC)

It's still no excuse to ignore what passed consensus though. And again, all this has done so far is create new issues/more work for editors for no real gain. ~ Dissident93 ^(talk) 20:32, 11 August 2016 (UTC)

I have to disagree. It's about enriching Wikipedia as a whole, not just enwiki. This helps populate Wikidata and allow every Wiki to use the same data. Where it doesn't work here on enwiki, a local value can be supplied, exactly as has always been done. There is no extra work, nor any mandate to remove existing local values. Just do what you've always done if a particular field needs it. If Wikidata just doesn't suit you at all, completely ignore it and do as you've always done in the past. It is simply a new option in our toolbox, and we'll continue to improve it. -- ferret (talk) 21:02, 11 August 2016 (UTC)

At this time I do not have a suitable way to filter distributor, or any suggestions to implement. If distributors from Wikidata do not fit a particular enwiki article, a local value should be used. -- ferret (talk) 14:10, 19 August 2016 (UTC)

I just used the hidden markup to override it, but this still isn't perfectly ideal. ~ Dissident93 ^(talk) 20:12, 19 August 2016 (UTC)

That is the correct/accepted way to do it per the last major RFC for Wikidata inclusion in Infoboxes (Which yes, I know, was 3 years ago). The hidden comment isn't necessary but is nice and informative. If someone can suggest a reliable way for us to mark distributors as "online only", I can build a method for excluding them from display here on enwiki. -- ferret (talk) 20:59, 19 August 2016 (UTC)

@Ferret and Dissident93: Steam (and all other methods of distribution) should be in distribution, not the distributor property. --Izno (talk) 15:31, 31 August 2016 (UTC)

Then there's no action to take here on the infobox, we just need to make corrections if we find Steam listed in distributor, versus distribution. -- ferret (talk) 15:47, 31 August 2016 (UTC)

Same as publisher

• Is there a way we can detect if the publisher is the same as the distributor? In cases like Fallout 4, Bethesda is listed twice, as both publisher and distributor. (I have personally removed it from the wikidata) I thought this is our consensus, or at least our common practice? AdrianGamer (talk) 12:58, 25 August 2016 (UTC)
  • @AdrianGamer: It should only be removed from Wikidata if it's wrong. To suppress it from displaying on enwiki, specify an empty distributor with |distributor=. Please add back to Wikidata. See WP:VG/WD for more detail. -- ferret (talk) 13:01, 25 August 2016 (UTC)
  • "distributor" was misspelled at Fallout 4. Fixed. -- ferret (talk) 13:12, 25 August 2016 (UTC)

    @Ferret: I think it would be pretty easy to do a check in the template using just the getValues and some simple parser functions (or maybe a lua function to do comparison) to do the suppression as requested. --Izno (talk) 13:23, 25 August 2016 (UTC)

    Tested in this diff. This works except in one case. If the local |publisher=[[Bethesda Softworks]], and distributor pulls the same value from Wikidata, distributor will still display. This is because Module:Wikidata is using a piped link (Wikidata EN label, piped to Enwiki article). The outputted display is the same, but the values during the comparison differ so it doesn't catch it. If |publisher=[[Bethesda Softworks|Bethesda Softworks]] is used, distributor is suppressed. -- ferret (talk) 13:35, 25 August 2016 (UTC)

I've implemented this. As long as publisher and distributor are exactly the same, distributor will be hidden. Note that a local enwiki publisher may cause distributor to display due to Module:Wikidata building the wikilink differently. In these cases, either remove publisher so both use Wikidata (Which should hide Distributor) or set a local value for distributor to hide it. Either should work. -- ferret (talk) 14:57, 29 August 2016 (UTC)

Hide "edit on Wikidata" when infobox pulls no data from Wikidata

Animal Farm

Author	George Orwell
Pages	92

This one seems like sugar, but it doesn't make sense to stuff the link in someone's face if the data isn't on Wikidata yet. --Izno (talk) 11:39, 11 August 2016 (UTC)

This would require one of two things. More drastically, a complete rewrite of the template into a module so that pulling of values can be tallied and determined if nothing was pulled. Less drastically, a new method in Module:Wikidata that takes a list of properties and returns the total count of populated items. This would be somewhat simple but becomes complicated if we do sub-templates for some of the rules around publisher, developer, etc. For example, what if Developer is in Wikidata, but our sub-template excludes the only value because it didn't match our region rules? Wikidata would say there's "1" value and display link. However, we're talking weird edge cases there. -- ferret (talk) 12:56, 11 August 2016 (UTC)

Secondary thought: If there's no data on Wikidata yet, isn't that a case where we want the link? I.e. "Go populate it here!". If you drop an empty infobox on a new article, that might be your clue to go populate the values for your new article. -- ferret (talk) 13:31, 11 August 2016 (UTC)

I realized after you responded the first time, and I wasn't sure if you had covered it in your response, that I may not have been clear. My suggestion is more pointed at: if all the fields in the infobox are locally filled (even if there is Wikidata), we shouldn't provide the edit link, as that's misleading to the readers/editors. --Izno (talk) 14:01, 11 August 2016 (UTC)

Third option then is possible, if ugly. Just chain checks for parameters. I.e. {{#if:{{{director|{{{designer|{{{programmer|<etcetc>}}}}}}}}}||Edit on Wikidata link}} -- ferret (talk) 14:09, 11 August 2016 (UTC)

Another alternative is to place the edit-on-Wikidata icon after each value that is called from Wikidata, as is done in Module:WikidataIB - cribbed from the way the French implemented it. It's built into the call so only shows when a value is returned. You then don't need a separate link at the bottom. Here's a demo adopted from {{Infobox book}}. I'm pretty sure it's the most functional solution; I'm equally sure that it won't be liked by those who are used to doing things the way they always have done. --RexxS (talk) 15:56, 11 August 2016 (UTC)

Due to the discussion at Wikipedia:Village pump (technical)#"edit on wikidata", other adminstemplate editors have looked to revert the link, so I've removed it while discussion continues. I disagree with removing it, since it follows the basic convention established by other Wikidata-enabled infoboxes. -- ferret (talk) 17:42, 11 August 2016 (UTC)

I don't see any admin looking to revert the link, just GeoffreyT2000, a template editor since 17 July 2016, taking three attempts to blindly revert the wrong change. I'm happy to wait a while for further discussion here, but I'll give notice that unless there is consensus not to have the link, I'll restore it in the near future. --RexxS (talk) 18:45, 11 August 2016 (UTC)

Noted, adjusted above. -- ferret (talk) 19:28, 11 August 2016 (UTC)

Why are we discouraging visitors from editing things on Wikidata? SharkD  Talk  01:48, 26 August 2016 (UTC)

Title

There is a title attribute. We should use it, where the language is English. For most video games, we might even able to fall back to "any claim made" before needing to fallback either to local definition or to the PAGENAME. Suggested order of priority:

• Wikidata, in English
• Wikidata, not in English
• User definition
• Pagename.

--Izno (talk) 13:29, 23 August 2016 (UTC)

Should we use a title property? Or just use the item label? Since Wikidata doesn't do "Fallout (video game)" as the label. Would need to add a "getLabel" to Module:Wikidata first. I'll craft one on the sandbox in a little while. -- ferret (talk) 13:38, 23 August 2016 (UTC)

Title is a bit safer/less prone to vandalism right now. Also, sometimes, the label doesn't match the English article (though I haven't noticed any cases where that's true of a video game, it's sometimes or even especially true w.r.t. editions of written works). --Izno (talk) 14:10, 23 August 2016 (UTC)

Ok will let this sit for a couple days to gather comment but seems uncontroversial. One problem as proposed, I believe Module:Wikidata will only return English strings. So it won't do the second bullet.. (Need to check...) Otherwise will add this weekend. -- ferret (talk) 14:13, 23 August 2016 (UTC)

@Izno: Module:Wikidata does not have an appropriate function for this logic. It would output all values of P1476 regardless of language. I will have to build something that will filter to just EN. Will be a bit longer on this one. I am not planning to try to do the second bullet, because I don't have a way to determine the best language to return if EN is missing but multiple others exist, other than "the first one found". -- ferret (talk) 18:50, 26 August 2016 (UTC)

Oh, no hurries, and not worries about the 'best language'. --Izno (talk) 19:10, 26 August 2016 (UTC)

When Module:Wikidata was written, there was no monolingual text, so there's no function to fetch it. Monolingual text is only useful if you have text available in different languages, so I'd have to ask why you'd want the title of a video game in some language other than English? Do we have infoboxes in articles for videogames that have no English title? Anyway, the function getImageLegend has the code to get whatever language is desired for the property media legend (P2096), so it should be simple to adapt for what you want, if there really is a need. --RexxS (talk) 21:23, 26 August 2016 (UTC)

Do we have infoboxes in articles for videogames that have no English title? Actually, yes, come to think of it. There are older titles and even the occasional new title that see release in e.g. Japan first and don't receive an English name (except either as a literal translation or an unreliable-sourceable not-quite-so-literal translation) that aren't the actual titles of the games. I'm thinking Japanese predominantly... --Izno (talk) 21:43, 26 August 2016 (UTC)

Okay, what are our articles called? Do you have an example? --RexxS (talk) 02:01, 27 August 2016 (UTC)

Take a dip into Category:Visual novels for a few--mostly using transliterated Japanese. --Izno (talk) 14:35, 27 August 2016 (UTC)

I took a dip, but it seems all of the articles I looked at have usable English article title, and that is used in the infobox. Not one of them had a Wikidata property title (P1476), so I'm still clueless about what you're trying to fetch and how it would fit into the infobox. That doesn't matter though. --RexxS (talk) 16:15, 27 August 2016 (UTC)

@RexxS: Dai Gyakuten Saiban: Naruhodō Ryūnosuke no Bōken, 11eyes: Tsumi to Batsu to Aganai no Shōjo, Akaneiro ni Somaru Saka are just a few on the first page.... --Izno (talk) 15:41, 1 September 2016 (UTC)

@Izno: I didn't miss them. Dai Gyakuten Saiban: Naruhodō Ryūnosuke no Bōken is a usable title for the infobox and The Great Ace Attorney: Adventures (Q17338571) has no title (P1476) property. Same for 11eyes: Tsumi to Batsu to Aganai no Shōjo (Q1347470) and Akaneiro ni Somaru Saka (Q1205695). I'm still at a loss to see what you're hoping to do. Apologies for being a dinosaur of small brain. --RexxS (talk) 16:17, 1 September 2016 (UTC)

Links

Is there a point to "wikilink" people that has no page? In the case of Dishonored 2, It seems unhelpful to do so, if the wikidata page is only going to tell me that he is a game designer. It looks rather clumsy, having [*] all over the place. There is another issue with it. In the case of Tom Clancy's The Division, it is essentially cheating to list the game engine, since we decided not to list them unless they have a page. In addition, is there a way we can apply plainlist or something similar into this wikidata stuff? It looks terrible, since there are so many names mentioned together in one line. As a whole these wikidata stuff does not look good, especially with that giant icon (Edit on wikidata). I would prefer having a small [edit] icon right next to the top of the infobox, or a small "E" in the top left or top right corner, similar to how the navigation template talk page is handled. AdrianGamer (talk) 12:58, 25 August 2016 (UTC)

The output is generated by Module:Wikidata. Please use the talk page there to discuss changes to the formatting. It affects all Wikidata enabled infoboxes on enwiki. There is already a discussion to change the [*] to a link icon for clarity. -- ferret (talk) 13:02, 25 August 2016 (UTC)

Regarding an "Edit on Wikidata" link, it is currently removed entirely. I am opposed to the small "E" at the top because the typical convention is used to link to editing the template itself. Infoboxes suppress the display of it currently. Regarding the engine, specify |engine= to suppress the Wikidata display. This is the accepted RFC backed convention on enwiki. -- ferret (talk) 13:05, 25 August 2016 (UTC)

Didn't know it was so simple. Thanks for replying. AdrianGamer (talk) 13:16, 25 August 2016 (UTC)

@AdrianGamer: Please let me know if WP:VG/WD needs further work. It's new and I'm trying to make sure it gets seen. Izno did a pass over it, but if there's any details you or anyone think is lacking, please let me know. I added an example of suppressing engine. -- ferret (talk) 13:19, 25 August 2016 (UTC)

Other templates

Will be taking a look at the complexity for Template:Infobox video game series soon. There are several others that need work as well. -- ferret (talk) 12:29, 25 August 2016 (UTC)

ISBN and OCLC numbers

I am using WorldCat, and I am seeing that video games also have OCLC numbers as well as ISBN numbers (but why ISBN? They are not even books!). That information may be useful to add to the template, or it may not be, but who knows? Gamingforfun³⁶⁵ (talk) 18:53, 17 August 2016 (UTC)

This information is available from Wikidata, should this field be added to the infobox. However I do not think it has any real value to us and should be left out. -- ferret (talk) 14:13, 19 August 2016 (UTC)

Not in the infobox. OCLC numbers are interesting, I suppose, but should be in the external links (either using {{authority control}} or otherwise). --Izno (talk) 13:13, 23 August 2016 (UTC)

OCLC #s are only as good as its member libraries that collect games—which isn't many. Not much use for this, especially right now czar 21:19, 10 September 2016 (UTC)

How to remove autopull

Instructions should be much clearer on how to prevent the infobox from pulling from Wikidata either in a single field or in toto. czar 21:20, 10 September 2016 (UTC)

Expanded on this in the guide, here. I'm not sure the best way to work it into the template's direct documentation. -- ferret (talk) 21:35, 10 September 2016 (UTC)

@Ferret, what about this case? czar 06:44, 12 September 2016 (UTC)

Logic issue related to making sure to italicize only Wikidata pulls (As existing data in Enwiki local values already has italics). Similar to a previous logic issue for genre/mode. See this sandbox diff. I do not have time this morning to do full use case testing and move live, but will try to get to it later today. For now I switched Wave Race 64 to the sandbox. -- ferret (talk) 12:02, 12 September 2016 (UTC)

 Done -- ferret (talk) 21:49, 23 September 2016 (UTC)

Suggesting Version field

Could we get a new field named "Latest Version" or "Current Version"? Recent years have seen more and more games being released as early acess titles, and receiving regular updates. This is a needed addition, at least IMO. Wikipedia already has this field in other languages. YuriNikolai (talk) 02:32, 21 September 2016 (UTC)

• Oppose. We removed it in the past. It's just a number with no meaning to the general reader. It adds nothing. The infobox's purpose is to summarise key information in the article body and version number is not important or noteworthy enough to be mentioned in an article.--The1337gamer (talk) 06:12, 21 September 2016 (UTC)
• Please review the discussion at Template talk:Infobox video game/Archive 11#Proposal for removal of Version field. --Izno (talk) 11:55, 21 September 2016 (UTC)
• Oppose per above arguments. If it's really that important to document, a Wikidata field for it exists. Also, English Wikipedia guidelines do not apply on other languages and vice versa, so that's not a good argument for it. ~ Dissident93 ^(talk) 19:01, 21 September 2016 (UTC)

• CommentI agree with the previous arguments. Instead, how about a field stating the "Current stable release", with emphasis on the date, not version number? Infobox software already has this, and i think it's an useful way of checking if there have been changes. — Preceding unsigned comment added by YuriNikolai (talk • contribs) 01:58, 24 September 2016 (UTC)

Release date formatting

Currently:

Use the {{Video game release}} template

Proposed:

Use the {{Start date}} template or, if appropriate, {{Video game release}}

Another editor is edit warring to add {{Video game release}} to article infoboxes even when it isn't warranted. Most of the games I write about do not specify region when giving release dates, so I think it's inappropriate to add a "WW" automatically in front of the date. Start date is the simple format we've used for a long time but I'm fine with not requiring a template in this field at all, but for editors who like to throw the book at other editors, I'd like to clarify this in the guideline as {{Video game release}} is not always an appropriate template. (And re: using it without specify a region, see its talk page—it is not designed to be used without specifying a region.) czar 01:34, 21 October 2016 (UTC)

Multiple release dates in the infobox

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Per the discussion at Template talk:Video game release new#Font size is not accessible, I think we should reconsider our standard of shoving every release date into the infobox. Here are a few reasons:

1. The content is almost always unencyclopedic. For all the parading of the difference between NA/EU/AUS region releases, the difference is at most a week, on average. In all of my editing, I cannot recall this date difference being of importance to any of our sources, nevertheless a fact that readers need to see. (Is there any encyclopedic purpose for knowing that the official release date was first in NA instead of Europe? Not according to our sources.) I doubt whether these specific dates are in our purview.
2. They are rarely or atrociously sourced. Like most of the infobox parameters, they are more likely to be unsourced than if they were included in the text. (Really they're supposed to be included in the text but more on that below.) We don't have any canonical source for release dates. We have yet to verify the origins of IGN's dates (yes, I've tried contacting them), but they were associated with the site's user-contributed wiki for some time. We dropped GameFAQs/MobyGames as a source for dates a long time ago. In the end we're really trying to pull what historic press releases and routine reporting says, but I can even attest with Videoball's recent release and all kinds of reporting on breaking street date that not even modern dev release dates necessarily match what was reported...
3. Which brings us to citogenesis. Gaming culture, and our editors likewise, have a fruitless obsession for exact release dates when often ranges or simply "MMMM YYYY" would be a better fit. We host reams of unsourced, specific dates, that often make their way back into user-submitted databases and make us just as guilty for perpetuating inaccuracies. Our dates are supposed to be sourced—full stop—and if we can't do that well, we need to look at whether we are a good source for compiling that information. I have my own doubts about the accuracy of information we now pull from the newer Nintendo sites (Nintendo Life, even NWR) as they often have release dates in our format that match our exact dates, yet I haven't been able to find any secondary source verification even in historic newspapers for such dates. I assume that they pulled their data from us or another untrustworthy source.
4. They belong in prose. We all agree that the release dates, if important, should come from secondary sources and be cited in prose. But we also agree that they make for really, really boring prose. Prose that I don't think should even withstand a FAC review. I've grown into the habit of relegating the cited release date prose into an endnote so it's there for those who want it but not in the text to bore anyone else. It would be better visualized...
5. That a game was released first in North America or Europe by a few days is unadulterated trivia. This is one of those relics of the age in which Wikipedia articles had more trivia and game guide sections and less focus on Reception and Development. In my years of editing, I have never seen a source besides us ever substantively care that the title released first in a region, apart from its listing as a matter of fact. It would be more accurate to say that the game released in the beginning of a specific month, or to similarly generalize the release windows. If this information is too clunky for prose, I think a visualization by way of a Development/Release section template would be in order, similar to how we've visualized review scores or chronologies within a tricky series when warranted by the sources. For instance, we help very few with the mess that is our Doom smorgasbord of infobox dates, but perhaps we can visualize the releases better within their appropriate section and focus less on the regional releases of the minor releases, which are truly inconsequential.
6. It is the most Frankensteined infobox parameter that I can recall out of any infobox I've seen, with multiple formatting styles (bold subheaders, superscript regions, regular dates requiring multiple templates). The infobox is meant for reporting the most important information simply, and the key detail here is when the game was released. All other specifics beyond that original release are supposed to be in prose. We would be following the standard of every other major media infobox template by only listing the date of first release.
7. In advance of any handwringing over making a major change, we had the same situation with every other major template change (dropping media format params from the infobox, dropping GameRankings as a vg reviews necessity) but there has never been an issue as long as the consensus is documented and the reasoning is sound.

My suggestion is to remove all but the first major release date from the infobox, à la the other media infobox templates, and to brainstorm a better template for illustrating the differences in release dates when they are consequential (significant differences across multiple platforms or regions). Perhaps even a timeline? I would also suggest that we adopt language in our WikiProject guidelines to encourage release dates to be put in engaging prose with relative dates or else relegate them to endnotes. All in all, we should follow the lead of our sources by putting less emphasis/importance on specific dates, especially for older releases, and more emphasis on relative dates (MMMM YYYY or with early/mid/late prefixes or date ranges instead of X in NA, Y in Europe, Z in Australia). czar 06:36, 30 July 2016 (UTC)

• I agree with most of what you said, exact release dates don't really matter in the long run. The lead sections of (well written) articles already have generalized release info, which is simply better prose if read out loud. ~ Dissident93 ^(talk) 09:44, 30 July 2016 (UTC)
• I would say that for games that take a long time to get released in other regions than the one it originated from, such as Mystery Dungeon: Shiren the Wanderer (1995 in Japan, 2008 in the West), this time difference is important enough to be in the infobox. I think I would prefer to include the first release date for each major region in the infobox, while the rest should be moved elsewhere (but not deleted entirely). --IDV^talk 10:53, 30 July 2016 (UTC)
  • Yeah, info should be generalized, not simply removed all together, as then you could make the case if release dates matter at all. ~ Dissident93 ^(talk) 11:12, 30 July 2016 (UTC)

• I agree that having regional release dates in the infobox is unadulterated trivia and that they must be removed ASAP. In fact, I previously proposed ditching them from the infobox, but no consensus was reached. However, I disagree with the fact that only one release date should be included in the infobox. Unlike films, albums, or novels, video games are tied to a platfrom, and knowing the original platform for which the game was developed is an important piece of information that should be included. I propose the following: combine the release date and platform fields together and simply call the resulting field "Release date(s)". This would include a list with two things: the first release date and its corresponding abbreviated platform. Here's a Resident Evil 3 example:
  • Sept 22, 1999 (PS)
  • June 16, 2000 (PC)
  • Nov 16, 2000 (DC)
  • Jan 23, 2003 (GC)
    • --Niwi3 (talk) 13:20, 30 July 2016 (UTC)
• I agree with this in a general sense and originally stated it at the other talk page, including making something akin to {{Video game timeline}} to hold more detailed information (Not necessarily that format, but in that style of template format). Niwi3 just to ensure we have a clear example, in your setup how would you present multiple platforms from the same date? Would it be: Sept 22, 1999 (PS, PC)? Note that the outcome of this discussion could lead to a much more consistent format I can use in Wikidata pulls. -- ferret (talk) 14:12, 30 July 2016 (UTC)
  • @Ferret: Yeah, that would work for me. Even better, we could create a template that is similar to Template:Video game release, but with platforms instead of regions. --Niwi3 (talk) 17:41, 30 July 2016 (UTC)

• There are some exceptions I would make, but would argue that release dates that are all within the same week, perhaps month, should be treated "equivalently" for purposes of the infobox. This would make cases like how most Japanese games come to the West stand out, how some ports take months to come to some systems, but normalize games that come out in different regions and on different systems within the same week as having the same effective release date. I will note that sometimes a matter of days is not as trivial (for example, No Man's Sky, there was actual sourced discussion about a two-date delay in the UK version which was resolved to get it released at the same time as the EU), but that's all good for prose, not infobox. --MASEM (t) 14:51, 30 July 2016 (UTC)
  • No no no no no no no no. We had this exact discussion just six months ago, proposed by Czar as well, and concluded that it was not a good idea. Calling the release date field of the infobox "unencyclopedic" is fundamentally misunderstanding its purpose. The true purpose is to tell me "at a glance" whether a game has been released in my (English-speaking) region. I shouldn't have to sift through prose to figure that out. If the release date was in fact simultaneous worldwide, collapsing it into one date without calling it out specifically makes me uncertain if it was actually released in my region, especially if I live in a "secondary" market like Australia (this is a US WP:BIAS problem).
    • Hmmm. So if you look in the box and you don't see your region, does that mean it's not released, or they just didn't add it? You can't know, so that renders it useless. Further, if this is presented it's useful for what, a week? And is this information not trivially available on many other websites? Maury Markowitz (talk) 17:02, 30 July 2016 (UTC)
  • The solution to #2 is to source them. "But it is le hard" is not an excuse to just remove that information altogether. Proper sourcing fixes #3 as well. For #4, I actually disagree that it belongs in prose. It only belongs in prose if, as you say, there's something notable to talk about differences in release dates. If not, then there's no need to repeat it in prose. It's a complete straw-man to call release dates "trivia" in the same way that a list of guns in Call of Duty is trivia. In the case of Doom, it's true that a better visualization would benefit the reader more, as long as the data remains whether that's in the infobox or somewhere else.
  • As I said last time, this is a solution in search of a problem. We already have a perfectly functional answer to the release date parameter getting too long in Template:Collapsible list. Wikipedia is not paper and there's no need to excise perfectly good sourced information in the name of brevity. Axem Titanium (talk) 16:51, 30 July 2016 (UTC)
    • Pinging all the participants of the previous discussion. @Rhain, Maplestrip, Favre1fan93, Maury Markowitz, AdrianGamer, Hellknowz, Famous Hobo, JDC808, Hahnchen, and Sergecross73: Axem Titanium (talk) 16:51, 30 July 2016 (UTC)
    • The issue is not to wipe out the regions, but the granularity of them. Say a title is released on a tuesday in the US, on the immediate thursday in the EU, and the next week in AUS/NZ. From the standpoint of PAST the game's release, those all are the same time, so indicating a single WW release would be appropriate. Yes, for seven-odd says, people from Australia may be confused, but we're not writing for immediacy but enduring information, and that's the goal here. --MASEM (t) 16:58, 30 July 2016 (UTC)

That wasn't the conclusion from the last discussion... If the "solution" of sourcing the dates were viable, it would have been done already. The vast majority of our release dates are not sourced anywhere in the article and many need to be referenced directly from print. It's not a solution to leave up junk dates until someone decides to take on that gargantuan sourcing effort—until then, we have an obligation to WP:V. We have removed such trivia sections in the past when poorly sourced. (Yes, if we don't have a reliable, secondary source for regional release data, it is trivia (primary source, low-impact factoids) and not at-a-glance facts.) Your Call of Duty is a perfect example: Call of Duty 4: Modern Warfare is a FA and look at its release date sourcing—either unreliable or nonexistent. And for what? The main release dates are mere days apart. I find it impossible to trust our release date content as is. czar 19:48, 4 August 2016 (UTC)

• I'm already irritated/tired of all the constant revisions/arguments that pop up on my watchlist about not putting every platform for a game in the infobox. This sort of thing is going to double that sort of issue. It's just not intuitive - outside of the core 10-20 of us at WP:VG, everyone is going to think it's missing information. I don't like these guidelines that just increase the need for constant maintenance by our core editors. I guess it's up to you guys if you want to spend your time meddling away with this sort of thing. I'll leave that to you all. Sergecross73 msg me 17:00, 30 July 2016 (UTC)

• This is a very good point, I think.--IDV^talk 17:17, 30 July 2016 (UTC)

• Agreed, and to add my opinion to this discussion, I still hold my stance from the first discussion. --JDC808 ♫ 04:30, 31 July 2016 (UTC)

I think I addressed this above, but the issue of drive-by editors changing infoboxes has more to do with compulsion—they see a hole in the list and go find whatever date they find online and fill it in. That's a problem with its design. We've been over fear of change before and have not had any sustained problems with enforcing, for instance, removing GameRankings from the standard vg reviews box or removing ports from the infobox. If anything maintenance should be much easier once we've reduced the reason to fiddle with the infobox. Like always, users will adjust—the question is whether the change is right czar 19:48, 4 August 2016 (UTC)

Agreed. The simpler the release date field is, the easier it is to maintain, and the less likely drive-by editors will pay attention to it. I think the question is right to a certain degree, mainly because regional release dates are not just difficult to source, but are trivia that shouldn't belong to the infobox. They should belong to the body if and only if they can be backed up with reliable sources. Release dates for multiple platforms, on the other hand, are much easier to source. --Niwi3 (talk) 09:29, 6 August 2016 (UTC)

Given we're only talking about the infobox (that is, date information can be in prose where it can be readily and properly sourced), what if we took the approach that the Film project does, which is the first release date and a second release date if that first release is not necessary in the country of origin of the game (if that even really happens?) It gives the critical bit of data - the approximate time the game was released that properly serves the general reader using the infobox, and allows proper expansion in prose or in tables if the situation gets any more complex. (And regardless of any change we make, grandfathering in existing articles and only applying this new criteria in a mandatory fashion at GA/FA review levels needs to be done) --MASEM (t) 17:25, 30 July 2016 (UTC)

• Comment : List only first release dates by regions in infobox (|released={{vgrelease new|JP|18 Dec 1987 (FC)|NA|12 Jul 1990 (NES)|EU|14 Mar 2003 (PS1)}}), and change |platforms= to |platforms=Famicom (1987), MSX2 (1989), WonderSwan Color (2000) ... , then move other things into a new infobox of development section? --43.242.155.141 (talk) 03:17, 31 July 2016 (UTC)

Personally, I like the second part, but I really doubt we could accurately source the first part (or should) czar 19:48, 4 August 2016 (UTC)

Release years

Platform	JP	NA	EU
FC	1987	1990	—
MSX2	1989	—	—
WSC	2000	—	—

• I hate to see structured content disappear into thin air. The "Release years" infobox to the right of my post seems okay, though. It would be a good substitute. SharkD  Talk  10:30, 31 July 2016 (UTC)
• As long as the regional release dates are still kept somewhere in the article then I am ok with it. The release years template seems to look quite decent, and would be a great alternative. However, I am concerned that editors are just going to throw all the release dates out of the windows instead of turning them into prose/putting them into a new template if a consensus is reached. In addition, I also thought that this template would be useless in articles like Mad Max and Star Wars Battlefront, in which they would probably only have one row. And if we are really going to use the new template, port releases should not be mentioned in the infobox as well. AdrianGamer (talk) 11:54, 31 July 2016 (UTC)

I like this template as a start. I'd recommend adding a 1px black border between the column/row headings and the data czar 19:48, 4 August 2016 (UTC)

• Don't put release dates in prose. Lists of dates makes for godawful reading in the same way that strings of review scores do. I complain at FAC when video game articles have lists of release dates clogging up the development section. In prose, I will usually only state the month and year of the release, and have the details in the infobox. - hahnchen 17:49, 6 August 2016 (UTC)
• So...just to confirm, I'm not seeing any consensus for change really, right? Thought it should be outwardly stated, as sometimes editors misinterpret "having the last word in" with discussion dying off as some sort of consensus in their favor. Sergecross73 msg me 17:32, 8 August 2016 (UTC)
  • I don't see consensus but I really think we need to work this out better, maybe starting with straw polls (eg "Should we have detailed release dates by region/platform in our articles to start?"). Release date stuff is kudzu that clogs up articles, whether infobox or in prose (as Hanchan identifies above), and I do feel pushing the bulk of it to tables or footnotes or something else will make our articles read much more smoothly. --MASEM (t) 17:39, 8 August 2016 (UTC)
• I created the Draft:Template:Video_game_release_table, and tested it in Final Fantasy V#Ports and remakes and Final Fantasy VI#Re-releases. --117.136.26.138 (talk) 12:46, 13 August 2016 (UTC)
• Requesting formal close with summary of discussion, as this is going to come up again czar 01:26, 21 October 2016 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Error message and tracking category for unsupported parameters

I have added error tracking for unsupported parameters to this template. See Category:Pages using infobox video game with unknown parameters. A red error message appears when you Preview the article, between the edit screen and the rendered preview. In the category, the articles are sorted by the name of the parameter that is unsupported.

I have added this error-checking to a number of heavily used infoboxes, and it usually goes smoothly, highlighting errors that improve the articles that end up in the category. Every once in a while, parameters are missed or something goes wrong. If that happens, don't panic, just post here and I will be happy to fix it. Revert the change if you feel that you must.

If I have made any mistakes in coding, or if template changes are desired, please let me know.

One additional thought: since Category:Infobox video game with deprecated parameters is almost empty, it probably makes sense to finally remove those parameters from the template (and from the new supported parameter check, and from the documentation). The new error category will catch any subsequent uses of those no-longer-supported parameters. – Jonesey95 (talk) 06:06, 15 November 2016 (UTC)

One parameter that is in the documentation but not in the template is |show image=. Anyone know about what should be done with that parameter? – Jonesey95 (talk) 06:23, 15 November 2016 (UTC)

Remove it? It seems to be a thing from that past that I've never personally seen used. ~ Dissident93 ^(talk) 07:07, 15 November 2016 (UTC)

Infoboxes – optional plural parameters – removing (s) from labels

Hi! I've started a discussion at WP:VPR#Infoboxes – optional plural parameters – removing (s) from labels about the possibility of removing "(s)" from the end of labels in infoboxes, and as I just came across an article with it in, used this infobox as an example of one with lots of these "(s)" labels. I'd like to know what your thoughts are in general about having optional "plural" parameters (e.g. |genres= as an alias for |genre=, with labels to match), and, depending on the outcome of the discussion, whether you think this would be a suitable template for a trial run, since this seems to be a lively, well-watched template. ‑‑Yodin^T 20:39, 29 December 2016 (UTC)

Generally, this is not a bad idea, however, there is one huge problem: Every page using that infobox, almost 22 thousand, have their parameters adapted to the current format, regardless of plural or not. Hence, if you would default the current fields, except for platforms, to singular, every instance of multiple entities in a field would be put alongside a content description depcting a single one. This template is almost 13 years old now, and it has grown up without singular/plural differentiation, so it should probably kept without. Lordtobi (✉) 21:04, 29 December 2016 (UTC)

Ok, no worries :) At Template:Infobox book (38k!), this was considered, and the prevailing thought was that readers would probably not notice singular labels (i.e. that "Genre: Detective, Horror" was less bad than "Genre(s): Detective, Horror"), and editors who wanted to make the infobox grammatically correct could make the change when they noticed it. ‑‑Yodin^T 21:16, 29 December 2016 (UTC)

But that's not the point. By that logic, if readers would not notice the missing pluralism, they would also not notice if it was gramatically correct anyways. So why bother changing it in the first place? And once it would be pushed through, you cannot expect a lot of changes going down, editors would not care enough to change it every time they come across such a "wrong-grammar" case, and that being 15 years of articles. By a slight chance, editors might take an eye when writing new infoboxes, for new articles, and consider them. Note also that the Visual Editor just wouldn't care as well. Even if you put all those things aside, the small fraction of infoboxes actually being adapted would cause and incredible inconsistency between 2k with and 20k without adaption. Horrible!, especially considering that it would be used on pretty much every parameter. A better example for what you would want to achieve is Template:Infobox company, in which a total of 5 parameters uses optional plurals, however, even there the inconsistency is large; although founders, successors and predecessors are semi-frequently put correctly, the other two, owners and areas_served, are usually singularized, for whatever reason. (I might as well argue why Subsidiaries and Divisions are default plural, or parent default singular, without optional other-case parameter, but that is for another time.) Therefore, I hope you understand why I'm saying that is a nicely-thought idea, but set in sand and unlikely to find big support among the editor masses. Lordtobi (✉) 21:55, 29 December 2016 (UTC)

• Opposed To implementing singular/plural parameter pairs. It really bloats the template code, and readers understand just fine as is, and creates extra effort for editors to ensure the right form is used in each article. -- ferret (talk) 21:57, 29 December 2016 (UTC)

Replace "Release date(s)" with "Release"?

In relationship to the previous section about the width, the "Release date(s)" name is the longest in pixel width compared to any other ("Progammer(s)" is next). If we trim "Release date(s)" to "Release" that saves a few pixels as well as avoids the (s) plural. --MASEM (t) 15:04, 7 March 2017 (UTC)

Agreed. Also should just consider dropping all the (s)s. They eat up space at the end of programmer as well, and there's not a lot we can do to otherwise shorten "programmer" -- ferret (talk) 15:06, 7 March 2017 (UTC)

Also agreed. ~ Dissident93 ^(talk) 13:38, 8 March 2017 (UTC)

+1. Anyone with template editor rights want to carry this out? Seems relatively uncontroversial.--The1337gamer (talk) 15:31, 11 March 2017 (UTC)

 Done. --MASEM (t) 15:34, 11 March 2017 (UTC)

Writer link

"Writer(s)" in the infobox is currently not linked. However, there is an article in Wikipedia for video game writer. Should that be linked to the "Writer(s)" in the infobox? -- Wrath X (talk) 09:21, 18 March 2017 (UTC)

 Done Lordtobi (✉) 09:38, 18 March 2017 (UTC)

@Lordtobi: You linked director(s) to Video game director, which is a disambiguation page. That's not ideal because now thousands of video game articles are going to be listed as needing disambiguation link fixes. Either remove the link or change the target to Creative director. --The1337gamer (talk) 09:57, 18 March 2017 (UTC)

I missed that, pardon me. Link removed again. Lordtobi (✉) 09:58, 18 March 2017 (UTC)

Shorten "Progammer(s)"

The "Programmer(s)" label is a little too long compared to the other labels. It takes almost as much space as "Release date(s)" did. Is there a way to shorten it to save some space? Maybe smaller font? -- Wrath X (talk) 10:58, 20 March 2017 (UTC)

Shrinking font sizes will violate MOS guidelines concerning how small text can be. The only real solution will be to remove (s). Give the other discussion some time. -- ferret (talk) 12:27, 20 March 2017 (UTC)

We shouldn't be trimming the infobox to the point where it's worse off more than it was before, which this would probably do. ~ Dissident93 ^(talk) 16:33, 20 March 2017 (UTC)

Remove modes?

There are only two things to enter in the modes field (single-player, multiplayer), unlike the other fields which have many things to select from. It's also raises questions of which mode should be listed first. -- Wrath X (talk) 10:19, 23 March 2017 (UTC)

The order they're in is the least of your worries. The field is full of all manner of stuff, its a free entry text field and users have taken advantage of that. - X201 (talk) 10:47, 23 March 2017 (UTC)

I think the modes are a small yet nice feature to a VG article's infobox, and that there is no reason to remove it. Your argument that it raises questions is cited through a discussion you started, so not really a valid argument. If the issue X201 raises is the main problem, we could opt to a |single-player=yes, |multiplayer=yes solution, though I don't think that it would do good for editors. That it is a free-entry field makes it as vulnerable as any other, as some people like to append age ratings to the genres. Lordtobi (✉) 14:07, 23 March 2017 (UTC)

Modes should be pulled from Wikidata, which avoids the issue of free-text. There is almost zero reason not to do so. --Izno (talk) 16:25, 23 March 2017 (UTC)

Agreed in theory, but still allows essentially any item to be linked to the field. At least there are constraint reports to check though. -- ferret (talk) 16:35, 23 March 2017 (UTC)

Was the data that was copied over to wikidata cleaned? Because the data I saw on Wikipedia before it was harvested was an unholy mess. - X201 (talk) 16:43, 23 March 2017 (UTC)

Ferret: Right. X201: Even if we don't trust the data on Wikidata, we can implement an infobox-side check to ensure that the data from Wikidata is good and only let through the good stuff. But even so, we should clean Wikidata instead of removing the information here--and Wikidata already has constraint reports to help with that (which would serve the same as a tracking category here). --Izno (talk) 16:59, 23 March 2017 (UTC)

Widen the infobox

Can the infobox be widened a bit so that the "single-player" and "multiplayer" in the mode field can fit in one line? Furthermore, sometimes the release dates won't fit in one line if sources are added next to them (see Uncharted: Drake's Fortune). In other cases, the release dates won't fit in one line even if they don't have any sources next to them (see BioShock: The Collection). Widening the infobox will prevent this line breaking. -- Wrath X (talk) 14:43, 7 March 2017 (UTC)

The problem with changes like this is that they are dependent on the user's resolution, display and text zoom level. For example, the issues you mention above don't occur for me on either 1080p or 1440p. Secondly, in regards to references causing issues, strictly speaking the infobox doesn't require references, as long as the content is in the prose and sourced (Which it should be anyway). -- ferret (talk) 14:58, 7 March 2017 (UTC)

They both fit on a single line for me, which depends on the zoom level (and display resolution too). I wouldn't be opposed to making it slightly wider though, maybe by 10-15 pixels or so. ~ Dissident93 ^(talk) 13:36, 8 March 2017 (UTC)

Does anyone know how to widen the infobox? -- Wrath X (talk) 21:14, 8 March 2017 (UTC)

Yes. It's the width parameter, which defaults to 264px. This can be specified locally on any article that needs it. -- ferret (talk) 21:16, 8 March 2017 (UTC)

Could you be more specific? -- Wrath X (talk) 23:40, 8 March 2017 (UTC)

If you mean, widen the infobox for every article, no, you don't have consensus to do that. For any individual article though, just specify |width=whatever. -- ferret (talk) 23:42, 8 March 2017 (UTC)

@Ferret and Dissident93: you both say you don't have line breaking problems. Just wondering what's your display resolution and zoom level? And your browser if you don't mind? -- Wrath X (talk) 12:08, 30 March 2017 (UTC)

I don't see line breaking issues at either 1080p or 1440p. It's a bit irrelevant though, the fact is readers use a range of resolutions, zooms and browsers, and we can't set widths in a manner that will anticipate all of them. This often comes up in articles with stacked images as well. One editor puts "Left image: This, right image: that" because they are side by side for that editor. Another editor comes and changes it to "Top image: This, bottom image: that" because their settings have made the stack vertical. I see zero reason for adjusting our infobox from the default standard for all infoboxes. -- ferret (talk) 13:00, 30 March 2017 (UTC)

I noticed, at 1080p for me, there is line breaking in Firefox but not in Chrome/IE. Wierd. -- Wrath X (talk) 13:14, 30 March 2017 (UTC)

I use 1080p with 140% on a fork of Firefox called Cyberfox, if that matters. ~ Dissident93 ^(talk) 16:50, 30 March 2017 (UTC)

Distributor Wikidata values

It seems the infobox uses "distributor" property from Wikidata, but Wikidata says it is for films (that seems where it originally came from). The documentation is probably not updated. The main issue is that our field is for physical distributors only, but Wikidata has no such restriction, thus things like Steam or GOG can appear if we omit the field. I don't know enough about Wikidata to resolve this one way or another. I feel like doing something like this defeats the purpose of Wikidata use. I have no idea if there is a way to automate this and how one would possibly mark things as digital distribution. —  HELLKNOWZ  ▎TALK 19:15, 15 April 2017 (UTC)

Wikidata is wrong in this case. Steam is not a "distributor", but a "distribution". The entry on wikidata should be updated. However, in a general sense, we cannot enforce enwiki standards against Wikidata. When Wikidata conflicts, we'll have to override with local values, or when possible, find a programmatic solution. For example, if Publisher and Distributor are the same value, the infobox automatically suppresses distributor now. -- ferret (talk) 20:48, 15 April 2017 (UTC)

Remove (s) from the infobox

The (s) makes the infobox uglier and takes some space. Should they be removed from the infobox? I see I'm not the only one who considers having them removed. -- Wrath X (talk) 11:36, 12 March 2017 (UTC)

This has been discussed multiply though the template's lifespan, but never actually reached consensus as the (s) makes clear that the succeeding item(s) could me multiple or just a single one without having editors to use different parameters for either plural or singular. Hence, I will still be pro-inclusion of the (s). Lordtobi (✉) 12:18, 12 March 2017 (UTC)

• Remove I don't believe a reader is ever going to be shocked or confused to see "Programmer", but find the field contains two people. -- ferret (talk) 14:18, 12 March 2017 (UTC)

• I note the film infobox and some fields of the TV series infobox use fields like "Created by" which is plurality-neutral, though it is one character longer than "Creator(s)", I still think it's cleaner-looking. However, I agree with Ferret that using the singular aspect and having multiple names is not going to cause a reader to go stir-crazy over it. (Until we have a simple fool-proof way to do this plurality via templates, that is). --MASEM (t) 14:22, 12 March 2017 (UTC)
  • The anime/manga one that has the video games sub-template does too, for what it's worth. ~ Dissident93 ^(talk) 18:55, 16 March 2017 (UTC)
• Some fields in the infobox don't have the (s) even though they could have more than one entry e.g. engine, arcade system. -- Wrath X (talk) 14:36, 18 March 2017 (UTC)

I've updated the sandbox to remove (s), and added a test case to show how it changes the width of the label column. Please see Template:Infobox video game/testcases#Vertical comparison (for width). -- ferret (talk) 14:45, 18 March 2017 (UTC)

I think without the (s) provides more space. The infobox is a little cramped in my opinion. -- Wrath X (talk) 14:48, 18 March 2017 (UTC)

Are the other media infoboxes (anime/film/book) using the same width/text sizing as the video game one? The only time I see this one getting cramped is when you have a long developer/publisher name (Bandai Namco Entertainment), or a large list of unbroken platforms using the comma (which should be using the unbulleted list template, in that case). And as stated above, some of this is different on other display resolutions/scaling sizes, so what may be a fix at the most common ratio of those two (1080p/100%), might be "broken" on another. As for removing the (s), I say we just keep it per Lordtobi's argument, as your only argument for removing it is because of sizing issues. That being said, I wouldn't arguing for bringing it back if it ever did get removed. ~ Dissident93 ^(talk) 16:41, 20 March 2017 (UTC)

We are using the default dynamic widths. {{Infobox}} is controlling it, not us, so we are standard. However because the width is dynamic, our label names impact how much space labels get versus data. -- ferret (talk) 16:43, 20 March 2017 (UTC)

Ah, ok, that's pretty much what I expected. ~ Dissident93 ^(talk) 16:45, 20 March 2017 (UTC)

I just want to point out that in the infobox some field labels have the (s) while others don't. Inconsistency? -- Wrath X (talk) 09:54, 24 March 2017 (UTC)

The infobox isn't being consistent. If the infobox is supposed to have the "(s)" then how is it that some labels which can have plural entries (e.g. engine) don't have it? -- Wrath X (talk) 13:14, 30 March 2017 (UTC)

Engine can't have plural entries. A game only has one engine. Note that the engine parameter is not suppose to contain middleware like Havok or PhysX. -- ferret (talk) 13:25, 30 March 2017 (UTC)

What about The Lab? It uses two engines. -- Wrath X (talk) 13:38, 30 March 2017 (UTC)

Odd ball example, but I suppose you're right. But it's more accurate to say that the "Lab" is not a single video game, but a collection of 8 demos, some of which are Source 2, and some are Unity. Then again, my position is to simply state the singular noun and be done. It's not as ugly and no readers are going to complain. Many other prominent infoboxes take this approach, such as Book, most of Person (Spouse/parents being exception). We certainly wouldn't be the first to state singular even if a field may contain multiple. -- ferret (talk) 13:49, 30 March 2017 (UTC)

That infobox should not even fill out the engine field. The main prose never even mentions the engines and different sub-games using different ones. All it does it add more confusion there -- you absolutely can't have the same game using Unity and Source. —  HELLKNOWZ  ▎TALK 14:40, 30 March 2017 (UTC)

We shouldn't remove stuff from the infobox just because it's not in prose. But I agree that it needs to be explained in the article. (I thought it used to be though). ~ Dissident93 ^(talk) 16:52, 30 March 2017 (UTC)

We should. The inclusion criteria for the infobox is that it needs to be mentioned in the prose with references. The infobox is just a summary of sourced prose. - X201 (talk) 10:07, 1 April 2017 (UTC)

Then I'll do it later. Both of the engines were confirmed by the devs, so it's just a matter of writing it into the article. Just removing them and not doing this would make the article worse off in the end. ~ Dissident93 ^(talk) 05:12, 2 April 2017 (UTC)

So will something be done about this inconsistency or are we just going to leave it? "Release", which can have plural entries, also doesn't have the (s). In fact, avoiding the (s) was cited as one reason why "Release date(s)" was changed to "Release". -- Wrath X (talk) 09:50, 1 April 2017 (UTC)

There's no clear consensus to make the change. At best it's 50/50, and there's no real policy to point to that would support removing them. At best there's a technical argument to shorten the labels for spacing, but offset by a weak MOS argument that "(s)" is valid and indicates plurality. -- ferret (talk) 12:51, 1 April 2017 (UTC)

But several infoboxes don't use the (s): infobox person, its various offshoots, book. Also film has multiple labels which can have plural entries yet don't use the (s) (country, language). It's wierd that some infoboxes are fine without the (s) while others aren't. -- Wrath X (talk) 13:41, 2 April 2017 (UTC)

Remove - After seeing the example linked above, I agree to remove the (s). It make the infobox much more presentable and isn't more confusing than if the (s) was missing. If two composers are listed, it's clear that there were two, you don't need the (s) to clarify that. TarkusAB 20:05, 2 April 2017 (UTC)

Comment - Determined by its value? For example: | composer = Minoru Iwamoto results in "Composer" and | composer = Minoru Iwamoto<br />Kōsuke Fujishima results in "Composers"? --A Sword in the Wind (talk | changes) 11:29, 3 April 2017 (UTC)

There's no programmatic method to determine if the data field contains multiple values. -- ferret (talk) 11:37, 3 April 2017 (UTC)

How difficult would that be to implement? Perhaps if it recognizes an unbulleted list template (which is never used for single people, only multiple), it could trigger (s)? ~ Dissident93 ^(talk) 16:51, 17 April 2017 (UTC)

Keep - It's rather odd to have multiple items for a field that's singular. --JDC808 ♫ 06:08, 4 April 2017 (UTC)

Engine wikidata

A lot of games (e.g. sequels) have presumed or even verified statements that a game reuses the "engine" from a previous title, yet this is done in a trivial manner that comes down to ubiquitous code reuse rather than a modular framework implied by a game engine product. Most devs do reuse and extend existing codebases to create new games but this is rarely discussed in the context of being an engine. The current usage guideline for the infobox basically says to only fill out the engine field for standalone engine products. Yet even if you omit this field, the infobox will automatically pull any engine entry from wikidata, without any regard for the usage guideline here, and people entering wikidata may or may not care for the difference between a recycled codebase as an "engine" and an engine product. Can we just not use wikidata here or have a way to disable it on a case by case basis? Ham Pastrami (talk) 10:27, 15 May 2017 (UTC)

Wikidata ist a Wikimedia project like any other, so we would rather want to fix these entries at Wikidate rather than having us prevent issues while keeping other Wikipedias with this issue--that's not the sense of Wikidata. So, if you come across such an issue (regardless if on Wikipedia or Wikidata), please fix it immediately, building a workaround is fairly unnecessary. Lordtobi (✉) 10:34, 15 May 2017 (UTC)

If possible, fix Wikidata (Within their policies and guidelines). If Wikidata cannot be fixed in a manner inline with English Wikipedia expectations, specify an empty engine parameter to suppress wikidata. See WP:VG/WD#Preventing Wikidata values for more. -- ferret (talk) 11:57, 15 May 2017 (UTC)

Few update suggestions

1. Could Do not list people with titles such as "Character designer" or "Environment artist" (these should be described in the article's development-related section) be removed under the artists credit field documentation? We've been including character designers in a number of FA/FAC articles (Chrono Trigger and Final Fantasy VII for example), and nobody has ever removed them due to the reasoning stated here.

1. If a single person is credited as "Lead programmer", list that person; synonyms for this position include "Main programmer"; could be updated to read If a single person is credited as "Lead programmer", list that person; synonyms for this position may include "technical director". Technical directors are a more commonly credited role in recent games, and a "lead programmer" isn't even credited in a number of these titles (mostly smaller/indie titles). "Main programmer" was removed as it's obvious that they're the lead guy, so we don't have to state that here.

Hopefully this shouldn't be controversial, as it's been our de facto MO for a while, so it should be official here. I've got more suggestions, but decided to wait until this one is decided upon first. ~ Dissident93 ^(talk) 16:47, 17 April 2017 (UTC)

• Anybody opposed to this? I would have done this myself by now, but I lack editing rights. ~ Dissident93 ^(talk) 17:41, 24 May 2017 (UTC)

  Seems logical to me. Gonna get to that right away. Lordtobi (✉) 17:50, 24 May 2017 (UTC)

   Done Lordtobi (✉) 17:53, 24 May 2017 (UTC)

Displaytitle error

Note that the automatically-set displaytitle in this tempalte causes a Warning to be displayed at [[4]] — Preceding unsigned comment added by 217.46.133.56 (talk) 15:51, 4 June 2017 (UTC)

 Fixed - X201 (talk) 17:04, 4 June 2017 (UTC)

Programmer

Just how important is the role of programmer? I've heard of notable game directors, producers, designers, writers, artists, composers but I've never heard of notable programmers. I've never seen an infobox where the programmer is linked to an article. -- Wrath X (talk) 13:25, 4 July 2017 (UTC)

Doom (1993 video game)? While less likely to be a big notable name in modern games, this field is often filled in and sourcable. It's constantly filled in by IPs and other new editors as well. There's very little controversy or misuse with it. -- ferret (talk) 13:46, 4 July 2017 (UTC)

Fair enough. -- Wrath X (talk) 13:52, 4 July 2017 (UTC)

Yuji Naka on the early Sonic games? A game (and any software) doesn't exist without coding, so I don't see why you do not consider the lead programmer to be an important enough role. ~ Dissident93 ^(talk) 16:55, 4 July 2017 (UTC)

Platforms

Not sure if this is in module:Wikidata or here, but Godville's list of platform's is missing some spaces between values. I checked the code here, which leads me to believe it's in the module... --Izno (talk) 15:40, 4 July 2017 (UTC)

@RexxS: Any ideas? I know there was a recent update to the module concerning delimiters. -- ferret (talk) 15:45, 4 July 2017 (UTC)

@Izno and Ferret: Yup, that was the problem. I was in the habit of trimming leading and trailing whitespace from parameters (it's not needed anymore). Of course I managed to trim the trailing space from the default delimiter, ", ". D'oh!

Fixed now, I hope. You can now add an optional |delimiter= that specifies a custom delimiter, which may contain html, for specialised applications - the code strips double quotes (") so you can pass leading/trailing spaces as needed. Just don't encourage folks to use <br> as a delimiter to make a vertical list! If need be, I'll add the code from Module:WikidataIB that allows the output to be passed through {{Hlist}} or {{Ubl}}. Cheers --RexxS (talk) 19:10, 4 July 2017 (UTC)