Template talk:Version nav

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
I think that there is a problem with this template that put a lot of pages in Special:WantedPages.

You can see exemples at http://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  statements used to link to these pages if they exist. When you check if a page exists using , 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)

Server version for Alpha
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)


 * . Use the parameter to add the version. – KnightMiner  t/c 14:50, 7 July 2015 (UTC)

after 1.8
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)


 * – KnightMiner  t/c 20:40, 3 August 2015 (UTC)


 * Great, thanks! – Sealbudsman (Aaron) SealbudsmanFace.png T/C 20:46, 3 August 2015 (UTC)

change the default of the server parameter
Perhaps if the  parameter matches the current v value,   should link to "https://minecraft.net/download" as it does, but otherwise   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
Right now, the download part of the 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= 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) T/C 22:18, 6 August 2015 (UTC)

Different proposal
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
I've put a new parameter,. 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  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 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  works in conjunction with.
 * 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
Hi, 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)


 * , 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)