Talk: Community portal

Revision as of 19:39, 12 July 2018

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?

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:

Alpha v1.0.14_01

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":

Classic 0.0.13a_02
Classic 0.0.13a_04
Classic 0.0.14a_01
Classic 0.0.16a
Alpha v1.0.17

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

Probably, yes. – Nixinova

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

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 (Talk Contributions) 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).-- Madminecrafter12^{Talk to me} 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?-- Madminecrafter12^{Talk to me} 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 [

] 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 [

] 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 [

] 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 Blobs 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. -- Orthotope^talk 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 [

] 08:54, 24 May 2018 (UTC)

Next time, if you are writing something that is a stub and/or not completed yet, press the "Save draft" button instead of the "Save changes" button. You can come back to work by accessing the Special:Drafts page. Leduyquang753 (talk) 00:34, 24 June 2018 (UTC)

Update Videos (up)

Are you guys still ok with this? Hugman_76 [ ] 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?-- Madminecrafter12^{Talk to me} 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. -- Orthotope^talk 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 [

] 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 [

] 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?-- Madminecrafter12^{Talk to me} 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 [

] 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.-- Madminecrafter12^{Talk to me} 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?-- Madminecrafter12^{Talk to me} 02:39, 6 May 2018 (UTC)

I think so, I'm going to start, a template is available here. Hugman_76 [

] 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 [

] 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. –Majr ᐸ Talk
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 (Talk Contributions) 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.-- Madminecrafter12^{Talk to me} 13:06, 10 May 2018 (UTC)

Bedrock Beta versions

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 (iOS)	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 (Talk Contributions) 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?-- Madminecrafter12^{Talk to me} 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 (Talk Contributions) 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. –Majr ᐸ Talk
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.

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.

release
November 18, 2017		Dolphins were shown in a video clip during MineCon Earth
upcoming
1.13 {{Extension DPL}}<ul><li>[[Cyan Dye\|Cyan Dye]]<br/>{{Item \| image = Cyan Dye.png \| renewable = Yes \| stackable = Yes (64) }} '''Cyan dye''' is a [[Dyeing#Secondary\|secondary dye color]]. == Obtaining == === Crafting === {{Crafting \|head=1 \|showdescription=1 \|showname=0 \|Blue Dye \|Green Dye \|Output=Cyan Dye,2 \|type=Material }} {{Crafting \|Lapis Lazuli \|Green Dye \|Output=Cyan Dye,2 \|description={{only\|bedrock\|education}} \|type=Material }} {{Crafting \|Pitcher Plant \|Output=Cyan Dye,2 \|description= \|type=Material \|foot=1 }} === Trading === [[Wandering trader]]s sell 3 cyan dye for an [[emerald]]. == Usage == {{dye usage}} === Crafting ingredient === {{crafting usage\|ignore=Banner\|continue=1}} {{banner crafting usage}} === Loom ingredient === {{Banner loom usage\|Cyan Dye}} === Trading === {{IN\|bedrock}}, journeyman-level shepherd villagers have 20% chance to buy 12 cyan dye for an emerald. {{More info\|java=1\|Java UI does not use a specific trade slot, which results in a different chance to offer this trade.}} == Data values == === ID === {{edition\|java}}: {{ID table \|edition=java \|showforms=y \|generatetranslationkeys=y \|displayname=Cyan Dye \|spritetype=item \|nameid=cyan_dye \|form=item \|foot=1}} {{edition\|bedrock}}: {{ID table \|edition=bedrock \|showaliasids=y \|shownumericids=y \|showforms=y \|notshowbeitemforms=y \|generatetranslationkeys=y \|displayname=Cyan Dye \|spritetype=item \|nameid=cyan_dye \|aliasid=dye / 6 \|id=401 \|form=item \|translationkey=item.dye.cyan.name \|foot=1}} == History == {{History\|java beta}} {{History\|\|1.2\|[[File:Cyan Dye JE1 BE1.png\|32px]] Added cyan dye.}} {{History\|java}} {{History\|\|1.4.2\|snap=12w34a\|Added the ability to [[Armor#Dyeing\|dye]] leather [[armor]] and [[wolf]] collars.}} {{History\|\|1.4.6\|snap=12w49a\|Cyan dye can now be [[crafting\|crafted]] with [[gunpowder]] to create a [[firework star]].}} {{History\|\|1.6.1\|snap=13w19a\|[[Stained clay]] can now be crafted.}} {{history\|\|1.7.2\|snap=13w36a\|With the addition of new [[flower]]s, many secondary and tertiary dyes are now primary [[dye]]s.}} {{History\|\|\|snap=13w41a\|[[Stained glass]] can now be crafted.}} {{History\|\|1.8\|snap=14w02a\|Due to [[lapis lazuli]] being [[renewable resource\|renewable]], cyan dye is also renewable.}} {{History\|\|\|snap=14w30a\|Added [[banner]]s, which can be dyed.}} {{History\|\|1.13\|snap=17w47a\|The different data values for the <code>dye</code> ID have now been split up into their own IDs. \|Prior to [[1.13/Flattening\|''The Flattening'']], this [[item]]'s numeral ID was 351.}} {{History\|\|1.14\|snap=18w43a\|Cyan dye is now [[crafting\|crafted]] using [[blue dye]], instead of [[lapis lazuli]]. \|[[File:Cyan Dye.png\|32px]] The texture of cyan dye has now been changed.}} {{History\|\|\|snap=18w44a\|Cyan dye can now change the text color on [[sign]]s to cyan.}} {{History\|\|\|snap=19w05a\|Added the [[wandering trader]], which sell cyan dyes.}} {{History\|\|\|snap=19w11a\|Cyan dye can now be [[trading\|bought]] by shepherd villagers.}} {{History\|\|1.17\|snap=20w45a\|Cyan dye can now be used to craft [[cyan candle]]s.}} {{History\|\|\|snap=21w19a\|Cyan dye can no longer be used to craft cyan candles.}} {{History\|\|\|snap=Pre-release 1\|Cyan dye can once again be used to craft cyan candles.}} {{History\|\|1.20<br>(Experimental)\|link=1.19.3\|snap=22w42a\|Cyan dye can now change the text color on [[hanging sign]]s to cyan.}} {{History\|\|1.20\|snap=23w12a\|Added [[pitcher plant]]s, which can be crafted into cyan dye.}} {{History\|\|\|snap=23w14a\|[[Pitcher plant]]s now craft into 2 cyan dye instead of 1.}} {{History\|pocket alpha}} {{History\|\|v0.3.0\|[[File:Cyan Dye JE1 BE1.png\|32px]] Added cyan dye. It is currently unobtainable and serves no purpose.}} {{History\|\|v0.4.0\|Cyan dye is now craftable with [[lapis lazuli]] and [[cactus green]]. \|Cyan dye can now be used to craft cyan wool.}} {{History\|\|v0.6.0\|Cyan dye can now be used to dye [[sheep]].}} {{History\|\|v0.9.0\|snap=build 11\|Cyan dye can now be used to craft colored [[terracotta]].}} {{History\|\|v0.11.0\|snap=build 1\|Cyan dye can now be used to dye tamed [[wolf]] collars.}} {{History\|\|v0.14.0\|snap=build 1\|Cyan dye can now be used to dye water in [[cauldron]]s.}} {{History\|pocket}} {{History\|\|1.0.0\|snap=alpha 0.17.0.1\|Cyan dye can now be used to dye [[shulker]]s.}} {{History\|\|1.1.0\|snap=alpha 1.1.0.0\|Cyan dye can now be used to craft [[concrete powder]], colored [[bed]]s and dyed [[shulker box]]es.}} {{History\|bedrock}} {{History\|\|1.2.0\|snap=beta 1.2.0.2\|Cyan dye can now be used to craft [[firework star]]s, [[stained glass]] and patterns on [[banner]]s.}} {{History\|\|1.4.0\|snap=beta 1.2.20.1\|Cyan dye can now be used to craft [[balloon\|ballons]] and [[glow stick\|glow sticks]].}} {{History\|\|1.8.0\|snap=beta 1.8.0.8\|Cyan dye can now be used to dye tamed [[cat]] collars.}} {{History\|\|1.10.0\|snap=beta 1.10.0.3\|Cyan dye are now [[trading\|sold]] by [[wandering trader]]s. \|Cyan dye can now be used to dye white [[carpet\|carpets]] and undyed [[glass pane]]s. \|[[File:Cyan Dye.png\|32px]] The texture of cyan dye has now been changed.}} {{History\|\|1.11.0\|snap=beta 1.11.0.4\|Cyan dye can be [[trading\|sold]] to shepherd [[villager]]s.}} {{History\|\|1.16.100\|snap=beta 1.16.100.56\|The ID of cyan dye has been changed from <code>dye/6</code> to <code>cyan_dye</code>.}} {{History\|console}} {{History\|\|xbox=TU1\|xbone=CU1\|ps=1.00\|switch=1.0.1\|wiiu=Patch 1\|[[File:Cyan Dye JE1 BE1.png\|32px]] Added cyan dye.}} {{History\|PS4}} {{History\|\|1.90\|[[File:Cyan Dye.png\|32px]] The texture of cyan dye has now been changed.}} {{History\|new 3ds}} {{History\|\|0.1.0\|[[File:Cyan Dye JE1 BE1.png\|32px]] Added cyan dye.}} {{History\|foot}} == Issues == {{issue list}} {{Items}} [[Category:Items]] [[Category:Dyes]] [[Category:Renewable resources]] [[cs:Azurové barvivo]] [[de:Türkiser Farbstoff]] [[es:Tinte cian]] [[fr:Teinture cyan]] [[hu:Ciánkék festék]] [[ja:青緑色の染料]] [[ko:청록색 염료]] [[nl:Turquoise kleurstof]] [[pl:Błękitny barwnik]] [[pt:Corante ciano]] [[ru:Бирюзовый краситель]] [[zh:青色染料]]</li><li>[[:Category:Invalid data value items\|Category:Invalid data value items]]<br/>[[Category:Items]]</li></ul>	18w15a	Added dolphins.
Upcoming Bedrock Edition
1.4 {{Extension DPL}}<ul><li>[[:Category:Minecraft: Story Mode items\|Category:Minecraft: Story Mode items]]<br/>[[Category:Minecraft: Story Mode]] [[Category:Items]]</li><li>[[Carrot\|Carrot]]<br/>{{about\|the natural food item\|the golden food\|Golden Carrot\|the item for controlling saddled pigs\|Carrot on a Stick}} {{Item \| group = Age 0-1 \| 1-1 = Carrots Age 0-1.png \| 1-2 = Carrots Age 0-1 BE.png \| group2 = Age 2-3 \| 2-1 = Carrots Age 2-3.png \| 2-2 = Carrots Age 2-3 BE.png \| group3 = Age 4-6 \| 3-1 = Carrots Age 4-6.png \| 3-2 = Carrots Age 4-6 BE.png \| group4 = Age 7 \| 4-1 = Carrots Age 7.png \| 4-2 = Carrots Age 7 BE.png \| image2 = Carrot JE3 BE2.png \| renewable = Yes \| heals = {{hunger\|3}} \| stackable = Yes (64) }} A '''carrot''' is a [[food]] [[item]] obtained from carrot crops that can be used to plant them, eaten or used as a crafting ingredient. '''Carrot crops''' are planted in [[farmland]] and used to grow carrots. == Obtaining == === Breaking === {{See also\|Fortune#Seeds}} Fully grown carrot crops drop 2 to 5 carrots ({{frac\|3\|5\|7}} per crop harvested on average). Yield can be increased using a tool enchanted with [[Fortune]], with Fortune III harvesting an average of {{frac\|5\|3\|7}} carrots. The yield is calculated by a binomial distribution: 2 drops are fixed, then a drop is attempted three times with a success rate of 57.14286% to yield the extra 0–3 drops. Each level of Fortune enchantment increases the number of attempts by one. === Natural generation === [[Village]] farm plots have a chance of having carrots. The exact chance depends on the style of the village: {\| class="wikitable" ! Village style !! Chance \|- \| {{EnvSprite\|plains-village}} Plains \|\| 30% \|- \| {{EnvSprite\|snowy-village}} Snowy \|\| 10% \|} === Mob loot === [[Zombie]]s, [[husk]]s, and [[zombie villager]]s have a 2.5% ({{frac\|1\|40}}) chance of dropping either an [[iron ingot]], carrot, or [[potato]] when killed by a player or tamed wolf. This is increased by 1% ({{frac\|1\|100}}) per level of looting. This gives carrots the following chances of dropping: * {{frac\|1\|120}} (about 0.83%) * {{frac\|7\|600}} (about 1.17%) with Looting I * {{frac\|9\|600}} (about 1.50%) with Looting II * {{frac\|11\|600}} (about 1.83%) with Looting III === Chest loot === {{LootChestItem\|carrot}} == Usage == {{see also\|Tutorials/Hunger management\|title1=Hunger management}} To eat a carrot, press and hold {{control\|use}} while the carrot is selected in the [[hotbar]]. Eating a carrot restores {{hunger\|3}} [[hunger]] and 3.6 hunger [[Hunger#Mechanics\|saturation]]. === Farming === {{see also\|Tutorials/Crop farming\|title1 = Crop farming }} Carrots can be [[farming\|farmed]] and harvested on [[farmland]]. Planted carrots take 8 [[Block tick\|stages]] to grow, and go through 4 visually distinct stages. Planted carrots require a light level of 9 or greater to continue growing. If the light level is 7 or below, the crops instantly un-plant themselves ("pop off"). It is not possible to plant carrots if the light level is too low. Crops grow faster if the farmland they are planted in is [[Farmland#Hydration\|hydrated]]. Using [[bone meal]] on crops also increases the speed of growth by randomly increasing their growth stage by 2 to 5. Crops break if pushed by a [[piston]] or if their supporting farmland breaks or turns to dirt (i.e. by being trampled), dropping their usual drops. If {{cmd\|gamerule mobGriefing}} is <code>true</code>, rabbits will find mature carrot [[crops]]{{only\|je}} / carrot crops with growth stage greater than 1{{only\|be}}. This reduces the growth stages by one, removing the crop completely when the growth stage reaches 0. === Breeding === Carrots can also be used to [[breed]] and attract [[pig]]s and [[rabbit]]s. Villagers can pick up carrot items to become willing, which allow them to breed. Villagers require 12 carrots to become willing. === Trading === Novice-level Farmer villagers have a 25% ({{frac\|1\|4}}){{only\|bedrock}} or 40% ({{frac\|2\|5}}){{only\|java}} chance to buy 22 carrots for an emerald. === Crafting ingredient === {{crafting usage}} === Composting === Placing a carrot into a [[composter]] has a 65% chance of raising the compost level by 1. == Sounds == === Block === {{Sound table/Block/Crop}} === Item === {{Sound table/Entity/Food}} == Data values == === ID === {{edition\|java}}: {{ID table \|edition=java \|showblocktags=y \|showforms=y \|generatetranslationkeys=y \|displayname=Carrots \|spritetype=block \|nameid=carrots \|blocktags=bee_growables, crops \|form=block}} {{ID table \|displayname=Carrot \|spritetype=item \|nameid=carrot \|form=item \|foot=1}} {{edition\|bedrock}}: {{ID table \|edition=bedrock \|showforms=y \|shownumericids=y \|generatetranslationkeys=y \|displayname=Carrots \|spritetype=block \|nameid=carrots \|id=141 \|form=block \|translationkey=-}} {{ID table \|displayname=Carrot \|spritetype=item \|nameid=carrot \|id=279 \|form=item \|foot=1}} === Block states === {{see also\|Block states}} {{/BS}} == Advancements == {{load advancements\|Husbandry;A Balanced Diet}} == History == {{History\|java}} {{History\|\|1.4.2\|snap=12w34a\|[[File:Carrot JE1.png\|32px]] Added carrots. \|[[File:Carrots Age 0-1 JE1.png\|32px]] [[File:Carrots Age 2-3 JE1.png\|32px]] [[File:Carrots Age 4-6 JE1.png\|32px]] [[File:Carrots Age 7 JE1.png\|32px]] Added carrot crops. \|Carrots can be obtained only as a rare [[drop]] from [[zombie]]s.}} {{History\|\|\|snap=August 28, 2012\|slink={{tweet\|Dinnerbone\|240428477856231424}}\|[[Dinnerbone]] released an image of a [[saddle]]d [[pig]] being controlled with a [[carrot on a stick]]. [[Wheat]] was considered as a "fuel" along with carrots,<ref>{{Tweet\|Dinnerbone\|240188453789257728}}</ref> but Dinnerbone eventually decided on carrots.<ref>{{Tweet\|Dinnerbone\|240355810650247168}}</ref>}} {{History\|\|\|snap=12w34a\|Carrots can now be used to craft [[golden carrot]]s.}} {{History\|\|\|snap=12w36a\|Carrots can now be found in [[village]]s. \|Carrots are now used to breed [[pig]]s. \|Carrots are now used to craft [[carrot on a stick]].}} {{History\|\|\|snap=12w37a\|[[File:Carrot JE2 BE1.png\|32px]] The texture of carrots has now been changed. The texture has been changed to singular carrot, with the tooltip changed to reflect this.}} {{History\|\|1.5\|snap=13w04a\|[[Bone meal]] now grows carrots by 1 stage instead of fully growing it. The [[player]] might not see it grow, because some stages look the same.}} {{History\|\|1.8\|snap=14w02a\|Carrots now restore {{hunger\|3}} points and 3.6 hunger [[saturation]], instead of {{hunger\|4}} and 4.8 hunger saturation. \|Farmer [[villager]]s now [[trading\|buy]] 15–19 carrots for 1 [[emerald]].}} {{History\|\|\|snap=14w04a\|[[Farmer]] (profession) [[villager]]s now harvest fully grown carrots. \|Villagers can now be made willing using 12 carrots.}} {{History\|\|\|snap=14w06a\|[[File:Carrots Age 0-1 JE2.png\|32px]] [[File:Carrots Age 2-3 JE2.png\|32px]] [[File:Carrots Age 4-6 JE2.png\|32px]] [[File:Carrots Age 7 JE2.png\|32px]] Carrot crops are now a pixel higher - previously they were offset one pixel down as to match farmland's sunken model. This is likely an accidental result of model conversion.}} {{History\|\|\|snap=14w10a\|[[File:Missing Model JE2.png\|32px]] [[File:Missing Model JE2.png\|32px]] [[File:Missing Model JE2.png\|32px]] [[File:Missing Model JE2.png\|32px]]<br>[[File:Missing Model (anisotropic filtering) JE2.png\|32px]] [[File:Missing Model (anisotropic filtering) JE2.png\|32px]] [[File:Missing Model (anisotropic filtering) JE2.png\|32px]] [[File:Missing Model (anisotropic filtering) JE2.png\|32px]]<br>Carrot crops of all stages [[Missing model\|no longer have a model]].}} {{History\|\|\|snap=14w10b\|[[File:Carrots Age 0-1 JE4.png\|32px]] [[File:Carrots Age 2-3 JE4.png\|32px]] [[File:Carrots Age 4-6 JE4.png\|32px]] [[File:Carrots Age 7 JE4.png\|32px]] Carrot crops now have models again.<ref>{{bug\|MC-50232}}</ref> In addition, they are now offset downwards by one pixel once more.<ref>{{bug\|MC-50155}}</ref>}} {{History\|\|\|snap=14w25a\|[[File:Carrots Age 0-1 JE5.png\|32px]] [[File:Carrots Age 2-3 JE5.png\|32px]] [[File:Carrots Age 4-6 JE5.png\|32px]] [[File:Carrots Age 7 JE5.png\|32px]] Carrot crops are now darker and subject to directional shading.}} {{History\|\|\|snap=14w27a\|[[File:Carrots Age 0-1 JE6.png\|32px]] [[File:Carrots Age 2-3 JE6.png\|32px]] [[File:Carrots Age 4-6 JE6.png\|32px]] [[File:Carrots Age 7 JE6.png\|32px]] Carrot crops are no longer subject to directional shading. \|Added [[rabbit]]s, which can be [[breeding\|bred]] and/or tamed using carrots. Rabbits also grief carrot crops. \|Carrots are now used to craft [[rabbit stew]].}} {{History\|\|\|snap=14w34a\|Rabbits can no longer be tamed.}} {{History\|\|1.9\|snap=15w38a\|The [[drops\|drop]] chances have now been slightly improved from an average of {{frac\|2\|3\|5}} per [[crops\|crop]] harvested to {{frac\|2\|5\|7}}.}} {{History\|\|1.13\|snap=17w47a\|Prior to [[1.13/Flattening\|''The Flattening'']], this block's numeral ID was 141, and the item's 391.}} {{History\|\|\|snap=18w11a\|Carrots can now generate in the chests of [[shipwreck]]s.}} {{History\|\|1.14\|snap=18w43a\|[[File:Carrot JE3 BE2.png\|32px]] The texture of carrots has now been changed. \|[[File:Carrots Age 0-1 JE7.png\|32px]] [[File:Carrots Age 2-3 JE7.png\|32px]] [[File:Carrots Age 4-6 JE7.png\|32px]] [[File:Carrots Age 7 JE7.png\|32px]] The textures of carrot crops have now been changed.}} {{History\|\|\|snap=18w47a\|Carrots can now generate in the [[chest]]s of [[pillager outpost]]s.}} {{History\|\|\|snap=19w03a\|Placement and breaking [[sound]]s have now been added to carrots. \|Placing a carrot into the new [[composter]] has a 50% chance of raising the compost level by 1.}} {{History\|\|\|snap=19w05a\|Carrots now have a 65% chance of increasing the compost level in a composter by 1.}} {{History\|\|1.15\|snap=19w34a\|[[Bee]]s can now pollinate carrot crops.}} {{History\|\|1.17\|snap=21w13a\|[[File:Carrots Age 0-1 JE8.png\|32px]] [[File:Carrots Age 2-3 JE8.png\|32px]] [[File:Carrots Age 4-6 JE8.png\|32px]] [[File:Carrots Age 7 JE8.png\|32px]] The "crop" template model has changed such that pixels appear in the same physical positions on opposite sides of texture planes, changing the carrot crop's appearance in the process.<ref>{{bug\|MC-199242}}</ref>}} {{History\|\|1.18\|snap=Pre-release 5\|[[File:Carrots Age 7 JE9.png\|32px]] A stray dark pixel has been removed from the texture of fully-grown carrots.<ref>{{bug\|MC-226711}}</ref>}} {{History\|pocket alpha}} {{History\|\|v0.8.0\|snap=build 1\|[[File:Carrot JE2 BE1.png\|32px]] Added carrots. \|[[File:Carrots Age 0-1 JE6 BE1.png\|32px]] [[File:Carrots Age 2-3 JE6 BE1.png\|32px]] [[File:Carrots Age 4-6 JE6 BE1.png\|32px]] [[File:Carrots Age 7 JE6 BE1.png\|32px]]{{verify\|Correct models?}} Added carrot crops. \|Carrots can be obtained by killing [[zombie]]s.}} {{History\|\|\|snap=build 3\|Carrots now have a chance to [[drops\|drop]] when tilling [[grass block]]s.}} {{History\|\|\|snap=build 4\|Carrots are no longer dropped by tilling [[grass block]]s.}} {{History\|\|v0.9.0\|snap=build 1\|Carrot crops now naturally spawn in [[village]]s. \|Carrot now used to breed [[pig]]s.}} {{History\|\|v0.12.1\|snap=build 1\|Carrots now restore [[hunger]] instead of [[health]]. \|Brown robed [[villager]]s can now harvest fully grown carrot crops. \|Carrots can now be used to craft [[golden carrot]]s.}} {{History\|\|v0.13.0\|snap=build 1\|Carrots can now be used to breed [[rabbit]]s. \|Carrots can now be used to craft [[rabbit stew]].}} {{History\|\|v0.15.0\|snap=build 1\|Carrots are now used to craft [[carrot on a stick]].}} {{History\|\|v0.16.2\|Carrots can now be found in a [[chest]] inside the large house in [[snowy tundra]] and [[snowy taiga]] [[village]]s.}} {{History\|pocket}} {{History\|\|1.0.4\|snap=alpha 1.0.4.0\|Farmer [[villager]]s now [[trading\|buy]] 15–19 carrots for 1 [[emerald]]. \|Carrots can now be picked up by villagers and become willing.}} {{History\|bedrock}} {{History\|\|1.2.0\|snap=beta 1.2.0.2\|Carrots can now be found inside of [[bonus chest]]s.}} {{History\|\|1.4.0\|snap=beta 1.2.14.2\|Carrots can now be found inside [[shipwreck]] chests.}} {{History\|\|1.10.0\|snap=beta 1.10.0.3\|Carrots can be found in the new [[pillager outpost]]s. \|[[File:Carrot JE3 BE2.png\|32px]] The texture of carrots has now been changed. \|[[File:Carrots Age 0-1 JE7.png\|32px]] [[File:Carrots Age 2-3 JE7.png\|32px]] [[File:Carrots Age 4-6 JE7.png\|32px]] [[File:Carrots Age 7 JE7.png\|32px]]{{verify\|Correct models?}} The textures of carrot crops have now been changed.}} {{History\|\|1.11.0\|snap=beta 1.11.0.1\|Carrots can now be used to fill up [[composter]]s.}} {{History\|\|\|snap=beta 1.11.0.4\|[[Trading]] has now been changed, farmer [[villager]]s now have a 25% chance to [[trading\|buy]] 22 carrots for an [[emerald]].}} {{History\|\|1.14.0\|snap=beta 1.14.0.1\|[[Bee]]s can now pollinate carrot crops.}} {{History\|\|?\|[[File:Carrots Age 0-1 BE.png\|32px]] [[File:Carrots Age 2-3 BE.png\|32px]] [[File:Carrots Age 4-6 BE.png\|32px]] [[File:Carrots Age 7 BE.png\|32px]] Carrot crop planes use a mapping that results in very unnatural mirroring when viewed from certain angles, such as northwest.<ref>{{bug\|MCPE-146936}}</ref>}} {{History\|console}} {{History\|\|xbox=TU14\|xbone=CU1\|ps=1.04\|wiiu=Patch 1\|switch=1.0.1\|[[File:Carrot JE2 BE1.png\|32px]] Added carrots. \|[[File:Carrots Age 0-1 JE6 BE1.png\|32px]] [[File:Carrots Age 2-3 JE6 BE1.png\|32px]] [[File:Carrots Age 4-6 JE6 BE1.png\|32px]] [[File:Carrots Age 7 JE6 BE1.png\|32px]]{{verify\|Correct models?}} Added carrot crops.}} {{History\|\|xbox=none\|xbone=none\|ps=1.90\|wiiu=none\|switch=none\|[[File:Carrot JE3 BE2.png\|32px]] The texture of carrots has now been changed. \|[[File:Carrots Age 0-1 JE7.png\|32px]] [[File:Carrots Age 2-3 JE7.png\|32px]] [[File:Carrots Age 4-6 JE7.png\|32px]] [[File:Carrots Age 7 JE7.png\|32px]]{{verify\|Correct models?}} The textures of carrot crops have now been changed.}} {{History\|\|xbox=none\|xbone=none\|ps=1.91\|wiiu=none\|switch=none\|Carrots can now be used to fill up [[composter]]s.}} {{History\|New 3DS}} {{History\|\|0.1.0\|[[File:Carrot JE2 BE1.png\|32px]] Added carrots. \|[[File:Carrots Age 0-1 JE6 BE1.png\|32px]] [[File:Carrots Age 2-3 JE6 BE1.png\|32px]] [[File:Carrots Age 4-6 JE6 BE1.png\|32px]] [[File:Carrots Age 7 JE6 BE1.png\|32px]]{{verify\|Correct models?}} Added carrot crops.}} {{History\|foot}} === Carrots "item" === {{:Technical blocks/Carrots}} == Issues == {{issue list}} == Gallery == <gallery> AllSeeds.png\|All the seeds that exist in the game (except [[nether wart]] and [[cocoa beans]]). VillageGrowingCarrotsAndPotatoes.png\|Carrots and [[potato]]es found growing naturally in a [[village]]. Carrots Growing.png\|Carrots in multiple stages of growth. Carrot Dungeon.jpg\|A carrot that dropped from a zombie, just to the right of the [[spawner]]. Carrot SDGP.png\|Carrot in the [[Super Duper Graphics Pack]]. </gallery> == References == {{reflist}} {{Items}} {{blocks\|vegetation}} [[Category:Plants]] [[Category:Food]] [[Category:Renewable resources]] [[Category:Non-solid blocks]] [[Category:Generated structure blocks]] [[cs:Mrkev]] [[de:Karotte]] [[es:Zanahoria]] [[fr:Carotte]] [[hu:Sárgarépa]] [[ja:ニンジン]] [[ko:당근]] [[lzh:胡蘿蔔]] [[nl:Wortel]] [[pl:Marchewka]] [[pt:Cenoura]] [[ru:Морковь]] [[th:แคร์รอต]] [[uk:Морква]] [[zh:胡萝卜]]</li></ul>	Beta 1.2.20.1	Added dolphins.
	Beta 1.2.20.2	Dolphin model has been updated.
	Beta 1.2.20.2	Dolphins now have sounds.
	Beta 1.5.0.0	Now lead players to shipwrecks and underwater ruins.

- Princess Nightmoon (Talk Contributions) 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.

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.-- Madminecrafter12^{Talk to me} 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. –Majr ᐸ Talk
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. –Majr ᐸ Talk
Contribs 06:07, 18 May 2018 (UTC)

Deletion requests for mod pages

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}}.-- Madminecrafter12^{Talk to me} 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?-- Madminecrafter12^{Talk to me} 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? –Majr ᐸ Talk
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. –Majr ᐸ Talk
Contribs 09:58, 5 May 2018 (UTC)

English wiki deletes mod articles.
English wiki removes mod support from templates/modules.
A non-English wiki (Wiki X) decided to keep their mod articles and use the original template/module versions.
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). –Majr ᐸ Talk
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. –Majr ᐸ Talk
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

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.-- Madminecrafter12^{Talk to me} 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

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. –Majr ᐸ Talk
Contribs 07:28, 6 May 2018 (UTC)

Hostile Mobs not spawning in singleplayer survival.

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 (talk • contribs) 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

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. –Majr ᐸ Talk
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. –Majr ᐸ Talk
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. –Majr ᐸ Talk
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. –Majr ᐸ Talk
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. –Majr ᐸ Talk
Contribs 07:47, 21 May 2018 (UTC)

Reference template with archive support

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

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!" (Archive).	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 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

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

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.-- Madminecrafter12^{Talk to me} 00:13, 11 May 2018 (UTC)

A bug in the Bug template

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

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. –Majr ᐸ Talk
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. –Majr ᐸ Talk
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

File:Ground impact1.ogg

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

Education Edition Infdev and other backlog oddities

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?

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 Blobs 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 Blobs 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?

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

This is our situation:

We have a Discord server intended for wiki users and just interested community members.
It's not prominently linked anywhere (such as on the community portal).
There has been no discussion behind its creation.
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:

Does the wiki need a Discord server?
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?-- Madminecrafter12^{Talk to me} 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

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 [ ] 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

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 [

] 07:31, 24 May 2018 (UTC)

Simplified version guides

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.-- Madminecrafter12^{Talk to me} 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.-- Madminecrafter12^{Talk to me} 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 [

] 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.-- Madminecrafter12^{Talk to me} 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 [

] 12:20, 31 May 2018 (UTC)

Madminecrafter12 for admin?

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-- Madminecrafter12^{Talk to me} 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 [

] 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.-- Madminecrafter12^{Talk to me} 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 [

] 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.-- Madminecrafter12^{Talk to me} 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

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.-- Madminecrafter12^{Talk to me} 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 [

] 20:38, 25 May 2018 (UTC)

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

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

Support – Nixinova

22:51, 25 May 2018 (UTC)

New mainterace templates?

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.-- Madminecrafter12^{Talk to me} 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.-- Madminecrafter12^{Talk to me} 12:18, 25 May 2018 (UTC)

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

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 Blobs 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.-- Madminecrafter12^{Talk to me} 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.-- Madminecrafter12^{Talk to me} 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 Blobs 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.-- Madminecrafter12^{Talk to me} 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. :(-- Madminecrafter12^{Talk to me} 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.-- Madminecrafter12^{Talk to me} 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 [

] 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

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.-- Madminecrafter12^{Talk to me} 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!-- Madminecrafter12^{Talk to me} 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-?-- Madminecrafter12^{Talk to me} 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. –Majr ᐸ Talk
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

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.-- Madminecrafter12^{Talk to me} 20:10, 25 May 2018 (UTC)

I would suggest: {{only|bedrock|java}}{{upcoming|ver=1.13}} which is ‌^{[Bedrock and Java editions only]}‌^{[upcoming: Lua error in Module:Version_link at line 112: attempt to concatenate local 'text' (a nil value).]}

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. :)-- Madminecrafter12^{Talk to me} 21:22, 25 May 2018 (UTC)

Proposal: Classification of edits in others' user pages

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.-- Madminecrafter12^{Talk to me} 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:

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.
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.
articles that would not belong in the mainspace — similar to #1, but not exactly the same, I'm not sure this should be changed.
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?
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.
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.
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:

Fixed
Fixed
In this case articles makes most sense. Its for things like User:KnightMiner/1.7.banana
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.
Fixed
Fixed
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

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:

Don't have any images at all for maintenance templates. Remove the existing ones, and don't add images to any of the others.
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.
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.-- Madminecrafter12^{Talk to me} 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.-- Madminecrafter12^{Talk to me} 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 [

] 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 [

] 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.-- Madminecrafter12^{Talk to me} 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

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

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. =)-- Madminecrafter12^{Talk to me} 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?-- Madminecrafter12^{Talk to me} 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 [

] 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.-- Madminecrafter12^{Talk to me} 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 [

] 15:04, 7 June 2018 (UTC)

To change a large amount of pages at a time, we can use bots, but I am not sure if bots are allowed here... Lê Duy Quang (Make some words | Contributions)

New idea

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.-- Madminecrafter12^{Talk to me} 22:49, 16 June 2018 (UTC)

Anybody want to comment on this matter? You can see some demonstrations of this in my sandbox. Improvement suggestions are welcome.-- Madminecrafter12^{Talk to me} 13:04, 27 June 2018 (UTC)

Message boxes are horrible IMO. They're centered on the screen (which means small boxes leave a lot of space on wide screens), and text inside them is also centered (which looks terrible on small screens, and on wide screens when the last word (or two) is the only one on its line. They also have quite a lot of margin and padding, which makes them take even more space. Why not just use plain text? --AttemptToCallNil (report bug, view backtrace) 13:20, 27 June 2018 (UTC)

Do you think what I have in my sandbox now is better?-- Madminecrafter12^{Talk to me} 13:46, 27 June 2018 (UTC)

Better, though I would consider splitting the "if you think the page doesn't need to be protected anymore" part into its separate bullet point. Also: 1) "Directors are any user..." has inconsistent singular/plural; 2) the talk page is linked twice, this may be unnecessary. --AttemptToCallNil (report bug, view backtrace) 14:01, 27 June 2018 (UTC)

I still prefer the "Another idea"'s locks to these huge message boxes. And we could make some sort of expanding the details when the lock is clicked. Lê Duy Quang (Make some words | Contributions) 14:07, 27 June 2018 (UTC)

@AttemptToCallNil: Better now? Also, Leduyquang753, this wouldn't be huge message boxes anymore, just normal text - additionally, in case you didn't know, this would not actually show up when viewing the page normally; it would only show up in replace of the "This page has been protected to prevent editing or other actions" when editing an article that you don't have permission to edit.-- Madminecrafter12^{Talk to me} 14:15, 27 June 2018 (UTC)

@Madminecrafter12: But still, we need a kind of indicator to add to the View mode that the page is locked. –Preceding unsigned comment was added by Leduyquang753 (talk • contribs) at 14:19, 27 June 2018 (UTC). Please sign your posts with ~~~~

@Madminecrafter12: Better, but it seems you are using the protection variable in your examples, and the variable is not defined. If that's the same as the reason variable, I have no further objections. --AttemptToCallNil (report bug, view backtrace) 14:21, 27 June 2018 (UTC)

When I changed the name of that defined variable, I forgot to update all of the cases in the template using it. :( Fixed that now.-- Madminecrafter12^{Talk to me} 14:24, 27 June 2018 (UTC)

Jack McKalling - sorry for the ping, but because you didn't seem to think it would be a good idea to use locks to signal page protection until we can figure out a way to automate it, I would be curious to see what you think about this idea.-- Madminecrafter12^{Talk to me} 18:58, 28 June 2018 (UTC)

I may make a script to automate this. Just need some learning about Lua and MediaWiki... Lê Duy Quang (Make some words | Contributions) 14:17, 29 June 2018 (UTC)

I definitively think what MadMinecrafter12 made on his sandbox page is a big step in the right direction. Locks on the main page are not really necessary, particularly if it's not possible to make it automatic. However, indicating to users why they cannot edit their pages is absolutely necessary, and giving them instructions to discuss about changes. It may sounds simple, but it's not something obvious for someone new. Perhaps you could reduce a bit the text length and link to the admin list for the third case — but otherwise, I really like his suggestion. JSBM (talk) 14:32, 29 June 2018 (UTC)

JSBM - I've added the text "or contact an administrator directly" linking to the list of administrators. Also, do you have any specific suggestions of how to reduce the text length?-- Madminecrafter12^{Talk to me} 13:32, 30 June 2018 (UTC)

Ok, so, this is my take on the three messages:

This page is protected so that only registered users can edit it. To edit this page, you'll need to create an account. You can also request change on the article's talk page. You can discuss about the protection on the article's talk page or the admin noticeboard. (See the page's protection log for more details about the protection.)
This page is protected so that only directors can edit it. You can request change on the article's talk page. You can discuss about the protection on the article's talk page or the admin noticeboard. (See the page's protection log for more details about the protection.)
This page is protected so that only administrators can edit it. You can request change on the article's talk page. You can discuss about the protection on the article's talk page or the admin noticeboard. (See the page's protection log for more details about the protection.)

Yes, I'm too lazy to actually make links. Also, I feel some of the working (« You can request change ») isn't really working in English, so feel free to adapt as you want. But I feel a shorter version would do a better job at providing the information. JSBM (talk) 16:57, 30 June 2018 (UTC)

Just an overview of all the changes you made and what I think of them: I like having a bulleted list - it looks cleaner, so I'm opposed to changing that. I support making the intro text bigger, like you did. I also like how you were able to condense the "creating an account" and "requesting an edit" into 1 line, so I support that part as well. I am opposed to putting the protection log information just as small text in parentheses at the end - although perhaps we should move that down a bit from where it currently is, as I do think knowing how the page can be edited is more important than the reason for the protection. I'm neutral about removing the directors definition - it's certainly nice and convenient to have there, but it is a bit out of place and it does link to the MCW:Directors page right there, which contains an explanation.-- Madminecrafter12^{Talk to me} 17:07, 30 June 2018 (UTC)

I've done this for the protected page text interface page on the RollerCoaster Tycoon World Wiki, another wiki I'm an administrator on. It works great, and actually looks fairly decent. You can see it in action here.-- Madminecrafter12^{Talk to me} 13:44, 30 June 2018 (UTC)

It would have looked even better if the list bullets weren't barely distinguishable from the background. --AttemptToCallNil (report bug, view backtrace) 14:12, 30 June 2018 (UTC)

That's just exclusive to that wiki - wouldn't be a problem here. Yeah, there are a lot of CSS skin problems on that wiki.-- Madminecrafter12^{Talk to me} 14:16, 30 June 2018 (UTC)

This looks good! I already implemented it on the German wiki. The old text really was not informative at all. | violine1101^(Talk) 15:41, 30 June 2018 (UTC)

So, this discussion has been up for 2 weeks. It seems that the clear consensus is to definitely give more of a description on the MediaWiki:Protectedpagetext page. This proposal has not gotten any strong objections and seems to have mostly support, and nobody seemed to think that what I had in my sandbox was problematic, after I had modified it to comply with what people thought about it. Also, remember that these actions are easily reversible - if a mob of users suddenly come and for some reason say that we should just have that one old non-descriptive sentence, I or another admin can just modify that page. Likewise, if a lot of people think a change needs to be made to this, which is something I'm definitely expecting, we can easily do that as well.

So, please comment if you think this needs to be changed, tweaked, removed, etc., but for now I've Done what I had in my sandbox.-- Madminecrafter12^{Talk to me} 16:05, 30 June 2018 (UTC)

I think the padlocks we use as indicators at the top of protected pages, could be added to that page with the padlock and the text why the page is protected, and I could think the text could be:

Semi protected:

This page is protected so that only registered users can edit it.
To edit this page, you'll need to create an account or sign in. You can also request a change on the article's talk page.
You can discuss about the protection on the article's talk page or the admin noticeboard.
(See the page's protection log for more details about the protection.)

Full protected:

This page is protected so that only administrators can edit it.
You can request change on the article's talk page.
You can discuss about the protection on the article's talk page or the admin noticeboard.
(See the page's protection log for more details about the protection.)

Directors only protected:

This page is protected so that only directors can edit it.
You can request change on the article's talk page.
You can discuss about the protection on the article's talk page or the admin noticeboard.
(See the page's protection log for more details about the protection.)

- psl85 (☎ Talk | ✏️ Contribs) 06:33, 2 July 2018 (UTC)

@Madminecrafter12:, I definitely like the system message solution. It is automatic and doesn't need any additional admin action during protecting. I really like the more condensed version of JSBM as well. It is too much to read if there are 4 bullets below the main line, 2 lines would be ideal. That line about the protection log can be further simplified as a single link like this:

	This page is protected so that only registered users can edit it [protection log] To edit this page, you'll need to create an account. You can also request change on the article's talk page. You can discuss about the protection on the article's talk page or the admin noticeboard.

I believe this is enough for all three cases, only differing in the usergroup in the bold text, with a link for the directors. No need to explain what directors are, this message/page is not responsible or related to the definition of each usergroup. The link should be fine. I combined JSBM's table here with your bullets, because I really like the offset background so that it pops up and it definitely deserves that. It doesn't need to be centered but I think this way it shows the importance of the message, as opposed by regular text. I also added Psl85's padlocks, it provides a fast message at glance to reduce the need to read even more. But I'm not sure about the table border between. I don't want this to turn into a centered message box though, I agree this one needs to be left aligned along with the text there. – Jack McKalling [

] 08:01, 2 July 2018 (UTC)

In my last few edits to the page, I went ahead and condensed the information into two bullet points. I also removed the protection log bullet point and added the link to the log in the first line instead. Finally, I made the "This page has been protected so that only [X] can edit it" text bigger. I'm not too sure about implementing it into a table. And as for the locks, I do think that would be a good idea. I like what Psl85 did, I just think they should probably be a little bit smaller. If we do end up using a table, I'm against putting the lock in a separate cell from the text - I just think it would look much better if the lock and the text are together.-- Madminecrafter12^{Talk to me} 13:11, 2 July 2018 (UTC)

Here's kind of what I'm thinking for incorporating the locks:

This page is protected so that only registered users can edit it.(see the protection log)

To edit this page, you'll need to create an account. You can also request a change on the article's talk page.
You can discuss the protection on the article's talk page or the admin noticeboard.

-- Madminecrafter12^{Talk to me} 13:22, 2 July 2018 (UTC)

Good message, but the text "to edit this page, you'll need to create an account." could be changed to "to edit this page, you'll need to create an account or sign in" to add a link to allow signing in from that link instead of only a link for creating an account, and I would also be able to edit those Mediawiki: messages instead of only admins and wiki guardians, this wiki and other Gamepedia wikis could add a interface editor user group and users in that group could be able to edit the Mediawiki: messages, and could be given through requesting the right, is this possible??? psl85 (☎ Talk | ✏️ Contribs) 17:43, 2 July 2018 (UTC)

Another idea

I have also a new idea - the padlocks could be replaced with blocks in Minecraft - iron block on semi-protected page, gold block on fully protected page, coal block on directors protected page, emerald block on move protected page, and lapis lazuli block on upload protected file, and those soes not needed to be uploaded, and only be used on the top right corner on protected page, and the Mediawiki:protectedtext could be a message box, with padlock/the blocks mentioned before image, and information about the protection, reason, and then add a link to suggest the reader to create an account/submit a edit request using a new template {{edit request}}, and a link to the admin noticeboard to remove the protection if the protection is not needed anymore, I planned to experiment with the edit request template and the new protection messages in my sandbox - psl85 (☎ Talk | ✏️ Contribs) 06:06, 27 June 2018 (UTC)

The Minecraft-themed protection locks would certainly be an interesting idea. It's still not addressing the problem about adding the locks automatically, which is something that many people seem to think is necessary (although I personally don't think it is). I've tried to see if MediaWiki:Protectedpagetext can detect protection levels on another wiki, and it definitely works! I'm not really that supportive of creating the edit request template, though - there's not really much need for it on such a small wiki, and we don't need to have all of the complex systems that Wikipedia has.-- Madminecrafter12^{Talk to me} 12:50, 27 June 2018 (UTC)

Maintenance issue. We in general should not use images of game content as part of wiki design for the following reason:

If the depicted object's appearance is changed, the image has to be reuploaded. Allowing regular users upload system images is a risk due to potential severe harm from vandalism. Disallowing this would require administrators to upload the image, rendering them not uploadable by regular community members for essentially no good reason. Keeping duplicates used solely in the interface will make the engine unhappy (it will list the files as duplicates), or cause discrepancy between these two files, which would have to either be kept (for no reason) or fixed by having administrators upload the protected copy (creating a duplicate with restricted maintenance). Images which can never be updated, such as locks, solve all the aforementioned issues.

--AttemptToCallNil (report bug, view backtrace) 12:57, 27 June 2018 (UTC)

Definitely a good point. We don't want anybody who's logged in to be able to overwrite an important skin image, nor do we restrict the ability to reupload several images that would appear on Minecraft-related articles (that may need to be updated to comply with new versions), to administrators. Therefore, I have to withdraw my support to use Minecraft icons to signal page protection.-- Madminecrafter12^{Talk to me} 13:01, 27 June 2018 (UTC)

I can try drawing 16x16 padlock icons to make them look like Minecraft... Lê Duy Quang (Make some words | Contributions) 14:27, 27 June 2018 (UTC)

For more appealing results you could just extract the padlock from this file and recolorize the body. Just a suggestion. – ItsPlantseed ⟨₰|₢⟩ 15:32, 27 June 2018 (UTC)

Madminecrafter12: See my sandbox now, I created some differently-coloured message boxes with the blocks I mentioned above, and some links on the message boxes to suggest the reader to create account/log in, request edit or unprotection, and I will now try to start working on the edit request template I mentioned above on the sandbox - psl85 (☎ Talk | ✏️ Contribs) 15:51, 27 June 2018 (UTC)

As you can see above, Nil pointed out that the message boxes are a bit disruptive and messy, and it would be better to use plain text. As shown in my sandbox, I've used plain text instead - as I agree with this. Also, note that GRASP aren't able to edit fully-protected pages - only admins and wiki guardians can. And I personally don't think an edit request template would be necessary, as I've said above. I do like where you're going with this, though. :)-- Madminecrafter12^{Talk to me} 15:58, 27 June 2018 (UTC)

Madminecrafter12 I will use plain text, but I created some differently coloured message boxes, and I think those not was too messy an ugly, I can add the protection block and plain text- psl85 (☎ Talk | ✏️ Contribs) 16:04, 27 June 2018 (UTC)

@psl85: I have made the locks, which you can preview here:

File:All locks.PNG

Lê Duy Quang (Make some words | Contributions) 16:14, 27 June 2018 (UTC)

Leduyquang753 Cool locks, and I would use those, the only need is only have one file/padlock - psl85 (☎ Talk | ✏️ Contribs) 16:22, 27 June 2018 (UTC)

I fail to understand the insistence on styling everything like Minecraft. The current locks are already perfectly functional, the choice is purely stylistic (following an unstated and pointless guideline), so creating new images where other already exist and are capable of doing their job is a wasted effort. --AttemptToCallNil (report bug, view backtrace) 16:55, 27 June 2018 (UTC)

psl85. Here are 10 icons in the preview colored according to Wikipedia's protection locks with description of what they do. You can try using them in your sandbox messages. And AttemptToCallNil, if this wiki doesn't need anything to look like Minecraft at all, why does the Hydra skin exist? And the icons near the links in the mainpage. They all have the same purpose to make this Wiki look more like a Minecraft wiki, don't they? Lê Duy Quang (Make some words | Contributions) 01:22, 28 June 2018 (UTC)

Comment I don't see the point of having that padlock template at all, it's just adding more workload to the admins who have to change the template every time they change the protection. Apart from that, it's rather obvious if a page is protected or not, protected pages have "View source", unprotected pages have "Edit" (and "Edit source" if you've enabled the visual editor).
My point is, we aren't Wikipedia. I don't see the point in creating meta-templates which add nothing to the contents of the page. It will just make everything messier.
Lastly, Leduyquang, I appreciate the work you put into pixeling the padlocks, but in my eyes, they don't fit to Minecraft at all and also look a little clumsy. As I mentioned on Discord before, it would make more sense and look better if you just used the padlock texture that's included in Minecraft anyway (given that it's decided that such a template is needed in the first place). | violine1101^(Talk) 09:45, 28 June 2018 (UTC)

"doesn't need anything to look like Minecraft at all" means "shouldn't have elements which look like Minecraft", the opposite of which is "may have elements which look like Minecraft". What you're trying to accomplish is "shouldn't have elements which don't look like Minecraft", which is not a valid opposite.

And yes, why bother adding locks if we can just change the protected edit message? --AttemptToCallNil (report bug, view backtrace) 10:05, 28 June 2018 (UTC)

Adding locks gives a nice, compact indicator to the users about the protection state of a page. Having a massive message box (a small one is still big and distracting in this case) at the top isn't good for focusing on the below content. And the difference between "Edit source" and "View source" only indicates whether the user can edit it or not. Lê Duy Quang (Make some words | Contributions) 14:05, 29 June 2018 (UTC)

And also using the vanilla's lock icon doesn't give a nice result because it needs to be recolored to indicate different protection states. The lock's texture looks like gray stone, so recoloring it makes it ugly. Lê Duy Quang (Make some words | Contributions) 14:08, 29 June 2018 (UTC)

My main point was that admins would have needed to update the template on the page every time. This problem has been solved with AttemptToCallNil's proposal below. Locks are fine with me, but to be honest, I still don't like your pixel arts.
The question now is, which indicators do we need? Should the colors mean something or should they be random? Let's take a look at your proposal from User:Leduyquang753/locks:

Color	Default	My proposal	Meaning	Notes
Gold		File:Minecraft protection lock full.png	Fully protected	Gold makes sense, but your color looks a little dull at the moment.
Green		--	Move protected	Do we really need a seperate lock for move protected pages?
Silver		File:Minecraft protection lock semi.png	Semi protected	Makes sense, but the gray is a little dark.
Pink	--	--	Template protected	What's the difference to normal protection? Besides, this protection level doesn't exist here as far as I know. Also, the pink is too similar to the purple of the Upload Protected lock.
Purple		--	Upload protected	Again, what's the difference to normal protection? Why do we need a seperate lock for this? Do there actually exist pages which are upload protected. Also, the purple is too similar to the pink of the Template Protected lock.
Light blue	--	--	Cascade protected	Every page which is cascade protected is also normally protected. Why do we need an extra lock for this? Also, the light blue is too similar to the cyan of the Create Protected Lock.
Cyan	--	--	Create protected	Again. Why an extra lock? Also, the cyan is too similar to the light blue of the Cascade Protected Lock.
Blue	--	--	Extended confirmed protected	What is this? I don't think this protection level exists here.
White	--	--	Pending changes protected	No such protection level exists on the Minecraft wiki.
Black		File:Minecraft protection lock full.png	Office protected (directors and above)	I would use the same icon as for full protection; there's just a small amount of users to whom it matters whether a page is fully protected or protected on directors level.

| violine1101^(Talk) 14:57, 29 June 2018 (UTC)

Support your icons. They are exactly what we need, they are clear and stay Minecraft enough. (We just need them a bit bigger) (And yup, only 2 of them is enough, the other categories are really optional, they don't need a specific lock) JSBM (talk) 15:20, 29 June 2018 (UTC)

Cascade protection used to be used with the main page onto various templates, but in most cases its a bit difficult to tell why a page is protected if its just marked with regular protection (difference between "we think this page is a target" and "we think this page may be used to target another page") so it might be worth a separate lock to mark. Hard part is its slow to fetch anyways compared to regular protection data.

Otherwise, I prefer the locks that are actual sprites over the pixelated ones. Between the antialiasing and the black borders they don't really match Minecraft's style in my opinion. –KnightMiner · (t) 18:46, 29 June 2018 (UTC)

Yet another idea

JavaScript could be used to place locks on protected pages automatically. It saves the need for administrators to add a template every time a page is protected and remove the template when it expires or if it is removed. It could be implemented as a gadget.

This script I wrote (it's not exactly pretty, but I found no predefined functions to set indicators) uses the Wikipedia-style icons. As I have said before, these icons are perfectly functional, there's no point to create new ones as if just to conform with a nonexistent rule demanding we make every interface image Minecraft-styled. --AttemptToCallNil (report bug, view backtrace) 14:12, 29 June 2018 (UTC)

We should make a debate... Lê Duy Quang (Make some words | Contributions) 14:30, 29 June 2018 (UTC)

Support This works really well, nice script! | violine1101^(Talk) 14:57, 29 June 2018 (UTC)

Nice script. That's a kind of script what I meant above. Whould this script fit in Mediawiki:Common.js? This would work very well for the main view of a page, and the system message from the New idea above would work for the edit view. – Jack McKalling [

] 08:48, 2 July 2018 (UTC)

"Twinkle" gadget on this wiki

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)

Support. These could be great things to keep the Wiki fresh and clean. Lê Duy Quang (Make some words | Contributions) 01:21, 24 June 2018 (UTC)

Support twinkle and navigation popups. No opinion on wikEd as I generally don't use any type of visual editor, although I will note that the correct link is User:Cacycle/wikEd, not User:Azatoth. Also, I'll note that I tried to use twinkle via user JS and that didn't work, though that was a while ago; the module would be very nice (but it definitely would need editing for the list of templates). --Pokechu22 (talk) 01:41, 24 June 2018 (UTC)

What if Minecraft appears in another game?

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 [ ] 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.

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.-- Madminecrafter12^{Talk to me} 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 [

] 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.-- Madminecrafter12^{Talk to me} 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)

I think if we stick to just moving the images, it's fine (which is atthis moment basically already done (only Tall Grass -> Grass and Double Tallgrass -> Tall Grass left); the actual pages themselves shouldn't be moved yet until 1.13 release though. Without a doubt the bedrock (and possibly legacy console) editions will start following the new names soon. FVbico (talk) 18:40, 25 June 2018 (UTC)

Zombie hurt.ogg

The file doesn't work on the Zombie page. –Preceding unsigned comment was added by Enderdespawnmite (talk • contribs) 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

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.-- Madminecrafter12^{Talk to me} 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 [

] 09:46, 18 June 2018 (UTC)

Then we could just export {{ModSprite}} there.-TheCreeperStrikes (talk) 14:33, 18 June 2018 (UTC)

Project announcement

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)

Elements and existing pages with the same name

Here's a couple of pages that I think should be moved to free up space for element redirects

Gold to Gold (disambiguation)
Iron to Iron (disambiguation)

I don't think there are any other pages like this, but I'd like some input before I (or someone else) move these. Kienan (talk • contribs) 19:20, 20 June 2018 (UTC)

No support for redirecting the pages to the element. I suspect that the majority of users entering Gold or Iron as a URL would not want to see the element, but instead a disambiguation. Maybe support moving the articles and having Gold redirect to Gold (disambiguation), and including the element on there. But maybe it's just better to leave it as-is. Wikipedia seems to just not use the (disambiguation) suffix in that case (in fact, they redirect the disambiguation page back); for instance Mercury and Mercury (disambiguation). In fact, that gives a fairly good case for it, in that mercury itself is an element. --Pokechu22 (talk) 19:32, 20 June 2018 (UTC)

Oppose moving. The primary meaning for non-Education Edition-oriented readers (which I expect to be the majority of the wiki's audience) would most likely be the resource in general, not the element. Redirecting Name to Name (disambiguation) would be completely pointless, same with the reverse redirect; or, to be more accurate, these redirects are only useful if some program code we can't modify handles "(disambiguation)" titles in a desirable special manner, and I am not aware of any such distinction. --AttemptToCallNil (report bug, view backtrace) 19:51, 20 June 2018 (UTC)

Weak oppose. If we were to be perfectly consistent and always use the in-game names, the pages should be moved, which is why my oppose is weak. However, I really think readers searching for gold are much, much more likely to want to go to gold ingot or gold ore than the element page. In my opinion, this is more important than being perfectly consistent and always using the in-game names.-- Madminecrafter12^{Talk to me} 01:52, 21 June 2018 (UTC)

Oppose moving; while it has to be acknowledged that they are in-game names, they're not something from the core gameplay. The existing pages for gold and iron have to take precedence in ambiguous situations like this because they are based in the core gameplay. – Sealbudsman talk | contribs 02:46, 21 June 2018 (UTC)

Oppose move. The disambiguation suffix should only be used for pages like this when there are other articles with the same name, but as said above, the term "gold" and "iron" are only a partial use for in-game names. Those elements from Education Edition are basicaslly edition exclusive and that's not enough reason to override that partially used in-game name. Having a link to Gold (element) and Iron (element) on the Gold and Iron pages respectively is the best way here, IMO. – Jack McKalling [

] 08:54, 21 June 2018 (UTC)

Oppose. We should instead keep the page Gold (element) for the element, like Clay (block), and leave the Gold page alone. Lê Duy Quang (Make some words | Contributions) 01:16, 24 June 2018 (UTC)

Item stack general format

So, when a high amount of item is expressed in the Wiki, it would be "x stack(s) and y item(s) (n total items)", which is a bit complicated. So I am thinking of a template that we could write it as for example "2s35" with the hover comment "2 stacks and 35 items (163 total)". Improvements can be made as long as they make sense, then this would make the Wiki more compact. Lê Duy Quang (Make some words | Contributions) 02:36, 24 June 2018 (UTC)

Question about sparklers

According to the text:"When lit, the sparkler will emit colored particles; the durability meter depletes while the sparkler is burning.",is that means sparklers have it's item durability? (In zh,it displays "?")--Wth213 (talk) 08:24, 28 June 2018 (UTC)

Absolutely, it only burns when you hold it in your hand though. – ItsPlantseed ⟨₰|₢⟩ 10:30, 28 June 2018 (UTC)

Well,how should we express it?If not,please tell me reasons.--Wth213 (talk) 02:56, 29 June 2018 (UTC)

Weird spacing and bullet formatting on templates

I'm not entirely sure where to post this so I guess I'll post this here: On navboxes, the formatting seems to be a bit bugged with creating additional bullet points - while it does make it in parentheses, at the end it has a weird space before the ")" and it creates a space between that and the next item. You can see this better on the Bedrock Edition versions template. It just seems off so if this can be fixed that would be great. --Marioprotvi (talk) 20:16, 28 June 2018 (UTC)

It's been the case since tidy was broken, and tidy is a requirement for hlists to work properly, so nothing we can do about it. –Majr ᐸ Talk
Contribs 07:52, 30 June 2018 (UTC)

Replace edition abbreviation links with templates

Replacing edition abbreviations links like BE with templates like {{BE}} would be useful as we can have the template link to the full page name, so the title says the full name rather than just the abbreviation to make it clearer to readers what it means. It also provides the opportunity to add some styling to the links (like a background colour or icon). –Majr ᐸ Talk
Contribs 08:01, 30 June 2018 (UTC)

File naming consensus

There doesn't seem to be any file naming consensus except for things from mods (suffixing with "(<mod name>)").
There's files in all different naming conventions:
runninglowercase
lowercase with spaces
Capitalrunning
Capital On Every Word
Capital on first word
etc.
Even file extensions have the FULLCAPS and nocaps variants used interchangably.
Alongside this inconsistent naming, there is no telling if the file is a user file by name (or from who it is in general).

I propose the following naming convention:
File:<user name in case it's a user file> Capital On Every Word (<mod name>).lowercase extension
Examples:

File:FVbico Some Funny Meme.gif
File:Computer (ComputerCraft).png
File:Skeleton Riding Spider.png

Of course, changing all existing files will take a long time, so when a naming convention is chosen, I (potentially others too) will go through all files and move to the proper naming. FVbico (talk) 12:51, 1 July 2018 (UTC)

I Support it, though I might take it a step further; for user files, call it like: File:User FVbico Some Funny Meme.gif. Just so that it's more obvious in case someone's username is something ambiguous like Indev. –Preceding unsigned comment was added by Sealbudsman (talk • contribs) at 17:13, 1 July 2018‎ (UTC). Please sign your posts with ~~~~

Actually that’s a good point, didn’t think of that. FVbico (talk) 18:32, 1 July 2018 (UTC)

Neutral. I would be open to having a message when uploading a file, telling the uploader to give the file a detailed name that describes the image clearly, AND use whitespace where you normally would. We could also add that little bit to MCW:IMAGES. However, I don't think the userspace and capitalization restrictions would be necessary, so I'm against making that part a formal guideline.-- Madminecrafter12^{Talk to me} 13:43, 3 July 2018 (UTC)

Drowned and Zombie

The information for the Drowned is on the Zombie page, so why not merge the pages? File:Talk.png File:Edits.png 02:34, 3 July 2018 (UTC)

If so, it should also applies to Husk. Hugman_76 [

] 14:27, 3 July 2018 (UTC)

Comment Husk has already been merged into the zombie page.-- Madminecrafter12^{Talk to me} 14:29, 3 July 2018 (UTC)

Oppose. Drowned currently is actually quite a long page as far as content goes, with a lot of detail about spawning, drops, and behavior, much of which is very different than zombies. Merging the two would make the zombie page more cluttered, with little benefit.-- Madminecrafter12^{Talk to me} 14:39, 3 July 2018 (UTC)

Oppose. It's pretty clear that they are different mobs. Also, merging all entities that could fit under the term "zombie" doesn't help much with adding more information to the wiki, but only clutters it up with so much information that it gets confusing. (Hence I also disagree with Husk and Zombie villager being part of the Zombie article. They aren't real zombies either and have their own special properties.)
On an unrelated note, this should be on Talk:Drowned, not here. | violine1101^(Talk) 15:32, 3 July 2018 (UTC)

Note - the same thing is currently being discussed here.-- Madminecrafter12^{Talk to me} 12:46, 4 July 2018 (UTC)

Oppose - why is Husk on the same page as Zombie, anyway? - MinecraftPhotos4U (talk) 17:13, 5 July 2018 (UTC)

Using artworks instead of renders in some info boxes

Some entities got official artworks. I was wondering, why don't we use these in 'Entity Boxes'? I've put an example on the right side to prove you how it could render, but it can works with other mobs with official artworks, like

,

or even

. Hugman_76 [

] 17:51, 3 July 2018 (UTC)

While I can definitely understand the appeal of this, I'm not sure if this will fit well in an unofficial encyclopedic context (especially given these are not honest in-game appearances), and the fact that we don't have artworks for absolutely everything would cause major inconsistencies. I otherwise wouldn't mind this if it weren't for these problems. - MinecraftPhotos4U (talk) 15:40, 3 July 2018 (UTC)

Take the encyclopedic context out of the cage. Does other game wikis will choose a T-Pose of the mob in question? Nope, and we're litterally doing this. Also I don't think they aren't honest in-game appearances, and even so, again, the other wikis does this as well. For the inconsistencies, we could keep the 'T-Pose' renders under the first paragraph or something like that, or even make an image2 in the infobox. Hugman_76 [

] 17:51, 3 July 2018 (UTC)

My opinion: This looks nice, and arguably better than the renders from the game we have now. However, the wiki is supposed to document the game as it is. Ironically, Minecraft's artworks have a different artstyle than the actual game, it uses even more simplified textures for everything. Therefore, I don't think that it would be a good idea to change the images in the info boxes so that they are different from the game.
Also, there's the question of where to get the artworks from – we can make the renders by ourselves, for the artworks we would need to wait for Mojang or Microsoft to come along and create one. | violine1101^(Talk) 18:05, 3 July 2018 (UTC)

We could display these artworks somewhere else, like in the second image of the info box template to not remove the render. Or even add it under the first paragraph of the article. Hugman_76 [

] 18:48, 3 July 2018 (UTC)

I have to agree with Violine1101 here. I definitely see where you're going with this, and I like how they look - however, I really think it's better to use the exact in-game textures for infoboxes, as they are right now. Also, I don't really see much benefit for having the artwork as the second image in the infobox. However, I do like the idea of including the artworks in the gallery.-- Madminecrafter12^{Talk to me} 12:50, 4 July 2018 (UTC)

A patroller user group

This was suggested on Discord and seemed to be supported. Pinging JSBM and MarkusRost, as both of these users participated and voiced their opinions in the discussion, so it would be great if they could do the same here.

So as you can see above a proposal was made to create a new user group that can semi-protect pages. However, there were a number of concerns raised about this on Discord that I agree with. First of all, I could easily see this being abused in edit wars even by an experienced user - one user thinks they're right so they just semi-protect the page. Second, many experienced users may semi-protect incorrectly - e.g., because of 2 IPs vandalizing twice in the last month, or one IP vandalizing 5 times. Also, protecting usually isn't the answer to vandalism - it's usually actually blocking. So if we give somebody the access to semi-protect, they may do that when blocking is really the answer - because they don't have permission to block. And if we allow them to protect AND block, then we might as well just go ahead and give them admin. Finally, I'm not sure if it's possible to allow editors to only protect pages for a short amount of time - we would likely have to create a whole new user permission, as currently it's just listed under one: protect. And is it really worth it, especially considering protecting really isn't usually the way to go in cases of vandalism? Many of these concerns I have are shared here.

However, I support creating a new user group called "Patrollers" that gives the following rights:

Mark others' edits as patrolled (patrol)
- What this does: It allows to click the button "Mark as patrolled" in a diff. In recent changes, any unpatrolled edits have a red exclamation mark next to them. This allows admins (and possibly soon patrollers) to see the edit, look over it, and know that it has not yet been reviewed, or the administrator who reviewed it doesn't know if the information is accurate or not. Although this isn't a necessary feature, I definitely think it would be helpful.
- Reason: The patrol backlog is very large right now. Dinoguy and I are pretty much the only ones patrolling, and about half of all edits remain unpatrolled by the end of the day. I could see this being very helpful for users who can't look at every edit in recent changes - they would be able to see which edits have been reviewed or not, so that the unpatrolled can take priority. Patrolling isn't a necessary feature, but I do think it's a good idea and helpful in many circumstances.

Quickly rollback the edits of the last user who edited a particular page (rollback)
- What this does: On the latest diff of a page, there is a "rollback" button. When this is clicked, it will revert all of the last consecutive edits by that user. This will also automatically mark the user's rolled-back edits as patrolled. Additionally, Majr created a wonderful script that allows for a custom rollback summary without having to load any new screens. This is very helpful for reverting bad edits that were likely made in good faith, which would usually warrant an edit summary
- Reason: Rollbacking is much, much quicker. Especially for multiple edits. If a normal user finds a user who made multiple vandal edits, they must navigate to the diff before their edits, reload several screens, click the edit button, wait for that screen to load, put in the edit summary something like "Rvv last 3 edits," click save changes, and wait for that to load. With rollback, all of that's in a single click. Additionally, you can revert multiple good faith edits using rollback much quicker as well, as long as you don't disable to editable rollback summary gadget. Instead of doing the same thing as for vandal edits except adding an extra custom edit summary, just click the pencil button next to the rollback link, quickly edit the summary, press save, and the edits will be reverted right away. Additionally, rollbacking automatically marks edits as patrolled, which is another reason why having a user group that can rollback edits would be helpful.

-- Madminecrafter12^{Talk to me} 13:41, 5 July 2018 (UTC)

Support Frisk (Talk page) 13:46, 5 July 2018 (UTC)

Support david92003 (talk) 13:50, 5 July 2018 (UTC)

Support also --

psl85 (profile | talk | contribs | send email) 14:25, 5 July 2018 (UTC)

Support

MarkusRost (talk) 14:38, 5 July 2018 (UTC)

Support And officially, I want to get all the credit for that idea! JSBM (talk) 17:21, 5 July 2018 (UTC)

Support sounds great. – Sealbudsman talk | contribs 03:47, 6 July 2018 (UTC)

Support. In addition, I see no reason for any user to have patrol and not autopatrol rights. Maybe we could also grant autopatrol rights to the group, or alternatively, make sure every member of the group is also a member of the autopatrolled group? --AttemptToCallNil (report bug, view backtrace) 14:49, 6 July 2018 (UTC)

I do think it would be better to keep them separate, just in case for some odd reason one may think a user could be trusted with patroller but not autopatrol, which would be rare. But yeah, in most cases, users would get both user rights - and there's not much of a problem with that; literately the only difference is a bureaucrat checking off one extra box when changing user rights.-- Madminecrafter12^{Talk to me} 14:36, 8 July 2018 (UTC)

Support. I would really like to participate patrolling in my favourite set of pages. It's what I'm already doing basically anyway, without the actual applied hint. And this has nothing to do with my autopatrol usergroup, nor with achievements. I'd like to see it as guarding pages against all kinds of imperfections and what not that I could find as a voluntary task. Besides, it's a built-in feature already to actually patrol edits anyway, why not use it more if admins can't cover it enough. – Jack McKalling [

] 23:23, 9 July 2018 (UTC)

Support as well. | violine1101^(Talk) 19:32, 12 July 2018 (UTC)

Group created and populated July 12, 2018 — Game widow ^(talk) 19:39, 12 July 2018 (UTC)

What should we patrol?

Since this proposal is heavily based on edits being patrolled, both manually and automatically during reverts, we should come to a consensus about what makes an edit worthy of being patrolled.

On one end of the spectrum, we could patrol everything as long as it isn't blatantly disruptive and/or against the rules. This will result in stealth vandalism being patrollable, not to count various errors.

On the other end, we could patrol only edits which don't require any further fixes, including spelling, grammar, facts... Needless to say, this effectively defeats the purpose of patrolling, making it massively difficult to patrol new edits.

I'm finding it difficult to even draft a proposal. Any suggestions? --AttemptToCallNil (report bug, view backtrace) 15:19, 6 July 2018 (UTC)

I definitely think that more than just blatant vandalism should be checked when patrolling, but I wouldn't necessarily say only edits don't require any further fixes should be patrolled. So I'm probably in between those two points, but closer to the second. Also, note that because I am an active editor of this wiki and have a lot of time to edit it, I often check for a lot more when patrolling than even what I personally think is necessary. I would say mainly check for and fix factual errors, wiki-code formatting errors (e.g., not closing a table causing the whole page to be messed up), and maybe very major prose issues, before patrolling. However, like I said, I have the time to be nitpicky, so I personally like to check for less important grammar errors, spelling errors, etc. as well.-- Madminecrafter12^{Talk to me} 13:21, 10 July 2018 (UTC)

Rule violations, vandalism, invalid html structures (destruction of the webpage), wrong or misleading facts (false information), I think should all be checked. But stuff like rephrasing, spell checks, other maintenance, does not need patrolling. I imagine this from (humorously) analysing the picture that gamepedia gave to the patrolling achievements, namely an officer enforcing order. You basically patrol pages to check them off as being non-rule breaking. And if an edit violates something, to finish patrolling such edit you revert it or make another edit. And when you do, I believe this should not automatically mark all prior edits as patrolled (sometimes you check an edit that isn't necessarily the first unpatrolled one). However a quick rollback is most suitable to an automatic mark as patrolled for the related edits. – Jack McKalling [

] 14:20, 10 July 2018 (UTC)

Also, I'm assuming the patrol mechanism requires the patroller to eventually mark all edits whatsoever as patrolled, disregarding whether they originally had rule-breaking content. In the case they had, you'd of course fix it by reverting or another edit, before you manually mark the edit as patrolled. – Jack McKalling [

] 14:25, 10 July 2018 (UTC)

No edits are required to be patrolled. In fact, looking at the patrol log, the wiki didn't use the patrol feature hardly at all before December 2017, besides administrators having their edits automatically marked as patrolled. And even now, about half of the edits on the wiki remain unpatrolled, due to the huge backlog of edits and the very small number of administrators who actually patrol edits on a normal basis. However, it is definitely helpful to see what edits have been reviewed and which have not, specifically for people who may not have time to take a look at every single edit out there. Also, rollbacking edits automatically marks the rolled-back edits as patrolled (but undoing doesn't).-- Madminecrafter12^{Talk to me} 14:39, 10 July 2018 (UTC)

One thing I will say, is that I do really think that major grammatical errors need to be fixed before marked as patrolled. For example, if somebody adds "Ghast fireball shoot players," I really think that marking it as patrolled as it is, and telling all other editors that it's been reviewed, doesn't seem quite right. A minor grammatical error, such as "Ghasts will shoot fireballs at player," is fine being marked as patrolled. Imo, a patrolled edit doesn't mean it's worded perfectly, but it should mean that the edit has been reviewed and any major problems have been fixed.-- Madminecrafter12^{Talk to me} 15:46, 11 July 2018 (UTC)

I agree a certain level of grammatical fixes may need to be applied before the mark. But there is a serious issue in determining what classifies as such. So I would say to solve this no grammatics need be fixed before marking as patrolled, unless the grammatical error(s) cannot get the intention across of the content. If you can still determine the meaning and people can add more words to make it complete, it may be patrolled. But if the edit would break the information due to ambiguity, potential misinterpretation or false information, it should not be patrolled before fixing it. Would that be better? In other words, assume "patrolling" means making sure the content is "correct(ly interpreted)" (and also non-rule breaking, but we already established that). – Jack McKalling [

] 10:27, 12 July 2018 (UTC)

With regards to "wrong or misleading facts (false information)": I think this is probably the most important use-case for patrolling. If an IP user (any user, but most recently it's been IPs that have been doing this) adds in some dubious information, it shouldn't be marked as patrolled until someone verifies that it's actually correct. That'd be an improvement over the current case, where such information can be added; someone will see it and thing "I should verify this"; and then they forget what they're doing and the information gets stuck. --Pokechu22 (talk) 16:37, 12 July 2018 (UTC)

Suggestions to the Minecraft Wiki

Here have I some suggestions to the Minecraft Wiki:

Make so autoconfirmed users can view abuse filters and the abuse log instead of only sysops, GRASP and wiki guardians
Make so the wiki have the "Minecraft" font or "Minecraft"-like font as default font
Some more skins, usually one "Minecraft" skin with the Minecraft font, stone background with white text, and other Minecraft items, and a skin with the sky as background and default font
Change the "Watch" tab to a Minecraft book instead of a default star
Add a "Interface editor" user group that users in that group can edit the MediaWiki: pages and create/edit editnotices
Make so users can create custom editnotices (as on Wikipedia [1]) for their user and talk spaces as notice while an editor trying to edit the page
More gadgets (wikEd, Twinkle (should be modified to use on this wiki), Navpops, dropdown menu to choose subject/edit summary while editing a page, ProtectionStatus (padlock on top right corner on protected pages), HotCat, a "AutoRefresh" tickbox on Special:RecentChanges to automatically refresh the page instead of reloading the page)
A "Translate" extension on this wiki (as on ftb wiki, mediawiki, meta wiki) instead of creating translation projects

Please add comments below -- psl85 (profile | talk | contribs | send email) 16:02, 5 July 2018 (UTC)

No. --Pcj (talk) 16:14, 5 July 2018 (UTC)

I am going to go by number so its easier to reply to:

I see no reason to grant more people abuse filter rights, especially since some of the abuse filters apply to auto-confirmed users and they rarely need changes.
The Minecraft font would drastically decrease text readability, plus does not support many special characters. I would encourage you to enable this in your own custom CSS instead
Mostly neutral on alternate skins. They serve little benefit and require modifying templates to support them though (plus users may make visual changes to reflect their personal skin), so leaning against having them. You can easily make one in your custom CSS though.
I have that in my personal CSS and it looks pretty good, but when I proposed it before the consensus was it was not immediately clear the book represented watch.
I see no reason to have an interface editor group, they need rare enough edits that you can just ask one of our admins
I feel like custom edit notices has potential for abuse, but mostly neutral.
If you want a gadget here, feel free to port it using your custom JavaScript then propose the ported script. I personally would not use any of them so I don't see myself porting any of them.
The translate extension is terribly complicated to use and makes the markup terrible. I think it discourages edits from all users over encouraging translations.

–KnightMiner · (t) 16:22, 5 July 2018 (UTC)

Autoconfirmed users could only view abuse filters and the abuse log, not modify the filters.

psl85 (profile | talk | contribs | send email) 16:39, 5 July 2018 (UTC)

Just a thought - as you can see above I suggested that a new group called "Patrollers" be added, what if only this user group was allowed to view abuse filters and the abuse log (and not allow them to modify the filters)? Also, I may comment on the rest later - I just wanted to bring this up.-- Madminecrafter12^{Talk to me} 16:42, 5 July 2018 (UTC)

To what end? There isn't really any reason for them to be able to view them. --Pcj (talk) 16:58, 5 July 2018 (UTC)

My opinions:

No. Users would be able to circumvent the abuse filters then. There's no reason for non-admins to see them. Besides, most filters are globally managed by Gamepedia anyway and can't even be seen by admins.
No. The font looks well ingame, but it is horrible for reading larger texts.
Neutral. But it doesn't really make much sense to have 10 different skins. There's a winter skin currently, so maybe we could add one or two more, but it's not really necessary. In my opinion, special skins for special occasions (such as Halloween) would be a great idea. (We do this on the German wiki)
Although I think the star doesn't really fit the skin, a book wouldn't be good to represent "watching". I think an ender pearl / an ender eye would be a good option too. But, really, it's just something visual that every editor should be able to decide for themselves.
No. Why? Just more maintenance work for basically no gain at all.
No. If you need them, add them to your personal JavaScript.
NO. This extension is horrible. (And breaks stuff.)

| violine1101^(Talk) 17:29, 5 July 2018 (UTC)

Here are my opinions:

Not for autoconfirmed users. Possibly for a patroller user group.
Agree with KnightMiner. Possibly make it a gadget for registered users to use, but I don't think it should be the default.
I do think more skins would be nice. I don't think having every possible skin imaginable would really be practical, but I do think a dark skin would be really nice.
Meh. I think people are used to the standard star, and I don't think it helps much making it a book or even an eye. Again, though, having it as a gadget not on by default might be nice.
Don't really see the point and doesn't seem necessary. Anybody can request for an admin to edit an interface page, and editing the interface seems like one of the most hazardous right that admins have.
Possibly, not really sure if it's worth it though.
Neutral.
I don't know much about it, but based on what I've heard, it doesn't seem popular! xD-- Madminecrafter12^{Talk to me} 15:56, 6 July 2018 (UTC)

New wiki skin proposal

I'd like to propose my poorly written stylesheet to be used as the official wiki skin. I have created two themes such as the normal and the winter theme. It's been a long journey since the last time it was changed. So I figured that now is the perfect time to move on from the minecraft forum style. Any kind of suggestions are welcomed. Link to the image – ItsPlantseed ⟨₰|₢⟩ 07:37, 6 July 2018 (UTC)

Would you mind posting some screenshots so people don't have to modify their CSS to comment?

Also, what is the goal of the new skins? The only real difference I could see, apart from some font changes, was most of the background images are zoomed in more. I personally think the current wiki skin is pretty iconic and does not need to match Minecraft.net, since it is very recognizable as Minecraft. –KnightMiner · (t) 14:45, 6 July 2018 (UTC)

I agree with KnightMiner. We don't need to match the style of minecraft.net. We never even tried to match it, the wiki always had its unique design. | violine1101^(Talk) 14:58, 6 July 2018 (UTC)

Link to the image

The current theme is considerably "classic" from a certain perspective. I'm totally fine with the current design, there is nothing to blame about. However, this is not all about emulating the minecraft.net. This is just a minor change for what I called an improvement, that is aimed to make the web equalified with the metro style or whatever you may call it. There's always be a negative side of this and it might decrease the readability of an article. I understand if we don't really need a redesign, but there is always a room for improvement. – ItsPlantseed ⟨₰|₢⟩ 15:53, 6 July 2018 (UTC)

I think my biggest complaint is the inconsistency in the resolutions. The grass side is mostly the same scale as before, but the dirt is now four times the size and stone eight times, despite all connecting to each other directly. Also, I am not sure how I feel about the green links. It looks okay in the main text area, but clashes a bit with the edition boxes, plus I think most users these days are used to blue links so its not immediately obvious that green is a link. –KnightMiner · (t) 16:04, 6 July 2018 (UTC)

The inconsistency of the resolution is mostly intentional, I thought that the nonuniformity will devote a different feeling to readers. As for the green links, I'm not too proud of that either. I just wanted to see how that will look for a long period. That's all I can say right now. I might do another round by changing the links and include others suggestion. Thanks for the feedback anyways. – ItsPlantseed ⟨₰|₢⟩ 16:39, 6 July 2018 (UTC)

Updating the Director page to show only the active directors.

Hi!

The directors' page is currently not updated at all and contain a lot of name of admins that are no longer active on their community, which is not really useful for the overall project and can actually make it more difficult to communicate with an admin from another language that will be able to answer to you, or whatever the director project do.

If you want, this page contain an update to this page where I removed inactive admins — if I made any mistake, point them out. We can simply use that page to replace the content of the real one.

For thos who feel it's important to know everyone on a Wiki who have the admins' rights, I just want to point out that a direct link to that list is placed on the template for every language to know this information. But I don't see any case where it could be useful.

Thanks! JSBM (talk) 03:51, 7 July 2018 (UTC)

I personally think it is still worth showing inactive administrators, but I am fine with distinguishing them. Maybe add an inactive background color or an inactive administrator header/section? –KnightMiner · (t) 05:00, 7 July 2018 (UTC)

That's a good suggestion, that could be a good compromise.

If I may ask, however, what interest so you find to show inactive ones?

JSBM (talk) 05:46, 7 July 2018 (UTC)

The Directors page is supposed to be an overview of everyone who has any special rights on the Minecraft wikis. Changing the page to not show inactive admins would not only mean way more work for us to keep the page updated, but would also mean that it wouldn't actually list all directors. Then, there's the question, when is an admin inactive? After a month? After a year? After ten years? We would need to draw a line. It's the job of the respective wikis to demote inactive admins, not ours. To sum it up, I don't see much benefit in only listing active admins, all it does is creating more work for us.
And also, I think that if only active admins should be shown, we should somehow mark them as inactive instead of removing them from the list altogether. | violine1101^(Talk) 09:09, 7 July 2018 (UTC)

I'm definitely not a fan of removing inactive admins completely. However, I'm not opposed to distinguishing them somehow, whether that's giving them a different color or putting them in a whole different section. But yeah, we would need to decide what counts as "inactive." 3 months maybe?-- Madminecrafter12^{Talk to me} 13:12, 7 July 2018 (UTC)

I would suggest a longer period, as on a slow moving site maybe 3 months is enough for an admin. This is why I on Discord suggested displaying the last contribution date, which I understood would be hard to add sadly. I think maybe 1 year, would be better. Then you could update it quarterly, and not created as much extra work for the updating of this enhancement. With 3 months, you would need to update (bi-)/monthly. Holroy ^{talk◆contribs} 19:21, 7 July 2018 (UTC)

Would it be possible to generate this page in Lua based upon the various lists linked in the title sections? Or make a script to update it monthly? If that could be done, it would be a lot less work, and we could possibly add the last contribution date to the list, so that viewers could decide for themselves which admins are active or not. Holroy ^{talk◆contribs} 19:21, 7 July 2018 (UTC)

I think that the date of last contribution could be shown automatically with something along the lines of {{#explode:{{Special:Contributions/Jahunsbe|limit=1}}| (| 0}} However, #explode and other string functions don't seem to be able to parse templates passed as parameters. I am not sure how to fix that. Alternatively a lua function should be easily creatable. Jahunsbe (Talk) 01:52, 8 July 2018 (UTC)

It might be possible to make a template or module that can parse that, but it would only work for this wiki; there's no way to transclude pages from other wikis. I don't recall where the discussion of it is, but at least on this wiki there has been more effort to demote inactive admins recently. Rather than trying to create a policy for which users with directors permissions should be listed on the directors page, I think it would make more sense to focus on demoting inactive admins and updating the directors page to match actual permissions. -- Orthotope^talk 02:36, 8 July 2018 (UTC)

We are carrying out the inactive demotion process now (see Special:UserRights/IKJames, Special:UserRights/Kanegasi, and Special:UserRights/Hower64), but of course it does not apply to admins on other wikis. For reference, the original proposal can be found here.-- Madminecrafter12^{Talk to me} 02:39, 8 July 2018 (UTC)

Block and unblock templates

Psl85 recently created {{Blocked}} and {{Unblock}}. If we are going to keep these templates, there are several things we have to do:

Make it clear to administrators to use {{Blocked}} after blocking a user.
Change the admin noticeboard message "If you believe you have been wrongfully blocked, please visit an admin's userpage and send them an email using the left sidebar" (which I personally disagree with, considering how most blocks are made to IPs) to mentioning the {{unblock}} template instead.
Actually create Category:Requests for unblock
Decide whether we need {{unblock on hold}}, {{unblock reviewed}}, and {{Unblocked}}.
- If we don't decide to create these, we need to remove the part mentioning these from {{unblock}}

If we do these things, however, it will kind of make this an official guideline. Therefore, I do think it would be nice to get consensus from the community about this before making all of this official.

I personally weakly Support having {{blocked}}. I feel like this would be helpful for making it clear to editors why they were blocked and how long it is. For {{unblock}}, I'm a bit Neutral. I see the point of it, and it could be helpful, but is it really necessary? As for the others, I don't see the problem with admins just replying to the {{unblock}} template with whatever the result is - I don't see any reason why the template needs to be replaced or anything; it would just make it consistent with Wikipedia, which is not a good reason at all. And if we don't decide to create {{unblock}}, we definitely don't need them.-- Madminecrafter12^{Talk to me} 14:32, 8 July 2018 (UTC)

Weak support {{blocked}}, for registered users only (we can't have this template with finite blocks due to maintenance complexity, and we can't block IPs indefinitely). removed on 15:41, 12 July 2018 (UTC) Oppose {{unblock}}: I would expect blocking administrators to watch the talk page of an indefinitely blocked user if some probability of an unblock exists (e. g. not a sockpuppet of an indefinitely blocked cross-wiki vandal). --AttemptToCallNil (report bug, view backtrace) 14:40, 8 July 2018 (UTC)

Could you clarify what you mean by "maintenance complexity?" It seems to work just fine in my sandbox when I set the first parameter to something non-infinite.-- Madminecrafter12^{Talk to me} 14:44, 8 July 2018 (UTC)

I mean removing the template when the block expires. Unless you mean for the template to be the content of a message informing the user of a block instead of a state tag like the one for inactive users. --AttemptToCallNil (report bug, view backtrace) 14:53, 8 July 2018 (UTC)

Oh, I see what you mean now, but I actually was thinking for the template to be more like what you said about "content of a message informing the user of a block." Specifically, the block template stays on their until somebody removes it or archives it - informing the user of their block instead of a state tag.-- Madminecrafter12^{Talk to me} 14:59, 8 July 2018 (UTC)

In that case, why is this even necessary? Blocked users get all this information whenever they try to perform a write action. --AttemptToCallNil (report bug, view backtrace) 15:27, 8 July 2018 (UTC)

Imo, although the blocked text does provide a bit of information, it seems better for users if they get a clear talk page message explaining everything from an actual user as soon as their blocked, rather than just one day they try to edit and for some strange reason they can't - and they just see something that says they've been blocked and gives them some information about it.-- Madminecrafter12^{Talk to me} 15:33, 8 July 2018 (UTC)

Revoked my support for the template. I have reconsidered and Oppose it now. Messages to blocked users about blocks should include reasoning about why the block has been performed (which can't be made into a template), not duplicate information found in public logs and displayed whenever the blocked user tries to perform a write action. --AttemptToCallNil (report bug, view backtrace) 15:41, 12 July 2018 (UTC)

If I'm understanding correctly, you're saying that the reason why the block was performed can't be made into a template? It's actually in the template already, just use {{Blocked||[Reason here]}}, see the template's documentation.-- Madminecrafter12^{Talk to me} 15:45, 12 July 2018 (UTC)

I would say the reason is the key thing this template is useful for, and given that it has to be a parameter, pretty much the rest of the entire template is superfluous. If we do implement it, we should definitely make it more lightweight, similar to the user warning template we already have. --AttemptToCallNil (report bug, view backtrace) 16:13, 12 July 2018 (UTC)

Oppose. On procedure: users should not be creating de facto policies that the rest of the wiki is expected to follow without any prior discussion. On principle: we don't need every complex bureaucratic process that Wikipedia has. On content: MediaWiki:blockedtext already contains more information than {{blocked}} does, and is displayed and removed automatically. If more information needs to be given to a user, admins can always leave a message on their talk page, though I think it's usually not needed. Most blocks are for deliberate vandalism, or are given to users who have been repeatedly warned about their behavior; in either case, being blocked should come as no surprise. -- Orthotope^talk 18:47, 8 July 2018 (UTC)

I would like to point out that I've seen several instances where users who were almost certainly acting in good faith were blocked for a while without any warnings. Fortunately, though, I haven't seen as much of this recently, and when I personally block users, I always try to warn first, especially when it's not blatant vandalism.-- Madminecrafter12^{Talk to me} 18:58, 8 July 2018 (UTC)

@User:Madminecrafter12, User:Orthotope and User:AttemptToCallNil: I would think that we could still use the blocked template, and users could still request unblock using {{unblock}} instead of sending mail to the blocking administrator or another administrator. Current requests for unblock could administrators check periodly and review them, and I think to add a image to the top right corner on blocked user's pages to see if the user is blocked, instead of checking block log and so, and why do you not mention me by using @Psl85: or so, I would be notified about this event so I can easily respond here,

psl85 (profile | talk | contribs | send email) 06:31, 9 July 2018 (UTC)

I do think that we should modify the admin noticeboard text saying "If you believe you have been wrongfully blocked, please visit an admin's userpage and send them an email using the left sidebar." Most blocked users are IPs, and many registered users don't have email enabled. I think something like "If you believe you have been wrongfully blocked, please post your unblock reason on your talk page and notify the blocking admin using {{ping}}" or something similar, would be better.-- Madminecrafter12^{Talk to me} 15:51, 11 July 2018 (UTC)

Delete Norwegian translation project

As a Norwegian I've looked into MCW:Projects/Norwegian_translation, and it's obsolete and outdated, and I believe that this project could be deleted all together.

I've looked through Category:Norwegian_translation, and checked each of them for the last edit date, and found that almost all of those pages were last edited in the period 2014-2016. Some of them have newer edit dates, but that is from two distinct reasons: 1) Fixing broken file links, and 2) Adding other translation links. In the few exceptions to being old edits, just very minor details has been changed since 2016.

To add to this, I would also argue that most Norwegians are proficient enough in English, that there really isn't a need for a Norwegian translation which is poorly translated and outdated. Therefore I suggest to close down this project, and cleanup/delete related pages. Holroy ^{talk◆contribs} 20:29, 8 July 2018 (UTC)

Deletion templates to redirects

This has been brought up a few times on Discord, but I've never gotten around to drafting a proposal. The proposal is that when adding {{delete}} to redirects, that it always goes BELOW the redirect, UNLESS it is a blatant violation of Rules #1 or #2. As many of you know, this will make the redirect actually functional, so that any readers searching for it will automatically be redirected to the target page, but the redirect will still show up in Category:Pending deletion. Here are my reasons:

For alternate capitalization redirects, when a deletion template is on them, readers will be taken to the page that's pending deletion when they search for the title. However, if they are actually deleted, the reader will automatically be taken to the alternate capitalization page that EXISTS.
It's more confusing for newbie readers to come across a page with this giant red box and a link, than if they just searched for it. The second would be the case if the redirect were actually deleted, the first would be if it were just marked for deletion. Also, pages that are marked for deletion show up as search suggestions, so it's likely that readers would click on those.
Some redirects in the deletion category are marked because of a mistake, a misunderstanding, etc. and really should not be deleted at all.
As redirect links in categories appear italicized, this would be very helpful for marking what pages in the deletion category are redirects and which are not. I try to patrol and delete pages in the deletion category as often as possible, especially non-controversial ones (e.g. author's request), but it is difficult with all of the redirects clogging it up.

Curious what others think about this.-- Madminecrafter12^{Talk to me} 16:54, 9 July 2018 (UTC)

Why would this be a question? I'd say that placing the redirection code somewhere other than at the very top should only be done when it is necessary to disrupt the redirect because the fact that A redirects to B is itself damaging (e. g. if someone redirected a page to Special:Logout). --AttemptToCallNil (report bug, view backtrace) 17:40, 9 July 2018 (UTC)

Are you suggesting a new template, aka {{redirectdelete}} or a new policy? If new template, would it be used? How to trigger it usage? If new policy, some of the same apply. In general, I do believe you've got some valid points, though. Holroy ^{talk◆contribs} 20:00, 9 July 2018 (UTC)

Holroy - actually, I'm not suggesting a new template. All I'm saying is that when people add the normal {{delete}} to a redirect page, they should add it below the actual redirect instead of above, so that the redirect is functional.-- Madminecrafter12^{Talk to me} 20:03, 9 July 2018 (UTC)

In other words, you're trying to educate the users to do {{delete}} below the redirect, which is sound advice, but hard to get out to the people. Holroy ^{talk◆contribs} 21:25, 9 July 2018 (UTC)

If this gets mostly support, we can kindly tell users on their talk page to place {{delete}} below the actual redirect if they don't, and reference this discussion. We could also add it to the template's documentation.-- Madminecrafter12^{Talk to me} 02:22, 10 July 2018 (UTC)

Yeah. The way I see it, a pending deletion is just that: pending. It's a maintenance request. Having {{delete}} break a redirect is just as damaging as if {{delete}} also wiped the content of a normal page, like Stone. So yeah, that would be a good rule on the template documentation. – Sealbudsman talk | contribs 02:19, 10 July 2018 (UTC)

Support all of the above. The template must go below the redirect. When the template is placed to break the mechanism of a redirect, it's like saying with arrogance that the request has to take effect immediately without waiting for input from the admin(s) that are notified by it. – Jack McKalling [

] 11:18, 10 July 2018 (UTC)

I Agree with this as well, no point breaking a redirect until we decide whether to keep it or not. This is especially true of template redirects as that makes anything transcluding it now transclude {{delete}} and file redirects as it breaks anything linking the file (though none of these should be marked if still in use anyways).

Its also worth mentioning that the deletion pending redirects show up in Special:RandomRootPage which is not beneficial to the readers. –KnightMiner · (t) 15:03, 10 July 2018 (UTC)

Under the same principle of not breaking things, I'd like to add that when tagging pages for deletion, the page content should not be removed. The exception (similar to what AttemptToCallNil mentioned above) is if the presence of the page content is immediately harmful (personal information, abusive content, etc.). -- Orthotope^talk 01:32, 11 July 2018 (UTC)

Agree. Actually, after thinking about this more, I think that redirects should only be broken or pages blanked if they contain private/sensitive information (e.g. an 8 year old's address), solely attack a living person, or consists only of a copyright violation, rather than just any violation of rule #2. More or less, only pages that would require revision deletion if they were added to an existing page should be blanked. It's helpful for admins to know what the content of a page was without having to dig into the history.-- Madminecrafter12^{Talk to me} 16:01, 11 July 2018 (UTC)

Image animation don't work in Template:Mod/Block

While you can do some animation with images in infoboxes by using, for example |image=White Wool.png;Red Wool.png with the Template:Block, this feature doesn't works in Template:Mod/Block. Could someone check in what's wrong and probably fix it? I can't easily manipulate this sort of code as some of you do. Thanks! - Hugman_76 [ ] 13:14, 10 July 2018 (UTC)

Done

MarkusRost (talk) 13:17, 11 July 2018 (UTC)

Should completely untranslated pages in translation projects be deleted?

I've been marking some of these for deletion lately. It seems like many pages from translation projects (particularly Lithuanian and Vietnamese) have not seen a single attempt at any form of translation, despite existing for several years. Unlike redirects, these pages also clog up the search bar, and being taken to an outdated copy of an article from clicking one of these pages could end up being confusing to new users.

I see no benefit to keeping these pages - they clog up the search bar, are completely useless, are more than likely outdated in comparison to their current English counterparts which could be considerably harmful if someone were to try translating said outdated information, and by deleting them we're not losing anything important since they can be recreated with more up-to-date information. - MinecraftPhotos4U (talk) 20:41, 10 July 2018 (UTC)

In that specific case, it seems reasonnable to delete them, if and only if there is absolutely no translation made on it. JSBM (talk) 20:47, 10 July 2018 (UTC)

I Support deleting any translation pages under the following conditions: they were created over a year ago, and no translation, nor any attempt of translation, has been made to them, per the reasons provided.-- Madminecrafter12^{Talk to me} 20:49, 10 July 2018 (UTC)

Support deletion of translation subpages inactive for over a month if there was no translated content on the page. I put a month instead of a year because such pages should only be works in progress, any reasonable work in translation subpages is made in the language of the translation project, and a month of no translation edits is more than enough to say there's no work in progress on that page. --AttemptToCallNil (report bug, view backtrace) 15:32, 12 July 2018 (UTC)

I agree with that. Also Support. Having all these basically (old) duplicates of pages deleted, cleans up a lot. – Jack McKalling [

] 15:36, 12 July 2018 (UTC)

Makes sense. -Xbony2 (GRASP) (FTB Wiki Admin) (talk) 15:47, 12 July 2018 (UTC)

I'm currently deleting some of the more extreme cases - e.g., absolutely no translation at all, no links, and existed for over 1 year.-- Madminecrafter12^{Talk to me} 18:22, 12 July 2018 (UTC)

On minimally translated pages

There exist pages such as Data values/fin, where only the very first sentence has been translated. While this undoubtedly counts as "translation work", should these also be considered eligible for deletion, due to containing overwhelming amounts of outdated information (that page has existed since 2011), and not having any work done besides the first sentence? - MinecraftPhotos4U (talk) 16:22, 12 July 2018 (UTC)

I think such pages should be deleted on a case-by-case basis only. I agree with the provided reasoning, and I'd say this page scores rather high on my "delete" scale, but I find no way to formalize the criteria for deleting or keeping such cases. --AttemptToCallNil (report bug, view backtrace) 16:37, 12 July 2018 (UTC)

I agree with AttemptToCallNil, it should really depend on the page. In that specific case, a single sentence is not enough to show that the page was translated, and it could be deleted. JSBM (talk) 16:53, 12 July 2018 (UTC)

Archive this talk page

It's the 50th topic, it might need a clearup. - Hugman_76 [ ] 12:01, 12 July 2018 (UTC)

Support, I thinked it also, this talk page is getting very very long and needs archiving.

psl85 (profile | talk | contribs | send email) 12:33, 12 July 2018 (UTC)

The thing is, a lot of these topics are actually quite active. I think at best we could archive the first 11 topics. Maybe we could create an archive for ~~July~~ May - August (I swear I had put May there, but apparently I had put July - anyways, I meant May) right now, and then slowly add inactive conversations to it. Usually MCW creates an archive all at once, but to me archiving topics one by one (or five by five, etc.) seems like our best option here.-- Madminecrafter12^{Talk to me} 12:39, 12 July 2018 (UTC)

The first subject is last updated in May, so I'd start from there already. Besides, it's the next from the last archive. – Jack McKalling [

] 14:49, 12 July 2018 (UTC)

[1] ttps://twitter.com/docm77/status/1001757427480649728

[2] ttps://twitter.com/AypierreMc/status/1001790077083799552

[3] ttps://twitter.com/docm77/status/1001763772111958016

[4] ttps://twitter.com/AypierreMc/status/1001832123609899008

[1]

[2]

[3]

[4]

@@ Line 1,538: / Line 1,538: @@
 :{{c|support}}. I would really like to participate patrolling in my favourite set of pages. It's what I'm already doing basically anyway, without the actual applied hint. And this has nothing to do with my autopatrol usergroup, nor with achievements. I'd like to see it as guarding pages against all kinds of imperfections and what not that I could find as a voluntary task. Besides, it's a built-in feature already to actually patrol edits anyway, why not use it more if admins can't cover it enough. – [[User:Jack McKalling|Jack McKalling]] [ [[File:Grid Book and Quill.png|16px|link=User talk:Jack McKalling|Talk]] [[File:Grid Diamond Pickaxe.png|16px|link=Special:Contributions/Jack McKalling|Contrib]] ] 23:23, 9 July 2018 (UTC)
 :{{c|support}} as well. <nowiki>|</nowiki> [[User:Violine1101|violine1101]]<sup>([[User talk:Violine1101|Talk]])</sup> 19:32, 12 July 2018 (UTC)
+::Group created and populated July 12, 2018 — [[User:Game widow|Game widow]] <sup><small>([[User_talk:Game widow|talk]])</small></sup> 19:39, 12 July 2018 (UTC)
 === What should we patrol? ===
 Since this proposal is heavily based on edits being patrolled, both manually and automatically during reverts, we should come to a consensus about what makes an edit worthy of being patrolled.