Minecraft Wiki talk:Style guide

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

Also, there was a discussion already at Minecraft Wiki talk:Community portal/Archive 9. Please continue the discussion here as well. - Asterick6 (talk) 22:22, 17 June 2012 (UTC)

Update: User:Metalhannes/Grammar 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. - Asterick6 (talk) 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? -- Orthotope 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 The Void or The Nether) 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. Hower64 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.--82.69.54.207 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.) -- Orthotope 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. - Asterick6 (talk) 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"). - Asterick6 (talk) 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. Creepergoboom64 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? wiler5002 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 Spider, you can link it inline as spider and get the same result. -- Wynthyst [[Image:User Wynthyst sig icon.png ]] talk  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. Data values for example isn't a game item, so only the first word is capitalised. Chicken Egg is an item in-game that is spelt with capitals, so it should be like that on the wiki as well. — Number  maniac  (C)  08:05, 22 March 2013 (UTC)

Mobs
I think fictional mobs should be capitalized and real mobs should be lowercase, so Mooshroom is capitalized and cow is not. Or all mobs can be capitalized. - Asterick6 (talk) 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. Hower64 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. - Asterick6 (talk) 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. - Asterick6 (talk) 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? Asterick6 (talk) 01:47, 21 June 2012 (UTC)

Image captions
Image captions should not have periods at the end, unless the phrase is a full sentence. - Asterick6 (talk) 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. - Asterick6 (talk) 05:15, 19 June 2012 (UTC)


 * I agree, that seems right to me!Creepergoboom64 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.  Pokechu22 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. - Asterick6 (talk) 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. - Asterick6 (talk) 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 Programs and editors pages) also sorts them chronologically. -- Orthotope 09:13, 6 June 2012 (UTC)


 * We discussed date formats a while back. 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. –ultradude25 (T&#124;C) at 10:35, 6 June 2012 (UTC)

When writing a numbers-only date format, we should use YYYY-MM-DD, because it is the ISO standard. 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. —kpreid 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. - Asterick6 (talk) 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. -- Orthotope 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? Hower64 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. —kpreid 18:11, 6 June 2012 (UTC)
 * This ordering is fine, but the video section should go after the history section and before gallery/trivia. - Asterick6 (talk) 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. Hower64 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. - Asterick6 (talk) 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. - Asterick6 (talk) 03:04, 10 June 2012 (UTC)

Issues about history-cruft were brought up before at Minecraft Wiki talk:Community portal 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). - Asterick6 (talk) 02:29, 10 June 2012 (UTC)
 * So many pages with that issue... Hower64 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. -- Orthotope 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. Hower64 10:02, 6 June 2012 (UTC)
 * We could implement that to template:history. - Asterick6 (talk) 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. —kpreid 15:20, 6 June 2012 (UTC)


 * I thought all of them are in that order already. - Asterick6 (talk) 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. - Asterick6 (talk) 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. Hower64 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. -- Orthotope 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 Spawn from Mobs, 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 Gunpowder from Creeper, because it is already linked and the uses of gunpowder are not part of understanding creepers. —kpreid 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 Bone Meal 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. —Fenhl 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. —Fenhl 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. —Fenhl 01:05, 18 April 2013 (UTC)


 * Here is a mockup of how the Blaze Rod article might look like with this layout. —Fenhl 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 Data values 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 Data section to the block/item articles, adding a new Data values section directly above Achievements. —Fenhl 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 Data values. I find it extremely useful to have everything in one place.
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &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. —Fenhl 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 Data values. As long as it's still available there. : )
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 04:44, 28 May 2013 (UTC)


 * Sounds good. —Fenhl 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. -- Orthotope talk 12:33, 28 May 2013 (UTC)


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


 * I have now added this to the style guide, and updated the Coal and Wood articles accordingly. —Fenhl 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 Data values also?
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &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 Data values page which as I understand it is often used as a quick reference. —Fenhl 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 Data values.
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &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? —Fenhl 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. — Hower64 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.--82.69.54.207 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. —Fenhl 04:40, 10 July 2013 (UTC)

Mob page layout
Do mob pages have any set format to follow? I, ah, attempted to rearrange and fill in the Horse 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. - Tabby 15:20, 16 June 2013 (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. --Simons Mith 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 here", use something like "For a tutorial on mob farming go to Tutorials/Mob Farm".
 * - Asterick6 (talk) 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. --Moxxy 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? --Simons Mith 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? --Mental Mouse 11:35, 19 April 2013 (UTC)


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


 * Wikipedia uses the Wikipedia: namespace for its style guide. 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;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 14:44, 19 April 2013 (UTC)
 * I'm fine with either namespace, though now Minecraft_Wiki seems more appropriate. --Mental Mouse 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 $wgSitename. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 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. --Mental Mouse 13:52, 20 April 2013 (UTC)

MediaWiki:Editnotice-0
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. — Hower64 02:13, 20 April 2013 (UTC)


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


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

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

Any answers??? Is it simply allowed in all articles, some articles, or no articles? –Goandgoo ᐸ Talk Contribs Edit count 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 mushroom page. It doesn't pertain to the ingame appearance and isn't really good trivia. On the other hand, the trivia on the hopper 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 player 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. --Mental Mouse 11:32, 18 May 2013 (UTC)

Singular form
Titles should be singular form, but what exceptions are there? Blocks, Items, Mobs, Redstone circuits, Mods, Tutorials, Version history/Development versions, various "upcoming features" pages and probably others are still plural. Is there any reason? –ultradude25 ᐸ Talk Contribs 06:53, 25 April 2013 (UTC)


 * The main reason I can see is that these articles are mainly in list form, e.g. the Mobs 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 Tutorials, Version history/Development versions, and maybe Redstone circuits) 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? —Fenhl 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…" exception, 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;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &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;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &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. --Mental Mouse 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;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &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. hotdogPi-t--c--Try my quiz! Do not click! 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. —Fenhl 06:04, 31 May 2013 (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? —F‌enhl 13:47, 21 October 2013 (UTC)