Template talk:History/Archive 1

From Minecraft Wiki
Jump to: navigation, search
This page is an archive of past discussions. Do not edit the contents of this page.
If you wish to start a new discussion or revive an old one, please do so on the current talk page.


I think the version numbers should link to the respective section in the version history page so people can see the full changelog as well. Instead of having a separate section for development versions, maybe they should just be integrated into the release cycle type. For example, the weekly snapshot version changes can be integrated into the full release section, and beta pre-release changes into Beta section, so this way the chronological order is maintained. - Asterick6 (talk) 05:07, 9 June 2012 (UTC)

I'm working on the version number links. As for the pre-release thing, I think it makes the most sense if changes are sorted by officially released versions (not prereleases). This means that a feature introduced in the Beta 1.8 prerelease is listed under Beta 1.8, and a feature introduced in the Beta 1.9 prerelease is listed under Minecraft 1.0.0 (since Beta 1.9 eventually became Minecraft 1.0.0). If there is no official release yet (as is currently the case with the 1.3 snapshots), it gets listed as an upcoming feature, similar to how other templates and pages handle the snapshots (just look at the list of blocks for an example). —Fenhl 05:15, 9 June 2012 (UTC)
Then this formatting style is basically the same as the one used in the version history article. If we format it like this, then how will we order the update notes during each development release (links, videos, images, etc.)? I think the purpose of a history section for each topic is to group the changes regarding the article topic into an readable section and to log the events/images/etc. that cannot be added to full version change list. Instead of grouping the development versions into the upcoming section, how about adding them to the full release section (for snapshots) in chronological order? This way it maintains the first (development) version in which specific features were implemented/changed. Pre-release changes can be added into the Beta section. - Asterick6 (talk) 05:41, 9 June 2012 (UTC)
I think you misunderstand me. I agree with you on adding Beta prerelease changes to the actual release they were made for. In fact, that's what I've done in the pages I've already updated. In order to be consistent with the rest of the wiki, however, pre-release changes that have not yet been released yet should be marked as such (planned or upcoming). In doing this, the order stays perfectly chronological. —Fenhl 05:54, 9 June 2012 (UTC)
Ok, so after the official version is released, the development version changes will be moved to the official release section. I think it's best if the development version number is maintained for each change after they are moved to the official release section. - Asterick6 (talk) 06:02, 9 June 2012 (UTC)
I looked at the conversions you made, and you were leaving out some of the development version details. Pre-releases should be placed between Beta and Official release since those pre-releases were part of the Beta cycle. This format may actually take more effort to maintain if we have to move the upcoming section changes into the official release section each time the official version is released. Why don't we just list the changes, along with the snapshot version, directly under the official section since these snapshots are part of the official release cycle. This way there's no need to move them again. - Asterick6 (talk) 06:27, 9 June 2012 (UTC)
Please tell me what exactly I have “left out”. The additional effort is, as has been proven repeatedly, no problem for the large community. The snapshots are not official releases, they are only a way to test new features and find bugs. Also, please refrain from editing the articles based on your suggestion until a consensus has been reached on the matter, to prevent edit wars. —Fenhl 07:52, 9 June 2012 (UTC)
What Orthotope said below was what I was trying to tell you about. - Asterick6 (talk) 01:55, 10 June 2012 (UTC)
I'm a bit concerned about the loss of detail caused by merging snapshot notes into the release version. Take emerald ore, for example. If we just have '1.3: Emerald ore added', we lose information about the changes in its generation in the last few snapshots. On the other hand, it is nice to have the release version, so you don't have to check Version history/Development versions to see which one a snapshot became part of. One solution might be to list both the snapshot and the full release it became part of. For example:
Official release
1.2.5 release stuff
1.3 12w19a snapshot stuff
12w23b more snapshot stuff
The code for that would be a bit gnarly, so another option is to mention the snapshot version in the history entry. -- Orthotope 07:54, 9 June 2012 (UTC)

We could have two versions of the table — one with the releases only and one with all the details from development versions and leaked info — and let readers switch between them at the click of a button (similarly to how the table of contents can be collapsed or expanded completely). This might require help from an admin since it uses JavaScript and I'm not sure how MediaWiki and JavaScript work together, but it definitely can be done. It would be the best of both worlds. And don't worry about gnarly code, the template syntax for this can still be kept pretty clean. —Fenhl 08:09, 9 June 2012 (UTC)
That would work, if it's possible; it's well beyond my abilities. Ultradude25 seems to be the resident wikicode and JS/CSS expert, so I'd like to see what he thinks. -- Orthotope 08:26, 9 June 2012 (UTC)
That could probably be done if mw-collapsible would work, but I don't think Curse has fixed it yet. ultradude25 (T|C) at 09:20, 9 June 2012 (UTC)
I don't even see mw-collapsible on Special:Version. Or is that the problem? Anyway, we would need a way to provide a button that hides one part of the code (the release overview) and shows another (the snapshot-by-snapshot details). Does mw-collapsible do that? —Fenhl 09:34, 9 June 2012 (UTC)
mw-collapsible is a built-in part of mediawiki. I did actually manage to fix it a while back, but that was by removing a part of its code... so I assume it must break somewhere else now, but at least it seemed to work on basic usage.
I've made some changes to the template so there is only one parameter name, and added the {{verlink}} template to it. ultradude25 (T|C) at 11:07, 9 June 2012 (UTC)
Although mw-collapsible does not have all the features we would need for this, I have tried to make a table where changed made in development versions should be hidden by default. However, they are not. mw-collapsible does not work as described on the MediaWiki page. —Fenhl 12:55, 9 June 2012 (UTC)
Exactly... it's broken. ultradude25 (T|C) at 13:19, 9 June 2012 (UTC)
On an unrelated note, is there any particular reason for having the template generate raw HTML rather than wikicode? -- Orthotope 07:54, 9 June 2012 (UTC)
I had problems with the wikicode table in the parser functions, so I changed it to a HTML table. Feel free to fix that if you know how. —Fenhl 08:09, 9 June 2012 (UTC)
Because templates and wikicode tables won't work without escaping them, which is much uglier than just doing the tables in HTML. ultradude25 (T|C) at 09:20, 9 June 2012 (UTC)
I did try to escape them, but it didn't really work the way I thought it would. And yes, it's ugly. I got confused way too quickly. —Fenhl 09:34, 9 June 2012 (UTC)

For my previous comment: The other snapshot release dates that are already released officially should retain their original version, and not be merged into the official version. For example, the Beta pre-releases such as 1.9preX should be in the Beta section, not the 1.0 release section, because the changes were added in the Beta release cycle, not the official release. The snapshot versions that are already released in 1.2.5 should be in the official release section with the development version in which the change was added, and not be merged into the 1.2.5 label that doesn't accurately show the exact version change. - Asterick6 (talk) 19:05, 9 June 2012 (UTC)

For example, Ice#History has a situation in which a feature was changed in 1.9pre4, but was removed in 1.0. If they are all merged into the official release version, the player loses context for the next change. The development version will NOT be merged or relabeled. - Asterick6 (talk) 05:04, 10 June 2012 (UTC)

Maybe there can be a field that allows dates to be added, or any custom note, instead of linking to a version history page. Content that do not have specific versions (e.g., image previews) can be left above the template, or it can be added into the template above the version changes. - Asterick6 (talk) 22:14, 9 June 2012 (UTC)

The new version of the template will take care of all that. —Fenhl 05:38, 10 June 2012 (UTC)

Linking to version history

Well, now we can't post a non-update history entry. Can someone re-add the blank entry parameter to allow for that? --M0rphzone 01:09, 1 September 2012 (UTC)

Oh nvm, "unknown" takes care of that. --M0rphzone 01:10, 1 September 2012 (UTC)

Link parameter not working with page links

Thinking about the hack Hower64 did to allow page links instead of external links for the |link= arg, would the following fix that? I am honestly confused about complex wiki markup code, so I don't want to edit this in and cause an issue.

Replace the following line

| [{{{link}}} {{{2|link}}}] }}</th>

with this

| [{{{link}}} {{{2|link}}}]
| {{static link|{{{page}}}|{{{2|page}}}}} }}</th>

This way, if we need to have the date in History tables link to another page, we just use the |page= arg. --User:Kanegasi User_talk:KanegasiSpecial:Contributions/Kanegasi 03:17, 28 December 2012 (UTC)

This wouldn't what you want it to do, sorry. —Fenhl 03:48, 28 December 2012 (UTC)

Xbox 360 upcoming

So I added Xbox 360 upcoming features to the template, however when I then add a version under it, it still links to the version history instead of the upcoming features page, how do i fix this? CRRaysHead90 21:34, 13 January 2013 (UTC)

Since this is Template:History, you wouldn't have xbox upcoming features on here at all. The only reason there is an upcoming section for PC is because of the weekly snapshots, as while the feature is upcoming for an official version, it has actually been released as a snapshot and is documented as part of history. ultradude25Talk
01:18, 14 January 2013 (UTC)
Good point. I guess I shall revert my addition. However I'd like to see something where upcoming xbox features can be told about. CRRaysHead90 16:16, 14 January 2013 (UTC)

Dev is not Official. Fix it!

Developmental history is not Official Release history!

They should NOT be linked the way they do. For the majority of players, people don't really care about the beta release, and we really just want to see what has been released based on specific real version numbers. The current system causes all kinds of confusion where the end user has to look up the current release's corresponding development version number and backtrack it from there. This is broken and unintuitive.

I think one of the big questions here is whether all the snapshot features actually get released into the official SVN or if they are put into snapshots experimentally. I went searching between the two lists for a while and found an extremely hard time tracking which features were fixed and which official version it went out to.

As an end user, I don't know what development version my client recently got... it is not shared with client info without significant research. Giving the developmental release of a feature being changed instead of the official release breaks a lot of things, for example: searching for specific things on youtube where people cite the regular version number and not the dev designation. You can't match the two up.

Development versions are nice for people working with development, but lets fix this and stop labeling development versions as official versions please? 17:50, 5 February 2013 (UTC)

Now that I'm thinking about this a bit, what we could do in entries is move developmental release numbers into a new header in the History template called Developmental Releases. Then, add the appropriate stable information in the Official release section of the template using the wording from Mojang. This would require lots of work editing the pages, but it really needs to be fixed. 00:50, 6 February 2013 (UTC)

I have made a new version of the template (Template:History2) to demo the ability to toggle displaying the developmental versions under the official version.
Currently, an official version's history can be split up by putting the developmental version number in a pre tag (put a space at the start of the line)
Then clicking the show details button will show those versions next to the official version number.
Changes that only make sense to show in the details view (such as a bug that was introduced in one snapshot, and fixed in the next) can be hidden by using an ordered list instead of an unordered list. The change will then only be shown (as an unordered list) in the details view.
This is just a demo of the functionality, we can decide what needs to be changed from here before we actually put this into use. ultradude25Talk
03:05, 9 February 2013 (UTC)

Raspberry Pi Edition

A few bits of edits are needed for the Raspberry Pi edition as I can't put some stuff into the Flowers page history as I am new to the wiki and as far as I can see there isn't s Raspberry Pi bit in the template code. I looked at the code and thought I wouldn't risk editing it GingerGeek 20:38, 19 February 2013 (UTC)

Added. -- Orthotope 05:49, 20 February 2013 (UTC)

Snapshots sorted by official release version


it would be great, if the template of the history would be changed to the one,

Orthotope suggested on 07:54, 9 June 2012 (UTC)

It is hard to know, at which point a feature has been implemented in an official release (1.2, 1.3, 1.4.5 and so on) if you only see the snapshot numbers. As an example I would tell you to go to the page of the map item.


11:31, 24 February 2013 (UTC) McMicGera

Add Development history type

It seems as if the addition of a Development Version type would alleviate the confusion between development versions and official versions. Currently, the template pushes development versions onto the official releases category, which is incorrect. Silivrenion 19:19, 10 April 2013 (UTC)

Snapshots are considered 'released' once their content has been included in an official update. Putting all development versions in their own section would break the chronological ordering of entries. -- Orthotope 19:33, 10 April 2013 (UTC)
If the snapshot doesn't have a release version yet, put the entry under a {{history|u}} which will put it under "Upcoming". If a snapshot entry is listed under "Official Release", it means whatever change that snapshot has is now included in a main release. There shouldn't be any confusion with the snapshot numbers. The history template does have the ability to list the release versions to the left of the snapshot versions in order to differentiate between the snapshot releases. An example of this is on Emerald#History User:Kanegasi User talk:KanegasiUser:Kanegasi/edit count 20:28, 10 April 2013 (UTC)
Why can't we just simply start using Template:History2 as that was what it was designed for? Btw the last edits for the History2 template was 10 February 2013, meaning that it's been two months since that was set up. User:GoandgooUser talk:Goandgoo
User:Goandgoo/edit count
05:43, 13 April 2013 (UTC)
That isn't really usable. It was a test concept on a way to handle the snapshot versions, but it doesn't really work very well. While the current way to do it isn't great, it will do until we get lua. ultradude25Talk
14:04, 13 April 2013 (UTC)

Change upcoming to development

"Upcoming history" has always been weird, it would be better to call it "development" or something like that. ultradude25Talk
09:45, 15 June 2013 (UTC)

Release versions in Upcoming section?

There's been a bit of an edit war between me and Matt regarding whether or not to include the release version number in the Upcoming part of the History sections.

Both the official and developmental version numbers should be used

This part of the documentation clearly refers to the Official release part. Also, Matt argues that

It's useful to show the version that the snapshot relates to.

How would this be useful when the version does not even exist? —Fenhl 04:44, 28 September 2013 (UTC)

It is useful as it shows what version to expect these features in when it is released. Most history sections already have a version/snapshot pair, so it doesn't take up any extra room to have the information there, and even in cases where there isn't any already, it barely takes up any space. What benefit is there to not have this information? MattTalk
⎜ 05:49, 28 September 2013 (UTC)
It is misleading: 1.7 is not a released version of Minecraft yet, while the “1.7” on Minecart makes it look like it is. We have enough problems with people confusing the snapshots for releases already. It also currently links to a hanging anchor on Version history, which illustrates my point: it's just not there. Besides, as little space as it may take up, it still adds clutter. —Fenhl 06:12, 28 September 2013 (UTC)
Well it's under the heading "upcoming" so I don't see how anyone could be confused by that. However, the hanging anchor seals the deal for me. It's gotta go. MattTalk
⎜ 08:04, 28 September 2013 (UTC)
I have edited the template docs to make this more clear. —F‌enhl 13:40, 21 October 2013 (UTC)

Upcoming Pocket Edition

It would be good to see a Upcoming for Pocket Edition category, so any information about the upcoming 0.9.0 update can be put there. Currently, some people are putting information from 0.9.0 into history tables already, however 0.9.0 isn't released yet. GoandgooTalk
Edit count
09:36, 2 March 2014 (UTC)

This is the history template. The only reason we have the (poorly named) upcoming section at all is for development version releases which haven't been put in official releases yet. If this 0.9 update has a released development version, then it can go in Pocket Edition's existing upcoming section, otherwise it doesn't belong in history at all. MattTalk
⎜ 09:44, 2 March 2014 (UTC)
Ok, thanks for the reply. GoandgooTalk
Edit count
11:43, 2 March 2014 (UTC)

Color coding the editions

The different editions of the game (PC, Pi, Pocket, Xbox) should be more easily distinguishable in the template. I propose color coding the table cell background for the different editions. The different development cycles within one edition would still have the same color (for example, Classic and Upcoming would be the same color as Release, and Pocket Alpha would be the same as Pocket Beta). Here's the colors I've come up with:

Edition header color regular color why
Computer #f2f2f2 #f9f9f9 default wikitable background colors
Pi #ffdbe8 #fdedef because of the pink-ish Pi logo
Xbox #e8ffe7 #edffed because the green Xbox logo
Pocket #ffe9d0 #fff3e7 just some colors that were different enough from the others, feel free to suggest a better color scheme

F‌enhl 13:49, 5 March 2014 (UTC)

It could work for the header of each edition, but it might be too much to colour the whole table, probably need to make a mockup. On that topic, something I was considering was having each edition in a separate table MattTalk
⎜ 14:24, 5 March 2014 (UTC)
Here's a mockup of the different variants. I think the “everything colored, same table” one looks best. —F‌enhl 02:16, 18 March 2014 (UTC)
If we were to have separate tables, they would be set 100% width. Full colour looks alright, but I'm still leaning towards just the headers, personally. MattTalk
⎜ 03:16, 18 March 2014 (UTC)
I also prefer headers only, the rest seems a bit busy/too colourful. GoandgooTalk
Edit count
07:00, 18 March 2014 (UTC)

Renaming Xbox Edition to Console Edition

Now that there is a Playstation version (basically an exact replica of the Xbox version), could someone edit the template so the Xbox 360 Edition header gets changed to Console Edition? GoandgooTalk
Edit count
07:05, 18 March 2014 (UTC)

According to the Achievements article, they are not the same. Besides, the PlayStation version came out much later, no? So I think there should be separate sections for the two. (Correct me if I'm wrong, I don't play console Minecraft.) —F‌enhl 03:46, 21 May 2014 (UTC)

Changing parameter functions

Would there be a problem with changing {{{ilink}}} to set the link, rather than simply adjust the type of link for {{{link}}}? I'd assume based on usage that it is rarely used thus far, and any current usage could easily be adjusted.

An example of the code required can be seen here

--KnightMiner (t|c) 15:15, 3 September 2014 (UTC)

So I went ahead and added it, after remembering :Category:Fixme --KnightMiner (t|c) 18:52, 6 September 2014 (UTC)

Removing rowspan parameter

Fenhl, Majr (plus anyone else concerned)

I have found a way to eliminate the need for the rowspan paramater using #var_final, as this template could count the number of rows after it (see use here). My main question is can you think of any problems with using that, such as memory or variable limit. It would require a variable to be generated for each use of the a version with a snapshot (automatically of course), plus using a function claiming to be experimental. --KnightMiner (t|c) 04:35, 7 September 2014 (UTC)

Demonstration --KnightMiner (t|c) 03:49, 8 September 2014 (UTC)
I'd love to get rid of that parameter, give it a try. MajrTalk
⎜ 05:19, 8 September 2014 (UTC)
It worked! rowspan is now automatic. @Majr: Would you mind removing the outdated rowspan parameters using you bot? --KnightMiner (t|c) 14:17, 8 September 2014 (UTC)
I'd rather leave it for a bit so we can easily revert if there is a problem. MajrTalk
⎜ 00:45, 9 September 2014 (UTC)
The only problems I found so far were caused by incorrect usage of the template. I had to remove support for a few cases to make the new system fully work, so I adjusted the incorrect usages. --KnightMiner (t|c) 00:52, 9 September 2014 (UTC)
You could've just removed the rowspan parameter from the template. MajrTalk
⎜ 00:53, 9 September 2014 (UTC)
{{{rowspan}}} was removed completely, the problem was attempting to pass a blank content with {{{2}}}, rather then using the value "unknown". The other problem was attempting to use {{{rowspan}}} with no {{{snap}}}, in which case adding support would be more trouble than it is worth, as there is already a simpler method to do that by. --KnightMiner (t|c) 00:59, 9 September 2014 (UTC)

Seems rather stable, plus it seems some people noticed {{{rowspan}}} no longer is used, and have skipped adding it. KnightMiner (t|c) 21:32, 3 October 2014 (UTC)

Yep, there's been no obvious issues, so I'll nuke it now. MajrTalk
08:47, 4 October 2014 (UTC)

Outdated function in the code

There seems to be a few outdated and somewhat broken functions leftover in the code, namely setting the header to "details" (not used for the details table within a table) and "overview". Both when used make the title that of the aforementioned, and all version links break until another header is specified. Any reason to keep them? KnightMiner (t·c) 03:29, 28 January 2015 (UTC)

I recall there was a proposal to have it able to switch between two views: details (i.e., everything) and overview (basically just changes since the last release version, ignoring all the fiddling about within development versions). I can't find the original discussion or a demo, and it doesn't seem to have been fully implemented.
Incidentally, is there any page that still uses the nested tables? It always looked a bit ugly to me, and I don't think it's necessary with the current template features. -- Orthotopetalk 07:18, 28 January 2015 (UTC)
The only page I remember the nested table being used on was Redstone Comparator, although that has since been removed, including on the translation projects. It would be rather easy to call up a list of all pages using it though.
And I forgot to mention previously that there also seems to be an outdated head function, which simply returns nothing. KnightMiner (t·c) 17:06, 29 January 2015 (UTC)
Currently, there are no pages that use the details header, as shown in the temporary category History uses details view.
I created a sandboxed version of this template shown here, which removes the details mode and outdated headers, plus cleans up the code a bit and adds a few minor features (like easy pre-release linking). Are there any objections to implementing it? KnightMiner t/c 02:07, 9 April 2015 (UTC)
Alright, I've removed the details view, and the "details", "overview" and "head" modes. If anyone disagrees now, feel free to say so. KnightMiner t/c 21:38, 21 April 2015 (UTC)

No link

I think there should be a way to make a version so that it is not a link. On user pages, the user might want to tell the version to give readers an idea of when an event happened. I notice that there are 2 |'s after the word history, so maybe it could be something like link=false. 15:39, 22 February 2015 (UTC)

It is possible, use |link=none. Example:

{{History||Text|link=none|text}}LauraFi - talk 16:57, 22 February 2015 (UTC)

@ Please try to read the templates documentation fully before requesting a feature, it states it on the documentation in the section "Versions" KnightMiner (t·c) 23:38, 22 February 2015 (UTC)

Broken 'slink' parameter

It doesn't seem to work for wikilinks or external links; it fails to display the link entirely when slink is not 'ver' or 'none'. – Sealbudsman (Aaron) frameless t/c 16:15, 8 May 2015 (UTC)

I think I got it. – Sealbudsman (Aaron) frameless t/c 19:49, 8 May 2015 (UTC)
Yeah, apparently I messed up the placement of a few brackets, causing the default to be moved to a third parameter of the "if unknown" declaration, and never noticed it due to the recent template cache issue. I went ahead and fixed another bracket I missplaced and remove the old misplaced statement. KnightMiner t/c 21:52, 8 May 2015 (UTC)

Better console edition versions

Since there are now three different version numbers for the console edition, shouldn't we list all three versions in the history section? We currently only list the Xbox 360 version unless it is exclusive to the Xbox One or PS.

I have a solution shown in my sandbox (code) which replaces the normal two columns with three, one for each of the console editions. It adds the additional parameters {{{xbox}}}, {{{xbone}}}, and {{{ps}}} to set the numbers for each version, and in the case of the playstation edition, it supports a bit of disambig for the two cases where two different versions have the same number.

So, would anyone be in support of this idea? If so, should we also add a category to mark pages using the old format for the console edition? KnightMiner t/c 22:36, 30 June 2015 (UTC)

Problem with console edition TU14

There's a bit of a dilemma with merging this to the new console format - as you can see on the Baked Potato page, the version TU14 corresponds with 1.04 for the Playstation version. The dilemma appears to only be for this version where the Playstation 3 version number is larger than the number that the PS4 version receives when it is released later, meaning that the history table in its current form seems a bit confusing ("how does 1.04 appear before 1.00?" - well 1.04 relates to the PS3 number while 1.00 relates to the PS4 number). Hopefully I've explained myself clearly enough and what is the best way to handle this problem, because what I've done on the page doesn't seem to make much sense from a reader's viewpoint. GoandgooTalk
10:22, 11 December 2015 (UTC)

I really am not sure what to do about this, as it really is Mojang's fault the PS version numbers are so different at first. I would add another column, but they sync up at 1.10 which would lead to redundant information then. The best idea I can come up with is to either specifically mark where it is a PS4 version instead of a PS3 exclusive one, or to add a fourth column that only shows before 1.10, of which both ways could be a bit confusing, but hopefully better than now. KnightMiner t/c 15:55, 11 December 2015 (UTC)

Remove header alises

Currently, just about every header has at least five aliases, and it would be a lot easier to both maintain this template and have my bot adjust headers upon update releases if the headers all had just one or two possible names. Would anybody argue with me deprecating and removing some of the redundant header names? KnightMiner t/c 21:46, 18 February 2016 (UTC)

I'd be fine with it, and I'm not particular about which ones we settle on. – Sealbudsman talk/contr 22:00, 18 February 2016 (UTC)
From the looks of it, the one or two letter ones are the most used, so I'd keep those. The full names are also used by less frequent wiki visitors, but beyond that I'll most likely get rid of the rest. KnightMiner t/c 22:27, 18 February 2016 (UTC)
Is there any reason to use cryptic aliases instead of a simple name? Like console instead of cn (???), pocket alpha instead of pa, etc.? It's not like there are a ton of these on the page. MajrTalk
03:34, 27 February 2016 (UTC)
Because they are easier to type? I mainly did not touch those ones since they were around for so long and commonly used (thus keeping just the shortest of the short names), and added cn for the sake of consistency (and to replace its previous shortname of "ps3"). Since the history tables are only used once per page, I cannot think of any reason we really need the really short names other than that I'm used to them, so I don't see it being a problem deprecating the two character aliases in favor of just the full names (which it would also help new users in learning the history tables). KnightMiner t/c 18:56, 27 February 2016 (UTC)
At long last,

There are no more pages in :Category:History_uses_deprecated_header, apart from translation pages, which are probably going away anyway. – Sealbudsman talk/contr 19:24, 29 August 2016 (UTC)

What about making the version names so they're non-breaking

I noticed that whenever you make the table small enough, the WiiU version 'Patch 1' will take two lines; 'Patch' then '1'. I thought it would be nice if the WiiU cell were non-breaking – but then I thought it might be nice if all the rest of the version links were non-breaking, such as 'Beta 1.9-pre6', so it wouldn't break into 'Beta' and '1.9-pre6'. In my thinking, there's no reason for header cells to make a row taller, if avoidable.

Now, do we have any exceptionally long version cells that still ought to split to multiple lines, that might make non-breaking an undesirable thing? – Sealbudsman talk/contr 22:52, 24 February 2016 (UTC)

The only exceptionally long titles are the dates used in early development (pre-alpha) and the occasional link, it should be easy enough to set it to wrap if either of those conditions are met though (just don't wrap if the parenthesis are added or {{{link}}} is set). I'll try to make something work once KnightBot finishes his current task (as I have to remove a category once he is done anyways). KnightMiner t/c 22:57, 24 February 2016 (UTC)
Oh yeah – links are what I'm thinking of. Yes that will probably catch all the cases. Thanks! – Sealbudsman talk/contr 23:08, 24 February 2016 (UTC)
 Done KnightMiner t/c 23:20, 24 February 2016 (UTC)

Use a module

The wikitext for this template is extremely complicated. We should use Lua.

On Wikipedia, almost every template uses a module


The Blobs16px 14:15, 24 April 2016 (UTC)

Most of the complication here comes from the fact that the cell code is located in 6 different spots, once for each console version plus two for normal versions. That being said, making this a module would benefit the template as that can be converted into a function, I just have not found time to write something that is not just about as complicated as this template is, and that module with its current state it did not increase performance much either.
I have been making a few internal changes to the template recently aimed at making the code cleaner though, such as deprecating a lot of the excessive aliases (I would prefer not to have to mw.loadData it just because it is ridiculously long), and making all types cells use consistent "empty" and "merge" values. KnightMiner t/c 19:16, 24 April 2016 (UTC)


For the 'Upcoming' and 'pocket edition upcoming' sections, could it be set up so it adds :Category:Upcoming to the page? – Sealbudsman talk/contr 12:09, 10 May 2016 (UTC)

They actually intentionally don't, as there should already be content on the page elsewhere if something is upcoming, and if not there is nothing really for a human to fix (a I normally send my bot to remove the headers once an update is released instead of manually doing it). Basically, it is a bit easier for a human to update things if they don't have a bot's to do list in the way.
If you want a list of pages that use either header though, there are subcategories of Category:Upcoming with those pages. KnightMiner t/c 22:57, 10 May 2016 (UTC)

Dates for version numbers

If a date and a version number appear in two adjacent rows, people who want to know the difference between the dates have to visit the version page. The same applies for two subsequent (not sure if that's the right word) versions, and even more for the same history entry for multiple editions.

I think it may be necessary to somehow integrate dates for versions into this template. Any ideas, objections or opinions? --AttemptToCallNil, previously known as GreenStone (report bug, view backtrace) 07:31, 19 May 2016 (UTC)

In principle I like it, as a usability feature. It is the 'history' section, after all. Do you find yourself looking up dates a lot, like you said? – Sealbudsman talk/contr 12:04, 19 May 2016 (UTC)
I often wonder what these dates are in comparison, but I'm probably too lazy to actually click the link and wait for the page to load so that I can read it. --AttemptToCallNil, previously known as GreenStone (report bug, view backtrace) 12:07, 19 May 2016 (UTC)
Could change the link's tooltip to be the release date? MajrTalk
01:59, 20 May 2016 (UTC)
Maybe, but I think this would need to be supplemented with either {{Tooltip}} formatting, a note above the table ("Hover over version numbers to see the versions' release dates" or something like that, with reduced font size), or even both. --AttemptToCallNil, previously known as GreenStone (report bug, view backtrace) 04:27, 20 May 2016 (UTC)