Talk: Community portal

This is the community's main discussion page.
Talk about anything wiki-related here!
Sign your posts with ~~~~, add new posts below others, and click "Add topic" above for new topics.
Note that this page is NOT for suggesting new ideas about the game. That belongs on the forums.

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 sign unsigned comments 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. Rule #5 (it relates to talk pages, it would be a good idea to have mention of it so it is all in the same spot)
7. Rule #22, possibly with some extended guidelines on signatures (such as excessively larges files and text, this rule could theoretically be migrated to the page)
8. That one thing I'm forgetting, and someone will remind me of in a reply (just so I covered everything)

–KnightMiner · talk 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.

–Nick the Red³⁷ — ru.wiki moderator (talk) 06:57, 15 January 2015 (UTC)

Here is a link to a proposed page with such guideline listing. Feel free to correct things or leave suggestions on the pages content.

@NickTheRed37: Thanks, I knew I was forgetting something.

–KnightMiner · talk 23:31, 15 January 2015 (UTC)

So... –KnightMiner · talk 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.

—munin · · 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 MCW:Wiki rules is not editing other people's comments.

–KnightMiner · talk 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, Knight), 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. –KnightMiner · talk 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 [[User:Munin295|Bob]] starts getting confusing. Not including a link is questionable at best – Wikipedia actively prohibits it – and I don't see any reason why one person's signature should link to another person's userspace. -- Orthotope^talk 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). –KnightMiner · talk 05:11, 18 February 2015 (UTC)

1. 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. –Majr ᐸ Talk
Contribs 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 Goandgoo's signature. –KnightMiner · talk 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. Link to the proposed guidelines.

It may also be relevant to use the MediaWiki:Sitenotice 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) –KnightMiner · talk 15:58, 21 February 2015 (UTC)

1.  Agree.
2. 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 Nick the Red³⁷ (talk · contribs) 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. –KnightMiner · talk 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). –Majr ᐸ Talk
Contribs 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.

–KnightMiner · talk 00:53, 22 February 2015 (UTC)

So, any more points/guidelines to discuss before implementing? Otherwise, I will implement it shortly. –KnightMiner · (t) 17:03, 7 March 2015 (UTC)

If there is, it can't be anything important or someone would've thought of it by now. –Majr ᐸ Talk
Contribs 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 #Reform the style guide and wiki rules.

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 MCT:Wiki rules/Archive 1#Talk page rules (specifically editing the main topic without noting it, and removing old sections other than for archiving. –KnightMiner · (t) 04:42, 14 March 2015 (UTC)

Minecraft texture for blue boxes

Following up the previous topic (#New texture for blue bars and boxes?), where I mentioned a lighter stone color for the blue boxes. I applied a texture like that to Minecraft Wiki/editcopy, 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). –KnightMiner · talk 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. -- Orthotope^talk 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 MCW:Community portal) –KnightMiner · talk 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. -- Orthotope^talk 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. –Goandgoo ᐸ Talk
Contribs
Edits 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). –KnightMiner · talk 14:55, 26 January 2015 (UTC)

White text on dirt might be reasonably readable. -- Orthotope^talk 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 test page (compare: former (darker) version). I also blurred the background file so you can read the white text better. | violine1101^(Talk) 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. –KnightMiner · (t) 16:59, 2 March 2015 (UTC)

Maybe use wood planks texture? ru:Обсуждение:Заглавная страница/Копия#Каменный фон заголовков, ru:Заглавная страница/Копия, ru:Файл:Фон заголовков заглавной.png, ru:Файл:Фон заголовков заглавной 2.png, ru:Файл:Фон заголовков заглавной 3.png — NickTheRed37 (former Naista2002) (talk) 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. –KnightMiner · (t) 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). | violine1101^(Talk) 19:43, 2 March 2015 (UTC) Edited 19:45, 2 March 2015 (UTC)

The Korean wiki already uses changed headers: ko:마인크래프트_위키. I just wanted to add that, form your own opinion. | violine1101^(Talk) 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))

Markus Persson/editcopy?

Everyone probably knows this message box by now:

Surprisingly, why is there no editcopy version of Markus Persson? 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. -- Orthotope^talk 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. –KnightMiner · talk 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 mw:Extension:Approved Revs? 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. –Majr ᐸ Talk
Contribs 02:24, 3 March 2015 (UTC)

That could work, and I  Agree. BDJP ^(t|c) 14:29, 26 April 2015 (UTC)

Fair enough, but it may appear to be redundant.  0.5–0.6. —  NickTheRed37 (talk|contributions) 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. –KnightMiner · (t) 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. –Majr ᐸ Talk
Contribs 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. –KnightMiner · (t) 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. –Majr ᐸ Talk
Contribs 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. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 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. - MinecraftPhotos4U (talk) 19:14, 30 January 2015 (UTC)

Even if I see it as useful, I don’t feel like it should be added. I’m Nick the Red³⁷, f.k.a. Naista2002 19:21, 30 January 2015 (UTC)

 Comment 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. –KnightMiner · talk 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. -- Orthotope^talk 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:

• Style guide
  • 
     Mostly contains the current style guide, minus the layout sections. This change was implemented on 15:54, 20 February 2015 (UTC)
  • The section "Section headings" links to the general sections. The section "Article layout" was kept to link to the subpages.
  • 
     The section "Notability" comes mostly from the wiki rules, except General 4 and 5, which are from the style guide's future section/#Unimplemented, mentioned, and upcoming features This change was implemented on 17:48, 23 February 2015 (UTC)
    • 
       Notability's wiki rules are duplicated from the remaining rules. They are mainly there so all the information is in one place.
  • 
     One of the current wiki rules was moved to the section "Images" (previously "Image captions") This change was implemented on 17:48, 23 February 2015 (UTC)
  • "Article titles" general title format is entirely based on general practice.
• Style guide/General features Page was moved to MCW:Style guide/Features on 15:54, 20 February 2015 (UTC)
  • 
     Contains the general sections for the most part copied from the current style guide.
• Style guide/Versions
  • 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).
• Wiki rules Implemented at 00:49, 2 March 2015 (UTC)
  • 
     Will contain stuff that is block worthy, rather than just any random policy we want to list (except maybe what would be rule #7).
  • 
     Removed all the rules that are now within the style guide.
    • 
       The note about the userspace was moved as well, as now all the rules are required in the user space (except where noted)
  • 
     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 #Talk page guidelines)

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.

–KnightMiner · talk 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. –KnightMiner · talk 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 High-functioning autism a.k.a Asperger's syndrome a.k.a "Autism Level 1" (kudos to Holtz 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 Majr edited a tracker title on 1.4.6. NickTheRed 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. -- Orthotope^talk 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. –KnightMiner · talk 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. –Majr ᐸ Talk
Contribs 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:

1. 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.
2. "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.
3. 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.

–Majr ᐸ Talk
Contribs 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 #Unimplemented, mentioned, and upcoming features.

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.

–KnightMiner · talk 05:30, 18 February 2015 (UTC)

A similar idea for article-specific style guides is used in work-in-progress Russian wiki's style guide. It uses a tree layout for them, and links to avoid duplicate information. — Agent Nick the Red³⁷ (talk · contribs) 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. –KnightMiner · talk 16:31, 18 February 2015 (UTC)

The article structure section on that style guide is here. 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. — Agent Nick the Red³⁷ (talk · contribs) 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. –KnightMiner · talk 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 MCW:Wiki Rules, archiving the current rules?

Since rules 18 and 22 are likely to get moved soon due to #Talk page guidelines, 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. –KnightMiner · talk 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 here)

In any case though, something needs to be done with the wiki rules to finish this discussion, and the rules are administrator protected. –KnightMiner · (t) 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 tooltip for it. –Majr ᐸ Talk
Contribs 09:27, 1 March 2015 (UTC)

MediaWiki:Deletereason-dropdown 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 notability", 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. –KnightMiner · (t) 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. –Majr ᐸ Talk
Contribs 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 Herobrine. 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.

–KnightMiner · (t) 02:33, 3 March 2015 (UTC)

 Done. Once the guidelines are all in place, we should probably put up a site notice about the rule and guideline changes. –Majr ᐸ Talk
Contribs 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. –KnightMiner · (t) 04:30, 3 March 2015 (UTC)

Fixed. –Majr ᐸ Talk
Contribs 04:46, 3 March 2015 (UTC)

The remaining two things have been moved to MCT:Style guide#Following up, as well as a few other minor proposals. –KnightMiner · (t) 23:45, 4 March 2015 (UTC)

Indestructible blocks

Do you think a Category:Indestructible blocks would be useful? This category is for blocks that cannot be broken in Survival mode. 108.210.219.49 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 Hardness#Blocks by hardness and see all the blocks that cannot be broken by hand. –KnightMiner · talk 16:50, 12 February 2015 (UTC)

Uh...what about explosions? For example, Nether Portal blocks are destructible by explosions (blast resistance 0). Therefore, the Hardness#Blocks by hardness is not a reliable list, since it would make you think Nether Portal blocks are indestructible, even by explosions. AwesomeMan31415926 (talk) 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 Category:Indestructible blocks. AwesomeMan31415926 (talk) 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). –KnightMiner · (t) 15:07, 11 May 2015 (UTC)

 Oppose If not by Hardness#Blocks by hardness, then also by Explosion#Blast resistance. Also, unilateral controversial changes are forbidden. —  NickTheRed37 (talk|contributions) 06:46, 11 May 2015 (UTC)

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

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

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

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

New administrator

1, 2, 3. 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 KnightMiner 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.

— Agent Nick the Red³⁷ (talk · contribs) f.k.a. Naista2002 13:55, 20 February 2015 (UTC)

KnightMiner, Majr, Dinoguy1000, JEC6789, LauraFi, Orthotope, BDJP007301, Goandgoo, GreenStone, ToonLucas22, Munin295? — NickTheRed37 (former Naista2002) (talk) 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 –KnightMiner · (t) 18:46, 2 March 2015 (UTC)

 Promote: 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 IKJames, Hower64, and Kanegasi for example, who have been inactive since 2011 and 2013, respectively. I think we could promote a few more admins if need be. BDJP007301 ^(t|c) 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. -- Orthotope^talk 04:18, 11 March 2015 (UTC)

 Agree It has sometimes puzzled me why KnightMiner isn't an admin. 71.212.10.80 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 Talk:Planned versions regarding 0.11.0 being split into a new article (before it got too big) a short while ago and Knight 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? BDJP007301 ^(t|c) 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. –KnightMiner · talk 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.71.35.109.25 19:37, 22 February 2015 (UTC)

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

This was discussed a year ago, see Talk:Granite#Merge with Stone. 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 Talk:Red Sandstone to merge with Sandstone, 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. –KnightMiner · talk 00:01, 23 February 2015 (UTC)

How about decoration stone.71.35.109.25 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. –KnightMiner · (t) 15:39, 28 February 2015 (UTC)

Account

I attempted to create an account, but I do not have an email.67.160.25.176 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. –KnightMiner · talk 00:10, 24 February 2015 (UTC)

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

See gphelp:Logging in#Why log in? (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. –KnightMiner ^t/_c 03:41, 24 February 2015 (UTC)

What happens if you try to use someone else's email address?71.35.109.25 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. –KnightMiner · (t) 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.71.35.109.25 02:30, 26 February 2015 (UTC)

Actually, I do have email. Does it matter what website an email address is using?71.35.109.25 00:11, 8 March 2015 (UTC)

It shouldn't, any site should work, provided its a valid email address (name@website). –KnightMiner · (t) 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... • ObelusPA2 ^d · FR Admin · 14:37, 4 March 2015 (UTC)

Ask Citricsquid via email. — NickTheRed37 ^t ⁄_c (f.k.a. Naista2002) 14:41, 4 March 2015 (UTC)

Try asking VaultAusir, see Special:Diff/631033. –LauraFi - talk 14:46, 4 March 2015 (UTC)

https://minecraft.net/community , under 'Official Resources'. -- Orthotope^talk 15:51, 4 March 2015 (UTC)

Thank you ! • ObelusPA2 ^d · FR Admin · 17:47, 4 March 2015 (UTC)

Periodic Table

I think there should be a page that shows the periodic table of Minecraft.71.35.109.25 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. –KnightMiner · (t) 16:50, 7 March 2015 (UTC)

Non-renewable creative mode items

I disagree with including creative mode items in Category:Non-renewable resources, 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? PhilHibbs (talk) 14:44, 11 March 2015 (UTC)

Minecraft Wiki:Projects/Categorization — NickTheRed37 ^t/_c (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. –KnightMiner · (t) 16:19, 11 March 2015 (UTC)

They technically count because you can't get them in Survival. 108.216.28.48 00:07, 13 March 2015 (UTC)

 Done I have added a Category:Blocks unobtainable without Creative as a subcategory of Category:Non-renewable resources. –Preceding unsigned comment was added by AwesomeMan31415926 (talk • contribs) at 6:54, 11 May 2015 (UTC). Please sign your posts with ~~~~

Don't do controversial actiobns unilaterally. —  NickTheRed37 (talk|contributions) 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. –KnightMiner · (t) 15:12, 11 May 2015 (UTC)

The category is now pending deletion. –LauraFi - talk 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. 108.216.28.48 00:12, 13 March 2015 (UTC)

File:Lockedchest13w18b.png. I don't think we need an entire page for it, but it could be mentioned at Resource pack. -- Orthotope^talk 00:35, 13 March 2015 (UTC)

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

Nmoleo64 (talk) 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?Contrapple (talk) 13:30, 13 March 2015 (UTC)

Go to Special:Preferences. | violine1101^(Talk) 14:00, 13 March 2015 (UTC)

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

In Special:Preferences, 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. BDJP ^(t|c) 14:29, 13 March 2015 (UTC)

Can't change my signature correctly

I attempted to change my signature using ~From Contrapple [[User:Contrapple/List of pages|{{ItemSprite|Empty Map}}]]. However, when I saved my preferences, "SUBT:" was automatically added just before the word "ItemSprite", which messed things up. How can I fix this?Contrapple 03:01, 14 March 2015 (UTC)

Templates aren't allowed in signatures. –Majr ᐸ Talk
Contribs 03:06, 14 March 2015 (UTC)

I tried using the file and got ~From Contrapple [[User:Contrapple/List of Pages|File:Map (Item).png ]] 03:21, 14 March 2015 (UTC).

You can't put files inside links. Use |link=. –Majr ᐸ Talk
Contribs 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 File:Map (Item).png 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. –KnightMiner · (t) 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. –LauraFi - talk 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 Special:Preferences#mw-prefsection-echo and select the 'Email me when a page or file on my watchlist is changed' option. -- Orthotope^talk 00:02, 15 March 2015 (UTC)

Help pages

How relevant are the help pages to keep, since gamepedia has a whole wiki devoted to general help? Most of the help pages here are barely touched, with many outdated, and this edit by Cblair91 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 Help:Official sources and Help:Schematic.

–KnightMiner · (t) 01:45, 16 March 2015 (UTC)

And add missing wiki-specific help pages. I once made one for infoboxes (on Russian wiki) -_- — NickTheRed37 ^t/_c (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). –KnightMiner · (t) 15:33, 16 March 2015 (UTC)

Smilies

On Russian wiki, there is a template for inserting graphical smilies into the text. I would like to also have that template here. Any objections/concerns? — NickTheRed37 ^t/_c (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 . -- Orthotope^talk 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. — NickTheRed37 ^t/_c (f.k.a. Naista2002) 15:47, 21 March 2015 (UTC)

Either way, I need to ask Ivan-r. — NickTheRed37 ^t/_c (f.k.a. Naista2002) 16:02, 21 March 2015 (UTC)

GNU General Public License. — NickTheRed37 ^t/_c (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. –KnightMiner · (t) 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)

mw:Help:System message –KnightMiner · (t) 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 User:KnightMiner/Workbench/User pages. 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...) –KnightMiner · (t) 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." —munin · · 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 talk page guidelines, 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, Majr mentioned disallowing deletion of comments, 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.

–KnightMiner · (t) 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.? —munin · · 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) –KnightMiner · (t) 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) –KnightMiner · (t) 03:44, 25 April 2015 (UTC)

Finally...  Permanent support. — NickTheRed37 ^t/_c (f.k.a. Naista2002) 09:04, 25 April 2015 (UTC)

 Agree. –LauraFi - talk 11:47, 25 April 2015 (UTC)

 Strong and permanent opposition - BDJP ^(t|c) 12:54, 25 April 2015 (UTC)

Punishment is not an argument. — NickTheRed37 ^t/_c (f.k.a. Naista2002) 12:56, 25 April 2015 (UTC)

Do I have the word "punishment" anywhere in that sentence? BDJP ^(t|c) 13:11, 25 April 2015 (UTC)

No, but I feel that you oppose due to punishing me anyway. — NickTheRed37 ^t/_c (f.k.a. Naista2002) 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 wiki rules.
• 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). BDJP ^(t|c) 13:41, 25 April 2015 (UTC)

1. Rules are not ideal, and may be corrected if needed.
2. 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 forbids it.

— NickTheRed37 ^t/_c (f.k.a. Naista2002) 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 proposed guide 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. –KnightMiner · (t) 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 me. With that, I still hold a  Strong Oppose. BDJP ^(t|c) 16:43, 25 April 2015 (UTC)

 Oppose 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. —munin · · 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 this user's page? 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. –KnightMiner · (t) 18:09, 25 April 2015 (UTC)

User talk:Lhs970317#User:Lhs970317/Pocket Edition version history —  NickTheRed37 (talk|contributions) 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. –KnightMiner · (t) 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 User:Anomie x/Materials. If anyone would like to look that over, I'd appreciate it. Anomie x (talk) 03:04, 12 April 2015 (UTC)

I see a few minor errors, such as you used "Grass" instead of "Grass Block" 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 Materials? (If unsure of what I'm referencing, see here) –KnightMiner · (t) 03:46, 12 April 2015 (UTC)

Please feel free to make any necessary edits. Materials would be a good title for it, yeah, in which case the existing article could move to Raw materials which is currently a redirect with no incoming links, but that'd need admin help to take care of. Anomie x (talk) 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 Materials 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). Orthotope then pointed out that Category:Raw materials already contains the same pages and suggested instead of deleting the page to replace it with an article about Minecraft's internal materials. –KnightMiner · (t) 00:35, 13 April 2015 (UTC)

Works for me, I overlooked that conversation when I checked that talk page. Anomie x (talk) 11:23, 13 April 2015 (UTC)

Shortcuts for to Minecraft Wiki pages

Following up MCT:Community portal/Archive 15#Minecraft Wiki namespace shortcuts, 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:

Name	Target	Notes
MCW:RULES MCW:RULE	MCW:Wiki rules	The latter would allow simple but readable linking to a rule, such as like MCW:RULE #1, but would be unneeded if the page gets moved to MCW:Rules.
MCW:TALK	MCW:Talk page guidelines
MCW:PORTAL	MCW:Community portal
MCT:PORTAL Maybe MCT:CP	MCT:Community portal	Linking topics slightly easier, especially in the case of the latter
MCW:STYLE Maybe MCW:SG	MCW:Style guide
MCW:NOTABILITY MCW:NOTABLE	MCW:Style guide#Notability	For the sake of deletion proposals. Might be useful for redirects based on notability sections.
MCW:IMAGES	MCW:Style guide#Images	I link this section often when cleaning up galleries
MCW:HISTORY or MCW:UPTODATE	MCW:Style guide#Keeping articles concise and up to date	Really long section title, for a frequently referenced rule. I am not so sure about the name for this one though
MCW:FUTURE	MCW:Style guide#Future
MCW:LAYOUT	MCW:Style guide#Article layout
MCW:FEATURES	MCW:Style guide/Features	Since the subpages are somewhat longer as far as titles, this would be useful for linking sections such as the trivia

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. –KnightMiner · (t) 19:58, 16 April 2015 (UTC)

I would be in favour of those suggestions, as well as perhaps one for the admin noticeboard. –Goandgoo ᐸ Talk
Contribs 04:43, 18 April 2015 (UTC)

That would make sense, though the best I can come shortcut I can think of is MCW:ADMINS or MCW:ADMIN (ex. if you need administrative help, ask the MCW:ADMINS? It would be slightly inconsistent with MCW:Administrators leading to MCW:Directors). Otherwise, we could copy the shortcuts from wikipedia and end up with MCW:AN or MCW:ANB, though they are hardly descriptive. –KnightMiner · (t) 00:00, 19 April 2015 (UTC)

I do think MCW:ADMIN 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 MCW:AN or MCW:ANB seem very intuitive... –Goandgoo ᐸ Talk
Contribs 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. –KnightMiner · (t) 17:27, 25 April 2015 (UTC)

Ok, but why are they all uppercase? They're not abbreviations. –Majr ᐸ Talk
Contribs 07:25, 29 April 2015 (UTC)

Perhaps for the same reason they are uppercased on Wikipedia. —  NickTheRed37 (talk|contributions) 09:27, 29 April 2015 (UTC)

Which is? –Majr ᐸ Talk
Contribs 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 WP:BOLD. 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 mcw:style" or "refer to MCW:STYLE", (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. –KnightMiner · (t) 15:34, 29 April 2015 (UTC)

I hate the MCW:RULE shortcut. I feel like we shouldn't sacrifice readability for efficiency that much. —  NickTheRed37 (talk|contributions) 06:52, 11 May 2015 (UTC)

 No. We can just use piped links. [[Special:MyPage/Sandbox|Visit your sandbox now]] -> Visit your sandbox now. –Preceding unsigned comment was added by AwesomeMan31415926 (talk • contribs) at 11:14, 31 May 2015‎ (UTC). Please sign your posts with ~~~~

First, this is already implemented. Second, noone wants to write [[Minecraft Wiki:Wiki rules|rules]] if they can write [[MCW:RULES]]. | violine1101^(Talk) 14:55, 31 May 2015 (UTC)

Version pages

Reviving discussions from here and here

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 Pocket Edition development versions page, it is starting to get very cluttered with new versions being added. These would need additional support for multiple editions. –Goandgoo ᐸ Talk
   Contribs 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.

–KnightMiner · (t) 19:31, 18 April 2015 (UTC)

I think the table we have at/on/in(?) the German wiki (de:Konsolen-Versionsgeschichte) 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 Console Edition version history 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. | violine1101^(Talk) 22:50, 18 April 2015 (UTC)

While what you have there Violine1101 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? –Goandgoo ᐸ Talk
Contribs 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. –KnightMiner · (t) 01:00, 20 April 2015 (UTC)

Absolutely agree with removing {{Minecraft}} from the version articles. — NickTheRed37 ^t/_c (f.k.a. Naista2002) 11:30, 20 April 2015 (UTC)

Would KnightMiner or Majr 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. –Goandgoo ᐸ Talk
Contribs 06:33, 29 April 2015 (UTC)

Does pocket edition not have the same issues of multiple platforms as the console edition, though? –Majr ᐸ Talk
Contribs 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: I'll start messing with the {{version nav}} template in my sandbox to see about adding support. –KnightMiner · (t) 15:19, 29 April 2015 (UTC)

 Done. 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. –KnightMiner · (t) 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 Pocket Edition Alpha 0.11.0 build 1 (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 Pocket Edition Alpha 0.11.0 page, how can I make it so the snapshots/dev builds are listed in the version nav bar (like on the PC versions)? –Goandgoo ᐸ Talk
Contribs 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). –KnightMiner · (t) 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. –Goandgoo ᐸ Talk
Contribs 04:54, 3 May 2015 (UTC)

Are you able to make a page like 1.8/Development versions for Pocket Edition 0.11.0? Also, why are the snapshots on 1.8/Development versions out of order? –Preceding unsigned comment was added by Goandgoo (talk • contribs) 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 |categories= to builds.

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). –KnightMiner · (t) 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 Pocket Edition Alpha 0.9.0)? 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. Pocket Edition Alpha 0.9.0/Development versions)? 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. –Goandgoo ᐸ Talk
Contribs 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. –KnightMiner · (t) 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 Pocket Edition Alpha 0.1.3, 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. –Goandgoo ᐸ Talk
Contribs 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 "Pocket Edition pre-release]].

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. –KnightMiner · (t) 20:36, 7 May 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. Majr, Orthotope, Goandgoo, Dinoguy1000, KnightMiner? —  NickTheRed37 (talk|contributions) 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. Quatroking 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. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 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. –KnightMiner · (t) 16:20, 27 April 2015 (UTC)

I only used the IRC because Wyn used it. –Majr ᐸ Talk
Contribs 07:21, 29 April 2015 (UTC)

Bug descriptions controversy

Another edit war was sparked over 1.4.6 by BDJP007301, 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. — NickTheRed37 (talk|contributions) 15:33, 26 April 2015 (UTC)

 Strong Oppose - Majr and Orthotope's statements in an eariler discussion regarding the style guide:

“	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.	„
	— Orthotope

“	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.	„
	— Majr

BDJP ^(t|c) 15:43, 26 April 2015 (UTC)

And what? It will still also provide guidance in creating future version articles. —  NickTheRed37 (talk|contributions) 15:48, 26 April 2015 (UTC)

But what I said directly argues against what you were doing... –Majr ᐸ Talk
Contribs 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 rule 3; some of your comments have been very close to personal attacks. -- Orthotope^talk 17:29, 26 April 2015 (UTC)

•  I would agree that a clarification in the 'Writing' section 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. – Sealbudsman (Aaron) ^t/_c 18:55, 22 May 2015 (UTC)

•  Agree with Sealbudsman. –LauraFi - talk 19:31, 22 May 2015 (UTC)

•  Question - 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: "<correct title here>". Or also vice-versa; Use the corrected grammar and put the question mark that when hoevered over it shows "Original title: "<original title here>". I may draft these later. --ToonLucas22 (talk) 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? – Sealbudsman (Aaron) ^t/_c 23:17, 22 May 2015 (UTC)

•  Question - Maybe people could spell out why they consider the exact original tracker title to be that important? I've been curious about that. – Sealbudsman (Aaron) ^t/_c 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. --Illidicia (t+c) 23:47, 22 May 2015 (UTC)

  ...were you trying to be humorous with the "grammer" thing? --ToonLucas22 (talk) 23:53, 22 May 2015 (UTC)

   I also prefer the titles, and also only really care about those exceptions you mentioned. – Sealbudsman (Aaron) ^t/_c 00:03, 23 May 2015 (UTC)

•  Agree: 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? –KnightMiner · (t) 02:42, 23 May 2015 (UTC)

“

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?

„

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. BDJP ^(t|c) 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. – Sealbudsman (Aaron) ^t/_c 05:05, 23 May 2015 (UTC)

•  Oppose 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. —munin · · 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. —  NickTheRed37 (talk|contributions) 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 5551, 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. – Sealbudsman (Aaron) ^t/_c 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.. --Illidicia (t+c) 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 correcting spaces, 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 "Mine Cart Off track and into Walls" 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? –KnightMiner · (t) 23:01, 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 correcting spaces, provided the original words are still used?

„

1.  Strongly oppose any changes to the title.
2. Correcting typos:  Oppose
3. HTML formatting:  Agree
4. Correcting spaces:  Oppose

BDJP ^(t|c) 14:33, 31 May 2015 (UTC)

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

•  Agree - 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? –Goandgoo ᐸ Talk
  Contribs 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? --Kkkllleee (talk) 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? –Goandgoo ᐸ Talk
Contribs 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. --Kkkllleee (talk) 08:39, 5 June 2015 (UTC)

New disambiguation icon

I recently uploaded an updated version of the disambiguation icon. 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 User:NickTheRed37 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? | violine1101^(Talk) 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 WP:BOLD. –KnightMiner · (t) 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

Nmoleo64 (talk) 15:31, 4 May 2015 (UTC)

I prefer the old icon. Please revert it.67.160.25.176 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. —  NickTheRed37 (talk|contributions) 06:52, 7 May 2015 (UTC)

I prefer the old icon. –LauraFi - talk 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}}.) —  NickTheRed37 (talk|contributions) 17:35, 7 May 2015 (UTC)

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

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

Your ping didn't work. –LauraFi - talk 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. -- Orthotope^talk 00:24, 23 May 2015 (UTC)

New icon

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

Support

•  Support. BDJP ^(t|c) 19:12, 7 May 2015 (UTC)
•  Support. | violine1101^(Talk) 13:04, 11 May 2015 (UTC)

Oppose

Neutral

•  Neutral– Oppose. 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. — NickTheRed37 (talk|contributions) 17:35, 7 May 2015 (UTC)
•  Neutral It looks almost the same as the current disambiguation icon. Therefore, I can't see what the huge stink is about. AwesomeMan31415926 (talk) 08:09, 11 May 2015 (UTC)

Old icon

Here, you should give opinions on the old icon.

Support

•  Support. —  NickTheRed37 (talk|contributions) 17:35, 7 May 2015 (UTC)
•  Agree 67.160.25.176 22:36, 7 May 2015 (UTC)
•  Support. –LauraFi - talk 22:42, 7 May 2015 (UTC)

Oppose

•  Oppose per WP:BOLD. BDJP ^(t|c) 17:19, 16 May 2015 (UTC)

  If you oppose per WP:BOLD, I have to tell you that you are wrong. Please read WP:BRD. Plus, it doesn't have really much to do with the file aside the fact that someone just made a bold edit to it. --ToonLucas22 (talk) 23:42, 22 May 2015 (UTC)

•  Oppose 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. 71.212.10.80 20:16, 22 May 2015 (UTC)

Neutral

•  Neutral. | violine1101^(Talk) 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: minecraft.gamepedia.com/Special:Random
-Nmoleo64 (talk) 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. -- Orthotope^talk 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... Nmoleo64 (talk) 15:29, 4 May 2015 (UTC)

Missing texture

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

Resource pack#Textures, at the end. That is all there is to say about it (though you can add an image if you like). –KnightMiner · (t) 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 |content= would represent the input. Each comma (or whatever you set |id= to) would separate each part of the list. The parameter |format= would replace every <content> with whatever is used in the list. This template can be created using {{#vardefine:currentAmount|1}}{{#replace:{{#pad:|{{#replace:{{#replace:{{{content|}}}|{{{id|,}}}|{{#vardeifine:currentAmount|{{#expr:{{#var:currentAmount}}+1}}}}}}{{#var:currentAmount}}|{{#replace:{{{content|}}}|{{{id|,}}}|{{#vardeifine:currentAmount|{{#expr:{{#var:currentAmount}}+1}}}}}}}}}}|+}}|+|{{#replace:{{{format|}}}|<content>|{{#explode:{{{content|}}}|{{{id|,}}}|{{#var:currentAmount}}}}}}{{#vardefine:currentAmount|{{#expr:{{#var:currentAmount}}+1}}}}, 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.67.160.25.176 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. -- Orthotope^talk 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.71.212.10.80 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 mw.text.split( content, id )? –Majr ᐸ Talk
Contribs 03:23, 7 May 2015 (UTC)

@Majr: 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..'{{#replace:{{{format|}}}|<content>|'..content..'}}'
	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.71.212.10.80 13:33, 7 May 2015 (UTC)

The parser function won’t be parsed. It should be called via frame:callParserFunction(), which is still rather more complex than using just Lua anyway. —  NickTheRed37 (talk|contributions) 14:18, 7 May 2015 (UTC)

Actually, the parser function will work because it is returned, and whatever is returned is treated as wikitext.71.212.10.80 14:34, 7 May 2015 (UTC)

I’ve already tried to call a template like that, and it failed. —  NickTheRed37 (talk|contributions) 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. Anomie x (talk) 19:54, 7 May 2015 (UTC)

(edit conflict)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|<content>}}, which will return the default missing sprite, then the module will try to replace any cases of <content> with the new value, which would be none as {{blockSprite}} already replaced <content> 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 {{#dplreplace:}} as I did in {{Block state table}}.

The only option other than Lua that will actually process a function are the loop parser functions, 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. –KnightMiner · (t) 20:31, 7 May 2015 (UTC)

The template can be achieved using {{#dplreplace:+{{#replace:{{{content|}}}|{{{id|,}}}|-+}}-|/+(.*?)-)/|{{#replace:{{{format|}}}|<content>|\n}}}}, which might be more simple than a module. Please state your opinion.67.160.25.176 23:02, 8 May 2015 (UTC)

In the few cases where {{#dplreplace:}} 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. –KnightMiner · (t) 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.71.212.10.80 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 sandbox, 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. –KnightMiner · (t) 14:11, 9 May 2015 (UTC)

 Agree We can simply incude the wikitext in templates that use it.71.212.10.80 16:52, 9 May 2015 (UTC)

Minigame notability

Moved from MCT:Style guide#Minigame notability, due to notability changes being a community issue rather than simply style

Currently, minigames are considered notable if Mojang has claimed to play them (see MCW:Style guide#Community notability). 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:

• Marc was in the original video of SethBling's "Blocks vs. Zombies",^[1] 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.^[2][3]
• Several mojang employees have been on several minigame servers. Dinnerbone has for example played both "Juice" and Survival Games on PlayMindcrack.^[4]

Basically I am proposing only allowing minigames which do not require plugins or excessive command blocks, leaving games such as Spleef 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). –KnightMiner · (t) 17:37, 19 March 2015 (UTC)

I don’t see the point of listing minigames at all. — NickTheRed37 ^t/_c (f.k.a. Naista2002) 13:50, 24 April 2015 (UTC)

 Agree We could have a page called Minigames and minigames could be subpages.67.160.25.176 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.71.212.10.80 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 MCW:Sandbox to write the page before proposing it. –KnightMiner · (t) 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. 108.210.219.23 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. –KnightMiner · (t) 14:36, 16 May 2015 (UTC)

 Done: Category:Version banners. –LauraFi - talk 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 hydra.css 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 (File:Book-watch-icons.png) for all four icons, with a book for the unwatched icon, a enchanted book for watched, and both are tinted the color of the written book 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 File:Grid Book and Quill.png, 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? –KnightMiner · (t) 15:37, 16 May 2015 (UTC)

•  Agree. BDJP ^(t|c) 17:17, 16 May 2015 (UTC)

•  Neutral. –LauraFi - talk 17:29, 16 May 2015 (UTC)

•  Agree, but 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:

#ca-watch+unwatch.icon a:everything - "padding: 14px 12px 6px 17px;"
#ca-watch.icon a - "background-position: 17px 15px !important;"
#ca-unwatch.icon a - "background-position: 1px 15px !important;"
#ca-watch.icon a:hover+focus - "background-position: 17px -1px !important;"
#ca-unwatch.icon a:hover+focus - "background-position: 1px -1px !important;"
#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) | violine1101^(Talk) 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. –KnightMiner · (t) 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. Link to updated CSS. –KnightMiner · (t) 03:26, 18 May 2015 (UTC)

•  Support. —  NickTheRed37 (talk|contributions) 07:25, 17 May 2015 (UTC)
•  Disagree. 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. –Majr ᐸ Talk
  Contribs 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. –KnightMiner · (t) 03:26, 18 May 2015 (UTC)

•  Maybe 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. —  NickTheRed37 (talk|contributions) 07:47, 17 May 2015 (UTC)

  Maybe it's possible to add a setting for that in Special:Preferences? Other than that, I like the idea of taking ender pearls and ender eyes. But what would the sprites for hovering over be? | violine1101^(Talk) 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. —  NickTheRed37 (talk|contributions) 09:16, 17 May 2015 (UTC)

  I just uploaded an enderpearl version of the stylesheet here. Feel free to change it if you want. | violine1101^(Talk) 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. –KnightMiner · (t) 03:26, 18 May 2015 (UTC)

  See above. —  NickTheRed37 (talk|contributions) 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. | violine1101^(Talk) 15:16, 18 May 2015 (UTC)

  CSS does support fade animation of sorts using @keyframe, 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. –KnightMiner · (t) 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... –Majr ᐸ Talk
  Contribs 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. | violine1101^(Talk) 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 Granite where it states outdated information about andesite and diorite, 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?) –KnightMiner · (t) 16:11, 19 May 2015 (UTC)

•  Agree. –LauraFi - talk 16:22, 19 May 2015 (UTC)
•  Neutral. I'm certainly unsure. —  NickTheRed37 (talk|contributions) 06:11, 20 May 2015 (UTC)

•  Agree - It would certainly help to see which are the videos are in need of updating. –Goandgoo ᐸ Talk
  Contribs 00:24, 23 May 2015 (UTC)

 Done: 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. –KnightMiner · (t) 04:39, 27 May 2015 (UTC)

Would your bot just detect if there is other text in the video section? –Goandgoo ᐸ Talk
Contribs 09:07, 27 May 2015 (UTC)

Basically. It also has to remove any previous formatting and the word "note" though. –KnightMiner · (t) 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. –KnightMiner · (t) 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 Farmland, Village and Desert temple are not in the category. –Goandgoo ᐸ Talk
Contribs 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 LauraFi got all of those. –KnightMiner · (t) 16:20, 28 May 2015 (UTC)

You could just trash the bot and put a <includeonly> tag around a category definition as the content of the template, ex:

<includeonly>[[Category:Inaccurate videos]]</includeonly>

The <includeonly> makes it so that the template itself doesn't have the text (isn't in the category) but anything that uses it is. AwesomeMan31415926 (profile|contribs) 11:08, 31 May 2015 (UTC)

Banner patterns

I was thinking of a sprite sheet for banner patterns (maybe AllBannerPatterns.png), preferably with the patterns well organized. Once this is done, the sprite sheet would be used in Module:Grid, making it possible to display banners with multiple patterns. It would not be able to use Module:Sprite 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").71.212.10.80 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? -- Orthotope^talk 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. –KnightMiner · (t) 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. 71.212.10.80 17:09, 2 June 2015 (UTC)

HESI Project = Discontinued?

Since the last discussion 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 categories 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. -Sonicwave ^talk 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. –KnightMiner · (t) 23:13, 24 May 2015 (UTC)

ToonLucas22 may be a good candidate, if we can get him to re-focus on this wiki. —  NickTheRed37 (talk|contributions) 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. Health, Multiplayer, Inventory, and several others.) are lacking in history for the Pocket, Pi, and Console Editions. All pages I listed here have dramatically different histories from the PC edition, making me wonder if this is intentional? -Illidicia (t+c) 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, mw:Help:CirrusSearch describes some search parameters that might help, such as searching "health incategory:Pocket_Edition_versions") –KnightMiner · (t) 15:32, 25 May 2015 (UTC)

Raw and cooked food

The following is a closed discussion of a proposed merge. Please do not modify it. Any editors wishing to make further comments should start a new topic.

The result of the discussion was do not merge.

---

I suggest merging each other, since cooked is basically just a different state of food. —  NickTheRed37 (talk|contributions) 11:59, 31 May 2015 (UTC)

 Strongly Oppose Actually, it isn't. The actual data values are different. For raw beef, for instance, the value is 363 and the name is "beef". For cooked beef, 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 subpage of your sandbox, 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 Beef and ask for Raw Beef and Steak to be deleted, then merge all the other raw and cooked.) AwesomeMan31415926 (profile|contribs) 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.  Busted. —  NickTheRed37 (talk|contributions) 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 (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. AwesomeMan31415926 (profile|contribs) 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 Talk:Red Sandstone#Reboot (yes, it is not about sand directly, but it is about sandstone). —  NickTheRed37 (talk|contributions) 13:55, 31 May 2015 (UTC)

 Oppose - Different food items with completely different properties. BDJP ^(t|c) 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 on Talk:Red Sandstone#NickTheRed37’s conclusion

— NickTheRed37 (talk|contributions) 14:31, 31 May 2015 (UTC)

 Oppose. –LauraFi - talk 14:31, 31 May 2015 (UTC)

Unargumented voices don’t count. —  NickTheRed37 (talk|contributions) 14:35, 31 May 2015 (UTC)

Stop creating your own rules. –LauraFi - talk 14:38, 31 May 2015 (UTC)

Where had I did so? It’s a general rule. —  NickTheRed37 (talk|contributions) 14:42, 31 May 2015 (UTC)

The "general rule" that you claim exists actually does not exist on the official rules nor the talk page guidelines. BDJP ^(t|c) 15:11, 31 May 2015 (UTC)

In short, why do you oppose? —  NickTheRed37 (talk|contributions) 14:43, 31 May 2015 (UTC)

 Oppose: 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.). --GreenStone (talk) 15:11, 31 May 2015 (UTC)

 Oppose: 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. –KnightMiner · (t) 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 Dragonfly5555 (talk • contribs) 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". | violine1101^(Talk) 11:06, 4 June 2015 (UTC)

Council

Should the Minecraft Wiki have a wiki council where users can discuss and vote on wiki stuff? -- MCPEplayer2 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. –Goandgoo ᐸ Talk
Contribs 02:40, 6 June 2015 (UTC)

You are thinking of talk pages. 71.212.10.80 02:59, 6 June 2015 (UTC)