Template talk:Infobox version
Can someone make it so that the |exedl doesn't cause a white space to appear where it is not needed? Thanks –Goandgoo ᐸ Talk
Contribs
Edits 12:20, 3 August 2014 (UTC)
Problem with wanted pages[edit source]
I think that there is a problem with this template that put a lot of pages in Special:WantedPages.
You can see exemples at https://minecraft.gamepedia.com/index.php?title=Special:WantedPages&limit=500&offset=10000
There are pages like "Pocket Edition Alpha 1.2.4" and "Beta 13w22a", these versions have never existed...
I don't know how conditions work in templates, the problem is probably near "editions" and "othereditions".
We use the same template on the french wiki, so we have the same problem in our wanted pages.
Does anyone know how to fix this ? • ObelusPA2 d · FR Admin · 12:00, 13 December 2014 (UTC)
- It's because of the
#ifexist
statements used to link to these pages if they exist. When you check if a page exists using#ifexist
, it counts as a link to that page, even if no link is created. There may be a way around this with Lua, but there isn't any with just parser functions and other wiki markup. 「ディノ奴千?!」? · ☎ Dinoguy1000 00:22, 14 December 2014 (UTC)
- Fixed, 4 years later, by changing the #ifexist to a list of existent versions. – Nixinova
07:52, 15 May 2019 (UTC)
Server version for Alpha[edit source]
Could someone add a row for server versions so we can start to separate the Alpha versions? –Goandgoo ᐸ Talk
Contribs 07:04, 7 July 2015 (UTC)
Done. Use the parameter
{{{server}}}
to add the version. –KnightMiner t/c 14:50, 7 July 2015 (UTC)
after 1.8[edit source]
Hello, could somebody who bots go ahead and convert all the usage of "after 1.8" to "1.8.1", where they occur in 1.8 snapshot pages, but not in others such as the 1.8.x pages? – Sealbudsman (Aaron) T/C 14:49, 3 August 2015 (UTC)
- Great, thanks! – Sealbudsman (Aaron)
T/C 20:46, 3 August 2015 (UTC)
- Great, thanks! – Sealbudsman (Aaron)
change the default of the server parameter[edit source]
Perhaps if the title
parameter matches the current {{v}}
value, server
should link to "https://minecraft.net/download" as it does, but otherwise server
should default to something like unavailable. Because as it is, all the old versions seem to indicate that those version's servers are available at that page. – Sealbudsman (Aaron) T/C 21:29, 6 August 2015 (UTC)
better links, indicate is version available in Launcher[edit source]
{{version nav}}
for 1.6.2 (and for anything available in the launcher anyway) looks like the following:
|
I suggest it would be nicer if it looked/worked like the following:
|
This template could have a parameter "amazondownload" which, if there weren't a clientdl or serverdl, could take care of the links in the client/server lines. Existing version navs it wouldn't change, but future navs would have the amazondownload param set, which would take care of linking up that version -- which reduces what a person has to do with a new page. If it were ever wrong due to Mojang doing something funny on their end, you could do it manually. If they ever moved those assets, we could re-link them.
That second line would appear if:
edition = computer and ( title doesn't contain Alpha or Beta ) and (
type=<blank> or type = Release or (
( type = Pre-release or type = Snapshot ) and snapshotfor != {{v}}
(except we'd have to compare truncated 1.8 rather than full )
)
)
... which would automatically handle indicating when a snapshot is available in the launcher, based on Mojang's current practice of leaving the snaps available until the next snapshot cycle.
We wouldn't have to go through and change existing pages for this. What do you all think?
– Sealbudsman (Aaron)
Different proposal[edit source]
Thinking about it, there's not a reliable way to predict what snapshots are available in the launcher. So I scrap that idea. What remains:
Compare the current download area (link to minecraft launcher + link to minecraft.net/download):
Instead, use an amazondownload link that takes no parameters, and links to the jars and the json, and a link to Tutorials/How_to_install_a_snapshot:
|
In case the page version is identical to the value of {{v}}
, it would point to minecraft.net/download as usual (in that case, it's appropriate)
– Sealbudsman talk/contr 20:16, 13 September 2015 (UTC)
- That makes sense, it should be an easy enough way to mark pages based on what type of download they have without manually typing it, and it should be easy enough to add a case to exclude the .json could take a value to exclude the .json (for versions before 1.6).
- It would be a good idea to keep the parameter though, just in case of a very different download link (eg, April Fools versions) or no dowload link (removed for some reason).
- Although it does raise the question of if alpha and beta download links still work, and if so, how do they differ from release links? –KnightMiner t/c 21:43, 13 September 2015 (UTC)
- I agree, there's no need to ditch the current parameters. I should be clear, this would be an additional param that would override the other params. Or maybe they would override this one. In any case we could keep both, because at any point there may be a need for the original params.
- Perhaps if it wasn't downloadable at all, there could be a nodownload param that explicitly makes that note?
- As far as alpha and beta, it looks like the pages point to minecraft.net/download and the launcher page. I think those assets are pulled from amazon, and could be directly linked to theoretically... I could have sworn the directory structure was viewable at some point recently, though they may have closed it up now. Can we play a beta version in the launcher and see where on the internet it's reaching out to? Can't check myself, right now. – Sealbudsman talk/contr 22:04, 13 September 2015 (UTC)
update[edit source]
I've put a new parameter, download
. It's active right now in 1.8, 14w06a and 15w45a. When set to 1, the link it creates points to whatever is the title of the page. When set to anything else, that value is used as the target of the link. For instance if used in 1.8-pre, you would set download=1.8
because 1.8 is the relevant download (there is no 1.8-pre jar).
This 1. removes a source of editor error/maintenance with new snapshots, 2. consolidates the formatting should we decide to tweak it across the board, and 3. consolidates the download URL should mojang move the server for some reason.
If there are no objections, my next suggestion would be that KnightMiner would have his bot convert existing download parameters to this format – snapshots for 1.7, 1.8 & 1.9 that currently use clientdl and serverdl, as well as release versions that currently don't use any such parameter – so that we would actually have benefits 2 & 3. – Sealbudsman talk/contr 21:39, 10 November 2015 (UTC)
- One TODO item: the 1.6 snapshots also have an .exe available, so I ought to make sure
exedl
works in conjunction withdownload
. - Another TODO item: older versions going back to [[Beta 1.9-pre1]] are available at a different URL, and perhaps it might be worthwhile to bundle these up into another parameter so that benefits 2 & 3 extend to these versions as well.
- Another TODO item: versions older than that, by and large, have unavailable servers and in many cases unavailable clients. The links for these are misleading and should be removed.
- Final TODO item: those older versions that are available can be linked up properly on a case-by-case basis, or maybe there is room for a new download parameter here as well, I don't know. – Sealbudsman talk/contr 21:40, 10 November 2015 (UTC)
- Looks good, I'll have my bot convert a few more pages after making sure there are no other objections. –KnightMiner t/c 15:45, 11 November 2015 (UTC)
deprecate 1.8.x[edit source]
Hi KnightMiner, you may have already done this, but, when you get time, would you be able to remove instances 1.8.x – and then remove it from this template? – Sealbudsman talk/contr 17:58, 9 March 2016 (UTC)
Done, along side "after 1.8". I also added "after 1.9" to point to the first 1.10 release.
- What is your opinion on a "after 1.10" that would be blank at this time? It is a little harder to make a variable be blank for now, so since it only makes sense assuming we get a bunch of 1.10 releases before 1.11 (or later) is announced (which I doubt will happen), I am not sure its worth the effort. –KnightMiner t/c 22:59, 13 March 2016 (UTC)
- Great, thanks!
- Adding an "after 1.10" at this time ... What would be the benefit? – Sealbudsman talk/contr 15:13, 14 March 2016 (UTC)
- The idea was we would set all 1.10 releases to point to "after 1.10", and upon Mojang announcing 1.11 (or 2.0) we could simply add a value to the variable and the pages will automatically fill the next parent field. Since the "after" variables get a lot less use than the ".x" ones I am not sure that is really needed though. –KnightMiner t/c 04:53, 15 March 2016 (UTC)
- I see a time saver at least in the case of snapshots. Consider what we have with 1.9 snapshots; we didn't add an "after 1.9" until now, and now we're probably going to have to manually fill those in, when 1.9.1 comes out. Though if it's troublesome to get a blank value in there, that's fine. – Sealbudsman talk/contr 13:33, 15 March 2016 (UTC)
- From the looks of it, snapshots' "next parent" are a bit of an awkward case since as soon as it has a value, that value is now constant and should be replaced with a constant, and it needs a slightly different value than "after 1.9" contains (1.9.1 rather than 1.10). I think in the case of those, the main advantage of the variable is it would be it can update before a bot can run (which prevents us from needing to rely on the bot to update it) and it becomes a bit easier for a bot to replace, as text is easier to find than an empty field.
- Actually adding the field is not too much extra effort, I just want to make sure it is worth having before adding it. –KnightMiner t/c 14:23, 15 March 2016 (UTC)
Other versions[edit source]
There is random capitalisation on the 'Other versions' section. Example from Pocket Edition 1.0:
Other Editions of 1.0: Computer alpha Computer Beta Computer
Also it should be changed to 'Java'
– Nixinova •
• 05:37, 13 June 2017 (UTC)
Download link[edit source]
Dinnerbone has confirmed that the old http://s3.amazonaws.com/Minecraft.Download/versions/ will be discontinued. Old url will be removed by the end of the year. It will not receive any new versions or updates, but existing files will remain for now. Please update to use https://launchermeta.mojang.com/mc/game/version_manifest.json instead.--Skylord wars (talk) 11:48, 8 May 2018 (UTC)
- For example, https://launchermeta.mojang.com/mc/assets/1.12/e75e9535754c6f2158b0b18b35660f45c4495d78/1.12.json will be 1.12.json. While https://launcher.mojang.com/mc/game/1.12.2/client/0f275bc1547d01fa5f56ba34bdc87d981ee12daf/client.jar will be 1.12.2.jar file--Skylord wars (talk) 12:00, 8 May 2018 (UTC)
- You can find all of the current URLs on this page: de:Minecraft Wiki:Versionsliste (you need to enable a gadget and click on "Laden" for each version that you're interested in). Dinnerbone said that the URLs might break in the future and you shouldn't hardcode them, and also the list only includes versions available in the launcher, so it misses quite a lot. | violine1101(Talk) 20:37, 8 May 2018 (UTC)
- Can someone add a value to also add windows_server.exe hashes? 79.222.153.250 17:57, 29 May 2018 (UTC)
- All hashes can be found on Module:Downloadlinks. You don't need to add the hashes for them. –Preceding unsigned comment was added by Skylord wars (talk • contribs) at 0:57, 30 May 2018 (UTC). Please sign your posts with ~~~~
Using {{downloadlink}}[edit source]
Someone please help me to add {{downloadlink}} to this template. Add a parameter "old" to let the editors to customize the version name to comply with the game file names. skylord_wars (talk) 03:30, 29 May 2018 (UTC)
Beta Versions[edit source]
@Marioprotvi: What is your goal with Beta versions? I noticed you removed the code that makes them appear, may I ask what was not working? I will note that the beta builds for BE 1.4 are currently categorized as "builds" which would make the list empty if that article was your goal, so you will have to recategorize them for it to work. –KnightMiner t/c 18:39, 6 June 2018 (UTC)
- I initially created it to see if I can find a workaround for the weird formatting for 1.4’s betas since the standard “build 1, build 2”, etc seems to not work well with recent versions (since 1.0 when the switch was made) in Bedrock, most specifically 1.4’s betas. I initially tested it on one beta version for 1.2 and it didn’t work so great due to it listing it in the nav as "Bedrock Edition beta 1.2.0.x" or something rather then just the "1.2.0.x" I had intended it to display. And yes I realize recategorizing would have to happen. If anyone knows a way to make it so that only the version number shows up in the template for BE. --Marioprotvi (talk) 18:49, 6 June 2018 (UTC)
Currently shows disambiguation pages as "Java Edition"[edit source]
Is there any way to test if a page doesn't have the category disambiguation? Because on pages like New Nintendo 3DS Edition 0.1.0 it shows "Java Edition" in "other editions" even though 0.1.0 is a disambig page. – Nixinova
22:03, 2 November 2018 (UTC)
- Fixed this ages ago. – Nixinova
21:41, 17 July 2019 (UTC)
Add ability to add links to Bedrock/Java Edition guides[edit source]
As of the time of writing, hatnotes are used to link to guides from version articles. I think it would be better to place these links in the {{Version nav}}
template. It would take up less space and if for some reason we were to move all the guide pages to a new format, it would be a lot easier to change the nav template than to change all the hatnotes. Fadyblok240 (talk) 02:58, 3 September 2020 (UTC)
Include resource pack format version?[edit source]
Would save you having to cross-reference pack format. 2001:8003:3FED:5100:692F:77A3:4AB0:C8F8 12:17, 31 January 2024 (UTC)
Support. Data pack format should be similarly added. – ZacNVR (talk) 12:27, 31 January 2024 (UTC)
Support adding resource pack and data pack format version, though care should be taken to make the difference between data pack format versions and data versions obvious. Kationor (talk) 12:38, 31 January 2024 (UTC)
- I've long planned to add this to the version navs. I have the data in JS form here: https://github.com/nixinova/pack-format. Will work on translating into wiki. Nixinova T C 10:12, 26 May 2024 (UTC)
- Done. See
{{Pack format}}
with data stored at{{Pack format/data}}
&{{Pack format/resource}}
. Nixinova T C 11:20, 26 May 2024 (UTC)
Next parent in pre releases should link to the next minor release of the game[edit source]
This means that the next parent of a pre-release should be the version it is being developed for.
Example:
- [Java Edition 1.14.4 Pre-Release 4] -> [Java Edition 1.14.4]
This is already the case for snapshots, and it should be consistent with pre-releases and release candidates.
Snapshot example:
- [Java Edition 20w45a] -> [Java Edition 1.17]
--Simanelix (T|C) 03:32, 21 April 2024 (UTC)
- For reference, this is also being discussed in this forum post: Minecraft Wiki:Forum/Mass revert recent edits changing nextparent in development versions to the parent version. –Sonicwave talk 04:53, 23 April 2024 (UTC)
Move "other editions" out of infobox[edit source]
The other editions information isn't data about the version, it's disambiguation, so should be outside of the infobox. I propose we change it to be like this:
Released |
2018 |
---|---|
Other instances of 1.0 |
{ "title": "Old version", "rows": [ { "field": "2018", "label": "Released" }, { "field": "\n*<span style=\"white-space:nowrap;\">(link to Java Edition Classic server 1.0 article, displayed as Java Edition Classic server)</span>\n*<span style=\"white-space:nowrap;\">(link to Java Edition Alpha v1.0 article, displayed as Java Edition Alpha)</span>\n*<span style=\"white-space:nowrap;\">(link to Java Edition Beta 1.0 article, displayed as Java Edition Beta)</span>\n*<span style=\"white-space:nowrap;\">(link to Launcher 1.0 article, displayed as Minecraft Launcher)</span>\n*<span style=\"white-space:nowrap;\">(link to Realms#1.0 article, displayed as Realms)</span>\n*<span style=\"white-space:nowrap;\">(link to Pocket Edition 1.0 article, displayed as Pocket Edition)</span>\n*<span style=\"white-space:nowrap;\">(link to Education Edition 1.0 article, displayed as Education Edition)</span>", "label": "Other instances of (link to 1.0 article, displayed as 1.0)" } ], "invimages": [], "images": [] }
Released |
2024 |
---|
{ "title": "New version", "rows": [ { "field": "2024", "label": "Released" } ], "invimages": [], "images": [] }
Thoughts on this, or perhaps where better to put it? Nixinova T C 07:34, 10 November 2024 (UTC)
Support - It feels somewhat weird to put all these other versions in there. Maybe the actual game versions are fine, but the Launcher? Server software? Realms? Absolutely not. 3A | T C 07:01, 9 January 2025 (UTC)
- I did a bit of thinking, and maybe we should add an "equivalent update in other editions" section instead, so e.g. the section in the JE 1.15 page would include BE 1.14, and EE 1.14.31; the section in the JE 1.13 page would include BE 1.4 and 1.5, EE 1.4, and all those console edition versions, e.g. PS3/Vita/4 1.76. That would work much better.
- Example:
Edition | |
---|---|
Official name | |
Released |
July 18, 2018 |
... |
... |
Equivalent versions | |
{ "title": "Minecraft 1.13", "images": [ "Java Edition 1.13 menu.png" ], "rows": [ { "field": "''(link to Java Edition article, displayed as Java Edition)''", "label": "Edition" }, { "field": "(link to Update Aquatic article, displayed as Update Aquatic)", "label": "Official name" }, { "field": "July 18, 2018", "label": "Released" }, { "field": "...", "label": "..." }, { "field": "\n*(link to Bedrock Edition 1.4 article, displayed as Bedrock Edition 1.4)\n*(link to Bedrock Edition 1.5 article, displayed as Bedrock Edition 1.5)\n*(link to Education Edition 1.4 article, displayed as Education Edition 1.4)\n*(link to Xbox 360 Edition TU69 article, displayed as Xbox 360 Edition TU69)\n*(link to Wii U Edition Patch 38 article, displayed as Wii U Edition Patch 38)\n*(link to PlayStation 3 Edition 1.76 article, displayed as PlayStation 3 Edition 1.76)\n*(link to PlayStation Vita Edition 1.76 article, displayed as PlayStation Vita Edition 1.76)\n*(link to PlayStation 4 Edition 1.76 article, displayed as PlayStation 4 Edition 1.76)", "label": "Equivalent versions" } ], "invimages": [], "footer": "</tr>\n</table>" }
- 3A | T C 15:29, 10 January 2025 (UTC)
- That's a different case altogether. The current parameter is for versions on other editions that share the same version number. Nixinova T C 05:02, 16 January 2025 (UTC)
- Yep, I simply suggested adding a separate, new row. The "same version number" row can be moved out. — 3A | T C 08:05, 16 January 2025 (UTC)
- That's a different case altogether. The current parameter is for versions on other editions that share the same version number. Nixinova T C 05:02, 16 January 2025 (UTC)
- 3A | T C 15:29, 10 January 2025 (UTC)
- Have moved it into a pointer box. Having an equivalent versions param can be a separate discussion. Nixinova T C 03:42, 8 February 2025 (UTC)
Lack of documentation for jsonfile parameter[edit source]
There is no documentation for the jsonfile
parameter. It is used on pages such as Java Edition 1.21.4 Pre-Release 3. - CrowdingFaun624 (talk) 04:36, 4 January 2025 (UTC)
- Filled that out Nixinova T C 08:14, 8 January 2025 (UTC)
An "equivalent versions" section for the infobox[edit source]
This section continues from the section where we moved "other editions" out of this infobox. Here's what I said then:
“ |
|
„ |
Edition | |
---|---|
Official name | |
Released |
July 18, 2018 |
... |
... |
Equivalent versions | |
{ "title": "Minecraft 1.13", "images": [ "Java Edition 1.13 menu.png" ], "rows": [ { "field": "''(link to Java Edition article, displayed as Java Edition)''", "label": "Edition" }, { "field": "(link to Update Aquatic article, displayed as Update Aquatic)", "label": "Official name" }, { "field": "July 18, 2018", "label": "Released" }, { "field": "...", "label": "..." }, { "field": "\n*(link to Bedrock Edition 1.4 article, displayed as Bedrock Edition 1.4)\n*(link to Bedrock Edition 1.5 article, displayed as Bedrock Edition 1.5)\n*(link to Education Edition 1.4 article, displayed as Education Edition 1.4)\n*(link to Xbox 360 Edition TU69 article, displayed as Xbox 360 Edition TU69)\n*(link to Wii U Edition Patch 38 article, displayed as Wii U Edition Patch 38)\n*(link to PlayStation 3 Edition 1.76 article, displayed as PlayStation 3 Edition 1.76)\n*(link to PlayStation Vita Edition 1.76 article, displayed as PlayStation Vita Edition 1.76)\n*(link to PlayStation 4 Edition 1.76 article, displayed as PlayStation 4 Edition 1.76)", "label": "Equivalent versions" } ], "invimages": [], "footer": "</tr>\n</table>" }
I still think we should add a section for this. Any thoughts on this? Thanks. — 3A | T C 11:31, 8 February 2025 (UTC)
- My only problem with it is the huge size that it balloons the infobox out to be. Not sure what to do about that. Maybe have it in a pointer box as well? Nixinova T C 11:39, 8 February 2025 (UTC)
- That works as well. — 3A | T C 11:43, 8 February 2025 (UTC)
- ↑ Infobox not included in the quote, for obvious reasons.
Bedrock Dedicated Server "server for" row links to BDS instead of BE[edit source]
the Bedrock Dedicted Server "server for" row uses the parent param, but it links to the BDS version instead of BE version. For example, if the parent param was 1.6.1 instead of linking to Bedrock Edition 1.6.1 it links to Bedrock Dedicated Server 1.6.1. NmF (talk) 22:30, 20 February 2025 (UTC)