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)

 Support--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#Italic words--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)

 Oppose, 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 [ ] 13:27, 7 March 2018 (UTC)

 Oppose: 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)

 Meh. 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)

 Done Redirect from redlink created. – Jack McKalling [ ] 23:21, 7 March 2018 (UTC)

 Slightly oppose. 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.-- Madminecrafter12^{T • C} 00:51, 8 March 2018 (UTC)

 Oppose “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)

References

This wiki doesn't really have any rules regarding references; editors usually just add plaintext links. I find that this doesn't look that good and also doesn't give the reader much information on the page. I have created a few templates ({{Article}}, {{SnapshotLink}}, {{Link}}) that are loosely based off of Wikipedia's citing templates, but I seem to be mostly the only one using them (although {{Article}} is used on all recent snapshot pages). I just think there need to be some guidelines of linking references. Thoughts? – Nixinova 07:00, 21 April 2018 (UTC)

Suggestion: strongly recommend to use the most specific template possible with plaintext links as a last resort. --AttemptToCallNil (report bug, view backtrace) 08:00, 21 April 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 Blobs 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, Trolls are weak to fire, taking 25% more fire damage. is fine by itself, and should be in the article. However, if someone added So don't forget to include your fire mage in your party whenever you're going through troll territory! 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#National_varieties_of_English. 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#National_varieties_of_English 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  Agree 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^{Talk to me} 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)

 Neutral. 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)

 Oppose. 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)

 Oppose: 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)

 Oppose 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 [ ] 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 Bedrock Edition 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)

 Support 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)

@Marioprotvi and Giorgosarv18: 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^{Talk to me} 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  Support 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 [ ] 12:56, 3 September 2018 (UTC)

For reference, "software other than games" (game engines are not games) is listed in wikipedia:MOS:TITLES#Neither, 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 [ ] 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)

 Support: 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  Disagree. 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 · 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 [ ] 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 · 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 [ ] 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 [ ] 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 love to see us use "(the) Bedrock editions", and to link only [[Bedrock]] (i.e. not [[Bedrock edition]]s) 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 · 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 [ ] 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  Support 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. Madminecrafter12 and AttemptToCallNil 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 · 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 [ ] 21:55, 20 May 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 Block#Removed blocks , Item#Removed items , and Mob#Removed/Unimplemented mobs 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)

 Support -BDJP ^(t|c) 01:42, 9 April 2019 (UTC)

 Neutral 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)

 Oppose. 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 · 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 — 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:

“

The PlayStation 4 Edition is partially exempt from this rule as no development versions for said edition are available to the public, and the only source to conclude that features are planned to be added is through images posted by the 4J Studios Twitter account.

„

-BDJP ^(t|c) 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 · contribs) 04:12, 10 April 2019 (UTC)

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

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

“

The PlayStation 4 Edition is partially exempt from this rule as no development versions for said edition are available to the public, and the only source to conclude that features are planned to be added is through images posted by the 4J Studios Twitter account. This exemption only applies to pages that have a "platform availability" section, such as Mob.

„

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

Future vs. present tenseZero 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.

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.

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." — JavaRogers (talk) 09:03, 17 June 2019 (UTC)

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#Present or past tense in lead section of a version release? – Jack McKalling [ ] 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 · 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.)

1. (In Bedrock and Legacy Console editions), top snow is affected by gravity.
2. Snow will generate in single layers (in Java‌ and Legacy Console Editions).
3. Snow golems generate a trail of snow (in snowy, cold, and some medium biomes).
4. (In snowy biomes or in cold biomes at varying layers), it will snow instead of rain.
5. (When broken with a shovel), snow blocks drop snowballs.

My point is, we have inconsistencies across the articles—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 · 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   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 · 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 [ ] 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—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—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—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—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. — 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).

@JavaRogers: 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 Auldrick 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 · 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 · 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.[1][2] -- 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)