Latest comment: 6 May 20257 comments7 people in discussion
In the phrase "potion of <effect>" the current style guide implies that <effect> should use the in-game capitalization (per MCW:CAPS) and the rest of the text should use normal (prose / paragraph) capitalization.
Question 1: should we format potions in that way?
Is "potion of Regeneration" better than "potion of regeneration" and "potion of Regeneration"?
Also, is "potion of Regeneration" better than "potion of regeneration" and "potion of Regeneration"?
Keep in mind, this discussion applies equally to "splash potion of <effect>", "lingering potion of <effect>", and "arrow of <effect>". Thus "potion" (in this discussion) is a shorthand for all 4.
However, what about "potion of <in-game potion effect name>"? The <in-game potion effect name> is sometimes different from the normal in-game name of the status effect:
Question 2 is simple: should potions with different names than their effects follow the same capitalization rules as potions with the same name as their effects?
For Question 1: I like effects being capitalized, but I think "potion", "splash potion", "lingering potion", and "arrow" should also be capitalized in this context. I know that items are usually lowercase, but to me "potion of Fire Resistance" looks a little awkward; I think "Potion of Fire Resistance" looks better. The oddest one is "potion of the Turtle Master"; Turtle Master isn't even an effect, we're just mimicking the style used for effects. If one part of the item name is capitalized, the rest of it should inherit the capitalization, too.
For Question 2: Yes, same capitalization. Even if the names don't match exactly, it's too arbitrary to say "potion of Fire Resistance" is correct, but "potion of Wind Charging" is incorrect. Rampage455 (talk) 13:18, 3 September 2024 (UTC)
I also feel like they (potions, arrow, etc.) should be capitalized. Obviously Im not going to go against the style guide here, but outside of the wiki I always capitalize them. It just has a better look and vibe that way 👁 Image amethyst_hhh(talk)(quiz)00:19, 6 May 2025 (UTC)
I agree. The word "potion" or "arrow" should be lowercase, and the effect it has should be title case. – Unsigned comment added by Anachronist (talk • contribs) at 20:42, 6 May 2025 (UTC). Please sign comments with ~~~~
👁 Image Disagree, potions are common nouns. Keeping them lowercased is being consistent with other lettercasing rules like "Nether portal" where the dimension is capitalized while the described noun is lowercased 👁 Image QwertyLilley [ talk ] 22:56, 6 May 2025 (UTC)
Latest comment: 6 May 202511 comments7 people in discussion
Two of the sentences in the lead say, "Although Wikipedia already provides a more general style guide, a more specific one is necessary for Minecraft-specific guidelines. As such, only guidelines pertaining to the Minecraft Wiki and its basic formatting rules are included here." This seems to imply (almost inescapably) that this style guide only includes Minecraft-specific guidelines and that, otherwise, we are to apply Wikipedia's style standards. If that is what we intended, then we should state that clearly at the very beginning. If that's not what we intended, then what exactly did we intend? What style standards do we refer to when this style guide does not cover a particular style issue? Thank you. HolyT (talk) 21:22, 3 October 2024 (UTC)
Probably just a dated sentence from when the wiki was new. These days we always say that Wikipedia policies don't apply here, they just can be referenced if there is no specific policy here. However, generally if we need any policy that is not covered here we should just implement it instead of deferring to Wikipedia; their polices are designed for a very different type of wiki along with a very different volume of editors. Probably best to change the tone of that sentence to still be a reference to WP's style guide but explain how it does not apply here, but can be referenced if no policy exists. –KnightMiner(t/c)23:14, 5 October 2024 (UTC)
However, except for the capitalization rules for article titles, we tend to follow Wikipedia conventions here anyway. You're probably correct that the statement is a holdover from when this wiki's style conventions weren't fully defined, but there's no reason why the Wikipedia style guide (which is not "more general" it's quite specific, comprehensive, and spans across several chapters) shouldn't be deferred to for things our guide doesn't address. When such cases are found, we can expand our guide accordingly. Over time, the Wikipedia style guide would be needed less and less. ~Anachronist (talk) 00:59, 6 October 2024 (UTC)
This is a great argument (or two) for formally stating that we default to Wikipedia's standards when the Minecraft style guide is silent. If we don't have a general statement, the editor is left without guidance. If our answer is that we should add to our own style guide when we don't have guidance, we will ultimately have to write tons of style guidance that duplicates what has already been hashed out and refined in Wikipedia for decades. Because we have a much smaller set of editors, our efforts at recreating a full style guide will inevitably be clunkier, slower, and less comprehensive. Let's keep things easier for ourselves by having an overarching standard, knowing that we can always make our own standards, specific to our needs, that differ from the default guidance.
I think that "more general" in the sentence in the lead is fitting because it means that Wikipedia's style guide is for a vast encyclopedia covering almost every imaginable topic (i.e., it covers encyclopedic writing in general), whereas this style guide, e.g., is for coverage of a specific video game. Wikipedia's style guide is "more general" in that it is written to cover every type of writing and encyclopedic content in its vast scope, while "a more specific" style guide is required for the types of writing, tables, illustrations, and so forth that are specific to our field (Minecraft). Of course, every style guide seeks to be "specific" in explaining its guidance and standards. HolyT (talk) 18:56, 14 October 2024 (UTC)
I generally disagree with falling back to Wikipedia guidelines that aren't explicitly called out here. Wikipedia and our wiki have very different communities and goals and we are both constantly evolving. We should port over the guidelines the wiki is already adhering to so we can continue growing them in our own way. Mudscape👁 Image talk19:08, 14 October 2024 (UTC)
Porting over the existing Wikipedia guidelines is impractical because they are so vast, and this wiki has a much narrower scope. I think it's sufficient and correct for the lead section of our style guide to say what it already says. For the most part, like with capitalization, heading styles, and layouts, we already use the Wikipedia guidelines adapted for documenting Minecraft. ~Anachronist (talk) 19:13, 14 October 2024 (UTC)
👁 Image Comment: Personally I think we should not fallback to Wikipedia for these policies. Many stuff that are policies, guidelines or essays on WP generally tend to cover mostly Wikipedia-focused topics and environments. While yes, WP has worked on its guidelines for so much years and that is to be respected, these are unrelated to the Minecraft francise reality that our wiki covers.
I really think we should adapt some of Wikipedia's guidelines and include them on our wiki, whether they are copied or fully reworked, and make them work in this wiki's environment. There is no harm to include more guideline pages on the wiki as long as they are properly organized and make sense in the wiki. Supeika (talk) 16:46, 3 March 2025 (UTC)
Completely agree, it is clear that we already do not follow all of Wikipedias guidelines and the blanket statement has caused multiple new editors to try and apply the "correct" style from Wikipedia which actually doesn't fit in with how our wiki currently does things. The style guide is just that, a guide, it doesn't need to cover everything, and it certainly doesn't need to defer to Wikipedia guidelines of which we have no control over. Mudscape👁 Image talk16:57, 3 March 2025 (UTC)
👁 Image Comment I think Wikipedia should be a fallback. The Style guide will always take precedent anyway so any conflicts can easily be referred to our guide. Additionally, when creating clearer, more general and more formal writing, it's useful to refer to their Manual of Style. This is especially needed for the Movie namespace when it can sometimes derive away from the base game and I found it useful using Wikipedia to help my writing. 👁 Image Ayaan07:27, 6 May 2025 (UTC)
Latest comment: 9 January22 comments10 people in discussion
...don't exist. I think that there should be a standard for intro texts, because I want to standardize them so as too provide more consistency. I have made a couple of edits to some, but I am not confident about them and should be checked by a more experienced user. These guidelines, if any, should include details on what information to include and how to write the intro text. -~-Nerdyguy2000TalkEdits00:44, 17 October 2024 (UTC)
Do you have a proposal for what an intro text should look like in your opinion? Personally I find the intro texts currently to be a bit too short usually, but I'm not sure what I would add. | violine1101(talk)20:21, 19 October 2024 (UTC)
I have lots of ideas! Thing is, I didn't presently have time to list all of them... But there are lots of little things wrong with intro texts currently. The first inconsistency is that they sometimes say, "__s are __s that..." Rather than "A __ is a __ that..." I'm personally favoring the first one, but I'm just one user. This is what I think:
Introduction texts should be very brief summaries about the topic of the page. The following should be added to introduction texts about blocks and items:
How to get/use a block or item
How a block forms or naturally generates within the world (e.g. obsidian forming when water touches lava)
How common the resource is
Where the item is found as loot
What kind of item/block it is
Only some of those should be included depending on how many are needed. Intro texts should go like this:
"(Name of topic)s are (block/item/tool/etc) that can be obtained by (mining __/trading/etc) and are used to craft (__). It is ......"
Although this topic has been quite inactive, I feel it should be said that, as I said, "__s are __s that..." Rather than "A __ is a __ that..." Would be more consistent because some things have plural names, so that would be the only way consistency could be achieved. -~-Nerdyguy2000TalkEdits15:27, 28 November 2024 (UTC)
MCW:FEATURE#Introduction has a brief section about intro texts which isn't much to go off of. The fact that it states "briefly describe the article's most important points" probably makes it general enough to cover bases for now. However, I think intros should explicitly fit an additional criteria that it needs to allow readers to gain a brief understanding of what the feature is and how it behaves. They should perhaps also avoid overly technical information, and do not need to be exhaustive, such that they are useful to readers unfamiliar with Minecraft without overwhelming them or requiring too much prerequisite information from elsewhere.
In my opinion, many intros have been excessively been shortened when the style guide rewrite was first implemented back in 2014, many of them being reduced to a single sentence. For example, the current intro for Skeleton states "A skeleton is an undead hostile mob that performs ranged attacks with a bow.", which is technically sufficient but still very terse, and leaves out key information which familiar players would easily associate with the mob, namely that it's a common nighttime mob and burns in sunlight, and are important resources for obtaining bones and gunpowder. The creeper intro is much better and probably one of our better examples, though it still lacks the nighttime information.
I think a good place to start would be to incorporate some form of the guideline in my first paragraph, and expand existing intros in the meantime, perhaps looking pre-2014 style guide changes for inspiration though not necessarily copying them verbatim. I don't think we need specific points like obtaining/usage for now; we can add them later if necessary or we happen to fall on a consistent format meeting these points.
I do also think it's a good idea to standardize whether the subject should be introduced in plural or singular, with preference towards the former, or at least avoiding the slightly awkward "A ___ is...". I'm not sure if there's been enough discussion to define it in the guideline, but perhaps we can work on standardizing it for now and see if more feedback pops up or if it runs into issues. –Sonicwavetalk19:38, 26 June 2025 (UTC)
I agree that leads should be more than just a sentence. Summarise the feature as tersely as possible while still providing a good overview. Version pages have very good leads, I think. Current lead for skeleton is good. General form for a feature should roughly be "<X> is a <category>. <short obtaining>, <short usage> or <short spawning>, <short behavior>. Basically, should touch for half a sentence on each page section. NixinovaTC08:35, 28 July 2025 (UTC)
Reviving this. It's important we have some guidelines on lead sections.
We should add a section saying that the lead should be a short and simply summary of the topic, describing its most important features.
One important addition that I think we need (that prompted me coming here to propose) is that any topic not about the base game that is in mainspace needs to have the context there in the lead ("X is a [shortdesc] "). NixinovaT ⁄ C05:27, 21 October 2025 (UTC)
Not for ones with namespaces no. If a feature is from its namespace, like Creeper Woods in the Dungeons namespace, it does not need to state where its from. Each namespace acts as a wiki specifically for its respective game. If a feature is not directly from the game corresponding to its namespace, then yes, it should be stated where it's from or what type of thing it is. -- Simanelix(T|C)19:52, 21 October 2025 (UTC)
It's not needed unless it's from a secondary/minor/obscure installment covered by a namespace (e.g. for mainspace I would count joke versions, non-Java or Bedrock editions, all side material such as books, or YouTube videos as secondary/minor/obscure). Saying that a rainbow sheep appears in Minecraft Earth while you are browsing the Earth namespace is redundant.--Capopanzo (talk | contribs) 19:58, 21 October 2025 (UTC) - edited Capopanzo (talk | contribs) 23:16, 21 October 2025 (UTC)
I feel like MCE should be an exception, because otherwise the thing would just say "X was a block/item" which doesnt look good when there is absolutely no text on the page except for headers, whatevers in the infobox, and the navbox. 👁 Image amethyst_hhh👁 Image 23:19, 21 October 2025 (UTC)
Just going off my intuition here. The intro should have the following:
What type of thing is this? Block, item, structure, mechanic, song, etc. State this directly. "Crafting is a mechanic...". In the case of mechanics, you could just describe the usage / what id does instead.
Summarize the most useful or relevant parts of the Usage, Behavior, Obtaining, or Spawning sections. Keep this very short.
Avoid trivia.
Avoid describing the appearnace unless the feature exists primarily for decoration of aesthetic purposes. In which case, state its decoration of aesthetic purposes upfront.
If it is primarily designed as a redstone component, it might be helpful to summarize its redstone functionality.
Yes, exactly. #2 and #4 only apply to feature articles. Other articles can and should describe the appearance of something, especially if that is a defining trait. And an intro should try to summarize any other relevant parts of the article, unless it would be too confusing. Similarly, an intro can describe the history of its topic. And any other details are fair game, really. What belongs in an individual article's intro is upto consensus. Some people would call that "common sense", but "common sense" is an insulting term that discourages discussion. So I think consensus is the better term. -- Simanelix (T|C)18:38, 9 January 2026 (UTC)
Other articles can and should describe the appearance of something, especially if that is a defining trait. And an intro should try to summarize any other relevant parts of the article, unless it would be too confusing. Similarly, an intro can describe the history of its topic. <...>
I think these first few points could generally fit into the style guide/proposal, or, if MCW:FEATURES were ever to split, separate intro guidelines could be written for different types of articles. Outrowed (talk) 19:18, 9 January 2026 (UTC)
Latest comment: 9 January3 comments3 people in discussion
Some pages have all “out of game” history like announcements and tweets at the start of the history section, some have them placed chronologically among the Java Edition history. The style guide doesn’t say which is correct. SprouSprou (talk) 17:37, 19 October 2024 (UTC)
Items especially need to be evaluated, right now there’s no separation between an object in the narrative, a usable item, and a prop that a character happens to use. Realshow19 (talk) 01:45, 15 December 2024 (UTC)
I guess we could start by sorting them in MCSM:Item first. How about Items that hold significance in the story, Items used for crafting, building, etc, and Items used as props as section names? QwertyLilley (talk) 03:43, 17 December 2024 (UTC)
A bit of a pet peeve of mine is what to do with older images, like this one. I support documenting them, but galleries are supposed to be up to date. A lot of the time they get pushed up to below the history tables, but a basic banner like this is hardy the same as development screenshots. Realshow19 (talk) 21:39, 18 December 2024 (UTC)
Latest comment: 25 February 202524 comments9 people in discussion
This is a minor issue, but I think we should settle on where we place quotes. The consensus among Project DLC members is that quotes should go in their own dedicated section, since they don't work at the top of others on mobile. This is also how character and movie pages have generally been operating. Problem is, the Dungeons namespace is pretty reliant on them being a header. I tried moving them in a few pages I was already updating, and someone took this as vandalism. I think we should just make it consistent across the board. Realshow19 (talk) 17:26, 31 January 2025 (UTC)
Can you link some examples? Not really familiar with Dungeons, but if it's in-game descriptions/flavor text, I would add it to the infoboxes.--Capopanzo (talk | contribs) 17:30, 31 January 2025 (UTC)
I took a look at the examples on my phone and I’m not seeing any minor or major issues. The pages seem to display fine, and I don’t quite understand how this creates a problem for editors. Could you provide more context or a specific instance where this has caused trouble? Also linking to the Project DLC consensus on this would be really helpful for context too. Thanks! -BrianGLHF (talk) 21:22, 31 January 2025 (UTC)
In simple terms, it's what helps us ensure pages are seen by the most people in search engines, in some cases before Fandom. Realshow19 (talk) 21:12, 31 January 2025 (UTC)
Our work isn't of much worth if no one can find it because we do everything Google hates. SEO shouldn't be used as a reason to make poor changes to the wiki, but it's still a notable thing we should keep in our minds at least a tiny bit. - Harristic / Talk👁 Image 00:31, 25 February 2025 (UTC)
I think the current way of adding quotes is "it feels correct" to put it here. I like the idea because now it's concretely said what's correct and what's incorrect. 👁 Image Ayaan21:33, 31 January 2025 (UTC)
See also the relevant discussion from 2019 about longer introduction text and quotes, where we decided to remove quotes from the page intros. Quotes in the intro are the first thing anyone sees while they don't provide any value to the reader, taking up the important space at the top of the page where more useful content should be. They commonly also get picked up as page description by search engines like Google, which is not useful for anyone looking for the relevant page. As such, quotes should be limited to a dedicated section instead of the page intro. -- 👁 Image MarkusRost (talk) 21:51, 31 January 2025 (UTC)
Another thing just occurred to me, how would we feel about adding a quotes section to vanilla pages? Most major features already link to Minecraft.net articles at the bottom, wouldn’t exactly save space but quoting them instead of linking them where people probably miss them might be handy. Realshow19 (talk) 00:12, 2 February 2025 (UTC)
It should certainly be a section imo. As a reader I would much rather the first thing I see on a page be the editor-written description of the topic (because it is written to be useful) than the editorialised comment made by one person. - Harristic / Talk👁 Image 00:33, 25 February 2025 (UTC)
Latest comment: 3 February 20252 comments2 people in discussion
I looked at this style guide and found the beautiful table about trees and planks. Then I looked at the pages Trees and Planks and was appaled. Not only was there no simple beautiful table listing all the wood types, but there is so so much clutter. This is a general problem for all blocks and probably more pages. How can I help make this better? I'm new and definitly don't feel comfortable to just delete huge sections of clutter without talking to someone first. --Pelznymphe (talk) 01:04, 3 February 2025 (UTC)
Hello and welcome to the wiki! One of the best things about wiki's is its impossible to permanently break something, all pages have a full history and its only a few clicks to undo your edit if you get something wrong. I am surprised there isn't a nice table on those pages, that definitely feels like it'll be an improvement. You should be able to just copy and paste the table, but if you have any more questions about editing you can ask here, on my talk page, or on discord and other editors will be happy to help you out. Mudscape👁 Image talk01:11, 3 February 2025 (UTC)
There is no use for having "File:", infoboxes don't have it either, but visual editor adds it automatically and I don't know if we are able to change that. - Harristic / Talk👁 Image 18:27, 24 February 2025 (UTC)
I think this is one of those things where a standard hurts more than it helps. It looks identical to the end user, and it's equally clear either way to editors. Enforcing one way or the other is just extra work for no real benefit. Mudscape👁 Image talk18:30, 24 February 2025 (UTC)
I only say this because I see constantly people adding and removing File: to galleries (and I question myself everything if I'm doing it correctly) 👁 Image Ayaan18:40, 24 February 2025 (UTC)
I'd say just make sure it's consistent within any article, but otherwise leave them alone, it doesn't matter to the reader.
I think it's time we added a note to the style guide that says that it's not needed, but if you come across it, don't bother to change it because the next time somebody edits the article with the visual editor, it will be automatically readded. It's a common point of confusion; I've seen multiple people ask about this since I started editing the wiki. I think the reason the visual editor defaults to adding the prefix is because the wiki uses MediaWiki, which recommends adding the File prefix to help distinguish image file names from other wikitext. Rampage455 (talk) 22:11, 24 February 2025 (UTC)
I once came across an edit that removed it and started removing it, but it was unnecessary. I'm not proud of it, but there's a topic in my talk page archives about it if anyone cares. I'd say that it should be kept for clarification, but left alone if not within gallery. -~-Nerdyguy2000TalkEdits23:20, 24 February 2025 (UTC)
👁 Image Commenting that everyone forgot to use the {{c}} template (kinda joke). In any case, now being serious, I'm inclined to agree with Rampage's proposal, it's the most logical one long term and would solve once and for all this inconsistency. If there is one without File:, it's fine but not needed to add it. The only situation where it would be needed to remove the prefix is in the hypothetical situation where page byte size actually caused issues because of those small bits of text, which is unlikely to happen as of now due to page splitting and more caution when handling galleries. So, yeah, I support their proposal :D -- Supeika (talk) 23:38, 24 February 2025 (UTC)
I think the standard is no prefix, but it gets automatically added with the visual editor, so there's nothing we can do about it. It's like [[Apple|apples]] vs. [[apple]]s, where the visual editor just doesn't allow that. This is a bit different, as the visual editor kinda just forces it to be back for some reason. --MinecraftExp123(talk|contribs)00:30, 25 February 2025 (UTC)
Latest comment: 25 February 20252 comments2 people in discussion
With the franchise expanding into more mediums I think it's important that we prepare for more pages on narratives, and the like. I mostly do EU pages myself, namely DLC and videos. I think I've got a good idea how those pages should look, we even have a template for map pages, but nothing is formally written down yet. For character pages I think it's especially important, I've found plenty of duds and studs which don't really know how they should look. Realshow19 (talk) 00:22, 25 February 2025 (UTC)
Latest comment: 2 March 20253 comments2 people in discussion
We should have a section or a subsection in the style guide about making citations. I have seen pages that have citations only having raw links, which isn't really descriptive as it doesn't have enough context what is being cited, and some links can get really long which isn't nice to see especially if there are many of them. I recently just found out that citation templates exist, those templates are pretty much unknown and was never mentioned anywhere, an editor will only find out about them if they are editing a page that uses them. We should have them in the style guide.
{{Citation}}, {{Cite bug}}, {{Cite Discord}}, {{Cite Instagram}}, and {{Tumblr}}, to name a few. 👁 Image QwertyLilley [talk] 02:17, 2 March 2025 (UTC)
I wouldn't mind something in the style guide that says to format citations neatly; although you don't necessarily have to use those templates to do so, but they are convenient. On a side note, I've also experienced what you're describing; essentially, the wiki has many tools for many situations and you don't always know they exist until you edit an article that uses one of them. If you'd like to help with that, Help:Contents could use a good amount of work. Every once in a while I think about adding to one of those articles, but I always forget they exist because the only link to the category is at the top right of the main page. I should probably ask if they could add a link on the sidebar; they should be a very important set of pages, but they are very much neglected. Rampage455 (talk) 03:34, 2 March 2025 (UTC)
Oh I'd love to contribute to that, thanks for redirecting me there. I'll make a page about the tools or a section on an appropriate page that already exists. 👁 Image QwertyLilley [talk] 04:51, 2 March 2025 (UTC)
Latest comment: 12 May 20252 comments1 person in discussion
The style guide states that any name of mobs should be treated as a common noun, unless it is referred to as a proper noun. The guide also states that names of characters should always be capitalized.
The wither storm is both a mob and a character. Yet one of the examples in the guide treats the wither storm as a common noun. The wither storm is capitalized in-game, but we also don't follow official sources' capitalizations like for endermen (Story Mode also capitalizes endermen)
Proper nouns usually refer to unique things. However, the wither storm is not unique as it is recreatable like regular withers and iron golems. Even the command block is recreatable as one of the characters, Ellegaard, attempted to make one. Her attempts materializes a command block briefly, the fact that she can materialize one in the first place is proof it's recreatable. The wither storm is not one of a kind.
I propose for the names of characters to be written as common nouns if the name of a character refer to its kind, even when referring to a specific instance of that name. 👁 Image QwertyLilley [ talk ] 09:47, 12 May 2025 (UTC)
The spin-off pages would benefit from dedicated layout subpages in general. They are currently a wild west as the main style guide doesn't specify any specific layout. -- 👁 Image MarkusRost (talk) 21:08, 21 June 2025 (UTC)
I believe that Wookieepedia's well organized and detailed layout guide is a good template to use to begin building our own.Drour1234 (talk) 21:12, 21 June 2025 (UTC)
👁 Image Weak support, it’s fine to touch more on production but I’m not really sure how this relates to history tables. On the moviespace they’ve been used mostly for listing appearances, I at least have been avoiding mentioning production material like trailers. Realshow19 (talk) 23:06, 21 June 2025 (UTC)
I don’t think it’s terribly necessary to split history sections like this. Wookiepedia does this because Star Wars is an interconnected universe, characters there make considerably more appearances. The Minecraft franchise is growing, sure, but it’s never going to be a hugely plot driven franchise. Only the default skins are probably going to have as many appearances as the average Star Wars character. For that matter, having them just be a plain list removes clarity, like characters being replaced. Using history tables keeps things consistent between game and adaptation namespaces. Realshow19 (talk) 23:00, 21 June 2025 (UTC)
Latest comment: 18 July 202521 comments13 people in discussion
I see that @Sightnado has changed the MCW:ITALICS section to include that official editions and games should be de-italicized but I disagree with this because it looks really weird to see it not italicized while it's italicized all over the wiki. I think the style guide should just say: Minecraft, and other official games and editions should always be italicized, no matter what the context is. I don't think it's needed to de-italicize it in hatnotes just for emphasis, because these italics are not for emphasizing a statement, but just because it sort of looks better when it's italicized. MinecraftBedrockPlayer7 (talk) (contribs) 👁 Image 09:14, 15 July 2025 (UTC)
I probably should have discussed this first, yes, but having these things italicized in hatnotes completely nullifies the reason they were italicized in the first place, which is emphasis.
If an entire sentence is italicized, a word or phrase that is not italicized will stand out just as much as something that is italicized in a sentence that isn't.
Honestly, the fact that this had to be specifically added to the style guide is disappointing, since people are not thinking about why things should be italicized, and are instead just blindly italicizing them. Sightnado ( talk | contribs ) 09:24, 15 July 2025 (UTC)
They are titles of works, this is why they're italicized. They should keep their formatting (i.e. be different from the rest of the text in the hatnote) to show this. Establishedmorning (talk) 09:32, 15 July 2025 (UTC)
"Nested italics" result in non-italics (roman or upright text). This is a worldwide publishing standard. There are different reasons for italicizing. One is emphasis. Another is titles of works, etc. No matter the reason, if a normally italicized word appears inside a larger portion of text that is completely set in italics, it is to be written without italics. See the APA Style Guide, the Wikipedia article [1] on italic type, Chicago, and USGPO, which all explicitly prescribe this convention. HolyT (talk) 16:15, 17 July 2025 (UTC)
Well, no webpage cares about the APA Style Guide. It's written for papers and mostly used by students. Even actual researcher use different conventions. But yeah, the rule about italics is universal. What is weird though is HTML does not use this rule: This is italics. Now let's use [further italics] inside this. Further italics should be not italics. -- Simanelix(T|C)20:06, 17 July 2025 (UTC)
If you're curious enough, there was a discussion on Discord (which you can access via Zulip). Obviously, a talk page should have been opened before making any changes.
I didn't check the discord, sorry, and I didn't know how this was done on Wikipedia. But I still think it looks kinda weird to see these official names not italicized, although I'll admit that it might be better. MinecraftBedrockPlayer7 (talk) (contribs) 👁 Image 09:32, 15 July 2025 (UTC)
They are non-italicised because the rest of the text is. Leaving them italicised with the rest of the text removes all emphasis/formatting, as it appears the same as the other text. Not italicising them in hatnotes means that they appear different to the full sentence text, as it would be in the body of the article. Establishedmorning (talk) 09:28, 15 July 2025 (UTC)
As others have noted and tried to explain already (including @Establishedmorning): When a section of text is entirely italicized, and that section includes a word that would otherwise normally be italicized (e.g., book title or a word that is intended to be emphasized), that word is set in upright or roman typography (i.e., not italicized). This is a worldwide standard that style guides, publishers, books, newspapers, magazines, etc., use consistently, not a weird convention that we just made up. When you see an italicized section of text, and within that text you see words that are in roman or upright type, the reader is supposed to understand those words as if they were indeed italicized. (This may already be explained on Discord, which I cannot read.) HolyT (talk) 19:10, 15 July 2025 (UTC)
I do think it is harder to see non-italics within italics then to see italics within non italics.
Examples:
I was hungry so I went to McDonald's and got some ice cream.
I was hungry so I went to McDonald's and got some ice cream.
As other users explained, de-italicizing game titles in hatnotes has been the de-facto standard on the wiki since forever, and it's just a general formatting convention. It should stay this way and should be noted in the style guide.--Capopanzo (talk | contribs) 20:17, 17 July 2025 (UTC)
👁 Image I agree, when seeing a name link to most of the YouTuber pages, I have absolutely no idea who it is. I feel like if they are infinitely more likely to be referred to by their screenname, then the page should be named after that, rather than their real name. Of course, if their name is public, kt should still be mentioned in the article, as well as be a redirect 👁 Image amethyst_hhh👁 Image 07:16, 26 August 2025 (UTC)
Violine's move was due to Grian's supposed real name not being backed by sources. In this case we essentially have no real name to work with, so the nickname is the only other option remaining. For Technoblade we only know the given name (which is one of the more common ones), not the surname. (By the way, I still insist that either Technoblade is not notable or the notability criteria must be explicitly expanded to allow an article on him) — BabylonAS07:32, 26 August 2025 (UTC)
Technoblade is arguably the most notable YouTuber we have an article about, given how often Mojang has referenced him, including in the movie. Perhaps apart form the YouTubers also having a character in Story Mode. | violine1101(talk)11:40, 26 August 2025 (UTC)
As Babylon said, the main reason for my edit was that the name was completely unsourced. Additionally, we shouldn't dox people who don't want their real name out there. The wiki already had a real person request information about them to be deleted form the wiki, quite a few years ago, and we should avoid this from happening again. But apart from that I think that it makes much more sense to use the more commonly used name; Wikipedia does the same. | violine1101(talk)11:38, 26 August 2025 (UTC)
Latest comment: 7 September 20256 comments6 people in discussion
While we are already on the subject of modifying MCW:TITLE (see above), I think we should make a few additional changes for certain unclear guidelines:
Articles that are not about in-game features (like franchise-related media) should generally use the same name as the described subject matter, if any, and title case if the name is a proper noun. Otherwise, sentence case should be used.
This also applies to some non-article pages, such as category, template, and project pages.
If such an article could be confused for a Minecraft feature and is in the main namespace, it should be disambiguated, even if it describes the only Minecraft-related media with exactly that name.
Articles about updates and game drops with no known final name should use a title of the format "Nth Drop <Year>", e.g. "Third Drop 2025", and major updates with no known final name should use a title of the format "Update 1.N", e.g. "Update 1.21", unless Mojang uses a significantly different placeholder name based on the theme of the updatein official communications.
Honestly, I'm still not satisfied with that last one (we should be using the in-game experiment names when available) but whatever I guess. Sightnado ( talk / contribs ) 20:03, 26 August 2025 (UTC)
Title case isn’t the same as proper noun capitalization. We should keep an article in title case only if similar articles are also title cased, and the same goes for sentence case. If we base casing just on whether there’s a proper noun, similar articles' names will end up inconsistent. 👁 Image QwertyLilley [ talk ] 01:57, 27 August 2025 (UTC)
Anyways, instead of saying "updates and game drops", you should say "major updates and game drops". Since they both exist and that's what they are. Also, I know Mojang might still refer to the next major update as a game drop. But a named major update is still a named major update, regardless of how you look at it, and would still be different from the named minor updates we've been getting ever since Update 1.21.
Also, logically, the named major update should be released as Update 1.22, since that is what players would be expecting. And with the version number making it so clear that it's a major update, it doesn't really matter if Mojang decides to call it a game drop or not. -- Simanelix(T|C)17:29, 7 September 2025 (UTC)
I think the first point is ok, but honestly I'm not sure if that'd even need to be clarified. I don't think the second point is at all necessary. If we know that an update will end up with version number 1.x, we can just name it as "Update 1.x" because that's one known final name. | violine1101(talk)21:16, 7 September 2025 (UTC)
Latest comment: 10 February23 comments12 people in discussion
Ahead of Minecraft Live where we will inevitably have to make an article for the announced drop, I suggest we reconsider our naming scheme of "Nth Drop <Year>", as it is not official, and our usage of it as the placeholder name for The Copper Age has caused confusion on that front. (We even had to put a comment in the Copper Age article specifically saying that our name was not official in any capacity because people kept putting it there assuming it was.) Using "Drop N <Year>" like Mojang uses for Bedrock Edition experiments would entirely solve that issue, as it appears to be Mojang's preferred format for public placeholder drop names, and is thus as official of a name as we could have.
The argument against "Drop N <Year>" that led to our current compromise was... potentially being "hard to read". I don't exactly think that is an issue, and Mojang also does not seem to believe it is a problem either considering they are still using that naming scheme after over half a year. Additionally, it is probably less confusing if we use the exact name that is used in-game regardless. 👁 align=top Sightnado ( talk / contribs ) 03:08, 27 September 2025 (UTC)
👁 Image Support using Drop N 202X naming (unless Mojang uses another placeholder name for the update). It's official, unambiguous, and denotes the concept of being a "placeholder" as well. NixinovaT ⁄ C04:53, 27 September 2025 (UTC)
Okay, well they just up and announced the name of the drop with the drop itself so this discussion isn't relevant for Mounts of Mayhem. I suppose we can keep this going in case they ever decide to not announce a drop name immediately in the future though. 👁 align=top Sightnado ( talk / contribs ) 17:33, 27 September 2025 (UTC)
👁 Image Oppose — The previous discussion arose due to the "North Hemisphere Season Drop Year" format that was then-prevalent on the wiki and which Mojang has used in some cases alongside "Drop NYear", meaning that there was no single "official" format to stick with. The current option was chosen as a compromise of sorts, though I still believe that the sentence-case format "Nth drop of year" is more obvious as a placeholder. Given that the upcoming drop has immediately got an official name, unlike previous ones, I suppose we should wait until the next one would be announced in order to come at a definite decision, as Mojang could suddenly change things again. — BabylonAS07:21, 8 October 2025 (UTC)
👁 Image Support for using "drop <n> <year>" But i think <year> drop <number> Is good too as its much closer to the new numbering system; example: 2026 drop 1 just like the 26.1 or 26.0 that mojang uses. AT (talk) 18:55, 23 December 2025 (UTC)
👁 Image Support for using "Drop <n> of <year>", which is the in-game experiment name for the upcoming Spring 2026 drop. It doesn't sound any worse than "First Drop 2026" so I see no reason to go with a conjectural name over the official one.--Capopanzo (talk | contribs) 17:34, 7 January 2026 (UTC)
This option averts the old issue of having two numbers in succession without an interleaving word; however, it must be consistently used by Mojang in publications outside of the game in order to be accepted. — BabylonAS16:59, 8 January 2026 (UTC)
Why would it have to be consistently used by Mojang in other publications? It's in the game and that's what matters the most when naming anything on the wiki. They never use consistent placeholder names in minecraft.net articles or social media posts anyway (latest drop, upcoming drop, new drop, the cutest drop ever, etc).--Capopanzo (talk | contribs) 23:06, 8 January 2026 (UTC)
Okay, well since clearly there's at least some opposition to our current system, and since "Drop <N> <Year>" has apparently been shut down, I'm going to restart this whole thing except hopefully we just agree to use the in-game name like everything else and not make a stupid exception for this one thing.
👁 Image Support using in-game experiment names, and the format "Drop <N> of <year>" (based on the current "Drop 1 of 2026" in-game experiment name) if the experiment name is not available yet.--Capopanzo (talk | contribs) 19:18, 14 January 2026 (UTC)
👁 Image Oppose in general. I think "Drop <N> of <Year>" is much better than "Drop <N> <Year>" but it still sounds quite clunky to me. Also relying on the experiment names kinda depends on the experiment being out. The current naming scheme is predictable and we can just not worry about the naming discussion at all when we don't know if there will or won't be an experiment.
After all, this is just a temp placeholder name, once the name is known it's moved to its official name. The experiment name always is just a different placeholder name, not an official one in my opinion. There's no real advantage to sticking to the experiment names just because they're "official". That doesn't make them better.
I remain with the reasoning that "Nth drop" is best for the wiki, as it's the name that readers would expect. And if someone would look up a different name (e.g. the name of the experiment), they should be redirected anyway. | violine1101(talk)12:59, 10 February 2026 (UTC)
Latest comment: 30 November 20256 comments3 people in discussion
As the nautilus is added, should the plural "nautiluses" or "nautili" be used? On the page Nautilus, I've seen instances of both, since both can be correct. I propose to standardize "nautili" because we are using "cacti" as plural for Cactus. --MinecraftExp123(talk|contribs)13:28, 10 October 2025 (UTC)
Common English usage. So whatever editors intuitively are using. I think as an uncommon word that doesn't look foreign, nautili may beconfusing. Nixinova T ⁄ C06:54, 10 November 2025 (UTC)
The thing is, Mojang has officially used nautili in their articles. I know we don't use the same style guide as Mojang, but this could actually make "nautiluses" confusing if it's less common in official articles. --MinecraftExp123(talk|contribs)06:56, 10 November 2025 (UTC)
You may not have misremembered. Mojang did use "nautili" once in the 25w45a snapshot summary. However, they used "nautiluses" in two other snapshot summaries and in two Minecraft Monthly YouTube videos. I think "nautiluses" is their preferred (or at least most commonly used) term. Rampage455 (talk) 04:08, 30 November 2025 (UTC)
Latest comment: 26 October 20257 comments5 people in discussion
I think there should be a clear and complete separation between April Fools' content and non-joke items. This includes hat notes, navboxes, article writing and trivia with a few exceptions being disambiguation pages, (see potato (disambiguation)) featured articles(see 2025/27) and history sections. (see stained glass)
There has been an apparent disapproval (see Joke potions and splitting) within the wiki with the togetherness of the April Fools' content as it bloats articles and navboxes with the countless new additions specific to that joke update and is at an inevitable risk of becoming outdated. This gives negligible benefit as the hype around the updates always dies down after the month has passed and leaving the normal wiki users frustrated questioning if the particular is in the current game or not.
No, not yet. While it is a de facto rule, I think adding it to the style guide will allow it to be referred in the future if April Fools' content and regular game content are merged (like it has been done before multiple times). 👁 Image Ayaan18:08, 11 October 2025 (UTC)
👁 Image Support In my mind April Fools snapshots are no different from things like add-ons. Sure, technically they're a build of the game instead of DLC, but they're little more than a cobbled together visual gag that happens to be playable, and for exactly one day. Even if they stop making these they've already bloated a lot of pages, the potato snapshot especially. They should be considered their own thing in the same way Marketplace content is; only on vanilla pages in the rare case they have direct relation to vanilla content. Realshow19 (talk) 02:14, 12 October 2025 (UTC)
While it does seem like a nice idea, April Fools' content isn't nearly as big as the actual games with it already being very clearly documented and managed well inside the mainspace. 👁 Image Ayaan08:24, 12 October 2025 (UTC)
I think this is very reasonable, but I'm wondering what concretely you're proposing here? What should change about the status quo? | violine1101(talk)22:10, 25 October 2025 (UTC)
It's mainly hatnotes which are the issue. Usually, April Fools' content are eventually removed from actual game content except hatnotes and allows it to be "hey look at this. The style guide says its recommened to not put that here". 👁 Image Ayaan09:50, 26 October 2025 (UTC)
Thanks for your many edits and comments. Regarding the Iron ore page's infobox and the style guide's capitalization standards: If you read all the capitalization guidance, the pattern seems to be that ONLY article titles use title case (unless, of course, a word is the first in a sentence or is part of a proper noun). There is no explicit guidance for the infobox, but section headings and table headings (which are not themselves prose) are explicitly directed to use sentence case. The infobox seems to me to be most analogous to a table. If table headings are to be in sentence case, then surely individual entries in rows or cells within a table would also be in sentence case. I think that, when the style guide says, "Content on the wiki in prose should be written differently than an article title," it's basically lumping everything that is NOT an article title into an "other" category and, for simplicity's sake, using the word "prose" because that covers MOST everything else. That sentence is not endorsing or promoting title case in other places; it's proscribing (i.e., opposing) title case in places other than article titles. I grant that this was not written explicitly enough to cover every case, such as infoboxes. I also appeal to the similarity between the MCW and Wikipedia in its use of title case, with the most notable exception being that MCW uses title case in article titles whereas Wikipedia does not (the other exceptions being things specific to Minecraft, such as effects). Your thoughts? Thanks! HolyT (talk) 03:36, 21 October 2025 (UTC)
This discussion really seems like it should be moved to the style guide! Mainly discussing whether these are good conventions and then editing the style guide to reflect it. I think these are good conventions and the style guide should have a new section, called "special tables" or something. Stating that info boxes, crafting tables, and similar tables should use article format for item names, even if they are partial like on Wool. And like a note that this is intentionally vague since new types of tables might arise in the future that necessitate this? -- Simanelix(T|C)03:55, 21 October 2025 (UTC)
Regarding the iron ore page, the tab headers should definitely be in title case/match the IGNs as they are titles, but for the contents of the infobox it's fine for it to be in sentence case as it's near-prose, though I think in that case it's more 50/50. NixinovaT ⁄ C03:45, 21 October 2025 (UTC)
Latest comment: 10 November 20256 comments3 people in discussion
The current section about coordinates doesn't mention how to write a set of coordinates. I propose to standardize that it should be written as (x, y, z), or just (x, z) when the y-value isn't needed. Right now, some pages like End spike#Construction use a different format. --MinecraftExp123(talk|contribs)08:34, 1 November 2025 (UTC)
I swear this was discussed before. I think it was about capital Y? Our was it about the full coordinate? I just remember seeing it while browsing the wiki. -- Simanelix(T|C)11:51, 1 November 2025 (UTC)
What formula do those circles use by the way? I made a desmos graph with an example formula: https://www.desmos.com/calculator/aw2bksgkix. Anyways, I think we need to state how a circle is drawn, because "distance" is not clear enough. A radius 3 circle could be interpreted as a square. -- Simanelix(T|C)12:02, 1 November 2025 (UTC)
Latest comment: 11 November 202521 comments10 people in discussion
Going through the tutorial namespace I've noticed a number of very glaring issues. Many are outdated, some to the point of not being updated in years. Others are shockingly opinionated, giving recommendations to third party content over actually giving a tutorial. Almost all of them are clearly unpolished with frequent typos, capitalization errors, you get the idea. If we're going to have these still up we should have an actual style guide to follow. As of now the only information about them is to post in the namespace, saying you is allowed, and the obvious fact tutorials aren't allowed elsewhere. Realshow19 (talk) 02:00, 10 November 2025 (UTC)
Support having a tutorial style guide. There's a lot of junk that has been accumulated in the 15 years of the wiki. I've never really moderated the tutorial space, as it's always been quite a free-for-all. Having known guidelines on what is and isn't allowable in the tutorial namespace would be good. Nixinova T ⁄ C02:03, 10 November 2025 (UTC)
Evidently a bulk of the space was conceived very early on and hardly updated, if at all. Newer versions are frequently mentioned as if they're exceptions, and prose templates are entirely absent. Someone even got away with making a page for a random challenge from an obscure YouTuber with less than 2,000 subscribers. Realshow19 (talk) 02:08, 10 November 2025 (UTC)
👁 Image Support – though enforcing them would be a monumental task. We would have to start massively purging and rewrite most of the tutorial articles. Of course, I would not be opposing to that. Outrowed (talk) 06:26, 10 November 2025 (UTC)
I’m not sure if videos should even be there in the first place, what’s the point of writing our own tutorial if we’re going to cite somebody else’s? We’re not documenting their channel. Realshow19 (talk) 06:43, 10 November 2025 (UTC)
Some videos are useful in visualizing tutorial where a written text would be hard to understand, e.g. building redstone contraptions. Outrowed (talk) 06:45, 10 November 2025 (UTC)
Given the varied nature of tutorials, dedicated guides might be needed for recurring tutorial topics like farming (in the broad sense) or structure exploration. — BabylonAS06:47, 10 November 2025 (UTC)
I don't think so, most of the scripts in there are just one big wall of text with little to no explanation on what they do. I doubt readers will understand the script and just copy paste them straight into their system, which also a bit worrying if left unchecked, a bad actor could add a malicious code in. Outrowed (talk) 07:30, 10 November 2025 (UTC)
👁 Image Strong support. I've been looking around for tutorials to clean up since the year began, and just redoing the entire beginner's guide already took quite a bit of work to filter out good stuff and unneeded duplicates (that was a very serious issue at the time). I hope that this initiate can speed up this process of fully updating tutorial pages for it to fit modern standards, and for them to receive more attention. — 3A | TC13:03, 11 November 2025 (UTC)
Latest comment: 9 December 20251 comment1 person in discussion
I've noticed a few oversights in the style guide relating to how Bedrock Edition versions should be named:
Bedrock Edition development builds should first contain the lowercase word "beta" followed by the version number. For example, "1.2.0.9" would be titled "Bedrock Edition beta 1.2.0.9".
This is the only text describing how Bedrock Edition development version articles should be named; this implies that all Bedrock Edition development versions should be called betas, even though convention is to call them Previews if any release of the version was through Minecraft Preview. I strongly recommend updating the style guide to account for this.
Additionally, there have been a few cases where the version numbers have not been the same on all platforms; 1.19.0/1, Preview 1.21.90.21/22, and Preview 26.0.23/24 come to mind. I believe the convention in this case is to use the lower version number where applicable, so this should most likely be codified as well. 👁 align=top Sightnado ( talk / contribs ) 03:22, 9 December 2025 (UTC)
Latest comment: 18 December 202552 comments13 people in discussion
This part REALLY confuses me. Why is this a thing?
Linking to a redirect seems like it just adds an unnecessary toast that can distract the user, with no obvious benefits. Does it somehow have performance benefits for the wiki?
Blended links are simply more convenient when there is already a redirect link to be used, or a piped link isn't needed. You wouldn't use [[Dual wield|dual wield]] in a sentence if there's already [[dual wield]], for example.
My logic is that: for the same reason that excessive links are distracting because of all the blue text, the toast is just more visual noise for the reader.
You're not wrong. "Readers first" is true; if it makes it easier for editors at the cost of the readers it shouldn't be done. However I wouldn't be surprised if piped links caused even a little bit of lag. -~-Nerdyguy2000TalkEdits02:35, 16 December 2025 (UTC)
The same logic could also be applied for this idea of entirely avoiding redirects; the wiki would be much harder to maintain for editors. RedX (talk) 02:52, 16 December 2025 (UTC)
Please don't strawman arguments. REaders use redirects too, for example when someone types in "A" they wouldn't get to the target of the redirect if it wasn't there. -~-Nerdyguy2000TalkEdits14:09, 16 December 2025 (UTC)
That's not really about "free time or energy". It's about readability and maintainability of the source.
Long piped links add visual noise and make the source harder to read at a glance. Using redirects keeps the source cleaner.
Redirect links don't meaningfully disrupt readers, the links still behave as expected and resolves instantly. The trade-off only affects the source, not usability.
What editing causes the length of piped links to have any meaningful effect? Especially one more significant than the disruption of an unexpected and confusing redirect toast?
Also, I have already explained that the toasts are noticeable and disruptive. In fact, it's disruptive enough that it's the entire reason I created an account here at all.
Source editing itself is what's affected. When you're scanning or maintaining wikitext, especially on pages with many links, long piped links add visual clutter and slow down comprehension at a glance. This matters during routine edits, reviews, refactors, and copy-editing. I understand that you personally find redirect toasts too noticeable, but that's a UI preference, not a functional problem with redirects themselves, and also them being noticeable is the point, it's to show readers that they have been redirected. Redirecting is instantaneous and expected behavior in mediawiki, and most readers either dont notice the toast or quickly ignore it. I think the only problem here that you are mentioning is the redirect toast, not redirects themselves, you should suggest disabling the toast, rather than removing redirect links across the wiki. 👁 Image QwertyLilley[talk]05:07, 16 December 2025 (UTC)
Another example is that once we split the slab page, all links like [[Slab|Stone Slab]] would no longer be valid, but [[Stone Slab]] still works correctly. -- Leo768 (talk) 07:03, 16 December 2025 (UTC)
I personally 👁 Image Agree with you. It makes no sense to prioritize source editing convenience over reading convenience. In the case of redirect links, the redirected notice is quite obstructing, especially on mobile. Furthermore, in the visual editor it's much easier to enter and edit piped links than redirect links, and blended links are not possible at all. I think while source editing it's okay to prefer blended links over piped, but (similar to File: prefixes in galleries and infobox whitespace removal), people should not solely edit a page to remove piped links, it's just completely unnecessary. And in the case of a moved or split page; in such cases we already need to review all links, doesn't really make a difference if they're piped or not. MinecraftBedrockPlayer7 (talk) (contribs) 👁 Image 08:58, 16 December 2025 (UTC)
Source editing convenience and reading convenience are not even contradictory here. The problem being mentioned here is the redirect notice, which is a UI issue, not the redirects themselves. 👁 Image QwertyLilley[talk]10:08, 16 December 2025 (UTC)
Don't let's have this discussion go longer than necessary. Redirects are a core aspect of wikis and avoiding them it fruitless and bloatful. There will never be a policy change that bans linking through them. The redirection notice being too big is a completely separate issue that does not concern redirects themselves. Nixinova T ⁄ C10:46, 16 December 2025 (UTC)
From the discussion above, I have a different proposal: to disable the "redirected from" toast altogether on the wiki by default, by adding the following CSS:
I'm not sure whether I should create a new section for this (as this requires admin permissions to implement), but as this is quite relevant to the discussion here, I'm posting this as a subsection here. My reasoning for the proposal is that, as discussed above, this really is a UI issue rather than an issue with redirects themselves, and this toast can be confusing to readers, and even those who know what redirects are, as typically redirects are HTTP 301s, which implies that the links should be changed, which is not the case here. Unless there's some weird side effect in doing so (maybe that it's really hard to get to a redirect page wihtout manually editing the URL, but there's nothing wrong with editing the URL), I think this should overall solve Lumicat's issue. ‑‑MinecraftExp123(talk|contribs)09:54, 17 December 2025 (UTC)
Should we consider new editors? This feature was useful when I edited a redirect for the first time. I actually didn't know redirects exist in the wiki without the "(Redirect ...)" toast, then I took sometime to research them and got into editing redirect pages. I'm pretty sure new editors wouldn't know how to properly edit them (or even knew about them) without the redirect toast or prior experience with MediaWiki. Redirect pages cannot be edited/viewed without adding a magic "?redirect=no" to the URL parameter, which I think is bad when the toast is hidden, given it is one of the few times they would potentially introduce the concept of "redirect" to new editors. Outrowed (talk) 12:28, 17 December 2025 (UTC)
👁 Image Oppose I really see no issues with displaying the "redirected from" toast/line, it's not obtrusive at all (the enormous hat templates are much worse IMO, no reason for them to be so large), and as pointed out by Outrowed it can be useful for editors. Capopanzo (talk | contribs) 12:41, 17 December 2025 (UTC)
👁 Image Oppose, there are arguably more problems worse than a single redirect line, such as the hatnote templates (pointed by Capopanzo), and I have yet to see solid proof on how it would disrupt one's wiki experience entirely. RedX (talk) 14:10, 17 December 2025 (UTC)
My point is, how would users even get to the URL in the first place? It'd be a tedious route of target -> page info -> redirects to this page -> redirect, rather than page -> redirect. -~-Nerdyguy2000TalkEdits14:31, 17 December 2025 (UTC)
I agree, and your proposal wasn't necessarily a bad thing to do -- it shows what not to do, and that's a good thing. We're now able to look through our options more easily with the ruling out of removing the toast.
Given that it's three lines of CSS that can be copy-pasted into your own common.css, I don't think it's notable enough to create a gadget for, but maybe it could work if it had some other features, like somehow having some other way to access the redirect page. ‑‑MinecraftExp123(talk|contribs)14:37, 17 December 2025 (UTC)
A gadget for what reason, exactly? This topic is focused on the readers, isn't it? Would a normal reader be able to know what a gadget is? RedX (talk) 14:41, 17 December 2025 (UTC)
It might not be that not all readers find it, but it'd at least be better than not allowing the toast to be turned off at all. Please don't try to oppose arguments for tiny flaws that make them imperfect; if we tried for a perfect solution we'd be waiting forever. -~-Nerdyguy2000TalkEdits14:47, 17 December 2025 (UTC)
There needs to be more feedback on whether it's obtrusive. This case is just based on a single reader's experience; it won't be the same for everyone else. RedX (talk) 14:35, 17 December 2025 (UTC)
Agreed. Given that it's just a small line below the title in desktop and disappears after 5 secs in mobile, it seems like a very minor issue overall. It isn't generally obstrusive since it only takes up a small portion of the screen/page and doesn't block scrolling and clicking completely. 👁 Image QwertyLilley[talk]02:23, 18 December 2025 (UTC)
In my opinion, the notice is also useful for readers. It helps readers better understand why they arrived at the target pages. -- Leo768 (talk) 14:33, 17 December 2025 (UTC)
Well, piped links also exist and lead to the target without explanation to the reder, and on desktop, the toast only appears at the top of the page, so when the redirect target is in a section, the reader wouldn't see the notice. ‑‑MinecraftExp123(talk|contribs)14:35, 17 December 2025 (UTC)
As I said above, it would probably be more friendly to put it as an option to disable in MobileOptions instead. The only real issue with the toast is on Mobile, on Desktop it's incredibly unintrusive, and on both views they are very useful for editors. 👁 Image GameCatastrophe (talk) 15:00, 17 December 2025 (UTC)
I don't know how the fancy stuff "Oppose" text these other people are doing works, but as the person who brought up the distracting redirect toasts initially: I really don't think this is a good solution.
Latest comment: 19 December 20253 comments2 people in discussion
How are in-game options supposed to be formatted? I don't see this mentioned anywhere here. By in-game options, I mean, for example, something like saying the key binds can be changed at Options > Controls > Key Binds. How is the "Options > Controls > Key Binds" part supposed to be formatted? Ideally, I think there should be a template for this, but I can't find one either.
{{UI}}. This template is used on the Debug hotkey page for F3+T. Using the template, it would render as "Options" → "Controls" → "Key Binds". Rampage455 (talk) 02:33, 19 December 2025 (UTC)
Latest comment: 8 January14 comments6 people in discussion
Mostly affecting edition-specific subsections, it happens on articles like Poppy, especially after the history table split. Linking to sections becomes less intuitive as their anchors are named like Java Edition, Java Edition 2, Java Edition 3 with no obvious indication of what section is for what (in case of Poppy, the first is post-generation specifics, the second is general history, the third is data history even though I thought we are ditching those). Also, it confuses the wiki engine: the summary does not differentiate between identically named sections and does not add the disambiguating number, and submitting an edit to, say, the second Java Edition section returns you to the first identically-named section which was not edited. To solve this issue, I suggest prescribing all page sections to have unique names; so the Poppy example would have “Java Edition generation”, “Java Edition history” and “Java Edition data history” instead of repeating “Java Edition” over and over.
Actually I would even consider recommending that subsection names make individual sense out of the higher section's context, e. g. when linking to them or arriving by a direct link; in the latter case the higher-level section header is usually not seen. Thus a subsection of “Generation” about how something generates in Java Edition would be named “Java Edition generation”, not just “Java Edition”, even if there are no other sections called “Java Edition”. — BabylonAS08:33, 7 January 2026 (UTC)
👁 Image Oppose. It's already clear enough as you navigate down the page, and the problem only occurs in linking, for which piping off the index works perfectly fine. Nixinova T ⁄ C11:45, 7 January 2026 (UTC)
The pipe index is vague, it only shows numbers instead of explicit names, like "Java Edition history". It's also not that reliable, another heading named like "Java Edition", then index changes to whatever number it wants to. Outrowed (talk) 12:05, 7 January 2026 (UTC)
If it's something that needs to persist then a link to a custom anchor also works. I just don't think it's a good idea to change user viewable stuff just because of wiki editor quirks. Nixinova T ⁄ C12:17, 7 January 2026 (UTC)
It doesn't solve the issue of the subsection header being “incomplete” when arriving at it by direct link; as I've said earlier, the larger section's header is usually hidden in this case. — BabylonAS12:20, 7 January 2026 (UTC)
👁 Image Support I remember a page (I don't remember which) where infobox tabs had same names as some headings inside sounds so it was impossible to link to infobox tab without scrolling down. Adding "sounds" to subheadings would help. 👁 Image Miner(👁 Image talk👁 Image contributions) 12:39, 7 January 2026 (UTC)
Latest comment: 9 January8 comments7 people in discussion
The release for the newest snapshot, Java Edition 26.1 Snapshot 2, refers to several baby mobs by different names: pups, kittens, piglets, calves, and lambs in the first paragraph. This has led to some users updating the Style guide and individual mob pages. I don't think we should change our standard of referring to baby mobs as anything other than baby <mob name> (except for snifflets and ghastlings of course since those names appears in-game or have been confirmed official). The in-game names did not change in this development version, and baby wolves and baby pigs are called "baby wolves" and "baby pigs" further down in the same release. I think the language in the first paragraph of the release contains one-off artistic or flowery expressions, including "cutest game drop yet", and referring to baby mobs as "floofier". I don't think these names should be considered official at this time, and we should stick to our current standard until the in-game names change. Rampage455 (talk) 17:07, 7 January 2026 (UTC)
The hard rule should be that we stick to what is said in-game via subtitles. That being said, baby animals which were given unique sounds actually have been given unique names in subtitles. Puppy, for example, is used in-game. - Harri / Talk👁 Image 17:11, 7 January 2026 (UTC)
Baby wolves are called "Puppy" and baby cats "Kitten" in the new subtitles, but baby pigs are named "Baby Pig" instead of "Piglet". I personally would stick with whatever names are used in-game and the usual "baby" + mob name for babies not mentioned in-game. In any case, we shouldn't be renaming anything until the update is officially released.--Capopanzo (talk | contribs) 17:15, 7 January 2026 (UTC)
We should stick to in-game subtitle names per Harri. Since they are in development, the other names could be updated or changed over time. Outrowed (talk) 03:43, 8 January 2026 (UTC)
I feel the same way, especially because I find baby animal names to be somewhat obscure. And many people would feel the same way. A lot of people don't know what a lamb, calf, piglet, or chick is. And then there is "kid". Also, baby dolpins are also called calves, though the actual mob is incredibly rare in-game. -- Simanelix (T|C)18:46, 9 January 2026 (UTC)
Since they are generally referred to "Baby X" before getting official names, maybe we could consider clarifying them beforehand by notes or some statement, something similar to this. When grouped with other baby entities, they are still called "baby mobs" or some baby variants otherwise. Outrowed (talk) 19:48, 9 January 2026 (UTC)
Latest comment: 15 February1 comment1 person in discussion
The upscaled textures section says "The exceptions to this are item and effect icons, though original resolution versions of these textures should still be provided via the Gallery section of an article.", which the first half has been done, but the original resolution versions of them haven't been added to any galleries. Should the original in gallery part be removed or should the original resolution versions be added to galleries? 👁 Image NmF (talk) 17:29, 15 February 2026 (UTC)
Latest comment: 23 February3 comments3 people in discussion
in one of the examples There’s a list of wood types next to a list of trees which they come from and then the biome in which they found but it doesn’t include all of them for example it’s missing warped and crimson planks. Blah (talk) 06:08, 23 February 2026 (UTC)
The list isn’t for general wood sources, it’s for trees. Crimson and warped planks are made from nether warts. It’s just an example anyway, doesn’t need to be comprehensive. Realshow19 (talk) 06:15, 23 February 2026 (UTC)
Latest comment: 13 April8 comments8 people in discussion
The result of the discussion last year at #Normalizing all-caps text was "Any topic or feature with names stylized in all caps ... for stylistic reasons should be written in title case or sentence case". An effect of this is that pages then get inconsistent -- "MINECON" must be titled "Minecon" under this rule, yet "MINECON Earth" would be allowed to stay as is, as its not 'all caps'.
I propose we amend this to only normalise sentences or clauses, as was the purpose of the original discussion (Dungeons mission names). Atomic names like "MINECON" or "LEGO" may therefore stay as-is in all cases ("MINECON" and "MINECON Earth" being valid titles). Nixinova T ⁄ C05:12, 16 March 2026 (UTC)
The first is put at the top of an article or section to state that it applies to the whole page/section.
The second and third are pretty much the same in how you use them, the difference is just readbility. The second is used generally for introducing version differences while the third is used in shortened situations such as in tables, parentheses, or infoboxes. Nixinova T ⁄ C10:26, 16 March 2026 (UTC)
Basically what Nixinova said. I want to add that, usually the third one is used in tables or anything that isn't prose, whereas the second is used if it applies to a whole sentence or paragraph (but not section). ‑‑MinecraftExp123(talk|contribs)11:41, 16 March 2026 (UTC)
Latest comment: 23 April9 comments3 people in discussion
What's the intended prefix for Education? Files I uploaded as MCED are being moved to MCEDU, and the guide doesn't mention it in the spin-off section. MinecraftEdu is its own thing so I think we should go with MCED or ED to distinguish them. Realshow19 (talk) 19:40, 22 April 2026 (UTC)
I know. But that was just one reason I listed for why "MCEDU" is a better prefix than "MCED". It isn't the only reason I listed for why "MCEDU" is a better prefix than "MCED". "EDU" is a common prefix for the term "education". Using it for files associated with Minecraft Education won't be confusing because there is no need to have a prefix for MinecraftEdu. In addition, not only was MinecraftEdu discontinued, but there is a lack of files associated with MinecraftEdu; hardly enough to warrant a prefix. Therefore, for all these reasons, most people will think of Minecraft Education when they see the prefix "MCEDU".Drour1234 (talk) 20:02, 22 April 2026 (UTC)
Simply EDU might be better, the abbreviations are three letters on average. If someone is searching for files they wouldn’t need to sort through things related to Earth or any future media that will also start with E. In any case we should reach a consensus before enforcing this. Realshow19 (talk) 20:40, 22 April 2026 (UTC)
Agreed. Disambiguation should lists pages with similar name, not concepts, that's for set index or generally a notable article in itself. Outrowed (talk) 13:57, 30 April 2026 (UTC)
Sorry, to clarify I meant that the current revision of that page is so inconsistent with every other disambiguation page, that it singlehanidly inspired me to make this post requesting a disambiguation style guide. Not that we should base the style guide on the page itself. TheCaptainYaya (talk) 17:11, 30 April 2026 (UTC)
For that page specifically, it can just be moved to Lake, because currently that page just redirects to the "disambig", and putting the page there would not suggest it is a disambig and thus would be fine being a set index. I also changed the {{Disambiguation}} to {{set index}}. ‑‑MinecraftExp123(talk|contribs)01:42, 1 May 2026 (UTC)
This does lead me to something I actually came to this talk page to make a section on before seeing this discussion, should disambiguation pages use commas or hyphens?
Compare Abomination (disambiguation) to Basalt (disambiguation). As far as I can tell both are currently accepted which does sometimes lead to confusion. Either way some sort of style guide for DABs and set indexes is necessary because the line is sometimes blurred, and right now there isn't a clear criteria for what's applicable for both, such as if materials (Birch, Diamond, Basalt, Cinnabar) deserve set indexes. 👁 Image FireDragons5206:33, 1 May 2026 (UTC)
En dash and em dash specifically. Though this guideline could also be useful for "See also" and "External links" sections. Outrowed (talk) 10:54, 1 May 2026 (UTC)
👁 Image Support, but please take a lot of inspiration by Wikipedia's policies (for example, WP:D, WP:NAMB). Disambiguation pages and their hatnotes are nothing more than logistic assets, they are not actual encyclopedic content so they should be informative, just practical.
And unlike set indexes, they are also not a list of related subjects, their only purpose is to distinguish articles that may be confused with each other. example: Birch (disambiguation).
A good example of a disambiguation page is AI, just contains any topic the single word AI may refer to. Note that the hatnotes on their pages are : none of them are ambigious on their own, so omit it.
I personally don't think we should have a style guide about writing disambiguation pages, maintaining consistency is enough. We do need a guideline about notability of disambiguation pages, what to put on there, and how we use hatnotes because currently it is massively overused. We're not the Minecraft Disambiguation Wiki. MinecraftBedrockPlayer7 (talk) (contribs) 👁 Image 11:20, 1 May 2026 (UTC)
👁 Image 100%. We're getting a little crazy in how disambig pages are set out, and some people seem to be editing disambigs without realising the purpose of them. Nixinova T ⁄ C23:01, 4 May 2026 (UTC)
Latest comment: 22 May1 comment1 person in discussion
The style guide does not have any guidelines on how the names of the potions mentioned in the title are capitalized. They are regular adjectives, implying regular lowercase, but are also used in the same way as effects/potion names are, which are capitalized. Awkward Potion does not capitalize it but, for example, Tipped Arrow has "... as well as Awkward, Thick, and Mundane ...". So, what should be the correct capitalization? ‑‑MinecraftExp123(talk|contribs)06:14, 22 May 2026 (UTC)
