Join us on Discord!

Minecraft Wiki talk:Community portal

From Minecraft Wiki
(Redirected from Minecraft Wiki talk:PORTAL)
Jump to: navigation, search

This is the community's main discussion page.
Talk about anything wiki-related here!
Sign your posts with ~~~~, add new posts below others, and click "Add topic" above for new topics.
Note that this page is NOT for suggesting new ideas about the game. That belongs on the feedback site.

Did these versions actually exist?[edit]

Following the recent rediscovery of Alpha v1.0.2 I've been in the process of adding evidence of existence of various versions from Alpha which are no longer available in the launcher. There is currently one remaining version which I am yet to find any proof for:

I can't seem to find any particularly solid ground on this version's case. I've searched through various YouTube videos, but it appears to be elusive, and I'm not being too successful with finding sources on Notch's blog either. General googling also provides no relevant results, photographic or otherwise.

There's also a few versions that can be presumed to exist due to later patches, but don't have pages, and I have also had no success verifying:

Can anyone help provide proof (video, screenshot, blog post or otherwise) that any of these four versions existed? - MinecraftPhotos4U (talk) 14:35, 21 March 2018 (UTC)

I can provide some history from the wiki, which seems to show that it doesn't exist: a1.0.15 was added to version history in revision 13802 and included the changes given to a1.0.14_01. But it was put before multiplayer instead of after, so there were two a1.0.15 versions listed, and this was also an after-the-fact revision (dated 25 August 2010). (n.b. I bypassed the broken username in version history by just manually editing the date)
This was later converted into a table in revision 15910, and that changed the second a1.0.15 to a1.0.14 (probably by accident), so that there were two a1.0.14's listed; this is also when it was given a release date of August 03 2010. This duplicate entry continues on for years, until the articles are split off in revision 212986. The alpha history was put here. And, it was eventually the unique _01 name in revision 370385 when Fenhl refactored the links in the article.
As one more point of evidence, check the history of Patch history. There is only Seecret Friday 7 (with the last edit on 31 July 2010) and Seecret Friday 8 on 20 August 2010. No a1.0.14_01. And, finally, it just doesn't make sense; the changes for a1.0.14_01 include "Can enter the IP for a server other than Mojang's server", yet a1.0.15 is supposed to be the version that introduced support for multiplayer.
Basically, it is pretty clear to me that this version doesn't actually exist, and all of the changes listed for it are actually part of a1.0.15. No comment for the other versions yet. --Pokechu22 (talk) 18:18, 21 March 2018 (UTC)
Alpha v1.0.14_01 doesn't exist, the only blog post that would be fitting belongs to Alpha 1.0.15. The post is mislabeled as Alpha 1.0.14 though, but comparing the dates of the jars and the timestamps of various blog posts it becomes clear that this one is indeed for Alpha 1.0.15. – Fuzs 19:26, 21 March 2018 (UTC)

On a similar topic, it seems as though the versions 0.30_01, 0.30_02 and 0.30_03, as listed in Version history/Classic, are all misnomers/conjectural; these were all called 0.30 in the page's initial revision, and looking at the corresponding blog posts on Word of Notch showed that they also shared the 0.30 title ingame. The situation with the 0.24 versions is identical. Does this affect any other versions? - MinecraftPhotos4U (talk) 18:58, 22 March 2018 (UTC)


I appear to have found the proof that Alpha 1.0.17_01 does indeed exist, as per here: https://i.imgur.com/SAkZp.png sourced from here: https://www.reddit.com/r/Minecraft/comments/d3fmt/double_tree_what_does_this_mean/ 44trent2 (talk) 08:14, 25 April 2018 (UTC)

added! There's one that can be crossed off of the list.
Now that we're also keeping track of Classic versions now, here's an updated list of conjectural versions:

And the "no-proof-so-they-might-as-well-be-fakes":

Would this be better split off into its own project? - MinecraftPhotos4U (talk) 10:30, 25 April 2018 (UTC)

Probably, yes. – Nixinova Grid Book and Quill.png Grid Diamond Pickaxe.png Grid Map.png 05:51, 26 April 2018 (UTC)
I'll get around to setting it up at somewhere along the lines of Minecraft Wiki:Projects/Proving missing versions sooner or later. - MinecraftPhotos4U (talk) 15:22, 5 May 2018 (UTC)

Creating empty/contentless pages[edit]

Please stop creating new pages that are functionally empty (e.g. they only contain maintenance tags such as {{Stub}} or text such as "Foobar is a block.") Such pages are useless to readers; because links to these pages become blue, readers are misled into thinking there is useful content on these pages. This practice is especially useless if you create a page in this manner and then immediately turn around and edit the page with useful content. If this continues, lI'm going to start handing out blocks over it. ディノ千?!? · ☎ Dinoguy1000 14:26, 18 April 2018 (UTC)

Yes! Several chemistry-related pages were created in this way, which was bothersome. Others (the 4 utility blocks) were created with useful text, except it was copied directly from the education edition website, which is also not wanted. - Princess Nightmoon (TalkContributions) 15:17, 18 April 2018 (UTC)
I've also noticed this for snapshot pages. For example, there will be a tweet that "a snapshot may come out later today," and somebody will create that as soon as the tweet is posted, with the only content being "Dinnerbone tweeted that a snapshot will come out today." I understand that it's exciting when this happens, but there really is no reason to rush. I have complete trust that editors will create the snapshot page within 5 seconds of its release (I mean, literately).-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 15:22, 18 April 2018 (UTC)
Yeah, this is a problem I've noticed happening for a while. The creation of contentless stubs for the various Classic versions is what finally spurred me to comment on it, though. ディノ千?!? · ☎ Dinoguy1000 15:24, 18 April 2018 (UTC)
I'd say there are two cases here. One would be creating the articles, and marking them all as {{In use}} so that two people don't work on making it at the same time. In my opinion, that's fine (though the template should probably be used for that case). Another would be just creating an article where the subject doesn't even exist yet (e.g. future snapshots) and the article couldn't be written. That's a case where I would say it's a problem. --Pokechu22 (talk) 16:16, 18 April 2018 (UTC)
If someone wants to work on an article like that, they need to do it in their userspace and then move it to the mainspace when it's ready to go. Trying to prevent duplication of effort is not a valid reason to create empty/contentless pages. ディノ千?!? · ☎ Dinoguy1000 23:26, 18 April 2018 (UTC)
MinecraftPhotos4U, please read this section, and note that in the future, reverting edits that change empty/contentless pages to redirects will result in a block. ディノ千?!? · ☎ Dinoguy1000 23:26, 18 April 2018 (UTC)
After checking those edits, I was mistaken about what you did. However, in the future if you properly create a page from an edit revert, please replace or delete the edit summary before saving so your edit isn't listed as a revert in the page history. ディノ千?!? · ☎ Dinoguy1000 23:32, 18 April 2018 (UTC)
Play dashtm, please read this section. ディノ千?!? · ☎ Dinoguy1000 22:31, 23 April 2018 (UTC)

So, what is the community consensus here? Should we not create snapshot pages until they have been released unless there is significant coverage over the features that will be added in a source? Jjlrjjlr created 18w19a before it was released, and MinecraftPhotos4U created 18w19b, as it's expected to be released tomorrow (both of these users did it out of good faith). Whatever decision we make should probably be mentioned in the style guide. I personally like the idea of not creating any unreleased snapshot pages unless several of their features are mentioned in a source (kind of like how it currently is with version releases), but I'm open to anything. What do the rest of you think?-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 00:45, 9 May 2018 (UTC)

This isn't about creating pages for announced versions before their release (which is fine), it's about creating empty or contentless (e.g. the only content is something like {{stub}}) pages. As long as something useful can be (and is) said in the article, it can (and should) be created. ディノ千?!? · ☎ Dinoguy1000 19:49, 16 May 2018 (UTC)
So if I understand correctly, it's fine to create (snapshot) pages (before they are released yet), if it is done with useful content in the first edit. So if you'd be filling in more content later, hold off clicking the submit button before you do. Fair enough, right? – Jack McKalling [ User page Talk page Contributions ] 19:58, 16 May 2018 (UTC)
Yes, that's it exactly. ディノ千?!? · ☎ Dinoguy1000 20:00, 16 May 2018 (UTC)
Well, we could enforce this with a message (box) in the editintro, add a formal note to the already mentioned style guide, or a step further, insert a minimum data requirement to the editor (there must be some mechanic for something like that somewhere). Because I'm sure people new to this discussion are probably not going to read this before they make the same mistake others have already. These are just the tools I can think of to help, do we need any of that? – Jack McKalling [ User page Talk page Contributions ] 20:07, 16 May 2018 (UTC)
Adding a note to the style guide (or some other place where it's clear this is a wiki guideline/policy) would be ideal. An abuse filter rule can be created to catch some cases of this as well, but I don't think this problem is widespread enough to justify that (though if someone who knows their way around writing abuse filter rules wants to write one, I'd have no problem adding it; email it to me in that case). Adding an editnotice wouldn't be appropriate for this, because page creations are a very low proportion of edits, and AFAIK there's no real way to selectively display an editnotice specifically on page creation. ディノ千?!? · ☎ Dinoguy1000 20:16, 16 May 2018 (UTC)
Regarding the editnotice, wouldn't it work to just put {{#ifexist:{{FULLPAGENAME}}|| page creation notice }} in it? Interested to know if it would. And if that doesn't work, you could also try checking a variable inserted by Mediawiki:Newarticletext. The parser function failed for me, but I can't truly test it in system messages like that. So all right, lets focus on the style guide then. What about adding another phrase to Notability.General.1, so it would read for instance "Articles must contain enough information to warrant a full page. If they do not have enough content, they should be merged with other similar articles. Creating an empty page to add content to it later, is not allowed." Any thoughts? – Jack McKalling [ User page Talk page Contributions ] 20:50, 16 May 2018 (UTC)

 Unnecessary There is a separate message that occurs when creating a page. I do not know the name, but it currently starts with “You have followed a link to a page that does not exist yet”. Additionally, the message would be useful for all namespaces except user. Therefore, we should use {{#ifeq:{{NAMESPACE}}|user||[message box]}}. It would generalize the message to an indication that placeholder pages should only be created in the userspace. The BlobsPaper.png 23:21, 16 May 2018 (UTC)
System message newarticletext controls this message, so creating such a notice is possible. Not sure how useful the abuse filter would be in this case: many placeholder pages are created with infoboxes, navboxes, etc., so filtering on page length wouldn't necessarily work. A filter to prevent creating any page less than 16 bytes might stop some blank or nearly-blank pages while still allowing redirects, but could be bypassed with an empty section header and a navbox. -- Orthotopetalk 03:17, 17 May 2018 (UTC)
Of course we could just use newarticletext, I had already linked to it above, but this system message is NOT visible during preview. Does that matter here? So no adjusting the abuse filter. Also agreed the message box could be shown on more namespaces than just the mainspace. And as an example implementation of the message box, would this suffice?

Creating an empty page to add content to it later, is not allowed. Add the content before you submit.
I just used the same sentence as I suggested for the style guide. – Jack McKalling [ User page Talk page Contributions ] 08:54, 24 May 2018 (UTC)

Update Videos (up)[edit]

Are you guys still ok with this? Hugman_76 [ User page Talk page Contributions ] 14:39, 22 April 2018 (UTC)

I personally am fine with it, and it seems like many other users are too. Dinoguy1000, Orthotope? Would you be okay with doing this?-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:51, 22 April 2018 (UTC)
I'm fine with whatever the community consensus is. (Personally, I'd rather read a well-written article than watch a video, but that's mostly because I can read a lot faster than most people talk.) However, as Dinoguy repeatedly mentioned, we need a list of Mojang/developer channels to add to the video policy before this can be implemented. -- Orthotopetalk 16:43, 22 April 2018 (UTC)
Currently, there are only Help:Official sources#Video hosting services.The only YouTube channel there is TeamMojang. We should start making a section about official YouTube accounts other than Mojang's.--Skylord wars (talk) 01:06, 23 April 2018 (UTC)
I've saw that slicelime was added, could we start now? Or do we need another seperate page Orthotope? Hugman_76 [ User page Talk page Contributions ] 18:54, 23 April 2018 (UTC)
The help page is probably the ideal location for the list to go, and the video policy should be updated to point to it instead of maintaining a separate list. ディノ千?!? · ☎ Dinoguy1000 22:03, 23 April 2018 (UTC)
Alright, can we start now Dinoguy1000, Orthotope, Skylord wars, Madminecrafter12? Hugman_76 [ User page Talk page Contributions ] 15:10, 30 April 2018 (UTC)
Works for me, especially because it's now been added to the Help:Official sources page. However, should we update the video policy page as well before we do this?-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 15:22, 30 April 2018 (UTC)
The Minecraft Wiki:Wiki rules/Video policy can be easily changed, as it's copied from Terraria wiki. Minecraft Wiki can set up their own rules. The video policy should be updated. Skylord wars (talk) 15:33, 30 April 2018 (UTC)
I don't know how to do it, can someone do it? Hugman_76 [ User page Talk page Contributions ] 21:38, 1 May 2018 (UTC)

┌──────────────────────────┘

Only admins can edit the page, and none of the admins you've pinged have replied yet. I guess we can wait a week or so, and then I'll try contacting one of the active admins directly.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 21:43, 1 May 2018 (UTC)

I've made the change, though I welcome suggestions for improvements to the text there (not just my text, but any of the text on the page, most of which I didn't look very closely at while editing). ディノ千?!? · ☎ Dinoguy1000 07:35, 2 May 2018 (UTC)
So, may we start adding update videos by slicedlime? Dinoguy1000?-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 02:39, 6 May 2018 (UTC)
I think so, I'm going to start, a template is available here. Hugman_76 [ User page Talk page Contributions ] 17:22, 9 May 2018 (UTC)


 Question So to clarify, it is ok to start adding slicedlime videos to update pages now? jjlr (talk) 05:49, 10 May 2018 (UTC)

Yes! Make sure to all follow the same template (which can be found on 'Category:Update_videos' too) to not be confused. Hugman_76 [ User page Talk page Contributions ] 08:38, 10 May 2018 (UTC)
You can't use subpage transclusion as the snapshot pages are transcluded on the development versions subpages, which points the video transclusion to a subpage of that page, which obviously doesn't exist. MajrTalk
Contribs
10:17, 10 May 2018 (UTC)
{{/Update_Video}}
doesn't work, but
{{:{{subst:PAGENAME}}/Update_Video}}
fixes the issue. Applied fix to existing pages and altered the instructions on the category page. - Princess Nightmoon (TalkContributions) 12:58, 10 May 2018 (UTC)
@Princessnightmoon: That's strange how it doesn't work for you. It should work, and it does work just fine for me. So when you access this revision of 18w16a, the video does not show up? (That revision is before you added the extra :18w16a) Oh wait, I'm sorry, never mind - it's for the development versions that is doesn't show up, I should have read Majr's comment more thoroughly.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 13:06, 10 May 2018 (UTC)

Bedrock Beta versions[edit]

So, ever since the 1.2.13 betas, the version numbers have gotten pretty weird, and at the top of the weirdness is the recent Beta 1.5.0.0, the ninth beta version leading up to full version 1.4. Attempted breakdown as follows (numbers in brackets are full version numbers):

Full Version Beta Builds Update Aquatic
1.2.13
(1.2.13.54)
1.2.13.5 N/A
1.2.13.6 N/A
1.2.13.8 Build 1
1.2.13.10 Build 2
1.2.13.11 Build 3
1.2.13.12 Build 4
1.2.14 (iOS) 1.2.14.2 Build 5
1.2.14.3 Build 6
1.2.15 (iOS)
(1.2.15.01)
N/A N/A
1.2.16 (iOS)
(1.2.16.3)
Non-iOS: 1.2.13.60
N/A N/A
Future Versions 1.2.20.1 Build 7
1.2.20.2 Build 8
1.5.0.0 Build 9

Now, the article for Beta 1.5.0.0 is currently called "1.4 build 10", which is false, since it's the 9th build for 1.4 (Update Aquatic). And unlike previous numbers, it doesn't make sense for it to be "1.5 build 1", since it's not a build for 1.5. So, should it just be called "Beta 1.5.0.0"? Should the naming system be changed for the beta versions? I'm not really sure what to do here. - Princess Nightmoon (TalkContributions) 21:05, 26 April 2018 (UTC)

To be honest I have no idea what to do, I've been wondering the same thing! For 1.2.14, builds for it added update Aquatic features, but then the iOS release of it only had bug fixes. Also, the order of the builds doesn't make sense at all, and it seems like some of the Wiki, such as the bedrock Edition version template, regards all of the builds as "1.4." Anybody else have any ideas?-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 21:14, 26 April 2018 (UTC)
Yeah, out of the beta versions listed, only 1.2.13.5-6 have actually been related to the version number. 1.2.13.8 and later have all been Update Aquatic betas, with no correlation to the full versions 1.2.13 or 1.2.14 despite sharing version numbers. As briefly touched upon, naming them "Beta [number]" could be a potential solution for the 9 builds in question, but it would need consensus. - Princess Nightmoon (TalkContributions) 21:33, 26 April 2018 (UTC)
Looks like it's better if we named the version articles like "Beta [version number]". I'd consider "Update Aquatic Build [N]", but build numbers seem unreliable, judging by the 9/10 confusion, and this naming method will fail if the builds for the next major update become similarly confusingly versioned before the update's name is announced. If things get worse, we may have to resort to version release dates... but then again, nothing prevents the developers from "accidentally" releasing two or more updates on the same day in an ambiguous order. --AttemptToCallNil (report bug, view backtrace) 10:33, 27 April 2018 (UTC)
My suggestion is "Bedrock Edition Beta 1.2.6" for Bedrock Edition 1.2.6 build 1. Using this way will prevent confusion and make it a lot easier. We don't need to version numbers and update names. This is to keep consistent with Java Edition's snapshots articles. The name does not have the update name. Plus, builds are names used by Android betas only, Mojang uses the term Beta instead of builds.--Skylord wars (talk) 11:33, 27 April 2018 (UTC)
This is going to be confusing with the way we've historically treated the terms alpha/beta: as being an entire set of versions that come prior to the initial 1.0 release (just look at how {{history}} is organised). You might expect that BE Alpha 1.0 precedes BE Beta 1.1, but there's actually release versions in between. If we do this, we're going to have to make sure the infobox clearly differentiates between pre-release alpha versions, and mid-release beta versions. MajrTalk
Contribs
11:49, 27 April 2018 (UTC)
Well, that only applies to Java. While it might be confusing, it is accurate; Bedrock Edition uses Beta versions as their equivalent of Java snapshots (as of Beta 1.2.13.8), introducing experimental features which may or may not be included in the full version. Display methods in templates could be as follows:

Infobox (Beta 1.5.0.0)
"Type" indicates that it's a beta (snapshot) version, "Beta version for" indicates which version it's a beta for.

Beta 1.5.0.0
Type

Beta version

Release date

Xbox One, Windows 10, Android - April 25, 2018

Beta version for

1.4

History (dolphin)
For this one, "beta [version number]" is used in the same way as snapshots, being listed under the upcoming version they are a beta for.

Official release
November 18, 2017 Dolphins were shown in a video clip during MineCon Earth
Upcoming Java Edition
1.13 18w15a Added dolphins.
Upcoming Bedrock Edition
1.4 Beta 1.2.20.1 Added dolphins.
Beta 1.2.20.2 Dolphin model has been updated.
Dolphins now have sounds.
Beta 1.5.0.0 Now lead players to shipwrecks and underwater ruins.

- Princess Nightmoon (TalkContributions) 13:19, 27 April 2018 (UTC)

A better way is to write the version just like in-game. We don't need beta prefixes. Beta 1.5.0.0 will be just called 1.5.0.0. This can prevent confusion. Skylord wars (talk) 06:57, 28 April 2018 (UTC)

An example.

Infobox (1.5.0.0)
"Type" indicates that it's a beta (snapshot) version, "Beta for" indicates which version it's a beta for.

1.5.0.0
Type

Build

Release date

Xbox One, Windows 10, Android - April 25, 2018

Build for

1.4

I'm sure most readers can determine this is a Beta version page.Skylord wars (talk) 07:01, 28 April 2018 (UTC)

Are we going to start a renaming project?--Skylord wars (talk) 01:32, 2 May 2018 (UTC)
I don't think a renaming project would be necessary - I certainly wouldn't mind moving all of the builds to their beta titles and fixing the article's information. I would like the opinions of other editors before doing this though, as I'm not sure if we've come to a consensus yet. This will be a pretty drastic change to the wiki, so we need to make sure that the community overall is OK with doing this, so that we can avoid a mass page-move revert. Another thing to keep in mind is all of the templates and links that will need to be updated after we've done this.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 01:36, 2 May 2018 (UTC)
I guess we don't need to move all of it, but only updates after 1.0. Because the in-game version started using this format after 1.0. Before 1.0, Pocket Edition still uses build numbers in-game. This is the same with Beta 1.9 Prerelease and 1.9-pre1, we need to follow the in-game number. I have created a page User:Skylord wars/Bedrock Beta.--Skylord wars (talk) 01:46, 3 May 2018 (UTC)
I'm all for using in-game names as much as possible. Making up our own terms isn't helpful to reducing confusion. MajrTalk
Contribs
05:28, 5 May 2018 (UTC)
How about fitting the Japanese page that separates the template before and after the 1.2 release that became Bedrock Edition?--Mikanzukituyu02 (talk) 15:08, 6 May 2018 (UTC)
If you use Changelog in game as information source, 1.2.20.1 is build 8, 1.2.20.2 is build 9, 1.5.0.0 is build 10, 1.5.0.1 is build 11.--Mikanzukituyu02 (talk) 15:20, 6 May 2018 (UTC)
Can confirm the above as I’ve seen a screenshot of it that said “Build 11” on it. So referring to these as builds 9, 10, 11, etc. is fine. --Marioprotvi (talk) 13:10, 9 May 2018 (UTC)
Revisting this because yesterday on the MC Monday stream the devs announced that 1.4 would be coming very soon and said conduits would be in the second part of UA, which is 1.5. This actually makes sense because Beta 1.5.0.0 may actually the first build for 1.5 (despite just being bug fixes) and 1.5.0.1 is build 2 since that added conduits. Also, 1.2.20 may end up being similar to 1.2.14 where the betas share the same version number but the actual update contains none of the things in the beta. The current betas that are considered part of Update Aquatic (up to the last 1.2.20.x beta) would be part of 1.4, since there was no beta labeled 1.4.0.x. --Marioprotvi (talk) 16:13, 15 May 2018 (UTC)
Another thing I thought we could do is rename the articles to something like Bedrock Edition Update Aquatic build 1 on the Bedrock Edition 1.2.13 build 3 page (this would make it somewhat easier to distinct it from the other To keep the other versions mentioned as well, the lead would be something like this:
Update Aquatic build 1, also known as 1.2.13 build 3, 1.4 build 1 or beta 1.2.13.8 is a build released on March 16, 2018 that added some of the Update Aquatic features through Experimental Gameplay.


I’m not entirely sure how this would work but I’ll explain it more in detail soon. --Marioprotvi (talk) 00:45, 16 May 2018 (UTC)
Dinoguy1000 undid nearly every single edit I did to try and fix this problem and he claims “no source was given”. We need to settle this right now (pinging KnightMiner, Skylord wars, Majr and any others i couldn’t immediately think of) as Bedrock Edition 1.4 build 11 is mislabeled - there are no conduits in the full 1.4 release (I checked, not added even in EG) but this is a 1.5 feature that is in an article under 1.4 which is factually incorrect. Someone needs to email the development team itself to see if they can provide better information to fix this. --Marioprotvi (talk) 19:28, 16 May 2018 (UTC)
As I explained on your talk page, the names of version articles should reflect those versions' in-game names (see also MinecraftPhotos4U's massive cleanup and correction campaign with early Minecraft versions, which featured a lot of renaming for that purpose). If you can demonstrate that a given build is named in-game how you renamed its article, then the rename is fine and can be redone. Otherwise, if you can demonstrate the name was used in an official source, it should be noted in the article as an alternative name. Beyond that, if there is incorrect information in the articles, it should be corrected (for most of them, if anything is required, this probably just means clarifying what version the build is actually for). This does not mean, though, that articles should be "corrected" because a given feature in the build isn't included in the release version the build is named for (that comes down to the versioning for BE being messed up in the first place, and is not our place to try to fix, though we should explain it for readers). ディノ千?!? · ☎ Dinoguy1000 19:56, 16 May 2018 (UTC)
Now that I think about it, the way the betas were named post-1.0 actually seems like a plausible idea (like what Skylord wars suggested) since they are the actual numbers in-game. --Marioprotvi (talk) 20:01, 16 May 2018 (UTC)
I've created two template mockups for Template:Bedrock Edition versions so we can vote which one is more suiting.
Mock-up #1
Mock-up #2
Personally I'd be willing to go with the second one since thats what its referred to in-game, although the alpha/beta name can be template-only and the pages without the name - e.g "beta 1.2.13.8" would link to Bedrock Edition 1.2.13.8. This creates problems with 1.0 and 1.1 as their respective builds were labeled "alpha v1.x.x.x" during gameplay but it changed to "beta v1.x.x.x" from 1.2 onwards. If such a case rises we can just name it Bedrock Edition alpha 1.1.0.0 with alpha being all lowercase to be different from the Alpha phase of development (0.1-0.16). Same would go for beta. --Marioprotvi (talk) 22:34, 16 May 2018 (UTC)
We need to do something about 1.4, it's currently claiming that beta versions for 1.2.13, 1.2.14, and the seemingly non-existent 1.2.20 belong to it, but then the page's themselves refer to the parent version of the same name. So which is it? It looks more like those versions are entirely separate from 1.4, but re-implemented features from it in a "pseudo beta" behind the experimental gameplay setting. MajrTalk
Contribs
06:07, 18 May 2018 (UTC)

Deletion requests for mod pages[edit]

Several IPs (I'm pretty sure they're the same person though, as their IPs are very similar and always have a similar edit summary) are going to mod pages for mods that only work in outdated versions, and requesting that they be deleted. I'm not familiar with mods and how they should be incorporated into the wiki, which is why I'm asking this question to the community. If a mod does not work in the current version, should it be deleted? Like I said, I'm not too familiar with the subject, so I haven't been adding any deletion templates myself, but if the answer is "No, just because the mod doesn't work in the current version doesn't mean the mod page should be deleted," then I will start reverting the edits from the IP(s) adding {{delete}}.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:18, 4 May 2018 (UTC)

Trivially, this is not enough reasoning. No mod would work with the ultra-new, two-hour-old JE release, and this is not valid basis to nuke every mod page there is.
However, mod pages in general seem to be largely abandoned. Some of them are almost contentless. I think we should change the topic of the conversation to the more general one of mod article policy on this wiki. --AttemptToCallNil (report bug, view backtrace) 14:27, 4 May 2018 (UTC)
I do agree that we should discuss the mod policy on the wiki. However, for short term purposes, should I let the IP(s) add deletion templates to every single mod page there is that does not work in the current version (which is pretty much what they're doing now), or revert the edits?-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:52, 4 May 2018 (UTC)
I'm not the final authority, but I'd just check, and if both the mod is available for download, and the required MC version is listed in the official launcher, I'd revert; if not, I'd replace the deletion reason with "no longer available/usable". --AttemptToCallNil (report bug, view backtrace) 15:47, 4 May 2018 (UTC)
We also need to make the same decision about custom servers.
I'm totally happy to get rid of all the mods and move them to ftb:. It's better set up to work with mods, whereas ours are just tacked on the side with vanilla taking the main space. I think it's a lot simpler to have this wiki focus on vanilla, and FTB and individual wikis focus on mods.
@Xbony2: What's FTB's policy on abandoned mods and ones for outdated versions of Minecraft, such as what's currently inhabiting Category:Pending deletion? MajrTalk
Contribs
05:20, 5 May 2018 (UTC)
I believe the question of mods has come up on Slack in the past, though I couldn't say what (if any) result came of it; personally I'd be in favor of Majr's suggestion to move all mod content to FTB and/or individual wikis. Doing this would also let us simplify several templates that have for years had to include support for mods (IIRC it would mostly be the inventory-related templates that are affected).
I added a comma to your comment to clarify your meaning, Majr, feel free to remove it if I got it wrong or you don't want it there.
ディノ千?!? · ☎ Dinoguy1000 08:12, 5 May 2018 (UTC)
What would you have other language wikis do with their mod articles? The Russian wiki has a substantial portion of users contributing mainly to mod articles. --AttemptToCallNil (report bug, view backtrace) 09:23, 5 May 2018 (UTC)
That would be up to each wiki to decide for themselves; the English wiki shouldn't presume to dictate how the other-language wikis have to operate. If any of them want to go the suggested route here, though, the obvious option would be checking if there's an FTB/individual wiki in that language, and if not, seeing about having one set up (assuming the FTB/individual wiki isn't currently operated as a multilingual wiki). ディノ千?!? · ☎ Dinoguy1000 09:32, 5 May 2018 (UTC)
En's mod articles being mostly garbage and unmaintained doesn't affect other languages, so I don't see how us getting rid of them entirely does either. MajrTalk
Contribs
09:58, 5 May 2018 (UTC)
  1. English wiki deletes mod articles.
  2. English wiki removes mod support from templates/modules.
  3. A non-English wiki (Wiki X) decided to keep their mod articles and use the original template/module versions.
  4. Affected templates/modules are updated on the English wiki in order to introduce functionality needed on all language wikis. The update requires nontrivial adaptation (i. e. beyond copying and string translation) in order to make it work with the original, mod-supporting templates/modules. As a result, a major portion of mod templates/modules on Wiki X now requires substantially more effort to update.
I don't think this is an improbable scenario. --AttemptToCallNil (report bug, view backtrace) 10:11, 5 May 2018 (UTC)
That's fair, in which case I would use separate templates for mods. If we were keeping mods, that's what I'd want to do anyway, as supporting mods makes some things difficult to do (like getting rid of the legacy grid images). MajrTalk
Contribs
12:05, 5 May 2018 (UTC)

┌───────────────────────┘
I'm not exactly sure what "separate templates for mods" means. Something like a Slot which only supports vanilla and ModSlot which also supports mods? And then Crafting for vanilla recipes, and ModCrafting for recipes from mods, plus similarly separated template pairs for all other interfaces? --AttemptToCallNil (report bug, view backtrace) 13:04, 5 May 2018 (UTC)

If the features mods need diverges from the features vanilla needs enough, it would be easier yes. If possible, it should be designed so that the mod version can just implement the extra features and hook in to the vanilla version for output. But if it's simple to include, we don't necessarily need to remove mod support entirely. MajrTalk
Contribs
13:34, 5 May 2018 (UTC)
Vanilla supports mod content via namespaces (vanilla uses minecraft:, other mods are assigned other namespaces). This behavior should probably be in all of the templates, especially if Mojang does end up introducing content in other namespaces. I don't know enough about how the templates work to actually say how feasible this is though. (I've been adding namespaces to things when I see it, though a lot of pages still are missing them) --Pokechu22 (talk) 16:26, 5 May 2018 (UTC)
oh god, I have been pinged for a bunch of stuff I haven't seen. Please poke me on Slack if you need my attention here; echo notifications are totally broken. Sorry that this is late. We accept and would be happy to accept the move of any/all mod content to the FTB Wiki, and we have no restrictions on mods being abandon or old or whatever. -Xbony2 (GRASP) (FTB Wiki Admin) (talk) 13:02, 13 May 2018 (UTC)

Create redirects[edit]

I guess yet again, I have to discuss with the community about the creation of these redirects per MinecraftPhoto4U's move summary. The redirects I want to create are Version history/Infdev, Version history/Indev, Version history/Classic, and Version history/Pre-classic. The reason is, A a ton of pages link to these that have not been fixed, B they are all very likely search terms, and C no other versions have development stages with these titles, so there's no reason not to have these redirects. Also, I'm not sure why MinecraftPhotos4U moved them to Java Edition Version history/[Development stages], as no pages would link to them and would never need to, AND it's useless for searching, as the first letter of any word is not case-sensitive in the search box.

Also, please don't think I'm trying to be rude or anything, but MinecraftPhotos4U, I'm really not a fan of how you're moving a ton of pages without leaving a redirect, breaking a lot of links, removing search options, AND all of the moves are without discussion, could be controversial, and many times (such as this time), just really don't make any sense - and then you say that we must discuss before recreating the redirects. I'm fine with you doing this if the community agrees with this, but for me it kind of seems annoying. I really hope you don't take any offense to this - you're a great editor and you've done some great things on the Minecraft Wiki. We're all just trying to make the Minecraft Wiki a better place, and I just thought I would bring this up. Once again, please don't take this as rude or offensive, as I do not mean for it to be taken that way at all.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 22:39, 5 May 2018 (UTC)

About the redirects, most of them are fixes. See Pre-classic, Classic, Indev, and Infdev. Most search engines have fixed their links. Plus, it seems strange to let Alpha and Beta be in "Java Edition version history", while others are in "Version history". Thus, I don't see a reason to make these redirects--Skylord wars (talk) 06:40, 6 May 2018 (UTC)
It is useful to have these and they existed for ages and are still linked to by a lot of pages. What's wrong with having them? – Nixinova Grid Book and Quill.png Grid Diamond Pickaxe.png Grid Map.png 06:53, 6 May 2018 (UTC)
You don't because there's no reason to be moving these redirects in the first place. Additional redirects can be created where needed, and unused and worthless redirects can be deleted, but moving them usually doesn't make sense. Since they were warned to stop moving pages, but continued, they've been blocked for a few days. MajrTalk
Contribs
07:28, 6 May 2018 (UTC)

Hostile Mobs not spawning in singleplayer survival.[edit]

I've started a singleplayer survival world, but I've had this problem that hostile mobs rarely spawn, only spwaners work, traps that include them spawning randomly in low light platforms seem to not be working. I've tried everything;

  • lighting up caves (which are almost empty, no mobs in there, as if I was in peaceful mode)
  • afk 24+ blocks away for longer than 1 hour (only 2 creepers spawned, figured that when I found 4 gunpowder transported in the chest by hoppers at the bottom of the trap)

If there's anything I can do please let me know. I've seen other vanilla players in youtube, they get massive quantities of spawns, but I don't get any. Screenshots included.–Preceding unsigned comment was added by EternalAssassin (talkcontribs) at 19:00, May 6, 2018 (UTC). Please sign your posts with ~~~~

You may need to post in in the forum. Try turn your render distance to a higher level, it may work.--Skylord wars (talk) 11:19, 6 May 2018 (UTC)

Texture Update sprites[edit]

So when the texture update is released, will these old textures in the {{InvSprite}} stay? Or are they going to be replaced with the new ones? I propose to move the old sprite to a separate template where it will eventually be used in the history section. – ItsPlantseed|⟩ 06:16, 9 May 2018 (UTC)

@ItsPlantseed: So something like moving InvSprite to InvSpriteOld or InvSpritePre(release date here), then updating InvSprite with the new textures? jjlr (talk) 06:20, 9 May 2018 (UTC)
Yes, but I'm not sure if that's necessary though. The file has reached 1MB and I don't know if it will affect performance issues. – ItsPlantseed|⟩ 06:50, 9 May 2018 (UTC)
Performance isn't really a concern with sprites, they're meant to have lots of images in (I'd actually be more worried about the size of the documentation page). However in this case, since it's changing pretty much everything I think it would be good to split off now, just to make editing easier (smaller page/image to upload reduces edit time), and also we should probably do this for blocks and items too. Then we just need to decide if we want to make it totally historical stuff (so whenever a texture changes we move the old image to the historical invsprite), or if it should contain all textures beginning from the texture update.
I'll create the base for the modules now so anyone can start getting the new textures uploaded. MajrTalk
Contribs
07:56, 10 May 2018 (UTC)
Nice, I'll start adding texture for the items now. Also I have a question, are those "TextureUpdate" suffix temporary? We seem somewhat familiar with the current sprite title. – ItsPlantseed|⟩ 10:36, 10 May 2018 (UTC)
Of course, the current templates/modules will be moved elsewhere once the update comes out (the name of which we need to decide on), then the new ones moved over the redirects.
Also I noticed you mentioned having an issue with using find in the browser creating duplicates? Did you mean you used some sort of find/replace thing to change names rather than editing them manualy? If that's the case then I think I can fix that. MajrTalk
Contribs
10:47, 10 May 2018 (UTC)
About that, I didn't use CTRL+F to replace (well since I can't), I used the key to find the name instead of scrolling. When I search E.g 'blue', the highlighted word will be considered as a duplicate, so I can't save it until I change all the misinterpreted words into something different. It seems like it only occurs on Edge, but I'm not sure for other browser. – ItsPlantseed|⟩ 11:23, 10 May 2018 (UTC)
Ah that wasn't the bug I was thinking of then. The issue is that edge sends a blur event to elements when it moves the find highlight off of them, regardless of if it was focused (and it doesn't send a focus event on the element which it moved the highlight to), which causes the script to think the original value is undefined (because there was no focus event to set the original name), which causes the script to "change" the current name to exactly the same as it already was making it think it's a duplicate. Was easily fixed though. MajrTalk
Contribs
12:10, 10 May 2018 (UTC)
@Majr: Also, how did you manage to make semi-transparent grid images while retaining its original color transparency? I had this problem while adding the Hardened Glass. – ItsPlantseed|⟩ 07:46, 11 May 2018 (UTC)
Well it was quite awhile ago, but I seem to recall using a feature in gimp to remove the background. I would assume it's possible in other editors. MajrTalk
Contribs
03:21, 13 May 2018 (UTC)
To remove the background in gimp it's: "Fuzzy Select" or "select by color" to select just the background, then "color to alpha". This way only the background is selected and the rest of the image remains untouched, also only editors that can handle alpha (transparency) can be used to remove the background, and beyond that only a few file formats can store images with alpha, for example PNG. jjlr (talk) 23:53, 16 May 2018 (UTC)
Thanks. Even though the RGB values are slightly off, it's fair enough. – ItsPlantseed|⟩ 03:41, 17 May 2018 (UTC)


 Question How are the sprite sheets currently generated? By hand or with a script? jjlr (talk) 04:57, 17 May 2018 (UTC)

Its done using JavaScript, but the code is integrated into the wiki. Just head to any sprite page and click the edit sprite tab. KnightMiner · (t) 16:18, 17 May 2018 (UTC)
@KnightMiner: Thank you. So i can just call the sprite editor from a sandbox and create a sprite sheet directly that way? Also i'm assuming the sprites are just block renders, correct? jjlr (talk) 02:29, 19 May 2018 (UTC)
The sprite editor is for editing the sheets after the fact, since you are just using the old version of the current textures just copy InvSprite to start for the textures. KnightMiner · (t) 04:40, 19 May 2018 (UTC)
KnightMiner but in theory would starting with a blank image work? jjlr (talk) 04:59, 19 May 2018 (UTC)
Template:InvSpriteTextureUpdate is exactly that. I could copy the names over too, but they're not all necessarily relevant to the texture update version (like historical sprites), so I just left it to start from scratch. The inv sprites are just screenshots from the inventory, not renders. MajrTalk
Contribs
07:47, 21 May 2018 (UTC)

Reference template with archive support[edit]

What is everyones opinion on a reference template that allows you to specify both the original link to a page but also an archive.org link for it? Something similar to wikipedia's archiveurl option for it's citation template. jjlr (talk) 11:05, 9 May 2018 (UTC)

Could be useful, but I don't think we want to specify archive links for absolutely every reference. --AttemptToCallNil (report bug, view backtrace) 11:24, 9 May 2018 (UTC)
I know that, it would be optional, so if you don't specify an archive link it will treat it as a normal reference. jjlr (talk) 11:27, 9 May 2018 (UTC)

 Support--Skylord wars (talk) 12:46, 9 May 2018 (UTC)

 Question Where on the page would this template be used? Would it also have deadurl= and archivedate= parameters? – Auldrick (talk · contribs) 17:33, 9 May 2018 (UTC)

 Answer I was thinking it could be used in place of the ref tag, so it would be used anywhere the ref tag could be used. Also it could have archivedate and maybe a urldead parameter that accepts a binary value (0 for false;1 for true), when true it could maybe state in the reflist that the original link is dead and to use the archive link, or maybe it could automatically redirect the reference to the archive link, otherwise when false it would just do nothing. This is currently more a concept than a working idea, and i would need some help getting a working prototype. jjlr (talk) 00:24, 10 May 2018 (UTC)
I've added an {{{archive-url}}} parameter to {{link}} (which only shows if {{{dead-url}}} is set). – Nixinova Grid Book and Quill.png Grid Diamond Pickaxe.png Grid Map.png 04:18, 10 May 2018 (UTC)
That looks really good to me, except I wonder: What's the rationale behind displaying the dead URL and following it with the archive URL? Wouldn't it be better to display the original link but link it to the archive site, and insert "(archived)" without a link? That would keep users from trying to follow the dead link first. – Auldrick (talk · contribs) 15:20, 10 May 2018 (UTC)

 Agree That would make more sense, especially since the archive link is only if the original is dead. Although i would make a slight change to your idea, rather than displaying "archived" at the end i would do something more like this:


   Archived page (original ) – Example site, archived day month, year

jjlr (talk) 22:56, 10 May 2018 (UTC)

I just don't agree with intentionally displaying a broken link when you have one that works. As a link it's useless. As a record of the original source it's useful for historical reasons, but not for validating the citation, and the archive page serves both purposes so it's not needed. Besides, it will still be in the template call when you're editing, assuming nobody would bother to delete it. Anyway, here's a comparison of the proposed expansions, as I understand the preceding discussion:
Target page status Proposed by Template expansion Link(s) point to
alive "Everything Aquatic!" target
dead, archived Nixinova "Everything Aquatic!" (archived) dead target, archived target
Jjlr "Everything Aquatic!" Archived page (original) archived target, dead target
Auldrick "Everything Aquatic!" (archived) archived target
dead, not archived "Everything Aquatic!" (dead link) dead target

Auldrick (talk · contribs) 05:25, 11 May 2018 (UTC)

I've edited it to replace {{{url}}} with {{{archive-url}}} if the latter is set. – Nixinova Grid Book and Quill.png Grid Diamond Pickaxe.png Grid Map.png 19:45, 11 May 2018 (UTC)


 Question I've been trying to use {{link}} for awhile now and it doesn't seem to produce a reference entry, if it doesn't work like a reference how is it suppose to be used? jjlr (talk) 08:17, 19 May 2018 (UTC)

Sounds parameter in BlockTileEntity template[edit]

When trying to add the new audio for the conduit and beacon to their relative infoboxes i noticed the BlockTileEntity template didn't have a sound parameter, would it be possible to add one since there are quite a few tile entities that produce sound. jjlr (talk) 05:44, 10 May 2018 (UTC)


 Done by Majr.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 00:13, 11 May 2018 (UTC)

A bug in the Bug template[edit]

I've recently edited the 1.13 page on the Hungarian wiki, and found out that links to Mojang bug pages at references don't work. Instead they try to link to wiki pages like MCbug:122563. I've checked the template and it's the same as the one here. What could be the problem and how could it be fixed? david92003 (talk) 16:52, 10 May 2018 (UTC)

You need to go to hu:Speciális:Wikiközi hivatkozások and add some interwiki prefixes from Special:Interwiki. These prefixes may be used by the template (space-separated): apibug mcapibug mcbug mccebug mclbug mcpebug pebug. --AttemptToCallNil (report bug, view backtrace) 17:07, 10 May 2018 (UTC)
Thank you! david92003 (talk) 17:19, 10 May 2018 (UTC)

Audio from mp3 to ogg[edit]

Would anyone have any objection to me reuploading current mp3 files in ogg format, ogg has better compression while often providing better audio quality, and is completely open source. jjlr (talk) 01:21, 11 May 2018 (UTC)

It should be noted that IE can't play ogg. MajrTalk
Contribs
01:34, 11 May 2018 (UTC)
Although development for IE has been discontinued, and it is increasingly being replaced by other browsers. jjlr (talk) 01:56, 11 May 2018 (UTC)
Discontinued development doesn't mean it's not being used. Also Edge can't play ogg either. – Auldrick (talk · contribs) 05:36, 11 May 2018 (UTC)
You can technically open .ogg files in Microsoft Edge. You need to install this pack to open. It is free by the way. Skylord wars (talk) 08:04, 11 May 2018 (UTC)
Since that's installed by default (as least on the April 2018 update), it may as well be considered that Edge can play ogg. MajrTalk
Contribs
08:24, 11 May 2018 (UTC)


 Opinion IE has been discontinued and every other browser has support for vorbis encoded audio (webm and ogg), since IE is no longer being developed and support for it will eventually run out i don't believe it should be considered. Ogg is a much better format for audio in web browsers and has many advantages compared to mp3. If we are considering IE though then what about the other audio files on the wiki that are already in ogg format, would we reupload them in mp3 specifically for IE users? jjlr (talk) 09:48, 11 May 2018 (UTC)

IE is officially discontinued since the release of Windows 10 Edition. I dont think we need to reupload. For IE users, they should take some time to see this article. Skylord wars (talk) 04:13, 12 May 2018 (UTC)

 Oppose What about ios users?, we cant play ogg--TheCreeperStrikes (talk) 03:38, 13 May 2018 (UTC)

File:Ground_impact1.ogg[edit]

why is nothing being done about it?--TheCreeperStrikes (talk) 06:29, 12 May 2018 (UTC)

Education Edition Infdev and other backlog oddities[edit]

No, really.

The reason behind this, as well as way too many other Special:WantedPages entries, is that Template:Version nav checks the existence of articles on similarly named versions of other editions by calling #ifexist, which creates a backlink even if the target page is never supposed to exist.

Pretty much the only solution is to code the corresponding infobox row value manually. Manual substitution of already automatically inserted links shouldn't be too much of a problem. --AttemptToCallNil (report bug, view backtrace) 13:02, 13 May 2018 (UTC)

The same also goes for Bedrock Edition Infdev. See here. Skylord wars (talk) 00:51, 16 May 2018 (UTC)

Turtle shell documented on Armor page, and has its own page?[edit]

Is the Turtle Shell being documented on the Armor page, but also having its own page intentional? -EatingSilencerforBreakfast (talk) 23:39, 17 May 2018 (UTC)

Hello? Is anyone there? -EatingSilencerforBreakfast (talk) 00:32, 19 May 2018 (UTC)
I believe it is intentional. Because turtle shells can be worn as armor, but are also very different from all other armor making a separate page good for explain turtle shells in particular. jjlr (talk) 02:16, 19 May 2018 (UTC)
The helmet, chestplate, leggings and boots pages have their own pages but are also a part of the armor page. There is an unfinished discussion on whether to merge them. I would support merging these pages, as they are wearable, protective items that have a material associated with them (e.g., ‘’iron’’ helmet), and various enchantments that can be applied. Turtle shells are different because they are the only “armor” crafted using scutes, they provide water breathing as well as protection, they are not enchantable, and they can also be used for brewing. However, there is a section of the armor page that links to other wearable items, such as pumpkins and elytra. I would support mentioning turtle shells here and otherwise make turtle shells a separate page. The BlobsPaper.png 14:15, 19 May 2018 (UTC)

 Info Actually turtle shells can be enchanted with an anvil in survival mode. jjlr (talk) 00:31, 20 May 2018 (UTC)
Jjlrjjlr, the turtle shell page does not mention enchantments. Could you please list the enchantments available on a turtle shell? The BlobsPaper.png 02:59, 20 May 2018 (UTC)

 Done I added the enchantment section to the Turtle Shell page. jjlr (talk) 02:54, 30 May 2018 (UTC)

Minecraft Wiki (EN) Discord?[edit]

Crraftt has already created a Discord server for this wiki, but there's a problem.

This is our situation:

  1. We have a Discord server intended for wiki users and just interested community members.
  2. It's not prominently linked anywhere (such as on the community portal).
  3. There has been no discussion behind its creation.
  4. It has been created by a non-administrator.
  • A server not prominently linked will miss its intended audience.
  • A server prominently linked is implied to be endorsed by site administrators.
  • A server for a site not administrated by that site's administration team, but endorsed by them, is weird at best and problematic at worst.

I think there's no point in a permanently unofficial and unrecognized Minecraft Wiki Discord server, and that we should only request the server to be taken down as a last resort.

Decisions need to be made on the following points:

  1. Does the wiki need a Discord server?
  2. If it does, can it be, after some reconfiguration, the server created by Crraftt?

I propose the following:

  • In this discussion topic, the community decides on the points 1) and 2) mentioned above.
    • If the decision is against 1) (i. e. a Discord server is not needed), a further decision will need to be made on what to do with the existing one. Note: @Crraftt: please don't act rashly if the discussion starts to go against having a server, it would be better if you waited for the resolution before e. g. taking the server down.
    • If the decision is for 1), but against 2), a further decision will need to be made on the procedure of the new server's creation and deprecation/decommissioning of the existing one.
    • If the decision is for 1) and 2), Crraftt is asked to reconfigure the server as per the discussion's resolution (likely including, but not limited to, transfer of the "Server Owner" status to a confirmed wiki administrator), and the server is advertised as per the discussion's resolution (e. g. sitenotice, community portal, dedicated page like MCW:IRC, etc.)

I favor the points 1) and 2) mentioned above. --AttemptToCallNil (report bug, view backtrace) 17:37, 20 May 2018 (UTC)

While I'm not necessarily an active member of en wiki, I moderate a Discord server for other MCWiki project. I feel like a Discord server is beneficial to our (much smaller) community. It's a place where we often have a possibility to talk about edits to members who made them directly, definitely easier than discussion pages. With our current setup (recent changes feed, IRC bridge, some bots) it's also pretty neat place to hang out and banter or monitor changes. I think if properly moderated (with moderators spread around the globe) the server would be beneficial for this community as well. However, one of my fears when I created the server for project I'm contributing to was that it would distribute the discussions between the wiki and Discord, which is not what I want in a open project, chats on the Discord are closed only to server members. I think this is a really important matter that should be discussed further. Answering to two questions:
1. I think it would be beneficial for the wiki to have a Discord server
2. I'd feel safer if the server was in hands of administration member or at least more active/experienced editor, I don't mean any offence to Crraftt, I'm pretty sure their intentions are good and all they want is to make the wiki better, they seem very passionate about how they could help, but still. If Crraftt proves to be a good person to lead the server however, I have no issue with their server being the one for this community. Frisk (Talk page) 18:12, 20 May 2018 (UTC)
Perhaps I should have been more clear, but Discord has a concept of "Server Owner". Whoever created the server is initially designated such. If this person decides so, they can transfer this status to another user of the same server. A server owner has total control of the server and cannot be restricted from anything.
Given Crraftt's reaction in Slack, I don't think he would be unwilling to transfer the "server owner" status to a wiki admin. Thus, he wouldn't need to lead the server. --AttemptToCallNil (report bug, view backtrace) 18:22, 20 May 2018 (UTC)
I'm well aware of how ownerships work on the Discord, but considering the fact Crraftt didn't say anything about transferring the ownership I assumed it wouldn't happen. Frisk (Talk page) 18:39, 20 May 2018 (UTC)


 Support I feel a discord server for the wiki would be very useful, i understand there is a slack server but it seems to be more difficult to use than discord. Not to mention more people use discord than slack, which would allow more people to get involved in discussions. But i also feel the discord server should be created by a wiki admin, and should have a set of rules setup specifically for it as it would be difficult to apply wiki rules to a discord server. jjlr (talk) 01:15, 24 May 2018 (UTC)

I agree. - Erufailon4 (talk · contribs) 06:53, 24 May 2018 (UTC)

Why is the invite not working? - MinecraftPhotos4U (talk) 14:22, 24 May 2018 (UTC)

@MinecraftPhotos4U: What happens when you click it?-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:24, 24 May 2018 (UTC)
The original one may have expired. Here's a new one, it shouldn't expire. --AttemptToCallNil (report bug, view backtrace) 14:26, 24 May 2018 (UTC)


 Question So where does this currently stand, has a decision been made regarding this topic? jjlr (talk) 22:55, 27 May 2018 (UTC)

Yeah, the Discord server is already up and running with roles, channels, bots etc. A lot of wiki staff is there as well (currently 45 members overall). It's supposed to be more "public" soon. You can join to it using the link AttemptToCallNil posted above. Frisk (Talk page) 23:10, 27 May 2018 (UTC)

New snapshot pages and their related article reference[edit]

Every snapshot comes with a related article on the main website, and we create a new page for each. But each additional snapshot of the same week that is released, does not actually create a new article, but instead the previous is updated. However, the problem there is that Mojang apparently doesn't update the link to those articles consistently. Sometimes the article of an additional snapshot keeps the link of the previous, and sometimes the link gets updated to the name of the new snapshot, but not even consistently during the same week. For example, the articles for snapshots 10a, 10b, 10c and 10d all are linked by 10a, but 20a, 20b and 20c are all linked by 20b.

I just updated all snapshot articles of 1.13 to test and fix them (some were dead already). At the same time I took the opportunity to replace references to {{article}} with {{snap}}. The snap template exists specifically for these links, an alternative to the article one, so I think we should always use that instead of article. The only visual difference is that it does not include quotes around the link.

So I would like to ask everyone to from now on use {{snap}} for consistency, and secondly, to always be aware that the article link does not always include the name of the particular snapshot you're referring to. So always update the links to all same-week-snapshot articles, in case a new snapshot comes out and Mojang decided to change the existing article link. Thanks :) Lastly, do we need to update all older snapshot pages with this template as well? – Jack McKalling [ User page Talk page Contributions ] 16:56, 23 May 2018 (UTC)

I have updated the template to include quotes, and as I am the creator of the template, I have been updating the latest snapshots to incldue {{snap}} and hoped that other users would catch on. – Nixinova Grid Book and Quill.png Grid Diamond Pickaxe.png 05:24, 24 May 2018 (UTC)
@Nixinova: To clarify, where on the page would {{snap}} be placed? jjlr (talk) 05:42, 24 May 2018 (UTC)
The template specifies the link to the Minecraft.net snapshot article, and it goes into the reference just after the snapshot name of the first sentence on the page. Like this: '''18w21a'''<ref>{{snap|18w21a|May 23, 2018}}</ref> is the thirty-eighth snapshot released for [[1.13]]. The first argument is the name of the snapshot to link to, and it may be different than the one that the page is about. – Jack McKalling [ User page Talk page Contributions ] 07:31, 24 May 2018 (UTC)

Simplified version guides[edit]

For about a week now i've been working on a simplified 1.13 guide, i designed it to allow players to get a general overview of the additions and changes of 1.13, without being overwhelmed by the technical information on the 1.13 page. I think it is finally ready to let people see it, and i would appreciate opinions and suggestion from everyone, but keep in mind it is still a work in progress. The page is currently located Here. jjlr (talk) 07:14, 24 May 2018 (UTC)


 Info The guide for 1.13 should be done within the next week now, so do we know yet where it will go? I still think a tutorial page would be fine. jjlr (talk) 23:09, 30 May 2018 (UTC)

I definitely like the idea of it, and your guide certainly seems more appealing to readers than just a bunch of text, like how the normal version pages are. I'm not so sure about what it should be moved to - a tutorial page seems reasonable to me, but I would like to hear the opinions of other users. If you're planning on making version guides from 1.0.0 - to present, though, that's quite a lot - it may be worth it to even create a new root page name for version guides exclusively; e.g. Version guides/1.0.0, Version guides/1.8.7, Version guides/1.12.2, etc. For now, though, it may be better to just create this as a "Tutorials" sub page.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 23:14, 30 May 2018 (UTC)
Would it be fine to link to the guides from the main {{Java Edition versions}} template even if they were tutorials? I think that would be cool. – Sealbudsman talk | contribs 23:40, 30 May 2018 (UTC)
I definitely like the idea of that. It would be kind of crammed and a bit much to condense in a small space, but I don't think it would be too bad, especially because we're not doing it for snapshots.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 23:43, 30 May 2018 (UTC)
I also like the idea of that, but I think it would only make sense on doing it for "full" releases -- not e.g. ones like 1.7.5 or such that don't have a lot of changes (the main article for it is definitely enough for those). Perhaps they should go under the version subtitle ("Update Aquatic", "World of Color Update", etc) in the template? For minor updates that still added content such as 1.11.1 I'm not entirely sure how that would work, though (perhaps just a subsection on the main guide?). --Pokechu22 (talk) 02:33, 31 May 2018 (UTC)

 Support as a subpage of the major version update page, like Update Aquatic, not 1.13. Because the scope of the version update page includes all releases of that major version, which the guides are also if I understand correctly. And for instance 1.13 is just one release, just like 1.13.x. I find this hard to explain, but to show what I mean, it could be added to the template like this:

1.5

Redstone Update
(Guide)

Jack McKalling [ Talk Contrib ] 08:55, 31 May 2018‎ (UTC)
That's actually an even better idea in my opinion. I definitely like that. And I do think the minor updates should be mentioned somewhere - and having them as a subsection of the main guide makes the most sense to me.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 12:07, 31 May 2018 (UTC)
I also forgot to mention that if the guides become a subpage of the major update page like I showed above, the main page should also offer a link to its guide somehow, on-page. – Jack McKalling [ Talk Contrib ] 12:20, 31 May 2018 (UTC)

Madminecrafter12 for admin?[edit]

The result of the discussion was promote Madminecrafter12 and AttemptToCallNil.


Proposed both on Discord and on Slack. In the last weeks, a significant part of vandalism and spam has been handled by global administrators, and it has been suggested new local administrators should be promoted.

In specific, Madminecrafter12 was the candidate with the most support. I suggest the proposal is further discussed here, and everyone who's voiced their opinion outside the wiki re-post it in this topic.

I offer strong support for the idea to promote new administrators (or at least one), as well as weak support for the idea to promote Madminecrafter12 in particular. --AttemptToCallNil (report bug, view backtrace) 14:14, 24 May 2018 (UTC)

I appreciate you taking the time to post this. I'm also going to ping many of the people who were active in this matter outside of Slack so that they know this is going on: ReedemtheD3ad, Sealbudsman, Frisk and Pcj-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:28, 24 May 2018 (UTC)
I have reasons to believe Madminecrafter12 is the right user to acquire administrator status. With his experience on this and other wikis, good history of contributions and good communication with rest of the community he has enough of qualities to properly administrate the wiki. With Gamepedia staff admitting Minecraft Wiki needs more administration, I think adding new administrator is a responsible, if not necessary thing to do. I hope the current administration agrees. Frisk (Talk page) 14:52, 24 May 2018 (UTC)
MCW needs more active admins. GRASP and global admins shouldn't have to step in as often as they do (almost daily), especially for as large and active a wiki as MCW. Whether or not that should be Madminecrafter is up to you guys. --Pcj (talk) 15:46, 24 May 2018 (UTC)
Agreed on the new admin need, uncertain about Madminecrafter12. He's made a lot of useful and good quality contributions, but I'm not sure about his administrative decision making. I haven't seen much of that to be able to judge it. How are new admins brought up to speed with admin policies and procedures, and would they get training, supervision or some other form of guidance on how to deal with their new abilities and responsibilities? Just casually concerned and caucious, not trying to be a downvoter. – Jack McKalling [ User page Talk page Contributions ] 16:06, 24 May 2018 (UTC)
To be honest, most of what I know about admin tools is from watching how many experienced admins handle situations many times. There are several guides for admins on the Gamepedia Help wiki, and there are many more on Wikipedia, and I have read the ones that I think are the most important. However, I've found that just watching how admins handle situations (especially when comparing them to how I would handle them), is the most helpful to me. Also, I do think it might be worth noting that I'm admin on two other wikis, one of them being a Gamepedia wiki. I don't think admins necessarily get any specific training or anything, but I do think the community and bureaucrats prefer to promote admins who are familiar with how admin tools work and when to use them.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 16:29, 24 May 2018 (UTC)
Also forgot to mention I'm interested in the prior Slack discussion, but I fear I can't get access to it on this machine. Last time I joined a team on slack, the platform rendered disabled due to lack of support in my browser. I'm really hating my old machine here. – Jack McKalling [ User page Talk page Contributions ] 16:12, 24 May 2018 (UTC)
(edit conflict) Echoing the general opinion. Also, Madminecrafter12’s promotion would introduce “new blood” into the wiki’s administration — the last newly appointed admin, KnightMiner, has actually deserved his new status (in my opinion) for many years. — BabylonAS (talk | ru.Wiki Admin) 16:15, 24 May 2018 (UTC)
That was one of the things I thought the community may not be supportive of - the fact that I've not been registered for a long time like many admins are. I definitely have learned a lot in the time that I have been involved with wikis, though. And I agree that KnightMiner should have been appointed admin a long time ago - it seemed like the community was fully supported of him in early-mid 2015, but he didn't become an admin till late 2017 somehow.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 16:40, 24 May 2018 (UTC)

 Strong Support - The user have made many constructive edits, even creating the templates {{speedy delete}} and {{welcome-vandal}} templates, both are good, the most useful template was the speedy delete template. I Strongly support that the user could become admin, but should be here for at least 1-2 months more. Psl85 Chat! 16:31, 24 May 2018 (UTC)
HEKP0H of the Russian Wiki was promoted to admin just two months and ten days after registration on October 2010, but he apparently came from Wikipedia or some other wiki. The candidate is known to be a Wiki Guardian for a different Gamepedia project. — BabylonAS (talk | ru.Wiki Admin) 16:45, 24 May 2018 (UTC)
Correction: HEKP0H is one of the founders of the Russian wiki. --AttemptToCallNil (report bug, view backtrace) 16:50, 24 May 2018 (UTC)

 Strong Support also - I would be extremely comfortable with no reservations with Madminecrafter as an admin. The way he comports himself as an editor interacting with his fellow editors, old and new, and with anons, is exemplary in my opinion, and is an example worth following. He displays a self awareness of how new he is, comparative to others who have taken the role, and I believe he fully appreciates that there is much to learn -- and he certainly cares to do so, and to do things well. If he will accept the keys to do some of the things that need done around here, I fully trust him to have them. – Sealbudsman talk | contribs 19:12, 24 May 2018 (UTC)
There really is no negative consequence to making Madminecrafter12 an Administrator in my opinion. He is very active in the Slack community, already a Wiki Guardian on another wiki, and has demonstrated good hard work and determination. He is well respected and trusted by many. All good qualities for an Administrator. – ReedemtheD3ad! (talk) 17:35, 25 May 2018 (UTC)

 Support --Pokechu22 (talk) 22:14, 25 May 2018 (UTC)

 Support as well. -Sonicwave (talk) 22:22, 25 May 2018 (UTC)

Shameless self-promotion[edit]

Just wondering, what is the general opinion of the community on me becoming an administrator here? Because I am active, in a different time zone from many other administrators, already have administration experience...

I think I am capable of being at least a basic anti-vandal/spammer who monitors the Recent Changes several times every day. Any opinions? --AttemptToCallNil (report bug, view backtrace) 20:19, 24 May 2018 (UTC)


 Supportive. – Sealbudsman talk | contribs 21:29, 24 May 2018 (UTC)

 Supportive Frisk (Talk page) 21:52, 24 May 2018 (UTC)

 Support. It certainly can't hurt to have an extra admin, especially if they're known to use the tools properly. I do think that it would be nice to promote another admin besides you as well - whether or not that would be me is for the community to decide. But if you and one other user become an admin, I don't think we'll be needing another admin for a while - unless an admin suddenly decides to leave MCW indefinitely.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 22:22, 24 May 2018 (UTC)

 Support jjlr (talk) 23:58, 24 May 2018 (UTC)

 Support The wiki currently only has 13 admins exclusing bots and Abuse Filter. I suggest adding more 3 admins in total. skylord_wars (talk) 01:24, 25 May 2018 (UTC)

 Support -Erufailon4 (talk · contribs) 06:52, 25 May 2018 (UTC)
I also support AttemptToCallNil for Administrator. They also have been active in the Slack community, have demonstrated good hard work and determination, and are respected and trusted. – ReedemtheD3ad! (talk) 17:35, 25 May 2018 (UTC)

 Support, good experience with AttemptToCallNil. Self-promotion looks promising, with your success here, but I admit I don't want to carry admin responsibilities myself. I fear the power. – Jack McKalling [ User page Talk page Contributions ] 20:38, 25 May 2018 (UTC)

 Support --Pokechu22 (talk) 22:14, 25 May 2018 (UTC)

 Support -Sonicwave (talk) 22:22, 25 May 2018 (UTC)

 SupportNixinova Grid Book and Quill.png Grid Diamond Pickaxe.png 22:51, 25 May 2018 (UTC)

New mainterace templates?[edit]

Hello, I thinked today that we should need some mainterace templates, and modify the existing, and upload some images for those templates, and those templates can include, example: rewrite, more images, just released version or snapshht, to notice the readers that the pages need more rewrite. I can also add a navbox for the existing templates and deletion notices. A warning template for copyright violation can also be added, to use on copyright violation pages. If ok, can I begin to create those pages. Questions, ask below Psl85 Chat! 16:58, 24 May 2018 (UTC)

My opinions about the creation of each template:
Rewrite - In my opinion, that may not be quite necessary. You could just use {{Cleanup}} and say "This article needs to be rewritten" for the first (reason) parameter. Also, Category:Cleanup is not an extremely huge category right now, so currently I don't think it needs to be divided. As more and more features are added to Minecraft, though, this may could eventually become a useful template though.
More images - We already have that one - {{MoreImages}}. However, I do think it probably should be moved to have space in between the two words - I'm definitely going to create a redirect with the spaces though.
Just released version or snapshot - I don't really see the point of that. How would that really be useful?
Copyright vio - Could just mark those deletion. The admins aren't really that active with deleting pages requesting to be deleted anymore, but I doubt they would delete it quicker if it were separate.
I'm open to other opinions, though, and just because I may not be a fan of some of these doesn't mean you're not allowed to create them.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 17:09, 24 May 2018 (UTC)
Oh, and another thing, I do like the images idea - I think it makes the maintenance templates a lot more visually appealing with images.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 12:18, 25 May 2018 (UTC)

Allow editors to lock pages from ip edits for short periods of time[edit]

Would it be possible to add a way for editors to temporarily protect a page from ips making edits in order to avoid the long revision wars like on 18w21a, which ended up filling the page with obscenities that people visiting the wiki shouldn't need to see. For example have a way to protect it for one to two hours in order to give time for an admin to come and either extend the page protection, or block the ip. jjlr (talk) 23:53, 24 May 2018 (UTC)

Madminecrafter12 and KnightMiner i would like your opinions on this. jjlr (talk) 23:55, 24 May 2018 (UTC)
(edit conflict) I am not sure if we want users to abuse this. However, it may be helpful to add a “Short Protector” user group. Game widow, is this possible? The BlobsPaper.png 00:00, 25 May 2018 (UTC)
Jjlrjjlr, are you saying that you think all users, or a certain group, should be able to protect pages, or are you just asking if there is a way for anybody to protect a page? If you mean the second option, then admins can semi-protect (allow only registered users) or fully-protect (allow only admins) a page. However, protection is usually (there are many exceptions though) only done when there are mutiple users vandalizing a page - otherwise, it's usually just better to block the vandal.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 00:03, 25 May 2018 (UTC)
@Madminecrafter12: I'm suggesting allow all, or maybe a select few (but how to decide on that?), confirmed users semi-protect a page for a short period of time in order to stop the vandalism until an admin can block the ip. jjlr (talk) 00:05, 25 May 2018 (UTC)
I definitely don't think we should allow all confirmed users to protect pages (on MCW, confirmed users are the same thing as registered users). That means that you could literately just create an account, completely blank a page, and then fully-protect it so that the vandalism can only be reverted when an admin sees what happened. Creating a new user group is a better, but I'm not sure it's worth it to create a whole new user group just to protect pages. We're currently discussing a similar matter on Slack.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 00:11, 25 May 2018 (UTC)
@Madminecrafter12: Why would it require an admin? I'm suggesting having it only semi-protect the page not fully protect it. Though i do somewhat agree that the vandal could create an account, so there would need to be a way to decide who gets to protect pages. jjlr (talk) 00:15, 25 May 2018 (UTC)

Dinoguy1000 Could we get your opinion please? jjlr (talk) 00:17, 25 May 2018 (UTC)

I don't think MediaWiki supports granting individuals such specific protecting capabilities. Its either you can protect up to your role or not, no control over specific time.
Main thing I'd be wary about giving a larger group the right to protect is people being too quick to protect pages when they get any vandalism. Mostly, if too many people get the ability, its more likely to be abused, and if too few get it that's just adding another group to ping if vandalism happens.
Best solution for this is to probably adjust the abuse filter if there are patterns that can be tracked, or to continue the other conversation on specific users to give additional rights. KnightMiner · (t) 00:49, 25 May 2018 (UTC)
On Wikipedia, there are extended confirmed users. Can we add this new group? Additional rights can be given to these users. skylord_wars (talk) 01:02, 25 May 2018 (UTC)
As mentioned earlier, we (Gamepedia) do not distinguish between registered users and autoconfirmed users, so merely having an account is sufficient to be an autoconfirmed user. We can create a new group which is allowed to protect (or semi-protect) pages, so if that's the way you want to go we can do that but i don't see a whole lot of benefit — Game widow (talk) 12:58, 25 May 2018 (UTC)
As an option, there could be an adminbot responding to commands by authorized users who are not administrators. The commands could include temporary page protection and/or even short-term blocks. The bot could be linked with the Discord server. --AttemptToCallNil (report bug, view backtrace) 13:03, 25 May 2018 (UTC)
I would support this user group, as some edit wars receive many edits before an admin can semi-protect the page or block the user.
@KnightMiner: I would also support an abuse filter. Since edit wars often involve a user reverting reverts to their own edits, the filter could prevent anonymous users from posting an edit that is similar to a recently-reverted edit. The BlobsPaper.png 14:21, 25 May 2018 (UTC)
@Blobs2: We were discussing this on Slack, and we definitely thought that the way to go was to make it so that if an IP edit is reverted 3 or 4 times within a certain timespan, they can't make another edit to that page for a certain amount of time. However, what we're not sure about is whether the abuse filter is able to detect that an edit has been reverted. If this does turn out to be possible, I definitely think that we should see how the AF goes before creating any kind of user group.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:24, 25 May 2018 (UTC)
Just checked on the Russian wiki, abuse filters can't perform such operations on page histories. --AttemptToCallNil (report bug, view backtrace) 14:44, 25 May 2018 (UTC)
Oh, darn. :(-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:46, 25 May 2018 (UTC)
Mr Pie 5 told me that he had a couple ideas on how to do what I had requested for the AF detecting edit reverts, and that he would experiment with them later.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 20:12, 25 May 2018 (UTC)
Late to the discussion, but I like the idea of a specific usergroup for dealing with spam/vandalism/edit warring etc. These tasks are not for the casual editor, as KnightMiner pointed out we need to appoint individuals who are trusted to have those abilities. I would suggest to start with the people who have already been dealing with these issues and contributed well at it. So I support a new usergroup, similar to the Autopatrol one we have, but there need to be selections and/or applications for it as well, not just on discord or slack. What is the difference between those two btw?Jack McKalling [ User page Talk page Contributions ] 20:32, 25 May 2018 (UTC)
Maybe like a "verified" group? That could contain (edit: *regular*) users that have been on the wiki for over, say, one year (edit: and haven't had any trouble). – Nixinova Grid Book and Quill.png Grid Diamond Pickaxe.png 22:12, 25 May 2018 (UTC) (Edited 03:24, 26 May 2018 (UTC))
I definitely think that if we do decide to do something like this, admins or bureaucrats should have to approve the users - how long they've been on the wiki or how many edits they've made would not be safe enough in my opinion.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 22:14, 25 May 2018 (UTC)
Just for reference, the Russian wiki once had a "moderator" user group which could delete, hide revisions and perform rollback. This group was disbanded when of the only two members one was demoted, and the second one was promoted to a full administrator. Even if the group suggested in this topic is formed with different permissions and generally in a different context, the group may meet the same fate.
One of the factors contributing to the demise of the Russian wiki group was probably an increase in local administrator activity. Given that there are two RfAs being discussed right now, both with positive outlook, creating an additional layer of vandalism combating may be excessive. --AttemptToCallNil (report bug, view backtrace) 22:24, 25 May 2018 (UTC)
A "Moderator" group sounds like it would work perfectly, so long as the group has the ability to semi-protect pages in the event of excessive vandalism. jjlr (talk) 00:37, 26 May 2018 (UTC)
I definitely support the idea, but there are things I want to say about this.
I recommend first seeing how both of the requests for adminship turn out before doing this. Who knows, maybe this won't be necessary if 1 or both of the candidates that are being discussed on the community portal talk page end up becoming an admin. I definitely think that we should see how that turns out before creating a whole new user group.
I would suggest having the following modifications from the user rights that the Russian wiki moderator group had. First of all, I'm not sure how necessary the delete tool would be. Right now it's not being used to revert that much vandalism, and it seems like it's one of the most sensitive admin tools, and abuse of it could lead to very drastic consequences. I definitely think that if we do decide to allow this moderator group to use this tool, that they should not have access to Special:Nuke. As for the hiding revisions, I haven't really made up my mind - other opinions and suggestions are welcome. I definitely think that rollbacking should be included.
And now for the protection part. Obviously, this is kind of the whole point of the group - otherwise it would just be a rollbacker group. Well, actually now that I think about it, that may not be so bad either... But anyways, one of the problems is, the ability to fully-protect pages as well as semi-protect pages are the same user right and listed on the same screen ([pagename]&action=protect), so I'm pretty sure there would be no way to allow moderators to only semi-protect pages (somebody please correct me if I'm wrong). If we did allow them to fully-protect pages, then it seems kind of counter-intuitive to not allow them to edit fully-protected pages, so it would probably be better to give them that right as well. I don't think that moderators should be allowed to block, though, as in my opinion, that's one of the more sensitive admin tools as well. It not only has potential to be abused, but a user may not be sure when to use it, and may block a good-faith editor unfairly.
Besides those things, this sounds like a good idea. Thanks for bringing it up, Jjlrjjlr!-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 00:56, 26 May 2018 (UTC)
If I remember correctly, you are only allowed to protect a page to a group you have access to, which is why all admins are also directors: to allow them to protect pages with director. There is a chance that feature is from an extension though, so don't quote me on that. KnightMiner · (t) 01:09, 26 May 2018 (UTC)
@KnightMiner: Hmmm... interesting, that would definitely be nice if that is true. Are you basically saying that if, e.g. all registered users could protect pages, they could only semi-protect pages but not fully-protect pages, because they wouldn't be able to edit fully-protected pages? Also, would it work vice versa, e.g. if the same case were true, registered users wouldn't be able to downgrade a fully-protected page to semi-?-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 01:20, 26 May 2018 (UTC)
I'm pretty sure that would work, if not I'm sure another wiki has made an extension granting that ability by now. So if going that route we would give them the ability to semi-protect for short times, and maybe an new protection level for the new "editors" and admins for the case of edit wars (if the edit war involves editors of course, not stopping after the protection would be grounds for possible loss of the additional editor rights). KnightMiner · (t) 18:31, 26 May 2018 (UTC)
 I do somewhat disagree with Nixinova's idea of it being time based, i.e. one year, because i feel time is a very unequal measure. Someone who has been here a year is not necessarily more qualified than someone who has been here six months. It should be entirely based on the individual, regardless of time. So perhaps change it to a certain number of edits, combined with how extensive those edits were? jjlr (talk) 03:52, 26 May 2018 (UTC)
As I said on slack, I
 Agree with having some sort of trusted group to allow additional management without increasing the attack vector that admins create. It should be the quality of the edits, not amount of time the editor has been here, that determines if they should be in the trusted group. The main thing to decide is what permissions the trusted group would get, what is actually possible to implement in MW, and who should be in the group. MajrTalk
Contribs
07:49, 26 May 2018 (UTC)
UESP has a Blocker group with short-term block rights only, but that's apparently a custom extension. mw:Manual:User rights suggests user rights' assignments are Boolean values (true/false) and have no parameters which can be set on a per-group basis; this page also lists no other blocking rights beyond the standard one, which apparently can't have lengths constrained server-side.
I have my doubts on "soft" enforcement of short-term administrative actions by trusted users (e. g. a blocker can issue blocks of any length an admin can, but when an admin comes, blockers' blocks are reviewed and their lengths adjusted as necessary). Judging by every comment in this thread though, people are looking for a solution built into the software.
But there's also my idea of an adminbot issuing short-term protections/blocks based on authorized users' commands. It hasn't received any comments, should I consider it rejected? --AttemptToCallNil (report bug, view backtrace) 08:56, 26 May 2018 (UTC)
I would avoid an admin bot unless the software entirely prevents what we want, they tend to feel a bit clumsy and are one extra thing to learn. It would be a lot easier on the editors to just add a new user group. KnightMiner · (t) 18:31, 26 May 2018 (UTC)


 Question So has a decision been made about this yet? jjlr (talk) 09:18, 9 June 2018 (UTC)

Use of upcoming and only templates[edit]

What is the best parameter to use for the {{upcoming}} or {{only}} templates, or a combination of them, for when a feature has been released for Bedrock Edition but only appears in snapshots for Java Edition, and does not appear in LCE at all? This is kind of the case right now for quite a few features currently.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 20:10, 25 May 2018 (UTC)

I would suggest: {{only|bedrock|java}}{{upcoming|ver=1.13}} which is [Bedrock and Java editions only][upcoming 1.13]
A digression: lately I've toyed with the idea of a single template that accomplished something like: [Bedrock & upcoming Java Edition 1.13 only] -- but A) it becomes one of those difficult-to-translate templates, and B) the combinations are many and varied, and I couldn't think of easy to use parameters for all cases. – Sealbudsman talk | contribs 20:39, 25 May 2018 (UTC)
Ok, thanks! The second one would definitely be ideal, but you're right - with all the possible combinations and variations, I'm not sure how practical it would be. I'll do the first one, though. :)-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 21:22, 25 May 2018 (UTC)

Proposal: Classification of edits in others' user pages[edit]

Discussed on the Discord server. Requested post.

Proposed classification follows ("host" is the user whose userspace is edited, "actor" is the one who edits; definitions used for convenience):


Minor edit
a minor correction unrelated to technical maintenance (spelling, grammar, etc.) Allowed unless either prohibited by host, or for actor.
Major edit
addition of content or non-maintenance formatting changes. May be explicitly allowed on draft pages by host, prohibited otherwise.
Maintenance edit
correction of problems which negatively affect site functioning, e. g. which cause the page to appear in any automatically filled list or category such as "pages with script errors". Allowed unless prohibited for actor. Host cannot restrict, reverting is considered disruptive editing.
Reversion of disruptive edits
same rules as for performing maintenance edits.
Administrative actions
an action performed as a reaction to violations of site rules. Such actions by non-admins can be overruled by admins. If the actor is an admin, the action cannot be reverted without prior admin noticeboard discussion.

Reasons for writing the proposal: it clarifies a major point not explicitly listed anywhere. Additional issues arise from the unclear status of maintenance editing of others' user pages. --AttemptToCallNil (report bug, view backtrace) 17:00, 27 May 2018 (UTC)

I agree that maintenance edits, reversion of disruptive edits, and administrative actions are fine - for obviously reasons. I also definitely think that major edits should be prohibited. However, I also support that minor edits should not be made either unless the owner has given permission to make minor edits. This hasn't been a problem lately, but if we advertise that one may make minor edits to other people's user pages, I don't think that would be good. I mean, it's somebody's user page for a reason, and if they don't mind theirs being edited, they can say so. Also, I could see minor edits having a gray area as to what is considered minor and what major.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 17:07, 27 May 2018 (UTC)
Agreeing with concerns. Version 2:

Maintenance edit
correction of problems which negatively affect site functioning, e. g. which cause the page to appear in any automatically filled list or category such as "pages with script errors". Allowed unless prohibited for actor. Host cannot restrict, reverting is considered disruptive editing.
Reversion of disruptive edits
same rules as for performing maintenance edits.
Administrative actions
an action performed as a reaction to violations of site rules. Such actions by non-admins can be overruled by admins. If the actor is an admin, the action cannot be reverted without prior admin noticeboard discussion.
Content edit
any other form of edit. Acceptable only if allowed for actor and by host.

--AttemptToCallNil (report bug, view backtrace) 17:14, 27 May 2018 (UTC)
I assume this has something to do with a proposed guideline? Because to my knowledge there is currently no official prohibition in this wiki against editing user pages other than the suggestion in MediaWiki:Editnotice-2. So where is this guideline being discussed on the wiki? (Please don't tell me to go read the Discord. Any discussion on Discord is preliminary and unofficial, not a substitute for talk page discussion.) – Auldrick (talk · contribs) 17:07, 9 June 2018 (UTC)
There is only a suggestion, and that is the problem. In addition, there is general, often unwarranted hostility against any modification of others' user pages. If there were to be a guideline (and one is being proposed), people could refer to it when editing others' user pages or discussing such actions. Currently, the only relevant provisions are either nowhere explicitly stated or too general. --AttemptToCallNil (report bug, view backtrace) 17:49, 9 June 2018 (UTC)
I'm all for using Discord to discuss ideas one-on-one or with a few, but I'm strongly opposed to using it for consensus building. I think reaching a consensus on Discord would tend to make those involved feel a sense of being finished and would subtly discourage them from considering objections raised later on the wiki. I'm not saying that I don't trust Discord users to try and be fair in their later deliberations, I'm just worried that once a group of editors agrees on something, they'll tend to act like a bloc, and an us-versus-them mentality could ensue. That's human nature. So if you're getting ready to propose a guideline, I hope you'll bring it to the wiki soon. – Auldrick (talk · contribs) 20:35, 9 June 2018 (UTC)
In the context of this proposal, Discord hasn't been used to build a binding consensus on Minecraft Wiki policy. I am aware of your concerns and share them. I cease my maintenance of the proposal for reasons not related to this discussion. --AttemptToCallNil (report bug, view backtrace) 22:01, 9 June 2018 (UTC)
A while ago I proposed adding a page with some of our user guidelines, similarly to the talk page guidelines. It would probably be good to have something similar to list not just when you are allowed to edit user pages, but what is allowed on them in the first place. Here is the draft from back then, it basically describes what is the user space, what it is allowed to contain, then who can edit it. Its been a while since I wrote it, but for the most part everything came from common practice that I just wanted an official place to write.
As for the specific proposal, I feel it could be condensed a bit. For instance, you could cover "both administrative action" and "reversion of disruptive edits" as "users may remove content that breaks the rules". I also personally do not think major and minor edits should be separated, I do not think users should be editing other people's user pages at all for non-maintenance tasks such as typos without permission. KnightMiner · (t) 00:00, 10 June 2018 (UTC)
That draft of yours actually looks good. Why don't we implement that, possibly with some modifications?
Speaking of which, here are my suggestions on that draft:
  1. The userspace is all articles According to my knowledge, "articles" is typically reserved to refer to content namespace pages. I suggest replacing "articles" with "pages" in this sentence.
  2. directly controlled by the user. That just sounds weird to me. (in Harbinger's voice) "I AM ASSUMING DIRECT CONTROL OF THIS USERSPACE." (back to normal voice) I suggest replacing this with "directly associated with a specific user" or something similar.
  3. articles that would not belong in the mainspace — similar to #1, but not exactly the same, I'm not sure this should be changed.
  4. If a subpage ends in .css or .js, it becomes a script. Strictly speaking, .css pages are stylesheets, not scripts. Also, the extension only affects the default content model of a page (it can be changed). On a side note, I've seen some users put all their actual main userpage content into a .css subpage, and then transclude that subpage onto the main userpage. Should we suggest that .css/.js user pages should not be used for other purposes than stylesheets and scripts respectively?
  5. Fixing or updating template usage ... file usage, page links, and possibly other maintenance issues such as invalid HTML. I suggest somehow adding all this there.
  6. Editing pages which the owner marked as "Anyone can edit" Suggest rephrasing as "marked as editable by other users". I see no reason any particular sentence should be mentioned (which is what the draft currently does), especially given the notice on the draft itself used different wording.
  7. please provide a link to the discussion or to a difference, given that discussions may be archived?
--AttemptToCallNil (report bug, view backtrace) 06:33, 10 June 2018 (UTC)
Overall I would be in favor of implementing it if there is enough support. As for specific comments:
  1. Fixed
  2. Fixed
  3. In this case articles makes most sense. Its for things like User:KnightMiner/1.7.banana
  4. Reworded to include style sheets. I am mostly neutral on forbidding people from using .css/.js pages for transclusion. Sure, its a pretty hacky solution, but if they feel their content is safer then that is on them. I guess the only concern is it makes maintenance harder as only an administrator or the user can change anything.
  5. Fixed
  6. Fixed
  7. The original discussion was here, though most of the discussion side railed based on a different issue at the time.
KnightMiner · (t) 22:51, 10 June 2018 (UTC)
Minor maintenance, including as "as" looks like a mistake. Also, "minor maintenance" implies some maintenance is not minor, which sounds somewhat weird to me. What kind of maintenance would not be minor?
In point 7, I wasn't asking about a link to a previous discussion on the draft, but about the text in your draft: If this is the case, please provide a link to the discussion in the edit summary for the convenience of others. --AttemptToCallNil (report bug, view backtrace) 09:24, 11 June 2018 (UTC)
For minor maintenance, I was mainly trying to distinguish it from some general wiki maintenance tasks, such as keeping articles up to date or cleaning up grammar, both of which fall under maintenance but I don't think should be freely allowed on user pages. Its not too important to distinguish as I list allowed maintenance, but I think it makes it a bit more clear that some types of maintenance do not apply.
The main reason for the link is so people don't revert with good intentions, they can just read the article. I guess a diff is useful for historical purposes though so I added that. KnightMiner · (t) 14:24, 11 June 2018 (UTC)
I see no further issues.
 Support implementing the proposal. --AttemptToCallNil (report bug, view backtrace) 15:20, 11 June 2018 (UTC)
Well spelled-out.
 Support. – Sealbudsman talk | contribs 17:50, 11 June 2018 (UTC)

Maintenance template images[edit]

Kind of revisiting the discussion Psl85 made about the new maintenance templates, but in a clearer way and this time specifically about the images. This was first discussed on Discord after the images were added to some of the maintenance templates. Basically, I see 3 options:

  1. Don't have any images at all for maintenance templates. Remove the existing ones, and don't add images to any of the others.
  2. Use images that are the same as Wikipedia's, or simulate something in real-life. This is kind of what we have now for some of the maintenance templates - e.g., splitting arrows for {{Split}}, broom icon for {{Cleanup}}, etc.
  3. Use images that are Minecraft-related. Some proposals on Discord were grass blocks moving towards each other for {{Merge}} simulating pages merging, and a piston getting ready to push a block for {{Move}} simulating moving.

Please discuss here, and new ideas are welcome as well.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 13:40, 30 May 2018 (UTC)

Ok, but I only want to have a image, and I use Minecraft-related images instead of uploading Wikipedia-related and using on the mainterace templates,
I would to have the "cleanup" brush remaining, and a warning icon want I to add on the {{delete}} page, but it is protected, I cannot do it, but I suggest some Minecraft-related images on some tags instead of Wikipedia's images. I would continue with some tags, but if no good exist will I place an information icon. psl85 ☎ Talk 13:48, 30 May 2018 (UTC)
Listing 3 options gives me the impression you'd like to standardize on this idea. I would object to making this a formal standard. I like having the images, but I wouldn't want to discourage anybody from creating a useful template because they don't have one and aren't good at making images. But maybe I'm reading too much into it, and you're just asking for input for a personal project you're considering. In that case, I'd be happy with either Wikipedia's image or a custom Minecraft one, so long as it suggests at a glance the purpose of the template. – Auldrick (talk · contribs) 14:14, 30 May 2018 (UTC)
I think having a consistent goal is more important than a consistent style. If we decide we want Minecraft themed templates, a new template will just need a Minecraft themed image later, not immediately. KnightMiner · (t) 14:23, 30 May 2018 (UTC)
Oh, yes, let me explain better. In my opinion, this is not some very formal and important thing - that is, there may be some maintenance templates that won't have images soon, or possibly never, and nobody should be discouraged from creating templates if they can't find an appropriate image. I was just curious of the general opinion and what people seemed to like the best. But yeah, thanks for bringing this up.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:29, 30 May 2018 (UTC)

 Agree with 3. I personally think if we are going to have any images, they should be Minecraft themed to match the wiki skin. I would rather not just copy the Wikipedia icons. KnightMiner · (t) 14:23, 30 May 2018 (UTC)

 Support 3. I don't believe it's necessary to demand an image for every message box out there, or even to formally declare a guideline. This is just for deciding which style we'd like to be consistent with, for those that do get/have an image. And personally I'd prefer minecraft-related ones because it's more personalizing for this wiki and fits better with the skin. – Jack McKalling [ Talk Contrib ] 14:41, 30 May 2018 (UTC)
THIS IS AN EMERGENCY SUSPENSION OF A RUNNING WIKI-BREAK.
Given the community seems to converge on option 3, I request that, if this turns out to be the case, administrator consensus overrule this decision per arguments provided below.
Beyond potential legal issues I am not qualified to and therefore shall not comment about, Option 3 introduces a precedent in which additional usage of Minecraft assets is introduced on the wiki when non-Minecraft, freely licensed materials exist, are available and carry the same meaning no less clearly while being at least as legible and possibly more technically favorable.
I insist on vetoing option 3, and furthermore, making usage of Minecraft assets banned (as in, an enforceable rule) whenever it is at all possible to use any other, freely licensed materials.
After all, there's a reason you don't just write the entire wiki in the Minecraft font. --AttemptToCallNil (report bug, view backtrace) 15:53, 30 May 2018 (UTC)
Ah-oh, surely we should not use direct minecraft graphics, even with options 3. Fully agreed on copyright issues, although I don't fully understand everything you just said. But when I'd say "minecraft-related images", I do mean related, as in newly created looking similar to the game, not actually ripping the actual graphics. – Jack McKalling [ Talk Contrib ] 16:04, 30 May 2018 (UTC)

 Support rule 3, minecraft themed images than Wikipedia-themed images, I would rather have Minecraft themed images, but the delete trashbin can be kept on the speedy delete template. psl85 ☎ Talk 16:12, 30 May 2018 (UTC)
This wiki literally uses Minecraft assets in its logo, I think using additional Minecraft assets is acceptable based on the brand guidelines, so there is absolutely no reason to make a rule against using Minecraft assets on the Minecraft Wiki. Sure, there are non licensed materials available, but there are non Minecraft licensed assets to use for our Logo and the Wiki skin as well. I see absolutely no reason to be inconsistent just because there is a copyright that we are allowed to use. KnightMiner · (t) 16:30, 30 May 2018 (UTC)
Then I propose we just write the entire wiki using the Minecraft font. Any objections? --AttemptToCallNil (report bug, view backtrace) 16:34, 30 May 2018 (UTC)
I don't see how that is relevant here. This discussion is about whether images should be added to maintenance templates, and if yes, whether Minecraft or Wikipedia images should be used. | violine1101(Talk) 16:42, 30 May 2018 (UTC)
Non-Minecraft (Wikipedia) images are conventional, freely licensed, require no maintenance in case Minecraft changes, their meaning is more apparent beyond just that they're used on Wikipedia, they are likely to be more legible and less bandwidth-heavy.
Actually, I'm for version 1. No images. The text says it all. The templates are even (or could be) color-coded for convenience. This site is not for people who can't be bothered to read a couple of prominently placed short sentences. --AttemptToCallNil (report bug, view backtrace) 16:55, 30 May 2018 (UTC)
I can't find anything that says that the wiki is not allowed to use Mojang content if it could be replaced with something else. I understand your points as to why freely licensed images are better, but I still disagree - and I certainly don't think this would be considered an emergency. I also don't see how "I propose we just write the entire wiki using the Minecraft font" is an argument that supports this.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 18:27, 30 May 2018 (UTC)
...I withdraw myself from this discussion. --AttemptToCallNil (report bug, view backtrace) 18:35, 30 May 2018 (UTC)

Minecraft Creators Summit 2018[edit]

Here is a list of everything i can find tweeted about what was discussed at the summit, feel free to edit this list as information becomes available.

  • Update aquatic was meant to pre-release May 30, 2018.[1]
  • Three updates are currently planned out for minecraft, more information will be unveiled at Minecon Earth 2018.[2]
    • At least one update is suppose to overhaul combat mechanics, another is meant change gameplay.
  • Graphics settings will be changed to add "Super Fancy" above the already existing "Fancy" setting.[3]
  • The official modding API is still planned and being developed, it will supposedly be coming to bedrock edition before java.[4].

Also thanks to JSBM for translating some of the tweets. jjlr (talk) 00:26, 31 May 2018 (UTC)


All information about the Minecraft Creator Summit 2018 can be seen in twitter. Recompiled information.
  • The summit is in Stockholm, Sweden. On May 30, 2018.
  • There will be a new grafics setting in Minecraft. There will be a "fancy" and "super fancy" setting.
  • The combat system will get an overhaul. The combat system overhaul will not be part of Minecraft 1.14. Mojang wants to take time and really get a lot of feedback.
  • Minecraft Update Aquatic was supposed to come out on May 30, 2018. It is pushed back to make sure all crucial bugs are fixed.
  • After Update Aquatic Mojang has already 3 more updates fully planned out to release. More info about that at Mine on Earth later this year.
  • Making mods available on Bedrock edition is one of the highest priorities the bedrock team has at the moment. It is a difficult process though, because of the huge amount of devices and systems. It will not come in the near future but it will happen.
  • Java modding will always be a construct of the community and continue to exist.
  • Mojang recognizes the awesome stuff the modding community has created and is actively making an effort to make modders lives easier going forward. They are working to lessen the pain that each update to the game brings.
  • Hope that there won’t be any more major fundamental changes to the game that will impact modders like 1.8 did and 1.13 probably will. Modders should have an easier time going forward.
  • Mojang recognize how awesome forge is and kind of want to let it be what it is. There won't be an official modding api in java.

--skylord_wars (talk) 11:43, 31 May 2018 (UTC)

Page locks to signal protection[edit]

This was proposed about a week ago and it only got a few responses, so I'm starting a new community portal topic. The original discussion can be seen at Template talk:Protected.

So basically, AttemptToCallNil and I came up with the idea to have locks as indicators in the top right corner of any protected page. How it would work is for each level of protection, it will show a different lock color, title, link, and category. A demonstration of this can be seen in my sandbox. The reasons I think locks should be used is because the current {{protected}} template is kind of distracting and it's not really clear where to use it. It seems to be used on only a few pages, and is kind of big, making it distracting to readers. Also, it would be confusing if it were used on templates, as readers may think that it's the actual template, rather than signifying a state that applies to the template. However, using locks instead would solve all these problems - just simply add the template to pages that are protected in any way at any level. I haven't come across any problems so far with my experimenting, although I'm sure there's something.

Anybody who wants to discuss is welcome to do so either here or at Template talk:Protected. This will be quite a big change, so it would be nice to have some feedback and opinions. =)-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 20:04, 2 June 2018 (UTC)

Support - Wikipedia does the exact same thing and I don't see why we shouldn't. --Marioprotvi (talk) 20:12, 2 June 2018 (UTC)
Well, this idea seems to be fully supported with no opposition. The question is, what do we do now? Should we wait till somebody finds a way to add the template to every page automatically, or go ahead and move it to the template namespace? (I support the second). But if we do the second, should we move it to a temporary title (such as Template:Protected 2) as a work-in-progress until we have the details worked out and possibly found an automatic way to add it? Or should we go ahead and delete the current Template:Protected (obviously removing the pages that use it as well) and move my sandbox to that title?-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:07, 7 June 2018 (UTC)
Lets figure out first how to add the template to every page automatically. If a new template is introduced before it's achieved its goal, people will start using it wrongly, introducing even more overhead work. And removing the use of the current template from pages leaves those pages (as it currently works now) without any visual clue as to the protection level. So, how can a template be transcluded automatically on a page, depending on some parser function criteria? – Jack McKalling [ Talk Contrib ] 14:20, 7 June 2018 (UTC)
By the way, page status indicators for protection levels are already limitedly used on the Russian wiki and even referenced in the page protection guidelines. I don’t think we will ever get a working automatic protection indicator only using wikitext/template means, in my vision it necessarily needs some JavaScript code (and I’m not used to program in JS). The question says: is using JS means worth it? Administrators can “hang the locks” while changing protection levels, and a specifically designed program can place these templates en masse automatically, if run via a bot account with admin privileges. — BabylonAS (talk | ru.Wiki Admin) 14:42, 7 June 2018 (UTC)

 Agree with BabylonAS. I don't think we should be prevented from doing this just because we will need complicated JS code to add it automatically. Just noting, on Wikipedia all administrators are expected to add the locks as soon as they protect a page - though sometimes they forget. There are no bots that automatically add locks - but if a protection has expired, a bot will remove the lock from the page. However, this is solved with Category:Unprotected pages using Template:Protected, and all admins would have to do is look through that category every now and then.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:56, 7 June 2018 (UTC)
It does indeed require complicated JS code. The indicator element is a virtual one in wikitext, you cannot append it to an existing page with JS, it has to be processed by the wikitext parser first (or simulated as such). I'm not saying "no" to the idea, however. I'd just really like to see this thing automated when protecting pages. It removes the need for an admin to manually edit the page to reflect the new protection level (as you've mentioned already, sometimes this is forgotten). A bot helps, but are there maybe more direct ways to make it automated? Similar to how you could show a form of message box during editing for particular situations by abusing system messages. I haven't got an idea myself, as I'm not familiar enough with all the options we got. – Jack McKalling [ Talk Contrib ] 15:04, 7 June 2018 (UTC)

New idea[edit]

This idea doesn't seem to currently be going anywhere, but I have a different but sort of related idea. Currently, when one edits a page they do not have permission they edit, they just get the following message: "The page has been protected to prevent editing and other actions." I'm thinking we kind of do closer to what Wikipedia does but omit the stuff about edit requests, etc. - mainly say the level of the protection, link to the protection log, and if it's a semi-protected page, suggest that the reader create an account. I think this would be very helpful. The great thing here is we wouldn't need a bot - it would automatically be generated with MediaWiki:Protectedpagetext. I'm going to experiment a bit with this in my sandbox.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 22:49, 16 June 2018 (UTC)

"Twinkle" gadget on this wiki[edit]

Hello! I think that this wiki should have some new gadgets from Wikipedia, such as Twinkle, Navigation popups, wikEd (I edits with this gadget installed in the JavaScript subpage), and minor gadgets for syntax highlighting, mark blocked users and admins, and dropdown menu to easily choose edit summary while editing, think I to be added to this wiki, and I search for more gadgets, if Twinkle should be added, could it be customized for use on this wiki and its usage could be same as on Wikipedia, and it may need some lesser templates and only existing templates should be used by the gadget. psl85 ☎ Talk 14:14, 5 June 2018 (UTC)


What if Minecraft appears in another game?[edit]

What shall we do if Minecraft appears in another game, like the upcoming Super Smash Bros.? Should we create an article for the game? Hugman_76 [ User page Talk page Contributions ] 16:07, 9 June 2018 (UTC)

There is a section about Minecraft references in other games (Minecraft#References_in_popular_culture) :) • Yanis48 (talk) 16:23, 9 June 2018 (UTC)
To give a more general answer, no. This wiki exists to document what's in Minecraft, not what's in other works. Besides, that "news" is just a rumor from DasVergeben, who isn't a particularly reliable source according to this GameRant article. – Auldrick (talk · contribs) 16:51, 9 June 2018 (UTC)

Development versions or current version for names, images, sprites, etc.[edit]

There seems to be some dispute as to whether the title of images, the texture of images, the texture of sprites, and the word used in articles for a certain title of a feature or texture of a feature, as to whether it should be the one in the latest development version or in the latest full-release version. It seems like the description of the actual functionality of features is always how they work in the current version (except for statements marked with {{upcoming}}), so it seems like the names and textures should be the same way. I've been trying to keep them as they are in the current version, because it seems to make the most sense - a few times this has gotten reverted, but most of the time it hasn't. Here are some examples:

  • In this edit, all instances of "fish" were replaced with "cod." I changed this back later, and this time it was actually undisputed. However, it had stayed at the 1.13 name for a long time.
  • As can be seen here, the image was reuploaded in February to comply with the new 1.13 texture. I reverted it back, explaining my reasoning. However, that was reverted again by somebody else, because File:Pufferfish 13w43a-18w08b.png exists. I didn't re-revert, because I didn't want to start an upload war.
  • All of the fish textures and sprites were updated to the 1.13 textures. I changed them back after many months of being on the 1.13 names, and most of the changing back was undisputed; in fact, I actually got a few thanks for it. However, many of the sprites now seem to use the 1.13 name - but again, I don't want to start a sprite-edit war.

In my opinion, we should try to have both the texture and name in the current development version and the current full version, but the one in the full version should always take priority. For images, the actual in-game names, such as File:Water.png and File:Pufferfish.png should be the texture of the current version, not the latest development version. However, I think there should also be separate files, e.g. File:Water in 18w15a.png and File:Pufferfish 18w08b.png, for the textures in the latest development version. For the sprite names, I think that both the name in the current dev version and the current full version should be aliases for each other - however, I think that the current name is what should be used in articles, which is not the case right now. For sprite textures I feel the same way as I do for the images - the main one should be of the texture in the current full version, but there should be an additional one with the texture in the latest dev.

My reason for this is, 1.12.2 is still the current version the game is on right now - so no matter what crazy features have been added in development versions, the names/textures in 1.12.2 are the names and textures in the game. Another reason is for consistency with the actual description of features. The descriptions of the features is mainly how it is in the current version - with upcoming changes marked with {{upcoming}}. I don't see why textures, names, and sprites should be any different. However, I do think it can't hurt to prepare for 1.13 - which is why I support adding the dev names as aliases in sprites, and upload the new textures as separate files.

I propose that we discuss this here so that we can come to a decision once and for all.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 13:49, 13 June 2018 (UTC)

I mostly agree. In my own words, I think all files and other assets that are named in-game, should always carry the same name as in the latest full release. Any new name for them introduced in development builds/snapshots/releases should be an alternate name with the relevant version in it. If the graphic was not changed, the development name should redirect, otherwise, it should be an alternate file/asset altogether. As for the text on the articles, this should always reflect the latest full release, with specific {{upcoming}} notations/history entries being the only exceptions to that. – Jack McKalling [ Talk Contrib ] 14:34, 13 June 2018 (UTC)
In my opinion, we should try to have both the texture and name in the current development version and the current full version, but the one in the full version should always take priority. The highlight of the message, and I agree with it.
I think there should also be separate files, e.g. File:Water in 18w15a.png and File:Pufferfish 18w08b.png, for the textures in the latest development version. Also agree.
For the sprite names, I think that both the name in the current dev version and the current full version should be aliases for each other - however, I think that the current name is what should be used in articles, which is not the case right now. Agree with everything but one case. If development versions for one full version change both the name and the texture, no full version exists where the new name corresponds to an item with the old texture. This is why I think that, in such cases, the new name should be mapped only to the sprite with the new texture.
--AttemptToCallNil (report bug, view backtrace) 14:58, 13 June 2018 (UTC)
I agree that upcoming textures and names should both not be used until a release. In my opinion MCW:FUTURE already applies to feature names and textures as well direct information. At the very least we should add on the style guide that it specifically applies to textures and names as well. KnightMiner · (t) 15:10, 13 June 2018 (UTC)
Ah yes, I was going to mention in the post but I forgot - whatever the consensus is, I think we should add it to the style guide. That way it will be clear to everybody that it is an official guideline, rather than just one user thinking that it makes sense one way.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 15:16, 13 June 2018 (UTC)
(Edit conflict) In the past, it clearly made better sense to stick to released versions' names and images, because those are familiar to everybody whereas updated versions might not be. Unfortunately, this rule is no longer tenable because there is no longer a clear line between released and development usage. You all may not have thought of this, given that you equate "1.12.2" with "released version" and "1.13" with "development version" (sadly, one of the many examples of insidious Java elitism among the editors on this wiki), but different editions have different chronologies and any feature can be in both states at the same time. For example, the new Pufferfish texture is already in the release version in Bedrock but still in development in Java. (The last time I looked, the Fish (mob) infobox bizarrely had the new texture but the old sprite.) Given this conflict, I think we need to be more flexible. I suggest that a texture or sprite be allowed if it has been released on any version, or used consistently across several development versions in one or more editions. – Auldrick (talk · contribs) 15:31, 13 June 2018 (UTC)
I say that makes sense to extend the idea to being released in any version. Since we can not easily just use all sprites, the one that makes most sense is whatever is the current texture, so a priority system to show the texture from the latest release makes sense. Just as long as we clearly show that it has not changed in all editions yet. KnightMiner · (t) 15:49, 13 June 2018 (UTC)
Agree with the proposed edition-related amendment. What if an item has different names and/or textures in different editions? That case isn't covered. --AttemptToCallNil (report bug, view backtrace) 16:10, 13 June 2018 (UTC)

Zombie hurt.ogg[edit]

The file doesn't work on the Zombie page. –Preceding unsigned comment was added by Enderdespawnmite (talkcontribs) at 3:50, 17 June 2018 (UTC). Please sign your posts with ~~~~

Works fine for me. KnightMiner · (t) 04:05, 17 June 2018 (UTC)

Moving mod files to a sprite sheet[edit]

Hi! In my desire to improve the mods part on the wiki, I wanted to find a solution about all these mod files, mainly grids, used only once. So I thought about making a sprite sheet for that. With the agreement and help of Madminecrafter12, I tested it and it works exactly like InvSprite. It is currently called ModSprite.png, with the corresponding template and module.

So, what do you think about that? Do you agree to move the maximum number of mod files into this sprite sheet? • Yanis48 (talk) 15:20, 17 June 2018 (UTC)

The Russian wiki creates a sprite sheet for every mod which contains sprites just for that mod. The English version of Module:Inventory slot should have similar support.
Note that some people have been moving to deprecate mod support and eventually migrate all mod articles from the wiki. --AttemptToCallNil (report bug, view backtrace) 15:33, 17 June 2018 (UTC)
I definitely that would be a good idea if we decide to keep mod content here, but there's not much point of working hard on a sprite for mods only to have all mods removed or migrated.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 15:50, 17 June 2018 (UTC)

 Opinion Hi there. i personally think that we should keep mod articles here. Any objections or support?--TheCreeperStrikes (talk) 17:49, 17 June 2018 (UTC)
I personally would be in favour of removing mod content from this wiki, but setting up a sister wiki dedicated to mod, fandom, etc, content. - MinecraftPhotos4U (talk) 17:53, 17 June 2018 (UTC)
What should we do?, Anyone? - - TheCreeperStrikes (talk) 18:05, 17 June 2018 (UTC)
Its worth mentioning this wiki has an unofficial partnership with the Feed the Beast Gamepedia, which covers many mods both in Feed The Beast packs and some independent ones. I personally would rather just drop modded content in favor of not duplicating effort between this wiki and that one. They have a much better framework set up for mods (including support for Forge features like the oredictionary in modded recipes), plus it saves us from having to make a list of guidelines about what makes a mod notable. Additionally, with how poorly maintained the mod pages are here, I doubt we would have an easy time finding enough editors to handle all the mods, most editors tend to just handle a couple mods they personally play. KnightMiner · (t) 18:23, 17 June 2018 (UTC)
😞 I spent so much effort uploading all those images and they’ll just get DROPPED? Like that?!, *deep breath* Sorry, just went a little overboard there *sigh*
-TheCreeperStrikes (talk) 18:33, 17 June 2018 (UTC)
Hmmm… maybe we could make a wiki for each individual mod (not everything)?-TheCreeperStrikes (talk) 07:52, 18 June 2018 (UTC)
Wiki for each individual mod? That's not really a great idea IMHO - seeing how much the FTB Wiki relies on some common stuff (common templates like infoboxes, navbox and oredict frameworks, vanilla Minecraft crafting templates and tilesheet, etc. - imagine syncing changes to that...) and that many mods have integration with other mods (copying a template for some machine across 10 wikis to show some mod integration?). Keeping that stuff in sync would me more trouble than it is worth. Also, you'd have a lot more than one recent changes page to keep track of. Modded content doesn't really have enough wiki manpower for splitting it like that in my opinion. --Hubry (talk) 08:24, 18 June 2018 (UTC)
Agreed with Hubry. We don't need another wiki for each mod on here. The Feed The Beast wiki already covers a great deal of the mods, it would not be a bad decision to relocate all our mod content over to that wiki, or delete if it's already there/outdated. Our wiki isn't really suitable for mods, we're just documenting the game itself. – Jack McKalling [ Talk Contrib ] 09:46, 18 June 2018 (UTC)
Then we could just export {{ModSprite}} there.-TheCreeperStrikes (talk) 14:33, 18 June 2018 (UTC)

Project announcement[edit]

MCW:Projects/Refactoring edition specific information is a new project intended to explore ways we can structure edition-specific information to yield smooth, natural prose in articles, and later to clean up articles that need it. Interested editors are encouraged to join by adding their names to the Members list on the project page. – Auldrick (talk · contribs) 02:00, 20 June 2018 (UTC)

Promotional Content