Minecraft Wiki talk:Style guide

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.  Nixinova  T  C  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#Junk_and_treasure). 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  Support standardizing volume this way. -PancakeIdentity (talk) 18:39, 22 April 2020 (UTC)

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

 Support writing coordinates capitalised as X, Y and Z for two reasons: firstly, this is how the coordinates are shown when the player presses F3 in Java Edition. Secondly, these translate to x, z and y respectively as in most coordinate systems: as someone who is familiar with the Cartesian coordinate system, understanding that Y = z and y = Z can be a little confusing at first. Even worse, −Z is north instead of south (−z), while −X is the same as −x (west). As per Wikipedia's Manual of Style for mathematics, variables should also be italicised; this includes coordinates.

As for 'level', 'layer', 'altitude'... in the context of Minecraft, all of these words are synonyms of the same concept: 'Y = ...' What actually needs to be standardised is the Y-coordinate where blocks and entities are located: is it the top face of the block (e.g. sea level is 62, clouds appear at 127), or the bottom face of the block (e.g. sea level is Y = 63, clouds appear at Y = 128)? I believe the Y-coordinate of a block should be its bottom face: if the player were to use commands to fill Y = 62 with a solid block in a biome with water at sea level, it would replace the topmost layer of water with this solid block. Conversely, the Y-coordinate of an entity should be the top face of a block they can teleport onto or spawn on.

Regarding coordinates with multiple variables, Cartesian coordinates are usually represented as '(x, y, z)' in three-dimensional space. With Minecraft being an odd exception in having a inverted north/south axis and (arguably) confusingly named axes, it would be better to represent coordinates as '(X, Y, Z)'. It helps to repeatedly use commands like /fill, /tp and /summon across different octants to have a better understanding of Minecraft's coordinate system, and its relation to blocks and entities within the in-game world. Pearlia (talk) 23:11, 24 February 2021 (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)

 Support 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 Blobs 05:03, 1 June 2020 (UTC)

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

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

 Support subpage only. A style guide for Dungeons should not supersede anything already written for the main style guide, but address only situations not already covered. We don't need to add guides for capitalization and such; what we have is already fine. Amatulic (talk) 19:41, 21 May 2021 (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 Blobs 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)

I disagree.

Farming tutorials could be standardized. Lead section, a section about mechanics (with subsections for Java and Bedrock), a section or two describing basic survival builds using text, images, and diagrams (not videos), and finally a section that includes carefully curated videos that don't duplicate any information elsewhere. Examples of this would be Tutorials/Turtle farming and Tutorials/Drowned farming, and possibly Tutorials/Iron golem farming.

Tutorials on defeating something could also be standardized: Lead section, with sections on strategies, each having subsections on preparation and execution.

Some sort of standardization would be good to prevent tutorials from being indiscriminate lists of youtube videos, most of which were placed there by the video authors for the purpose of attracting clicks and likes. Amatulic (talk) 19:47, 21 May 2021 (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)

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

 Strongly Agree. 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 ~~~~

 Agree with an exception. 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.  Nixinova   T   C   20:11, 17 July 2020 (UTC)

 Agree. 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 Blobs 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. — BabylonAS 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? --SkyE | 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 ==
 * [[wikipedia:Minecraft|Minecraft]] on [[wikipedia:|Wikipedia]]
 * [link Minecraft] on [link Codex Gamicus]

This section could be above the Notes, Media or References section. TheLOLxd2 ^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)

 Support, 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)
• Pages that consist of general concepts
  • (Actually some of them. This point needs discussion, as it should be specified which pages with this condition should use plural or not)
• 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)

I  Support this proposal. Specifying this would make the plural usage less confusing. Thejoaqui777 (talk) 13:39, 18 March 2021 (UTC)

 Support Changing the plural title rules, only pages about one specific thing should be singular, general pages like those above should be plural.  Nixinova   T   C   19:07, 18 March 2021 (UTC)

 Support I support listing feature types pages being plural. We might want to clarify the wording slightly from "feature type" though, as I don't think Sword should become Swords. Maybe something like "pages listing all of a feature type should be plural, this does not include cases where multiple features are combined into one article, such as sword" KnightMiner ^(t/c) 19:42, 18 March 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.

Warden

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)

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

 Oppose. 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|c) 23:49, 29 January 2021 (UTC)

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

 Comment: I have an idea due to the comments above. The Warden could go to the "Mentioned mobs" section of the Mob article, as the Vulture, Meerkat, Ostrich, Frog and Termite are there, and they are on the same situation that the warden (confirmed to be added but not yet on any development version). Thejoaqui777 (talk) 00:10, 8 February 2021 (UTC)

That sounds to me more like a case of removing those mobs from the mobs page to comply with the style guide. The style guide in its current wording disallows mentioned features on any other articles, so if they are to remain the style guide needs to be amended. I'm replying because you basically said you disagree with this change but agree with something this change would have allowed. KnightMiner ^(t/c) 00:00, 9 February 2021 (UTC)

Changing to a  Comment. Also explaining. The warden should go on that section as it is a mob that has been announced but isn't on any snapshot or beta. Thejoaqui777 (talk) 05:56, 17 March 2021 (UTC)

Thats the whole reason MCW:FUTURE disallows it. That policy is about things that are announced that are not in any snapshot or beta. If you think that shouldn't be the case, then propose changing the style guide or agree with the given proposal. KnightMiner ^(t/c) 02:21, 17 March 2021 (UTC)

 Second comment: "The purpose of that rule was to prevent half baked features ending up on articles". --- It's true. If we allowed every page to have planned information then we would end with that. So, I made a proposal that would make a change on MCW:FUTURE, but without being too excessive:

• "For announced elements that have not appeared in development versions, it is allowed to place them only in the "Planned features" sections in release articles (such as Village & Pillage) or in articles that encompass general characteristics (such as Mobs), in the Mentioned Features articles (of Java or Bedrock), and in the history section of articles as planned changes, only mentioning them there."

That way we can control where would end the planned features. Thejoaqui777 (talk) 20:55, 31 March 2021 (UTC)

Per the comment below, I changed "planned" to "announced". Thejoaqui777 (talk) 20:48, 1 April 2021 (UTC)

 Oppose relaxing the rule for articles. An "announced" feature isn't equivalent to a "planned" feature. If it isn't in a development version, it's basically vaporware. Addressing Thejoaqui777's proposed change, the history section of articles is for history, not future plans. I have no objection to such features being present in release articles, but that is the only place they should appear, and should not proliferate into any articles beyond the release article until the feature is seen in a development version. Amatulic (talk) 19:32, 1 April 2021 (UTC)

 Weak support. People search for more information on pages like Warden. It's one of the most popular pages on Fandom's Minecraft Wiki, look on the side rail. Also, Mojang has changed over the years its process to reveal new features to the game. I mean, Warden behavior was widely documented on Minecraft Live 2020 and by the developers on Twitter. Given that, I'd strongly support having information of what Mojang said on the Minecraft Wiki. That doesn't include what community try to measure like the HP of the mob etc.

But, i understand how hard and superficial is to document things like the Sculk Sensor block (when it wasn't released), when even devs didn't know how it would work. So, /shrug. --Dr03ramos (talk) 23:29, 12 April 2021 (UTC)

Amend the notability rule regarding minigames

As of now, per the style guide:

“

Minigames are only allowed to be added if Mojang Studios claims to have played them.

„

However, as of recently, the minigames article has become much more of a cesspool of minigames that are notable to the community, and despite Mojang having played some of them, it is important to understand that most of them are mainly used on third-party servers, and even then, a good portion of them can all be done in the vanilla game. As such, I propose that the rule be changed to:

“

Articles about minigames are not allowed. Such information is better suited for the Minecraft Servers Wiki, which is designed for documenting such info. The only exception to this rule is the article about Mini games on Legacy Console Edition.

„

BDJP ^(t|c) 17:13, 2 February 2021 (UTC)

 Support as nominator. BDJP ^(t|c) 17:13, 2 February 2021 (UTC)

Support per nominator, but I don't think the notability guideline should be part of the style guide, especially because is unrelated to style. I would suggest splitting the notability guideline into a separate page or at least noting that the guideline does not have to do with style. Fadyblok240 (talk) 19:19, 2 February 2021 (UTC)

 Sure  Nixinova   T   C   19:31, 2 February 2021 (UTC)

It is also worth mentioning that some subjects don't warrant their own articles, but deserve a mention, such as many of the lesser known Mojang Studios staff. The guideline should consider more of these cases. Fadyblok240 (talk) 19:33, 2 February 2021 (UTC)

 Comment: Spleef is honestly a pretty big moment in MC history as it was the first "official" minigame, so I don't especially like the idea of deleting that article (especially since its linked on Notch's old blog). Likewise, Ultra Hardcore has directly influenced features in some of the updates (golden apple tweaks, the natural regen gamerule). My opinion is instead of outright banning all minigame articles, to simply make the guideline more strict. The addition of realms makes "Mojang Studios" playing them be a lot less viable, so perhaps something like "Minigames are only allowed if they had a significant impact on Minecraft's development"? Might still be a bit open for interpretation, but in my opinion those two minigame articles are worth keeping (I don't see any other minigames I would consider notable). KnightMiner ^(t/c) 07:06, 3 February 2021 (UTC)

Tried to find a ref for UHC affecting the game because I know its true, and it seems 13w23a was basically the UHC update - spread players, natural regen gamerule, gapple changes, health changes. Doesn't explicitly mention UHC but has Docm77 in the banner which is proof enough. I should add this to some trivia entries.  Nixinova   T   C   07:25, 3 February 2021 (UTC)

 Comment I would prefer to see things go in a different direction where more minigame articles (like Ultra Hardcore) are included simply because they provide pretty helpful information. –MJL ‐Talk‐^☖ 03:28, 21 March 2021 (UTC)

 Support I don't even know what "Mojang Studios claims to have played them" means. Who are we talking about here? Where are these claims supposed to come from? Does it count if they played it for fun during their free time? What if they hated it? Why does it make any difference that somebody at Mojang Studios played it anyway? And what even qualifies as a minigame in the first place? The current guidance is about as useful for screening out mediocrity as a participation award is for rewarding excellence. — Auldrick (talk · contribs) 05:51, 21 March 2021 (UTC)

That rule is from the early days of Minecraft. Back when Mojang AB was 5 people and would post on Twitter about collaborations with people from the community. It is far past being a good criteria, yes. KnightMiner ^(t/c) 04:09, 22 March 2021 (UTC)

The best part about Minecraft is actually its derivative contents.

Minecraft minigames.

They might don't directly related to "Minecraft", but it is a part of Minecraft for players.

It's a pity to delete them for MCWiki, "The Ultimate Resource for Minecraft" --Dahesor (talk) 05:41, 10 April 2021 (UTC)

 Strong support. This should go into a tutorials subpage. None of this shows content of the game and all of them are made by the community. If we allow this change, we need to allow things like servers, mods, etc.Humiebee^{talk contribs} 12:18, 17 April 2021 (UTC)

Servers and mods do change. But the ways to play game do not. I don't perfer to add servers stuff on MCWiki, but things like UHC is a very important part to Minecraft. They are already connected to the game. (Are you still playing the original Minecraft?) --Dahesor (talk) 03:57, 9 May 2021 (UTC)

 Comment That is not how to use {{c}} use like this {{c|oppose}} TheGreatFall (talk | contribs) (Tagalog translation) 04:07, 9 May 2021 (UTC)

 Relocate all minigame-related content to the Minecraft Servers Wiki and link to said wiki where applicable to further establish it as the official resource for such content, encourage its continued documentation and upkeep of existing documentation there, and make the bounds on what is accepted on this wiki clearer. - User-12316399 (talk) 16:24, 6 May 2021 (UTC)

 Support removing minigame (except Mini games) content from here. TheGreatFall (talk | contribs) (Tagalog translation) 04:07, 9 May 2021 (UTC)

MCW:LAYOUT needs updating

Currently MCW:LAYOUT lists these article components in order:

1. Hatnotes
2. Message boxes
3. Infoboxes
4. Introduction with a general description
5. Article body
6. See also
7. Notes and references
8. Applicable footer navboxes
9. DEFAULTSORT
10. Categories
11. Interwikis

The problem is, many articles have a lot more than that: Sounds, History, Trivia, Gallery etc. Some have galleries included in the History section and before or after the Trivia section. There's no history section listed above even though almost every article has one.

And about Trivia, we really need some stern guidelines for trivia; many people consider that as a dumping ground for personal commentary, speculation, random tangential facts. I find myself removing something from a trivia section almost every day. But that's another issue. I want to discuss layout here.

So taking WP:LAYOUT from Wikipedia and modifying it to be more comprehensive for Minecraft articles, I propose something like this:

1. Before the article content
   1. Hatnotes
   2. Deletion / protection tags
   3. Maintenance tags
   4. Message boxes
   5. Infoboxes
   6. Navigation header templates (sidebar templates)
2. Article content
   1. Lead section; introduction with general description
   2. Table of contents (usually automatically included)
   3. Article body
3. Appendices and footers
   1. Sounds
   2. Data values (if applicable)
      1. ID
      2. Block data / item data
   3. Video (if present for illustration)
   4. History
   5. Issues
   6. See also
   7. Trivia (avoid or minimize if possible)
   8. Gallery
   9. Notes and/or references (capture all citations from above sections; this can be two sections)
   10. External links
4. End matter
   1. Applicable footer templates / navboxes
   2. DEFAULTSORT
   3. Categories
   4. Stub templates
   5. Interwikis

The "Appendices and footers" region doesn't have much consistency across articles on this wiki, at present. People are doing the best they can, but there isn't any guidance. Whatever order is most commonly used should be what we establish as guidance to minimize changes across the wiki. But I don't know how to conduct a study; I can find examples of different orderings but I am not sure what is most common. Amatulic (talk) 20:57, 28 February 2021 (UTC)

You know the layout section is just a summary, the sub pages are for specific requirements? MCW:Style guide/Features#Trivia contains those strict guidelines for trivia you wanted. If something is missing, propose updating that instead of adding something we already have. I'll agree the subpages can be made more prominent, but don't expect the summary list to be all encompassing. KnightMiner ^(t/c) 23:40, 28 February 2021 (UTC)

I see. Thanks. That summary, then, doesn't match the list in the Features page. I'll do some cleanup. Amatulic (talk) 03:56, 1 March 2021 (UTC)

Its not just the features page it should match, we have a few other layout guides. I am partially inclined to just ditch it. Alternatively, maybe The major categories from your proposal above could be kept and the minor categories that differ can be left out. KnightMiner ^(t/c) 04:29, 1 March 2021 (UTC)

 Comment: First, MCW:Style guide/Features explains what should be done on the sections, not how the layout should be done. Second, it was suggested on its talk page that the page needs to be split, and many people agree on that idea, meaning that if it is split it won't be (if it was) anymore a general layout guide.
So, I  Support the proposal here because it will work perfectly. If a specific point need to be noted, then create a subpage specifying things. The layout is the order where things should go, not how they should be written. Thejoaqui777 (talk) 04:35, 12 March 2021 (UTC)

 Comment: I need to say that stub templates are maintenance templates too, so the layout would need to be like this:

1. Before the article content
   1. Hatnotes
   2. Deletion / protection tags
   3. Maintenance tags/Stub templates
   4. Message boxes
   5. Infoboxes
   6. Navigation header templates (sidebar templates)
2. Article content
   1. Lead section; introduction with general description
   2. Table of contents (usually automatically included)
   3. Article body
3. Appendices and footers
   1. Achievements
   2. Advancements
   3. Sounds
   4. Data values (if applicable)
      1. ID
      2. Metadata
      3. Block states
      4. Item data
      5. Block data / entity data
   5. Video (if present for illustration)
   6. History
   7. Issues
   8. See also
   9. Trivia (avoid or minimize if possible)
   10. Gallery
   11. Notes and/or references (capture all citations from above sections; this can be two sections)
   12. External links
4. End matter
   1. Applicable footer templates / navboxes
   2. DEFAULTSORT
   3. Categories
   4. Interwikis

What do you think? Thejoaqui777 (talk) 18:32, 26 March 2021 (UTC)

@Thejoaqui777:, I support this but how is anybody going to remember like 40 different things? I don't want to go back and forth. Maybe add it to the editing message box? Also, maybe a project should be made to change the order of every single page as there is an enourmous inconsistancy, mixed up sections, hatnotes, infoboxes, message boxes, it's chaos.Humiebee^{talk contribs} 22:21, 1 April 2021 (UTC)

All suggestions so far are missing the advancement and achievement sections. Please add them.

Under data values, metadata, block states and entity data are also missing; I'd suggest the order ID, metadata, block states, item data, block data, entity data (which is already the order they should have right now). Dhranios (talk) (Join the wiki videos project!) 22:23, 26 March 2021 (UTC)

 Comment: You are right, I'll add them to my proposal. Thejoaqui777 (talk) 23:39, 26 March 2021 (UTC)

I'd merge Achievements and Advancements. Call it "Advancements (if Java) or Achievements (if Bedrock)". They are the same section with the same function and essentially similar content, but with different names.

Also, on Wikipedia the practice is to put the stub template at the bottom, as it isn't really a maintenance template, but functions similar to a category. An experience Wikipedia editor coming here would get confused by a requirement to put it at the top. Amatulic (talk) 21:29, 1 April 2021 (UTC)

That's way too long for a header title, and helps almost no page, as almost every one that has one has the other too. We really don't need to change them, just make the order consistent. Dhranios (talk) (Join the wiki videos project!) 22:14, 1 April 2021 (UTC)

Not really keen on capitalization rules

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

User has failed to make a valid point for their cause. And when asked to give an explanation, they responded with nonsense. This whole proposal contradicts English grammar rules as Dhranios said so it will never be implemented, even with support. James Haydon (talk) 16:02, 23 March 2021 (UTC)

---

Enchantment names and potion effects such as “silk touch” and “fire resistance” do not deserve to be proper nouns. If block & item, mob and structure names are common nouns, it would only make sense for names of potion effects and enchantments to be common nouns as well.

Names of gamemodes do not deserve to be proper nouns either due to English capitalization rules. Dimension names should be common nouns as well. —SeriousError 14:02, 19 March 2021 (UTC)

A proper noun is a specific (i.e., not generic) name for a particular person, place, or thing. Enchantments and effects are specific names for things, dimensions are specifuc nanes for places, gamemodes are specific names for things. Simple as that. "Sheep" is not a specific name for a being, "dirt" is not a specific name for a block, "stick" is not a specific name for an item.  Biggest oppose ever as this is directly contradicting English grammar rules. Dhranios (talk) (Join the wiki videos project!) 14:22, 19 March 2021 (UTC)

You don’t know how English works. It’s more complicated than that.—SeriousError 14:28, 19 March 2021 (UTC)

Mind to give a full explanation then? Because Dhranios' point seems pretty valid. James Haydon (talk) 14:30, 19 March 2021 (UTC)

By all means, explain it then. I literally just looked up the actual definition of when something is a proper noun. Prove me wrong. Dhranios (talk) (Join the wiki videos project!) 14:31, 19 March 2021 (UTC)

SYSTEM ALERT CODE: 871–SeriousError 14:39, 19 March 2021 (UTC)

Wow, not even a proper response, let alone arguments.

Proper nouns:

Names of people and pets, geographical locations and astronomical names/planets, months, days of the week and hollidays, publications, books, schools, nonprofit organizations, companies and brand names, cities, states, countries and continents, religions/faiths, places, titles, course names (eg Economics 101), historical periods, languages/nationalities, etc. it all boils down to the simple rule above "specific names, VS generic names". A specific gamemode, a specific enchantment, a specific effect. (edit after edit conflict resolve) Auldrick is right in the small correction that context matters, if there were multiple dimensions named "Nether", it would not be capitalized, but there is only one. Dhranios (talk) (Join the wiki videos project!) 14:48, 19 March 2021 (UTC)

"The Overworld" and "The Nether" are specific names for particular dimensions. Whether a noun is proper or common is not a characteristic of the word itself but of what it refers to. You can't just say "the overworld" is a common noun, you have to consider whether what it refers to in the surrounding context is generic or specific. In Minecraft, there are several dimensions but only one called the Overworld, so it's specific. Similar arguments apply to other things you've lowercased. "Manual of Style" refers to a specific set of guidelines or a specific page. If it were "a manual of style", that would be a common noun, but with the definite article or without an article it's a proper noun because of what it refers to. Also, please sign your contributions with "~~~~". — Auldrick (talk · contribs) 14:41, 19 March 2021 (UTC)

 Very strong strong strong oppose per Dhranios. TheGreatSpring (talk | contribs) (Tagalog translation) 00:51, 20 March 2021 (UTC)

Formatting filenames

Filenames on this wiki always seem to be formatted with <samp>, including in article titles. The <samp> tag is reserved for denoting sample output, but filenames are usually not outputs. I think we should avoid using any monospace formatting in headings and the bolded word, and use <span style="font-family: monospace, monospace;"> (which could be used in a new template) for other instances of filenames. Fadyblok240 (talk) 21:06, 27 March 2021 (UTC)

Wiki Rules

I think the Wiki Rules under Notability should be enumerated 1. 2. 3. to match the rest of the article or for the rest of the rules to be added. Starting the list with 4. seems messy. DeeFeeCee (talk) 21:33, 3 April 2021 (UTC)

Those numbers are referring to the wiki rules 4 5 and 6 directly. Numbering them 1 2 and 3 will be misleading as the rule numbers then don't correspond with the numbers on MCW:RULES Dhranios (talk) (Join the wiki videos project!) 21:55, 3 April 2021 (UTC)

Are the first 3 rules unnecessary to include then? DeeFeeCee (talk) 00:30, 5 April 2021 (UTC)

Capitalization of proper nouns in display names

Should proper nouns in item/block/structure names be capitalized? For example, should it be "a nether fortress" or "a Nether fortress", "an end portal frame" or "an End portal frame"? I think the later would make sense, that's applied somewhat in real life where location and demonyms are capitalised even if they're part of a bigger noun (i.e. "Asian elephant", "Portland cement"). Is there an in-game instance of either case where we can reference from? Pescavelho (talk) 09:47, 9 April 2021 (UTC)

Personally I've been writing "a Nether fortress" following normal English usage, so  Support standardizing this.  Nixinova   T   C   02:57, 11 April 2021 (UTC)

It's already been standardized in MCW:CAPS: "Proper nouns, however, such as the Nether or the Overworld should always be capitalized." Is that not clear enough? — Auldrick (talk · contribs) 03:06, 11 April 2021 (UTC)

That could be read as 'the terms themselves' and exclude derivatives, however. Adding "and all derivative forms" would clear it up.  Nixinova   T   C   03:12, 11 April 2021 (UTC)

 Support this – would clear up some ambiguity with stuff like "Enderman" (which used to be listed in lowercase as recent as this February). –Sonicwave ^talk 04:01, 11 April 2021 (UTC)

Some words like "netherrack" or "Enderman" (i.e. composite words which incorporate location names into the etymology) itself are inconsistently capitalised, I assume those would be addressed on a case by case basis or if there is any precedent from official sources to capitalise/uncapitalise. Pescavelho (talk) 17:19, 11 April 2021 (UTC)

 Comment: "Enderman" should be capitalized, however "netherrack" shouldn't be capitalized, as it talks about a fantasy element that it's common, making it a common noun and not a proper noun. For example, "blackstone" isn't capitalized, and it's a fantasy element. Thejoaqui777 (talk) 18:19, 11 April 2021 (UTC)

Well, in the example provided in the article, "Blazes spawn in nether fortresses." would seem to contradict that notion, that should probably be cleared up then. Pescavelho (talk) 10:05, 11 April 2021 (UTC)

Ah, I'm surprised I didn't notice that, as I've been focused on MCW:CAPS several times lately. Looks like we need to discuss it after all. I personally feel that Nether, Overworld, and End should be capitalized in any context (except, of course, "end" when not referring to the dimension). — Auldrick (talk · contribs) 10:13, 11 April 2021 (UTC)

Article naming for items with edition conflicts

Auldrick recently changed the naming guideline to avoid preferring a specific edition where the name differs between Java and Bedrock. While I don't oppose this principle in general, I disagree with this change and have reverted it for several reasons. The current guideline clearly outlines the criteria to use in case of conflicts, and is consistent across the wiki as the Java name is used in most cases. The changed one (which just says to use any name) is vague and doesn't help resolve conflicts, and therefore might as well not be mentioned on the style guide at all.

In addition, I believe the reasoning for using Java names is because Java has undergone the Flattening which renamed many blocks and items, whereas Bedrock hasn't gone through such a large-scale change yet. I haven't yet found a source suggesting that Bedrock plans to update to the Flattening names, but if these name discrepancies will be resolved eventually, it'd make more sense for them to choose the newer post-Flattening names instead of reverting to the old ones.

In any case, the previous guideline has been the de facto behavior on the wiki for a while now (e.g. Spawner, Daylight Detector, Milk Bucket, Redstone Dust before Bedrock renamed it) and should be discussed first before changing. The discussions on MCT:Projects/Renaming are several years old (before the Flattening) and don't really focus on article titles, just the treatment of editions on the wiki in general; so I don't think they apply here. I would not be opposed to rephrasing the guidelines to keep the same spirit but be less Java-centric; e.g. "If the feature has different names in multiple editions, the more recently changed name should be used". –Sonicwave ^talk 23:43, 10 April 2021 (UTC)

I'm pretty sure Bedrock is confirmed to receive the flattening eventually, which I assume would include the names. -PancakeIdentity (talk) 07:38, 11 April 2021 (UTC)

I didn't follow how the Flattening was relevant in the first place. Doesn't it just change the namespaced IDs? We don't use those for article titles, so how does it have any effect? And anyway, I think Bedrock has already been flattened, at least partly. We have new alias names for variants that were identified by a name/DV pair, and you can now use either one in commands. (Backward compatibility for old command blocks.) I have no idea whether they've changed the identifiers in stored data, but I don't see any reason they would need to, either. — Auldrick (talk · contribs) 09:58, 11 April 2021 (UTC)

Java 1.13 changed the names of some blocks and items in addition to the IDs. –Sonicwave ^talk 23:25, 11 April 2021 (UTC)

I fully expected this reversion and made the edit deliberately with the intention of evoking discussion and consensus building. I take issue with almost everything you're saying, but in order not to monopolize the page I'll skip the blow-by-blow and just address what I see as a pattern of problematic behavior that this wiki has tolerated for 3 1/2 years.

The "current guideline" is the product of a single editor on 17 December 2020. It was a time when a large fraction of our English-fluent editors would likely have been preoccupied with preparations for the holidays, so it probably got very little scrutiny, if any. And it was done without discussion, with an edit summary claiming, "they've been used for years, just solidifying them in the style guide now". (As if elevating a simple habit to the level of a guideline, thereby imposing it on all editors, is a trivial matter.) This was an obvious attempt to deflect any objections to the way it evades the normal wiki process of building a consensus. But let's look at where this so-called "de facto behavior" originated.

In the summer of 2018, a group of people got together on Discord to discuss upcoming changes to some Java block names, which I guess was in support of the Flattening. Not long after, several of these pages were moved to the new Java names with edit summaries referring to "a consensus reached on Discord" and mentions that these blocks were scheduled to be renamed on Bedrock as well. This had the desired effect of forestalling objections to the name change, since it would benefit both editions equally. However, I have many concerns about how the situation.

1. A live discussion off-wiki cannot possibly arrive at a consensus of the wiki's editors. Editors come from every time zone. Many would be working, sleeping, or eating at the meeting time. Some people can't install Discord or can't connect to the server. Some people just don't want to install it and can't be compelled to in order to preserve their right to participate. Maybe some people couldn't be present the whole time.
2. Discord doesn't record anything. Anything that might have been concluded is simply hearsay, as there is no record of it. And I'm sure we all know how fallible human memory is. What's been called a consensus might have been an agreement among 5 people after everybody else left. That's not a consensus, it's a cabal. Who's to say what really happened? Only the messenger delivering the self-serving message.
3. At the time of the Discord meeting, we already had an established consensus that no edition would be given priority. Yet somehow the meeting outcome was in direct contravention of it. Obviously, it was regarded as an inconvenience to be circumvented, or simply ignored.
4. It was said that Bedrock would be changing its names too, but nobody can source that claim (and of course, there's no record of who said it or how they knew it). It was plausible enough to be believed, but in fact it has so far not turned out to be true. Thus there is no evidence to refute a belief that it was a pure invention designed to blunt complaints from the Bedrock side that Java was being given priority.

So now the argument is that this illegitimate "consensus" has become a de facto guideline through long use and shouldn't be modified without discussion. And by the way, it's been a guideline for three months so it's already canon. Never mind that there's no hard evidence that it was ever really discussed at all. Never mind that it conflicts with an established and documented consensus. Granted that MCW:Projects/Renaming was a year or so old at the time, but at least it was on the record. And it still is, though that doesn't seem to mean anything to some people.

My reversion was reverted for failure to discuss it first. Ok, then where was this insistence on formality when the December edit was done? Or any of the dozen other edits, some of them rule changes, since then? Isn't it curious how formality only seems to matter when Java stands to lose some of its undeserved privilege. — Auldrick (talk · contribs) 09:58, 11 April 2021 (UTC)

I agree that important decisions like these should be made on-wiki and not based solely on Discord, it's even one of the server rules. My impression was that this was discussed on-wiki as well, but I could be misremembering the extent of discussion. To be honest I would be fine with removing the current guideline until we come to a conclusion, but not replacing it with something that contradicts current behavior (for the reasons stated in my previous comment). Regarding your last point, I went through most of the unique blocks/items on Java Edition 1.13/Flattening#Names, and for roughly 1/3 of them that had name conflicts after Update Aquatic (JE 1.13 and BE 1.6.0), Bedrock changed to Java's name at some point while Java's have largely stayed unchanged; so it seems like a reasonable assumption to make. –Sonicwave ^talk 23:25, 11 April 2021 (UTC)

Auldrick is referring to this undiscussed change], subsequent and proper revert, and then the nonsensical restoration of the change with an admonition about making undiscussed changes!

Can we just remove it? The editor who added it (Dhranios) was apparently having other problems around that time which led to his disappearance.

I also strongly oppose this change because if we are to give naming priority to one edition, it should be Bedrock because that has the larger installed base, so it's likely that most of the readers are coming from Bedrock anyway. I'd rather not give priority to either one and revert it back to the previous version that has consensus. Amatulic (talk) 20:00, 21 May 2021 (UTC)

I feel like I need to clarify some things:

The edit was the consensus for years (yes, years, not some short timespan) based on moves, splits, merges and new creations; that is why I felt fine ammending the style guide to propperly adress it based on said consensus.

Bedrock has a lot more conflicting and older names (with conflicting, I mean both reused names and names that are just inconsistent with one another), this is why it is objectively better to follow the java names where possible, which (SonicWave) are all the newest names in the game, so "newest name first" would have the same result.

The other edit issue, and me leaving should not be an argument to revert things.

I did not "choose to edit at this specific time to hide it", better yet, I didn't care for when I did this, nor is hiding edits possible. You are interested in this page, so you should be watching it in the first place. You get notifications and emails of edits to pages you watch, and it is listed in recent changes too, both on wiki and the discord. Do not use your own incompetence as an argument to villainize me, this is exactly the kind of crap I've received all over the community, and THAT is why I deleted my wiki account.

As for the flattening naming changes coming to bedrock source, that was Helen. And don't go pull that "things may have changed" crap, as with that logic, every single mentioned but not implemented idea may also just be removed from the wiki, even if shared seconds ago, because a decision to not do that may've come seconds after. The message proving this is (IIRC) somewhere in the discord, but I'm not going to look for it, as I quit.

This message is not me coming back, it is me defending myself from the horror that is the Minecraft community. I'm not going to help you anymore. I used to help the community with a smile from 2012 to 2021, but that's over. I've received way to much crap from it in return, everywhere I went. Mojira, the Minecraft discord, the wiki, the various subreddits (and corresponding discords)... I'm done! I'm no longer on the public end of the community, and will never return. 86.90.184.130 06:49, 25 May 2021 (UTC)