Minecraft Wiki talk:Community portal/Archive 25

Cleanup disambig pages with only two things
Disambiguation pages with only two items is useless, such as and  are useless, but some, like  and  are useful, I thinking that we could change disambiguation pages with two items only to be redirected to the thing that refer most to the title, and place about or redirect template on the page and link to the other page, what should we change with disambiguation pages with only two items? Here have I three suggestions:
 * 1) Keep them, they are useful
 * 2) Redirect them to the thing that refer mot to the title and place a about or redirect template that leads to the other thing
 * 3) Delete them

Any comments are welcome!  ( • ) 11:41, 31 July 2018 (UTC)


 * They are useful if they are disambig from the title like your two examples. I see no problem with the user deciding what they mean by or  instead of deciding for them. – ·  02:13, 1 August 2018 (UTC)


 * The, , and disambiguation pages is useful, but I think less useful disambiguation pages, like , , and , should we redirect speed to example  and place "about" or "redirect" template on the speed section and link to the other use, or should we keep them?

(See for a full list)  ( • ) 04:31, 1 August 2018 (UTC)


 * I just said I think we should keep them, why are you asking me again? Yes, you can redirect them and place an about, but that is only useful if one of them is the more likely target (which in both of your two original cases neither is, heart arguably is more useful as health but even that is a bit rough), plus sectional redirects are rough to add an about to.
 * I suggest you look at specific pages and give a clear opinion on what you want done, rather than stating in general disambig pages with 2 pages is bad. It could also be done on the dedicated talk pages instead of needing a community portal topic. – · 00:55, 2 August 2018 (UTC)


 * We could start here a community discussion where users can choose to keep or redirect disambiguation pages with only two items, here have i an example:, should i keep it, or redirect it to , or redirect it to the other use?  ( • ) 03:34, 2 August 2018 (UTC)

What should we do of the "/video" subpages?
Hello everybody,

Recently, after discussing with CrsBenjamin, I was told that, contrary to what I (and others) thought, the Curse videos (from the "/video" subpages) are not subjected to the. They were not "placed at or near the top of a content page by staff members" and we can manage them ourselves, including removing them from the pages, unprotect these pages or even delete them.

I would like to hear what you think we should do with them now. Do you think we should include videos on the pages at all? On which pages? Do you think we should remove the current videos and replace them? Or simply remove the ones that are outdated and that's it?

In addition, do you think the protection should be lowered on these subpages to Auto-confirmed? We could also decide to include them directly on the pages instead, removing the need for the subpages entirely.

21:07, 2 August 2018 (UTC)


 * Many of the videos have been outdated for a long, long time, and all of them were created to describe Java Edition specifically, so they certainly wouldn't meet our standards if they were transcribed into prose. On the other hand, they're funny, entertaining, and most of the information in them is still accurate (since they're fairly general). They're better than nothing, I'd say. They were still valuable to me as a noob, and I feel a bit nostalgic about them. I'd be sad if we decided to delete most of them. – ( &middot; ) 21:35, 2 August 2018 (UTC)


 * Technically most of them weren't created for an edition, since back then Java was the only platform for Minecraft. But back to the point at hand, if any of them are still relevant, they should just be included directly on the pages. If it's decided not to be used, either delete them, or use media links on a video archive page to keep them linked to something in case someone wants to find them. In either case, the video subpages themselves really don't have a practical use.   23:38, 2 August 2018 (UTC)


 * I believe it would be best to remove them only when they are very overrated (few of the cases) -  20:44, 4 August 2018 (UTC)


 * I believe the videos are useful (mostly due to what Auldrick said), so I don't think we should delete all or most of them. However, I propose to remove videos that are very outdated and a lot of the information doesn't apply anymore, such as the video for . I also strongly support lowering the protection. Admin-only seems extreme. Maybe we could change the /video subpage abuse filter so that it only prevents the edit if the user has made less than 50 edits and lower the actual protection to semi. I'm not sure how much I like lowering it completely, as I could see IPs adding their own videos and such.-- undefined 00:16, 6 August 2018 (UTC)


 * Also, we need to rewrite the video policy. The page is currently confusing and full of inconsistencies.-- undefined 00:19, 6 August 2018 (UTC)

Proposal
Given the few answers, I'm directly going to make a proposition instead.

I suggest that we do the following:
 * For articles that doesn't benefits from an additional visual explanation (for example, blocks like, or ; items like  or ), the videos should be simply removed. These pages are generally good with only text, and there is no reason to keep a video.
 * For articles that can be better understood with some visual content (for example, blocks like or ; items like ; most mobs and biomes), the current videos should be kept only if they are still accurate and reasonably up to date. Videos that are too outdated should be removed. (For now, they would not be replaced, but see the next section for that.)
 * Snapshot and update articles should keep their videos. However, they should be put between  tags when necessary to prevent them from showing on pages like.

In addition:
 * All "/video" (and "/Update Video") subpages should be removed, and videos should be directly inserted in the articles;
 * The abuse filter that prevent from creating or editing "/video" subpages should be removed;
 * We should start discussions to decide if we should encourage people to add new or more up to date video on pages where they could be useful. We should also discuss if we want to replace outdated video, and which video should replace them. Potentially update the too.

I think it would be a good start. We would already clean up a good part of the videos on the Wiki, and it would allow us to make a decision in the future on more complex or specific case, or about the future of videos on this Wiki. So, please share your opinion on this proposal, it would be greatly appreciated!

16:19, 5 August 2018 (UTC)


 * , I think the "/Update Video" subpages should be kept for their utility. - [    ] 16:30, 5 August 2018 (UTC)


 * Agreed.  13:36, 16 August 2018 (UTC)


 * , definitely. I like the idea (from point #1) that we might start only adding/keeping videos because they are useful because they convey ideas that are difficult in text. I notice that's already in the video policy, though, the first section. Definitely support weeding through them though. –  |  21:24, 5 August 2018 (UTC)


 * , I'm working on each of the videos. As I have mentioned several times, I would like to visually contribute some articles: first I am uploading right now a new tutorial video for the Beginner's Guide page. I would like to set up a small "media" team whose job would be to leave the site updated and expressed in harmony. For example, the x or y in-game server or minecraft news/foruns/etc. sites has a group of people focused mainly on the part of the presentation. --  00:10, 6 August 2018 (UTC)

InvSprite vs ItemSprite
There are currently two templates that manage the display of item inventory sprites on the wiki: InvSprite and ItemSprite. Are there any known differences in the purposes of these templates? Could they be unified in some way? InvSprite has a more complete listing of sprites, but ItemSprite has a handy associated linking template in ItemLink. So far as I can tell though, the overlapping sprites between the two templates are the same. I believe somehow merging these templates would allow for easier maintenance of sprites going forward, but I am not sure as to the best way of doing this without having significant, site-wide consequences. Any ideas? —  21:26, 7 August 2018 (UTC)


 * The easiest way to merge the spritesheets would probably be to resize and set a scale of 2 in . The hard part would be making the names consistent. The names from one or the other could be set to deprecated, or each template could use different names. It would be better to make all the names consistent. Unfortunately that would entail setting ~2,368 sprites names as deprecated. A solution to that could be to make  format names to lowercase and space replaced with -. It would need a parameter to turn that on/off.   23:55, 7 August 2018 (UTC)

Don't assume all edits are vandalism
A friendly reminder to everyone - just because an edit changes factual information, comes from an IP, or is unexplained does not mean it's vandalism. I have seen this happen a lot - a user makes an edit, an experienced user just assumes it's bad and doesn't verify it, so they revert it, a lot of the time with no edit summary, and it turns out the user was correct. This seems to have occurred repeatedly within the past week or so. So I just thought it would be nice to remind all of you - before reverting an edit for being "vandalism," look over the edit and see if it seems probable that it's actually correct information rather than just assuming that it's vandalism. If you have the game, of course you can test it there - otherwise, we do have. I have noticed this happening more often after we started promoting a lot of patrollers - if a new user makes an edit, it's just assumed to be vandalism and rolled back without an explanatory edit summary, assuming that it's vandalism.

Do note that it is not at all one specific person doing this, or even a few specific people. And I do know everyone is trying to help the wiki, and all of your work is greatly appreciated. I've just seen this from many different users several times, so I just thought I would point this out. Remember, not all edits that look like vandalism are vandalism. Not all IP editors all vandals. Not all unexplained changes are incorrect. Just something to keep in mind.-- undefined 19:43, 10 August 2018 (UTC)

Aboud "id", "id name", "data value", "name" and so on
Each one of the nouns above may have different meanings in different pages.

For example,. In the infobox, its "data value" is 35, and "name" is "minecraft: _wool". And in the section "", its "id" is "minecraft: _wool" and "data value" is an integer between 1 and 16 (in BE).

In the page, the id names of advancements are called "interal id", for example, "minecraft:story/obtain_armor".

In the page, those id names are called "IDs", but in the section Biome IDs, the IDs are called ID names. In the Enchantment IDs and Status effects section, those id names are called "Name". The whole page is names "data values", but includes id names and so on. "Block data further defines blocks placed, describing for example the height of water or the direction a torch points.", but "block data" means the NBT of block entityes (chests, signs etc).

So these concepts need clear names (see also ):


 * The id names of things with namespaces, all-lower cases and underlines, including s,, , , , advancement triggers, criteria, bossbars, , , , s, s, dimensions, type of and.
 * The number id of blocks, enchantments and so on before 1.13 and in BE.
 * The integer to specify the block's facing, color, variant and so on before 1.13 and in BE, for example, the "3" in.
 * The NBTs of blocks and entities, which can be modified with . -- 05:08, 17 August 2018 (UTC)


 * ID
 * Numeral ID
 * Metadata/block data/ item data item damage (Item data makes more sense for NBT)
 * NBT data/entity data/item data
 * These would be the most logical to use, and wouldn’t require changing most things.  05:23, 17 August 2018 (UTC)


 * Several of these labels have now been changed to "Numeral ID", which I find quite jarring. I was taught "numeral" as a noun denoting the symbols "1", "2", "3", etc. (especially in the phrase "Roman numerals"), and I don't remember ever seeing the adjective used before this. It's in my dictionary, but I don't think it's in frequent use. I would use "numeric ID" or the synonymous "numerical ID", and I think other American English users would as well, but I can't speak for non-U.S. speakers. Do native English speakers in other countries and regions also find "numeral ID" awkward? – ( &middot; ) 01:42, 13 September 2018 (UTC)


 * I have now put this on my, with the following:
 * the namespaced, lowercase and underscore IDs: Name ID
 * the numeric IDs: Numeric ID
 * the NBT data: Block/Entity/Item data
 * the integer for item damage, block variant, etc.: Metadata
 * Please tell me if this seems good, or what needs changing, so I can make it correct someday soon.  12:34, 11 December 2018 (UTC)

Creating a template
Can I create a new template on this wiki? -- zh.admin （ •  ） 10:27, 19 August 2018 (UTC)


 * What for? There’s no requirements AFAIK, but just to make sure no such template exists already.  10:59, 19 August 2018 (UTC)


 * If you think that a new template could be helpful, I'd say . But like FVbico said, make sure it doesn't exist already - if it does, though, it may make a good redirect.-- undefined 12:31, 19 August 2018 (UTC)

Should ids in infoboxes appear with namespaces?
For example, in the section, Java Edition IDs may be "minecraft: _wool" (although namespaces can be removed almost everywhere in game); in the infobox of the page , the "Biome ID" can be "minecraft:snowy_tundra" rather than "snowy_tundra". I think ids with namespaces can be more scientific. -- 10:38, 30 August 2018 (UTC)


 * I don't think this matters much - firstly, if not specified, it defaults to . Secondly, this wiki focuses on vanilla Minecraft content, and mods (and possibly datapacks in the future, if that ever catches on), if documented here at all, are clearly marked as such. We can safely assume every registry name defaults to starting with  . -- 10:44, 30 August 2018 (UTC)


 * We could add a hover text over the "nameid" label that says it's namespaced with, but as already stated, it doesn't matter if it's specified at all, and even worse: in bedrock the namespace has to be omitted (in commands at least). So I think namespace shouldn't be specified. (Though I do think mod pages should specify it, either in the value or hover text.)   11:03, 30 August 2018 (UTC)

Use of Minecraft: Bedrock Edition
On this page, the term Minecraft: Bedrock Edition was used. This was never officially used by Mojang or Microsoft. Is there something to do with it?--  08:25, 15 September 2018 (UTC) ''Edited on 08:27, 15 September 2018 (UTC) ''


 * It is officially used by Mojang now. What is your question? – [   ] 12:21, 15 September 2018 (UTC)

Navbar hollow's edge behind the search bar
Should this be retextured? ( | ) 12:26, 19 September 2018 (UTC)


 * I looked into it, and this isn't a texture. It's the solidly coloured border of an element, made to look like this specifically with the stylesheet. The dark background of the search bar is all style, no images here that overlay the page background. – [   ] 13:02, 19 September 2018 (UTC)


 * Then make a background image for it maybe? I made this image for that edge but didn't know exactly how to put it in...





Split different Minecraft versions
Pages are becoming increasingly cluttered and difficult to read as the different versions of Minecraft (e.g. Java Edition, Bedrock Edition, Education Edition, etc.) drift further apart. Currently, articles tend to describe all the different Minecraft versions in a very disorganised manner. It is frustrating trying to read an article when only a proportion of the information is relevant to the version you are using.

I propose splitting each page into a separate page for each version of Minecraft, as this will greatly improve readability. This could be done in a manner similar to the Star Wars Wiki: Many of their articles have separate pages for "Canon" and "Legends", with tabs at the top of the page to switch between the two. Minecraft Wiki articles could include similar tabs to switch between the different Mincraft versions.

-- 15:59, 19 September 2018 (UTC)


 * . This would make the wiki way more confusing to navigate then before. - ( 16:35, 19 September 2018 (UTC)
 * on this implementation, the idea of somehow allowing readers to choose preferred editions, or otherwise allow them to find content relevant to a specific edition faster. --  16:39, 19 September 2018 (UTC)


 * creating new pages for everything. Creating new articles where most needed, and for finding better ways to organize editions. I agree that the split between editions is somewhat disorganized, but I think that creating a page for every article is too drastic. There's not too many edition differences other than little quirks and edition exclusive features. I would rather do something like the Terraria Wiki(literally just hit random page) where they use icons to show the differences between editions.   00:44, 20 September 2018 (UTC)


 * like the others above for splitting all pages. Please refer to these existing discussions instead:, and , and check out the project . This is a hot topic, different, more convenient approaches have been discussed in many places as you can see, even on this page's archives. –  [   ] 07:48, 20 September 2018 (UTC)


 * Will make the pages even more confusing than they already are. –   08:09, 20 September 2018 (UTC)


 * This is not the way it should be done. Works well on Wookieepedia as things are often very different in Legends than Canon, but Minecraft has many editions and differences are smaller. - ( · ) 10:03, 20 September 2018 (UTC)


 * I do not understand what would be the advantage of this, even with your explanation. But I agree that we should think of a better way to make the pages less confusing, according to the editions of the game  05:41, 21 September 2018 (UTC)


 * I Believe that this will make the wiki a lot easier to read and acess, but it would take a LONG time to change everything. However, I still thing that thi is the best way to go.  00:25, 22 October 2018 (UTC)


 * . The idea of putting version onto tabs is not a very nice idea. On the Mobile version, it doesn't even have any tabs at all, and there are many versions currently, which will make the navbar look like so:




 * Also, putting everything in one page will help one compare between versions.


 * ( | ) 01:33, 28 October 2018 (UTC)

To everyone: Voting in discussions
There is this one issue with many editors' interpretations of discussion procedures which has the potential of being highly damaging to the project. It's that wiki discussions are votes. , and.

The wiki is a resource written for readers, almost none of whom are editors. According to the admin analytics dashboard, all Minecraft Wikis in total had more than 4.5 million visitors (you can safely assert that 3 million of them visited the English wiki) over the last 30 days, while during the same time period only 237 accounts have performed any actions at all on the English wiki, and if you exclude blocked accounts, known alts and bots, as well as users with less than 5 actions and without extended rights, this list gets down to 70 entries.

That is, out of every roughly 43 thousand visitors only one can very remotely (5 actions is an incredibly low bar) be considered an editor. And given the number of those who participate in discussions is even lower, we can with no hesitation assert we have not the slightest idea about the opinions of almost every visitor on matters which will almost definitely affect almost all of them. In other words, the set of people expressing their opinions in wiki discussions is an insignificant subset of the actual community affected by decisions made in these discussions.

And yet, I have seen many times that decisions have been made, or that it has been implied that a decision should be made, on the basis of the number of users who expressed their support or opposition to a proposal. In addition to the already stated misrepresentation issue, there are multiple others.

First, in a discussion it's meaningful not only to introduce a new viewpoint, whether entirely original or derived from an already stated one, but also to support an existing one. Just supporting an existing viewpoint is equivalent to saying "I have reviewed your proposal, haven't found substantial flaws in it, and would like to see it implemented". Just opposing it without any explanation is saying "I have found flaws in your proposal I'm not telling you which I think mean the proposal shouldn't be implemented". Do I need to tell you how constructive it is to be told there are significant errors in your work without a slightest hint at what these errors are? Yet I have seen editors rebuked for insisting raw opposition is meaningless. Just one example of a stated opinion which shouldn't affect the outcome.

Consider also this scenario which serves to demonstrate the nonuniformity of local and general competence among wiki editors. A proposal is made which is supported by ten users, yet an eleventh user comes and points out a significant and easily verifiable flaw in the proposal which means the proposal would be harmful if implemented. Do we need to delay dropping the proposal until either five of the supporters concede to Comrade Eleven, or twelve more users come and express their agreement with them? No, because the presented evidence takes priority over the number of initial supporters.

If you're going to go further, there's fact people are more likely to express discontent rather than content; I have been told by another prominent editor on the Russian wiki that they consider pure support unconstructive. I pointed out that this means a very good proposal won't receive any comments, rendering it unable to pass if the proponent wishes for a second user to review and support it before implementing it.

And that's not even considering arguments can be plain wrong. As a classic example, and one which I find very annoying, is this: Let's do X, like on Wikipedia! --User 1
 * Oppose. We're not Wikipedia. --User 2

Neither user really provides a point. There are many reasons why a procedure vital for Wikipedia could be highly detrimental to Minecraft Wiki. For one, we are a much smaller community with a significantly more narrow focus, and especially complicated procedures modelled after Wikipedia may backfire if implemented here, such as by exorbitantly draining the time and strength of our editors and administrators. Neither does User 1 in the example present issues on Minecraft Wiki their proposal is meant to mitigate, nor does User 2 properly analyze the proposal and present future readers of the conversation with the apparent intent and effects of the proposed procedure or action.

To summarize, counting opinions cannot be used as a substitute for analyzing arguments and evidence. Also, I'm very tired due to recent real-life events, so please forgive me for writing Frisk-sized walls of text with the clarity of a poorly constructed artificial intelligence. -- 16:31, 22 September 2018 (UTC)


 * Except that of those many many visitors, a large portion has no experience with this wiki or wikis in general. The people who are frequent editors are, in general, the people who have the most experience with the wiki. This is only a response to your first "point" about the significance of a vote in the grand scheme of the wiki and its users. -- 19:16, 22 September 2018 (UTC)


 * It took your post, and some time during a sleepless night interspersed with thinking about legally privileged child abuse and nonprosecutability of obstruction of medical services with the intent to cause death of another, to conclude that the problem was way worse than I initially thought.
 * The problem isn't that most readers are not experienced enough to offer useful feedback in discussions. Users' experience is covered by the "10 vs. 1" point. The problem is that readers are affected by something they will not influence for several reasons.
 * First, it's that the fact the wiki has a metapedic component at all is obscure for most readers. The idea that every software product or a website has the work of people behind it is not one which occurs to most people when they use it. To read a wiki, it is "sufficient" to view it as a black box which typically provides useful information when a request is made.
 * Second, it's indeed that people often lack the experience to notice improvements can be made at all. Such inference requires familiarity with many more concepts than even your slightly above-average Alison or Solomon would know. "Not everyone is a web designer" is an understatement.
 * Third, it's that people are being purposefully conditioned by powerful entities such as governmental and religious institutions not to express any form of discontent, but rather to accept the world as it is made for them without questioning the actions or their "superiors", let alone trying to change anything.
 * Referencing the third point, during my high school years (not so long ago as some of you might think) I have noticed what seemed to be a misspelling in the history textbook. While the teacher (she was hardly less than 70 years old at that point) agreed, half the class started fervently convincing me there is no error (despite none of the actors having higher language grades than me). It shouldn't come as a surprise I spent some time in the evening trying to figure out which opinion is the right one. I determined that the form used in the textbook had only recently entered dictionaries as a valid alternative, and writing practices listed in some less widely known, yet authoritative sources prescribe using the new form only in some contexts the older form was used in; the example from the textbook wasn't one such context.
 * Summarizing: even though our decisions affect so many, so few of them will ever participate in our decision-making processes. This requires a reader to be familiar with the wiki (and/or wikis in general), being able to generate ideas they would consider useful, and willing to offer their suggestions to others. At this point, we most likely no longer have a reader, but an editor; and I listed the ratio of readers to editors in my previous post, which is sufficiently accurate even considering various errors and potentially inaccurate assumptions made when calculating it. -- 06:24, 23 September 2018 (UTC)

Thanks for the fish
The fact that the message "Thanks for the fish" is a reference to Hitchhiker's Guide to Galaxy should be mentioned on the page about splash messages. I already posted a few comments about this topic on the page, but no one seems to have noticed them, so I posted the issue here. 17:05, 1 October 2018 (UTC)


 * The actual sentence in Hitchhiker's Guide is "So long, and thanks for all the fish", while "thanks for the fish" is an ordinary sentence that might be said spontaneously by any dolphin in the game if you imagine it could speak. What evidence is there that Mojang intended the splash to reference the book? I find it believable that they did, but I'd be more convinced if the splash included the word "all". – ( &middot; ) 17:17, 1 October 2018 (UTC)

is not Minecraft-related in any way and sounds like blatant advertising. I think it doesn't belong to Minecraft wiki and should be deleted. 11:22, 8 October 2018 (UTC)


 * Although this page was made by some of the hosting Gamepedia platform's staff members, and was legitimate back then, the page is old and I don't believe relevant anymore. It contains dead external links and mentions an "as of" date of over 5 years ago. The associated talk page also discusses whether or not to delete it. – [   ] 11:50, 8 October 2018 (UTC)


 * I asked on Slack what should be done with this page. -- 12:02, 8 October 2018 (UTC)


 * by ATCN. I personally still don't necessarily like the idea of having a mainspace page that's not fit for mainspace, even if it is a soft redirect, but it's better than it was before.-- undefined 00:42, 12 October 2018 (UTC)

Articles for Deletion: Texture pack lists
The result of the discussion was delete. I'm going to be deleting the 3 subpages of below, and am moving the Programs and editors/Inventory editors deletion discussion to a subsection and leave it open, so that the questions asked by  asked can be addressed.--  undefined 01:16, 18 October 2018 (UTC).

Quoting myself from Discord, they are "unmaintainable collections with no definable inclusion/exclusion criteria". Another quote from :
 * there is no reason to keep them anyway, it would just be another (set of 3) pages sitting and doing nothing
 * it's not there for people to refer to either, because they are not really linked to

Your thoughts? -- 17:35, 8 October 2018 (UTC)


 * for all reasons as stated above. - ( 17:42, 8 October 2018 (UTC)


 * I these quotes. And deletion as well. –  [   ] 18:37, 8 October 2018 (UTC)
 * , the lists are very incomplete and rarely updated, making them hardly useful for anyone. 04:07, 9 October 2018 (UTC)
 * . – undefined  04:20, 12 October 2018 (UTC)

Articles for Deletion: Programs and editors/Inventory editors
I would also support the deletion of (which is outdated and contains few items) under the same criteria. – undefined  04:20, 12 October 2018 (UTC)
 * the deletion of too. It seems to be incomplete and rarely updated, making it useless.  07:33, 17 October 2018 (UTC)
 * Just that subpage? You think some other subpages of (or that page itself) should be kept? If so, tell me why. --  19:19, 17 October 2018 (UTC)
 * Pinging . -- undefined 01:46, 18 October 2018 (UTC)


 * I wouldn't really mind the deletion of any of them (especially the list style articles or extreme stubs), though I think may still have some significance (partially since it was developed by Searge and ProfMobius). – undefined  23:52, 19 October 2018 (UTC)
 * all. Every one of the lists seems to be rarely updated and almost every program listed on those pages is incompatible with the most recent versions of the game. I don't think these pages are useful for anybody. 05:16, 20 October 2018 (UTC)

Create abuse filter for "Roblox" vandalism
I see that the "Roblox" word is often added to the pages by some IP users and is often added, should we create abuse filter for "Roblox" vandalism that does not allow inserting the word into pages?  ( • ) 06:15, 9 October 2018 (UTC)
 * , a filter like that would be very useful in preventing vandalism and won't create false positives, since there is no good reason why that word should be added to any page. 07:06, 9 October 2018 (UTC)
 * Filters for "Robux", "Robucks" and "Roblocks" would maybe be helpful as well. 16:20, 23 October 2018 (UTC)
 * It looks like filter 6 (the disallow certain words filter) isn't completely working now, which is why your test edit went through. I thought it might be something I messed up, but I don't see how that would be possible. How the abuse filter rule works, is all of the words in the filter are fully capitalized (i.e. GAY), but it apparently previously disallowed the edit when the same word is entered with ANY capitalization. However, as apparent with some recent vandalism, it no longer catches the certain words if they're in lowercase. A staff for Gamepedia believes it may be because of an abuse filter upgrade in preparation for the next MediaWiki update (which overall I'm very excited about). I'm not an expert with AFs, so I may consult with someone who has better understanding. As for your suggestion, I'm not sure how helpful Robux, Robucks, and Roblocks filters would be, but if it becomes a problem I'd be happy to add them to the filter.-- undefined 16:40, 23 October 2018 (UTC)
 * Ok, but i would be happy if you or some staff add them to the filter now because the words have no use in any page, and if there is problem with the words, please add them to the filter. Also, when is the next MediaWiki release?  ( • ) 16:51, 23 October 2018 (UTC)
 * We generally wouldn't add a word to the filter for the sole reason of never having any use, but rather if a word becomes a problem. So far, there hasn't been any vandalism regarding Robux, Robucks, and Roblocks as far as I know (correct me if I'm wrong please), so there's not any point adding them to the filter. If we were to add every possible variation of a word as long as it has no use, we would add "g*y," "ga*," "ga*y," "gy," "gaay," "gaey," and the filter would eventually get clogged up. Also, words will sometimes create false positives when you can't even imagine it would, so it's better to put as few words as possible while still making the filter effective against vandalism. Again though, if it becomes a problem, let me know and I'd be happy to add them. :)-- undefined 15:59, 3 November 2018 (UTC)
 * Also, MarkusRost was kindly able to help me fix the problem regarding the capitalization errors by just adding a bit of regex coding, so the filter should be working now. About the next MediaWiki release, I don't know exactly when it will come out, but hopefully soon!-- undefined 16:01, 3 November 2018 (UTC)

Mob and Block Renders
Where exactly do the images of mc mobs and blocks come from? How are they made? Who makes them? –Preceding unsigned comment was added by ( • ) at 6:51, 14 October 2018 (UTC). Please sign your posts with


 * See -- (undefined/undefined) 08:24, 14 October 2018 (UTC)

Proposed 3DS version history split.
After that small edit war which sort of felt like that time in which the crown when to Henry VI and then to Edward IV in the War of the Roses that seemed to never end, we have a discussion woo.

Anyway, this discussion is in regards to the splitting of the article into several version articles.

Personally, I do the split because I feel like the split is not really necessary and it would be better off if the version history stayed within the main article. - ( 22:04, 22 October 2018 (UTC)


 * That's basically saying you oppose the split because you don't like it. I am towards the split because while that single history page is somewhat hard to read and navigate, it's also rather short. Also, that table layout makes me cringe. So much empty space. Maybe refactor it into sections of regular text? --  22:36, 22 October 2018 (UTC)


 * Well obviously I support this split as I already did it. There is literally no reason not to and all other versions that go by only one name get their own pages. And that table layout is horrendous especially on mobile. You have yet to really provide an actual argument against splitting, BDJP. –    22:40, 22 October 2018 (UTC)
 * the split. Just like Nixinova said, the page is a bit hard to read on mobile. 16:06, 23 October 2018 (UTC)


 * splitting. First of all, I appreciate that we're actually discussing this, rather than just revert, revert, revert, revert, screams on the talk page to stop, page protection... lol. In short, I feel like it would help the wiki more to split rather than harm it. The table is cluttering and I see no benefit to having it there. Also, the pages Nixinova had created are actually quite long, so it's not like there's hardly any information that can be said about these versions making separate pages useless. The version history page for the Nintendo 3DS Edition has looked terrible for a long time, and I definitely think there's enough information about each page to go ahead and do the split.-- undefined 16:25, 23 October 2018 (UTC)
 * I'm going to remove the deletion templates since there's supports don't revert pls. –   00:48, 24 October 2018 (UTC)

Mubble migration - need to talk
Earlier in the past months I've seen a lot of discussion about moving Mods pages to the FTB wiki. I've got my own mod which is and before this topic started to trend again I've actually already had many pages of documentation about the mod here. After the topic came in again, I started thinked about what I should have to do. Then, I contacted the Gamepedia administrator team to make my own wiki about the mod, their reply was to move to the FTB wiki. So at this point, almost everything led me to migrate Mubble to the FTB wiki.

Today, I can fairly say that more than everything documented here have been moved to the FTB wiki: right here.

However, I still wonder if Mubble should be kept here, as have been created for it and I don't know how the topic of "moving mods to FTB" evolved. So I'm asking to you, do you support or oppose the idea of keeping the Mubble mod here? - [    ] 09:49, 23 October 2018 (UTC)


 * The discussion can now be found here: . Judging from the arguments, the idea of the migration was to move from here over to ftb, which indeed means our pages would get deleted after having been implemented there. It's not really a migration if we keep the pages on our wiki. I don't think it'd be a problem if we need to delete that many pages, as long as a link to the new location is put in the deletion summary (either the main entry of the mod for each page, or an individual link for each page). – [   ] 09:58, 23 October 2018 (UTC)
 * keeping Mubble here. In fact, I oppose keeping any sort of mods here. The FTB wiki is the right place for them, not this wiki. 16:02, 23 October 2018 (UTC)

Math format according to user settings
When I view this wiki (and every other site that uses English), I almost always have to face this format:

40,000.8 / 4 x 1.2 = 12,000.24

However, in my Vietnam, it writes like this:

40 000,8 : 4 . 1,2 = 12 000,24

And the result is I usually take my brain into calculating what is 40,000.8 (=320).

Recently because of my habit, when I was rewriting some portions of pages, I also applied my format to the things related to math and numbers.

But people use the 40,000.8 format, and they in turn are confused.

So I thought would it be possible if there is something to reformat these stuff for each user? Like when the page is generated, MediaWiki formats them according to the requesting user's settings.

Or do I have to learn to be familiar with the 40,000.8 format, which will force me to be two different people at the same time? ( | ) 23:44, 23 October 2018 (UTC)


 * I would use US standard formatting for consistency throughout the wiki, much like we use US English spelling. Other language wikis are free to select a style that is more familiar for native speakers of that language. I don't know of a way to automatically reformat numbers and math; it would probably require writing an extension, and using a template to mark what parts of a page should be reformatted. -- undefined 00:23, 24 October 2018 (UTC)


 * Yes it is confusing when you're used to a different format. But this wiki is supposed to follow American language and so formatting as well. It's possible a javascript gadget could be written to allow for flexible formats, customizable on a user basis, but there is currently no such thing available on the wiki. It doesn't have to be an extension (if I'm not mistaken) – [   ] 08:04, 24 October 2018 (UTC)

Not every statement needs to end with a period
This is probably something I should have brought up earlier, but it's getting out of hand at this point. ,, . Not everything needs to be a complete sentence. In particular, the issue links thing bothers me: issue titles are generally titles, not sentences; adding a period to the end of "private security issue" is grammatically worse. Adding periods in a list of titles is really not useful, I think; it's also counter to how Mojang writes it on their changelogs and how JIRA generates release notes. It's just a bit of a mess to add periods to everything, especially without rewriting all the titles (which I don't think is a good use of anyone's time either).

In other articles and contexts, it may make some sense, but e.g. in tables and lists converting things into a sentence just to add a period isn't worthwhile. (An example of a list on wikipedia like this: ). -- 15:30, 24 October 2018 (UTC)


 * In my defence, I never tried to do this up until someone did in my stead. I always merely just copy what others do. But still sorry, if you're not the only one who believes this, I'll adapt yet again no problem. – [   ] 15:47, 24 October 2018 (UTC)


 * No worries, just pinging you since I've seen that you've done it in the past. As I said, I probably should have brought it up earlier (I mentioned it on the slack and said I'd make a post, but never got around to it).  --  16:12, 24 October 2018 (UTC)


 * Thanks for this! This saves more time than you can imagine, I've been doing this since I also saw this sort of thing happening. Thanks again! - [    ] 21:31, 24 October 2018 (UTC)

(seems like I forgot someone else who's been doing this: ) -- 20:52, 24 October 2018 (UTC)
 * I just do it because everyone else does. I'm fine with not adding them to the bug fixes. –   21:16, 24 October 2018 (UTC)

"Discovered" features
I should know this already, but I don't. IP user 79.66.44.40 is making edits for Bedrock 1.8.0.11 Beta, claiming that the command was added. I have no doubt that this is something he found in the command autocomplete list, but it's not listed in the official changelog (and I'm guessing it probably doesn't work yet either). Do we have a consensus about including information about such "discovered" changes in the wiki? – ( &middot; ) 18:31, 24 October 2018 (UTC)
 * Well if it wasn't in 0.10 but is in 0.11 I see no reason not to add it. –   18:34, 24 October 2018 (UTC)
 * One possible argument is that if it hasn't been announced officially, they could postpone adding it indefinitely or even cancel it altogether. – ( &middot; ) 18:36, 24 October 2018 (UTC)
 * And thus we shouldn't mention it at all? Why not at least mention it explicitly as a not officially announced (or implemented) feature? -- 18:48, 24 October 2018 (UTC)
 * It was still added and we can't tell the future so it should be on the page. –   20:09, 24 October 2018 (UTC)

Pages maintained by Mojang
Certain of our pages, notably, , , , and , are maintained as official technical documentation by Mojang staff. We may have an occasional need to fix typos or make edits to bring them into compliance with the style guide (e.g., the names of the newest pages aren't capitalized properly), but in general these pages shouldn't be edited by non-Mojang staff. Should we have banners on these pages to warn people? What else can or should we do to protect these pages from vandalism, trolling, and even just misguided edits made in good faith? – ( &middot; ) 22:52, 24 October 2018 (UTC)
 * should be involved in this discussion. – ( &middot; ) 22:59, 24 October 2018 (UTC)


 * There is a template like disclaimer, I don't see why we can't have a similar (or modification of that) template to say something like "The contents of this page are directly supported by (...)" or something like that. – [   ] 23:13, 24 October 2018 (UTC)
 * Of course, we need another template which is excessively hostile and disruptive, and which has been fully protected for the purpose to ensure that it perpetually remains excessively hostile and disruptive. But seriously, a template wouldn't hurt, just don't go overboard with veiled threats warnings or praise. -- 04:23, 1 November 2018 (UTC)


 * I suggest all of them should have at least an autoconfirm users protection to prevent vandalism. We can make an needs update above or create a template specifically for these pages.--  01:33, 1 November 2018 (UTC)
 * What you're trying to accomplish would probably work better with FlaggedRevs stabilization, but I doubt this will get approved. I don't think the matter or vandalism protection can be meaningfully discussed without Mojang staff. -- 04:23, 1 November 2018 (UTC)

Protection locks
Hey folks! Per now archived discussion, I've enabled a gadget which makes a lock show up in the top-right corner of protected pages, with the color of the lock depending on the protection level. Currently, it is not on by default, so you have to go to the gadgets section of your preferences in order to turn it on. I was a bit in doing this, as not all the details had been worked out, but the discussion had gone silent for a while and I thought it would be nice to actually get this done. That being said, now that it's been implemented, if any one has any suggested improvements or changes you think would make the script better, please discuss here. Here may be some questions that should be answered:


 * Should we make this gadget on by default? Update: It's now on by default
 * Should we add locks to signal move protection or upload protection?
 * Should we use locks different than Wikipedia's, such as the ones Violine's suggestion or Leduyquang's?
 * Should we delete or deprecate protected?

One thing I would definitely support is making this on by default and only allow registered users to disable it. I might even support adding the script to the global JS and removing the gadget. Feel free to discuss any or all of these points here.-- undefined 12:52, 25 October 2018 (UTC)


 * Good script, and I see the lock on the page, and I support adding it on by default, the lock makes it easier to see the protection level, instead of needing to view source on locked pages to see the protection level. We can also use upload/move locks to see upload/move protection level without trying to move the page or upload new version of a file, and then the page is protected, and the protected is almost completely useless because the ugly message box and simply says "This page is protected due to a common vandlism target" or a commonly transcluded template. We can delete the protected templae, it is complete useless while it is now locks available. -- ( • ) 13:18, 25 October 2018 (UTC)


 * I like it. It's sad that the locks are only displayed at the end of the page loading cycle though, and I too, think it should be turned on for everyone. It's pointless if it has to be enabled first. I don't know the pros and cons of using a gadget versus just dumping it into our common style and script files though, but I'm guessing we can move it further up the loading phase if we would, not sure. – [   ] 13:29, 25 October 2018 (UTC)
 * Also, I really think all the different types of locks should appear as separate ones. Show a separate lock for the move protection, and another for file protection, etc. This makes sense, because they can happen at the same time, but otherwise building a "tree" hierarchy of these colours would be confusing. – [   ] 13:33, 25 October 2018 (UTC)


 * Considering the original intent of the discussion was probably to have these on by default, I've now made the gadget so that it's automatically installed for everyone, but registered users can still disable it in their preferences.-- undefined 13:52, 25 October 2018 (UTC)


 * I haven't checked out the locks yet because there is nothing to toggle the gadgets in the mobile version. Is the lock texture the one for "Lock Difficulty" button in the game? If so, how do I change them to my sweet, sweet locks, because I am still wondering if I am able to make my own version of the gadget? Anyway, you seemed to have done a great job on this. :) ( | ) 15:12, 25 October 2018 (UTC)


 * P/S: If I can make my own version then I may implement some of my humble ideas. Those are not yet very clear in my mind to be spoken out, though. ( | ) 15:20, 25 October 2018 (UTC)


 * PP/S: I have reviewed my locks and the criticism about "the antialiasing and the black border just don't fit in Minecraft at all". I will redraw them tomorrow or so so that there is no anti-aliasing. ( | ) 15:34, 25 October 2018 (UTC)


 * OK, so I've forked my own version of the gadget and have my locks there instead. You can see them here:.
 * However, I think there should be more states for the indicator. For example the template, there is a lock version called which indicates that the template cannot be edited by anyone except Administrators.  It is also similar for.
 * And I am thinking of adding some more features to the gadget. You can always check out my version here:.
 * ( | ) 03:36, 26 October 2018 (UTC)


 * the deletion of . The locks are definitely better, because unlike the template, the locks show the type of the protection. 05:12, 26 October 2018 (UTC)


 * I posted a minor script improvement suggestion on the . – [   ] 17:46, 3 November 2018 (UTC)


 * with the help of Jack and ATCN.-- undefined 21:50, 3 November 2018 (UTC)

Collaboration needed on page
Currently, I am writing. The tutorial is on an advanced level, and one funny thing is that this is the first time I have ever touched on 's resource pack.

I am trying to inspect the default resource pack to describe the work in a way that is as useful and detailed as possible. However, there are things in the creative aspect that I cannot write about, so I need someone to help me in the creation of this page.

Thanks. ( | ) 12:18, 26 October 2018 (UTC)

I Bought Minecraft Java Edition in 2011 or 2012, so how do I get my Free Windows 10 Edition?
The Windows 10 Edition page (the main one) says that people that bought Java Edition prior to 10/19/2018 get the Windows 10 Edition for free. How do I claim it? My Minecraft username is Goat__Man. If this deal is a fake or is outdated, is there any way I can get Java Edition on Windows 10? I couldn't find an answer to either on the Internet. Thanks, -- 22:46, 26 October 2018 (UTC)


 * I'm sorry to say the wiki is not owned or managed by Mojang, so we can't provide sales and technical support. I'd suggest using the Support link in the bar on the left side of every page. – ( &middot; ) 23:15, 26 October 2018 (UTC)


 * You have to buy it after Minecraft Windows 10 has released and before 19/10/2018. If you are sure you meet those criterions, log on to your Mojang account page and look for your Minecraft Windows 10 gift code. ( | ) 01:12, 28 October 2018 (UTC)

Texture Update changes on &sect; History?
Should every iteration to the texture changes be documented in the history section of articles? For example, add "changed texture" on everything for 43a and then add that again for stone, sand, cactus, etc for 44a. –   19:06, 31 October 2018 (UTC)


 * Previously, every texture change was recorded. But the is a huge one. I think we should follow how we did to .--   01:27, 1 November 2018 (UTC)


 * Perhaps a history section could be used on the page tracking all the changes?   04:32, 1 November 2018 (UTC)
 * I think that would be good. –   04:53, 1 November 2018 (UTC)


 * &#8203;. This will take a long time, but worth doing. Maybe we can at the same time add to each article.  ( | ) 13:37, 1 November 2018 (UTC)


 * What do you mean, add the flattening to sll articles? every flattening change is already listed for all blocks and items; I’ll go through the sounds, biomes and alike at a later date though. But I’m still unsure what you’re referring to, what’s left to add to those pages?  23:19, 24 November 2018 (UTC)

Sort History editions by date of first addition
I think that the editions in history should be sorted by date of first addition – if it was in Java first, put Java at the top; if it's in pe first, put PE at the top, etc. Just so people know roughly the chronology of the additions. –   23:20, 31 October 2018 (UTC)


 * . I've always thought this, but was too shy to say anything. Seems like a good way to honor whichever edition first hosted the innovation. –  |  01:23, 1 November 2018 (UTC)


 * &#8203;. I don't think people really care about that small detail, instead it will make the editions harder to locate. ( | ) 13:40, 1 November 2018 (UTC)
 * , while this would be chronologically more correct, it would be maybe a bit confusing for readers. 15:03, 1 November 2018 (UTC)


 * , and sorry. I believe the editions should always be in a defined and consistent order. The order in which content was added to multiple editions can already be deduced from looking at the dates. But the tables for each edition can become very long on individual pages, making it difficult to find a particular edition of interest to the reader like others said above. Sorting editions to date of content will not help more than keeping them in consistent order would. – [   ] 11:14, 3 November 2018 (UTC)


 * per Jack McKalling. - ( 12:40, 3 November 2018 (UTC)

Citation needed and verify
These two templates seem very similar. What's the main difference between them? 15:20, 1 November 2018 (UTC)


 * I'd say the difference is that verify is used for asking for testing generally, while citation needed is for things that would actually need a citation (such as the claim about the creator of spleef in ). -- 15:39, 1 November 2018 (UTC)


 * I use verify for things that don't necessarily need a citation but might not be true. For example, verify could be used to check that cactuses don't grow if there is a block obstructing its path in Bedrock. Citation needed could be used for a statement telling what the last minecon Notch spoke at was.  20:44, 2 November 2018 (UTC)


 * Basically both templates are used to request verification of the correctness of content, but the verify one doesn't ask for an actual citation source to prove said correctness. – [   ] 11:09, 3 November 2018 (UTC)

Use of issue list
Originally brought up on but got no replies, so I  thought I should bring this here as this affects all pages:

The template issue list doesn't seem to be necessary. No-one uses the wiki to report bugs anymore so it's useless having this in articles. It might have been useful 6 years ago before the bug tracker was created and the wiki was used to report bugs but everyone knows about the tracker now and adding this template to pages doesn't add any encyclopedic value. –   03:27, 2 November 2018 (UTC)


 * Allegedly, the template originally was able to expand a list of issues inline (there was some way to expand it and make a table?), but then that broke. If it were able to do that, it would definitely be at least slightly useful, but I agree that it's not too helpful in its current state (other than for things where there might be multiple search terms). --  03:30, 2 November 2018 (UTC)


 * Agreed. –  |  13:04, 3 November 2018 (UTC)


 * I don't really like seeing it on every page myself, but it isn't really true that "everyone knows about the tracker now". There are new owners of Minecraft all the time, and we can't know whether they'll discover the wiki before they learn of more appropriate sources of support. Plus, there are still people who edit articles to mention bugs (I saw one just today, in fact). I'm not sure that removing the templates would result in an increase in these unwanted edits, but having them might discourage it. Before we do the massive work, maybe it would be smart to try it out on a few pages, especially those for persistently buggy features? – ( &middot; ) 21:05, 3 November 2018 (UTC)


 * Cleaning up this equals to cleaning up a now obsolete section. ( | ) at 3h44 | 10/11/2018

Loot chest per-item summaries as tables instead of prose
Several users have been unsatisfied with the often complicated/messy prose on item pages' Natural Generation sections, which is the output/fault of template LootChestItem. mentioned it could be done as tables, as they do it on the French wiki, and brought to our attention (in the #wiki channel on Discord) some innovations in which  had put together. Compare vs, or for a more complicated/messy example,  vs.

I translated the relevant functions; see a few samples at.

So what do people think, should we do these things as tables instead of prose? –  |  14:50, 4 November 2018 (UTC)


 * Big support for this. It's much, much easier to find what you're looking for than having to parse all that repetitive text. I don't remember where it was now, but I once saw a case where the template output was unbearably hideous and I wanted to fix it, but when I found out it was a template I forbore because I didn't have time to learn how it worked or how my fixes would affect other pages. I'm curious, though: Why is there no Java Edition heading? It makes Bedrock Edition look like an exception. Also, there's an unexpanded in your sample page, probably just a typo I'd guess. –  ( &middot; ) 15:02, 4 November 2018 (UTC)


 * There's no Java heading because Bedrock was a relatively recent addition to this template, and yes that could be an improvement, I would support that. The exact same issue occurs in the text version and in the table version btw. Good pointing that out. –  |  18:20, 4 November 2018 (UTC)


 * Support, especially because I see how horrible the current description on the Armor page is. -- 15:23, 4 November 2018 (UTC)


 * . Auldrick worded this much better than I could, but for module-generated info such as this, prose looks so messy and choppy; using a table instead would be a significant improvement.-- undefined 15:24, 4 November 2018 (UTC)


 * I think it would be helpful if the template also generated a single line of prose before the table, e.g. "Apples can be found as loot in chests in the following locations:". Without it, you have to study the table for a bit to realize it's about chest loot. Also, the table makes me realize there are differences between Java and Bedrock (and question whether these differences are real). That's something I never would have noticed in the prose form, so one additional benefit of using tables. – ( &middot; ) 15:43, 4 November 2018 (UTC)


 * Good idea I think. The percentage chance differences bw Java and Bedrock are mostly because of different items elsewhere in the loot tables throwing off the weights, and only occasionally because of actual different drop chances. –  |  18:20, 4 November 2018 (UTC)


 * One more idea: Allow the Item column to be suppressed. In typical cases, it would only contain the item that the article is about, so it's just redundant and takes up space unnecessarily on mobile devices. – ( &middot; ) 15:50, 4 November 2018 (UTC)


 * Sounds good to me. –  |  18:20, 4 November 2018 (UTC)


 * tables. But please make them sortable. When the list gets very large, it'd be helpful if you could re-sort the table by name, percent, structure, etc. I've had troubles with this loot chest output before, where multiple variants of the title item were available under different circumstances among different game platforms, but all resulting in almost the exact same sentence 10 times. Really unhelpful. – [   ] 19:50, 4 November 2018 (UTC)


 * Someone may have to put a slight bit of thought into how to sort the table without losing edition and version differences. Sort to see what i mean. Maybe each version/edition gets its own table? –   |  21:17, 4 November 2018 (UTC)
 * Yes each edition its own table. Probably the best to do, if reasonable. – [   ] 21:39, 4 November 2018 (UTC)

Currently, edition / version differences are differentiated as if Java were the main version, and then some exceptions for whatever is different in Bedrock and upcoming versions. The module's loot tables aren't structured that way actually, so it actually introduces all kinds of complexity to boil it down from the full loot tables into the current form, which even if you ignore the Java-centrism, still leads to no end of ambiguity as to how to read all those versions taken together. It would be simpler to just display full tables, one for each different edition and version. Just an update on my thoughts. –  |  19:03, 5 November 2018 (UTC)


 * Are you thinking of it more as a list of tables with edition headers, or a list of edition section headers with one table per section? Are there any advantages either way, or are they entirely equivalent? (The section headers would appear in the TOC, but whether that's advantage is unclear. Some TOCs are already kind of cluttered.) – ( &middot; ) 19:10, 5 November 2018 (UTC)


 * The first one. –  |  21:10, 5 November 2018 (UTC)


 * But make the table transparent so that the readers' eyes won't be hurt. ( | ) 14:50, 6 November 2018 (UTC)


 * The default wikitable style is white background, and it's on the majority of tables in the wiki; is it a big issue? If it is, maybe raise a separate topic ..? –   |  16:56, 6 November 2018 (UTC)


 * Eh, I just thought a big table should be less bright compared to the whole page. ( | ) 01:15, 7 November 2018 (UTC)


 * How are we planning to organize the table? That means, what will the table look like in general? ( | ) at 3h53:37 | 11/11/2018 (UTC)

Any way to overlay one image on top of another in an infobox?
I'm thinking for the page we could have seperate images for the collars in the different colors displaying over the images of the skins, this way each skin will be seen with several different collar colors as the animations go on. But can it be done? If not, could a method of doing this be added? –  07:04, 7 November 2018 (UTC)
 * I don't see any simple solutions to do this but you could try a scuffed way similar to with negative margins and stuff. –    07:13, 7 November 2018 (UTC)
 * I would not recommend doing this. We already have an animation for looping through all the different cat types, it'll become a mess that isn't done before on any other page if we then loop through all collar colours for each one. Regardless of technique used. The red collar should be enough really. – [   ] 08:15, 7 November 2018 (UTC)

Make the "News and events" icon in the main page dynamic
Currently, the 's "News and events" section has an icon which resembles a calendar of 11/2011 and displays the date 6 | 18/11/2011 (although it actually displays Saturday). Since this is severely outdated, I have made a new version of the icon which you can check out in my version of the main page:

The actual font size of the month text ("/" at the moment) is 7px, depending in your browser, the size may be limited to a minimum number, which makes it larger and displaced.

( | ) 13:56, 9 November 2018 (UTC)


 * Nice idea. I copied parts for the german . And I cleaned the code a bit. - Wiki Admin 14:42, 9 November 2018 (UTC)


 * Proposed to . ( | ) at 3h40 | 10/11/2018 (UTC)

Status update: DESTROYED (per ). ( | ) at 14h28:06 | 12/11/2018 (UTC)

Put information pre-addition in prose
At the moment, any time the feature was mentioned prior to addition, it gets pushed into the table. I don't think this is the best way of doing things, especially on features like the lectern or lantern that have a ton of history before addition. I feel this would work better in prose above the table. For example, see (which has a ton of inline external links that would work better as references), and compare it to. It has a ton of links there that shouldn't be grouped in with the versions. –   18:34, 9 November 2018 (UTC)


 * I think the implementation history should be something to describe the statements in detail. ( | ) at 3h37 | 10/11/2018 (UTC)


 * , this makes sense, as each external link entry is not an actual history item, but more of a "historic message".  Do you suggest to modify all used history tables that have external link entries to pre-implementation information, or are you talking about a specific subset of pages? –  [   ] 10:33, 13 November 2018 (UTC)
 * Yes, everything with a version title of "month day, year" andan ext link should be moved into prose and leave the history template for changes ingame. –   02:37, 14 November 2018 (UTC)


 * . The information related to the external links are still part of history, and extracting it from the table and leaving it as prose above does not help the flow of the page. It would make the page less readable. However, if the text were rephrased to state exactly the information, it would be a lot better. For instance, the page shows how these external links can be well-phrased, and are easy to the eyes. In contrast, the  page does not. It is too messy, clunky and the text is not straight to the point. This argument was mentioned to me by . Paraphrasing here in her name, because I think it is a very valid point. –  [   ] 19:55, 15 November 2018 (UTC)

Getting error upon attempt to upload 80-frame gif file. Please help!
I made renders for the different cat breeds with different collar colors and threw them together in an 80-frame gif, meant to be used on the page for s in place of the cycling images displaying the different breeds all in red collars. However, I cannot seem to upload this file, constantly getting a "500 Internal Server Error, openresty/1.13.6.2" error upon attempting the upload.

If anyone has a fix for this issue, please let me know! –  13:29, 12 November 2018 (UTC)
 * It's a global Gamepedia issue, Gamepedia is aware of the issues and hopefully will fix it soon.  13:37, 12 November 2018 (UTC)


 * Oh, okay! Thanks for the information, I thought it was just gamepedia disliking the size of the gif file or something haha –  13:39, 12 November 2018 (UTC)


 * Seems to be fixed now. -- (undefined/undefined) 14:45, 12 November 2018 (UTC)

Sonicwave32 for admin?
We have needed more admins on MCW for a while now, and one of the few candidates I've seen that I really thought would make a really great admin is. Sonicwave joined the MCW in 2014, long before I did, and has since improved the MCW in a huge variety of ways, whether it's making basic copy-edits, adding sound files, or correcting/adding information. However, Sonicwave's primary area of focus is vandalism fighting. Many great qualities I've noticed about Sonicwave32 is that he always leaves clear edit summaries when making edits, is absolutely wonderful at communication, and never newbies.

So why should Sonicwave32 to become an admin? Well, as I mentioned, he's a wonderful vandalism fighter. In the event of a persistent vandal, he would be able to block them himself rather than wait for another admin to get to them. He knows exactly what is vandalism and what is not, as well as to give users friendly notices when they are making disruptive edits but acting in, so I'm confident that he can be trusted with the block button. In addition, Sonicwave32 is experienced and accurate with tagging pages for deletion, and has always been a backlogged area. From what I have observed, Sonicwave has great judgement, is experienced, and is "clueful." I believe that Sonicwave would make a great admin, and thus him, and I hope that the rest of the community feels the same way.

Sonicwave, if you would like to add something, please do so, or if I missed something, please let me know.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 21:23, 20 November 2018 (UTC)


 * Thanks for taking the time to write this out, and I accept this nomination. – undefined  02:38, 21 November 2018 (UTC)


 * While I admit I'm not really a regular user on this wiki, I would like to point a few things that I feel are important.
 * I'm not quite sure Sonicwave is active enough recently to solve by himself the issue about the lack of admins... While I don't disagree that he may be a good candidate for the role, this wiki really need a more present admin team. Thus, it would probably be a good idea to look at all the possible candidates — and I have to disagree with you, there is a bunch of editors here who would make some excellent admins! So, if the community want more than one additional admin, well, Sonicwave would definitively be a good candidate and I of course support him, but others should also be considered!


 * Regarding that, I would like to point out that seems another really solid candidate to become admin on this wiki, and I really think the community should also discuss to promote him as well. With his impressive knowledge of the game, his important contributions and his general motivation, he is definitively someone to think about for the role. I know some could be concerned about a bit of edit warring, and we should absolutely encourage him to improve himself on that aspect — but despite that, he's still someone who would really help the wiki if promoted. Promoting both of them could be a good way to resolve the lack of admins issues.
 * On another subject, the promotion system seems a bit ineffective right now... If the wiki is needing more admins for a while, without anything done to address the issue, perhaps it would be interesting to make a new system for the promotions. A Request for Adminship system is the most common elsewhere, this wiki should perhaps think about it (or something else). But anyway, that's not the point.
 * So this is my contribution to that subject. I hope I will have brought an helpful point of view for this discussion.   04:17, 21 November 2018 (UTC)


 * So you propose we implement sophisticated systems for tasks which, until now, have been served well by simpler equivalents, with no apparent substantial drawbacks? And yet you complain that Minecraft Wiki is bureaucratic? -- 07:18, 21 November 2018 (UTC)


 * I'm suggesting this wiki is reviewing its process, to make sure there is always enough admins to do the tasks on this big wiki. By encouraging people who are interested to become admin to identify themselves instead of this weird habit of choosing them when it's really too late, we could resolve a lot of problems. I'm not suggesting a RfA is the best system, of course, simply one who have been successful elsewhere. And for me, having new bureaucratic system is not in itself an issue; having some that are useless or used abusively is however. In this case, the goal would simply be to set clear rules and process on how promotion should work here, to make the process more fair and open to all. (I suggest that if you want to further talk about this, you should open a new section instead, to give a proper place for the community to answer on this subject.)  15:44, 21 November 2018 (UTC)


 * I don’t object to being nominated. :)  10:20, 21 November 2018 (UTC)


 * of being admin. He is doing great anti-vandalism work and might also be trusted with the "block" button to block vandals. --Wikipedia-logo.png ( • ) 09:58, 21 November 2018 (UTC)


 * I don’t object to accepting both Sonicwave32 and FVbico. I don’t recall any problems with either users, at least when I had been actively observing the English wiki. — ( | ru.Wiki Admin) 14:58, 23 November 2018 (UTC)


 * against Sonicwave getting the admin flag. -- 15:58, 23 November 2018 (UTC)


 * why not? =^^=  01:19, 24 November 2018 (UTC)


 * Per the above discussion, and given it's been several days since the last comment, I've Sonic to admin. 「」undefined 03:59, 28 November 2018 (UTC)

Page protection locks gadget: New padlocks?
Wikipedia has implemented a set of new padlocks to signal page protection, the reasons behind this implementation are in the RfC in the first link. Should we implement these same padlocks for our gadget? -- 14:47, 21 November 2018 (UTC)


 * , would definitely be easier to tell what type of protection was applied at a glance. – undefined  05:43, 22 November 2018 (UTC)

One thing I didn't think of: we use the black padlock to signal a level of protection which doesn't exist on Wikipedia; if we're going with the new Wikipedia padlock approach, we'll need someone willing and able to edit a vector image for us. -- 07:31, 22 November 2018 (UTC)


 * About the SVGs, I believe I can modify the thing. ( | ) at 14h25:41 | 30/11/2018 (UTC)


 * Here is my proposal for the director protected icon:


 * Director protected proposal.svg


 * ( | ) at 13h44:28 | 1/12/2018 (UTC)
 * I think you should remove the white design elements and make the letter substantially thicker. This icon is going to be used in 25px resolution, where the white design elements aren't visible, and the D is visible just barely; see it for yourself — Director protected proposal.svg. -- 14:06, 1 December 2018 (UTC)


 * Here is version 2 with thicker lines:


 * Director protected proposal 2.svg Director protected proposal 2.svg


 * ( | ) at 14h30:53 | 1/12/2018 (UTC)


 * ...or with just a D:


 * Director protected proposal D only.svg Director protected proposal D only.svg


 * ( | ) at 14h33:30 | 1/12/2018 (UTC)


 * The lines don't actually add any useful information for the readers, and they make the D (which is more or less useful information) less legible, so yes, I support the third version. -- 14:47, 1 December 2018 (UTC)

More opinions
I've been patrolling the deletion category and deleting/untagging what I can, but I would like to have some more opinions on the following pages before making a decision, because I'm really not sure if they should be deleted or not: If possible, I'd appreciate some of y'all helping me come to a decision on some or (preferably) all of these so that we can eventually empty the deletion category. Thanks, -- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 00:31, 24 November 2018 (UTC)
 * (redirect to, may be a useful typo because there is no 1.4.3 but there is ) . Kept and changed to redirect to instead per discussion below
 * and (both tagged for deletion as old and outdated custom servers)
 * ,, , , and
 * and (both tagged for deletion as old and outdated mods)
 * (tagged for deletion because the page is outdated and it already has an official wiki, but it's not a Gamepedia wiki)
 * (tagged for deletion as superfluous disambig)
 * ,, , and (tagged for deletion as unnecessary redirects) ; deleted per below
 * 1.4.3 should be kept as in-game he f3 screen doesn't say "pre" –  Grid Book and Quill.png Diamond Pickaxe.png 01:01, 24 November 2018 (UTC)
 * The launcher also uses too despite being a pre-release.--   10:46, 24 November 2018 (UTC)
 * do you think it would be better to redirect to instead then?--  Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 15:11, 24 November 2018 (UTC)
 * By the way, I think that "" should be renamed and redirected to "1.4.3 (Pre-release)". -- 15:15, 24 November 2018 (UTC)
 * Yeah since in-game that's all it's known as. –  Grid Book and Quill.png Diamond Pickaxe.png 18:15, 24 November 2018 (UTC)
 * Alright, . I've modified the target of the redirect, removed delete from the redirect, and struck through the 1.4.3 bullet point in this post with an explanation. Thanks for helping me out with this!-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 18:38, 24 November 2018 (UTC)


 * I went ahead and deleted the talk page redirects and it seems pretty uncontroversial. Feel free to scream at me if you have any objections. :-)-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 02:35, 27 November 2018 (UTC)


 * Anyone want to comment on this? Bumping this discussion.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 19:25, 5 December 2018 (UTC)


 * I don't really have anything to say, the deletion reasons are valid, and I see no real reason to keep them.  19:30, 5 December 2018 (UTC)

Some suggestion about private issue description rule
To settle about yesterday, I have the following suggestions on the : -- 14:01, 24 November 2018 (UTC)
 * For security issues mentioned on the official change log, use the title from the change log, since it has been disclosed by Mojang.
 * For security issues NOT mentioned on the official change log, use “private security issues (involving...)” instead.


 * I would that. If the issue fix is something Mojang's okay with having on an official change log, then I don't see why it can't be revealed on the wiki. Maybe we should add this to the style guide?--  Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 14:02, 24 November 2018 (UTC)


 * . -- 14:04, 24 November 2018 (UTC)


 * Also, for security issues mentioned on the official change log, use the title from the change log with ref to the change log, influenced by, and . --  14:06, 24 November 2018 (UTC)


 * . - ( 15:57, 24 November 2018 (UTC)


 * . For some issues, I think it's definitely fine, but I'm not sure about whether it's a good idea to include it for all issues.  My general opinion on it is that for issues that only affect snapshots, it's fine to include it; for ones that affect releases more care must be taken (but it also varies on the issue; duplication issues I think are generally safer to make public, but that's only my stance).  I should also note: I'm generally in favor of making private issues public eventually, though that hasn't really happened on the tracker.  I should probably look into that again; the super old issues for 1.8 and the like probably can be made public at some point...  (n.b. I am a bug tracker moderator, so I have access to the details of these reports, which does mean I have additional context others don't have) --  18:09, 24 November 2018 (UTC)


 * Like Pokechu, I'm a moderator on the bug tracker. I want to mention a couple of things for consideration.
 * 1) There are 2 reasons we make bug reports private: Either they contain personal information, or they describe an exploit. I believe the intent of the rule is to avoid giving publicity to exploits, but editors generally wouldn't be able to tell which reason applies (and both could apply simultaneously). If necessary, editors could ask one of us for a publishable description of a bug.
 * 2) There are some reports that we make public despite describing an exploit. This is generally when they are already published on YouTube or Reddit and we therefore anticipate them being reported many times. We encourage users of the bug tracker to search before submitting a report, but they can't find a private report that way, so we make it public to try and avoid a lot of duplicate reports. Thus, "public" ≠ "not an exploit".
 * I don't think it's a good idea to publish exploits on the wiki at all, regardless whether they're public or private. They can absolutely ruin the game sometimes, especially on multiplayer servers. (Examples include disruption of a server's economy, invincibility during PVP, and surrounding a player with illegally obtained bedrock to extort, coerce, or disable them.) So maybe the rule should prohibit mentioning a bug's exploitative aspect instead. For instance, if the had said merely "Shulker boxes can't be dyed" and left out the duplication effect, it needn't have been reverted.
 * For these reasons, I suggest that the rule should focus on not promoting exploits, instead of whether a bug report is public or private. – ( &middot; ) 13:47, 27 November 2018 (UTC)
 * I think that Java Edition “fixes” section should be consistent with Bedrock Edition “fixes” section to solve this problem.  05:14, 29 November 2018 (UTC)

Sound file licensing
Do all non-music sound files need to be licensed as License C418, or is License Mojang sufficient for some of them? If it's the latter, which cases are these? -- 21:18, 1 December 2018 (UTC)


 * Many sounds are creative commons licensed (the exact one varies though); see the sound attribution page. --  21:37, 1 December 2018 (UTC)


 * Are the CC BY-licensed sounds specified as such on the wiki?
 * Are the non-CC BY-licensed sounds all C418-licensed? -- 21:56, 1 December 2018 (UTC)

When do we describe bugs in articles? Pt. II
I'd like to reopen the discussion at since it doesn't really reach a consensus. I just came from a discussion about some unexpected parrot behaviour that I thought the wiki would have informed me about. I couldn't add it because the page was locked, and a user dismissed my request because it seemed too much like a bug. I've been describing things that could be suspected as bugs whenever I encountered them, treating the wiki as "this is how the game is", but maybe I misunderstood the goal of the wiki? 00:04, 3 December 2018 (UTC)


 * When we characterize ourselves as describing "how the game is", we don't mean that to contrast with "how the game isn't, but rather with "how the game is now" versus how it used to be or how it might be at some point in the future. It's intended to remind us to remove information that's obsolete, or at least to clearly mark it as such, and also to avoid treating mere rumors about upcoming changes as real information.
 * With respect to bugs, we only acknowledge a bug if it has been around for a long time and Mojang isn't actively planning to fix it. The reason is that we don't want to mislead people into depending on behavior that's likely to change in an upcoming release, and also because it's highly possible that nobody would remember to remove the bug description after the bug is fixed, at which point it would become misinformation.
 * I also took a look at your edit history to familiarize myself with the behavior you're talking about and saw what I assume is you say you just came from. To summarize, the other editor described the behavior as (paraphrasing) "parrots wouldn't follow or teleport to me while I was in an Ice Spikes biome". Then they jumped to the conclusion that "parrots […] become lethargic in a cold biome". You, in turn, appeared to accept that reasoning. The problem is that this conclusion is a generalization that doesn't automatically follow from the behavior. The assumption could be wrong: Maybe it doesn't happen in all cold biomes. Or the conclusion could be incomplete: Maybe it happens in some warm biomes, too. It's also possible that the true explanation is based on something completely different: Maybe a bug is making you untrackable by any mob when you're standing on ice. There's no way you can generalize from a specific event to a behavior description without making some assumptions about Mojang's intentions, and no way you can validate those assumptions unless you have access to the code base. Consequently, any generalizations of this type from non-Mojang staff have to be treated skeptically unless there's a very convincing argument. –  ( &middot; ) 06:07, 3 December 2018 (UTC)

Request for Comment: Get rid of change log collections on Development Version subpages
At the moment, a query grabs all articles for a particular release version's development versions and transcludes most of these articles on a single page. There was a time when a single page was enough for complete change logs for all development versions, this was obviously not acceptable as a permanent solution. Apparently, keeping such complete change log collections on a per-version basis was deemed enough of a compromise to avoid scrapping change log collections entirely in favor of a single, minimalistic list. In this request for comment, apparent issues with the current approach are described, and a resolution is proposed.

It is questionable that such collection pages are substantially useful for readers. Releases contain substantial numbers of snapshots, with many changes in each snapshot, and this often results in incredibly large pages where needed information is hard to find. The feature that would mitigate (not significantly) this navigational difficulty is the built-in browser search (Ctrl+F in desktop Mozilla Firefox)... however, it's very possible many readers aren't aware of this feature. This paragraph does not even consider mobile devices, where the pages and/or the search feature may be even less usable. As an extra note, bandwidth and client performance may be a concern assuming non-text content gets transcluded from many individual version articles at once.

As a result of this approach, editors who contribute to snapshot articles are expected to properly insert  tags into snapshot articles to avoid breaking the collection pages. Beyond that this is not something obvious to beginning editors, it is not even documented where exactly should these tags be placed, and in a recent incident, a user attempted to have the tags contain the video section, resulting in a mass revert.

Additionally, collection pages require a system of complicated templates and categories which has to be maintained by more technically capable editors. The complexity of this system could be substantially reduced by removing collection pages. (An even less substantial issue is that some automatically generated lists will list the development versions collections as well as the version articles themselves, resulting in somewhat inaccurate category/list population counts.)

Proposal:
 * 1) Decide whether to keep change log collections or to get rid of them.
 * 2) If it is decided to keep the collections, the placement of   tags in individual version articles will need to be documented.
 * 3) If it is decided to delete the collections, details of the deletion procedures will need to be discussed.
 * 4) Decide whether to replace minimalistic version lists on the per-edition development versions pages with more informative versions.

-- 18:54, 3 December 2018 (UTC)


 * There's not really much point in them. Want a list of all features? go to the 1.x page. Want to look through the specific snapshots? Go to YYwWWn and click the link. –  Grid Book and Quill.png Diamond Pickaxe.png 19:01, 3 December 2018 (UTC)


 * I use these pages. The main reason why is to find (using Ctrl+F) what snapshot a behavior was added in (usually so I can test bugs related to that feature, but others would have a different reason to do it).  These pages are the most convenient way to do this, since that information isn't in the full article and the specific things I'm looking for generally aren't in the history section of an article (e.g. options changes).  That would probably be solved by a more complete history section in those articles, but that's my current use case. --  19:08, 3 December 2018 (UTC)


 * I like the collection pages. They are specially useful, if you search for a change but don't know in which snapshot it changed (e.g. research for an history entry). Without the collection you would need to click through all 40+ snapshot pages.  HorseHead.png GRASP logo.png   19:12, 3 December 2018 (UTC)


 * There's not a single link to one of these collection pages in this topic, nor is one of them even named. I'm left wondering if I've ever even seen one of these; I don't remember ever seeing a giant version-related page full of transcludes. (That might be because I don't often concern myself with Java history stuff.) Are these pages actually linked on the wiki, or are they only available by typing a secret URL? – ( &middot; ) 20:11, 3 December 2018 (UTC)
 * . Clicking "view all" in the infobox on any 1.x page. –  Grid Book and Quill.png Diamond Pickaxe.png 20:17, 3 December 2018 (UTC)

Thoughts on adding the "Java Edition" prefix to version pages
Now that this has calmed down a bit, what are people's thoughts on prefixing version pages with Java Edition? I, personally, am on this. –   21:04, 20 December 2018 (UTC)
 * Pros: Doesn't look like we have any bias, less confusion (in the long run; especially since bedrock version numbers are catching up to Java and we're gonna get to the point where it's "upcoming 1.17 and Bedrock Edition 1.17").
 * Cons: Have to move a whole lot of pages.


 * moving pages.  on changing upcoming template behavior to include "java" prefix which would reduce confusion in that case. --  21:13, 20 December 2018 (UTC)

Simulation distance
A while back the Options page contained the information about the technical details about the render distance sliders (increment info, # of chunks, such as: 2x increments starting at 6 chunks max 16-24 chunks, 4x increment starting at 8 chunks max 28-48 chunks etc). It's been removed and I copied that data over to a different page.

It's come to my knowledge that the simulation distance slider also varies with device just like render distance.

1 device has the simulation distance slider in 2 step increments starting at 4 chunks and ending at 8 chunks, another device has 2 step increments starting at 4 chunks and ending at 12.

Does anyone have the specific technical info about the sliders for the Simulation distance? Specifically the increments, starting number and max range of chunks.

Something like this:

Simulation distance chunks

and so on so forth

01:51, 25 December 2018 (UTC)

Features with different names for different editions
Some features have different names depending on the edition. For example, the block called “nether brick block” in Bedrock Edition is called “nether bricks” in Legacy Console Edition and “nether brick” in Java Edition. Currently, we use the name in Java Edition for the title of the page (e.g., the page about nether brick blocks is called “Nether Bricks”).

A few years ago, the Java Edition was simply called ‘’Minecraft’’, so it was reasonable to choose the Java Edition as the “default” Edition. However, since the Better Together Update, the Bedrock Edition was the edition that is simply called ‘’Minecraft’’. It is therefore reasonable to consider the Bedrock Edition the “default” edition.

For features with different names for different editions, we should move the pages so that the page titles would correspond to the Bedrock Edition name rather than the Java Edition name (e.g., would be moved to “Nether Brick Block”. Paper.png 15:51, 31 December 2018 (UTC)


 * . We should also rename other pages like ' to ' to make it persistent with other pages. once moved it, but it was quickly reverted by  and the page was protected. [ According to him], the name "Top Snow" is not an official name and should be discussed. --   16:26, 31 December 2018 (UTC)


 * That was what I could tell at the time. I don't have access to any Bedrock Edition release of the game, so I can't check names for myself. I will note, however, that to my knowledge, since that happened, no one else has come forward even claiming without proof that the BE name for Snow is Top Snow (though I'd be happy to be proven wrong, on either count here).
 * For the proposal itself, I support documenting alternate official names as a matter of course, but am ambivalent towards which edition to consider the "main" edition or whether to rename pages to reflect that. 「」undefined 16:35, 31 December 2018 (UTC)


 * . Without getting into ideological concerns, the 1.13 brought about, which modernized and organized names.  To my understanding, bedrock has not yet had that.  Thus, the names from 1.13 should be considered more final. --  19:02, 31 December 2018 (UTC)


 * per Pokechu22. - ( 19:03, 31 December 2018 (UTC)


 * prr Pokechu22; additionally, we have confirmation from HelenAngel that bedrock will fillow the 1.13 names sooner or later (ie smooth sandstone is already renamed to cut sandstone as well.  19:26, 31 December 2018 (UTC)


 * . I propose having it so that the name that is in more editions is the name of the page so we don't have any version bias. For example, would stay there since it's used in JE and LCE but not BE but  would be moved to  even before 1.14 is released. –  Grid Book and Quill.png Diamond Pickaxe.png 19:42, 31 December 2018 (UTC)
 * No two editions have the same term for nether brick blocks, so your idea would not work universally. Paper.png 19:45, 31 December 2018 (UTC)
 * In that case the edition that has had the feature added first may have the priority, so as a result Nether Bricks would retain their name. — ( | ru.Wiki Admin) 20:03, 31 December 2018 (UTC)