Minecraft Wiki talk:Community portal/Archive 16

Talk page guidelines
I've noticed many new users post messages on talk pages that get reverted by a more seasoned user due to violating general talk page usage. The problem is the new user has no way of knowing they were not suppose to do that, as it is never stated outside of edit summaries.

Currently the only two rules stated are only discuss the page and its content, and sign your posts. The best way to state the other guidelines are a page which will not only state the aforementioned two rules, but will also mentioned the following:
 * 1) Don't Generally avoid replying to a comment more than a year old, as the user is very unlikely to see it and your response most like was not relevant back then.
 * 2) Keep replies to the same topic as the original topic of that section.
 * 3) Don't edit other user's comments, except to  or fix minor formatting errors (basically cover someone forgetting to use tl when discussing a template, forgetting to indent, and forgetting to escape a category/file link).
 * 4) Don't edit archives (it may seem obvious, but some people still edit them)
 * 5) Formatting guidelines, including proper usage of indentation for standard topics and consensus topics, and the proper way to link to a template, file, category, ect.
 * 6)  (it relates to talk pages, it would be a good idea to have mention of it so it is all in the same spot)
 * , possibly with some extended guidelines on signatures (such as excessively larges files and text, this rule could theoretically be migrated to the page)
 * 1) That one thing I'm forgetting, and someone will remind me of in a reply (just so I covered everything)

– · 03:58, 15 January 2015 (UTC)
 * Don't use talk pages for anything other than discussion or (in delimited places in user talk pages) testing talk page features.
 * – — ru.wiki moderator 06:57, 15 January 2015 (UTC)


 * . Feel free to correct things or leave suggestions on the pages content.
 * NickTheRed37@undefined Thanks, I knew I was forgetting something.
 * – · 23:31, 15 January 2015 (UTC)


 * So... – · 22:23, 24 January 2015 (UTC)


 * I don't like the first rule (can we number these for discussion purposes?). One year seems arbitrary, and I'd be happy to answer someone who responded to a years-old post. I'd just make that a recommendation or something to consider -- not something you would, say, undo for "breaking the rule".
 * For formatting, I wouldn't specify a specific number of indents before using outdent -- just use it when it feels right. Also, because of the way the wiki formats lists, I like to include a paragraph space between each user's comments -- that also makes it easier to follow the thread in the edit window which doesn't have indenting.
 * NickTheRed37's rule is fine for article talk pages, but it shouldn't apply to user talk pages -- there the user has total control of what is allowed on their talk pages, as long as it doesn't break the general rules.
 * &mdash; &middot;  &middot; 00:02, 25 January 2015 (UTC)


 * It would make sense to change that to recommended, although in most case of replying to an old comment it is a anon telling someone from 2011 to use a hopper to collect items (well, along those lines). I would agree to it being strongly advised rather than revert worthy though.
 * The number was mainly just copied from the template, I changed it to simply use eight as a standard. And I like the idea of adding a line break between comments by separate users (I already do that normally)
 * That makes sense, considering the wiki rules. The page now states the only user talk page requirements from that list that is not from is not editing other people's comments.
 * – · 00:36, 25 January 2015 (UTC)


 * I've made one last tweak, as it is mostly generally agreed upon. The signature guidelines now states that the username should either link to your user page (eg, ), or display your username (eg, KnightMiner), for the sake of identification. It also forbids impersonating another user by displaying their name and linking to their page (if my signature claimed I as one of the admins for example).
 * I am a little unsure of how far to extend the last part, as in what would qualify impersonation. It might happen that someone wishes to link another user's page for some reason, and display names are allowed, but both should not be combined. – · 16:12, 17 February 2015 (UTC)


 * What you have sounds reasonable to me. Basically, signatures need to identify the user who made a comment. The MediaWiki default both displays the username and links to their userspace, which is great. Some users may want to display a different name (such as munin, above); as long as there's still a link to their userspace, this is fine when the display name is a variation on their actual username, but something like starts getting confusing. Not including a link is questionable at best – Wikipedia actively  – and I don't see any reason why one person's signature should link to another person's userspace. -- undefined 23:46, 17 February 2015 (UTC)


 * I don't have anything against it being more strict. Most users already follow those guidelines, and those who don't it is usually by accident.
 * More specifically, I agree signatures should contain a link to a users page or talk page, to help with identification. In this case, it might make sense to go even farther to require a link to their main/talk/contribution page, otherwise the guideline should at least advise it. I would also agree to limit display names to being directly similar to the original name.
 * With linking another user's page, the only reason I can think of are to clearly show alternate accounts, so I would agree to advise against linking another user's page, if not forbidding it.
 * It does raise the question of other links though, wikipedia directly forbids external links, category links, and files in signatures, and advises against links not directly related to general information. I think we should take a similar stance taking a similar stance towards external, category, and internal links, though I am unsure about files (the reasons against using them make sense, though files are used to show curse or mojang staff in a few cases). – ·  05:11, 18 February 2015 (UTC)


 * Rather than forbid replying to old topics, we should instead try to archive them better.
 * I think it should be a rule that signatures must contain a link to one of your user pages (not sure if it is necessary to limit that to the more main ones, like main/main talk/contribs/logs), and the name should be similar to your username. It's really inconvenient when someone doesn't have a link to one of their user pages. I think wikipedia's rules are sensible, however as we don't have the talk page density that they have, I think it is fine to allow files, but limit them to one, maybe two at the most as well as sensible size restrictions. Speaking of which, an additional guideline should be that your signature shouldn't increase the line height, doing so causes the rest of the text surrounding the line with the signature to have excess spacing that makes it less readable. It's not like there isn't plenty of room to use anyway. Even though my signature spans two lines, the text is smaller and is pulled closer together, so it still stays within the standard line height. – ᐸ  05:53, 18 February 2015 (UTC)

We do need a better archiving system, that could be a later project though (would be nice to have one of those archiving bots like Wikipedia has, but a wiki project would make sense for now) We should at least archive entries that are over a year old. (On the proposal page, I did change it to advise against replying to old comments, rather than directly forbid.)

With the line height guideline, I do agree the line height change can be annoying and affect reading negatively. We should definitely advise against it, if not disallow it. For the most part, tags such as small, sup, and sub have little to no visual effect on line height (unless you have too big of font size), so the main things that would affect are files (20 pixel height limit sounds good), and 's signature. – · 15:50, 18 February 2015 (UTC)


 * So, any more/final comments on the guidelines? Otherwise, would anyone have anything against implementing them? Assuming there is enough of a consensus then, I can implement the guidelines in a week or so.
 * It may also be relevant to use the to alert users of the change for at least a week after, as from what I've seen, many of them don't read the community portal discussions. (it was most notable with the upcoming features rewrite) – ·  15:58, 21 February 2015 (UTC)
 * My rule about usage of user talk pages can be rephrased like so, changing it from a policy to a guideline: “Using user talk pages for things other than discussion or testing talk page features is discouraged.” —  Agent  ( &middot; ) f.k.a. Naista2002 16:10, 21 February 2015 (UTC)
 * My rule about usage of user talk pages can be rephrased like so, changing it from a policy to a guideline: “Using user talk pages for things other than discussion or testing talk page features is discouraged.” —  Agent  ( &middot; ) f.k.a. Naista2002 16:10, 21 February 2015 (UTC)


 * Currently rather than advising against non-talk usage, it advises towards good talk page usage (the rule about talk page usage is advised on user talk pages). I flipped it to discourage non-talk usage. In the case of talk page sandboxes, they would fit the category of advised against usage, but the user is free to do it still. – · 16:31, 21 February 2015 (UTC)


 * I have a couple of additional guidelines to consider: pinging and signature interwiki links.
 * Pinging should generally be used for pulling someone into a subject that warrants their attention, which they may not be watching. This means that it doesn't apply to the user's own talk page, as they should be getting notifications there already. Replying (which is really just pinging with an @ in front of it), should be used when your reply is to multiple people. It isn't necessary when your reply is to the previous post (the one directly above and one indentation level less), unless you feel they may not be watching the subject (a passing comment rather than a full reply, perhaps), and so you also wish to alert them to your reply.
 * Interwiki links probably shouldn't be used in signatures, at least not as the only link. Suddenly being taken to another wiki (even if just another language version) can be confusing, and a nuisance if you actually wanted to access a user page or user function on the original wiki. On a related (but not to this topic) note, we should probably also advise against redirecting at least the main user/user talk pages to another wiki/language, and instead use a soft redirect (and actually create that template too). – ᐸ  00:16, 22 February 2015 (UTC)


 * The pinging guideline makes sense, it helps to know which user someone is replying to, and it would be a good idea to state when pings are needed and when they are redundant. With the layout of the proposed guideline it would likely fit best in formatting, if not its own section.
 * As for interwikis, assuming we do not declare them as external links, that could be covered by requiring the link to your user page to be your English wiki user page, as I don't see any other useful English link to require them to have. Someone from another wiki could then link internally to their main page, and interwiki their talk page, or vice versa.
 * Yeah, that template would be useful, though I think only user pages would use it right now.
 * – · 00:53, 22 February 2015 (UTC)


 * So, any more points/guidelines to discuss before implementing? Otherwise, I will implement it shortly. <span class=nowrap>– · 17:03, 7 March 2015 (UTC)


 * If there is, it can't be anything important or someone would've thought of it by now. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 02:40, 13 March 2015 (UTC)


 * Since this topic has contained all agreement and the current revision of the page has had no major changes in over two weeks, I've moved the page to the "Minecraft Wiki" namespace to be treated as official guidelines. Now would be a good time for that site notice related to this topic and.
 * Looking over the archives of the community portal and a few other pages, I also find it interesting to note that a few of the policies were already "in place" from previous discussions, such as the guideline about image size in signatures, and there may be a few more relevant to add from (specifically editing the main topic without noting it, and removing old sections other than for archiving. <span class=nowrap>– ·  04:42, 14 March 2015 (UTC)

Minecraft texture for blue boxes
Following up the previous topic, where I mentioned a lighter stone color for the blue boxes. I applied a texture like that to, and I am wondering what opinions are on the design (as no one replied to any proposal in the previous topic other than the dirt). <span class=nowrap>– · 05:43, 24 January 2015 (UTC)


 * Looks okay, though I'm concerned there's not enough contrast between the black text and gray stone texture. -- undefined 06:55, 24 January 2015 (UTC)


 * I brightened it somewhat to increase the contrast. I think the contrast is alot better, the only place I'm at all concerned is completely standard text (which is only used on ) <span class=nowrap>– · 23:51, 24 January 2015 (UTC)


 * Much better, though I'd like to get Majr's opinion before rolling it out to the main page. -- undefined 00:52, 25 January 2015 (UTC)


 * I still don't like the new boxes as the black text and the grey backbround blend in far too much. I think using stone is probably not great as the box background. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:1em;vertical-align:-1em>   02:22, 25 January 2015 (UTC)


 * One option would be recoloring the stone to make it blend slightly less; either lightening it more or giving it a tint, provided it does not take away from the Minecraft feel.
 * If using a different block, we would need to make sure it is iconic enough to denote usage on most pages, while being simple enough that words can be read on it. That basically leaves block such as stone, cobblestone, dirt, grass, wooden planks, obsidian, maybe clay or sand, wool, possibly stone bricks, water, and lava. From that list, stone does fit the criteria the best, as the rest are either not as iconic or too dark/noisy.
 * Otherwise we could keep the current, but that really both does not say "Minecraft" like the rest of the skin, and has been in place for awhile (over three years it seems). <span class=nowrap>– · 14:55, 26 January 2015 (UTC)


 * White text on dirt might be reasonably readable. -- undefined 15:31, 26 January 2015 (UTC)
 * I personally don't like that bright stone texture, I still prefer the dirt one although I have to say that the texture really was way too dark, so I made an experiment on my (compare: ). I also blurred the background file so you can read the white text better. |  18:38, 1 March 2015 (UTC)


 * I personally still think it is a little dark, as it requires a font color of white. I am not fully sure what can be done about that though. <span class=nowrap>– · 16:59, 2 March 2015 (UTC)
 * Maybe use texture?, , , ,  <span class=nowrap>—   18:10, 2 March 2015 (UTC)
 * Maybe use texture?, , , ,  <span class=nowrap>—   18:10, 2 March 2015 (UTC)


 * I had previously ruled it out, due to me thinking it would not look good, but it actually is not that bad, especially the third one (birch, right?). It also solves the issue I was having with the stone being to monochromatic. One minor concern is it does not blend as well with the light blue background, though the yellow message boxes have been doing the same thing for years.
 * It also sort of makes sense if you conciser the background as natural Minecraft terrain, and the blue headers as player made buildings, though I might be stretching it a bit. <span class=nowrap>– · 19:05, 2 March 2015 (UTC)
 * In my opinion, the planks texture causes that the text ("About Minecraft", "Play it!", etc.) is more difficult to read, but I think that the birch planks texture would be a good choice if we take a planks texture. Anyway, the dirt texture can always be lightened - also it should be mentioned that the dirt texture is also used in Minecraft itself in the menu. As I earlier said, the texture of buttons would also be an option, but is technically difficult (and would also cause some problems on the German wiki's main page) . | 19:43, 2 March 2015 (UTC) Edited 19:45, 2 March 2015 (UTC)
 * The Korean wiki already uses changed headers: . I just wanted to add that, form your own opinion. | 17:18, 10 April 2015 (UTC) (I have absoulutely no idea why I duplicated this section, sorry for the inconvenience! | 18:27, 10 April 2015 (UTC))

?
Everyone probably knows this message box by now: Surprisingly, why is there no editcopy version of ? BDJP007301 01:57, 29 January 2015 (UTC)


 * Is there a need for one? Since he's no longer at Mojang, and didn't actively work on Minecraft for several years before it was sold to Microsoft, I don't imagine there will be many changes that need to be made on that page. -- undefined 04:06, 29 January 2015 (UTC)


 * Well, seeing as this template says that every user can contribute to every page, not allowing an editcopy version of that page would just be egregarious lying. BDJP007301 00:23, 12 February 2015 (UTC)


 * Not if we allow changes to be proposed on the talk page, which allows any user to contribute. I've done that before on that page. <span class=nowrap>– · 00:33, 12 February 2015 (UTC)


 * An editcopy has the advantage of showing the exact suggestion, whereas a talk page can only be used to propose the basic idea and has the possibility of miscommunication. I know this from experience not the planned versions talk page before I had an account. ~From Contrapple 03:04, 28 March 2015 (UTC)


 * Maybe we should try using ? It's like FlaggedRevs, but not ridiculously overcomplicated and (hopefully) buggy. It could be used instead of page protection, which would then be used for handling spam. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 02:24, 3 March 2015 (UTC)


 * That could work, and I .  ( 14:29, 26 April 2015 (UTC)


 * Fair enough, but it may appear to be redundant. . — <span class=nowrap> (&#124;) 15:14, 26 April 2015 (UTC)


 * I like the idea behind it, but I am not so sure about the specific implementation, as it requires either a magic word for approvals (which the page claims has a few bugs), or setting entire namespaces to require approval, rather than adding a specific protection level per page. This would mean we would get increased amounts of revisions/posts on talk pages wondering why their edit is not shown (as we already know that most users don't read the edit notices) and it would require either additional administrators to maintain it, or a new usergroup for reviewing pages. <span class=nowrap>– · 21:10, 26 April 2015 (UTC)


 * Incorrect. The namespace setting and magic word are to make pages approvable, as in allowing approving to be enabled. Requiring edits to be approved on an approvable page is as simple as approving an edit, and no longer requiring edits to be approved is as simple as unapproving the current approved edit. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 14:28, 27 April 2015 (UTC)


 * I assume you mean by setting unapproved pages to not be blank, but not display an unapproved page warning? I hadn't though of that, but in that case I don't have anything against the extension. <span class=nowrap>– · 15:04, 27 April 2015 (UTC)


 * By default, unapproved pages act like the extension isn't installed. It's only approved pages which show a message, which we could hide. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 02:59, 28 April 2015 (UTC)


 * On a semirelated note, I disagree with the wording in that notice (I haven't brought it up before because I've never paid it any attention until now): we definitely do not allow every user to edit every page; even ignoring the obvious issue of interface pages and high-use templates and files, banned users are not allowed to edit (that's the whole point to their being banned). I would suggest cutting "every" from "every user" at the least, and maybe change "contribute" to "propose changes", since that's effectively what the editcopy pages are intended for. <span class="nowrap">「」· 03:05, 27 April 2015 (UTC)

Can be insta-mined
I think we should add this into pages in some sort of way (the lowest tool that can instamine a siad block), and add enchantments if necessary. Like put on a page you need efficienccy V and haste II on a daimond pickaxe to insta stone, while a efficiency stone axe will melt mushrooms. -  19:14, 30 January 2015 (UTC)
 * Even if I see it as useful, I don’t feel like it should be added. <b class=nowrap>I’m , f.k.a. Naista2002 </b> 19:21, 30 January 2015 (UTC)


 * The problem with insta-mining is it is rather relative, and actually is not instant, just very fast. The only blocks that can really be insta mined would be slime blocks and tnt
 * This might make a relevant tutorial though, possibly under mining tips. <span class=nowrap>– · 20:13, 30 January 2015 (UTC)


 * It's slightly interesting for harder blocks, but I don't think it's generally useful. Part of the problem is that there are too many ways to do it. For example, saying that "huge mushrooms can be insta-mined by a gold, diamond, or iron axe, or an Efficiency I stone axe, or an unenchanted stone axe with Haste I, or an Efficiency III wooden axe, or an unenchanted wooden axe with Haste III, or an Efficiency II wooden axe with Haste I, or an Efficiency I wooden axe with Haste II" doesn't really help anyone. If there was exactly one way to insta-mine a block in Survival mode, that might be more noteworthy. -- undefined 21:04, 30 January 2015 (UTC)

Reform the style guide and wiki rules
I've noticed the style guide currently lacks the ability to expand, as it only lists sections for general feature articles. On a similar note, guidelines on article create are split in multiple places, and are even hard to find within their places, such as the rules has notability as random numbers.

A possible solution would be this proposed rewrite from by sandbox, containing the following pages:
 * <span style="color:gray">Mostly contains the current style guide, minus the layout sections. <small style="color:green">This change was implemented on 15:54, 20 February 2015 (UTC)
 * The section "Section headings" links to the general sections. <small style="color:green">The section "Article layout" was kept to link to the subpages.
 * <span style="color:gray">The section "Notability" comes mostly from the wiki rules, except General 4 and 5, which are from the style guide's future section/ <small style="color:green">This change was implemented on 17:48, 23 February 2015 (UTC)
 * <span style="color:gray">Notability's wiki rules are duplicated from the remaining rules. They are mainly there so all the information is in one place.
 * <span style="color:gray">One of the current wiki rules was moved to the section "Images" (previously "Image captions") <small style="color:green">This change was implemented on 17:48, 23 February 2015 (UTC)
 * "Article titles" general title format is entirely based on general practice.
 * <small style="color:green">Page was moved to on 15:54, 20 February 2015 (UTC)
 * <span style="color:gray">Contains the general sections for the most part copied from the current style guide.
 * A style guide proposed on the style guide talk page previously. Everyone in the topic liked it, but there were only two of us there (including me).
 * <small style="color:green">Implemented at 00:49, 2 March 2015 (UTC)
 * <span style="color:gray">Will contain stuff that is block worthy, rather than just any random policy we want to list (except maybe what would be rule #7).
 * <span style="color:gray">Removed all the rules that are now within the style guide.
 * <span style="color:gray">The note about the userspace was moved as well, as now all the rules are required in the user space (except where noted)
 * <span style="color:gray">Also removed the talk page guidelines, since if we are going to be changing all the numbers, might as well only do it once. (see )
 * <span style="color:gray">The note about the userspace was moved as well, as now all the rules are required in the user space (except where noted)
 * <span style="color:gray">Also removed the talk page guidelines, since if we are going to be changing all the numbers, might as well only do it once. (see )

The major advantages of this proposal are that the style guide will be more organized, as well as the wiki rules being all major violations, rather than half being minor. The style guide is also easier to expand for other article types, such as mods, template documentation, and tutorials.

The major disadvantage other than some rearrangement of information (making it confusing for a bit remembering where things are now) is that most of the wiki rule's numbers change, causing previous edit summaries to be broken. Things such as some deletion summaries also would need to be updated to support the notability guidelines rather than rules.

– · 00:27, 10 February 2015 (UTC)


 * Another thing this would have the ability to solve is the controversy over various parts of version pages, specifically bug tracker titles. With the current style guide, there is no place to put such a guideline relating to anything that is not general article style or specific to feature articles. <span class=nowrap>– · 01:08, 17 February 2015 (UTC)


 * Sorry for butting in to your huge paragraph of changes, but I sort of don't like the tracker title idea. Knight, do you remember the time that I told you I'm not used to sudden change? Well, I really don't feel like wanting to spit it out here (a bit shy on discussing this condition), but I suffer from a.k.a  a.k.a "Autism Level 1" (kudos to  for that name).
 * When I feel like there's a sudden change in my real-life schedule, I feel like I need to release all my anger. That same thing went for when edited a tracker title on .  decided today to rewrite almost all of the tracker titles on that page after wondering if I read Majr's notice regarding tracker titles. I told myself to stay calm, but my mind kept on telling me to revert every single little change. I eventually decided to give in.
 * Story aside, I'll now ageee to this change, but on the condition that all nouns (Piston, Baby, Cow, etc.) are capitalized. BDJP007301 02:29, 17 February 2015 (UTC)


 * On the subject of bug report titles, I don't think it's necessary to rewrite them for the most part. Occasionally there's one that's so badly written it's hard to understand, which should be improved, but I don't see a need to go through all 200+ pages that use bug just to change capitalization and minor grammar issues. I can understand not liking sudden changes to the way we do things; that's why this is a proposal for discussion, rather than one user deciding to change things without consulting anyone else. -- undefined 03:10, 17 February 2015 (UTC)


 * Other than a preference towards title readability (correcting typos and impossible to understand titles, code tags/cmd where relevant, ect), I don't have anything against changing the style or the current style, but I am against using inconsistent styles or switching back and forth between the two.
 * The main thing I was proposing here was a place for the guideline, and turning current standard practice into guidelines to avoid unneeded repeated discussions, which I brought up here as I felt it was directly related. That, and I've had quite a few proposals go unanswered, without anyone agreeing or disagreeing.
 * Sorry if I offended you with my actions. I often tend to be eager (if not overly eager) to use a new solution or method. <span class=nowrap>– · 03:31, 17 February 2015 (UTC)


 * It's fine for you to disagree with a change and discuss it, however using your condition as a sole reason for not liking a change is not an acceptable argument. There's no reason that tracker titles should be left at a poor standard compared to the rest of the wiki, especially since the lists are not automatically populated, and thus have to use the original titles.
 * It's not necessary to go through every page and fix every title to have perfect grammar and formatting, but they should at least be readable and have useful formatting like links.
 * As for the capitalisation: I don't see why tracker titles should treat those words as proper nouns when the rest of the wiki doesn't. If you don't agree with that capitalisation, that is something to take up with the general style guide. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 05:02, 18 February 2015 (UTC)


 * I think it makes a lot of sense and will be less confusing to have individual guidelines for different types of pages split out from the general guide. I would recommend starting out by just moving the general article structure (what should we actually call these types of pages?) to its own style guide page and any other rules specific to other types of pages to their own pages. Afterwards any changes to the style guides can be proposed as normal. This gets things organised now, rather than having that held up waiting for people to agree on changes to the actual guidelines themselves.
 * The rule changes as well I agree with, but I'm not sure what the best way to handle the changes should be. Here's the options I can think of:
 * Rules that no longer apply get moved to another section on the page, but keep their number. Any new rules always get a new number that hasn't previously been used. This retains links, but will continually increase the page size and rule numbers (as well as having gaps in the numbering), and clutter the page with old rules that don't matter any more.
 * "Version" the rules page. So the old rules page would be left as it is aside from a notice stating they no longer apply, and then a new page would be created somewhere (Wiki rules/v2? Wiki rules/Revision 2? Wiki rules/2015?). This also retains links, and keeps the "current" version clean with just the relevant information. However, maybe the page naming isn't so appealing, and anyone that ends up on the main wiki rules page will be looking at an old version. We could fix that by moving the existing rules page as version 1, but this then breaks links, and if we have the original page name redirect to the current version, this encourages people to create links that could break in the future.
 * Archive the old rules, as we do with talk pages, then leave links to previous versions of the rules. This keeps the main rules page current and clean, but breaks existing links, requiring the original rule to be hunted down in the archives. Obviously this is no worse than what we already do with talk pages, but that is a technical limitation from wikis not having an actual discussion system, rather than a good way to handle things.
 * <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 05:02, 18 February 2015 (UTC)


 * I'll split out the general sections to their own page shortly if no one disagrees. For the most part the style does not contain other page types yet, so we can continue from there with what other guides to add. The best titles I could come up with were "Features" with an optional prefix of "General", or splitting it further into "Blocks and items", "Entities", and "Structures", though splitting would lead to duplicate sections across article types.
 * As for proposals of actual guidelines, everything except "Article titles" and the version style guide are already rules in action, so assuming the new format is agreed upon, I can start the reorganizing, which would be moving notability guidelines and the image guideline from the rules and later adding the currently general practice guideline from.
 * I think archiving the rules would make the most sense, to preserve the commonly used name. It should be fine, as long a section/archive box is added with rule usage periods (so old talk page posts/edit summaries can use their date to discover the rule). Maybe we could add a notice to the top stating the start period of the current rules as well.
 * – · 05:30, 18 February 2015 (UTC)
 * A similar idea for article-specific style guides is used in . It uses a tree layout for them, and links to avoid duplicate information. — <span class=nowrap> Agent  ( &middot; ) f.k.a. Naista2002 05:51, 18 February 2015 (UTC)


 * That could work, though it does become slightly confusing for the general section links.
 * Another option might be transcluding the sections, which would add a bit of confusion only to the editing (though if done right, the section editing links would lead to the proper place).
 * Otherwise, since most feature articles follow the general format listed, except with variants on the names (obtaining for blocks and items, spawning for mobs, generation/creation for structure...), the titles could be changed to state variants (Obtaining / Spawning / Creation), and add anchors for each variant, though that may become more confusing. <span class=nowrap>– · 16:31, 18 February 2015 (UTC)
 * The article structure section on that style guide is . There are the general guidelines on article layout, and links to sub-guides for guidelines specific to different articles. I may move the general ones to a separate sub-page. But that is a different style guide for a different wiki and discussing it here is off-topic. — <span class=nowrap> Agent  ( &middot; ) f.k.a. Naista2002 16:47, 18 February 2015 (UTC)


 * I've implemented the first change (moving the article layout to a sub page). If all goes well, I will start moving a few of the rules over in a day or two. It could be split further if desired, having the specific sections link to subpages "Features/Blocks and items" or "Features/Entities", or some other system that gets chosen.
 * To explain my editing up top, green is notes edited in later, gray is implemented stuff, and strikeout is canceled. <span class=nowrap>– · 15:54, 20 February 2015 (UTC)


 * Rules relating to notability and images were copied over to the style guide. Can an administrator remove said rules from, archiving the current rules?
 * Since rules 18 and 22 are likely to get moved soon due to, I would place them at the end so the numbers are only required to change once.
 * Also, rule 12 does not really fit with the rest of the remaining rules, although I cannot think of a better place to put it. <span class=nowrap>– · 17:48, 23 February 2015 (UTC)


 * Alternatively, notability could be listed separate from the style guide, which would make the anchors a bit easier to deal with, and allow it to be protected without protecting the style guide. (sample )
 * In any case though, something needs to be done with the wiki rules to finish this discussion, and the rules are administrator protected. <span class=nowrap>– · 16:54, 26 February 2015 (UTC)


 * The rules have been updated, with both the changes here and the talk page guidelines, since they don't belong there either way. I've left the archive page unlocked, if you want to make any changes to it.
 * In addition, I added the style guide to the sidebar. You may wish to propose a better for it. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>  09:27, 1 March 2015 (UTC)


 * still needs to be updated, adding a new group for notability violation and updating the rule numbers. Currently I have not added anchors to specific notability guidelines, as based on what is wanted we would have only one delete reason for all of notability, or one per guideline. A single reason could be something like "Violates ", although mentioning which guideline they violated would likely be better.
 * I don't have anything against the tooltip for the style guide, as it seems rather consistent with the other tooltips. I am mainly glad the link was added, as I use it frequently. <span class=nowrap>– · 20:16, 1 March 2015 (UTC)


 * It occurred to me while updating the reason dropdowns that rule #11 is a duplicate of rule #4, rule #7 sounds like it belongs in the style guide, and rule #12.1 should be its own rule, rather than a sub-rule of abusing multiple accounts. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 02:16, 3 March 2015 (UTC)


 * Since these have only been in place for a day, I doubt they are heavily linked enough to require archiving again, so I would just make those changes:
 * Rule #11 does seem to be covered by rule #4, although I assume it was added due to . If needed 4 can be expanded to specifically state facts must be from actual game features.
 * I really don't see why 12.1 is a subrule, I agree it should be its own rule.
 * Based on the new rules requirements, 7 could easily be moved to a brief line in "Writing". I cannot foresee anyone being blocked for not leaving edit summaries.
 * – · 02:33, 3 March 2015 (UTC)


 * . Once the guidelines are all in place, we should probably put up a site notice about the rule and guideline changes. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 04:23, 3 March 2015 (UTC)


 * You might want to reinstate the disallowing of users from abusing multiple accounts in the user namespace. (numbers changed, but not user namespace exceptions).
 * As for the rest of the stuff left incomplete, I'll propose that on the style guide a little later. <span class=nowrap>– · 04:30, 3 March 2015 (UTC)


 * Fixed. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 04:46, 3 March 2015 (UTC)


 * The remaining two things have been moved to, as well as a few other minor proposals. <span class=nowrap>– · 23:45, 4 March 2015 (UTC)

Indestructible blocks
Do you think a would be useful? This category is for blocks that cannot be broken in mode. 00:03, 12 February 2015 (UTC)


 * There would not be a lot of blocks (Bedrock, barriers, End portals, command blocks, and Nether portals if you do not count breaking the frame), so I am not so sure of the usefulness. If needed, a user can simply check and see all the blocks that cannot be broken by hand. <span class=nowrap>– ·  16:50, 12 February 2015 (UTC)


 * Uh...what about explosions? For example, Nether Portal blocks are destructible by explosions (blast resistance 0). Therefore, the is not a reliable list, since it would make you think Nether Portal blocks are indestructible, even by explosions.   05:50, 11 May 2015 (UTC)


 * For the reasons I mentioned to KnightMiner (and the fact that there may at some time be blocks with their own page that have the explosion problem), I have added the .  06:33, 11 May 2015 (UTC)


 * If you are going to discuss a change before making it, please at least wait a bit before implementation, otherwise there is no point of discussing it. In this case, I find the category to be completely useless, as it simply contains four blocks already described in two other places as unbreakable. (or at least should contain four, if you actually read my comment above before replying to it). <span class=nowrap>– · 15:07, 11 May 2015 (UTC)


 * If not by, then also by . Also, unilateral controversial changes are forbidden. &mdash; <span class=nowrap> (&#124;) 06:46, 11 May 2015 (UTC)


 * NickTheRed, once again, stop making up your own rules. -- undefined 14:43, 11 May 2015 (UTC)


 * until there are sufficient unbreakable blocks to populate reasonalibly the category. -- 21:20, 17 May 2015 (UTC)


 * The category is useless. – - 18:44, 18 May 2015 (UTC)


 * It is now pending deletion. – - 01:44, 19 May 2015 (UTC)

New administrator
,, . The activity of admins on this wiki is dropping down, to the point that administrative actions may take much time to be done. In that time, everything can happen: a new snapshot of 1.9 (with much new blocks, items, entities etc.) or a mass vandalism/spam attack.

To respond to that, we need a new active administrator, and I’m confident that is best candidate for it.

'''Unsigned comments by new or anonymous users will be deleted. Please sign your comments with, which also can be added with or  button.'''

— <span class=nowrap> Agent  ( &middot; ) f.k.a. Naista2002 13:55, 20 February 2015 (UTC)


 * ,, , , , , , , , , ? <span class=nowrap>—  18:21, 2 March 2015 (UTC)


 * I doubt I am the best person to state reasons why I should be promoted, due to this wiki's administrator promotion policy, so rather I will state a few other things.
 * The administrator activity is a bit lower than before, though most administrative issues are dealt with in a reasonable amount of time (Majr's response to the first mentioned topic stated that for the most part). The main thing my promotion would change as far as administrator activity is a couple hours where I am online and no administrators are online (towards the early middle of the time I can be found here).
 * Overall, I would advise if you think I should be promoted to change or expand your approach to state if and why you think my skills or experience would be helpful as an administrator, rather than only my time.
 * Also, ping automatically comma separates <span class=nowrap>– · 18:46, 2 March 2015 (UTC)


 * : Basically agreeing with what KnightMiner said. On the contrary of administrator activity, (apologies beforehand to every admin and bureaucrat for checking the contributions) there have been some admins who have been inactive for quite a long time. Take, , and for example, who have been inactive since 2011 and 2013, respectively. I think we could promote a few more admins if need be.  ( 20:55, 2 March 2015 (UTC)


 * I'm still not convinced that we need more admins for the sake of having more admins. However, KnightMiner has made many good contributions, particularly to templates, modules, and the MediaWiki interface, but has often had to ask admins to make the actual edits to protected pages. I think the wiki would be well-served by letting him make these changes directly, instead of going through someone else. -- undefined 04:18, 11 March 2015 (UTC)


 * It has sometimes puzzled me why KnightMiner isn't an admin. 13:50, 25 May 2015 (UTC)

Split PE versions into their own articles?
I think the PE versions (listed in version history as of right now) should probably be split into their own pages. I talked about this in regarding 0.11.0 being split into a new article (before it got too big) a short while ago and  suggested that I should start a discussion here.

TL;DR Should we split the PE versions into their own articles or leave them as is?  ( 19:17, 20 February 2015 (UTC)


 * I would support splitting them. A few preparations would need to be made first, such as better support for non-PC versions in version nav (eg, support for multiple release dates and listing which editions got the release at all out of the four mobile versions). We would also need a value for the edition parameter which sets categories and likewise ("Pocket Edition", "Pocket" or "Mobile" would make sense). Lastly we would have to decide a consistent naming format (as of right now, "Pocket Edition version" seems to be the most popular).
 * I could work on the version nav changes if there is enough consensus to split the articles. <span class=nowrap>– · 19:38, 20 February 2015 (UTC)


 * I will move everything in the section. Note that if the page is actually moved, the new page would have irrelevant information. ~From Contrapple 22:36, 19 March 2015 (UTC)

Merge granite, andesite, and diorite
I propose that granite, andisite and diorite, as the only differences are their look and the way they are crafted.Please state your opinion. 19:37, 22 February 2015 (UTC)


 * They should be merged with stone. And . – - 21:08, 22 February 2015 (UTC)


 * This was discussed a year ago, see . The general opinion was to avoid merging them, as rather than decrease the confusion, it would increase the confusion. A similar case was discussed a couple times on to merge with, and the two cases basically stated that even if blocks function the same way, the community prefers article separate.
 * Specifically, there is no title the three variants can be merged under that would make sense, and they are too different from stone to consider merging it with that article. Also the crafting recipes would become confusing attempting state the block can be crafting into another colored block. <span class=nowrap>– · 00:01, 23 February 2015 (UTC)


 * How about decoration stone. 14:48, 28 February 2015 (UTC)


 * Since they are never called that in game, nor do any of the titles contain "decoration" or "stone", it would simply lead to confusion. <span class=nowrap>– · 15:39, 28 February 2015 (UTC)

Account
I attempted to create an account, but I do not have an email. 00:02, 24 February 2015 (UTC)


 * The only solution would be for you to create an email. Many places offer a free email account, and you do not have to use the email account after signing up. <span class=nowrap>– · 00:10, 24 February 2015 (UTC)


 * Why do they ask for your email address? 03:03, 24 February 2015 (UTC)


 * See (fifth bullet point).
 * According to that, the email should not be required, but it is recommended to help with identification. For example, should you ever have difficulties logging in makes it easier to contact support. <span class=nowrap>– undefined/undefined 03:41, 24 February 2015 (UTC)
 * What happens if you try to use someone else's email address? 02:01, 26 February 2015 (UTC)


 * You will not be able to confirm the email address, which prevents you from using any of the email features, thus defeating the purpose of adding the email. <span class=nowrap>– · 02:24, 26 February 2015 (UTC)
 * The page says that if you use your email, you will be able to send and receive emails, but even unregistered users can send and receive messages. 02:30, 26 February 2015 (UTC)
 * Actually, I do have email. Does it matter what website an email address is using? 00:11, 8 March 2015 (UTC)


 * It shouldn't, any site should work, provided its a valid email address (name@website). <span class=nowrap>– · 03:53, 8 March 2015 (UTC)

Why is the wiki "official" ?
Hi, the main page's title is "Official Minecraft Wiki - The ultimate resource for all things Minecraft", but can someone explain me why it is official ? Did Mojang say something about it ?

I am wondering this because of that... • undefined · <span style="font-size: 0.9em; font-style: italic; letter-spacing: -1px">FR Admin · 14:37, 4 March 2015 (UTC)
 * Ask via email. <span class=nowrap>—  undefined ⁄ undefined (f.k.a. Naista2002) 14:41, 4 March 2015 (UTC)


 * Try asking, see . – - 14:46, 4 March 2015 (UTC)


 * https://minecraft.net/community, under 'Official Resources'. -- undefined 15:51, 4 March 2015 (UTC)
 * Thank you ! •  undefined · <span style="font-size: 0.9em; font-style: italic; letter-spacing: -1px">FR Admin · 17:47, 4 March 2015 (UTC)

Periodic Table
I think there should be a page that shows the periodic table of Minecraft. 16:47, 7 March 2015 (UTC)


 * There is no periodic table of Minecraft. Creating anything as such would be a fan made product, and would not belong here. Try the forums if you want such a table. <span class=nowrap>– · 16:50, 7 March 2015 (UTC)

Non-renewable creative mode items
I disagree with including creative mode items in, they seem out of place there. Maybe creative mode items should have their own category, which could be a sub-category of non-renewables. That would still leave outlying cases like items that can only be obtained by inventory editing. Has this already been discussed? Is there a wikiproject for categorization? 14:44, 11 March 2015 (UTC)
 * — <span class=nowrap> undefined/undefined (f.k.a. Naista2002) 14:59, 11 March 2015 (UTC)


 * With the way the categories are added, it would not be easy to denote which are creative only using subcategories, though it could be done. (currently the categories are added automatically, but that would require them being added manually or change the infobox design)
 * Other than that, I don't really have anything against it, though a few more categories than creative only would be relevant.
 * Also, with the project mentioned above, it is currently not very active as far as discussing the categories, but I would still be open to discussing it there. <span class=nowrap>– · 16:19, 11 March 2015 (UTC)
 * They technically count because you can't get them in Survival. 00:07, 13 March 2015 (UTC)
 * I have added a as a subcategory of . –Preceding unsigned comment was added by  ( • ) at 6:54, 11 May 2015 (UTC). Please sign your posts with
 * Don't do controversial actiobns unilaterally. &mdash; <span class=nowrap> (&#124;) 07:14, 11 May 2015 (UTC)


 * That category is no where near complete as far as relevant resources, and it still has the issue of pages contained in a sub category should not be in the main category, and it also makes no sense to only highlight one aspect of non-renewable. <span class=nowrap>– · 15:12, 11 May 2015 (UTC)


 * The category is now pending deletion. – - 01:46, 19 May 2015 (UTC)

Missing texture
Should we have a page on the missing texture? If yes, please upload a picture of the current magenta-black checkerboard missing texture. 00:12, 13 March 2015 (UTC)


 * . I don't think we need an entire page for it, but it could be mentioned at . -- undefined 00:35, 13 March 2015 (UTC)


 * I think it should be mentioned on, due to resource packs showing defaults for textures that do not exist in the pack.

15:40, 4 May 2015 (UTC)

Default User Page
I recently created my account and user page. However, my page defaults to my profile. How do I change this? 13:30, 13 March 2015 (UTC)


 * Go to . | 14:00, 13 March 2015 (UTC)


 * Which section? I tried everything that would make sense. 14:15, 13 March 2015 (UTC)


 * In, go to User Profile and scroll down to Public Profile. Then, click on the box with Page Type next to it and select Use a standard wiki user page.  ( 14:29, 13 March 2015 (UTC)

Can't change my signature correctly
I attempted to change my signature using. However, when I saved my preferences, "SUBT:" was automatically added just before the word "ItemSprite", which messed things up. How can I fix this? 03:01, 14 March 2015 (UTC)


 * Templates aren't allowed in signatures. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 03:06, 14 March 2015 (UTC)


 * I tried using the file and got ~From Contrapple 03:21, 14 March 2015 (UTC).


 * You can't put files inside links. Use . <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>  03:29, 14 March 2015 (UTC)

Vandalism on my page
I was creating one of my user pages and there was an edit conflict. The version that would've been saved had no wikitext, meaning that someone tried to vandalize my page. Can someone tell me how to protect the page?~From Contrapple 15:18, 14 March 2015 (UTC)


 * None of your pages have been edited by anyone other than you. You may have edit conflicted with yourself, I've done that a few times.
 * As for protection, you cannot protect pages unless you are an administrator, and even if your page had been vandalized, a single vandalism is not enough to require protection. <span class=nowrap>– · 15:49, 14 March 2015 (UTC)


 * How do you know that you conflicted with yourself?~From Contrapple 19:52, 14 March 2015 (UTC)
 * How is it possible to conflict with your own edit?~From Contrapple 19:52, 14 March 2015 (UTC)


 * Pressing "save page" two or more times. – - 20:58, 14 March 2015 (UTC)


 * I put all my user pages on my watchlist. Is there a way to set up my account so that pages on my watchlist will give me a notification when edited? If so, how do I do it? If not can an administrator add a way to do so?~From Contrapple 22:41, 14 March 2015 (UTC)


 * Go to and select the 'Email me when a page or file on my watchlist is changed' option. -- undefined 00:02, 15 March 2015 (UTC)

Help pages
How relevant are the help pages to keep, since gamepedia has ? Most of the help pages here are barely touched, with many outdated, and by  gives the implication that using the help wiki is preferred over the local help contents (especially since the help link was removed as least four times in that edit...)

I would propose migrating the general help pages which are not already contained there to the help wiki, and keeping any help pages specific to this wiki, such as and.

<span class=nowrap>– · 01:45, 16 March 2015 (UTC)
 * And add missing wiki-specific help pages. I once made (on Russian wiki) -_- — <span class=nowrap> undefined/undefined (f.k.a. Naista2002) 11:28, 16 March 2015 (UTC)


 * I would agree to adding a few more of pages specific to this wiki, though we may want to decide a few standards on what is relevant and what should remain elsewhere (like on template documentation). <span class=nowrap>– · 15:33, 16 March 2015 (UTC)


 * So, if no one has any additional comments, I will start replacing some of our less specific to this wiki help pages with to the Gamepedia help wiki. <span class=nowrap>– ·  19:43, 10 June 2015 (UTC)


 * Which pages are you thinking of redirecting? <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  06:12, 11 June 2015 (UTC)


 * Well, other then fixing what would become redirects to a soft redirect, I plan on redirect the following pages:
 * to
 * to
 * to
 * to
 * to
 * to
 * to
 * I plan on keeping, and , plus tweaking  a bit to direct people to the help wiki for editing help, as well as to state some of the wiki specific help. <span class=nowrap>– ·  01:14, 12 June 2015 (UTC)

Smilies
On Russian wiki, there is a for inserting graphical smilies into the text. I would like to also have that template here. Any objections/concerns? — <span class=nowrap> undefined/undefined (f.k.a. Naista2002) 15:02, 21 March 2015 (UTC)


 * I don't see much need for it; we're not a forum. Also, those particular icons appear to be copied from the Invision Power Board forum software. As far as I can tell, its license doesn't allow this use: see https://www.invisionpower.com/legal/standards . -- undefined 15:33, 21 March 2015 (UTC)
 * Some of them are also found in phpBB. I think that these images were widely used elsewhere, and so some forum software creators decided to use them in their software. — <span class=nowrap> undefined/undefined (f.k.a. Naista2002) 15:47, 21 March 2015 (UTC)
 * Either way, I need to ask . — <span class=nowrap> undefined/undefined (f.k.a. Naista2002) 16:02, 21 March 2015 (UTC)
 * GNU General Public License. — <span class=nowrap> undefined/undefined (f.k.a. Naista2002) 14:51, 25 March 2015 (UTC)
 * The exact images should be able to be replaced with some royalty free icons, maybe even Minecraft themed ones, so I don't find that as a major concern.
 * I don't have much against the idea, but how often would it get used? I personally doubt I will use it, as I rarely use smilies, so in the rare case that I do use one, I am fine with a simple ":)". In general, I don't see a lot of smilies from other users anyways. <span class=nowrap>– · 16:41, 21 March 2015 (UTC)
 * A smiley face can be proposed on the talk page. On mobile devices (at least on iOS) you can type a smiley face. ~From Contrapple 03:07, 28 March 2015 (UTC)

Messages (pages)
When you search a page starting with "Mediawiki:", you will notice that in the section above the page, it is called a message. I couldn't figure out what they mean by message. Can someone please explain or create a page about it? ~From Contrapple 03:14, 28 March 2015 (UTC)


 * <span class=nowrap>– · 03:17, 28 March 2015 (UTC)

Official user page guidelines
Welcome back, KnightMiner here, and today I have a guide proposal in the userspace. (wait, that's not quite right, hold on a moment...)

Seeing as there has been some recent disputes on what is allowed in the userspace, and the specific guidelines are not stated in any central point, I have written another guide proposal to sort all of the information out and make the information official.

The proposed guide is located at. A few notes on the content:
 * It starts by describing the userspace, specifically the user pages, user talk pages, and user pages within other namespaces (those being modules, categories, and files)
 * The main purpose of this is to describe which pages the user has control over, and to allow more page types to be added should the need arise, such as if we ever have another extension requiring its own namespace.
 * The second section contains content allowed (mostly anything) and disallowed (mostly wiki rules and content that affects the mainspace).
 * It also has a brief segment to allow fixing of broken and double redirects, as well as to implement soft redirect for user page redirects to other wikis (notably language variants)
 * The final section contains allowed reasons for editing the userspace, with the primary reason being to remove disallowed content or discuss on talk pages, and other reasons that are generally allowed stated.

For the most part, the only new guideline is that user talk pages should discuss the relevant user content page (other than the main page, for direct communication). This is mainly because any other usage would end up as spam, such as a user taking build requests or minecraft suggestions. Other than that, I avoided adding any new guidelines, as I preferred to discuss new addition here or on its talk page if implemented.

That's about it, thanks for reading. (there it is again...) <span class=nowrap>– · 01:49, 1 April 2015 (UTC)


 * "Any user may … edit another user's talk pages" — This seems like a dangerous statement. Maybe something like "Any user may create another user's talk pages or contribute to a discussion on another user's talk page."?


 * Also, something like "Users may delete any posts or discussions in their own userspace, even admin warnings (though they still must obey rules). However, users are strongly discouraged from modifying other people's posts except to comply with the wiki rules, or deleting single posts that would make a discussion confusing." &mdash; &middot;  &middot; 18:00, 1 April 2015 (UTC)


 * Yeah, looking at the first rule does seem to be able to be taken the wrong way. I changed it to be basically what you said.
 * As for modifying other people's posts, that is already disallowed by the, so I don't think discouraging it on the user page guidelines as well is needed (since the user page guidelines require following the talk page guidelines).
 * As for removing discussions, I added that it is allowed, but discouraged. Though,, which would be something to discuss here. My opinions:
 * I personally would suggest disallowing deletion of comments or discussion, except in the case of rule violation. Still allowed would be moving the discussion to another talk page or archiving it. (if the user wishes to, they may create a separate archive for warnings, like I've seen several times on Wikipedia. They also are not required to reply to the warnings if they don't want to). (I feel it is worth mentioning that this rule would not apply to topics deleted before it was enacted should it become a rule)
 * On the other hand, users should be allowed to define some topics that are not allowed (as long as the topics do not include warnings), in which case creating a topic would be violating a rule for that talk page.
 * – · 18:45, 1 April 2015 (UTC)


 * I can see that allowing users to delete admin warnings might make it more difficult for admins to notice a pattern of behavior. Allowing users to move or archive warnings seems like a reasonable compromise that still allows users to present their userspace in their own way.


 * New issue: A non-native English speaker looking up the word "guideline" might believe it means the same thing as "rule" (that's the first definition listed in my dictionary, for example), but as a native English speaker I interpret it much more loosely than a rule. Perhaps "Recommendations" might be a better word, so that non-native English speakers don't believe these are rules that might justify blanking user pages, etc.? &mdash; &middot;  &middot; 19:34, 1 April 2015 (UTC)


 * I tend to think of guidelines as not quite as extreme consequences as rules, but still required (other than that one case with the project I started, in which I use the word "guidelines" as I would now conciser incorrect, I should really fix that...) . I could use a different word to state that meaning, though "recommendations" seems like we are advising against such action, but they are fine to do it, meaning we would lose the ability to remove improper content, while "rules" as it is used on this wiki sounds much too extreme.
 * It might be relevant to add some sort of rule priority scale to rules. The scale would range from "you could get blocked for breaking" to "fix only if you are already editing other stuff".
 * As for specifics on blanking userpages and alike, the only content disallowed by the guide would have to be removed anyways. Specifically:
 * Userspace redirects would get fixed or broken userspace redirects deleted
 * Some categories will get removed
 * Spam, plagiarism, and advertising would get removed. This one could be a slight problem as spam, plagiarism, and advertising are somewhat open to interruption.
 * Things like the rule about talk page usage exempts the userspace, and the userspace is also be exempt from the style guide (it is required to follow the wiki rules and talk page guidelines, and all other guides fall would fall into the "almost else allowed", though I could state it more specifically) <span class=nowrap>– · 22:46, 1 April 2015 (UTC)


 * Based on some recent actions by newer users, I would suggest disallowing the usage of a user's main talk page as anything other than a talk page, which would go in line with the "don't delete old topics". Otherwise, when a user fills their talk page with article content, it become impossible to use it to actually communicate with them, such as to communicate rule violations or to ask for a reason for a revert. I know we want to avoid "biting" the new users by removing their main place to test things, but that does prevent proper communication with the user, and we also now have a better sandbox to point them to should the reason be simply resting edits.
 * Along with that rule, it would be a good idea to suggest if a user is misusing their main talk page to move the page to their main userspace, rather than deleting the content (but first leave a topic to point to the rule about proper usage) <span class=nowrap>– · 03:44, 25 April 2015 (UTC)
 * Finally... . &mdash; <i class=nowrap> undefined/undefined (f.k.a. Naista2002) </i> 09:04, 25 April 2015 (UTC)
 * . – - 11:47, 25 April 2015 (UTC)
 * -  ( 12:54, 25 April 2015 (UTC)
 * Punishment is not an argument. &mdash; <i class=nowrap> undefined/undefined (f.k.a. Naista2002) </i> 12:56, 25 April 2015 (UTC)
 * Do I have the word "punishment" anywhere in that sentence?  ( 13:11, 25 April 2015 (UTC)
 * No, but I feel that you oppose due to punishing me anyway. — <i class=nowrap> undefined/undefined (f.k.a. Naista2002) </i> 13:19, 25 April 2015 (UTC)
 * I'm not opposing to punish you. I'm opposing because of a few things:
 * KnightMiner said that "advertising would get removed." If so, then the userspace is no longer exempt from rule 5.1 on the.
 * KnightMiner also said that he is against disallowing deletion user talk page comments which contradicts his next statement regarding about topics that are not allowed on a userspace as defined by the user.
 * If these rules go into place, my gosh, I feel like I want to shout f**k it and leave. In fact, no rule for the second thing I described exists on Wikipedia, and users have been allowed to delete user page comments on their own will (unless they are blocked, in which continous reverts can lead to editing the talk page being revoked) .  ( 13:41, 25 April 2015 (UTC)
 * Rules are not ideal, and may be corrected if needed.
 * We’re not Wikipedia. They have their own rules, we have our own. For your interest, I shall say that while English Wikipedia, as you said, allows users deleting comments on their own user talk pages, Russian Wikipedia it.
 * — <i class=nowrap> undefined/undefined (f.k.a. Naista2002) </i> 14:22, 25 April 2015 (UTC)




 * 1) That comment above was mainly stating the only content that would get removed to address munin's concern about userpage blanking. Advertising is things such as "Discount Steam games at our site" or spamming advertisements for a mod (which would be different from stating "I have this mod, here's a bit about it", that's the reason for the "open to interpretation" part). This specific rule is already in place, and the  still exempts user pages from 5.1 (though I did make it a bit more clear just now).
 * 2) With deleting user page comments, the idea is you are allow to set up some rules for topics allowed on your talk pages to go along with the general wiki rules (such as disallowing people to ask for Minecraft support, a Minecraft dev disallowing suggestions, or requiring certain topic types on an alternative talk page). You would not be allowed to disallow warnings or discussion on recent actions entirely. Along with this, you can then delete new topics that contradict the wiki rules or personal talk page rules, but you are not allowed delete old topics because of a new rule or delete topics that do not fit any of the rules (archiving is still allowed).
 * This specific rule was still open to discussion, it has not been added to the proposed guide yet so it is not final, so feel free to suggest improvements or a compromise (such as suggesting to only disallowing deletion of warnings). It is important to note its main purposes, which are allowing administrators to check user pages for past warnings, and allowing users to discuss recent actions of other users. <span class=nowrap>– · 15:54, 25 April 2015 (UTC)


 * I would also like to point out that you suggesting a user's talk page to not be anything other than a talk page would be disastorus and destructive, as the user pages (including talk) are already exempt from rules 4, 5.1, 6, and 8. Adding these so-called guidelines in place would probably cause some users to feel discouraged about the rules and what they actually mean, including . With that, I still hold a .  ( 16:43, 25 April 2015 (UTC)


 * I think my comment above implies this, but for the record I believe people should be able to control their own userspace (including talk pages) as much as possible. Your userspace is a place to explore your ideas about how to structure articles and talks and that allows people to innovate. Maybe 99% of non-standard userspace will be confusing and purposeless, but that freedom is where new ideas will come from that improve the wiki. Imagine if this conversation had ocurred before user boxes become common -- they might have been prejudicially banned because they didn't fit the conventions in place before the discussion. More rules just make people think they can go around telling other people how to run their userspace. I don't see any need for these rules -- there are already rules the admins can use to maintain the integrity and safety of the wiki, and otherwise people should just leave other people's userspaces alone. &mdash; &middot;  &middot; 17:08, 25 April 2015 (UTC)


 * As for the talk page usage, we already limit a user's "ownership" of their talk pages to allow comments from other users. Assuming we allow anything on their main talk page, how would you suggest leaving a comment on ? A few comments have been required there in the past, but there is now no way to discuss stuff with that user. If they need to freely experiment, they have their main userpage which has alot more freedom.
 * As for the rules that are "already in place" for the admins, there are none other than block worthy violations. The only authority users have to prevent user pages from interfering with the mainspace is some topic buried in the archives of the community portal. <span class=nowrap>– · 18:09, 25 April 2015 (UTC)


 * — <span class=nowrap> (&#124;) 18:27, 25 April 2015 (UTC)


 * The rule has not been agreed upon, so that was still technically allowed usage at this time. It is a better idea to wait until consensus has been achieved for a bit of time before making changes based on it. <span class=nowrap>– · 18:36, 25 April 2015 (UTC)

Materials
In Minecraft, each block has a "material" that controls certain properties and gives defaults for others that the specific block time can override. After digging through the code for 1.8, I wrote up. If anyone would like to look that over, I'd appreciate it. 03:04, 12 April 2015 (UTC)


 * I see a few minor errors, such as you used "" instead of "" for the grass material, and I see a few points where the grammar could be slightly improved. Other than that, it looks pretty good, I would support it becoming an article.
 * I assume the propose of this page is to replace the article ? (If unsure of what I'm referencing, see ) <span class=nowrap>– · 03:46, 12 April 2015 (UTC)
 * Please feel free to make any necessary edits. would be a good title for it, yeah, in which case the existing article could move to  which is currently a redirect with no incoming links, but that'd need admin help to take care of.   11:13, 12 April 2015 (UTC)


 * I made a few tweaks. I assume that list of blocks within the first table was left over from before the table split?
 * Also, as for the current article, I don't think it is necessary to keep it. I previously posted on its talk page stating that it really did not fit as a main space article, as its content would make more sense as a category (the entire content is a brief description, then article that fit the description).  then pointed out that  already contains the same pages and suggested instead of deleting the page to replace it with an article about Minecraft's internal materials. <span class=nowrap>– ·  00:35, 13 April 2015 (UTC)
 * Works for me, I overlooked that conversation when I checked that talk page.  11:23, 13 April 2015 (UTC)

Shortcuts for to Minecraft Wiki pages
Following up, where it was stated redirects for the Minecraft Wiki pages should be discussed, I am proposing a few redirects. It may also be relevant to create a page containing a list of shortcuts.

As for specific suggestions:

As for which of these I think need the shortcut the most, I would emphasize the style guide shortcuts for images and history/future, and the talk page guidelines shortcut. <span class=nowrap>– · 19:58, 16 April 2015 (UTC)


 * I would be in favour of those suggestions, as well as perhaps one for the admin noticeboard. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  04:43, 18 April 2015 (UTC)


 * That would make sense, though the best I can come shortcut I can think of is or  (ex. if you need administrative help, ask the ? It would be slightly inconsistent with  leading to ). Otherwise, we could copy the shortcuts from wikipedia and end up with  or, though they are hardly descriptive. <span class=nowrap>– ·  00:00, 19 April 2015 (UTC)


 * I do think makes the most sense out of all those suggested. Not really sure about the inconsistency, on one had it might be confusing but on the other neither  or  seem very intuitive...  <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  11:59, 19 April 2015 (UTC)


 * Alright, I added shortcuts, except where crossed out. For now I just added the shortcuts to the pages using shortcut. I am not so sure about the second wiki rules shortcut, as a title is normally used when linking that page anyways. <span class=nowrap>– · 17:27, 25 April 2015 (UTC)


 * Ok, but why are they all uppercase? They're not abbreviations. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 07:25, 29 April 2015 (UTC)


 * Perhaps for the same reason they are uppercased on Wikipedia. &mdash; <span class=nowrap> (&#124;) 09:27, 29 April 2015 (UTC)


 * Which is? <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 11:06, 29 April 2015 (UTC)


 * All caps is basically a stylistic design. While the shortcuts could be in any case, keeping them in one case, even between abbreviations and short names, helps users remember them. Other than that, it help are users who are use to Wikipedia, and keeps them consistent with any Wikipedia shortcuts we may reference, such as . Lastly, I think it reads a little better when a referenced policy is all caps should you reference the shortcut directly in text, such as saying "refer to " or "refer to ", (though arguably capitalizing the namespace and first letter would read fine)
 * Although, since they are not wide usage at this time and redirects are cheap, I don't see any reason we cannot change them if enough people prefer a different case. <span class=nowrap>– · 15:34, 29 April 2015 (UTC)

I hate the shortcut. I feel like we shouldn't sacrifice readability for efficiency that much. &mdash; <span class=nowrap> (&#124;) 06:52, 11 May 2015 (UTC)

We can just use piped links. -> . –Preceding unsigned comment was added by ( • ) at 11:14, 31 May 2015‎ (UTC). Please sign your posts with
 * First, this is already implemented. Second, noone wants to write  if they can write  . |  14:55, 31 May 2015 (UTC)

Version pages
Reviving discussions from and

Recently, the version history pages for the release and development versions were split up into their own pages for each respective version to increase readability. However, pages from Beta and earlier as well as the version history from other editions (Pocket and Console) were still left in tact. My questions are:
 * 1) For the PC version, should we go further back in creating version pages? I think Beta should probably be converted but for versions before Beta the changelogs are not very long.
 * 2) Should Pocket and Console Edition be converted to the new page format? Looking at the  page, it is starting to get very cluttered with new versions being added. These would need additional support for multiple editions.   <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  04:57, 18 April 2015 (UTC)


 * As for the PC editions, I don't have anything against splitting the articles, although the farther you go back, the less content is contained. I would suggest splitting beta editions for now, as there is a bit of an issue regarding its pre-releases and it seems to have decent content in most cases. I would wait longer for alpha, indev, infdev, and classic a bit longer, due to the latter three having very inconstant title format and all having a lot less content (though more than some snapshots).
 * I also still agree the pocket editions should have their own articles. I think the only reason it has not been done yet is due to only a few people stating support in previous discussions. As for titles, I personally prefer prefixing them with "Pocket", partly due to is current usage in version link and partly due to the addition of "Edition" seeming redundant, as it is going to be some form of edition in all cases. I would not disagree if most other editors agree to using "Pocket Edition" though.
 * With the console edition, the version history could use splitting up just as much, but we also have the problem that each update has three different names (Xbox uses TU#, Xbox One uses CU#, and PS3/PS4 use more standard version numbers), and I cannot think of a reasonable solution to cover all of them.
 * – · 19:31, 18 April 2015 (UTC)


 * I think the table we have at/on/in(?) the German wiki is pretty clearly arranged. A single page for every version is just confusing in my opinion (at least for the console edition; do you want five pages for a single version? And if you want only one, how do you name it? And how will someone find it?) so I don't think that it's good to split  up. I wanted to update that page after I completed the translation into German, which I haven't done yet (It's almost complete), maybe I'll look into that soon. |  22:50, 18 April 2015 (UTC)


 * While what you have there on the German wiki is probably better than the mess that is on our page, the fact that close to half of the width is taken up just by the version/date information is way too obtrusive. Only smaller devices (tablets) this issue is made worse. I do think version pages are the way to go to avoid long tables but I'm trying to think of how the navigation would work and how to sort out the multitudes of different editions. It might still turn out to be a mess...
 * I have also completed converting all of the Beta pages to version pages. Perhaps we can start converting the Pocket Edition as there don't seem to be any objections? <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  11:47, 19 April 2015 (UTC)


 * The new Beta pages look pretty good. I think the next step would be splitting the Pocket Edition versions, though we may want to wait a few days to start that to give people time to voice opinions.
 * I also agree that the amount of versions causes an issue due to the width of the version details. It takes up about half of my monitor. If there was a way to make it smaller, I might agree with that design, though I would overall prefer to split them out for consistency with the other versions.
 * On a somewhat related note as we are expanding the number of version articles, do the version pages really need the navbox minecraft? They are already contained in their own navbox computer versions, and none of the versions are on the minecraft navbox (other then the version history "hub" articles). Would anyone object to the removal of the minecraft navbox from version articles. <span class=nowrap>– · 01:00, 20 April 2015 (UTC)
 * Absolutely agree with removing Minecraft from the version articles. &mdash; <i class=nowrap> undefined/undefined (f.k.a. Naista2002) </i> 11:30, 20 April 2015 (UTC)


 * Would or  be able to create support for the Pocket Edition pages? In regards to the Console Edition pages, I think we'll leave them for a bit longer and see if there are any other better solutions to fix the multiple version/platform problems.  <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  06:33, 29 April 2015 (UTC)


 * Does pocket edition not have the same issues of multiple platforms as the console edition, though? <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 07:20, 29 April 2015 (UTC)


 * Sorta, except they all at least have the same name, which is the major issue with the console edition. Looking over the list of versions, the only real problems would be stating which versions it released for and separate release dates (which could be done together), and about five early versions where each platform got a slightly different version of the original version. It should be easy to cover though.
 * Goandgoo@undefined I'll start messing with the version nav template in my sandbox to see about adding support. <span class=nowrap>– · 15:19, 29 April 2015 (UTC)
 * . Currently it is set up for the title format of "Pocket Edition ..." (which means the edition parameter should be set to "Pocket Edition"), but it could easily be changed to the format "Pocket ..." if desired. <span class=nowrap>– · 18:10, 29 April 2015 (UTC)


 * I have started setting up the version pages for the later versions of Pocket Edition. I have created a page for (the first dev build of 0.11.0) and am wondering how that looks before I convert the rest of the dev versions. Also, on the main  page, how can I make it so the snapshots/dev builds are listed in the version nav bar (like on the PC versions)?  <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  02:46, 3 May 2015 (UTC)


 * It looks good in my opinion, though I did change it to use the type to "builds" rather than "snapshot" (and added default support for builds in version nav)
 * For the dev builds, a null edit updated the list, though I did make a few tweaks so it reads better.
 * One other tweak I would suggest is if a PE version is only released on some editions to note that in the header text, rather than just using the release date (like some of those andriod only bug fix versions). <span class=nowrap>– · 03:59, 3 May 2015 (UTC)
 * One other tweak I would suggest is if a PE version is only released on some editions to note that in the header text, rather than just using the release date (like some of those andriod only bug fix versions). <span class=nowrap>– · 03:59, 3 May 2015 (UTC)


 * Ok, I've changed the intro paragraph on some of those versions, and will post again should I run into any other concerns. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  04:54, 3 May 2015 (UTC)


 * Are you able to make a page like for Pocket Edition 0.11.0? Also, why are the snapshots on  out of order? –Preceding unsigned comment was added by  ( • ) at 5:12, 03 May 2015 (UTC). Please sign your posts with


 * Yeah, those work fine. Use the same title format, just remember to set to.
 * I also fixed the ordering, it seems DPL now defaults to ordering by title with namespace, which is broken (at least with the main namespace). <span class=nowrap>– · 20:50, 3 May 2015 (UTC)


 * Is there any way to order the pages such that build 2 comes after build 1, instead of build 10 (see )? In addition, is there any way of displaying the Pocket Edition versions template instead of the Computer versions template at the bottom of the combined development version lists (e.g. )? Also, I have now gone as far back as 0.9.0, and have used the same formatting on the development versions page as that of the computer version. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  14:38, 4 May 2015 (UTC)


 * I just fixed that using a sort key (its all automatic, so nothing needs to change on future pages). The DPL query also now sorts based on sort key rather than page title. Pocket edition development version lists now show the proper navbox. <span class=nowrap>– · 17:02, 4 May 2015 (UTC)


 * I've converted all of the pages from 0.1.0. All that's left now is the pre-release version - should that be converted to a version page or just left there? Also is there a better way to organise, what I did there was based off the information in the table, for all we know the Android and iOS versions could be the exact same. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  12:49, 7 May 2015 (UTC)


 * I would make it a version page for consistency, no reason to have a single version unconverted. Just call it something like.
 * Since they have the same number, I would definitely leave them together, and since all the features are exclusive to one or the other, I think what you have there makes the most sense. <span class=nowrap>– · 20:36, 7 May 2015 (UTC)

Pi Edition and further action
has recently split the Pi Edition version history, and as only three articles were affected and it was already fully supported on the technical side, I choose to leave the articles as split. I was wondering if there are any objections to this change before I update the to allow the Pi edition.

Additionally, since the PC alpha updates have just about as much content as the PC beta updates, I would like to start splitting them out, and then merge the, , and version history articles into one article. I would leave the pre-alpha version histories as they are, possibly as a permanent thing, since they lack both significant content and most lack version numbers (they just use dates, especially in indev and infdev).

Lastly, since the Console edition is now the odd one out, is there a good solution to split that article? The best ones I can think of are:
 * 1) To have all other editions as redirects (unless it lacks a corresponding version), and prefer the Xbox edition number
 * 2) * The major issues are it becomes a mess of which title is used by the wiki, and should the Xbox be discontinued, it would become even more of a mess
 * 3) We could to completely split the versions of the same number, and simply link each other as "this update contains the same content as blah blah PlayStation version" Since the PlayStation versions in nearly all cases use the same version number, I would keep them together (and in the two exceptions, just use a bit of disambig), but split the Xbox 360 and Xbox One into two articles.
 * 4) * The major issue with other than content duplication is we would have to redesign the way we link other console editions. With a bit of effort, we could simply have the history table use three columns for the version numbers, to correspond with each of the three version numbers (Xbox 360, Xbox One, and PlayStation), and just state an additional "exclusive to Playstation 3" or "first release for Xbox One" in the text if needed. This would also help the version histories cover the console edition a lot better, such as currently on articles we have cases such as stating the title updates for most of the table, and then switching to PlayStation in the middle due to an exclusive update, then switching back for common updates again. See for such a case. Updating to use a new format would become a lot of work in itself.
 * 5) Leave the versions on the old combined article
 * 6) * The main issue with this is the console edition versions would use a completely different format from the rest of the versions, but this option overall is a lot easier to use.

Overall, I am most in favor of idea 2, as it better supports slight diversity between console editions and the more major diversity with bug fixes, and the extra work seems minor compared to better representing the versions. <span class=nowrap>– · 02:57, 27 June 2015 (UTC)


 * Although I thought it was a bit strange that the Pi Edition was split due to the small number of versions that it has, just to maintain the uniformity across the multiple platforms I do support the change and the update to the style guide in this nature.
 * I also support the spitting of the Alpha pages, but unsure of the reasons to merge Alpha, Beta and the release version articles into one article. Surely having those pages merged but the Pre-classic, Classic, Indev and Infdev pages unmerged would be confusing and lacking in uniformity.
 * In regards to the Console edition, I would honestly just prefer option 3, as splitting up the versions would just result in a pretty significant mess. I know it's not necessarily the best option as the page will inevitably become longer, but I think usability-wise it would be much easier to use. Perhaps if we can avoid content duplication, but I think it's just going to be even messier than what we have now. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  03:29, 27 June 2015 (UTC)


 * The main reason I wanted the PC version history pages merged was to keep the pages together, put all the information in one place as there is less need to have it separate. We already have a section for "release" (called "version" there), so the rest would fit in well IMO. Also, should the Pocket or Pi edition get a beta, it would very likely be kept on the same article, since page size is no longer a reason to split it. (plus, it would also remove the need for the version nav since the article would better link that stuff.)
 * In regards to issues of merging the pages: yeah, leaving the infdev and back out of the article lacks uniformity, but if we don't split them it is the same boat, as most are split into separate articles, but a few bundled. To make it look less confusing, we could easily add a table in the pre-alpha sections, linking anchors and covering release dates, which would not only remove confusion, but add the missing condensed release date table. Overall though, this is still in the planning state, I do not have my heart completely set on it.
 * As for the Console edition stuff, really the only mess left with option 2 would be the mass content duplication (which is a significant mess nonetheless), and as even 4j does not have a consistent name for the version as a whole (the issue tracker calls one of the latest "0606" with a subtitle of each number), there is no way around that other than keeping the table. To prevent the merged article from becoming too long, we could move updates to subpages by year if needed. In any case, I would still at least like to get that better version history table for console, that could be useful in either format. <span class=nowrap>– · 04:28, 27 June 2015 (UTC)
 * Actually, I just wrote a sample page for the latest major update for Console Edition, . It only uses the Xbox 360 update name to prevent cluttering. Also the prevparent and prev (and vice versa) are made to have the bug fix updates in the middle, then the major updates on the side. It would show like this (using TU12 as an example): << TU9 < TU11 TU13 > TU14 >>. Tell me what you think of this. -- 15:49, 18 July 2015 (UTC)


 * So what would be done on a PlayStation or Xbox One exclusive article? The names would become inconstant if only some PS or Xbone versions are by their number, and the rest are by Xbox 360. (basically, the major thing keeping us back from the console edition split is the lack of a decent method for titling versions). <span class=nowrap>– · 19:42, 18 July 2015 (UTC)
 * I'd just add a section under the main TU page and add a note saying "Xbox One only"/"PlayStation only" in the article. -- 21:31, 18 July 2015 (UTC)


 * They are still separate versions though, so they should not only be covered or linked in the last Xbox version, they should fully exist in the navigation as their own version. <span class=nowrap>– · 21:46, 18 July 2015 (UTC)
 * We could name the pages "Console Edition Update (number)" then just add a note to them if the update applies to only Xbox One, Playstation, or Xbox 360? I'll try setting it up tomorrow in my workbench so I can show. -- 03:14, 19 July 2015 (UTC)
 * Here's the 3 articles in my workbench that I made for Console Edition..
 * There are a total of 42 updates on the version history pages (in order from TU1 to TU26/CU14/1.17). Update 42 has an Xbox 360 only sign to signal that it is an Xbox 360 only update. -- 22:27, 20 July 2015 (UTC)
 * I don’t like your idea, because it may get confusing, and I doubt it is used officially.
 * The mentioned GRAND RADION unauthorizedly (actually I allowed him in his question by mistake) made articles about console updates on Russian wiki, with the title format containing all version names split by / (see ), but I don’t like that either, because listing 2-3 version numbers is excessive.
 * If the same update is for multiple console editions, then I tend to be in favor of a specific edition’s version naming standard for article names. I first prioritize on Xbox 360’s standard (TUx), then PlayStation 3/4’s (x.y, like non-console editions), then Xbox One’s (CUx). —  14:16, 21 July 2015 (UTC)
 * I don't see how it is confusing? To avoid a messy title I name the article "Console Edition Update x", and I include a notification that says if it is Xbox 360, One or Playstation only. -- 14:49, 21 July 2015 (UTC)

It probably won't get confusing if you explain the version number system on the main page, but the main issue I see with your idea is that those version numbers aren't official. I strongly disagree with "inventing" version numbers just to make the version articles uniform. | 15:41, 21 July 2015 (UTC)
 * If that's the issue, then maybe we can just use a similar formatting to what GRAND RADION has done on the Russian wiki, but also possibly add my idea of the disclaimer on updates that are only on one edition or something. -- 16:02, 21 July 2015 (UTC)
 * @ any opinions/suggestions on this? -- 13:52, 22 July 2015 (UTC)

IRC channel
The wiki's IRC channel needs to be refurbished. Really, it has no operators, it even isn't registered on EsperNet. ,, , , ? &mdash; <span class=nowrap> (&#124;) 09:03, 26 April 2015 (UTC)


 * I'm guessing the IRC channel predates Curse's involvement with the wiki; I never use IRC and personally am not interested in doing anything with it. may be able to share more of the channel's history and provide a solution here, assuming anyone can finagle him into editing long enough to stop by and have a word. <span class="nowrap">「」· 03:13, 27 April 2015 (UTC)


 * I have used the IRC for a bit, and while the recent changes channel is a bit useful, the actual discussion IRC does not have much activity. Since I started using it over a year ago, I have only seen four posts: one almost a year ago when Quatroking was asking about the broken unblock function related to an incident a few days earlier, one from Fenhl a while back asking why a user was not blocked on the channel, one german post asking for someone to play survival with, and the hello from you. In all four cases, I did not notice the posts while actually online, but rather when I looked over the scrollback. There were likely some other posts since then, such as there was an IRC event I missed, but I think the current preference is to use the wiki for discussion, such as this page.
 * Basically, I have not seen enough interested people to refurbish it, but I would likely use it if it there were a bit more activity. <span class=nowrap>– · 16:20, 27 April 2015 (UTC)


 * I only used the IRC because Wyn used it. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 07:21, 29 April 2015 (UTC)

Bug descriptions controversy
Another edit war was sparked over by, who is known for insisting on using terrible bug tracker titles over proper, human-readable bug descriptions. We really need to have the guideline to use the latter be added to the style guide to solve this long-lasting bacchanalia. — <span class=nowrap> (&#124;) 15:33, 26 April 2015 (UTC)


 * - Majr and Orthotope's statements regarding the style guide:






 *  ( 15:43, 26 April 2015 (UTC)


 * And what? It will still also provide guidance in creating future version articles. — <span class=nowrap> (&#124;) 15:48, 26 April 2015 (UTC)


 * But what I said directly argues against what you were doing... <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 07:24, 29 April 2015 (UTC)


 * This really isn't worth edit-warring over. Again, I don't think we need to rewrite every bug tracker title, but I have no objection to improving the ones that are unclear or have terrible grammar.
 * Nick, keep in mind ; some of your comments have been very close to personal attacks. -- undefined 17:29, 26 April 2015 (UTC)


 * that a clarification in the should to be laid down affirming normal grammar, capitalization, spelling etc. in the bug titles. No argument so far has been put forth saying why bug tracker titles are immune to that section's rules for normal grammar, but people seem to be looking for some specific word on bug titles, and overlooking the general rule. At least that's my interpretation of what's happening. –   undefined/undefined 18:55, 22 May 2015 (UTC)


 * with Sealbudsman. – - 19:31, 22 May 2015 (UTC)


 * - What about this: We use the original bug tracker titles and put a question mark at the right of the issue title that when hovering the cursor over it shows "Corrected title: " ". Or also vice-versa; Use the corrected grammar and put the question mark that when hoevered over it shows "Original title: " ". I may draft these later. -- 22:52, 22 May 2015 (UTC)
 * My thinking is, why would we go to the trouble of being exact in documenting the bug tracker, when our purpose is to document the game? –  undefined/undefined 23:17, 22 May 2015 (UTC)
 * - Maybe people could spell out why they consider the exact original tracker title to be that important? I've been curious about that. –  undefined/undefined 23:17, 22 May 2015 (UTC)
 * We each have different opinions of what is ideal, for organizing and archiving puposes. I would prefer to use the original summaries, however, the majority of them a) are uninformative, b) use improper grammar, or c) Use A Styling Such As This. -- <span style='font: 6pt Zaptino'>(+) 23:47, 22 May 2015 (UTC)
 * ...were you trying to be humorous with the "grammer" thing? -- 23:53, 22 May 2015 (UTC)
 * prefer the titles, and also only really care about those exceptions you mentioned. –  undefined/undefined 00:03, 23 May 2015 (UTC)
 * There is no reason we have to have titles that were written which neither describe the issue, nor use proper spelling and grammar. As long as the title still describes the issue, while leaning on the side of being similar to the original title, there is no reason to not use it. We also have several new users correct spelling and grammar issues in the title, and reverting them because we declared the original titles "correct" is not only disruptive, but it will simply dissuade them from further contributions. I also agree there is no need to update every old tracker title to the style guide formatting. So if a guideline has to be added to stop the edit wars, it would simply need to state "Bug tracker descriptions in fixes sections of pages are not required to maintain the original title". Also, to those who want the original titles kept, may I ask why you believe so strongly they must be kept over slightly more helpful titles? Is that really worth fighting for? <span class=nowrap>– · 02:42, 23 May 2015 (UTC)
 * That is the reason why one IP decided to start rewriting them. This so called "guideline" has been quietly been in place for almost one whole year now, and now it gets crazy attention like its a fiesta?
 * First off, none of these reports need to be changed if the report title *makes absolute sense*.
 * Secondly, I literally don't know who the f**k decided to start up all of this bulls**t regarding tracker titles, but it has to stop. I literally can't stand every single time a bug tracker title gets rewritten because I'm autistic, and as such, am not used to sudden changes. There are still some people that literally don't know I have that condition. Heck, even NickTheRed37 explicitly stated that my condition was not a reason to revert text from a bug report to a "bad condition". Its literally been eating away at me throughout the past 4 months, and I wish people could have some more courtesy regarding the fact that I'm autistic.  ( 04:03, 23 May 2015 (UTC)
 * BDJP, respectfully, I think the reason we are bringing this up after a full year and haven't yet actually made a full decision on the matter is out of deference to your insistence on slow change on this matter. I don't see you being bothered by the literally  thousands of small and large changes across other parts of the wiki as it grows and evolves, so I'm not sure I totally get why this one thing evokes such a response.  This change, if actually implemented, will probably be one of the longest and slowest-implemented changes here I have ever, ever seen.  Hardly instant, hardly something you couldn't have prepared yourself for, hardly something you haven't seen coming in advance. –   undefined/undefined 05:05, 23 May 2015 (UTC)
 * BDJP, respectfully, I think the reason we are bringing this up after a full year and haven't yet actually made a full decision on the matter is out of deference to your insistence on slow change on this matter. I don't see you being bothered by the literally  thousands of small and large changes across other parts of the wiki as it grows and evolves, so I'm not sure I totally get why this one thing evokes such a response.  This change, if actually implemented, will probably be one of the longest and slowest-implemented changes here I have ever, ever seen.  Hardly instant, hardly something you couldn't have prepared yourself for, hardly something you haven't seen coming in advance. –   undefined/undefined 05:05, 23 May 2015 (UTC)


 * Rewriting titles is subjective and subject to further arbitrary rewrites by each generation of wiki editors (i.e., every year). Keeping the titles consistent with those on Mojang makes discussion and referencing easier and eliminates edit wars. Anybody who isn't sure what a bug title means can simply click on the bug link for further information. @Sealbudsman, to put forth the argument you pointed out was missing: Bug titles should be immune to the normal grammar rules because they are quotes from an official website (even if the titles were originally proposed by random people, they appear now on a Mojang news post). Quotes should be quoted precisely. @BDJP: Offensive language and bringing up your autism do not help your case. Wiki decisions are made by consensus and sometimes you're just going to be in the minority. &mdash; &middot;  &middot; 20:11, 23 May 2015 (UTC)
 * Munin, lots of people, me included, are not from English-speaking countries. And not everybody has good English. So for cases like this, I would go for a “wolves are full but sheep are alive” variant, that is having both the tracker titles and readable descriptions wherever needed. I may create a wiki extension for auto-populating bugfix lists that may have this feature. — <span class=nowrap> (&#124;) 13:27, 24 May 2015 (UTC)
 * Arbitrary rewriting the wiki has never a problem per se. It's also not quite as arbitrary as all that. It's still constrained to be accurate.
 * As for referencing, the tracker tickets have an indelible part, its numeric ID. If I wanted to discuss bug 5551, I would just need to link up, and it would be totally future proof without the need to be specific about the title. Maybe I am missing something you mean about making referencing and discussing easier?
 * As for quotes, the purpose of a Bug Fixes section in a version article is to firstly show the reader what has been fixed in that version. And to do that best, the bug should be well communicated. I'm not sure why our resource (the wiki) needs to be one where you need to click the link just to be able to understand what's going on. Also the blog post itself is a fine starting point, but we don't adhere to quoting it because inevitably they leave things out, and we have to free to be true to what's in the game, or else our article is less trustworthy than it could be. We also don't directly quote their changelog from their blog post (except as a starting point): we let all that be free for anybody to improve. –   undefined/undefined 13:58, 24 May 2015 (UTC)


 * Quite often, users will forgo an in-depth description because their summary fully describes the issue they are experiencing (i.e. 'Exactly what the summary says: xxxxxxxx'). If the summary uses improper grammar, it may evade the understanding of the majority of readers what the reporter is attempting to communicate, even if all information is there. In this case, we should most certainly use and alter the summary here on the wiki as we might any of Mojang's fixes that are not referenced to a bug report on their blog, Google+, ect.. -- <span style='font: 6pt Zaptino'>(+) 14:15, 24 May 2015 (UTC)


 * One question I would ask you is do you disagree with any changes to the title, or only changes that effect the wording? Do you agree with correcting typos, adding a bit of html formatting (code, cmd, italics, etc), and, provided the original words are still used?
 * In either case, while I understand your stance as them being quotes, I don't see the user's wording as relevant in this case. Unlike developer quotes, the actual meaning is definitely known so changing it is unlikely to be incorrect. The main question is will a user reading the bug fixes really be more benefited keeping the quoted "" rather then a rewritten summary "Minecart goes off track and into walls"? If the summary is able to adequately tell them what's fixed, why use the inadequate summary and force them to go to the tracker to understand the fix? <span class=nowrap>– · 23:01, 24 May 2015 (UTC)


 * any changes to the title.
 * Correcting typos:
 * HTML formatting:
 * Correcting spaces:
 *  ( 14:33, 31 May 2015 (UTC)
 *  ( 14:33, 31 May 2015 (UTC)


 * Why? . – - 14:39, 31 May 2015 (UTC)


 * - We should favor readability rather than a nonsense title. Some above are trying to negotiate limits (e.g. whether or not to correct titles, sentence case, readability, formatting etc), but I think there will continue to be more arguments if we set limits on what can and what can't be changed. For example, if we say that we can only change a title if it is not clear enough, where do you draw the line between complete garbage and a good title? What if it has some signs of readable sense, but could be improved to make it unambiguous? These are some more questions to ponder - where do we draw the line to changing text? What if we were to use the tracker title as a guide only and allow rewriting of the titles? <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  09:15, 27 May 2015 (UTC)


 * Here is my take on the issue: we make it so that all titles should remain identical unless they are either ambiguous and/or poorly formatted. We define the latter as simply not following the style guide, but not the ones that relate to the content per say, but rather the grammar and consistency aspects, this should keep the semantics intact. We define ambiguous as having more than one valid interpretation given the context of the wiki.


 * This should solve any and all contingency on the issue, thoughts? -- 03:27, 5 June 2015 (UTC)


 * I do like how you've tried to draw a line in the sand, but I don't think the lines you've drawn are really enough. One person may see there as being only one valid interpretation, others may see it to be more than one valid interpretation. What if the bug description is ok and unambiguous, but there could be a better way to phrase it? Where should we draw the line? Or is drawing any line at all too complicated? <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  05:23, 5 June 2015 (UTC)


 * Thank you for your feedback. You see the point of not having solid lines is to accommodate for the fact that people perceive things differently, so as I stated it, this acts as a lower bound on the acceptability of the titles, the laws of evolution specify that any gray areas should get ironed out, as long as you are dealing with reasonable persons, as it should since it is the what the entire wiki project is based on.


 * I disagree when they say we would have to revisit every single page containing a bug report; no, a better way of doing it is to just enforce for any new pages and don't discourage it for older pages if someone so chooses to, so the older pages won't update accordingly but that is not the whole point, the idea is to evolve even if we still keep many vestigial remains of past inefficiencies.


 * If it's unambiguous by the way, then it should just remain the same under any circumstances, it reduces the workload and it makes the bugs easier to search for in case the link fails. -- 08:39, 5 June 2015 (UTC)

New disambiguation icon
I recently uploaded an of the. I think that the version I uploaded is more visible and not so old-fashioned as the former/current one was/is. My upload however has been reverted by because I had uploaded "a new version of a critical file without consensus". (He however reverted without consensus, so... whatever.) I don't see a point in discussing every single edit or change in a huge discussion. I agree that it is a file which is transcluded in many articles, but I don't think that it would overload the server if you change a single file. (Reverting an upload actually does not overload the server in any way, does it?) However, I don't want to start an upload war, so what do you guys think? | 17:12, 26 April 2015 (UTC)


 * I think either one looks fine. The one you uploaded does have a bit better ratios between the shapes, and for the most part both colors look fine.
 * Since this is a minor change, I would say discussion is not required unless someone disagrees with the new version, it instead fits more under . <span class=nowrap>– · 21:08, 26 April 2015 (UTC)


 * I like this one better: http://hydra-media.cursecdn.com/minecraft.gamepedia.com/archive/f/fd/20150426154035%21Disambig_color.svg

15:31, 4 May 2015 (UTC)


 * I prefer the old icon. Please revert it. 21:06, 6 May 2015 (UTC)


 * I also prefer it. And don't urge to revert, until we get any eligible opposes in near future. &mdash; <span class=nowrap> (&#124;) 06:52, 7 May 2015 (UTC)


 * I prefer the old icon. – - 14:24, 7 May 2015 (UTC)


 * We should really make it an organized place for voting. (Votes are added into unordered lists. They should use c.) — <span class=nowrap> (&#124;) 17:35, 7 May 2015 (UTC)


 * Yes!! the old icon is back! – - 23:55, 22 May 2015 (UTC)


 * I only temporarily reverted it to the old version per . Lets keep the discussion going. -- 23:58, 22 May 2015 (UTC)


 * Your ping didn't work. – - 00:13, 23 May 2015 (UTC)


 * I prefer the 'old' blue/grey image. The red/blue one looks okay at large sizes, but I don't like the way it looks at 20px. I'm not a graphic designer, but I think it's too dark, with too much contrast between the red and blue. -- undefined 00:24, 23 May 2015 (UTC)

New icon

 * Here, you should give opinions on the new disambiguation icon.


 * Support
 * .  ( 19:12, 7 May 2015 (UTC)
 * . | 13:04, 11 May 2015 (UTC)
 * Oppose
 * Neutral
 * –. I don’t have eligible concerns about the new icon. However, this was an unilateral change of a critical image, that could provoke a big counter move. — <span class=nowrap> (&#124;) 17:35, 7 May 2015 (UTC)
 * It looks almost the same as the current disambiguation icon. Therefore, I can't see what the huge stink is about.  08:09, 11 May 2015 (UTC)

Old icon

 * Here, you should give opinions on the old icon.


 * Support
 * . — <span class=nowrap> (&#124;) 17:35, 7 May 2015 (UTC)
 * 22:36, 7 May 2015 (UTC)
 * . – - 22:42, 7 May 2015 (UTC)
 * Oppose
 * per .  ( 17:19, 16 May 2015 (UTC)
 * If you oppose per, I have to tell you that you are wrong. Please read . Plus, it doesn't have really much to do with the file aside the fact that someone just made a bold edit to it. -- 23:42, 22 May 2015 (UTC)
 * To me, the old icon doesn't fit in. Also, if we are going to upload a new version of the file, it should be smaller, as it is rarely used outside of text. 20:16, 22 May 2015 (UTC)
 * Neutral
 * . | 13:04, 11 May 2015 (UTC)

Random Page button on PC view
Can somebody add the random page button to the menu on the PC? It's on mobile, but not on PC. The link is: - 16:52, 2 May 2015 (UTC)


 * We removed the random page link because it frequently sends users to translation pages and non-articles (typically loaded subpages, such as Curse videos, block state pages, or circuit diagrams). It would be removed from the mobile view as well, but Extension:MobileFrontend is a bit stupid and doesn't have any way to customize the menu. -- undefined 17:42, 2 May 2015 (UTC)


 * Too bad :(
 * That feature is kind of useful, but very annoying. Maybe if somebody could design a better random page function, and if the mobile menu was better...

15:29, 4 May 2015 (UTC)
 * Some people might want to read a random page, but don't know about the  search. Add the random page button and possibly include a warning. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 16:46, 17 July 2015 (UTC)


 * I see no reason to include something that is basically broken just in case someone wants to try to work around the issue, especially since no one reads such warnings. Instead, it would be better to get some sort of working feature to replace it, such as . <span class=nowrap>– · 22:04, 17 July 2015 (UTC)

Missing texture
We should have an article about the. Also, the missing texture was changed to in 13w18a, so all missing texture images for 13w18a and later should be changed to the new missing texture. 20:01, 5 May 2015 (UTC)


 * , at the end. That is all there is to say about it (though you can add an image if you like). <span class=nowrap>– · 20:09, 5 May 2015 (UTC)

Template:List
There are some templates (such as :Renewable resource/row and Breaking row) that use Lua just because they have a list separated by commas. This is not necessary, there can be a template for it. The parameter would represent the input. Each comma (or whatever you set to) would separate each part of the list. The parameter would replace every   with whatever is used in the list. This template can be created using, so it doesn't require Lua.


 * Notes

A list with only numbers is not supported. Attempting to create such a list may result in not showing everything in the list, especially if the list is short. 21:11, 6 May 2015 (UTC)


 * Why do you dislike Lua so much? It can't be any less efficient (or harder to understand) than that mess of parser functions. -- undefined 01:33, 7 May 2015 (UTC)


 * It's not that. It's just that Lua is generally more difficult to work with, so we should only use Lua if standard wikitext is impractical. 03:11, 7 May 2015 (UTC)


 * I would consider that parser function spaghetti above (if it even works) a case where wikitext is impractical... And do you seriously consider that easier to work with than ? <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>  03:23, 7 May 2015 (UTC)


 * Majr@undefined You are right that the set of parser functions would be impractical. I had thought of a module previously. The code would be as follows:

local p = {} local content = args[content] function p.list (f) for v in mw.text.gsplit( content, '%s*,%s*' ) do		f=f..'' end return f end

return p
 * Note that this code wouldn't support custom ID's, but there would be some pre adjustments to the module. 13:33, 7 May 2015 (UTC)
 * The parser function won’t be parsed. It should be called via, which is still rather more complex than using just Lua anyway. — <span class=nowrap> (&#124;) 14:18, 7 May 2015 (UTC)
 * Actually, the parser function will work because it is returned, and whatever is returned is treated as wikitext. 14:34, 7 May 2015 (UTC)
 * I’ve to call a template like that, and it failed. — <span class=nowrap>  (&#124;) 17:36, 7 May 2015 (UTC)
 * No, it won't, because the returned value is wikitext after templates and parser functions have been expanded. Which is exactly why Scribunto provides frame:callParserFunction, frame:preprocess, and so on.  19:54, 7 May 2015 (UTC)


 * Even if that code was corrected, it also has the problem that any parameters to a template are phrased before they are passed on. For example, if you were to run blockSprite through that, it would first phrase as blockSprite, which will return the default missing sprite, then the module will try to replace any cases of  with the new value, which would be none as blockSprite already replaced   with positional values. It would still work in cases were the parameter is outputted without the template actually checking the parameter, but in those cases it would be more efficient to use   as I did in Block state table.
 * The only option other than Lua that will actually process a function are, which will allow you to loop a function. The main problem with them is they are limited to 100 loops per page, between all templates that use any of the functions.
 * Also, it might be relevant to note that breaking row's usage of Lua was because the original wiki code was terribly redundant and slow, the loops for the lists were a feature added after the conversion. <span class=nowrap>– · 20:31, 7 May 2015 (UTC)
 * The template can be achieved using, which might be more simple than a module. Please state your opinion. 23:02, 8 May 2015 (UTC)


 * In the few cases where  can be used for loops (which is currently only block state table), I don't see why a template would be needed as it would only use a single parser function to perform otherwise, especially since it would also be less flexible, as without the template you would have the option of sending multiple "parameters" through the single string, plus other formatting around the lists. <span class=nowrap>– ·  23:22, 8 May 2015 (UTC)
 * We have templates that are used because they require a format that someone might not think of (current examples are dablink and messsage Box. This template could be a similar purpose. 13:46, 9 May 2015 (UTC)


 * Both dablink and message box are used many times in templates to provide a consistent formatting, not so someone thinks of that format. There are many different "someone might find this useful" snippets, but there is not reason to create a template for each, especially when the code is so simply that it would make more sense to add it directly to the template. (This is also the reason I have several meta templates and useful code snippets sitting in my, of which none of them are currently required, so they are just there should someone else find and need the function). It is especially true in this case as all we are simply limiting a single parser function to one usage via a template. <span class=nowrap>– · 14:11, 9 May 2015 (UTC)
 * We can simply incude the wikitext in templates that use it. 16:52, 9 May 2015 (UTC)
 * We can simply incude the wikitext in templates that use it. 16:52, 9 May 2015 (UTC)

Minigame notability
Currently, minigames are considered notable if Mojang has claimed to play them (see ). The problem with that is there are many minigames Mojang has played, and some of them would be hard to cover in an article. For instance: <div class="plainlinks">
 * Marc was in the original video of SethBling's "Blocks vs. Zombies",[] as well as frequently plays new minigames for realms, all of which tend to require many command block implemented mechanics.
 * Both Grum and Dinnerbone have on several occasions joined MindCrack for their Ultra Hardcore deathmatch.[][]
 * Several mojang employees have been on several minigame servers. Dinnerbone has for example played both "Juice" and Survival Games on PlayMindcrack.

Basically I am proposing only allowing minigames which do not require plugins or excessive command blocks, leaving games such as or Ultra Hardcore, both of which require few to no commands for setup. It may also be relevant to only allow those minigames within tutorial articles, though minigames hardly seem like tutorial content directly (setting up maybe, playing strategies as well, but not general description). <span class=nowrap>– · 17:37, 19 March 2015 (UTC)


 * I don’t see the point of listing minigames at all. — <i class=nowrap> undefined/undefined (f.k.a. Naista2002) </i> 13:50, 24 April 2015 (UTC)


 * We could have a page called and minigames could be subpages. 23:06, 7 May 2015 (UTC)

Tutorials/Hiding resources
I think there should be a tutorial for hiding resources. Note that such a page has been deleted; an improved format is necessary. An ideal method would be for someone to create a project as a subpages for their user page. 02:47, 15 May 2015 (UTC)


 * The problem is the best hiding spot is the one no one would think to look, so if we document all the options, that ruins it :P In any case, if it is well written, I could see it as being useful, such as to describe the trick with the stairs to hide a chest in the wall or the trick to place a minecart with chest in a block.
 * As for an project page, I don't see why you cannot do that (assuming you have not logged in due to the login error, which seems to be fixed), or otherwise you could create a subpage of the to write the page before proposing it. <span class=nowrap>– ·  03:17, 15 May 2015 (UTC)

Snapshot banners
We should add a category for version banners and a subcategory for snapshot and pre-release banners. 03:46, 16 May 2015 (UTC)


 * I personally only think one category would be needed for the banner images. You should be fine creating it. <span class=nowrap>– · 14:36, 16 May 2015 (UTC)


 * . – - 21:48, 19 May 2015 (UTC)

Book watch icons
As most of you have noticed, the watch icons in no way fit the rest of the wiki's Minecraft theme, and the blue "watched page icon" very much blends in with the blue color of the tab. I would like to propose using Minecraft books for the watch icons instead, which I have been using personally since a bit before the icons were added in 1.23. The CSS can be found on my as the top for anyone wanting to test it (or make it better), and see here for an example of the icons. A few notes about the CSS:
 * The CSS uses one file for all four icons, with a  for the unwatched icon, a  for watched, and both are tinted the color of the  on hover, which are each slightly modified to make them more similar to each other. It could much more easily use a separate file for each icon, as I mainly kept them together for convenience of modifying.
 * The spinning star icon during the watching or unwatching segment is replaced with, which might need to use a separate system image should this get implemented.
 * I've reduced the padding a bit around the icon, partially by accident and partially because I like it better a bit smaller.

So, opinions on using the books icons instead of the stars? <span class=nowrap>– · 15:37, 16 May 2015 (UTC)


 * .  ( 17:17, 16 May 2015 (UTC)


 * . – - 17:29, 16 May 2015 (UTC)

<pre style="margin-left: 2.4em">
 * I would prefer that the width of the button won't change. It is too slim in my opinion, compared to the other buttons. Just change the padding and the background positions to:
 * 1) ca-watch+unwatch.icon a:everything - "padding: 14px 12px 6px 17px;"
 * 2) ca-watch.icon a - "background-position: 17px 15px !important;"
 * 3) ca-unwatch.icon a - "background-position: 1px 15px !important;"
 * 4) ca-watch.icon a:hover+focus - "background-position: 17px -1px !important;"
 * 5) ca-unwatch.icon a:hover+focus - "background-position: 1px -1px !important;"
 * 6) ca-watch+unwatch.icon a.loading - "background-position: 17px 15px !important;"
 * then it'll be as wide as before. (Shortened and simplified the code a bit so it's not taking up much space) | 18:13, 16 May 2015 (UTC)


 * I'd agree with keeping roughly the default width, and the values you added seem correct from my tests. <span class=nowrap>– · 19:26, 16 May 2015 (UTC)
 * I've bumped up the padding four pixels on either side, eight on both sides seemed to be a little much in my opinion. . <span class=nowrap>– · 03:26, 18 May 2015 (UTC)


 * . &mdash; <span class=nowrap> (&#124;) 07:25, 17 May 2015 (UTC)
 * . Using a book looks too much like bookmarking a page, which is not really the same as watching it. The tiny red band also does not make it obvious enough that it means that page is already watched. Additionally, all the icons should be a single image, rather than watching being separate. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 07:42, 17 May 2015 (UTC)
 * My browser does use star icons for bookmarking the pages, but I see your point as it makes the icon more likely to seem like a browser's or wikis bookmarks (though I do sometimes use my watchlist to mark a page quickly so I don't forget about it).
 * As for the red band: yeah, it's not a lot different from the "unwatched" book, but I personally find the bright red band to be enough to notice it is watched, as the color varies alot from the rest of the dark colored book.
 * As for the sheet, that does explain the slight blip while the image loaded, though I did not think of that back when I added the CSS... though I did expect the CSS would change a bit through this topic. <span class=nowrap>– · 03:26, 18 May 2015 (UTC)
 * use ender pearls and eyes? (The latter will be used when watching.) And, when clicking the button, the icon would fade from pearl to eye or vice versa. &mdash; <span class=nowrap> (&#124;) 07:47, 17 May 2015 (UTC)
 * Maybe it's possible to add a setting for that in ? Other than that, I like the idea of taking ender pearls and ender eyes. But what would the sprites for hovering over be? | 09:11, 17 May 2015 (UTC)
 * Maybe. For hovering, we can use lighter versions. For transitions, we can probably use 2 images at once (pearl below eye) with JS changing the transparency to give it a fade effect, and removing the "unneeded" image after finishing. &mdash; <span class=nowrap> (&#124;) 09:16, 17 May 2015 (UTC)
 * I just uploaded an enderpearl version of the stylesheet . Feel free to change it if you want. | 21:31, 17 May 2015 (UTC)
 * It does pretty good in my opinion. The colors have a bit more diversity that the books, and using an "eye" to represent watching should be easily recognizable. What would be used for the "loading" segment though? Blaze powder?
 * As for a setting for users to decide, I think it would be best left up to personal preference via CSS, partially because it seems very minor for a preference and partially due to Curse's preference of users using the same skin. Should either one be implemented, the more popular one would be used. <span class=nowrap>– · 03:26, 18 May 2015 (UTC)
 * See above. — <span class=nowrap> (&#124;) 14:44, 18 May 2015 (UTC)
 * I think it's reasonable not to use a javascript for this but to create a gif which would replace the book and quill (I also tried to create something with CSS for that but it didn't work). Other than that, we could use something like a clock to display that watching is in process. I also like KnightMiner's idea of taking blaze powder for that. I think it should be something like a enderpearl merged with blaze powder - I however don't really know how to do this. | 15:16, 18 May 2015 (UTC)
 * CSS does support fade animation of sorts using, though the problem I see with a fade effect is we have no idea how long it will take to watch or unwatch the page. A clock could work, though it does not fit as well with the ender pearls, and I cannot picture how the ender pearl and blaze powder would merge other than into an eye of ender. One last option would be spinning the ender pearl, similarly to the spinning of the star by default. <span class=nowrap>– ·  15:24, 18 May 2015 (UTC)
 * While the ender eye makes sense; if I was looking for the button to watch a page, I wouldn't think to click on an ender pearl... <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 09:43, 18 May 2015 (UTC)
 * If you don't know anything about MediaWiki yet and you are new to this wiki, you also don't directly think of "watching" a page when clicking on a star. A star could also be something like "favorite" or "marking as bookmark". I also think that the tooltip says everything, so if you don't know what the ender pearl means, you'll look at the tooltip. | 14:01, 18 May 2015 (UTC)

Category for inaccurate videos
I have noticed that over time many videos have become incorrect over time, and unless there are additional blocks added to the article, Curse does not seem to create updated videos. I am wondering if part of the problem is that they do not know which videos need an update, so I would like to ask: Would it be relevant to add a category for inaccurate videos?

As for how to add the category, I think the best option would be a template (something like video note) which adds the category and some standard formatting for the notes above the video. I've written a mockup [ here], which uses dablink as the standard formatting. It also adds the option to mark the inaccuracy as "minor" (which adds a subcat instead), for errors that are related to other articles content instead, such as on where it states outdated information about  and, or in cases where something is stated as "the only ..." where another one was added.

My main questions are would this be worth the trouble, and how would we inform Curse/MCSpotlights of the category(s)? (or assuming any of them read this topic, would you find this category useful?) <span class=nowrap>– · 16:11, 19 May 2015 (UTC)


 * . – - 16:22, 19 May 2015 (UTC)
 * . I'm certainly unsure. &mdash; <span class=nowrap> (&#124;) 06:11, 20 May 2015 (UTC)


 * - It would certainly help to see which are the videos are in need of updating. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  00:24, 23 May 2015 (UTC)


 * I created the template. If I am not too busy tomorrow, I will attempt to have my bot automatically add the template to pages, otherwise, I would advise simply adding it slowly while making other edits. <span class=nowrap>– · 04:39, 27 May 2015 (UTC)


 * Would your bot just detect if there is other text in the video section? <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  09:07, 27 May 2015 (UTC)


 * Basically. It also has to remove any previous formatting and the word "note" though. <span class=nowrap>– · 15:24, 27 May 2015 (UTC)
 * And done. It seems we have 38 inaccurate videos, five of which are minor errors. I may have missed a pages or two, but only if some sort of non-standard video page naming was done. <span class=nowrap>– · 15:46, 27 May 2015 (UTC)


 * Would the bot simply be able to see if there is any text at all in the Video section? That might mean that less videos are missed. Just after a quick search, I noticed that, and  are not in the category.  <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  09:23, 28 May 2015 (UTC)


 * It seems when I told it not to find video note in the text (so I don't add it twice), I forgot to tell it closing template brackets were allowed, and I also forgot to tell it newlines were allowed as part of the text. I ran it again with those errors fixed, and it seems those were the only cases of either error.
 * I just ran it again to check for notes below the video, but it seems got all of those. <span class=nowrap>– ·  16:20, 28 May 2015 (UTC)
 * You could just trash the bot and put a tag around a category definition as the content of the template, ex:


 * The makes it so that the template itself doesn't have the text (isn't in the category) but anything that uses it is. <span style="color: green; box-shadow: 0px 0px 5px green;">AwesomeMan31415926 (|) 11:08, 31 May 2015 (UTC)


 * I am not sure what you mean, the video note template already adds the category, the point of the bot was adding the video note template. <span class=nowrap>– · 14:18, 8 June 2015 (UTC)


 * Perhaps on the same note we can have a category for pages which are missing videos (e.g. ). <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  08:11, 8 June 2015 (UTC)


 * That would be relevant, though the category would have to be added manually on new pages, as there is no templatized way to check for a video. If no one objects, the categories could easily be added manually, or I could try to work up something to check for the video section. <span class=nowrap>– · 14:18, 8 June 2015 (UTC)

Banner patterns
I was thinking of a sprite sheet for banner patterns (maybe ), preferably with the patterns well organized. Once this is done, the sprite sheet would be used in, making it possible to display banners with multiple patterns. It would not be able to use because the images are not square, but the code is still possible (try substituting Module:Sprite using a random image and seeing what you end up with when you press "Save Page"). 19:08, 19 May 2015 (UTC)


 * Module:Sprite could be changed to allow non-square sprites. A separate banner module might make more sense, overlaying transparent sprites to create patterns. The sprite sheet will need 400 sprites if CSS transform trickery works properly, 624 if not. Before putting the effort into making that, I'm wondering if it would really benefit the wiki. Would this actually be useful anywhere other than vanity userpages? -- undefined 19:52, 19 May 2015 (UTC)


 * Why would you need non-square sprites if you are using it for grid? There is nothing wrong with a bit of whitespace in images as all other grid images are 32x32.
 * As for the overlays, I agree with Orthotope that there really is no place outside of the userspace where a banner builder is relevant, as a single pattern on white is enough to show the result of all the recipes.
 * The only reason overall to use a sprite sheet would be to reduce the number of images used, though it would be a pain to make the entire grid module use a sprite sheet. Just doing the banners would be slightly inconsistent, though doable. <span class=nowrap>– ·  03:40, 20 May 2015 (UTC)
 * Maybe you're right. What would be useful is the option to add text on top of an image (maybe by using a plus sign); we would simply need to do some adjustments to the banner-related aliases before getting rid of the banner patern images. Note that the number doesn't count because the module checks that it's a number from 2-999. Also, it might actually have a purpose: there is a section that shows combinations, and a reader might want to know how the player did it. Another possible usage would be a tutorial for custom banner patterns. 17:09, 2 June 2015 (UTC)

HESI Project = Discontinued?
Since the on the Highlighting Edition-Specific Information (HESI) Project, it has not been taken up by anyone. The creator of the project added a bunch of to gauge to progress of the project (similar to Rewrite for Style), though by now the categories are probably defunct. Unless anyone wishes to continue to project, we should probably get a bot to remove all of the added categories to simplify things a bit. -  22:49, 24 May 2015 (UTC)


 * The problem is we need someone who plays both the pocket and console editions to lead the project, or very well organized teamwork between a user who knows each, as a page can never be marked as "complete" until every edition is correct on that page. Since no one has taken up the project and it has done nothing in the two years since it started, I would agree with canceling the project for now and removing the unused categories. We can always start up the project again in the future and add the categories if there is enough interest in the future. <span class=nowrap>– · 23:13, 24 May 2015 (UTC)
 * may be a good candidate, if we can get him to re-focus on this wiki. &mdash; <span class=nowrap> (&#124;) 13:06, 25 May 2015 (UTC)

History for the Pocket and Console editions
While updating the history sections for older PE versions, I noticed that pages for certain key gameplay elements (e.g., , , and several others.) are lacking in history for the , , and s. All pages I listed here have dramatically different histories from the PC edition, making me wonder if this is intentional? - <span style='font: 6pt Zaptino'>(+) 13:53, 25 May 2015 (UTC)


 * I don't think it is intentional, it is just no one noticed among those who have played PE for long enough. Feel free to fix up the histories, either from you knowledge or from the version history pages. (if you need to search for occurrences of words among the pocket edition versions, describes some search parameters that might help, such as searching "health incategory:Pocket_Edition_versions") <span class=nowrap>– ·  15:32, 25 May 2015 (UTC)

Raw and cooked food
<div style="background-color: #efe; padding: 0 10px 0 10px; border: 1px dotted #aaa;">

The result of the discussion was do not merge.

I suggest merging each other, since cooked is basically just a different state of food. &mdash; <span class=nowrap> (&#124;) 11:59, 31 May 2015 (UTC)


 * Actually, it isn't. The actual are different. For, for instance, the value is 363 and the name is "beef". For , however, the value is 364 and the name is "cooked_beef". Even if this didn't matter, combining the usage sections is slightly awkward, at least for beef. Try combining them in a , and if you come up with something satisfactory and un-awkward to show us, then I might reconsider. (If we reach a yes consensus, then you can move it to  and ask for  and  to be deleted, then merge all the other raw and cooked.) <span style="color: green; box-shadow: 0px 0px 5px green;">AwesomeMan31415926 (|) 12:49, 31 May 2015 (UTC)
 * Players don't look for data values, it is mainly a deep-in-game factor. And states and just different data values of an item aren't the same. . &mdash; <span class=nowrap> (&#124;) 12:55, 31 May 2015 (UTC)
 * States mean the same data value but different block data, so of course "states and different data values of an item aren't the same." And by the way, the precedent of Sand and Red Sand doesn't say this should be merged, because Sand and Red Sand are the same but for the color and DV. Raw and cooked food behave differently, ex. you can't plant baked potatoes and cooked foods give more health. <span style="color: green; box-shadow: 0px 0px 5px green;">AwesomeMan31415926 (|) 13:44, 31 May 2015 (UTC)
 * Will you forget the data value argument any time soon? I wrote in black on white: “Players don't look for data values, it is mainly a deep-in-game factor.” For sands, see (yes, it is not about sand directly, but it is about sandstone). — <span class=nowrap>  (&#124;) 13:55, 31 May 2015 (UTC)


 * - Different food items with completely different properties.  ( 14:24, 31 May 2015 (UTC)
 * "I think that in merge/split discussions we shouldn’t rely on block [read: game element] characteristics alone. We should analyze the blocks from a player’s prospective, as this gives more info and, in result, more accurate statistics that will affect the resulting decision in a right way. Most users participating in these discussions don’t know that just yet. I know, this may not apply to sandstones, but I feel like this place is appropriate to say that."

- Me


 * — <span class=nowrap> (&#124;) 14:31, 31 May 2015 (UTC)


 * . – - 14:31, 31 May 2015 (UTC)
 * Unargumented voices don’t count. — <span class=nowrap> (&#124;) 14:35, 31 May 2015 (UTC)
 * Stop creating your own rules. – - 14:38, 31 May 2015 (UTC)
 * Where had I did so? It’s a general rule. — <span class=nowrap> (&#124;) 14:42, 31 May 2015 (UTC)
 * The "general rule" that you claim exists actually does not exist on the nor the .  ( 15:11, 31 May 2015 (UTC)
 * In short, why do you oppose? — <span class=nowrap> (&#124;) 14:43, 31 May 2015 (UTC)
 * Raw and Cooked food are different in usage (raw food can be cooked, unlike cooked food) and therefore also in player's point of view (according to my analysis, players are likely to view raw food as more of a cooking ingredient rather than actual food, while cooked food is likely to be mostly viewed as food.). -- 15:11, 31 May 2015 (UTC)


 * While arguably their different stats could likely be covered easily, both the obtaining and the usage differ greatly (raw can be traded, cooked, and drops more commonly, meanwhile cooked is better food and can be traded for). That basically leaves the only reason for merging to be the "similar state/title", which alone I do not believe is enough. <span class=nowrap>– · 20:33, 31 May 2015 (UTC)

food
I know this is beginner stuff but how do I eat food to restore my drum stick bar?```` –Preceding unsigned comment was added by ( • ) at 08:10, 4 June 2015‎ (UTC). Please sign your posts with
 * By default, hold right click to eat food. If you have changed your controls via the options menu, hold down the key which was set for "Use Item/Place Block". | 11:06, 4 June 2015 (UTC)

Council
Should the have a wiki council where users can discuss and vote on wiki stuff? --  01:46, 6 June 2015 (UTC)


 * The Minecraft Wiki is an open community - anyone can propose a suggestion to this page and generally actions are done based on consensus among its users. There's no need to have a council making these decisions - everyone can be involved in its development. <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">  02:40, 6 June 2015 (UTC)


 * You are thinking of . 02:59, 6 June 2015 (UTC)

File revert
Someone uploaded an incorrect version of a file, but I couldn't find file reverting in. How is a revert done? <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 13:46, 14 June 2015 (UTC)
 * The file revert button is contained in the file history. Go to the file’s page, scroll down, find a revert link in the row about the former correct version, click it, write in a description and click the button. —  13:53, 14 June 2015 (UTC)

Unregistered user talk pages
Should we allow unregistered users to have user talk pages. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 13:34, 16 June 2015 (UTC)


 * As long as they're not breaking the rules, why not? Sometimes it's the only way to attempt to communicate with someone who hasn't registered. &mdash; &middot;  &middot; 16:27, 16 June 2015 (UTC)


 * Talk pages are generally fine; sometimes it’s necessary to communicate with them, as Munin said. User pages are less tolerated. There isn’t an official policy on this, though; the closest I can find is the discussion at . — undefined 21:44, 16 June 2015 (UTC)

Anonymous user creation of pages
Can we just disable anonymous users creating pages? (or does Curse have something against that?) I have never seen an actually useful page made by an anonymous user, just spam pages and pages which are against policy or current practice (such as when the anonymous users spammed the "next snapshot" for PC, Pocket Edition version pages before the split was ready, and now apparently the console edition pages). We should still let them create talk pages, but require making an account to create pages, as if a user cares enough about the wiki to make an account, they are that much more likely to care about our policies.

I know spam bots won't be deterred by that, but I figure users with spam as their whole intention will likely be deterred as it is too much work to make an account just to make a spam article, and users who want to help the wiki will both be linked some policies upon account creation, and are more likely to stick to actually learn the policy.

I know a change like this has to be made by Curse, but I figure the community should decide before I suggest this to Curse.

<span class=nowrap>– · 04:04, 18 June 2015 (UTC)


 * .  ( 04:13, 18 June 2015 (UTC)
 * –  undefined/undefined 04:25, 18 June 2015 (UTC)
 * This can be done with the abuse filter, so it doesn’t necessarily need Curse to change the wiki configuration (though that might be the more elegant solution). There are some good contributions from anonymous users, but they tend to be casual edits – copyediting and such – rather than investing the time in creating entirely new, useful articles. I think this would prevent some spam and disruptive edits, but would not prevent useful contributions. — undefined 04:26, 18 June 2015 (UTC)
 * . &mdash;  06:37, 18 June 2015 (UTC)
 * Actually, I agree with Orthotope’s and Majr’s ideas. —  14:06, 21 July 2015 (UTC)
 * – <span style='font-family:Courier New' class='nowrap'> • 11:53, 18 June 2015 (UTC)
 * . – - 16:10, 18 June 2015 (UTC)
 * . - (&#124;)  17:55, 18 June 2015 (UTC)
 * . I support Orthotope's idea. --  15:58, 28 June 2015 (UTC)
 * . – <span style='font: 6pt Zaptino'>(+) 16:04, 28 June 2015 (UTC)


 * I think it is excessive to completely disable anon mainspace page creation. While a large percentage of anon-created pages are deleted or redirected, is it really too much to cope with that we need to prevent it entirely and lose out on a few acceptable pages that are created? Page creation already has quite high requirements to get past the filters in the first place. Only if there is an unmanageable amount of anon page creations being deleted per day (I see no evidence of this), should this be considered.
 * I think events like Minecon cause a general increase in vandalism and misguided edits, so rather than disable editing, we should instead enable stricter filters when necessary. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 17:32, 8 July 2015 (UTC)


 * If stricter filters is preferred, a case that would require stricter filters is around the time of snapshots. Every time an update goes into development, we get spam of "next snapshot" pages, often as a "template" for the update (as if somehow their 5 minute page cannot simply be created in five minutes the next day) or a "this is coming soon" page.
 * Basically all the filter needs to do is check some values such as the contents of the page (is additions/changes/fixes blank?) and the current date (is that snapshot number valid at this time?), and then display a warning or block creation entirely if those conditions return true (if only for anons). <span class=nowrap>– · 04:06, 29 July 2015 (UTC)


 * . - 21:40, 29 July 2015 (UTC)
 * Some "real" pages, especially tutorials, were created by unregistered users. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 21:18, 29 July 2015 (UTC)
 * Tutorials are generally considered one of the lowest quality sections of the wiki, and just because the article does not get deleted does not mean they did not abandon the article (there have been cases of an anon sticking around to write a decent tutorial, but those cases are rare) <span class=nowrap>– · 23:53, 29 July 2015 (UTC)

Typographical characters vs. typewriter characters
Should we (allow to) use typographical characters in place of plain typewriter ones? (Like “ and ” instead of ", and “—” or “–” instead of “-” where it is used as a dash.)

I’ve saw users reverting another user’s changes at not just due to vandalism, but to the usage of a typographical apostrophe “’”, and typographical quotes. I don’t think it is reasonable. Up until 1985–90 (as far as I know from reading, I wasn’t born then), when computers began to take a big role in typography, we had seen these characters much more often. Keyboard makers sacrificed the use of nicer characters for compactness, replacing quotes with a single ", apostrophes with ', dashes and minus signs with a hyphen -. This is now less of a problem in studios, but not among general people with personal computers.

Many of typographical characters are available in special characters section of the editing panel, so adding them is not too much of a problem. Plus some operating systems support key sequences involving special keys like Alt Gr or Compose.

—  14:39, 19 June 2015 (UTC)


 * Personally I'm in favor of it. I see these kind of edits as improvements, and not obligatory except that stylistically, it seems to me they should be consistent per-page.


 * Of course that would be subject to correct usage, like, using “–” as a hyphen would be wrong, using “—” for a numeric range would be wrong, and using curly quotes in prose would (as far as I can think) always be right, whereas using curly quotes in copy-paste sensitive environments like code samples or item names like jack o'lantern would be wrong... etc.
 * en-dashes and em-dashes feel more important to me than using curly quotes, but that may be just me. So those are my thoughts.
 * –  undefined/undefined 15:19, 19 June 2015 (UTC)


 * I basically have the same opinion as Sealbudsman: I say we should use en and em dashes, as there is no reason not to. The curly quotes I would also agree to using in most cases, though they should definitely be avoided in code samples.
 * As for the typographical apostrophe, I personally see no point for that one except in cases as opening and closing quotation marks in nested quotes. In names like "jack o' lantern", and possessives (along with contractions, though technically the style guide advises against those) I would stick to plain old apostrophes, mainly because they are easier to type. I also prefer them because I think Minecraft item names should at least use the same character as in game, rather than switching to the Unicode version, and using it in all non in-game name cases would just be inconsistent. <span class=nowrap>– · 18:21, 19 June 2015 (UTC)


 * Tangential question: I just noticed you using curly apostrophes on this talk page; do you do that intentionally, or do you have some kind of a plugin for it? –  undefined/undefined 18:45, 19 June 2015 (UTC)


 * My knowledge may be a bit out of date, but there used to be problems with using such characters because they were encoded differently on different systems and thus an em dash entered from one system might display as a junk character on another system. Instead we would use character entities like "&amp;mdash;" that could be converted on-the-fly by the displaying system. I still see junk characters on some webpages occasionally but these may be from early uploads—in general have these problems been overcome by modern web browsers or wikimedia code? &mdash; &middot;  &middot; 19:16, 19 June 2015 (UTC)


 * That seems to be fixed as far as I can tell. MediaWiki automatically converts unicode characters if it detects your browser cannot support them. See . <span class=nowrap>– · 19:35, 19 June 2015 (UTC)


 * The thing you might be seeing with old websites is that they set their character set in a  tag in the page head to be something like latin-1, rather than utf-8.  This site is utf-8, the whole way through, looks like. –   undefined/undefined 19:40, 19 June 2015 (UTC)


 * If you were talking to me, then I used them since a while ago. I generally use the Compose key to get them. &mdash;  06:32, 20 June 2015 (UTC)


 * Yes I was - thanks, I was just curious. –  undefined/undefined 15:15, 20 June 2015 (UTC)


 * I disagree. While they may be more typographically correct, they don't look fitting with a sans-serif font, and they have poor readability at the font size used here compared to normal ones. At the very least, an article should use all typographical quotes (where appropriate) or none, not a mix. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 02:28, 20 June 2015 (UTC)
 * I increased my browser&rsquo;s scale for this site, so for me it isn&rsquo;t much of a problem. &mdash;  06:32, 20 June 2015 (UTC)


 * Good for you, but we can't expect everyone who uses this site to zoom in to read it properly. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 06:37, 20 June 2015 (UTC)

Plans for Minecon 2015
Good morning, , , , , , , , , , and  (feel free to tag anyone else).

AYMK, Minecon 2015 is upon us (1 week from today, actually), and for the past few hours I've been thinking about how we can inform users regarding what articles will be affected by the event, and I've come up with two possible options.

Option 1: Use a meesage box (or a notice) on the main page to inform any / all users that any / all articles may be effected by the convention taking place (see below).

Option 2: Use a message box on certain articles where information is expected to change rapidly (,, etc. ; see below).

Thoughts?  ( 15:55, 27 June 2015 (UTC)


 * . Also please add digits back to your signature, or else it’s too short. —  16:53, 27 June 2015 (UTC)


 * : How much really does change from MineCon? For the most part, we just get additional sources (some containing new features) for articles such as, I doubt much content would be removed, thus all the changes are additive. Plus, those articles are already expected to rapidly change since they are about planned versions. Overall, we really could end up with a lot of new information, or nothing, but hardly breaking changes, especially due to . <span class=nowrap>– · 17:45, 27 June 2015 (UTC)


 * . The first one would be more efficient than the second one. But I'm okay with it. --  21:34, 28 June 2015 (UTC)


 * Good evening, I the first one, because who really knows what else they might reveal at Minecon, it could be anything.  Like KnightMiner says, it sort of goes without saying that the wiki could update with new info at any moment -- but as a gesture of acknowledgement of Minecon itself, it seems fine and appropriate to me. –   undefined/undefined 03:28, 29 June 2015 (UTC)


 * I don't like either of these, nor the general idea of marking up specific articles as potentially changing due to new info revealed at Minecon, since literally anything could be revealed. If we insist on notifying readers of the possibility, I would instead suggest a sitenotice, but personally don't see the point to any notification at all; whatever notice of Minecon's occurrence that will inevitably be added to the main page or wherever else should be enough in my opinion. <span class="nowrap">「」· 07:10, 29 June 2015 (UTC)