Minecraft Wiki talk:Style guide/Archive 1

Text style
Note: already started a style guideline at. It might be helpful. -  02:29, 10 June 2012 (UTC)

Also, there was a discussion already at. Please continue the discussion here as well. -  22:22, 17 June 2012 (UTC)

Update: goes over some basics of grammar (that everyone is probably already familiar with). But I still see frequent instances where an opening clause does not have a comma. Example: Originally water was infinite. Here, there should be a comma after "originally". I know that some styles don't use such commas, but this strongly applies for longer clauses, so we should just use commas every time. -  22:25, 19 June 2012 (UTC)

Capitalization
I think we can all agree that the wiki should be consistent, but there's been debate over what should be capitalized, particularly blocks and items. Personally, I'm leaning toward capitalizing anything that's named in-game. To me, "a house made of Wood" means it's built of Wood (log) blocks, while "a house made of wood" implies any block made of wood (planks, slabs, etc.) could be used. That may just be my particular use of language, though. Any other arguments one way or another? -- 09:13, 6 June 2012 (UTC)
 * I'd have to disagree on this one. Apart from looking very odd, capitalizing every single in-game item is unnecessary and common sense dictates the opposite because they are not proper nouns. Mojang developers themselves have never capitalized item names because that makes no sense whatsoever. Official Minecraft Forum posts and any offical posting relating to Minecraft have never capitalized item names. Notch's blog posts or any of the Mojang tweets NEVER capitalize item names. Only proper nouns (e.g names of places like or ) should be capitalized in my opinion. Also a better solution to the wood dilemma is to specify exactly what type of wood you need to avoid ambiguity or by linking to the relevant article. The capitalization solution is a bit confusing unless you take a second look.  10:02, 6 June 2012 (UTC)
 * Me too. If something is a sufficiently important in-game term, or the subject of the article, better practice is either to link to it or italicise it the first time it appears, thereafter treat it normally. I've written style guides before. I'll dig them up and see what areas of them may be relevant.-- 11:04, 6 June 2012 (UTC)


 * Point taken; capitalizing every instance of an in-game term does look rather strange. (At least in English; it probably doesn't stand out so much in German.) -- 08:48, 8 June 2012 (UTC)


 * All items/blocks should just be lowercase then, unless the name involves a fictional word or proper noun/adjective/word such as Nether brick or End stone. -  03:10, 10 June 2012 (UTC)


 * Also, only the first instance of the article title/topic can be capitalized. Example: for the Chicken Egg article, the first sentence would be: A Chicken Egg is.... not: A chicken egg is...
 * All other titles/phrases after the first should be completely lowercase unless it is fictional ("Ender Pearl" would still be "Ender pearl" and not "ender pearl"). -  23:44, 20 June 2012 (UTC)

I think capitalizing properly is important. Ex. "A Chicken Egg can be used to bake a Cake." Looks stupid. So it should be, "A chicken egg can be used to bake a cake." If you don't get it, because this is a wiki, (not spelling class) you need a book on spelling and capitalization. 17:28, 26 August 2012 (UTC)Creepergoboom64

What about the word Minecraft? Sometimes it looks strange capitlized. Such as "Minecraft forum" or "Minecraft wikki" what do you guys think? 14:52, 28 October 2012 (UTC)


 * Common wiki practice is to use the actual in game capitalization of item names. So if the item in game is "Chicken Egg" the article should be named "Chicken Egg". For article names not related to specific in game items, sentence case is appropriate for ease of linking. Remember that all articles are by default going to be sentence case even if you type it in lower case, as media wiki will automatically capitalize the first letter of all article names. Media wiki will also recognize the first letter of any link as capitalized whether it's typed that way or not, so you have the article titled, you can link it inline as  and get the same result. --    03:18, 21 November 2012 (UTC)


 * I would like to make a note on code capitalization noting Asterick6's spacing example below. The template in the example below, should be kept lowercase. There is no difference in the wiki code between  and, but just having a lowercase standard in edit pages looks neater. They have no effect on the viewing of the article anyways. I can't think of any examples off the top of my head, but templates using more than one word, or templates using a subpage, should be all lowercase as well, to imply sentence case, and I remember seeing a few things not fitting this. If it's not a normally viewable subpage, especially if it's used as a template or for transclusion, everything after "/" should be lowercase. Not only does this look neater while editing, but it is a bit of a pain to have to remember what templates need a capital letter.   02:30, 18 February 2013 (UTC)


 * It varies. I think that for items in-game, each word should be capitalised, but for things that are not an item/mob etc. in the game, they should be uppercase. for example isn't a game item, so only the first word is capitalised.  is an item in-game that is spelt with capitals, so it should be like that on the wiki as well. —  08:05, 22 March 2013 (UTC)

Mobs
I think fictional mobs should be capitalized and real mobs should be lowercase, so is capitalized and  is not. Or all mobs can be capitalized. -  03:10, 10 June 2012 (UTC)
 * I like the idea of having fictional mobs capitalized and real animals lowercase, on the other hand, having all mobs capitalized sounds worse then having no mobs capitalized. 09:04, 12 June 2012 (UTC)

Ok, but we need to determine which mobs are fictional and which are not. This depends on how fictional we consider the mobs. I'm thinking that the pig, cow, sheep, chicken, squid, wolf, ocelot, zombie, skeleton, spider, cave spider, giant, and villager are "nonfictional" mobs (i.e, they exist in real life or real life fiction). The Creeper, Enderman, Mooshroom, Snow Golem, Iron Golem, Pigman, Zombie Pigman, Ghast, Blaze, Magma Cube, and Ender Dragon are definitely fictional mobs (although some retain real-life names).

Now here are the tricky, specific considerations:

I'm not so sure about the Giant, Slime, Silverfish, and Spider Jockey. The Slime and Silverfish are real-life things in name only, since their behavior and appearance are greatly different. The Spider Jockey is actually just a combination of a spider and a skeleton, but the combined mob is also completely fictional thing. In fact, we could also argue that these Minecraft mobs are completely fictional since they are fictional game things, but that makes things too complicated and seeing stuff like "Cow" everywhere makes this wiki look like it's turning into the German wiki. I think we can capitalize the Slime, Silverfish, and Spider Jockey, since they are "fictional" mobs even though they have real-life names (same applies to the Creeper). The Giant retains the definition of a giant, except that it's a giant zombie. Should the name "Giant" be capitalized? Also, the skeleton is a real-life thing, but its behavior is greatly different from regular skeletons in real-life fiction. Should it be capitalized or not?

For the mobs with 2 words for names, such as Iron Golem and Zombie Pigman, should we capitalize the entire mob name, or only the "fictional part" (i.e., Ender dragon and zombie Pigman). I'm beginning to overthink this... in fact "Magma Cube" is composed of two real-life words, so it could be "magma cube". "Snow Golem"/"Iron Golem" could be "snow golem"/"iron golem" as well, since the names exist in real-life because there are real golems in real-life fiction, though not necessarily made of snow and iron, although they could be just a type of golem. But the actual Minecraft mob is completely fictional in appearance and behavior (even though the Iron Golem is derived from the robots in Castle in the Sky - but this is a big stretch and should not be considered). Do you guys have any thoughts? And I'm completely screwing up proper usage of commas and proper grammar. -  01:13, 21 June 2012 (UTC)

Article titles and section headings
Article titles should be in lowercase unless the phrases are proper nouns. They should also be in the singular form to maintain consistency. For section headings, we should follow sentence style capitalization, not title style, so only the first letter of the heading is capitalized. -  22:22, 17 June 2012 (UTC)

Update: Names such as TNT retain their capitalization in titles.

Do you guys think that proper nouns/fictional mob names should be in lowercase along with all other words in the section heading? Or should we retain the capitalization? 01:47, 21 June 2012 (UTC)

Image captions
Image captions should not have periods at the end, unless the phrase is a full sentence. -  01:08, 18 June 2012 (UTC)

Italicizing
Any instance of "Minecraft" should be italicized. Any emphasis (in talk pages, etc.) should be italicized instead of being bolded or capitalized. -  05:15, 19 June 2012 (UTC)


 * I agree, that seems right to me! 04:42, 5 September 2012 (UTC)Creepergoboom64
 * I agree that this seems right, but I don't think that there should be any specific style guidelines for talk pages, because different people speak differently. In articles, words should be italicized.   22:58, 30 January 2013 (UTC)

Spacing
This style guideline isn't completely necessary, but it helps to keep every article in the same format.

All articles should have single spaces between fullstops (periods) and the next sentence. No double spacing, unless you guys think we should make the change to double spacing between sentences for better readability/formatting.

All articles should have a space above and below a section heading to allow adequate space between blocks of text to improve readabiltiy and facilitate editing. Regularly formatted file links, video template code, disambiguation code/hatnotes/text, reflist and - (or similar templates) can be placed directly above or below a section heading without spaces. There should be a space between the wiki code/html code and regular text. Gallery code, wikitables, and the history template should be spaced just like regular text (with a space between the template code and the section headings. Video templates should have 2 spaces below the template code to allow adequate spacing below the embedded video. Any templates such as blocks or items should be spaced 2 lines away from the last line of article text such as reflist if there is a references section. The reflist can be placed directly below the section heading. -  00:29, 21 June 2012 (UTC)

Example (view in edit mode):

Section title
Text here.

Section title
Text here.

Section title
Text here.

Section title

 * Text here.

Text and symbols
For file links such as and in galleries, all underscores (in wikicode) should be spaces. URLs need to retain underscores (obvious reason). Special characters should not be replaced with HTML code (please comment there are good reasons to use HTML code for special characters, since I'm not sure if there are). Add on if I missed any other instances. -  01:29, 21 June 2012 (UTC)

Date formatting
While not common in the US, I think YYYY-MM-DD (as used in Minecraft screenshots) is the most useful. The main advantage is that sorting dates as text (such as on the pages) also sorts them chronologically. -- 09:13, 6 June 2012 (UTC)


 * We discussed date formats a . No clear decision was really made though.
 * Here's some example date formats I've seen on the wiki:
 * 1st January 1994
 * 1st January, 1994
 * 1st of January 1994
 * 1st of January, 1994
 * 1 January 1994
 * 1 January, 1994
 * January 1st 1994
 * January 1st, 1994
 * January 1 1994
 * January 1, 1994


 * Personally, I think we should use the international standard (YYYY/MM/DD. Forward slashes or dashes, it really doesn't matter) for tabular data and cramped areas like the infobox, and use one of the first six date formats above for normal article text. – (&#124;) at 10:35, 6 June 2012 (UTC)

When writing a numbers-only date format, we should use YYYY-MM-DD, because it is. The ordering lets it sort nicely, and the dashes help distinguish it from the US date ordering which is nearly always written with slashes. I offer no opinion on long date formats. — 18:11, 6 June 2012 (UTC)


 * How about "month name" DD, YYYY (June 10, 2012) since this wiki is supposedly using AE? Or we could just use the wiki date format, DD "month name" YYYY. This can prevent confusion with using numbers for months. -  01:40, 10 June 2012 (UTC)


 * This topic is a bit stale, but I would like to propose two date methods. Since we follow US spelling across the wiki, we should follow the long date standard of "Month day, year" when used within an article, such as the main page, for readability. "February 17th, 2013" flows better while reading than "17th of February, 2013", and I also suggest not using, as it screws up spacing and overuse makes it worse, as seen in an old revision of the main page in the "about" section. Reference numbers inside a paragraph are bad enough for spacing. Using simply "th" is fine, but shouldn't be required. For number-only dates, in ultradude's example of cramped spaces and Orthotope's sorting example,I agree that the ISO standard should be used.  01:56, 18 February 2013 (UTC)

Page organization
Many pages have Trivia, History, Bugs, Gallery, and/or See also sections, usually toward the end, but there doesn't seem to be any consistent ordering to them. It would be nice to have some guideline as to which order to put them in, though I don't have an opinion on what it should be. -- 09:13, 6 June 2012 (UTC)
 * This has definitely been bugging me a lot lately. I would say the most logical order and the one most wikis have would be: History -> Bugs -> Trivia -> Gallery then See also. Any opinions? 10:02, 6 June 2012 (UTC)
 * I like that ordering. We should also specify where “Video” (bleh) goes; I would propose buried at the bottom, er, above History but below all current textual information. — 18:11, 6 June 2012 (UTC)
 * This ordering is fine, but the video section should go after the history section and before gallery/trivia. -  03:04, 10 June 2012 (UTC)
 * I don't see a need to change every page just to put the video section after the history section :S. 09:04, 12 June 2012 (UTC)
 * Course not, just remember to move them or fix the small things whenever you edit pages for vandalism, cleanup, or updates, etc. It's efficient to do edits along with other edits instead of editing a page only to move sections around. Every editor should remember to fix small things along with the intended edit whenever (they) update a page. -  22:53, 14 June 2012 (UTC)
 * I've been putting the videos above the History section, but always below the actual page content. It's been quite some time since their initial arrival and there's now around 300 of them. Even though there's been some negative reception of them in the beginning, they are quite informative and they have refined their presentation of them to be quite neutral. If I were Curse, I wouldn't want them to be buried at the bottom, but I don't want them to be in everyone's faces at the top either. At the end of the page content and before the standard article bottom sections is a good place, since the video itself covers what would be considered article content.  02:37, 18 February 2013 (UTC)

I think each block/item article should be ordered like this: lede, Uses/Properties, Crafting, (additional sections), Video, History, Bugs, Trivia, Gallery, See also. For articles of mobs, it can be ordered like this: lede, (spawning, appearance,) behavior/AI, combat/breeding,, defense/strategies, video, history... For articles such as crafting with long crafting recipes/lists, I think the history section should be first since the crafting recipes section is very long. Since the history section is unrelated to the other sections, it can be placed first, then the related sections, and then the long crafting list. -  03:04, 10 June 2012 (UTC)

Issues about history-cruft were brought up before at where editors should move history versions and the associated content (as of xxx, etc.) to the history section, (but I think the problem might be fixed now). -  02:29, 10 June 2012 (UTC)
 * So many pages with that issue... 09:04, 12 June 2012 (UTC)

History sections
Should this be sorted with newer items at the top or bottom? Another one where I care more about consistency than which one we use. -- 09:13, 6 June 2012 (UTC)
 * We should implement a system similar to what the official TF Wiki uses in which all patch notes are organised in a consistent format with relevant links and a neat scroll bar to take up less space. 10:02, 6 June 2012 (UTC)
 * We could implement that to . -  02:06, 10 June 2012 (UTC)

They should have the newest items at the bottom; as each item will generally describe differences from the previous situation, this ordering creates a readable “story” and communicate the historical context of each change better. Also, I think most history sections are already in that order. — 15:20, 6 June 2012 (UTC)


 * I thought all of them are in that order already. -  02:06, 10 June 2012 (UTC)

What about the development versions? I think the update changes should retain the exact version of the update/change (e.g., 12w08a instead of 1.2), or we could just not document these changes (and save time) and only use the official release changelog. I kinda like having all the changes listed as they occur. -  02:06, 10 June 2012 (UTC)
 * Yeah I think we should keep the exact snapshot of change instead of merging it with the official release just because it saves time and is more accurate. 09:04, 12 June 2012 (UTC)

See also sections
Is there a point to these? Most of the time, all the listed pages are already linked to in the article. -- 09:13, 6 June 2012 (UTC)


 * I think they should include things which are either not already linked, or are material which one might expect to find in the article (except that the wiki more finely divides things). For an example of the latter, I might put a link to from, because someone looking to thoroughly understand mobs is quite likely to want to know about their spawning as well. “See also” sections should not include merely related items; for example, I would remove the SA link to  from , because it is already linked and the uses of gunpowder are not part of understanding creepers. — 18:11, 6 June 2012 (UTC)

Obtaining and Uses sections
In order to make block and item articles more organized, I propose that the first two sections on this kind of article should always be “Obtaining” and “Uses” (or “Usage”).

The Obtaining section would list any methods of, well, obtaining the block or item in question in Survival mode without cheats (and if the item is not obtainable in Creative mode, there should probably be a note in this section), including information on blocks that generate with the world or generated structures. The current Crafting and Smelting sections would become subsections of Obtaining. If crafting is the only method of obtaining an item (as is often the case), the Crafting section could simply be renamed to Obtaining, or left as is.

The current revision of the article illustrates my intent with the Uses section: it would list any uses of the article subject. The only thing that I would change is I would list “as a crafting ingredient” as one of the uses.

I think that with these changes, people who want to look things up while playing Minecraft will be able to find the information they are looking for much faster. However, I would not want to start making them myself without discussion on here, since they would be very visible. — 22:46, 16 April 2013 (UTC)


 * As far as I'm aware, there really isn't any consistent format for the main article body above the video section. I've been putting any achievement sections right above the video since that's part of the article (and quite a few articles had achievements down near history and trivia), but other than that, I think any plan to organize the top part would be welcome. As for "as a crafting ingredient", the general format I've seen looks good, where it's listed right under crafting.  02:12, 17 April 2013 (UTC)


 * “As a crafting ingredient” could still be right under Crafting (or Obtaining), but if there are other uses besides as a crafting ingredient, I think it would make more sense to list “as a crafting ingredient” as one of the uses (i.e. give it a h3 under the Uses h2), since that's basically what it is. — 00:40, 18 April 2013 (UTC)


 * Now that I think about it, “Usage” would probably be better than “Uses”, since some items are only useful for one thing. — 01:05, 18 April 2013 (UTC)


 * is a mockup of how the article might look like with this layout. — 01:24, 18 April 2013 (UTC)


 * Looks good to me. I also do remember changing one or two "Use/Uses" section names into "Usage" in the past.  02:35, 18 April 2013 (UTC)

Data values section
The article is a mess (as has been noted on its talk page on multiple occasions), and I would like to contribute to cleaning it up by moving the subsections in the  to the block/item articles, adding a new Data values section directly above Achievements. — 02:21, 28 May 2013 (UTC)


 * Although I'd be happy to see this information added to the appropriate articles, I definitely wouldn't want to see this content removed from . I find it extremely useful to have everything in one place.
 * &mdash; &middot;  &middot; 03:34, 28 May 2013 (UTC)


 * The Data values article is just too long, so yes, I would like to remove the copied sections from it. You would still have the table at the top of the Data section (and the little superscripts in the block and item ID tables) with links to everything. — 04:07, 28 May 2013 (UTC)


 * Well, I'll exercise my right to disagree. It's the perfect length -- all the information on data values. It's length doesn't seem to make it hard to load, even with all those sprites -- can you be more specific about what the problem is?
 * I'd be okay if a block or item's data value content was placed in a subpage of the block or item, then transcluded into the block or item article, and also transcluded or LoadPage'd into . As long as it's still available there. : )
 * &mdash; &middot;  &middot; 04:44, 28 May 2013 (UTC)


 * Sounds good. — 10:57, 28 May 2013 (UTC)


 * I've also found it useful at times to have all the block metadata values listed on one page. On the other hand, it would make sense to have it on the individual block pages as well. I like Munin's idea of transcluding it onto both pages; if anything is changed, we only need to update it in one place. -- undefined 12:33, 28 May 2013 (UTC)


 * I like this idea. -- 12:48, 28 May 2013 (UTC)


 * I have now added this to the style guide, and updated the and  articles accordingly. — 04:42, 30 May 2013 (UTC)


 * Any reason you're using the acronym "DV" instead of just "Data values"?
 * Also, I didn't understand the statement about descriptive text. If it's about the data values, shouldn't it go in the subpage so it'll be available on also?
 * &mdash; &middot;  &middot; 07:00, 30 May 2013 (UTC)


 * “DV” is shorter, so… yeah, why not? And descriptive text is usually just repeating what would already be in the table, so not really needed on the page which as I understand it is often used as a quick reference. — 08:32, 30 May 2013 (UTC)


 * I wouldn't call it the quick reference -- it's the consolidated reference. The point is to avoid having to go to multiple article pages, so if it's worth explaining there, it's worth explaining in.
 * &mdash; &middot;  &middot; 21:44, 30 May 2013 (UTC)

Trivia section
I think the rules on what's allowed in trivia sections should be a bit more restrictive. In their current state they contain hardly any useful information and lots of ramblings. For example, something about objectivity would be nice, or about game visuals (these are often obvious and rarely interesting). Any other suggestions? — 02:15, 12 June 2013 (UTC)


 * I agree. I would suggest borrowing from the TF Wiki's trivia guidelines as a starting point. Honestly, a lot of the trivia on this wiki resembles this. — 12:53, 13 June 2013 (UTC)


 * If we remove some of the drek, keeping it, at least temporarily, on a wall of a shame of our own might be educational. I rarely bother reading trivia sections at all these days.-- 13:49, 13 June 2013 (UTC)


 * I've added guidelines regarding the two points I mentioned above (objectivity and visuals). If no one objects, I might also add some guidelines from the TF Wiki. — 04:40, 10 July 2013 (UTC)


 * Now that I've seen what was added, I object. I think the addition is too restrictive. I'm fine with the Trivia guide as it was and with the Trivia sections as they were. They're trivia. As long as something's not false or speculation, let it stay in Trivia or incorporate it into the article. &mdash; &middot;  &middot; 22:01, 3 July 2014 (UTC)


 * I also believe it is too restrictive - for example the line "The collective hunger restoration of all the ingredients in rabbit stew is more than the item itself" is interesting and may appeal to players but does not fit anywhere else on the page. – ᐸ    23:12, 3 July 2014 (UTC)


 * I think this is one of the rare cases where such a comparison is relevant — another example might be the smelting times of vs . For this reason, I've added it to the relevant section, in this case “as a food”. Trivia sections are always going to be rambly because of their list layout, and moving good trivia items up into paragraph-style text and removing bad trivia items is the best possible way to solve this. — 00:09, 4 July 2014 (UTC)


 * Agreed. Maybe make this explicit in the guidelines: "If a trivia is factual and not opinion or speculation, consider incorporating it into the main article before considering it for deletion."? With that, I'd be okay with the TF addition. &mdash; &middot;  &middot; 00:32, 4 July 2014 (UTC)


 * Replace “factual” with “relevant” perhaps? — 00:34, 4 July 2014 (UTC)

Mob page layout
Do mob pages have any set format to follow? I, ah, attempted to rearrange and fill in the page recently, but I don't know for sure that the format I used adheres to layout guidelines. I am now going through other mob pages to check their formats, but it's somewhat inconsistent. For instance, what counts as Behavior? I thought spawning, breeding and offspring, taming, and the foods they will accept were all relevant to the Behavior section and should be inserted there as subsections, but other mob pages do not always support this. - 15:20, 16 June 2013 (UTC)


 * Spawning does not seem like it belongs to behavior logically. I don't spend much time on articles about entities, but perhaps taking the block/item article layout and replacing obtaining/usage with spawning/behavior could be a start. — 10:57, 3 July 2014 (UTC)

Style guide from another wiki
http://kevan.org/morningtonia.pl?Style_Guide - that's rather more specialised wiki than here, but I think we should consider stealing and modifying the following numbered guidelines: 1 2 4 5 9 11 12 16 20 and incorporating them into our own guidelines. Maybe one or two others as well, but I think on the whole those are the main ones. -- 22:39, 17 June 2012 (UTC)


 * Most of them are relevant to this wiki, but 3 and 14 should also be addressed. I don't think 12 is a good idea; that might just confuse editors. Plus, most browsers should support the characters.
 * So here are some of the guidelines (modified to fit this wiki):
 * Second and subsequent mentions of the term being defined should not be bolded/italicized.
 * Avoid excessive use of capitalization. Proper names, fictional names and terms such as Notch and Mooshroom should be capitalized, but most game modifiers – e.g., stone brick or wooden planks should be in lower case.
 * Also when linking, try to make the link self-describing, so that users can tell where it will send them before they click on it. For example, rather than "For a tutorial on mob farming, click ", use something like "For a tutorial on mob farming go to ".
 * -  00:41, 18 June 2012 (UTC)
 * That doesn't apply to video games. More things than just proper names and fictional names are capitalized. Almost every video game wiki follows this style. -- 21:14, 27 June 2012 (UTC)

Style guide article length
The content of the style guide WIP looks OK to me, but I'm worried it's going to get far too long. I would suggest choosing a size limit of 3-4 screens max. Catch is, at that size there might not be enough space for examples showing good practice. So perhaps it might be worth having a short version which just lists the rules - like the 'other wiki' style guide I linked above - and a longer version which has more explanation and gives examples of correct usage. Then maybe link to the examples from the short version. Or else, use those expanding widgets text boxes to hide the explanation and examples? -- 01:47, 30 June 2012 (UTC)

We seem to have two complete articles here.
The main style guide seems to be pretty much done, barring the usual ongoing improvements and changes. (I just filled in "Date Formats", the upshot being "use full dates with month names".) So does the Redstone style guide, which really ought to get its own page -- even the main style guide cites it as a "main article" for the topic. Really, they should be moved to a permanent home. The question is, which namespace? -- 11:35, 19 April 2013 (UTC)


 * The help namespace. — 11:48, 19 April 2013 (UTC)


 * Wikipedia uses the Wikipedia: namespace for its . I think that would correspond to the Minecraft_Wiki: namespace here. But I have no real objections to Help:, either.
 * After reflection, I agree now that the redstone style guide should be its own article, not a subpage -- because organization on the wiki should be done by categories, not by subpaging.
 * &mdash; &middot;  &middot; 14:44, 19 April 2013 (UTC)
 * I'm fine with either namespace, though now Minecraft_Wiki seems more appropriate. -- 16:35, 19 April 2013 (UTC)


 * The Wikipedia: namespace on Wikipedia (and the Minecraft Wiki: namespace here) are both aliases for the Project: namespace. This is a somewhat special namespace whose alias always reflects the wiki name as defined in . 「」· 16:37, 19 April 2013 (UTC)
 * So this was always in "Minecraft Wiki", aside from linking and perhaps indexing? My, that is peculiar.  Thanks for the info. -- 13:52, 20 April 2013 (UTC)

Now that the style guide is official, I've added a link to it in the mainspace editnotice so that it can be seen by all editors. Any feedback is appreciated. — 02:13, 20 April 2013 (UTC)


 * It's a good idea, works great. -- 02:16, 20 April 2013 (UTC)


 * Thanks :D — 02:35, 20 April 2013 (UTC)

Real life comparisons
What is the rule regarding real life comparisons in articles? – ᐸ    00:46, 25 April 2013 (UTC)

Any answers??? Is it simply allowed in all articles, some articles, or no articles? – ᐸ   08:58, 18 May 2013 (UTC)


 * In my opinion, it depends on the comparison. I remember a few months ago reverting a comparison to real mushrooms on the page. It doesn't pertain to the ingame appearance and isn't really good trivia. On the other hand, the trivia on the  page fits perfectly since I would like to think not many players have an industrial background and wouldn't know or recognize what a hopper is and knowing that it's a real thing is interesting. Also, all the measurement comparisons on the  page are pretty interesting. It really comes down to individual judgement calls. If it's a stretch, I'd say it's safe to revert it, but if you find the information fascinating, someone else may as well.   10:26, 18 May 2013 (UTC)


 * I would add: (1) it should be reasonably terse -- a sentence or short paragraph, with perhaps one or two appropriate links to Wikipedia or other sites. And (2) Must be reasonably true, which includes coherent and meaningful.  So "A real world suit of diamond armor would cost 2 trillion dollars" is right out (too many open variables).  I think they're especially helpful when Minecraft's usage of something is drastically different from the real world, as with Obsidian vs. volcanic glass. -- 11:32, 18 May 2013 (UTC)

Singular form
Titles should be singular form, but what exceptions are there? ,, , , , , , various "upcoming features" pages and probably others are still plural. Is there any reason? – ᐸ  06:53, 25 April 2013 (UTC)


 * The main reason I can see is that these articles are mainly in list form, e.g. the article first gives a general description of what a mob is, then lists all the mobs. If this were Wikipedia, I would suggest splitting these articles (with the exception of, , and maybe ) into a main describing article and a “List of &lt;subject&gt;s” article. However, while this would certainly improve readability on the describing articles, I'm not sure if this is needed in a smaller wiki like this one. Opinions? — 16:35, 25 April 2013 (UTC)


 * Most of the articles listed above could probably fall into the "Articles that actually distinguish among multiple distinct instances of related items…", since they're discussions or comparative summaries of multiple related subtopics. But since we sometimes need to refer to a "mob", "item", or "redstone circuit" in the singular, it wouldn't bother me if the article titles were made singular (it's a lot easier to pluralize a singular title, than to "singularize" a plural title).
 * &mdash; &middot;  &middot; 20:18, 25 April 2013 (UTC)


 * After reflection, I think that "things" should be singular, while "subjects" can be plural if it makes sense. So, "Redstone circuit", but "Miscellaneous circuits".
 * &mdash; &middot;  &middot; 04:36, 29 April 2013 (UTC)


 * I believe article titles should be singular unless it's a really good exception. Block, Item, Mob, Redstone circuit (like Munin said), etc. sound fine. For Mods and Tutorials, since those are big subpage organizations, they should be treated like a pseudo namespace, so singular would work for them. As for the massive dev version page, plural links aren't really pretty for that anyways since it's a subpage and a piped link is usually used for it.  11:07, 18 May 2013 (UTC)


 * As long as there are redirects for the "other" form, I don't see a huge problem doing it either way. Personally, I'd prefer plural form for collections, including "Tutorials" and "Redstone circuits".
 * However, for the subpage clusters, we really need to decide one way or the other, and the admins should make sure that the redirects propagate to subpages properly. (E.g. "Tutorial/Piston circuits/Piston NOR Gate" vs. "Tutorials/Piston circuit/Piston NOR gate".)
 * A related issue that could cover some of the problems: How about making the default search page search for subpages, e.g. within Tutorials?  Also, it should certainly include the "Help" and "Minecraft Wiki" namespaces by default. -- 12:45, 18 May 2013 (UTC)


 * &ldquo;As long as there are redirects for the "other" form&rdquo;: Redirects shouldn't be needed except for weird pluralizations. Anytime you would want to link to the plural form, you should just use the  construction.
 * (and corrected titles will leave a redirect behind, that's fine)
 * &mdash; &middot;  &middot; 14:54, 28 May 2013 (UTC)

Bad example
From the page: If the word "the" is used before the mob name, it should not be capitalized unless it is at the beginning of the sentence.

Example given: One of the most feared mobs is the Ghast.

They contradict. -----undefined undefined 20:50, 30 May 2013 (UTC)


 * You misunderstood the style guide. It says to write “the Ghast”, not “The Ghast”. Or at least that's how I interpreted it, since there is a different guideline for capitalization of mob names. — 06:04, 31 May 2013 (UTC)
 * The name of that mob is "Ghast". "The", "a(n)", and "that" are all articles that you put in front, but they are not a part of the original name.  23:48, 14 June 2014 (UTC)


 * I know that. What I was trying to clarify is that the “it” that should not be capitalized is the word “the” in front of the mob name. — 05:15, 15 June 2014 (UTC)

Templates
I would like to see the following added:

"When using a template, please see its documentation for information on how to use it. A template's documentation can be thought of as an extension to the style guide."

Not sure if that gets the point across though. Yay/nay/ideas for better wording? — 13:47, 21 October 2013 (UTC)

Oxford comma?
Is there a preference on the use (or lack thereof) for the Oxford/serial comma? 01:59, 24 October 2013 (UTC)
 * Given the range of writing skills among our contributors, I think an overall policy would be pretty futile. That said, the classic advantage of the Oxford comma is to clarify lists of multi-word items, and we do a lot of that here.  --  09:54, 25 October 2013 (UTC)
 * Although I didn't know the name, I was taught to use that sort of comma in 2nd grade (which is probably why I didn't know the name before). I've made edits to articles for the sole purpose of adding that comma.  I always thought it was mandatory before, so if someone adds one in, hopefully nobody removes it.  23:44, 14 June 2014 (UTC)

Image guidelines
This page doesn't contain any information on images, e.g. what images should contain, what the criteria are for an image to be deleted, and particularly what belongs in the Gallery section on each page, and so on. Am I looking in the wrong place, or should the article be updated? 11:18, 7 January 2014 (UTC)
 * One thing I've noticed about some images is that they are too dark. I understand that in game lighting is inappropriate for certain pictures, such as mob grinders, but in those cases you should probably use a night vision potion.  15:14, 17 June 2014 (UTC)


 * The has some guidelines for images of redstone structures -- those aren't "rules" for all images, but there are some good guidelines there. But in general, images on the wiki are like text on the wiki -- do your best and maybe someone will improve it someday (which might include deleting it in favor of another picture or simple consolidation or simplification).


 * That said, I'm not sure most articles need a gallery section. If the image illustrates some point in the text, it should go with the text. And if it doesn't illustrate anything, delete it.


 * &mdash; &middot;  &middot; 01:36, 28 June 2014 (UTC)


 * And don't use copyrighted material illegally, especially important to note with images. -- ( 02:19, 28 June 2014 (UTC)

Template:Achievements
So I just made, and I was wondering if there is any reason I cannot replace the wikitable in the Achievements section with that. -- ( 14:34, 7 May 2014 (UTC)


 * So, Load achievements was recently finished and it works better for the Achievement section of articles. Can "use this table" be replaced with "use Load achievements"?
 * -- ( 21:02, 9 June 2014 (UTC)

In-game description
That came out of nowhere and happened way too fast. I'm glad Majr reverted the style guide quickly and I hope we can agree to revert all the pages that were edited too.

These in-game descriptions seem rather trivial and definitely not worth prominently displaying in their own sections at the top of the article. At best, if they're all as short as the ones I've seen, maybe putting them in the Block template. Otherwise they seem like Trivia.

&mdash; &middot;  &middot; 16:31, 3 July 2014 (UTC)


 * I noticed most of them are pocket edition exclusive, and are already discussed better in the article. Although I am waiting for an official consensus before removing/adding to them. -- ( 16:52, 3 July 2014 (UTC)


 * Some additional discussion of this subject is occurring on . &mdash; &middot;  &middot; 17:11, 3 July 2014 (UTC)


 * I do agree that they should be displayed somewhere less prominent, maybe between Video and History. I added the section to the style guide instead of reverting the mass edits because I thought I wasn't going to be able to stop from adding it everywhere, so I might as well make sure the section consistent across articles. — 17:51, 3 July 2014 (UTC)


 * [/gossip]
 * I like the suggestion of putting them in between the video and history sections though. I also earlier mentioned on my talk page we could put them on a page like Nether Brick/description, and then putting the code of   on the page. -   18:59, 3 July 2014 (UTC)


 * There is simply not enough content to justify an entire section, anywhere on the page. I'd be okay with a line in the Block itembox, but man that's getting cluttered for some of the blocks.


 * What would putting it in a subpage accomplish? The three reasons we use subpages I can think of offhand are admin-protection, reducing load time, and synchronization across multiple articles.


 * Please remember . &mdash; &middot;  &middot; 20:33, 3 July 2014 (UTC)


 * As mentioned on, these descriptions are gone in upcoming versions of which development previews are already available. Because of this, I don't see a reason why they should be mentioned outside of the History section. — 20:40, 3 July 2014 (UTC)


 * Sounds good. &mdash; &middot;  &middot; 20:57, 3 July 2014 (UTC)


 * What about a whole page about descriptions to cut out the who,e need to put them on every page, and just have them in the one place instead? -  21:00, 3 July 2014 (UTC)


 * You want a page dedicated to something that's about to be removed?
 * Since it's completely useless information, I would accept documenting its removal in the history section, and nothing more. – ᐸ  ⎜ 06:46, 4 July 2014 (UTC)


 * Okay, I think we have enough of a consensus so I'm going to start removing the sections that were added. &mdash; &middot;  &middot; 14:34, 4 July 2014 (UTC)

So, what are we going to do with this idea? I have a log of some of the descriptions over at waiting to be used. And they werent totally removed - descriptions still work in furnaces, and there are also descriptions on the Cosole version, which are not removed. -  15:21, 5 September 2014 (UTC)


 * Matt said it's okay to document removals in the History sections. For in-game descriptions still existent, I'd be willing to accept a line in the Trivia section. Something like:
 * The Console edition provides an in-game description for pumpkin seeds: "Plant more pumpkins."
 * &mdash; &middot;  &middot; 18:36, 5 September 2014 (UTC)


 * I was more thinking about a subsection of Trivia to put the description in, but as long as the page documents it I'm in. -   15:08, 6 September 2014 (UTC)

Redirect links
What is the official policy here on linking to a redirect? The style guide mentions nothing, but the trend around the articles seems to be to avoid linking to them. What is an official policy?

If redirects should be avoided, I also would like to know if a template to lowercase the title on a link would be useful. Opionions?

-- ( 00:24, 6 July 2014 (UTC)


 * Redirects are good and should be used where-ever convenient, bypassing redirects just causes wikitext clutter. The exception to this is within templates where self-links are likely, like navboxes. You want to make sure not to use redirects there so the page you're currently on gets bolded, and you don't end up navigating through a redirect back to the same page. – ᐸ  ⎜ 00:33, 6 July 2014 (UTC)


 * Should it be mentioned somewhere on the style guide to stop the constant replacement of redirect links? -- ( 00:37, 6 July 2014 (UTC)


 * It might be a good idea, yes. How about this? “Linking to a redirect is preferred over using a piped link except in templates and other pages that will be transcluded. When a piped link is unavoidable, it should not point to a redirect.” — 01:37, 6 July 2014 (UTC)


 * Sounds pretty good, except to mention "If a redirect can be avoided using a suffix on the link, that is preferred." Like as s . -- ( 01:50, 6 July 2014 (UTC)

Advantages/Disadvantages
Another section being added, that I am not sure is needed. Basically it restates food articles from a tutorial point of view. Should it get documented, or removed? An example of this. -- ( 18:04, 10 July 2014 (UTC)


 * Not needed. There is already which is the best place to compare different food types. I say delete the sections (possibly incorporating useful info into the tutorial) and add a link to the tutorial (on all food pages? articles really should link to more tutorials I think).


 * But as for policy -- ideally, articles should simply document the item/block, and leave strategy discussions to tutorials and guides. However, not everyone has the time to write up a full guide on a subject, and until such a guide exists the articles are the natural place to explore ideas about what is important to write about. So I'd recommend not being too strict about little strategy notes, but when a few of these have shown up that share a theme then move them to a new guide and link to it from the articles to encourage others to improve the guide.


 * &mdash; &middot;  &middot; 19:46, 10 July 2014 (UTC)


 * We do have the often unused "See also" section, which is not suppose to link to articles already linked previously (about that). It could ideally link to tutorials that are relevant and somewhat well done. -- ( 22:10, 10 July 2014 (UTC)


 * I would only use the "See also" section if there was no other place to put it. For example, I would probably add Hunger Management as a see also link in the Usage section of . Tutorial links will be more useful if they are prominent, both to the reader and to keep people from adding stuff that should have gone in the tutorial. &mdash; &middot;  &middot; 02:46, 11 July 2014 (UTC)


 * I have seen that used frequently on pages like . The entire section was moved to a tutorial due to the chaotic amount of information. Some will do better with Main and some with See also -- ( 03:03, 11 July 2014 (UTC)


 * Sounds good. I'm going to conform now because it's bugging me. Were there other articles with ads/disads? &mdash; &middot;   &middot; 03:18, 11 July 2014 (UTC)


 * As far as I can recall, it's mostly foodstuff articles that have these sections. -- undefined 03:21, 11 July 2014 (UTC)


 * The cake, golden apple, melon, steak, rotten flesh, raw chicken, raw beef, pumpkin pie, carrot, bread, baked potato and cooked porkchop pages have this. – ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>  03:22, 11 July 2014 (UTC)


 * Blurg. Well, we'll see. Should probably update the tutorial first with the strategies and comparisons, then do those. And I'll wait to see if anyone attacks my cooked chicken rewrite as "wrong" and work out compromises before starting on the other articles. &mdash; &middot;  &middot; 04:05, 11 July 2014 (UTC)

That one looks good. The link to the tutorial is well placed. -- ( 15:02, 11 July 2014 (UTC)

Future section
The style guide currently says that information about upcoming changes should be in a "Future" section, but gives no guidance on where to put it, etc.


 * 1) Is this still what we want, or should upcoming changes be described with the things they'll affect? (obtaining, usage, etc.)
 * 2) If we have a Future section, how should it occur in the article?
 * 3) Call the section "Future", "Planned", "Upcoming", …?

I slightly prefer consolidating all upcoming changes in a section by themselves, but I don't feel too strongly about it (there's merit to putting changes with the things they'll affect, but that does get messy). I'd call the section "Upcoming" (match use of term in Blocks, History, etc.) and make it an h2 before the History section, with a note at the top that says "This section describes changes that may be included in the next update. These features have appeared in development versions, but the full update containing these features has not been released yet." (probably templated for consistency).

Some implementations of such a section will just be repeating what's in the History below for Upcoming snapshot releases, but others will need space to expand on those little notes and prepare text for when it will get incorporated into the rest of the article.

&mdash; &middot;  &middot; 21:57, 12 July 2014 (UTC)


 * I would opt for including upcoming changes in the relevant content sections, and using Upcoming to mark them as such. In cases where major changes are planned for upcoming versions (such as or  currently), having a “Future” or “Upcoming” h3 in the History section might work best. (The  article already has this, except named “”.) To keep with the principle of including future changes in the relevant section, there could be section header notes from content sections affected by future changes down to these “Future” sections. — 22:26, 12 July 2014 (UTC)

Properties or crafting first?
Initially posted on

Hey, sanoth here. Noticed how you moved the "Properties" section of the s article and put it after the "Crafting" section. I'd like to avoid this for two reasons:


 * 1) The crafting section is so long, lots of people will miss the properties section.
 * 2) If you check the  article (that I tried to form this article after, since they are quite related), you'll notice that the properties section is before the crafting section.

So I'd propose we put properties before crafting. :) What do you think?

--undefined 21:16, 23 July 2014 (UTC)


 * I was going based on the style guide's "Intro, Obtaining, Usage, Other sections, ect." I would be fine with it moving back, but this is really more of a conversation for the -- 21:24, 23 July 2014 (UTC)


 * Woops yeah, just wanted to contact you personally. I was also thinking that you'd maybe wanna know facts about the banner before you craft it? So, it's alright if I go ahead and move it? --undefined 21:28, 23 July 2014 (UTC)


 * I think it would be better to discuss it with a few other people first, since it does go against the style guide. Whatever decision is made can then be applied to both articles. -- 21:33, 23 July 2014 (UTC)


 * Sure, I'll paste this in the style guide discussion --undefined 21:34, 23 July 2014 (UTC)


 * "Properties" should simply be discussed in the Usage section. &mdash; &middot;  &middot; 22:21, 23 July 2014 (UTC)


 * I agree. Also, having a long “as a crafting ingredient” section (appropriately called “patterns” in this article) seems not enough of a reason to go against the usual article layout and make it a h2. — 11:44, 24 July 2014 (UTC)


 * I was placing "Patterns" as a separate from obtaining or usage, since it is part of the the usage, rather than the obtaining. -- ( 15:27, 24 July 2014 (UTC)


 * Hmm, tricky. I think, since they're all banners, the patterned banners should just go in Obtaining. Conceptually, there isn't much difference between adding patterns to banners and adding colors to wool -- it's still the same block and this is how you obtain its variations. I would only put the patterns in Usage (definitely not a separate section though) if they were actually a different block you were using banners to craft. &mdash; &middot;  &middot; 17:14, 24 July 2014 (UTC)


 * Good point. I will move patterns up into obtaining then. — 00:02, 25 July 2014 (UTC)

Publicity section
As seen mainly on the articles and. Where would be the best spot to put it? I think it interferes with the reading the article when you have it before the history section, and would likely work much better after the history (possible a subsection of trivia, like I did on pickaxe). -- ( 01:46, 29 July 2014 (UTC)


 * . I think it works well as a subsection of Trivia. — 06:33, 29 July 2014 (UTC)

Mob articles
What sections are proper for mob articles? common sections seem to include drops, combat, and behavior, spawning.

Other sections include variants. The rest of the sections are the normal sections mentioned here in the style guide (video, history, trivia, gallery). My main question is can we add mob articles to the style guide in some way? Spawning can be an alternative of obtaining, and drops an alternative of usage, but it would still be better to have the style guide mention them directly.

-- ( 02:25, 14 August 2014 (UTC)


 * . I think the style guide should mention that for mobs, obtaining should be replaced with spawning, and usage with drops. Behavior should go after that (but before the “all other sections go here” bit), since it tends to be much more detailed than drops. — 02:31, 14 August 2014 (UTC)


 * What is your opinion on combat? If only to link to the proper tutorial. -- ( 02:33, 14 August 2014 (UTC)


 * I'm not sure. At a glance, combat sections seem to have improved in style lately, so it might not be necessary to add something about them to the style guide. The only thing could think of is what you mentioned: they should always have a Main to the corresponding tutorial (if it exists), but that should probably be a more generic guideline since it also applies to other things such as farming tutorials. — 02:44, 14 August 2014 (UTC)


 * Spawning for Obtaining and Drops for Usage sound fine, and adding a Behavior section, but a Combat section should be limited to documenting how the mob behaves in combat (perhaps just as a paragraph in Behavior) -- it shouldn't discuss player strategies for defeating them (my whole "articles should document, tutorials/guides may discuss/opine" philosophy). &mdash; &middot;  &middot; 03:05, 14 August 2014 (UTC)


 * Good point. So the Behavoir section might have a “see also” link to the corresponding tutorial. — 03:09, 14 August 2014 (UTC)


 * Another thing, the "Appearance" sections, most of what is contained there is already in the picture in the infobox, others of that stuff is more of trivia, and the rest is size stuff. Would the size information be better in behavior or it's own section? -- ( 15:54, 14 August 2014 (UTC)


 * I found another section I forgot to mention. On many passive mobs there is the section on "Breeding". It is often a little long to be included in the "Spawning" section, so I suggest it getting it's own section. See for some things I've done with that. -- ( 14:21, 25 August 2014 (UTC)


 * Size information is usually only going to be a sentence or two, so I'd just make it a paragraph in Behavior (affects how it interacts with blocks, tunnels, etc.). &mdash; &middot;  &middot; 06:40, 16 October 2014 (UTC)


 * There's also "Taming" section, for and s. Where to put it (more likely Behavior)? -- ♦   08:47, 23 October 2014 (UTC)


 * Yeah, I would agree with behavior. If it is long, as a subsection, otherwise as a paragraph or two.
 * KnightMiner@undefined Later suggestion relating to breeding section is just about the same. Long like on can get its own section, otherwise as a subsection of spawning. <span class=nowrap>–  15:18, 23 October 2014 (UTC)

Video notes
An addition was just made to the style guide about adding notes to the video section that doesn't seem to have been previously discussed and with which I have a minor disagreement:


 * "If notes are made to correct the video, they should be above the video and the Note: should be in italics."

Personally I think there's rarely any reason to actually use the word "Note". Just state the facts. "The video below is outdated because …" or something.

I realize this is a minor writing-style point, but I'm bringing it up because it's now been enshrined in the style guide without discussion (that I can find -- if I missed it, I apologize).

In general, I'd like to state my preference that additions to the style guide are only made after discussing them here on the talk page, not simply because it's become a common practice in some articles which not everyone may be watching, or have cared about before it was proposed as a permanent part of the style guide. Some editors (myself included) tend to concentrate on certain areas/aspects of the wiki and their writing style can come to dominate those concentrations -- so a writing pattern shouldn't become "the style" for the entire wiki without a greater discussion, and that should occur here.

&mdash; &middot;  &middot; 17:36, 14 August 2014 (UTC)


 * I personally do not care for the word "note" much either. I personally think the entire note should be in italics, and the note should stated outdated rather then incorrect. -- ( 17:46, 14 August 2014 (UTC)


 * I also agree with this, however it would be somewhat easier if the video creators regularly checked the wiki for outdated videos. -  18:10, 14 August 2014 (UTC)


 * Apologies for the addition without discussion. Maybe there should be a yellow warning box above the style guide's editing area that says that all changes should be discussed here first.


 * I agree that the Note: part seems unnecessary, but having entire paragraphs in italics can be quite hard to read. So I propose that the note should simply be formatted as normal text in an article would, or as a bullet list in case of multiple notes (as on ).


 * As for the “outdated” vs. “incorrect” bit, it should say “incorrect” if the information in the video was never correct, even in past releases of the game, which appears to be a quite common occurence. — 00:15, 15 August 2014 (UTC)


 * I agree on non-italic and support adding a message box to the top of the style guide. Proposed text: "Please do not add new style guidelines without first discussing them on the style guide talk page." &mdash; &middot;  &middot; 04:51, 15 August 2014 (UTC)


 * I always felt that discussing changes first was implied. Is there a good way to add it as an editor's note maybe? -- ( 03:34, 16 August 2014 (UTC)


 * A notice can be created at . See for details. — 04:11, 16 August 2014 (UTC)


 * , thanks . — 06:59, 21 August 2014 (UTC)

Top of articles
Is there any specific order the templates on the top of the article are suppose to be in? Specifically templates like about, block, and snapshot. I overall find it to look better if the info box is first, then any article notes (about), then any message boxes, otherwise the infobox is pushed down by the other two. -- ( 20:41, 18 August 2014 (UTC)


 * . It really bothers me when people put the infobox after other elements. Your proposed sorting makes sense. — 05:44, 19 August 2014 (UTC)

Obtaining subheaders
Where an item is obtained naturally (in the world), should the header be Natural occurence, World generation or Natural generation. Also, should there be a From preceding the obtaining method, for example in the page rewrite? Either way, I think a consensus needs to be added to the style guide. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>  01:20, 30 August 2014 (UTC)


 * I have preferred "Natural generation" over the others. As for the "from", I have only been adding it as to say "From <entity>", as in most cases I just use "As a drop". And I agree that we need a consensus.
 * Generally as the style guide uses, obtaining contains sections using simply the name, while usage uses "As a" for recipes and does not mention other types. It may be better for obtaining to state "From <method>" or "<recipe>" and usage to contain "As a <recipe>" or "<use>".
 * -- 01:42, 30 August 2014 (UTC)


 * I've been using Natural generation, but now that you mention it World generation seems like a better technical term. But they definitely don't occur, they are generated.


 * We have been using "As a…" a lot for Usage. I don't think the prepositions are necessary -- the section headings make just as much sense without them -- so my preference for concision would say not to use them in either sections. And I think the non-prepositional form makes better links. But I don't feel very strongly about it.


 * &mdash; &middot;  &middot; 01:49, 30 August 2014 (UTC)


 * I would be fine with removing the "As a" and "From" if the Usage and Obtaining headers are not renamed for one section. "As a" is still a little better sounding for "As a crafting ingredient", otherwise simply "Crafting". -- 01:55, 30 August 2014 (UTC)


 * My opinion is to use Natural generation and remove the as a and from headings, except for As a crafting ingredient as listed above. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   05:41, 30 August 2014 (UTC)


 * Although what should be done for as a food, as animal food and endless other headers for items? <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   05:43, 30 August 2014 (UTC)


 * As animal food could also be Breeding or For breeding, except in the case of horses. As a food does not have many other options though. -- 14:24, 30 August 2014 (UTC)


 * Just say "Food". Makes sense to me. "Usage"? "Food". &mdash; &middot;  &middot; 15:36, 30 August 2014 (UTC)


 * Ok so if we can all agree on these below I will add them to the style guide.
 * In the obtaining section, Natural generation for location in the world. Headings should be stated without the prefix From. For example, Creepers should be used instead of From Creepers.
 * In the usage section, headings should not be prefixed with an "As a", except for As a crafting ingredient or As a brewing ingredient. Food should be used, not As a food. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   05:22, 3 September 2014 (UTC)


 * I still don't feel very strongly about it, but I don't see why we need exceptions. "Usage"? "Crafting ingredient". Makes sense to me as a heading and as a link, at least as much as any other title. I'd prefer consistency one way or the other, either way. &mdash; &middot;  &middot; 05:44, 3 September 2014 (UTC)


 * That does not sound too bad. I would agree to using "Crafting ingredient" and alike. -- 12:47, 3 September 2014 (UTC)
 * That does not sound too bad. I would agree to using "Crafting ingredient" and alike. -- 12:47, 3 September 2014 (UTC)


 * Ok, I agree with no exceptions. Changing style guide now. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>  13:28, 3 September 2014 (UTC)


 * On another note, there needs to be clearer guidelines as to what to do if there is only one obtaining method/one usage. Should the header 2 titles still be obtaining and usage? Should there be a header 3 title indicating what specifically it is? Should the header 2 title be replaced with more specific method (e.g. just crafting). The style guide does not make it clear, and I have seen all three cases when looking through rewritten pages. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   13:28, 3 September 2014 (UTC)


 * I prefer always having "Obtaining" and "Usage", suggest removing the option to replace Obtaining with Crafting. H3s are needed only when there are multiple subsections, otherwise just describe the single method/use under the H2.


 * Also, in the future, I'd recommend waiting at least a week or two before making changes to the style guide based on talk page discussions. Let ideas percolate for a while, and people with important contributions to make might be on vacation or something. &mdash; &middot;  &middot; 14:33, 3 September 2014 (UTC)


 * I agree with retaining the obtaining/usage headers. Sub headers can then be used if needed.
 * On another note, I have been putting information on mining a block directly after the obtaining header, specifically noting proper tool, fortune, and silk touch. Methods of generation/crafting then go after that. Should that practice be noted in the style guide / does anyone disagree with that practive?
 * -- 14:50, 3 September 2014 (UTC)


 * I would be in favor of adding this to the style guide. Currently, the tool needed to break a block is often only documented in the infobox, and the effects of enchantments are often not documented at all on the article (only on ).


 * As for the sections, I would recommend always having a header corresponding to the method of obtaining/usage type, even when it is the only one, so that it can be quickly identified when skimming the article. I originally proposed to replace the h2 with this header in some cases, but for consistency I would now prefer to have it as a h3. This would also work best with the aforementioned proposal to include mining info before the first h3. — 01:07, 5 September 2014 (UTC)


 * I'm not sure what you're saying about mining (examples?), but I think a general rule should be: one method, put it directly under Obtaining with no subsection heading; multiple methods, each get their own subsection heading. So if mining a block is only one of multiple ways to obtain a block, then mining should get its own subsection. If it's the only way to obtain the block, then it's fine right under Obtaining without its own subsection heading. Similarly for Usage and possibly other sections. Is that what you're saying, or something different? &mdash; &middot;  &middot; 03:22, 5 September 2014 (UTC)


 * That is not at all what I was trying to say. The wiki has never treated mining blocks as a method of obtaining, and I don't see why it should start now. Instead, what proposed is to add info about which tools are required to mine a block at the start the Obtaining section, before the h3s that describe how the block can be obtained. E.g. For, this info might say that an iron pickaxe or better with Silk Touch is required, followed by the “natural generation” h3.


 * Because this mining info would appear between the Obtaining h2 and the h3s, it makes sense to use a h3 even for a single method of obtaining. It additionally makes it clearer what the section is describing, and gives articles a more consistent structure. What are your reasons for preferring to omit the h3 for a single item? — 03:40, 5 September 2014 (UTC)


 * Ah. Hmm. I guess "mining" applies not only to obtaining, but also to usage, because it's also applicable to removing a block you've placed after obtaining it. And what about manufactured blocks -- where do we put the discussion of using a tool to remove them? Is that Obtaining? Hmm. I'd like to think about this some more. &mdash; &middot;  &middot; 03:57, 5 September 2014 (UTC)
 * Well, mining is technically how you obtain most blocks, if you define obtaining as putting in your inventory. So I think it makes more sense there. And I don't see why we shouldn't add mining info for manufactured blocks. — 04:01, 5 September 2014 (UTC)
 * Well, mining is technically how you obtain most blocks, if you define obtaining as putting in your inventory. So I think it makes more sense there. And I don't see why we shouldn't add mining info for manufactured blocks. — 04:01, 5 September 2014 (UTC)


 * Munin295@undefined: Basically what I would do with that section. I state if fortune or silk touch affect the drop, what it drops when mined normally, and what tool is required to mine it.
 * So for diamond ore, it would state an iron pickaxe or better gives you a diamond, it will drop itself from a silk touch pick, and it will drop multiple diamonds from fortune. -- 15:14, 5 September 2014 (UTC)


 * So, for some redstone components (and other blocks, I'm sure) it's important to note things that can destroy a block (water, lava, pistons, etc.). I had been placing those in a section called "Removal" under Usage, and it made sense to me to include mining by players there as well. But if mining should go in Obtaining, where's the best place to talk about things that destroy a block? Technically, some of those methods could be used to obtain the block too, so move that discussion to Obtaining? But it makes sense to discuss lava along with water and pistons, and lava can't be used to obtain the block. Or is it all "behavior", so should still go under Usage? &mdash; &middot;  &middot; 19:49, 15 September 2014 (UTC)


 * I don't think consensus has been reached on where to discuss block removal (one person agreed, one person didn't). Discussing how to break blocks is a subject being actively explored in articles and editors should have the freedom to play around with different ways to present the information until we've addressed all the questions (some of which I mentioned in the post above, but there likely will be others). It's simply premature to over-specify the style guide before the subject has been explored and we've discovered the best ways to present the information. There's absolutely nothing wrong with having some article structure inconsistencies while the subject is being explored, so there's nothing to be gained by jumping the gun on adding the rule to the style guide. I'd like to remove this rule until the subject has been explored further. &mdash; &middot;  &middot; 21:44, 19 September 2014 (UTC)


 * I had though we had a consensus, as there was two votes for, and one undecided. I also find it to overall make more sense to list in obtaining. Say I am a random wiki user. I read the article on stone, and want to know how to break the block, would my first implication be to check obtaining or usage? -- 03:54, 20 September 2014 (UTC)


 * Just to pitch in my vote, I agree that the block removal information should be in the obtaining section. In response to Knightminer above, obtaining seems like a more logical place to put it. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   09:46, 20 September 2014 (UTC)

Using DLs to organize content
I wanted to check and see how others feel about using DLs ( and  ) to organize content in articles. I'm not bringing this up to get it enshrined in the style guide, but just to gauge whether others might be inclined to remove them later. I know some people feel that DLs shouldn't be used to organize content, but only to define terms (its original HTML stated purpose).

I like using DLs because they can make walls'o'text more readable without spamming the TOC (as would have been the case with, or redstone circuit articles with lots of circuit write-ups) or without adding headings to the TOC which IMO just don't need to be there (for example, or ).

I even like the indentation that  gives as I think it helps to make the organization clearer.

Thoughts? Hates? Are others using them?

&mdash; &middot;  &middot; 01:17, 31 August 2014 (UTC)


 * I have mainly been using them in info boxes and lists, but it could work in articles like you mentioned. The only problem I see is the headers are rather small, looking a bit odd with the recipe templates. If needed, there is a way to display the title without adding it to the TOC (if I could remember how, that might be useful...) -- 02:57, 31 August 2014 (UTC)


 * Wikipedia has, but I don't think we do. Personally, I don't like using headings below h3 because the sub-sections are hard to distinguish with the default formatting -- the indentation of DDs helps with that, I think. &mdash; &middot;  &middot; 03:09, 31 August 2014 (UTC)


 * I think it looks better as a list on, but I personally prefer the subsections for obtaining on (and make the section on redstone dust be an h2 section). So I say use h3, but lists can be used instead of h4. --  03:21, 31 August 2014 (UTC)

Tile Entity section
So on I tried out adding a section on the block's tile entity.

Is this a great idea that will be helpful in the article and provide a good place for discussion and examples that wouldn't fit in, et al., or is this a terrible idea that will only make it harder to maintain this info? : )

&mdash; &middot;  &middot; 22:09, 2 September 2014 (UTC)


 * And here's another possible approach at . &mdash; &middot;  &middot; 02:12, 3 September 2014 (UTC)


 * I like the second one a little better, and agree adding tile entity data would be useful. It would also be helpful to start implementing block states into the DV sub page. I might see about a template for that... -- 02:19, 3 September 2014 (UTC)


 * , block states and tile entities should both be documented under the data values section. They could be differentiated from the item data value by adopting the internal label and calling it damage value. — 01:57, 5 September 2014 (UTC)


 * Over at, LB and I are brainstorming ways to break out the data structures into subpages so they can be transcluded into both chunk format and block/entity articles so they only need to be maintained in a single place (chunk format subpages).


 * I don't think there's a need to differentiate block/tile data from item data. Or at least I've always been calling it either block data or tile data, which shouldn't get confused with item data, I think. Damage value seems like an outdated term too, compared to the more generic item data.


 * I am going back and forth about whether it should be "block name, block data, and block entity" or "tile name, tile data, and tile entity" (I don't feel a need to be consistent right away -- I try them both out on different pages and see how I like them after a few days). I think "tile" is a better technical term generally, and "TileName" has been used in recent command arguments. But some people seem to prefer "block entity" over "tile entity" recently.


 * Down the road, we might consider adding discussions on block models to the section as well. &mdash; &middot;  &middot; 04:04, 5 September 2014 (UTC)

I just made a template (block state table) kinda like data value table for displaying block states. Should we start adding block state subpages (maybe /BS or /state) so they can get transcluded onto ?

Also, I agree on adding the names of the block state files / item model files to the data values, but the actual model files are not really needed, as they are relative. -- 21:45, 6 September 2014 (UTC)


 * I'm not exactly sure how it works, but what if we just added the block state tables to articles directly, and simply collated them the same way the  subpages do? &mdash; &middot;   &middot; 23:48, 7 September 2014 (UTC)


 * I assume you mean . It could be done, but it may lack several features, such as the ability to organize the information or group multiple of the same. Basically it would organize by page title, and heap the information in a pile.
 * The other main problem would be duplicate information would not only exist, but be loaded, such as between dirt and podzol, or the various types of stone. Also, eventually this would altogether replace the block meta data. -- 02:08, 8 September 2014 (UTC)


 * So, do we have a final format design for data values? I have a few questions based on what we discussed.
 * Should block states go on /DV, their own sub page, or directly onto the article and be loaded using a fancy template
 * What general order should the sections go in? I like the idea of "Block data"/"Item data", "Block states", "Model names", then "Entity data" (block entities go here)
 * Do we need a template for formatting model names? Each item will have between 1 and 16, and each block will have between 1 and 32.
 * -- 02:53, 11 September 2014 (UTC)


 * If dpl won't work, then let's put block states in their own sub-page to make collation easier (, I guess). I'm not sure what's going to happen with , but for now /DVs should collate there and /BSs should collate at.


 * By "model names", do you mean block model variants? Otherwise, ref?


 * Would it make sense to include the ID name (e.g., ) in the block state table? For many it will just be one extra line, but for some it might be easier and more concise to describe the ID names in the same table (and if we do it for some, we should do it for all), either because a "single block" has multiple ID names (like redstone torch), or because we're describing multiple blocks on one page (fences, doors, etc.). For example:
 * {| class="collapsed collapsible"

! Block state table with multiple ID names


 * }


 * I don't know if the ID name is technically part of the "block state", but it's lumped together with the other fields in the F3 screen, and it all gets spit out together in a result, so it shouldn't confuse people too much, I think. &mdash; &middot;   &middot; 04:09, 14 September 2014 (UTC)


 * As for "Model name", that would state the path to the model file from "assets/minecraft/blockstate" or "assets/minecraft/models/item"
 * Adding the block id would be helpful in a few cases like that, but can you think of a good way to differentiate it from a tag? I am thinking an icon replacing the string icon with a hovertext stating that it is a name id, but I cannot think of a good icon... Maybe " Name ID"
 * Otherwise group the ids in a separate section of the table, although in most cases where the blocks are merged, either only one id group is relevant (door) and a title can be used, or all use the same (door) and a value can be used.
 * -- 21:37, 14 September 2014 (UTC)

Pages in the Environment category
Currently, there is no style guide for pages in. However, many of these pages are a mess with paragraphs of information in the introduction etc. Should there be a guide for pages in the Environment category? Or is it too broad to create a guide? Or could there be different guides for the different categories in ? <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>  06:43, 9 September 2014 (UTC)

Similarly, many pages in such as  need to be rewritten. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>  06:54, 9 September 2014 (UTC)


 * It is somewhat hard to create a guide for those pages as they are so diverse in what is required. You can follow the basic guidelines (obtaining, usage, ect.) in the form of "Accessing", "Properties", other sections, ect. Also, tutorial information should always be moved to a tutorial article or removed. -- 14:02, 9 September 2014 (UTC)

Configurable controls
I often find articles referring to a by the default key or button. Should there be a style guideline to refer to controls by action verbs more closely associated with the control? The default key/button could still be mentioned in parentheses. For example, “The 3×3 crafting grid can be accessed by using (default: right-clicking) a crafting table.” — 10:25, 15 September 2014 (UTC)


 * Recently I've been getting even more explicit -- for example:  &mdash; &middot;   &middot; 11:02, 15 September 2014 (UTC)


 * I personally think we should keep mentioning the default controls, not only does it read easier to simply state the control, but we also don't mention everywhere that the names can be changed with a resource pack/language, or that the textures can be adjusted with a resource pack, or even the shaders/models can be readjusted.
 * Although if the consensus is to use control names rather then the button you press, I think a template would be in best interest for consistency, and to link to controls. -- 14:39, 15 September 2014 (UTC)


 * Changing controls is a lot easier than making or even using a resource pack. But yes, a template might be a good idea. — 15:40, 15 September 2014 (UTC)


 * My main point is adjusting of the controls is just as unofficial as languages or resource packs, stating "You must press 'Use item' (defaults to right click) to ..." would affect article readability. Just as most people tend not to use translations or resource packs, most people will not change their controls. And having to read another article to find the default control is out of the question.
 * Possibly it could be displayed as a tooltip, maybe something like "You must right click to...", or "You must press 'use item' to...", although in either case, a template would simply and create consistency between. A link to controls may also be applicable.
 * -- 16:10, 15 September 2014 (UTC)


 * I'd prefer to refer primarily to control names, with the defaults mentioned parenthetically or as a tooltip. Personally, I play with a left-handed mouse and use the numpad for movement, so I've remapped almost all of the configurable controls, and it bugs me a little when people assume everyone will be using the defaults. I'll see if I can throw together a template for consistency. -- undefined 20:59, 15 September 2014 (UTC)
 * Template:Control is made, currently using tooltips. Example usage: "accessed by a crafting table" or "you must press the  key". The tooltip is looked up based on the control name; the   parameter lets you use arbitrary text in the prose, which is good for verb forms. -- undefined 21:35, 15 September 2014 (UTC)


 * Orthotope@undefined That looks good, I would agree to using it. Although for the keys with no default, such as some of the streaming keys or spectator's highlight players, you may want to add a "No default" function. -- 21:49, 15 September 2014 (UTC)


 * I'm having trouble using this template for simple statements. Am I supposed to write something like: "To open a chest, it."? Or can I say "To open a chest, use the  ."? &mdash; &middot;   &middot; 14:28, 18 September 2014 (UTC)

Based on the way the template is set up, and what reads better, I would go with the first one. I mainly try to remove the "/" from the middle, as it makes it a sentence, rather than an option. -- 19:48, 18 September 2014 (UTC)


 * 'No default' handling added. I'm not attached to how the template parameters are currently used; if you think a different syntax would be more convenient, we can change it. -- undefined 20:50, 18 September 2014 (UTC)


 * It may be helpful to add a suffix parameter (to extend the tooltip). Replacing with  may also be useful, as   is a bit simpler syntax. --  21:20, 18 September 2014 (UTC)

Real world trivia
We need an official policy on real world trivia. Trivia like
 * "In real life, mycelium is the mushroom's nutrient gathering web of thin threads known as hyphae. The entire mushroom, from the mycelium to the cap Is made entirely of hyphae."

is relevent, but trivia like
 * "In real life, rabbit's feet are considered lucky"

is not. Basically, I suggest that real world trivia is only relevant to state major differences between the real world thing and the minecraft version.

-- 15:59, 15 September 2014 (UTC)


 * Some of the trivia about the real-world inspiration for blocks and items is good (such as lapis lazuli, mycelium, and podzol), but a lot of the comparisons aren't interesting or useful. The trivia about how much players supposedly weigh or can carry is particularly bad. -- undefined 21:10, 15 September 2014 (UTC)

Undiscussed pages / sub-style guides
We seem to lack policies on various types of pages that are less regular, such as "hub" articles (tools), generated structures, environment pages, and version pages.

Also, as we seem to have many different types of pages, would it be relevant to split the style guide into several sub-pages? Most general content pages, such as blocks, items, and entities contain the same basic things, but a lot of other types are rather unique, especially versions. Another idea would be to add those types of versions on their own sub page, and keep the current style guide as general content pages.

<span class=nowrap>— 03:51, 9 October 2014 (UTC)


 * Generated structures can be of following layout:
 * Introduction. Briefly about the structure. It should only have up to a couple sentences.
 * Spawning (if relevant). Where it spawns.
 * Structure. How it generally appears: how it generates and what blocks it's composed of.
 * Loot (if relevant).
 * Strategy (if relevant). How to advance through the structure and loot it.
 * General articles go here.
 * -- ♦  11:33, 10 October 2014 (UTC)
 * EDIT 1: Changed the list. -- ♦  11:35, 10 October 2014 (UTC)


 * Strategy should be removed, we never discuss tutorial in the main pages. Instead a link to the relative tutorial in the structure section may be relative.
 * — 15:26, 10 October 2014 (UTC)
 * I agree, maybe I forgot.
 * Below is the layout I want to use on :
 * Spawning: A single paragraph about positioning of Far Lands.
 * Structure
 * Edge Far Lands
 * Corner Far Lands
 * In the Nether: Differences between the two realms.
 * In Pocket Edition: Differences between PC and.
 * Strategy: Has a link to.
 * Effects: Lists the effects of Far Lands.
 * Trivia
 * History
 * Gallery
 * -- ♦  07:17, 12 October 2014 (UTC)


 * with proposals for the structure of generated structure pages, as well as the proposed Far Lands structure. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   07:47, 12 October 2014 (UTC)


 * You don't need to say "In the Nether" or "In Pocket Edition", just use "The Nether" or "Pocket Edition". And no Strategy section -- if there's no obvious section for a link, add a See Also section. &mdash; &middot;  &middot; 07:56, 12 October 2014 (UTC)
 * . Continue the discussion of Far Lands page rewrite . -- ♦  08:54, 12 October 2014 (UTC)
 * Dimension pages can use the following layout:
 * Introduction - Brief introduction.
 * Structure - General spawning patterns.
 * Blocks, structures and mobs
 * Naturally generated - Naturally generated blocks.
 * Naturally created - Naturally created blocks (like cobblestone from water and lava and obsidian from s)
 * Structures
 * Mobs
 * File save location
 * General sections go here. See also has distinctive links to tutorials (Getting on top of the Nether, End survival etc).
 * -- ♦  06:54, 17 October 2014 (UTC)
 * Goandgoo@KnightMiner So, the guidelines for most structure sections can be something like this (open the spoiler):


 * Rewriting and  would be somewhat harder: they need to be created by players, and the former can even generate itself to allow entities to return from the other dimension.
 * -- ♦  12:51, 24 October 2014 (UTC)


 * Naista2002@undefined Those guidelines look good. Generation could alternatively be named "creation" in the case of the, and it may fit well for the as well.  <span class=nowrap>–  15:38, 24 October 2014 (UTC)


 * KnightMiner@undefined Great. Can I now create the sub-project? What about categories, I'll add pages to them with my bot. -- ♦  16:01, 24 October 2014 (UTC)


 * We normally wait a few days to a week to see if anyone disagrees before adding to the style guide. The sub-project could be created, although the guidelines won't be official just yet.
 * As for categories, they get added manually after a page is rewritten, and removed with a bot upon project completion (which has not been needed yet). <span class=nowrap>– 16:13, 24 October 2014 (UTC)
 * I've meant, not . -- ♦  16:20, 24 October 2014 (UTC)

"We normally wait a few days to a week to see if anyone disagrees before adding to the style guide."


 * Yes, you're right. ?
 * -- ♦  16:25, 24 October 2014 (UTC)
 * P.S. Are Quote templates fine to use in talk pages?
 * When you'll discuss, we'll have the filled with pages already. My bot is working on that. -- ♦   16:57, 24 October 2014 (UTC)
 * ? -- ♦  06:51, 25 October 2014 (UTC)
 * ? -- ♦  06:51, 25 October 2014 (UTC)


 * would be fine added to the pages, since it applies. If you want, you can also start the sub-project (otherwise I will likely start it once the rules become official)
 * I generally find quote a little intrusive due to the amount of whitespace, especially on talk pages. I think it officially fine though
 * – 15:15, 25 October 2014 (UTC)
 * Thanks! -- ♦  15:56, 25 October 2014 (UTC)
 * Is someone going to check my guidelines? -- |  17:58, 2 November 2014 (UTC)


 * Sorry, I have checked them and they were good, I just forgot to mention it. I think it has been long enough to add it to the style guide, but it is getting a little crowded with its "If A then B, if C then D". – 01:07, 3 November 2014 (UTC)

Sub-style guides
As for the proposed sub style guides, I have made a. It may also be useful to split the "article layout" out into a sub style guide as well (or multiple for differnet types (mobs, blocks and items, structures) only problem is the sections they share), then change the article layout section to link to the sub guides. <span class=nowrap>– 03:33, 8 November 2014 (UTC)


 * Anyone have an opinion? I really cannot implement official guidelines without an consensus. <span class=nowrap>– · 00:15, 7 December 2014 (UTC)


 * I haven't been very involved in the style guide discussions, but it sounds reasonable to me, mostly formalizing the existing practice on version pages. -- undefined 00:51, 7 December 2014 (UTC)

Number formatting
The style guide should say something on this. I chose to use a thin space as a thousands separator to avoid the international community. (Thanks for pointing out the broken link, Munin.) This is similar to the direction set for date formatting, where potentially ambiguous formats are avoided. However, it was quickly changed to standard US formatting. It does seem to be the most common formatting on this wiki, but I doubt it's what's best for us.

You have to keep in mind that even if this wiki officially uses US formatting, an editor might not be aware of it and enter incorrect information. The possibility of that in turn makes readers and editors alike question numbers as much as always. What do you think when you read thunder can be heard up to 160,000 blocks away? I can vouch for it, but the outrageous magnitude is likely to lead to misinterpretations. It's even worse for numbers that aren't as round as this, where the comma is still more likely to be a decimal mark. I'd rather just sidestep the whole issue and format unambiguously as much as possible.

Any thoughts? -- 00:41, 10 October 2014 (UTC)


 * That "confusing" link doesn't go anywhere (did you mean ?), but Wikipedia is on using a comma just like we are even though they aren't standardized on American English. Grouping by spaces is only used for scientific/engineering articles where SI formatting might actually be known to the reader (it will be an unknown formatting style to the vast majority of our readers). This wiki uses American English formatting -- it's making exceptions that would be confusing. If an editor makes a mistake (have any?), someone will correct it; if a value is potentially confusing, it can be explained (e.g., "up to 160,000 blocks away, vastly far outside the usual chunk loading radius."). &mdash; &middot;   &middot; 01:15, 10 October 2014 (UTC)


 * Looking at Wikipedia a bit more, the use of commas as thousands separators seems to be standard for most of the English-speaking world, not just the US. The other language wikis are, of course, welcome to set their own standards, but I think we should stick to the format that is most familiar for the majority of English-speakers. -- undefined 01:26, 10 October 2014 (UTC)


 * I also agree an exception to using American English just to prevent confusion for the rare English dialect that uses a different number format is not necessary. We should remain using standard English commas. <span class=nowrap>— 03:11, 10 October 2014 (UTC)


 * Only traditional English-speakers. English is a common second language and has been adopted by much of the world as a language that brings us all together. Because so many people speak it in one form or another, English works tend to be much more comprehensive, starting a positive feedback loop, too. With Minecraft as an international phenomenon it works especially well. Mistakes are made, however. There are also differences that are more like a dialect than a mistake. In both cases numbers are among the most pernicious stumbling blocks because they look so familiar yet can be so different. Those who only understand the language at a basic level often get it wrong, where wrong means they misunderstand someone or cause others to misunderstand them.


 * International English will accommodate the need for effective communication by adopting forms that are more universally understood. Languages don't stop evolving at borders. Don't underestimate numbers; those who don't speak English very well are underrepresented among contributors. They are lurking here, reading articles. -- 04:56, 10 October 2014 (UTC)


 * But this is the English wiki. I don't see us adopting non-English quotation marks or non-English words simply because we have non-native English speakers. I also don't see why we should adopt special cases for the sake of people who have not fully learned English or speak a different dialect than the style guide openly states to use. We already publicly state that the wiki uses American English, so most people will assume we format the numbers as American English, and if they are confused as to American English number formatting, it is really easy to look up.
 * — 15:40, 10 October 2014 (UTC)


 * Wait, what? The message you replied to might as well be a reply to yours. I'll add that a preference for American English is usually about minor differences like color vs. colour that have little impact on understanding, not an embodiment of American culture. I'll mention the precedent set on dates once more. I don't think you really grasp the importance of the English wiki for foreigners, or the way English is understood by those who aren't perfectly proficient. But if I can't get any support, 160,000 is what it will be. -- 20:09, 13 October 2014 (UTC)


 * Either way, it still was a reply.
 * No, I don't understand what that is like to only partially know English, but such a knowledge is required for most other English websites they may use (such as wikipedia). If they know one of the other languages well, Minecraft Wiki is in other languages too. <span class=nowrap>– 21:13, 13 October 2014 (UTC)

Quote
Is there any rule about quote or tweet  12:16, 12 October 2014 (UTC)


 * Afif Brika1@undefined I'm unsure about quotes, but what about tweets, is that a direct external link (e.g. https://twitter.com/jeb_/status/119466949708222465) or Tweet template (e.g. jeb_) are favored over interwiki Twitter links like, but it is better to use the template, as it takes less space in the wiki text. is capable of replacing interwiki Twitter links with the template. -- ♦   16:40, 24 October 2014 (UTC)

Enchantments
Enchantments should be capitalized? ( / ) 01:22, 15 October 2014 (UTC)


 * The capitalization section mentions nothing about them, although since they are not proper nouns nor are they mobs, the only category left is in game items, which would state lowercase.
 * Although overall the capitalization section of the style guide may require rewriting, as its capitalization suggests often do not read well, or are simply avoided for some reason (Does nether wart or Nether wart look better?). In the case of enchantments, I am very undecided as to which would be better of Silk Touch or silk touch. The former seems to refer to a magical effect, while the latter seems refers to an attribute.
 * – 03:38, 15 October 2014 (UTC)
 * Enchantments are magical effects, and as such their names look better when in title case (e.g. Depth Strider, Blast Protection). Words "Overworld", "Nether" and "End" are dimension names and as such also capitalized. -- ♦  16:31, 24 October 2014 (UTC)

Rule about upcoming features
Originally mentioned.

I propose adding a rule to the general sections that features that will appear in the future are only allowed if they have appeared in development versions. We already have pages for features mentioned to be planned, and listing them on every article just causes the reader to assume they are coming soon, when they may not be coming at all.

Also, since it generally reads better, and we have upcoming, can we remove the rule about snapshot features being in a future section? A future section in a few cases reads better, but in most cases readers would have an easier time learning future changes if we mention "this feature is changing in <update>.

– 03:17, 23 October 2014 (UTC)


 * &mdash; &middot;  &middot; 03:59, 23 October 2014 (UTC)

Proper noun at the start of a word
"In-game items should be treated as common nouns and as such should not be capitalized. This includes fictional items, such as . The only exception to this are items that include a proper noun in the item's name, for instance: or . Proper nouns however, such or  should always be capitalized."

- Style guide

But, what if a proper noun is at start of a word, like ? Should it be capitalized?

-- |  17:19, 3 November 2014 (UTC)


 * I don't think "ender chest" or "nether wart" should be capitalized, so I wouldn't capitalize "netherrack" either. &mdash; &middot;  &middot; 18:12, 3 November 2014 (UTC)


 * Nether, End and Ender are proper nouns and, as per style guide, must be capitalized, unless (I think) are in word's start, so Ender chest, Nether wart and netherrack. Exceptions are fictional species names. -- |   18:16, 3 November 2014 (UTC)


 * I think is refering to changing that policy. I also agree that common nouns simply look bad with the proper noun parts capitalized. Fictional species I also disagree with capitalizing, since, in Minecraft, they are common nouns. (if Steve wrote a book, would he capitalize "Ghast"?) <span class=nowrap>–  18:38, 3 November 2014 (UTC)


 * Yes, I believe that all mob names should be lower case (ghast, creeper, guardian, elder guardian) regardles of fictionality or not, and all block names should also be lowercase (netherwart, ghast tear, end portal). Only the Nether, the End and the Overworld when used in those contexts should be uppercase. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   06:16, 4 November 2014 (UTC)


 * Okay, will keep that in mind when rewriting . -- |  08:01, 4 November 2014 (UTC)


 * I agree with Goandgoo (charged Creeper looks weird) ( / )  13:44, 4 November 2014 (UTC)

What about game modes/difficulties, such as Survival? I have seen some people write it as survival instead, so would there be a consensus to it being treated as a common noun instead? <span class=nowrap>– 18:06, 10 November 2014 (UTC)


 * They are game terms, it looks like. So they can be written in lowercase. -- |  18:20, 10 November 2014 (UTC)


 * What about status effects? They should be capitalized? ( / )  20:59, 10 November 2014 (UTC)


 * I would vote on no, with the reason that it reads better: "The creeper is poisoned" or "The creeper is Poisoned", "A spider with regeneration" or "A spider with Regeneration". <span class=nowrap>– 21:10, 10 November 2014 (UTC)


 * So, I think, as per these consensuses, the words in italics are correctly capitalized:
 * Nether fortresses have  growing inside.
 * Most of 's scenery is made of .
 * Charged s have twice the power of normal creepers.
 * Upon death in  mode, the world is deleted.
 * When spawned in peaceful, mobs instantly despawn.
 * Witches can throw splash potions of poison or harming for offense.
 * -- |  07:47, 11 November 2014 (UTC)


 * The first one two of us agreed looked better making the proper noun lowercase for the sake of the common noun, as in "Plant the Nether wart" compared to "Plant the nether wart". If you disagree with that though, this is the perfect place to discuss changing it back. <span class=nowrap>– 14:52, 11 November 2014 (UTC)
 * To me, "Nether" and "Ender" written in all-lowercase look weird, as these adjectives (not nouns) originate from respective proper nouns which should be capitalized. -- |  15:24, 11 November 2014 (UTC)


 * I personally think the entire phrase is a common noun, rather than a with a common noun. Would it really make sense to call those plants simply "warts"? Also, if they are always referred to using the adjective (in there in game name), what are we distinguishing it from that makes it require the adjective? <span class=nowrap>–  15:58, 11 November 2014 (UTC)
 * ... Thinking that the entire phrase is a common noun appears to contradict vocabulary. Phrases can be composed of both types of nouns (proper and common), as well as other types of words. The aforementioned Nether and Ender, in our cases, describe the item's origin (in case of Nether wart) or a related dimension (in case of Ender chest). Just "warts" may not make sense (so we use adjectives), due to the probability of an update that adds another type of warts . Meanwhile Ender in Ender chest reflects the, the key component, which in turn is made of an , which originates from , which is also called Ender. -- |  16:28, 11 November 2014 (UTC)

Looking up standard capitalization, I find that generally the proper noun is capitalized, although in those cases there is a common noun without the proper noun to fall back on (French toast is a variant of toast), while in this case, the common noun always contains the proper noun (eye of ender is not a variant of eye, nether wart is not a variant of wart). So, in the case of Minecraft, an eye of ender is a common noun, while Steve's eye of ender would add the proper noun part. <span class=nowrap>– 17:53, 11 November 2014 (UTC)


 * Okay, understood. But how with s? Shouldn't Ender/Nether, the departure/arrival dimensions, be capitalized either?
 * But still, an "ex-proper noun" written in lowercase still looks weird to me. If I do capitalize them, this is because of that.
 * -- |  18:26, 11 November 2014 (UTC)


 * I would agree to portals containing a capitalized proper noun. Nether portals are referred to simply as "portal" in game so the nether part is a disambig title (out of game, it is officially Nether portal). Although End portals are actually referenced as End portal instead, in this case there is a variant without the proper adjective. I can think of two other cases of such a variant: nether bricks to bricks, and end stone to stone. You could also say ender chest to chest, although "ender" could really be treated as a common adjective, since the place is called the End.
 * I guess it comes down to us both thinking the other capitalization method looks weird... <span class=nowrap>– 04:41, 12 November 2014 (UTC)


 * Nether portals being referred to just "portal" is Notch's problem, as he didn't think that, a new portal type will be added.
 * What about capitalization method as a whole, you're right. The vocabulary factor is very strong.
 * Useful links:, , ,.
 * -- |  07:49, 12 November 2014 (UTC)

Biomes
I think that since names are not proper nouns, but rather describe types of areas, they should normally not be capitalized.

Example:
 * Mushrooms naturally generate in poorly lit areas, as well as biomes and .

instead of
 * Mushrooms naturally generate in poorly lit areas, as well as biomes and .

(The sentence is taken from a recently rewritten article.)

-- |  07:34, 13 November 2014 (UTC)


 * . undefined 11:56, 13 November 2014 (UTC)


 * Okay. Let's wait the Clean Lord of the Style . -- &#124;   12:11, 13 November 2014 (UTC)


 * I agree because it may look weird, and reads better:


 * Coarse dirt generates naturally in Savanna biomes.
 * Podzol can be found in Mega Taiga biomes and its variants
 * Jungle temples generate naturally in Jungles


 * undefined 13:20, 13 November 2014 (UTC)


 * You could say your argument in the first place. (like ", it may look weird when capitalized.") -- &#124;  13:39, 13 November 2014 (UTC)


 * I also, especially since in real life biomes are common nouns. Really I am just as much in charge here as anyone else on this talk page, I am just more active on this talk page than some others, and obsessed with consistency. <span class=nowrap>– 17:01, 13 November 2014 (UTC)


 * So, may we change the style guide now? -- &#124;  17:17, 13 November 2014 (UTC)


 * Usually it is best to wait 5 to 7 days for smaller changes, as some people who have not been online yet may have suggestions or objections. But after that time feel free to change it. <span class=nowrap>– 17:20, 13 November 2014 (UTC)


 * The fifth day starts. I'll seek out the edits within this gap in order to see the change. -- &#124;  07:44, 18 November 2014 (UTC) with edits at 07:48, 18 November 2014 (UTC)

Potion and Gamemode/Difficulty Capitalization
I personally think that potion effects should still be capitalized, since. It might also clear up confusion (especially for newbies). (Gamemode/difficulties could also be capitalized, since it allows for shorthand writing and makes key info easier to find.) Here are some examples to explain what I mean:

''As zombies are undead mobs, they are harmed by healing and healed by harming. They are also immune to regeneration and poison.'' ''As zombies are undead mobs, they are harmed by Healing and healed by Harming. They are also immune to Regeneration and Poison.''

While the zombie is being cured, it will have the strength I effect in normal difficulty (or strength II on hard difficulty)... While the zombie is being cured, it will have Strength I on normal difficulty (or Strength II on hard)... While the zombie is being cured, it will have Strength I on Normal difficulty (or Strength II on Hard)...

Zombies deal damage in easy difficulty,  in normal, and  in hard. Zombies deal damage in Easy,  in Normal, and  in Hard. After second thoughts difficulties seem alright in lowercase, as long as the word "difficulty" itself isn't after each one. -  04:21, 20 November 2014 (UTC)


 * Potion effect makes sense assuming that is the way you intend to use them. Some newbies though may just think it is different capitalization though. I personally prefer capitalized, but that is mainly because of poison I think. One problem is their use as adjectives, such as an Invisible spider rather than an invisible spider.
 * The only other problem with capitalizing effects is it raise another question: "potion of strength" or "potion of Strength". Based on the fallback for common nouns I mentioned above, the latter would make sense.
 * What about something along the lines of the effects of potions are capitalized when used as nouns, but lowercase as adjectives? For example, "An invisible spider has the effect of Invisibility"
 * As for difficulties, I think they read somewhat better as lowercase (especially in your example if you replace "in" with "on").
 * – · 04:49, 20 November 2014 (UTC)


 * That seems good :). Also all topics that haven't had posts since 1/1/14 should probably be archived :) -  02:29, 21 November 2014 (UTC)


 * Should "creative inventory" be capitalized? – · 18:36, 11 December 2014 (UTC)


 * , so the word "creative" being in this word combination doesn't affect its capitalization. -- &#124;  18:42, 11 December 2014 (UTC)

Serial comma
Should we use the or not is the basic question. The main reason it should be mentioned is because I have seen a couple edits simply adjusting the comma to a serial comma.

I personally prefer without, as I find it reads better, but I have little opinion on the matter other than that, as I would be fine with using either.

<span class=nowrap>– · 04:28, 2 December 2014 (UTC)


 * I prefer the serial comma because it's consistent (treating all the items the same, as well as treating words the same as you would treat phrases) and because it reflects how most people would speak a list. Not sure a policy is needed (let 'em edit, it gives newbies something small to test out editing). Also see above. &mdash; &middot;   &middot; 05:31, 2 December 2014 (UTC)

NBT and JSON
We need a section about the style of NBT and JSON trees. Should "optional" come before or after the tag description? Should a JSON string be called a compound (its logical type, since it can contain subtags) or a string (its type according to the file format)? Should the JSON tags be formatted differently to distinguish them from subtags of an NBT compound tag? 19:01, 25 December 2014 (UTC)


 * Optionality may be noted at the beginning, while the default value (if any) may be stated at the end, like so:
 * : Optional. Info goes here. If omitted, it defaults to DefaultValue.
 * -- 08:54, 26 December 2014 (UTC)