Minecraft Wiki talk:Style guide

Italics
I think we need to add a part that says that Bedrock Edition and Legacy Console Edition should not italicized. While other versions need. Skylord wars (talk) 00:06, 2 February 2018 (UTC)


 * --Orange Glazed Terracotta.png Madminecrafter12 Talk • Contributions 14:13, 24 February 2018 (UTC)


 * Well on the main page, most editions name are already italicized. Well, I still think "Legacy Console Edition" should be named as "Legacy Console Edition". See Talk:Legacy Console Edition--Skylord wars (talk) 14:26, 24 April 2018 (UTC)

Move the page to Minecraft Wiki:Manual of Style?
Hello. I think this page to be moved to Minecraft Wiki:Manual of Style to match Wikipedia's title, instead of Minecraft Wiki:Style guide. A redirect can also be created from MCW:Style guide. --Philip57sundfors (talk) 12:00, 7 March 2018 (UTC)


 * , style guide suits our wiki better. We're a small wiki with not as many people as the big wikipedia, where they need many regulations to deal with so many editors. Here, we just have a guide and that's formal enough IMO. We don't want to dictate and scare away our new editors haha. – [ Jack McKalling ] [ Book.png Book and Quill.png Diamond Pickaxe.png ] 13:27, 7 March 2018 (UTC)


 * : Seems like a change just for the sake of changing it. Style guide is clear enough to state the purpose of this page. – KnightMiner  · (t) 17:47, 7 March 2018 (UTC)


 * . The exact name isn't important here; both "style guide" and "manual of style" communicate the page's purpose just fine, so there's really no strong argument for changing from one to the other. Redirect the redlink and move on. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 23:09, 7 March 2018 (UTC)
 * Redirect from redlink created. – [ Jack McKalling ] [ Book.png Book and Quill.png Diamond Pickaxe.png ] 23:21, 7 March 2018 (UTC)


 * . In my opinion either way works fine, but if the title is already Style Guide, I don't see any major benefit of moving it.--Orange Glazed Terracotta.png Madminecrafter12 T • C 00:51, 8 March 2018 (UTC)


 * “Manual” seems to sound too vast, like the UNIX man system including hundreds of pages. Plus it doesn’t look like a rational change; on both stances I agree with others. Also, “it is done on Wikipedia” can’t be a good argument by itself. —  BabylonAS (talk | ru.Wiki Admin) 17:00, 28 March 2018 (UTC)

New textures in images
When adding screenshots to an article, make sure the screenshots use vanilla textures and UI. Screenshots that use custom texturepacks, UI mods and other custom content are not allowed. Does this apply to the new textures? – Nixinova   07:10, 21 April 2018 (UTC)
 * The rule does not apply when the purpose of the screenshot in question is to demonstrate said custom content. This seems to be mentioned immediately after the sentence you quoted: "This does not apply to articles covering mods."
 * Yes, when this rule was created, nobody could have thought content may be officially developed as an alternative to default data. Even if this case isn't an exact match (the new textures are intended to eventually replace the old ones, and are temporarily offered as a beta release), I think we should clarify this guideline a bit. --AttemptToCallNil (report bug, view backtrace) 07:57, 21 April 2018 (UTC)

“Weaknesses” sections
On some new pages such as Dolphin there are “Weaknesses” sections. I propose that these sections be disallowed, as tutorial information is generally excluded from normal pages. The BlobsPaper.png 22:44, 10 May 2018 (UTC)
 * Definitely part of non-tutorial information in this case. It describes properties of the mob, it doesn't provide instructions as to what to do. In other words,  is fine by itself, and should be in the article. However, if someone added   after the first sentence, that should be removed as "tutorial content". (Yes, these examples aren't Minecraft related at all, but the concept still applies.) --AttemptToCallNil (report bug, view backtrace) 22:57, 10 May 2018 (UTC)

Removal of the "American English" mention
Hi!

I would like to suggest to remove the following line: "Pages on the wiki should use American English unless the in-game name is British English. For instance, “colour” should be “color”, and “centre” should be “center”. " And probably replace it with something way more appropriate, like the text of the help wiki: gphelp:Gamepedia_Help_Wiki:Tutorial/Keep_in_mind. I really think however that it should be clear that the in-game terms of en_US are the one to use on the Wiki, as they are the official language of the game.

Every user should feel free to write the way they learned to, and there is no good reason why to require users to use rules from a particular place or country in the world. We should also avoid to "correct" something good in another region, simply for the sake of correcting.

Of course, consistency is something important, and we should perhaps state that we should spell words (like "center"/"centre") the same way everywhere in a same article. (wp:Manual_of_Style is a good reference on that matter).

JSBM (talk) 01:50, 27 June 2018 (UTC)


 * The in game name part should not be removed as you really need to follow the in game name. The strange thing is, although Minecraft (game) uses American English as their default, Minecraft.net uses British English instead. I with removing the line saying that the wiki should be using American English. skylord_wars (talk) 02:07, 27 June 2018 (UTC)


 * I'm sorry, but to me it makes the most sense to use something consistent throughout the wiki, and American English makes more sense because it's what the game uses. I weakly think that the statement is okay the way it is. However, I do think that it's not really useful to make an edit if it's just to change British English to American English. It kind of just clogs up page histories and recent changes, with little benefit. Honestly, I personally am not really picky on the exact variety of English used - all users can almost always read and understand the other variet(y)(ies) so it doesn't really matter that much imo. I am definitely open to other ideas, and depending on what other responses this gets, I may change my mind about this as well. If we do remove the line, though, which I don't hold any strong objections to, that we should specify when what variety should be used, or if it matters at all.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 02:12, 27 June 2018 (UTC)


 * You can see wikipedia:MOS:ENGVAR as an example. Article names of in game things should use in game name, which is by default American English. Though the contents of the article may contain some bits of other English variants. Tutorial pages should instead be not be restricted. Plus, the English wiki is made up of many English-speaking people, but not all of them are American. Redirects can be made if there are different names. That is why I support the statement to remove that line. We should also add a line redirecting to Gamepedia's Manual of Style. skylord_wars (talk) 02:31, 27 June 2018 (UTC)


 * . Either a potential for potato chip wars or seemingly arbitrary, yet strictly enforced common standard. --AttemptToCallNil (report bug, view backtrace) 13:02, 27 June 2018 (UTC)


 * . As opposed to Wikipedia, the Minecraft Wiki has no region-specific articles, so we can't decide on what variety of English to use based on the Article contents. If we remove that guideline, that would mean that the wiki no longer follows a uniform variety of English. I don't see any profit in that, at all. All it would do is causing confusion. As American English is Minecraft's default language, it only makes sense to have this wiki written in American English. | violine1101(Talk) 17:11, 6 July 2018 (UTC)


 * Consistency in writing style is the goal, and so yes, some single standard has to be adopted. – Sealbudsman talk | contribs 21:48, 6 July 2018 (UTC)


 * with same arguments as mentioned above. Although I'd personally prefer British English as a language, the wiki makes the most sense in American English, and it needs to be specifically one or the other. We're working together with too many people already to allow for such useless conflicts as minor spelling disagreements. Which is what would arrise if we removed that line. There are more important things in life (and here on the wiki) than personal preferences in spelling. – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 09:33, 10 July 2018 (UTC)

Bedrock Edition: is it an official name?
While listed here on the Mojang website as a specifier, few other official sources use this term; in particular, this page doesn't. Editions based on the Bedrock code platform are now simply marketed as Minecraft.

A slow edit war is ongoing where instances of  in articles are italicized and deitalicized. Even the style guide itself had one undiscussed edit which was reverted.

I think we need to determine whether "Bedrock Edition" is to be considered an official name, and consequently, whether it should be capitalized in articles. --AttemptToCallNil (report bug, view backtrace) 11:14, 2 September 2018 (UTC)


 * for keeping Bedrock Edition as the official name. The different editions for different all run on the Bedrock engine and are all commonly known as Bedrock Edition as a consequence. As Bedrock is the official name for that engine, it makes sense to simply have all those versions (or editions, so you like) known as Bedrock Edition officially.


 * I may also note that the Minecraft.net help page is for individual versions on different platforms, as it would be rather difficult to write an article which addresses all platforms running Bedrock Edition (what applies for an Android device usually does not go for a Windows device and vice versa; same goes for the consoles). — DarkShadowTNT  ( t  ♦  c ) 11:38, 2 September 2018 (UTC)


 * Both of you: please stop reverting each other's edits that change Bedrock Edition to italicized or not, until there is a consensus here. You are welcome to comment here, but if the edit war continues, page protection or even short user blocks may be necessary.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 14:26, 2 September 2018 (UTC)


 * As I recall from this discussion, the official name was either just "Minecraft" or "Minecraft (Bedrock)". For the sake of consistency its been called Bedrock Edition on the wiki, but that is not as official as Java Edition or Console Edition. Basically, in most cases they want to drop the "Bedrock" and call it just Minecraft, but for our cases we need the clarification. Since we now have a Mojang link calling it "Bedrock Edition", I say it seems pretty official when referring to all of Bedrock as a whole. – KnightMiner  · (t) 20:06, 2 September 2018 (UTC)


 * Yes, I considering "Bedrock Edition" as an official name. It is not wrong to call each Minecraft edition on those individual platforms, instances of "Bedrock Edition". We're comparing full-product titles with software titles here, which not always correlate, due to a product sometimes containing embedded software, hence the confusion. I would definitely consider Bedrock (in the form of a game engine), as embeded software here. And as such, it carries the name of "Bedrock Edition" as a product name separate from the minecraft game (e.g. "Minecraft for Windows 10") that it is exposing. The reason for that is that Bedrock itself, is unquestionably a product of its own, has its own title, and in that way has nothing to do with the games released for the different platforms that use its codebase. Just like how all Samsung smartphones use "Android" operating system, and that "Android" itself is a name that has nothing to do with Samsung. The only difference being that Bedrock was developed by the same company that released the games.
 * And all this talk about official names and what not, questioning what should be formatted in italics or not, has everything to do with Bedrock being a "Major works of art and artifice", as wikipedia seems to call it. Although not listed there, a game engine meets all the described criteria to be a "major works", and in a different wording, is essentially a product on its own, regardless of it not having been publicly used as a standalone one. It has its own development space, name, version system and codebase, all completely independent from the publicly released products that carry the name "Minecraft" or "Minecraft (Bedrock Edition)". So it should (or could, I don't care about the result of this discussion), be identified as an official title that needs italics. Because this formatting has nothing to do with whether Mojang has officially announced or released Bedrock as a separate product, or whether them using the name is considered "official" or not. – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 12:56, 3 September 2018 (UTC)
 * For reference, "software other than games" (game engines are not games) is listed in wikipedia:MOS:TITLES, where such titles are stated as not to be italicized or put in quotes. --AttemptToCallNil (report bug, view backtrace) 13:54, 3 September 2018 (UTC)
 * But although correct that a game engine is not a game, it absolutely is game software. So it is arguable whether game engines should be defined by that category, and one could very well argue that it should even be renamed to "Software other than game software". It's not really "proof" that game engine names should not be italicized. – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 14:08, 3 September 2018 (UTC)
 * That's not what it says. The proposed change makes quite little sense; it looks like it's done to fit a viewpoint on a very specific question; also, this is definitely not de facto practiced on en.wikipedia. --AttemptToCallNil (report bug, view backtrace) 14:23, 3 September 2018 (UTC)
 * In this blog post, mojang specifically says "Bedrock Version", so it should be italic. (possible change Bedrock Edition to Bedrock Version) FVbico (talk) 15:46, 5 September 2018 (UTC)


 * I don't really see advantages to have the official names in italics. With that in mind, I suggest to remove the entire Italics section, instead. JSBM (talk) 15:56, 5 September 2018 (UTC)
 * There is absolutely no point in italiczing official titles, the Style Guide doesn’t even specify why they should be italiczed. --Giorgosarv18 (talk/contribs) 19:46, 5 September 2018 (UTC)


 * Sorry, but I have to . Bedrock Edition is the name we use "officially" within the wiki, but that's irrelevant to the question. As we learned in English class in grade school, the correct usage of italics (for the relevant purposes) is governed by the rules of English composition. Specifically, a term is written in italics when it names a "complete body of work" such as a book, periodical, or software product. There is no body of work named Bedrock Edition — that's just an abstract idea we invented to aggregate the various Bedrock versions — so italicizing it is misleading and incorrect. I can see how editors might have thought the italics have something to do with "officialness", but there's no rule, or even custom, for expressing such a status in prose. – Auldrick (talk &middot; contribs) 17:54, 27 September 2018 (UTC)


 * I understand your reasoning. I was also not referring to officialness but indeed to that complete body of work you're talking about. I just don't agree with you that Bedrock is not a complete body of work (or "major work of art" as I like to call it). Just because we can't download a "Bedrock Edition" does not mean it isn't a full software product. – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 18:40, 27 September 2018 (UTC)


 * Actually, it does mean that. "Bedrock Edition" doesn't refer to any particular software product, it refers to a collection of them, each of which is titled Minecraft with an X Edition subtitle. But an aggregation can also be considered a body of work (e.g. under copyright law), so your argument is still valid. My objection is that this collection either has no name or is named Minecraft; it isn't named "Bedrock Edition". I would also like to note that when we were searching for a term of art for this collection, Mojang asked us not to use "Bedrock Edition" for fear that people would think it was a product and be frustrated when they couldn't find it for sale. We chose to use it anyway because we couldn't think of a better alternative, and it was specifically mentioned that Mojang's concern could be satisfied by not italicizing it. I don't think we should thwart that goal for the sake of a consistent reference style, especially one that's misleading. We should instead be emphasizing to our readers that Bedrock Edition is not an actual edition, it's a version. (My earlier attempts to promote this idea were widely rejected, and it won't surprise me if my present argument is as well.) – Auldrick (talk &middot; contribs) 20:54, 27 September 2018 (UTC)
 * Ok you've convinced me, I revoke my previous opinion, and I'd like to think of one such alternative to work around those concerns before I formulate a new one. – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 20:58, 27 September 2018 (UTC)

New proposal
A new idea I just had for working around the italicizing problem, is by changing the name of Bedrock Edition to just "Bedrock editions". No italics, but plural. Lowercase "editions" because it isn't one product. Forget it's an engine, as we need to refer to specifically the collection of multiple platform adaptations of the game. Anywhere we're referring to Bedrock in an article, rephrase it to refer to the collection of editions rather than a single product, and remember that for instance "Education Edition" is an one of the "Bedrock editions". Modify templates like only and exclusive to use this naming (in their display) while still using "bedrock" as a key (in the parameters). Never refer to "Bedrock Edition" anywhere at all, but delete that name and refer to the collection of editions that use this game engine instead of referring to the engine (name) itself. Rename Bedrock Edition to the new name and keep redirect. Update Bedrock edition. Did I miss anything? What you guys think? – Jack McKalling 22:57, 27 September 2018 (UTC)
 * Is the same approach applicable to the term "Legacy Console Edition"? --AttemptToCallNil (report bug, view backtrace) 04:11, 28 September 2018 (UTC)
 * Good idea, "Legacy Console editions" sounds good to me. – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 07:26, 28 September 2018 (UTC)
 * Do we need to capitalize "Console"? (e: or "Legacy"?) --AttemptToCallNil (report bug, view backtrace) 08:29, 28 September 2018 (UTC)
 * I think it would be "legacy console editions," all lowercase. – Sealbudsman talk | contribs 18:50, 5 November 2018 (UTC)
 * I'd "legacy console editions", they were pretty different and recieved updates at different rates and with different naming systems. -PancakeIdentity (talk) 05:23, 8 November 2019 (UTC)
 * I'd love to see us use "(the) Bedrock editions", and to link only Bedrock (i.e. not Bedrock editions ) to emphasize even more that it's not a single edition. However, it's been done this way so long that I think Bedrock Edition already has a firmly entrenched meaning in the public mind, and we should be cautious about how far we deviate from how the public conceives it (even though it was the wiki, more than anything else, that planted the seed). I don't claim to have the answer to that, I'm just suggesting that we should consider it as a factor. – Auldrick (talk &middot; contribs) 15:04, 5 November 2018 (UTC)
 * Well, eventually people get used to change. Most people don't call poppies "roses" anymore for instance. – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 15:08, 5 November 2018 (UTC)
 * I believe that even if it goes against the public grain to a degree, it is still proper that the wiki be a force that corrects misconceptions in whatever way. – Sealbudsman talk | contribs 18:50, 5 November 2018 (UTC)
 * I think you have the right idea. Perhaps even the article should be called Bedrock editions, which would more reflect its multiple nature. – Sealbudsman talk | contribs 18:50, 5 November 2018 (UTC)


 * I this proposal; as you said, it's not 1 version, but several, it's not an edition but a codebase, so bedrock editions makes much more sense.


 * Also seeing the lack of activity, I feel like this idea could be started, but I'd wait until other admins agree with me here. FVbico (talk) 14:40, 7 March 2019 (UTC)


 * Lack of replies is just sad. do you agree we can start this solution?


 * Let's do it. --AttemptToCallNil (report bug, view backtrace) 20:25, 20 May 2019 (UTC)


 * Can I assume, given that we're on the Style Guide talk page, that this includes explicit instructions to be added to the Guide? – Auldrick (talk &middot; contribs) 20:29, 20 May 2019 (UTC)
 * Of course, we need to tell all editors that way (I don't know how though). And when it is in, also mention the style guide update on the com portal. – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 21:55, 20 May 2019 (UTC)
 * . How would this work in page titles? "Bedrock editions 1.14"? "Bedrock 1.14"? "Bedrock Edition", while not being an official name, has become a de facto official name in the community and would be quite the hassle to change (both the wiki and the terminology of the readers) and make everything more confusing. The current format is not broken, and works, so why fix it; I don't see any point in changing the entire wiki again because of a minor thing like this.  Nixinova  T  C  01:33, 6 November 2019 (UTC)
 * The community angle is my biggest problem with this. We're saying it'll be less confusing, but is it really if the average reader who has a basic understanding of the different versions of Minecraft understands what "Bedrock Edition" means? They'll the come to the wiki and be confused as to exactly what "Bedrock editions" means. I went a bit further into this down below. -PancakeIdentity (talk) 05:23, 8 November 2019 (UTC)

Important update from HelenAngel
I messaged her on Twitter asking is Mojang had any official stance on this. This was her response.

"We decided that Bedrock should never be used with the term editions

Bedrock codebase is the correct terminology

But I don’t push it bc some ppl on the wiki start yelling at me if I do. 😞"

It's pretty clear that "Bedrock editions" is not the way to go. Bedrock Edition, or even more correctly, Bedrock codebase, would be the best way to refer to it. -PancakeIdentity (talk) 02:46, 6 November 2019 (UTC)


 * Then the real discussion is whether to use "Bedrock Edition" or "Bedrock Codebase". I would support the latter, since Helen did say it is the official name. In addition, "Bedrock Codebase" should clarify that the information also applies to Education Edition and Minecraft Earth. I could see other users wanting to call everything "edition", but I don’t see any real reason for this. The BlobsPaper.png 04:09, 6 November 2019 (UTC)


 * I agree. Most places, "Codebase" works just fine with some tweaking. "In the Bedrock codebase, ..." works great and sounds logical. Bedrock Codebase 1.14.0 makes sense as a version number. Etc, etc. -PancakeIdentity (talk) 04:17, 6 November 2019 (UTC)
 * Edit: I've changed my opinion on this. I oppose "editions" or "codebase" when referring to the cross-platform enabled version of Minecraft. More details below. -PancakeIdentity (talk) 05:24, 8 November 2019 (UTC)


 * I send a clarification message to helen, since it might've been a miscomunication, but in case it isn't: You don't play the codebase, you play the edition containing the codebase; the "Minecraft" receives an update, that update doesn't always apply to Minecraft Earth, so that makes no sense. Earth uses the bedrock codebase, but beta updates and stuff like that do not apply to it, causing a contradiction in itself. FVbico (talk) 05:53, 6 November 2019 (UTC)

Modified proposal
With Helen's response above, I realize I should have thought about splitting my proposal. We must differentiate two different contexts we're talking about here. Still use "Bedrock editions" (interpreted as a shorthand for "Bedrock codebase-derived editions") for collectively referring to all editions that are derived from the Bedrock codebase, but use "Bedrock codebase" for specifically referring to (something about) the codebase itself, such as a codebase version number. Because importantly, when speaking about versions, these versions relate to the codebase and not the editions that are derived from said codebase. So I still stand by my proposal, but use "Bedrock codebase" instead in those other contexts.

I strongly believe it is necessary to change to this new scheme, as the convention currently being used is simply not correct and confusing. As it currently is, "Bedrock Edition" is not accurately describing what it is, namely not an edition. An edition is for example "Windows 10 Edition" or "Java Edition", where the former runs on the Bedrock codebase, and the latter on the Java one. Readers must be getting confused when they read "Bedrock Edition" versus "Windows 10 Edition", as essentially these two things point to the same thing, but because both have "Edition" in the name, they make believe they are separate. As we have already concluded in above subdiscussions, "codebase" is a better term for distinguishing Bedrock from the separate editions.

Also, I think what Helen means by not using "Bedrock" with the term "editions", is that it is confusing to call Bedrock an edition. And we know that. But the argument here is that we need to be differentiating between the two contexts I described above. It should be OK to use the term "editions" in the context of actual editions that are based on that codebase, because we're using the Bedrock name adjectively there. Just don't use "Bedrock editions", or use the term "edition" at all, when referring to the codebase itself. – Jack McKalling 10:03, 6 November 2019 (UTC)
 * I am hesitant to use the term "Bedrock Editions". If we used that nomenclature, then bedrock would say "In Bedrock Editions", which should not be italicized since it is not an official name. Whereas "Bedrock Codebase" is an official name, so "In Bedrock Codebase" makes sense.
 * The main issue with calling Bedrock an edition is that it is really 3 editions: Minecraft, Minecraft Education Edition, and Minecraft Earth. Very few features are specific to the main edition; the exception is on pages that document education-related features. In this case, Bedrock is an edition, but any other Bedrock specific information refers to the codebase in general. Therefore, "Bedrock Codebase" should be used. The BlobsPaper.png 15:24, 6 November 2019 (UTC)


 * The Win10 example doesn't hold much ground when you realize that Windows 10 Edition is not a name in use and should not be on the wiki unless specifically talking about the deprecated Win10 version.
 * Otherwise, I think "editions" or "codebase" is a bit too confusing when we want to refer only to the versions on Android/iOS/XBox/etc, not Earth or Education. "Bedrock editions" or "Bedrock codebase" makes me think of all 3, while "Bedrock Edition" limits it to the first. And anyway, the terminology of "Bedrock Edition" when referring to the cross-platform version has been community standard for, what, 2 years now? It doesn't make sense to change that because we don't like it. If anything, it becomes even more confusing as readers won't be sure what "Bedrock editions" is referring to. Is it that cross-platform version, or all games that run on the Bedrock engine? (Edit to clarify: I'd support using "codebase" when referring to all games that use the engine or the engine itself.)-PancakeIdentity (talk) 05:18, 8 November 2019 (UTC)

MCW:UPTODATE should explicitly not apply to overview pages
This has been the de facto behavior for many years, but since someone decided to remove the information from Commands, I'm proposing we make it more explicit (and bureaucratic). It's probably worth taking a look at the discussion on that change too.

Note that, , and exist. These articles all provide an overview of content, and act as a list of instances of the relevant type. Contrast that with the example article given in MCW:UPTODATE; this is an actual article and not a list. The example given is cluttered, but mentioning that there used to be other mobs after the big list of mobs is not really an issue. If that information were ghettoized into edition-specific articles, few would ever find it. That doesn't mean that the main information on them can't be in an edition specific article; it's just that hiding that information from all other pages makes for a worse experience.

Basically, I think something along the lines of "This guideline does not apply to lists and overviews where additional information does not harm readability" should be added to the section, to match the existing uses. --Pokechu22 (talk) 01:13, 9 April 2019 (UTC)


 * -BDJP (t 01:42, 9 April 2019 (UTC)


 * I really don't see the point of making those pages exempt, every single case you linked is a specific removed section which sounds pretty close to a history section. I think it makes more sense to just expand the current guideline to include "Removed X" as an alternative to a history section used in list articles. – KnightMiner  · (t) 05:16, 9 April 2019 (UTC)


 * I'm fine with something like that too. My main reason for even bringing it up is that information like that is useful and shouldn't be deleted (like it was on commands).  Frankly, I'd rather not even be having this discussion, but since I was forced into it, I'm fine with any method of making it more explicit or just deciding that we don't need to bother and can just have that information (as it already was).  --Pokechu22 (talk) 18:44, 10 April 2019 (UTC)


 * I already mentioned on the commands page that the problem could easily have been solved by doing exactly what the pages you reference are doing: just add a section for removed commands instead of keeping them in the main current commands table. It really did not need a policy change unless you wanted to call it something besides history, and even then removed is pretty clear that its history. – KnightMiner  · (t) 00:08, 11 April 2019 (UTC)


 * . The guideline is explicitly titled "Keeping articles concise and up to date". If anything, an "overview" page (if we had any consensus on what that means) should be more concise and up to date, for the same reason that a table of contents presents less detail than the text it points to. The majority of our readers use the wiki to learn how the game works. Obsolete information just gets in their way. I understand that a few people might have interest in the game's history. If the History sections aren't detailed enough for them, it's a simple matter to pull up an old revision that has what they need. Come to think of it, a link to the prior revision in the "removed X" History entry might be a good way to provide for such needs routinely. – Auldrick (talk &middot; contribs) 04:35, 10 April 2019 (UTC)


 * This is for a single section or mention in a general table, again not in prose where it's harder to skim over. I hardly see that getting in the way and nobody really seems to have minded the inclusion of those sections until now.  My rough definition for an overview is an article that lists all instances of something, but I don't think it really needs to be defined as we are not WP:LAWYERs.  Such lists really should list all instances, not just 98% of them.  There's a difference between "concise" and "incomplete" (just as there's a difference between dense and cluttered).   To put it another way, were I to say "The majority of readers do not care about PE; argal, all information about PE should be confined within a single article" you'd consider that absurd (and question my motives since there is a clearly implied "I don't care about PE; argal the majority of readers do not" which probably is not true).
 * Regarding the revision history, yes that does exist and it is useful. However, there are some issues regarding accuracy and all that &mdash; you're locked in to what the page looked like when the information was added (and for some things, information was just not known until much later on and there's no practical way to document it as it doesn't make sense to revert to the Alpha version of the page, make an edit, and revert back to present...).  But that's a separate issue which can be solved later; here I'm specifically talking about keeping since-removed things in lists and overviews (with the details being documented elsewhere), as is already the case. --Pokechu22 (talk) 18:44, 10 April 2019 (UTC)

MCW:FUTURE should partially not apply to the PlayStation 4 Edition
Reviving this discussion from nearly four years ago, I would like to bring up again the possibility of the PlayStation 4 Edition being partially amended from this rule. This is due to the PlayStation 4 Edition having two instances that work against it:


 * 1) The PlayStation 4 Edition (as far as I am aware) has no development versions that are available to the public.
 * 2) The only source to conclude that features are planned to be added to the PlayStation 4 Edition is through the 4J Studios Twitter account, as evidenced here.

As a result, I propose to add the following line to MCW:FUTURE:

-BDJP (t 04:07, 9 April 2019 (UTC)


 * Exempting the PS4 would mean there's no rule at all about planned updates for it. Wouldn't it be better to specify different criteria for it (namely, that it's mentioned on 4J's Twitter feed)? And perhaps a different way of marking the information, if upcoming doesn't support the PS4? (I'm ignorant on that question.) – Auldrick (talk &middot; contribs) 04:12, 10 April 2019 (UTC)


 * @ I have updated the original post accordingly. -BDJP (t 06:45, 10 April 2019 (UTC)


 * The big issue is that just because something is tweeted about does not mean it will be in the game. It is impossible to tell whether a tweet is a feature that is in the next version, a far future version, or is of a feature ultimately scrapped. This issue is not solved by a lack of development versions, it is made worse by a lack of development versions as we have no way to see a feature was added then later removed. We have mentioned features and planned versions articles to gather such information, no need to include it on feature articles. – KnightMiner  · (t) 00:13, 11 April 2019 (UTC)

Slight rewording
I’ve slightly reworded the proposed addition below:

-BDJP (t 18:02, 13 April 2019 (UTC)

Zero vs. first conditional modes for aspects of game behaviour
I've noticed that many articles' verb usage arbitrarily switch back and forth between the future and present tenses. For the sake of sentence simplicity, I propose the guideline: "Most verbs should be in the present tense. The past and future tenses should be used only when it clears up the writer's point." &mdash; JavaRogers (talk) 09:03, 17 June 2019 (UTC)
 * 1) Note that this will disable game pausing for the duration
 * 2) Many commands allow relative coordinates to be specified
 * 3) Wooden trapdoors can be mined with anything, but an axe is fastest. Iron trapdoors require a pickaxe to mine. Trapdoors will remain in place if their attachment block is moved, removed, or destroyed.
 * 4) When placed, a trapdoor will either occupy the top or bottom part of a block.
 * 5) A trapdoor's "hinge" will be on the block attached to it.

''EDIT: I'd accidentally left the bolded verb usage unfinished. Also I just placed examples in a numbered list for future referencing.'' - JavaRogers (talk) 20:55, 17 June 2019 (UTC)


 * I agree with the proposal. A similar discussion is going on here: MCT:PORTAL – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 12:12, 17 June 2019 (UTC)


 * None of your citations is an example of the "future tense". Some of them use constructions of the form "will" + infinitive, which resembles what many call the "simple future" tense (though whether English has such a thing is a controversial topic among linguists), but in these examples they predict a hypothetical result, not a future event. The rest use a different auxiliary verb* and don't even structurally resemble the future tense, which requires "will". (*Your second example doesn't have an auxiliary verb at all; I can't imagine how you infer any kind of future tense in that one.) Hence, whatever problem you imagine exists among these examples (for myself, I don't see any), your suggested guideline would not address it. Moreover, there is already a guideline about when it's ok to mention future events, at MCW:FUTURE.
 * The semantics of auxiliary + infinitive constructions in English are one of its most expressive features, but also one of its most obscure. Even native speakers seldom understand them analytically and instead rely on their intuitions to produce and interpret them, and ESL speakers often make do without the subtleties they add. For this reason, even if you elaborated and restated your suggested guideline in terms of these constructions (versus "future tense"), I think it would suggest different things to different editors and would be hard for them to apply in any consistent way. It would more likely become a basis for wikilawyering than help draw us toward a common style. - – Auldrick (talk &middot; contribs) 15:11, 17 June 2019 (UTC)


 * Thank you for the correction. I never knew the form "will" + infinitive wasn't properly considered English's future tense. You make good points, so there must be a way to incorporate this grammatical nuance into such a guideline. Perhaps we just avoid the phrase "future tense" altogether. Also, we want to avoid wikilawyering, so maybe a proposed guideline shouldn't hit too hard on grammatical rules or sentence structure, if at all.
 * Before I continue, there are a couple things I'd like to quickly clear up, if you don't mind. First, I want to be clear this topic is regarding descriptions of the current game on our wiki articles. Discussions of previous and future versions of the game are another topic, but a guideline should still allow for these. Second, I suppose I meant for my examples to demonstrate the mix of the simple present and simple future tenses; however, as you point out there's also a mix of sentence type (#s 2, 3, and 5 show simple statements of fact. #s 3 and 4 show conditional sentences, and #1 can be interpreted as conditional within its context.
 * The following are all conditional sentences. (I believe these "in [blah blah blah]" sentences can be interpreted as such. The conditions are denoted with parentheses.)
 * (In Bedrock and Legacy Console editions), top snow is affected by gravity.
 * Snow will generate in single layers (in Java‌ and Legacy Console Editions).
 * Snow golems generate a trail of snow (in snowy, cold, and some medium biomes).
 * (In snowy biomes or in cold biomes at varying layers), it will snow instead of rain.
 * (When broken with a shovel), snow blocks drop snowballs.
 * My point is, we have inconsistencies across the articles&mdash;Sometimes within paragraphs or even sentences. I believe we're in need of at least some mention of verb tense in our guidelines. As this is a programmed computer game, many (dare I say almost all) things said here are definitive descriptions of game behaviour: Zero conditional sentences, hence why I'm for the present tense in nearly all cases (obviously save for when we're talking about future events). What say ye to this:
 * "Due to the definitive nature of the game's code, the simple present tense should almost always be used when describing any current game behavior. Arbitrarily changing tenses should be avoided, but it sometimes becomes necessary, such as when describing future releases of the game." - JavaRogers (talk) 20:56, 17 June 2019 (UTC)


 * I'm still not certain you get that tense is not an issue here. In your new list of examples, the "will" + infinitive constructions signify that the author was treating the situation as hypothetical and describing its expected outcome. The sentences that don't use them signify that the author was asserting a definite outcome of a well-known situation based on past experience. The difference is a subtle one of a kind that linguists lump into a category called "mode", which is distinct from the category they call "tense". Tense expresses the time relationships between events being mentioned, referred to, or implied within the sentence. Mode expresses mental states like intention, degree of definiteness, imagination, wishing, etc. Unfortunately, both mode and future tense are represented in modern English by auxiliary + infinitive constructions, which has led English speakers to no longer distinguish between them clearly (and is partly why the question of whether English still has a future tense is controversial). So with this in mind, the "grammatical nuance" you're referring to is an instance of linguistic mode, not tense.
 * If I may reframe your suggestion in these terms, what you want is to curtail the use of certain linguistic modes on the wiki, specifically those that signify that the author conceived of the situation they're describing in the abstract. Now that we have the confusion with tense out of the way, I can see a kind of logic behind your suggestion: The wiki should be documenting definite facts, not suggesting possible outcomes of hypothetical situations. However, it's not actually that simple. Take your sentence #4 above for example. If it said "In snowy biomes or in cold biomes at varying layers, it snows instead of rains," that would be factually true, but it completely neglects the far more common situation of there being no precipitation at all. The abstract mode here signifies that the statement as written is an incomplete truth, that there are additional conditions that are relevant but unstated. The conditions can't really be omitted without implying the wrong meaning (that it only snows in these biomes), but at the same time they don't need to be explicitly stated because they're just common sense (i.e. everybody knows it doesn't rain or snow all the time, so saying so would sound pedantic). So there are situations where abstract modality serves a purpose. It's not an inconsistent use of grammar, it's alternative grammar that conveys a subtly enhanced meaning, and it shouldn't be banned outright.
 * There are probably cases where abstract or indefinite modalities are used unnecessarily and the auxiliary + infinitive construction could be simplified, but their relationship to meaning is complex, often obscure, and fairly difficult to think about analytically. That's why most people rely on intuition to guide them in choosing when to use them. I think that any guideline that tried to codify this intuition would be hard to write and even harder to apply, given the abstract nature of the use cases. It's just simpler to let people use their intuition, and to edit what you don't agree with. (But I wouldn't recommend it; writing from a slightly different mental state doesn't make the author objectively wrong.) - – Auldrick (talk &middot; contribs) 03:10, 18 June 2019 (UTC)


 * Not sure I completely understand what the above is saying but something like "if a trapdoor is right clicked it will open" has nothing wrong; the "open"ing is determined by the previous. Though I think this discussion as well as the verb tense in version articles one is mostly unnecessary; "write in whatever is the most coherant and makes the most sense" is a better technique than policing trivial aspects like this. – Nixinova Nixinova sig1.png Nixinova sig2.png 03:22, 18 June 2019 (UTC)


 * Perhaps without meaning to, your comment points out that I've been too didactic. It's a flaw I confess to. To take up the question from your simpler perspective, the usages of "will" + infinitive at issue are not future tense and are not errors, though the grammar might be too advanced for some speakers to fully grasp. The question then becomes whether it actively confuses them or they simply don't get the subtle implications, which they don't really need anyway to make use of the wiki. If it actively causes confusion, perhaps we should encourage simple declarative sentences, though I think that could be hard for writers (and readers) used to the more advanced forms. It would be like asking them to use simplified English, something like how one speaks to children. I'm not sure what a solution that works for everyone would be if this is the case. – Auldrick (talk &middot; contribs) 04:15, 18 June 2019 (UTC)
 * I did understand, and what I agreed with above was with the consistency argument. If there is inconsistent tense in articles, where it's not a subtle advanced meaning that actually makes sense, it should be looked into and fixed. This is what I was rooting for in the other discussion as well. Consistency is necessary for good readability, and that isn't trivially policing like you call it, Nixinova. – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 08:46, 18 June 2019 (UTC)


 * I didn't realize this discussion was going on.


 * I've been changing future to present when I see them, provided my change seems like an improvement, particularly for non-English speakers who understand simple verb forms. The example above, "if a trapdoor is clicked it will open", is a clumsy construction that I see often. Future tense is unnecessary here when the present tense "clicking on a trapdoor opens it" or "a trapdoor opens when clicked" removes the redundant if-then conditional and compound will+infinitive verb.


 * I've also run across ugly examples of mixed future and past tense, like "X will happen after Y happened" instead of "X happens because Y happens" or "Y results in X".


 * The rule I'm using for my own edits is, if I see future tense that can be stated clearly in present tense, I do so. Sometimes the future tense is appropriate. ~ Amatulic (talk) 18:00, 18 June 2019 (UTC)


 * So, Armatulic, my dude, my bro, sista, my lady-person, what-have-you&mdash;That's more or less a simple enough rule of thumb. The situation's a bit different. I've been trying to learn quite a bit about grammatical modes since Auldrick corrected me (I hope he knows how much I appreciate it!) We're not simply talking uses of future tense; we're talking about the first conditional mode, which predicts an event's possible future outcome. They're both often constructed with "will" + infinitive. Where appropriate, we want more of the zero conditional mode, a statement of known cause and effect.


 * So what's wrong with all these "will" sentences? It's that using "will" to form the first conditional casts a bit of doubt. It predicts the possible outcome of some event. Given that this wiki documents the literally hard-coded behaviours of a videogame, there are a lot of cases where we say "will" where we probably shouldn't.


 * I say 'probably,' because it's not as straight-forward as "Hey fellas, let's only use the zero conditional on the wiki." The uncertainty of the first conditional mode allows for different, also acceptable connotations: Considering the sentence "If a trapdoor is clicked it will open." Ol' Rick called a similar sentence "an incomplete truth." The trapdoor's material is left unmentioned, and that affects whether the player can right-click open it or not. I'd say the usual trapdoors that comes to mind first are probably wood, hence the statement at all, but iron trapdoors are a common enough occurrence to cast that uncertainty conveyed by the word "will." Another acceptable use is describing unpredictable human behaviour (and I'd say mob behaviour to some extent). More on this kind of stuff here. The three important modes we're talking about are:
 * Modes:
 * Indicative mode&mdash;Statement of fact. Generally has form of a declarative or imperative (questioning) statement. The wide majority of sentences are this. "This sentence is in the indicative mode."
 * First conditional mode&mdash;Prediction of an event's possible future outcome. Generally has the form: "If [present simple tense verb phrase], then [future simple tense verb phrase]" or "If this happens, then that will happen"
 * Zero conditional mode&mdash;Statement of known cause and effect. Generally has the form: "If [present simple tense verb phrase], then [present simple tense verb phrase]" or "If this happens, then that happens."


 * Fellas, is it accurate to say the consensus is we'll pass on this one, as these rules come intuitively enough to most editors, and any wiki guideline we write will look too much like a college publication? BUT also we can go about making the necessary corrections where we're sure of these sentences' intensions. &mdash; JavaRogers (talk) 01:57, 30 June 2019 (UTC)


 * I just let people write what they want and then I come along and correct it, using the indicative and zero conditional modes. In only the rarest cases the first conditional is needed because so much stuff in Minecraft is deterministic; if X occurs, then Y happens.


 * The most egregious instances of clumsy verb grammar can be found in the history section of many articles, using the odd construct "will now no longer" as in "Spiders will now no longer trample crops" instead of "Spiders no longer trample crops". I've been fixing those when I come across them (and I haven't fixed the spider article yet). ~ Amatulic (talk) 07:06, 30 June 2019 (UTC)


 * (I fixed that one recently).


 * I've added a couple of sentences about verb tense to the style guide in the "Writing" subsection, summarizing this discussion. ~ Amatulic (talk) 15:05, 22 July 2019 (UTC)


 * ...Although just reverted my change; apparently we have different perceptions of consensus here. ~ Amatulic (talk) 15:28, 22 July 2019 (UTC)


 * (edit conflict) I reverted that change. This is not the Simple English wiki. These sentences are grammatically correct and naturally used and understood by native English speakers everywhere. It's not acceptable to tell us we're not allowed to use them. You can revise it to make it a suggestion, but it was too strong and prohibitive as it was. (Frankly, I think this is all just a colossal waste of time.) – Auldrick (talk &middot; contribs) 15:33, 22 July 2019 (UTC)


 * In most of the instances were I am changing this in articles, the future tense makes no logical sense in context, and in some cases is downright ridiculous (as in "will now no longer trample" versus "no longer tramples"). You're right, what I wrote came across as too prescriptive. Spoken English doesn't equate to written English. The former is sloppy and full of ambiguities; the latter can be precise and clear. If clarity can be improved by a simple change in tense, it's something we should do. ~ Amatulic (talk) 21:14, 22 July 2019 (UTC)


 * You keep arguing about the "future tense". I have maintained several times now that this is not a future tense, but whether or not it is, is controversial among the language community. However, for the sake of argument I'll use your terminology in rebuttal of "the future tense makes no logical sense in context". Yes, it does. In a conditional sentence you describe a hypothetical event and its consequence. By the experience of absolutely everybody in the macroscopic world, consequences follow their causes in time, which means that relative to the hypothetical event, they occur in its future, and that's the only timeline that matters because it's hypothetical. With respect to "will now no longer trample", there's nothing ridiculous about it. The "now" means "as of now", meaning "as of this update" (since it occurs in the context of a changelog). It relates the change to the specific update. Your simplified preference "no longer tramples" doesn't do that. A strict interpretation of yours would be that it's unconditional, true even if you haven't installed the update. I'm not saying that anybody would take it to mean that, I'm saying that while the "now" might not be essential for understanding, the statement is technically more precise and clearer with it. And the "future tense" here represents that it's consequent to the unstated hypothetical that you have installed the update. I'm well aware that you will view these responses skeptically (implied conditional: if and when you read them). That's fine, you don't have to agree. But I expect you to acknowledge that yours is not the only, uniquely correct, point of view here and to admit that you're arguing from personal preference, not the rules of grammar and rhetoric. – Auldrick (talk &middot; contribs) 22:03, 22 July 2019 (UTC)


 * The meaning of a phrase "no longer tramples" immediately after a software revision number is clear in the context of that revision only. As you said, it relates to a change in that specific update. Context matters. "Now no longer tramples" would also work. "Will now no longer trample" is logically incorrect; in that specific revision, the feature described exists in the present, not in the future.


 * Yes, I acknowledge that my perspective isn't the only uniquely correct point of view, although as a former textbook copy-editor I do strive to follow the rules of grammar and clear writing. If there's any controversy about the meaning and usage of the zero conditional, that is news to me. It is commonly used to express a fact, a general truth, a cause-effect result that always happens. -- and I fully admit that my own usage of it on this wiki to replace the first conditionals may seem ambitious. But when I see a case where either one will work, my personal preference leans to being concise. ~ Amatulic (talk) 21:38, 23 July 2019 (UTC)

Minigame notability
Currently, the style guide has in the community notability section: "Minigames are only allowed to be added if Mojang AB claims to have played them." However, several users (including me), have been discussing this on Discord and agree that this is not a good rule. It's difficult to know exactly what minigames Mojang has played; chances are they've played a whole lot more Minecraft minigames than we have here. I don't think we should have to find out every minigame Mojang has ever played and make sure it's covered here. If we do even decide to keep minigames on this wiki at all, we need a better rule than this.

Please help us decide how this rule should be modified or if it should just be removed completely (i.e. no minigames allowed on the Minecraft Wiki at all). Thanks, --Madminecrafter12 (Talk to me 22:47, 19 September 2019 (UTC)


 * I still think Minigames should be kept similar to how Mods are/were laid out: Minigames/ . Then we can document generic minigames (eg, just Survival Games in general, not BlitzSG or something). Minigames documented like this are unlikely to become irrelevant as they shouldn't just rely on version-specific features of information.  Nixinova</b> </b> T</b> </b> C</b> </b> 23:35, 19 September 2019 (UTC)


 * I think Minigames should be kept itsMatyh (talk) 00:03, 20 September 2019 (UTC)

Proposal: Disallow irrelevant images of player builds
The result of the discussion was apply the proposed change. Substantial support, de facto being implemented with no current objections.

Like cactus farms, ice houses, or probably banner designs. Currently this is not disallowed in article galleries by MCW:IMAGES, and I listed 3 examples of questionable images being actually used in articles.

For the purpose of restricting player builds in article galleries, I propose changing: <div style="display: table; border: 1px solid hsl(10, 100%, 45%); background-color: hsl(10, 100%, 93%); padding: 4px">Images showcasing usage of specific features for decoration should be avoided. to <div style="display: table; border: 1px solid hsl(130, 100%, 45%); background-color: hsl(130, 100%, 93%); padding: 4px">Images showcasing usage of specific features as part of player builds should be avoided.

Any suggestions or comments?

--AttemptToCallNil (report bug, view backtrace) 18:29, 12 October 2019 (UTC)
 * (edit: noting that this proposal was inspired by a discussion on the community portal. --AttemptToCallNil (report bug, view backtrace) 18:31, 12 October 2019 (UTC) )
 * Blocks may be used in player builds for purposes other than decoration. They may be used for farm designs, and such images belong only in tutorials. The BlobsPaper.png 19:11, 12 October 2019 (UTC)


 * I'd grant 1 exception, and that's an image of the alphabet on banners. Other than that, full support here. FVbico (talk) 19:13, 12 October 2019 (UTC)
 * That would belong in a tutorial on banner designs. Currently, no such tutorial exists, but someone could create one. The BlobsPaper.png 19:40, 12 October 2019 (UTC)


 * I know there hasn't been an official conclusion, but I've removed a few bad and useless offenders, and haven't received any pushback so far. (Also just realized I never responded on this page but yeah ) -PancakeIdentity (talk) 02:59, 6 November 2019 (UTC)


 * . -BDJP (t 15:26, 6 November 2019 (UTC)

Article layout
Currently, according to the style guide, the order for templates at the top of an article is:


 * 1) Info boxes
 * 2) Message boxes
 * 3) Hatnotes (e.g. redirect templates)

I think it makes more sense to put the hatnotes before the message boxes, because why would you read all the message boxes before you realize that you are on the wrong article?

Thoughts? Thomanski (talk) 13:31, 25 December 2019 (UTC)
 * Furthermore, on smaller screens having infoboxes first means that hatnotes / message boxes are pushed down. This is unlike with wider (i. e. desktop) displays, where the other two categories of templates display to the left of infoboxes (where possible). For that reason, I believe infoboxes should be third in this order.
 * It is likely the same principle applies to hatnotes and message boxes. Wikipedia's guidelines require that hatnotes go first.
 * Thus, I propose the following ordering: 1) hatnotes; 2) message boxes; 3) infoboxes. --AttemptToCallNil (report bug, view backtrace) 14:27, 25 December 2019 (UTC)
 * . I haven't even thought about smaller screens. Thomanski (talk) 20:37, 26 December 2019 (UTC)


 * I support placing hatnotes before message boxes, order between those two is pretty arbitrary but I will say it looks better with hatnotes first.
 * I disagree with placing infoboxes last as that causes a ton of awkward whitespace above the infobox on larger screens, both the hatnote and message boxes clear the sides of them which looks pretty bad when it forces the infobox down several lines. I agree it is a problem on small screens, so if we can find a way to fix small screens without damaging the layout on desktop I would support. I know CSS can be conditional on screen size, so perhaps something can be done so on smaller screens infoboxes are moved down, or that whitespace above infoboxes is removed.
 * While we are discussing changing the order, we should consider quote that appear on many articles. It looks like they are typically put right before the article text, so I would suggest stating that specifically in the guideline. – KnightMiner  · (t) 06:40, 27 December 2019 (UTC)
 * We're talking about removing the quotes altogether (somewhere in MCT:CP I think).  Nixinova</b> </b> T</b> </b> C</b> </b> 07:43, 27 December 2019 (UTC)
 * CSS can be conditional on screen size, but I'm not sure that it's possible to change the template order in this case. The template order is defined by the order of HTML elements, not by CSS rules; CSS can conditionally order e. g. flex items, which does not seem to be applicable in this case. --AttemptToCallNil (report bug, view backtrace) 08:30, 27 December 2019 (UTC)
 * I am not talking about using CSS to change the order. I am talking about using CSS to fix the extra spacing around the infobox when the infobox is last. More specifically, if the message boxes/dablinks have the proper max width applied and are set to float left (conditional on screensize/mobile site or course), the infobox will appear as it does with the hatnote placed after. The max width would look awful if there is no infobox, so we may need to use something like  to set the width class if any infoboxes are added.
 * This is quite a bit of work to solve that spacing problem on desktop though, so does anyone else agree that the spacing is a problem when the infobox is last? – KnightMiner  · (t) 21:55, 28 December 2019 (UTC)
 * I actually do not agree the space above/around the infobox is a relevant problem, and I definitely think it is less important than poor ordering on mobile devices; especially since your solution involves highly complicated code. Or given that your solution does not necessarily account for the possibility that there may be multiple infoboxes in an article, further message boxes / hatnotes in sections that have infoboxes and those that don't. --AttemptToCallNil (report bug, view backtrace) 00:33, 29 December 2019 (UTC)
 * While we're here, can we switch to amboxes already?  Nixinova</b> </b> T</b> </b><b style=background:#00a1ff;padding:2px> <b style=color:white>C</b> </b> 22:47, 28 December 2019 (UTC)
 * That should be possible, and may even be an improvement for the spacing issue above, but I find it unlikely this discussion with have an acceptable resolution. --AttemptToCallNil (report bug, view backtrace) 00:42, 29 December 2019 (UTC)


 * I've considered the distinction between article message boxes and editorial message boxes before, and I think this is relevant and important here. Some message boxes apply to just the subject on the page (which is mostly relevant to the reader). Examples of these article message boxes are archive, bot, exclusive, official page and removed, and for instance the two message boxes on wikipedia:WP:HAT. These all describe (something about) the type of the subject. Other message boxes only apply to the source of the page (which applies mostly to the editor). Examples of those editorial message boxes are cleanup, in use, more images, [ [template:research|research]] and poorly written, which all describe something about the way their subject is actually implemented on the page.


 * It is my opinion that these differrent types of message boxes also need different handling, and that one needs to be above the hatnotes, but not necessarily the other. While editorial message boxes only apply to editors, they can, will and should be completely ignored by viewers, which in turn, means they can appear higher up the page. Even above infoboxes, because they literally apply to all of the page, not just the text body. The viewer message boxes however, can also fit below hatnotes just fine in most cases. I do prefer all hatnotes last though, because visually I think it is disturbing otherwise. Hatnotes are clean and unintrusive, but the way message boxes are currently designed, they are extremely intrusive and disrupt the page if they come after the hatnotes. It could even mean that the hatnote is overlooked altogether. So again in my opinion it isn't about what the reader needs to look at first, but about the visual structure of the page. Because as long as the visual structure is sound and balanced, the viewer will know where to look anyway without missing anything.


 * That is not to say however, that the message boxes couldn't be redesigned to be less intrusive, such as the modern [//default-loadout-en.gamepedia.com/Template:Ambox amboxes] that only have a small edge on the left that is distinctly coloured, as opposed to the whole background area. Which is why I said above that functionally, these viewer message boxes could also theoretically fit below the hatnotes, if they would use less intrusive styling such as in the amboxes. The editorial message boxes however, could even go higher than they are now, and don't need the same, less intrusive styling, considering they often carry a lot of "warning" value. – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 16:21, 6 February 2020 (UTC)


 * I also wanted to add, that all arguments regarding mobile view I cannot share, refute, or consider, as I have no way of using or looking into it. However, I do believe we should be fully capable of solving spacing issues and even ordering of elements with CSS, if needed. – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 16:27, 6 February 2020 (UTC)


 * On mobile devices, placing them at the top of the page would be more obstructive than where else. I think a better solution would be to have a collection of editorial notices that is collapsed by default. This would contain the message boxes the way they are now, but the boxes would be hidden until you press the Show button. The BlobsPaper.png 23:45, 6 February 2020 (UTC)


 * , as it makes sense for them to be just below the 'underline' of the title. --MMK21stream (talk) 13:51, 1 June 2020 (UTC)


 * Quoting from Wikipedia, "If a reader has reached the wrong page, they should find that out first." Fadyblok240 (talk) 22:17, 1 July 2020 (UTC)

Natural Generation Layout
For consistancy, which one should be used for Natural Generation section, especially for block that have multiple variants

Natural Generation specified to block variants like in planks and fence or specified to structures like in stairs and slab. The mixed one like in log doesn't look fine for me. ImakerB (talk) 00:09, 8 February 2020 (UTC)

Punctuation at end of parenthesis
The spelling section describes that the wiki to preferably be written with American English spelling. However, most cases of the use of punctuation at the end of parenthesis I've seen (including from this very talk page) have been using punctuation outside of the parenthesis, which is not regarded to be an American English style of writing. This may not need to be a guideline that strictly needs to be followed, but some kind of description of the use of parenthesis and punctuation should be mentioned in this guide. – 81.92.203.78 23:54, 13 January 2020 (UTC)
 * What do you mean? If the punctuation is relating to the stuff inside the brackets it goes inside them, else it goes outside them. (Standalone sentence here: has punctuation end inside it.) Regular sentence here (punctuation goes outside). No issues here. <b style=background:#0800aa;padding:2px> <b style=color:white>Nixinova</b> </b><b style=background:#006eff;padding:2px> <b style=color:white>T</b> </b><b style=background:#00a1ff;padding:2px> <b style=color:white>C</b> </b> 04:02, 18 February 2020 (UTC)

samp versus text style
When should you use [text] ( [text] ) versus ? From what I have seen samp is used for files (see launcher for example) and cd is used for commands, technical names from within the source code, and technical in-game names like tags (see Java Edition 1.15). 81.92.203.76 23:27, 17 February 2020 (UTC)
 * I agree we need a standarization. I always use  tags, and never samp tags, partially because I didn't realize there was a difference. If anyone feels we need to use samp for certain puropses, please speak up. Otherwise, we should stick with   for simplicity. The BlobsPaper.png 02:28, 18 February 2020 (UTC)
 * Samp is for general monospace font, code is for actual code or code-related material. E.g., item IDs use &lt;code>, file names use &lt;samp>, as the IP said; at least that's how I use them. Explicit standardisation would be good though. <b style=background:#0800aa;padding:2px> <b style=color:white>Nixinova</b> </b><b style=background:#006eff;padding:2px> <b style=color:white>T</b> </b><b style=background:#00a1ff;padding:2px> <b style=color:white>C</b> </b> 03:57, 18 February 2020 (UTC)

Writing coordinates
Usage of coordinates is very inconsistent across the wiki. Single coordinates are written in either uppercase or lowercase and Y coordinate usage alternates between "Y-level 10", "Y=10" and "altitude 10". Complete coordinates are written "1,2,3" or "(1,2,3)" or "1/2/3" or "x=1,y=2,z=3" or whatever. There needs to be a consistent way of writing coordinates. For single coordinates, I think they should always be uppercase (as that's what's given on the F3 screen), but I'm not sure which complete format is better or if saying "altitude" instead of "Y=" is better. <b style=background:#0800aa;padding:2px> <b style=color:white>Nixinova</b> </b><b style=background:#006eff;padding:2px> <b style=color:white>T</b> </b><b style=background:#00a1ff;padding:2px> <b style=color:white>C</b> </b> 03:56, 17 April 2020 (UTC)


 * I think saying "Y" something is better as it ties it in to the in-game description better. Altitude could easily be interpreted as altitude from sea level, as that's how it's used in the real world. As for coordinate sets, I think "(1,2,3)" or "x=1, y=2, z=3" would be best. Maybe use one over the other depending on the context. Standardization would be nice but I don't feel strongly about the specifics. Count this as a support for any of the mentioned systems other than altitude. -PancakeIdentity (talk) 18:19, 22 April 2020 (UTC)


 * No strong opinion (except that I also disagree with "altitude" for the reasons that PancakeIdentity mentioned), but we should also standardize cases where volume dimensions are described (for example, "5×5×4" at Fishing). IMO the height should always be in the middle to be consistent with Y being the height coordinate in the game. – Sonicwave talk  18:38, 22 April 2020 (UTC)
 * I standardizing volume this way. -PancakeIdentity (talk) 18:39, 22 April 2020 (UTC)


 * specifying X, Y, and Z, to avoid confusion. The BlobsPaper.png 18:42, 22 April 2020 (UTC)

Minecraft Dungeons style guide?
I have been adding a few new entries for Minecraft Dungeons (MCD) and realized that the style guide links over to this page. Most of the guide here is not applicable to MCD and some basic templates are very much needed to keep the new content neat.

--Touchportal (talk) 13:19, 30 May 2020 (UTC)
 * Some of this style guide would apply to Dungeons, so we could create a subpage. Also, would a Minecraft Earth style guide make sense? The BlobsPaper.png 05:03, 1 June 2020 (UTC)
 * I've made some basic templates such as navigations but not so much with infoboxes.
 * As of now the writing is very inconsistent. We should consider adding guides for capitalization, article layouts, file names, and perhaps image standardization. I've noticed several inconsistencies between editors, even for the most constructive one. So for the sake of keeping everything consistent, a new MCD-specific style guide would be very much needed. – ItsPlantseed ⟨₰|₢⟩ 13:13, 1 June 2020 (UTC)
 * Someone can start drafting one at Minecraft Wiki:Style Guide/Minecraft Dungeons. I do have some opinions about this style guide/manual of style. I'll discuss that later.-- skylord_wars (talk) 10:00, 11 June 2020 (UTC)

Standardized layout for Tutorials?
I request that tutorials should have their own standard layout. Thoughts? Fadyblok240 (talk) 22:22, 1 July 2020 (UTC)
 * I am not sure if this is practical. Tutorials are usually structured by having a bunch of designs, and sorting them into categories. The BlobsPaper.png 16:09, 3 July 2020 (UTC)
 * Ditto to what The Blobs said. Really not sure how this would be done. -PancakeIdentity (talk) 23:15, 29 July 2020 (UTC)

Screenshot sizes – unexpected and maybe unneeded de facto standard
Apparently some people insist screenshots must be 854x450. I don't see any reason to require any specific size beyond doing their job; consistency isn't a goal in itself, it's a means to organize content, and I don't see how a uniform image size here is needed or relevant.

Proposal: explicitly state there is no fundamental image size requirement that makes some sizes bad in themselves (beyond being excessive like 8K). --AttemptToCallNil (report bug, view backtrace) 18:12, 17 July 2020 (UTC)


 * . I'd also like to respond to a point seen on discord - aspect ratio requirements. While at face value this sounds reasonable, cropping images to help focus on what is actually being shows can be very helpful, especially for the smaller size of images in galleries and such. -PancakeIdentity (talk) 18:22, 17 July 2020 (UTC)
 * . Like some images have different shapes. Like things like non-isometric renders sometimes have really small sizes like the heart. this definatly saves space so YES –Preceding unsigned comment was added by Humiebees (talk • contribs) at 19:37, 17 July 2020 (UTC). Please sign your posts with
 * . Screenshots containing UI elements (main menu, options) should have the default aspect ratio of 854x450 with the default GUI setting to keep the screenshots readable and consistent. <b style="border:1px solid #0800aa"> Nixinova </b> <b style="border:1px solid #06f"> T </b> <b style="border:1px solid #0af"> C </b>  20:11, 17 July 2020 (UTC)
 * . Only UI elements need to be 854x450. — Thomanski | t | c | 20:46, 17 July 2020 (UTC)

Compromise for message box / infobox order
In Wikipedia, message boxes should go before any infoboxes, but in many articles on the Minecraft Wiki, the infobox comes before anything else. However, applying Wikipedia's layout on Minecraft Wiki articles creates a lot of blank space. So I propose a compromise: Message boxes about article maintenance go before infoboxes, but other message boxes that describe the feature instead of the article itself (e.g. version exclusive, disclaimers) go after infoboxes. –Preceding unsigned comment was added by Fadyblok240 (talk • contribs) at 02:19, 18 July 2020 (UTC). Please sign your posts with
 * That might be too complicated. Users will see the message boxes split, and they will move all of them to one side or the other. The BlobsPaper.png 17:43, 19 July 2020 (UTC)


 * I prefer the way Wikipedia does it; it makes the message boxes stand out rather than blending into the rest of the article. However, templates such as About should stay below the infobox. I think trying to differentiate between the two message boxes would be too much maintenance and not have enough benefit. — Godslayerchickennugget (talk | contribs) 17:50, 19 July 2020 (UTC)

A relevant article regarding native English speakers versus ESL speakers.
This article from the BBC seems somewhat relevant to the discussions of writing style. --MentalMouse42 (talk) 10:37, 4 October 2020 (UTC)

Category redirects
Recently, a template category redirect was create to mark categories where multiple names appear to fit. Notably, I see Category:Entity uses it to redirect to Category:Entities. Wanted to start this discussion about how to note them in the redirect notability. What makes a category redirect worth having it, and when should the category just be deleted instead? I don't have any ideas immediately as the idea is new to me. KnightMiner (t/c) 03:49, 7 October 2020 (UTC)


 * I personally don't see any sense in having category redirects — it's not like someone would benefit from them while searching categories, which is the first thing that gets into my head regarding their possible usage. — <b style="line-height:19px;letter-spacing:1px"> Babylon A S </b> 04:26, 7 October 2020 (UTC)


 * I have seen some wiki's store actual content on category pages, though I don't personally think that is a good place for contennt. If users are saving bookmarks they really should bookmark the article for info, in that sense, you bookmark Entity instead of Category:Entities. Otherwise, maybe they want to bookmark the list of pages, where deleting it would break old bookmarks, so I guess that may be useful?
 * The other usecase I can think of is to prevent creation of redundant categories. If someone did not think the entity category existed they may accidently create a duplicate. That would mostly be addressed checking categories on similar pages though. KnightMiner (t/c) 22:30, 7 October 2020 (UTC)

About the article titles of Pocket Edition versions
The version pages have used the new title style, whether in the style guide needs to be corrected? --  |  Talk · Contributions · Logs  16:51, 22 October 2020 (UTC)

Adding external links
I would like to suggest adding an "External links" section to the Minecraft and variant pages. This section would only link to the game/subject's respective Wikipedia and Codex Gamicus page where available:

== $section_name == * Minecraft on Wikipedia * [link Minecraft] on [link Codex Gamicus]

This section could be above the Notes, Media or References section. talk 13:27, 15 November 2020 (UTC)

Allow spellings suggested by spellcheckers for redirects
As a result of some names of blocks being made up but have similar spellings of dictionary words, such as the sculk sensor, end up being flagged by spellcheckers. Sculk, being a slight letter change to skulk, gets flagged, which suggests for it to be changed to skulk. Should this be added as a rule for redirects? – Unavailablehoax (talk) 08:54, 12 December 2020 (UTC)
 * , granted the spell check is set to english, obviously. Dhranios (talk) (Join the wiki videos project!) 09:08, 12 December 2020 (UTC)

Plural page titles
See my argument on Talk:Java Edition data values, there is a standard the wiki uses that is not listed here: "pages listing a feature type should be plural" and nobody has ever bothered to bring it to the style guide and write it off as an exception instead. It is not an exception.


 * data values
 * mentioned/removed/unused features
 * advancements/achievements (before I moved them)
 * a bunch more

These pages were all in plural and written off as exceptions to the rule, but exceptions should not be this common.

If we are going to apply this reasoning, add it to the style guide....... Dhranios (talk) (Join the wiki videos project!) 05:58, 18 January 2021 (UTC)

Proposal: a change to MCW:FUTURE
Right now there is no standard procedure for adding planned features to articles which are confirmed to be added in a known future update but have not yet appeared in development versions. MCW:FUTURE states that future content should only be included in articles if it is present in a snapshot or beta, but there are sometimes situations in which a planned future addition is signifigant enough within the context of the article to warrant inclusion. My opinion is that confirmed future features should be allowed to be included in the relevant articles within a "Planned" section, provided there is enough confirmed information to justify it.

Here's an example of a flaw in the current system, from the "Mobs" page:

=== Planned mobs ===

Planned mobs are mobs that are not yet in any publicly available version of the game, but have been announced to be added as part of a known upcoming update and have been visually confirmed.

Under the current rules, this example is not allowed to be added to the Mob page, because it refers to a feature not present in any playable version of the game. However, it is a confirmed feature that is planned to be added to a known update within a known time window. The Mob page also includes mobs with no known ETA, mobs confirmed to never be added in the foreseeable future, and mobs known only from 2D concept art, so for something with this level of confirmation to not be allowed a mention seems strange. And keep in mind that while the Warden will be released in a snapshot sometime soon, once the next major update is announced, there will inevitably be new mobs announced with it and this problem will arise again.

Of course, usually, if a feature doesn't yet exist in a development version, it's probably better off being listed only in the page for the update that will add it. However, in cases where it is warranted, the rules do not allow it. What I'm proposing is that MCW:FUTURE be slightly changed to allow more freedom in describing planned features in pages related to those features. AlienAgent124 (talk) 18:19, 27 January 2021 (UTC)
 * , It's OK for me, I mean, we are sure that we are gonna get the Warden in the future, so, the article would feel more complete having informations like this. RondiMarco (talk) 22:13, 29 January 2021 (UTC)


 * . While, yes, it is true that the mob is planned, it’s better to leave it off the article than the opposite. The rule states that a feature has to appear in a development version in order for it to be added, and that rule should remain as is. The Warden has not yet appeared in a development version, and as such, nothing should appear on the Wiki regarding said mob (the WIP page currently used as a redirect is the only exception). If such a section were added, then it would only fuel speculation further, and keep in mind that the mob could be scrapped at anytime during development, much like how changes to water physics were shown off at MINECON Earth 2017 that ended up not happening. BDJP (t 23:49, 29 January 2021 (UTC)


 * : The purpose of that rule was to prevent half baked features ending up on articles, you should have seen how many articles we had on things that were disucssed but never added before. Being in a development version means we have something concrete we can discuss. You can add it to Mentioned features until then, and I think the version articles are allowed a section for mentioned but not yet implemented. As a compromise, maybe have Mobs link "Mentioned features#Mobs" or "1.17#Planned mobs" in a "See also" section? That's about as far as I'd agree with adding it to the page. KnightMiner (t/c) 21:35, 30 January 2021 (UTC)