Minecraft Wiki talk:Community portal/Archive 21

Error: String exceeds 1,000 character limit.
Just like at -> Crash Report. Probably remove the character limit? undefinedundefined 10:49, 19 June 2017 (UTC)
 * Blobs2@undefined: this is not about the game or a mod, this is about the error that used to be displayed on the page due to the report being entirely fed to a parser function with this limit in . should have removed that restriction, but may have re-added another bug (that parser function was added in, see the summary of that edit).
 * The character limit is likely a server configuration value. If it's a recent change, and other pages using the template would be displaying errors as well, some sort of action is most likely necessary. -- 15:12, 19 June 2017 (UTC)


 * Its worth noting that the recent commit is adding a useless default, it only is useful within the  as it is escaping dashes. I switched the template to use   instead of the pre tag though and it seems to work fine now without needing to escape at all. – ·  16:41, 19 June 2017 (UTC)

Porting templates with variables to Scribunto
If a template is using  and   to store state for subsequent invocations, is it possible to port the template to Scribunto without modifying its syntax? This would require setting some sort of page state in Lua code, and I can't find anything for that in.

And another (somewhat related) question: can there be technical reasons not to port a template to Scribunto? -- 21:06, 25 June 2017 (UTC)
 * Edit: missed that  has return values. --  00:21, 26 June 2017 (UTC)


 * Scribunto isn't good for small, simple templates, due to the overhead of invoking the lua engine hundreds of times on a page not being outweighed by the performance and readability improvements afforded to more complex code, especially that which is only used a few times on a page. – ᐸ  04:43, 26 June 2017 (UTC)


 * Templates that use variables to pass state between them can be converted to Lua, but only by either converting them to a single-transclusion usage, or by requiring the state to be passed in the transclusion; you are correct that Lua/Scribunto doesn't provide any page state (this is an intentional design decision, meant to make partial (re)parses of pages possible without having to deal with potential side effects). 「」· 17:54, 30 June 2017 (UTC)


 * Actually, state can be preserved by using DPL vars, as is already used in . – ᐸ  03:35, 1 July 2017 (UTC)


 * Well, yeah, but DPL is an unrelated extension (and all of the DPL extensions are viewed with suspicion by WMF developers); my understanding of Nil's comment was that they were asking about methods purely in Lua/Scribunto to do so. If you're going to throw other extensions into the mix, though, you could just use Ext:Variables as well (assuming there's no hidden gotcha's preventing that from working). 「」· 17:42, 1 July 2017 (UTC)

Low InvSprite quality
The seem to have low image quality for me (look at the colo[u]rs). Is it Gamepedia's, the Sprite module's or the spritesheet uploader's fault? Or is my cache outdated? | 14:50, 30 June 2017 (UTC)
 * I don't think it has low quality. Probably your cache is outdated. –  undefinedundefined 03:47, 1 July 2017 (UTC)
 * Well, I actually asked because clearing my cache didn't help. After further investigation, I noticed that the sprite background image is  when I use Firefox, which is the one with the lower quality. The sprite background when using Edge or Chrome is   which is fine. Gamepedia seems to mess things up. |  09:49, 1 July 2017 (UTC)
 * Weird. I use Firefox and still get the second image. The first one is indeed of substantially lower quality due to color depth reduction (8 bits per pixel instead of 32). -- 10:10, 1 July 2017 (UTC)
 * And when I try to save this section,  is always replaced by  . Weird. |  10:22, 1 July 2017 (UTC)


 * You must have some script/addon/plugin changing it. The sprite doesn't use, and has never used, "instart". You can see this on . – ᐸ   11:27, 1 July 2017 (UTC)


 * That's the weird thing: It's not because of any script, addon or plugin. It also happens if I am logged out. I don't have any addons or plugins. I checked using the Firefox F12 Network debug tool, the page is sent directly from the server to me with the instart urls, so it is a server-side problem. | 11:37, 1 July 2017 (UTC)


 * Tell me if you see instart in either of these URLs: https://minecraft.gamepedia.com/load.php?debug=false&lang=en&modules=site&only=styles&skin=hydra, https://minecraft.gamepedia.com/index.php?title=MediaWiki:Common.css&action=raw&ctype=text/css. – ᐸ  11:42, 1 July 2017 (UTC)

It's not on the German wiki though, only here. | 11:52, 1 July 2017 (UTC)
 * Yes. If I had to guess, there's a php script which replaces all occurences of hydra-media with instart for me.


 * You see it on both? That's quite surprising. Even more so that it only happens on Firefox (which makes it seem clientside). Can you check the headers for one of those requests and see if there's any redirects or otherwise non-200 response, and what IP address it comes from in both Firefox and Chrome? – ᐸ  12:09, 1 July 2017 (UTC)

There are no non-200 responses after a hard reload, except for a 302 Moved Temporarily for MediaWiki:SpriteDoc.css which just appends &* to the url, and a 301 Moved Permanently for a Creative Commons image. Same in both browsers. IP adress is 192.33.31.70 in both browsers. | 12:24, 1 July 2017 (UTC)

Yes, I see it on both. | 12:27, 1 July 2017 (UTC)

New topic
I made some edits without being logged in. They can be seen in my contributions but i have not made all this edits. For example the one in the article is not me but its done in between edits i made. Also the IP is strange since i am editing from Sweden and whois gives USA!? How can the IP be that one and how can it be assigned to more people? / 16:10, 2 July 2017 (UTC)


 * IPs are dynamic and change whenever you start your router, unless you have specifically bought a static IP. The location of IPs cannot be accurately determined, and subnets may be bought by other ISPs, thus changing the approximate location. – ᐸ  02:48, 4 July 2017 (UTC)


 * That was not the problem here. Two people don't use the same IP at once if its not a shared one. I always have a Swedish IP and even when this occurred i had it when i checked with whatismyIP. There must be something in the wiki that uses another IP like VPN or Proxy. That is a problem because people doing destructive edits cant be targeted that easy. (Also now i am back at my normal Swedish IP) / 10:45, 8 July 2017 (UTC)


 * I actually didn't read your post properly, I thought you were talking about older edits being made by someone else. Yes it was a reverse proxy CDN that was being tested on some users, which broke a bunch of other stuff and was disabled a few hours ago. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 11:28, 8 July 2017 (UTC)

Redirect policy
I've recently deleted a bunch of pages from, including a number of redirects which are not needed as they are unlikely to be searched (e.g. certain redirects to version pages and other obscure redirects). However I'm unsure as to the policy for the rest of the redirects and whether to keep them or not. When is pluralisation allowed? What about capitalisation? Spacing? & vs and? Alternate spellings? <span class=nowrap>– ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em"> 03:22, 6 July 2017 (UTC)


 * Pretty sure there's not a policy, per se. But there's an attempt to hash one out.
 * There's a stalled where a lot of discussion was generated, but the will to finish never seemed to come together.  There were several things we mostly agreed on.
 * Keeping redirects around for the sake of external pages is a bad idea
 * Keeping plural redirects like or  (that aren't simple plurals: you don't just tack an "s" onto the end) is a good thing
 * Keeping simple plurals like is in conflict with the Style Guide on linking, because you should be writing such links like: s .  It also tends to clog up the search results (which is largely the point of the project) because as you type "Creep", you'll always see "Creeper" and "Creepers" right next to one another; it serves no purpose in that way either.
 * All-lowercase redirects exist so links can be written in all-lowercase form, without having ugly links like, and this is a good thing.
 * Maybe you could also look at:
 * . The banner redirects are probably unnecessary.  Looking at the code, I'm almost certain of it.  Maybe you could delete one link, and see if anything breaks, since you have the power to do that.
 * Also, any color- or wood- variant redirects like Blue Bed and Acacia Fence Gate.
 * – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 04:03, 6 July 2017 (UTC)

Wiki is thinking I'm removing https protocol from various websites when I actually aren't.
Well, it happened again this morning. Just editing as usual and the wiki somehow thought I was doing something different. - ( 11:18, 7 July 2017 (UTC)


 * Assuming its the CDN. . <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 11:39, 7 July 2017 (UTC)

Translation cleanup
Since large changes to all pages are coming, these unfinished translations are going to become even more obsolete than they already were, so they really have no value.

These are the inactive translations currently (no significant translation this year):
 * [.[MCW:Projects/Arabic translation|Arabic}}
 * [.[MCW:Projects/Bulgarian translation|Bulgarian}}
 * [.[MCW:Projects/Catalan translation|Catalan}}
 * [.[MCW:Projects/Croatian translation|Croatian}}
 * [.[MCW:Projects/Danish translation|Danish}}
 * [.[MCW:Projects/Estonian translation|Estonian}}
 * [.[MCW:Projects/Farsi translation|Farsi}}
 * [.[MCW:Projects/Greek translation|Greek}}
 * [.[MCW:Projects/Irish translation|Irish}}
 * [.[MCW:Projects/Romanian translation|Romanian}}
 * [.[MCW:Projects/Serbian translation|Serbian}}
 * [.[MCW:Projects/Irish translation|Irish}}
 * [.[MCW:Projects/Romanian translation|Romanian}}
 * [.[MCW:Projects/Serbian translation|Serbian}}

The ones in bold were considered inactive in the previous topic too, where none of the translators came forward to disagree with deleting the projects, and so they will be deleted momentarily. The others I will leave for a week of discussion before deleting them.

For remaining projects, I would like to simplify the requirements: Translate the main page, then you get your own wiki. I think having the translation pages be tacked on the English ones at "temporary" names is discouraging to translators, as if they do eventually meet the old requirements, they still have a bunch of work to do to move all their existing pages to the correct names and fix any templates they made. I also find they tend to waste time translating pages (and templates, which really shouldn't be translated at all in the projects) which are not necessary to meet the requirements to finish the project, which then results in the project often remaining for too long, and thus dying. So getting the project moved into its own wiki, where the changes are final, and they are free to translate whatever they like and actually have those pages read by the general public, should improve the chance the wiki will succeed.

These projects have had some activity this year, however are not viable to move to a separate wiki yet. Any pages which are a few years out of date should be deleted, and the participants should be contacted to see if they want to improve the translation so it can be moved to a separate wiki.

These projects look ready to go now under the new requirements, and so if there are no disagreements I will ask for them to be moved.

Pings:

, your translation projects are inactive, and may be deleted soon. Please reply if you would like to update your translations to meet the simplified requirements, so the project can be completed and given its own wiki.

, your translation projects are almost ready to be completed, you just need to update the "Minecraft Wiki" page translation to the current version of the page, then the project should be able to be completed and moved to its own wiki.

<span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 01:52, 9 July 2017 (UTC)


 * Is it safe to assume when you count "activity this year", you don't count users like myself who might go into a translation page and fix broken sprites and things like that? – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 06:07, 9 July 2017 (UTC)


 * Correct, I only counted edits which actually translated the page. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 06:09, 9 July 2017 (UTC)


 * The has been  by, so the project should not be deleted anymore. Let's see how active the translation will become. |  18:43, 11 July 2017 (UTC)


 * Ok, I have asked for the three wikis to be moved. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 10:03, 15 July 2017 (UTC)


 * ,, . I'll delete the project pages and email all the translators tomorrow. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 13:29, 17 July 2017 (UTC)


 * Great! I'll try to help setting those up if I have some time. Maybe  should redirect to the Czech wiki as   is the code for the Czech Republic while   is the code for the language. This could cause some confusion. (See ) |  14:47, 17 July 2017 (UTC)


 * The project pages have been deleted, and the translators I could find have been emailed. will be made admins of their respective wikis (once they log in), as they are the most active recent translators. Whatever communities spring up in the new wikis can decide on admin changes if necessary and I will implement them. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>  05:11, 18 July 2017 (UTC)


 * Still, the currently accepted way of creating translation projects isn’t perfect, and the way the projects were moved to their separate wiki projects isn’t either. A wiki robot could rename the translated pages like to  (only checked on Turkish wiki) just as easily as deleting the pages here, on the English wiki, and the linking problem would have been solved by using a template like  then substituting it with the aid of the same bot. Speaking of the Taş (Stone) article specifically, it still contains text in English, and some others may also have it, so I doubt the Turkish project should have even moved until finally completed. Same with the . — <span class="nowrap">  07:29, 18 July 2017 (UTC)


 * If new translations are started, then it will be done better. There projects don't include a (machine readable) mapping of translated page names to English ones, therefore a bot can't simply move them. As for the new wikis, read the topic, we're not waiting on 100% of the wiki to be translated before moving to a separate wiki, otherwise it will never happen, as demonstrated by all the years old dead translations we have. The new requirement will be simply to translate the main page, then it will be eligible for a separate wiki. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 07:36, 18 July 2017 (UTC)


 * What a stupid requirement. So do you think that such necessary pages as rules, community portal, admin noticeboard and at least a hundred of important articles don’t need to be translated? A wiki must have enough content to be read, and these new sections don’t satisfy the requirements. I suggest creating a list of pages required to be translated in order to start a new full section, and a template to simplify linking. — <span class="nowrap"> 07:59, 18 July 2017 (UTC)


 * The point of creating a separate wiki earlier is that the translation subpages here on the English wiki are not visible to the average user. That's why those translation projects need ages to be completed or die because nobody knows they actually exist. That's different with an own wiki - it's directly visible on the main page and, as a bonus, it doesn't clutter up the English wiki. Rules, admin notice board etc. can wait until the wiki has actually been created. However, I think it would be worth to promote the new and/or inactive language wikis in the site notice (at least for a short while), so even more people know that the wiki is available in their language. | 09:17, 18 July 2017 (UTC)


 * A wiki also needs to exist in the first place to be read. The EN wiki didn't start with 100% of the pages created before it was made public, neither should the translations. Wikis are all about being WIP. Creating a wiki is quick and easy, there's no reason to try to cram them into this one. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 09:35, 18 July 2017 (UTC)


 * The English wiki was simply the first one, while the Russian and Polish ones just as simply originated independently. Others were made from translation projects based on this wiki. Isn’t it better to go towards potential readers and new editors? A list of required pages would give a stimulus to preliminary translation project’s members, a goal to reach. Also, if you need additional coverage for translation projects, isn’t it simpler to create a small language navbox akin to one featured in FTB Wiki and mention that translation projects ever exist? Isn’t that simple enough to implement? Or maybe just simply install ? (I’m not a fan of this extension myself, but someone would necessarily mention it.) — <span class="nowrap"> 10:39, 18 July 2017 (UTC)
 * How would that help? We already have something like a navbox -- it's called interwiki links. Why create two separate systems which essentially do the same? Also, when the German wiki was created, alongside the Dutch one, it consisted of one page only. Which contained one word with six letters. Now it's the third largest Minecraft Wiki. Why should translation projects have no goal to reach if they're on a separate wiki? | 12:59, 18 July 2017 (UTC)
 * How would that help? We already have something like a navbox -- it's called interwiki links. Why create two separate systems which essentially do the same? Also, when the German wiki was created, alongside the Dutch one, it consisted of one page only. Which contained one word with six letters. Now it's the third largest Minecraft Wiki. Why should translation projects have no goal to reach if they're on a separate wiki? | 12:59, 18 July 2017 (UTC)


 * By the way: Maybe the Greek wiki should be mentioned in the site notice as well. There is almost noone active there, many pages are untranslated and I've actually never seen translation work there. | 14:39, 18 July 2017 (UTC)


 * I also agree with . The system we have had here for translations is both complicated to use and overall puts users off as they cannot create page titles in their own language. All links and templates are awkwardly linked as well. Separate Wikis makes both this one a lot cleaner instead of being filled with half finished translations, and makes it easier to translate for others. <span class=nowrap>– · 04:27, 19 July 2017 (UTC)


 * If we are going to keep the translations in the English wiki, a better system would to have them at (for example) cz/Stone instead of Stone/cz. This makes the translation projects much more manageable and easy to navigate, as cz could be the Main Page. –    04:35, 19 July 2017 (UTC)


 * The problem is that it would clutter the main namespace. I think a special translation namespace for translation projects should work. Like . Yes, that requires Curse to apply the changes here, but at least we would not have to bother with naming, linking and renaming (only strip the   prefix). Off-topic: With this mass movement of articles, the count of content pages for English wiki dropped to 4,686 (as of now), so it is now only the second-largest wiki after the Russian wiki (5,464)! — <span class="nowrap"> ( | RU) 07:43, 19 July 2017 (UTC)


 * One reason is because they give Console Edition updates their own pages. Should we do that here? Also, what accounts for the other thousand? –    07:49, 19 July 2017 (UTC)


 * Mods. Off-topic ends here, don’t reply. — <span class="nowrap"> ( | RU) 13:15, 19 July 2017 (UTC)


 * I can volunteer to help with the Romanian translation. However, if it's super out of sync with its English counterpart, it will probably take a while until I am done, unless we can find someone to help me.  11:27, 19 July 2017 (UTC)
 * L4bbogdanbarbu@undefined: if you can get the main page translated and maybe ask for help in any Romanian Minecraft communities, a new wiki can be set up ^_^ which will hopefully make it more visible and more useful, and more likely to have interested volunteers.
 * I don't really see any good reason to move translations, that sounds like a waste of time with no obvious benefits. Exporting translations would be slightly easier under a system where things are named like "Translation:Ukrainian/Камінь", but because we've become liberal with the requirements and we'd have to move all of these pages anyway to establish such a system there's not much of a benefit in that. The only benefit I can think of is an article count that only counts English pages, but that benefit is pretty negligible.
 * I wouldn't recommend that Extension:Translate be installed on this wiki, it's not very user friendly. Well, it is really nice for translators, but not for other editors because of the required translation markup (see here). I've been intending to replace it on the FTB Wiki with something less annoying but that's another story. Minor note: the "language navbox" is called a language bar, or langbar for short. It's a bit more visible than the interwikis although I don't think interwikis are particularly hidden.  16:54, 20 July 2017 (UTC)
 * Using interwikis for translations sounds like a terrible idea to me for several reasons. First of all, we were only able to easily point out that certain translations were out-of-date because they all resided here. I believe such care is to the reader's benefit. Secondly, it's not simply a matter of starting a new wiki; we'd also need to copy all the images and templates over and keep them in sync (e.g., the Schematic template will get an update everytime new blocks are introduced in the game). Separating the community in this way unnecessarily adds to everyone's workload. Last but not least, it makes finding the translations a little more difficult because when looking up something like "minecraft command block" on Google and possibly other search engines, the first two results are typically this wiki's English article on command blocks and its relevant translation (e.g., I used to get English and Romanian before the Romanian translations were removed). Also, Extension:Translate doesn't add a lot of markup at all and seems straightforward to use. I, for one, am all for it.  05:09, 21 July 2017 (UTC)


 * Installing Extension:Translate here would allow for translating articles to languages that already have a separate section, which is absurd. It is usually installed on wikis that don’t have separate language sections like, , FTB Wiki etc. That’s first. And second, the translation markup is known to be very fragile to VisualEditor edits, while some newer users tend to prefer this editing tool over source editing. Speaking of newcomers, the ugly markup will make editing articles complicated.
 * Not all sections have originated from English wiki’s translation projects. Russian and Polish Minecraft Wikis have been originated as part of separate websites (e. g. Russian wiki was formerly a part of minecrafting.ru, the main site for Minecraft community in Russia) until joining Curse’s project in 2011. Russian and probably German wikis have communities big enough to keep stuff up to date, but keeping smaller sections up to date will be a problem, because users are needed to do it, and they in turn may need assistance. — <span class="nowrap"> ( | RU) 09:59, 21 July 2017 (UTC)
 * Translation to certain languages can be disabled. For example, since we have a Russian wiki, we can disable translation to Russian. On the MediaWiki Wiki, variations of Chinese (zh-tw, zh-cn, zh-hant, etc) are all disabled in favor of translation to only one Chinese (zh). That's not an issue. The markup is the main issue I've had as the "translation administrator" of the FTB Wiki; no one but me seems to understand how to apply it correctly, new users, as well as very experienced users, have trouble editing pages with translation markup. Working with templates and modules is painful, and so is adding the markup to every single page if you intend to do that, because unmarked pages cannot be translated. VE stuff can indeed be funky (although to be honest I don't care that much about that, I never liked VE in general). Also related: , my very on-hold project to replace the extension with something custom (the page is slightly out-of-date but it is still useful). I was planning to do it but got into a depression after something else failed, and after returning to wiki editing I haven't touched it. Hopefully I will eventually.  13:05, 22 July 2017 (UTC)


 * Yeah, the extension's syntax clutter is hellish for editors. The translation interface is great though, but it isn't worth making all the source pages unreadable. Plus having all the translations on the same wiki still doesn't work well even with the extension. You don't get translated page names (in the URL), and reports are often uselessly cluttered with irrelevant (to a particular language editor) pages, for example. Using the translate extension here is absolutely out of the question. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>  01:47, 23 July 2017 (UTC)

. requested to create the Farsi (Persian) section after the respective project has been removed. This is the first proposal of such kind. — <span class="nowrap"> ( | RU) 16:11, 23 July 2017 (UTC)


 * No, Romanian has also been requested after the project has been deleted, see above. | 19:24, 23 July 2017 (UTC)

One and a half months passed. The Turkish wiki, just like the Greek wiki (updating doesn’t count). What I see there is only pointless edits like empty article creation by anons, writing important pages in English, interwiki bot edits and other users (like me) complaining about problems, occasionally reverting some bad edits (but I’m frusturated that I can’t delete empty pages). The project is practically dead, has gone missing, the IRC channel I created in order to give hints to users hasn’t been visited by anyone else. Isn’t it because nothing was done in order to create help pages, a normal community portal, rules and a few dozens of benchmark quality articles? The new users probably don’t see any guidelines to follow, and don’t mind about anything to do. Or maybe the Minecraft community in Turkey is way smaller, despite that country’s population of about 80 million (comparable with Germany, and more than a half of Russia’s), because Thai and Czech wikis are still somewhat active. — <span class="nowrap"> ( | ru.Wiki Admin) (fka NickTheRed37) 09:28, 31 August 2017 (UTC)
 * Take it up with —   12:07, 31 August 2017 (UTC)


 * I don't know what you expected with making an IRC, as even the main IRC is probably dead, because who even uses IRC these days? Discussion is all on-wiki or slack. As for the wikis being dead, they would have just been dead projects otherwise. At least they have a chance to be used instead of being stuck here in purgatory, never to be seen by the public, like the remaining projects are. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 03:43, 5 September 2017 (UTC)


 * Russian wiki has a good experience of using IRC for discussing various problems (just like the FTB Wiki); in fact, it was me who proposed a channel in that network and created it. Later both of these wikis have opened a Discord server each, which took the IRC channels’ role of main real-time discussion media. As far as I know, nobody on the Russian wiki used Slack for the same thing IRC and Discord are used for. Polish wiki also has an IRC channel, #mcwikipl on Freenode. This protocol doesn’t give up quickly. Also, I have left a link to the Turkish wiki’s channel on the community portal’s talk page.
 * If these translation projects are not so publicly seen, isn’t it better to give them more coverage within bounds of this specific section? Look at how FTB Wiki made it. They have a separate translation portal, their articles have a navigation bar which shows translations. Finally, many of FTB Wiki users are or originally were translators. Why do you think we can’t implement something like that here, on the Minecraft Wiki? — <span class="nowrap"> ( | ru.Wiki Admin) (fka NickTheRed37) 14:34, 24 September 2017 (UTC)

I think it would be a good idea to modify that animated render so that the ghast shoots a fireball every 2 or 3 cycles. This will allow people to see the alternate face texture. What do you think? 00:29, 13 July 2017 (UTC)


 * This would show the attack animation. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 01:06, 13 July 2017 (UTC)


 * I’m not even sure. If we should do it for the ghast, then we should do the same for all other mobs. Creepers should be shown exploding, skeletons and guardians should be shown shooting, zombies should be shown rising hands when attacking etc. Either modify the ghast animation and create everything for other mobs, either upload a different file to show ghast’s screaming face. That’s the only two options that I see, and I personally lean to the latter. — <span class="nowrap"> 10:43, 18 July 2017 (UTC)


 * I have to say, I really like the idea of having the mobs in the infobox occasionally play their attack animation. Although it really shouldn't happen too often so the reader doesn't get distracted all the time. I'll take a look at this kind of animations tomorrow!  00:08, 24 July 2017 (UTC)

Unused images
Following the deletion of several inactive translation pages, a lot of images which were used on said pages but removed from the English pages will have become unused. I kind of want to look through these files and possibly add them to relevant pages before they get deleted for being unused. How can I view them? -  10:50, 13 July 2017 (UTC)


 * which can also be reached through the 'special pages' link in the left sidebar. -- undefined 11:04, 13 July 2017 (UTC)

Elements of April Fools
I can not do it now, but can I add elements of April Fools' joke to Entities, Blocks, Items and Gameplay? --/ 05:15, 16 July 2017 (UTC)


 * I am neutral, but if they were to be added, the navboxes should have a "Joke features" section. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 15:04, 16 July 2017 (UTC)


 * I personally feel joke features should be left to their own articles same as mentioned features. They were never in the actual game so would just lead to confusion possibly clutter. <span class=nowrap>– · 01:17, 17 July 2017 (UTC)


 * I agree. The main pages should only reflect the current state in the latest version. The features of april fools snapshots were never intended to be a serious addition to the game so I feel they shouldn't even be mentioned in the history sections. They never persist across versions and thus would require an "added" and "removed" entry in immediate succession which just looks silly. They do deserve a mention on their april fools snapshot page or joke feature pages where relevant.  11:21, 19 October 2017 (UTC)

Videos
A lot of the videos on this wiki are obsolete, and have to have lots of notes above them, and the mcspotlights channel doesn't upload any more. Do we really still need the videos? –    03:44, 19 July 2017 (UTC)


 * The videos are shown because . Damn capitalism. — <span class="nowrap"> ( | RU) 07:49, 19 July 2017 (UTC)


 * Let's test out the guidelines they laid down in that article you linked, for getting rid of videos. And see how it goes. – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 11:08, 19 July 2017 (UTC)

Proposal to restrict bureaucrat’s rights
Since nobody has discussed that idea, I want to revive it. It’s about restricting what rights can be set or unset by bureaucrats. agreed with it on IRC (#ruminecraftwiki on EsperNet), and I have decided to put it out on the English wiki’s community noticeboard. Since it affects user rights, Curse members like, and  should discuss it.

The idea is to leave bureaucrats the ability to only assign bot, administrator and bureaucrat statuses, and resign these three statuses as well as wiki guardian status. CheckUser status is found to be not something Curse wants to see widely assigned, widget editing (for which a separate user group exists) is available to administrators already, and Curse usergroup should be restricted to Curse employees only (and I think that changing this status by a simple bureaucrat is futile anyway, since it is global). Wiki guardians are appointed by Curse, but can be converted into regular administrators by a bureaucrat if they think the user in question is suitable to work as a new full administrator, or can be resigned if the user didn’t prove themselves worthy of this status.

If the idea will be supported and implemented on this wiki, I suggest implementing it on other wikis (with their admins’ approval, of course) and keeping it as a standard set of rules for any new wiki that would appear. — <span class="nowrap"> ( | RU) 15:32, 20 July 2017 (UTC)
 * One question. Why? What's wrong with the current bureaucrat's rights? | 17:07, 20 July 2017 (UTC)
 * Apparently (at least on the Russian wiki), bureaucrats can edit any user group, see here (I changed my interface language to make this screenshot). -- 17:56, 20 July 2017 (UTC)


 * Okay, that makes more sense now. While bureaucrats are highly trusted users, it does seem inappropriate for non-Curse bureaucrats to be able to assign Curse-specific group rights. That said, looking at, I'm not readily seeing many rights in the Curse groups that aren't available to regular admins as well. Global admins have checkuser, but that's about it. -- undefined 03:14, 21 July 2017 (UTC)


 * While you can see them, you can't actually set them. In fact, they shouldn't be able to be modified on the normal wikis at all. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 12:52, 21 July 2017 (UTC)


 * Which in turn can justify why these options should not be available in the user group managing tool. I suppose you agree on this topic. — <span class="nowrap"> ( | RU) 13:50, 21 July 2017 (UTC)


 * Yes, and there is a ticket already in asking to do that. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 00:38, 22 July 2017 (UTC)


 * There's not much point in the global/staff groups being displayed to bureaucrats, no. However, their being displayed isn't a big deal (even if it is a bit confusing; I raised this topic with GP staff some time ago, unaware of the earlier discussion on it here), so I can't see it being a very high priority to fix. <span class="nowrap">「」· 19:56, 21 July 2017 (UTC)


 * Oh, and one thing. I propose giving rights to assign and resign the  group to regular administrators. I have forgot about this group earlier, and I don’t think it is of big significance to bureaucrats. — <span class="nowrap"> ( | ru.Wiki Admin) 06:12, 25 July 2017 (UTC)

So, how far this idea goes? — <span class="nowrap"> ( | ru.Wiki Admin) 08:43, 30 July 2017 (UTC)


 * I don't see that there's really anything to do here; the display of errant groups on Special:UserRights for bureaucrats is a known bug that GP staff will get to whenever they do, and there's not much point in limiting bureaucrats' ability to grant or revoke any of the other groups - ignoring the fact that generally bureaucrats are also admins more-or-less as a matter of course, if a given bureaucrat can't be trusted to grant/revoke widget editor or autopatrol, they probably shouldn't be trusted with admin, bot, etc., either. <span class="nowrap">「」· 09:18, 30 July 2017 (UTC)


 * And what’s with the idea of assigning and resigning autopatrol status by administrators? Again, this group is not of high significance to bureaucrats. — <span class="nowrap"> ( | ru.Wiki Admin) (fka NickTheRed37) 09:30, 1 August 2017 (UTC)


 * If a user is trusted enough, they can be given autopatrol rights. Cleans up the recent changes. It probably is not used that much, but it does not hurt that it is possible, does it? | 10:52, 1 August 2017 (UTC)


 * The posts may have been poorly phrased. The question's meaning is whether to allow administrators (and not just bureaucrats) to grant and revoke  group membership.
 * I am neutral with regards to this question. -- 11:32, 3 August 2017 (UTC)


 * , do you ever intend to implement my suggestion regarding  status?  already had to request  assign the status to two users on the Russian wiki, and while the request was fulfilled, the very fact that Ivan-r had to request a Curse staff member to do this without requiring the only Russian wiki bureaucrat’s assistance makes this problem actual. I don’t limit the suggestion to Minecraft Wiki only, I suggest implementing that globally on Gamepedia. — <span class="nowrap"> ( | ru.Wiki Admin) (fka NickTheRed37) 15:34, 8 August 2017 (UTC)


 * I don't have any access to the hydra platform to implement such changes. Assigning user rights is a bcrats primary role, so I don't see why admins need to do it too. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 05:49, 9 August 2017 (UTC)


 * Because autopatrol is not an important group (it only has a single right which only makes these red !’s to not appear on edits of users with it), and requesting a bureaucrat just to assign this status to someone is a hassle not proportional to the group’s value. Wikipedia managers already understood that and . — <span class="nowrap"> ( | ru.Wiki Admin) (fka NickTheRed37) 08:43, 9 August 2017 (UTC)


 * At yet the group is important enough for you to make a fuss about having to ask a bcrat to do their job. Are you really giving autopatrol to so many users that this is actually an issue? In that case, you might as well just ignore the patrol feature like we do. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 09:25, 9 August 2017 (UTC)

The sprites are wrong
April Fools' elements do not work properly with BlockSprite and ItemSprite. (The sprite appears as shown .), do you know how to fix? --/ 07:01, 21 July 2017 (UTC)
 * That’s a server-side caching issue. Russian Minecraft Wiki used to be plagued with them. Wait from a few hours to a few days until it will be fixed. — <span class="nowrap"> ( | RU) 09:44, 21 July 2017 (UTC)
 * I understand. After all, the wiki is often unstable ... Even before this, the server was out ´д` ; --/ 10:44, 21 July 2017 (UTC)

Thumbnails of images are dark
They are dark when scaled, but has normal lighting at original resolution. (renders uploaded by ) Do I have an outdated cache or the wiki has something wrong? <font face="'Open Sans',sans-serif">– undefinedundefined 11:12, 21 July 2017 (UTC)


 * Uploaded a new file, but the scaled version is dark. I guess something's wrong with the wiki. <font face="'Open Sans',sans-serif">– undefinedundefined 11:20, 21 July 2017 (UTC)


 * Not so sure what is going on, even some of the old files from appear dark to me. This just happens randomly, sometimes the images are dark, sometimes normal. But I guess it's the wikis fault and has nothing to do with local caching, because even when using different browsers the darkness remains.   11:21, 21 July 2017 (UTC)


 * It's an ImageMagick "bug", which would be fixed if we could update ImageMagick, or someone would bother to add a to MW. We can workaround the issue locally by not optimising images to greyscale. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>  11:34, 21 July 2017 (UTC)


 * Still not fixed. <font face="'Open Sans',sans-serif">undefined 10:38, 12 August 2017 (UTC)

The "flattening"
So with Java Edition 1.13, something called the "flattening" will happen. You can read about it on the page. All in all, it's a pretty big change that's going to require a lot of updating on the wiki once 1.13 will be fully released. I think we should start thinking about possibly setting up a project for it. We still have a lot of time, I doubt we will even see a snapshot soon, but it's good to be prepared.

The French wiki already used a public list provided by one of the Mojira Moderators (FVbico) which lists the splitting of block states into separate blocks to set up their own list. This list is around 90-99% confirmed and technically not official, but it will be a very very good guideline which will require minimal changes once a snapshot is out (so we can link to it/include it on the snapshot page). -- 18:09, 21 July 2017 (UTC)


 * We've created . -- 20:23, 21 July 2017 (UTC)


 * I'd argue against creating its own article just as its not released so its very subject to change. Maybe we can put it under 1.13 or mentioned features for now as its still technically not part of the game? The issue is littered with comments stating it is still being reworked so its going to change again.
 * For when this is official I could see it worth creating a table template for that though, so you can do something like: . Throw in a few defaults and it will be quite clean to use <span class=nowrap>– ·  00:52, 22 July 2017 (UTC)


 * It will spam the 1.13 page if we put it there and having one subpage (with nothing even linking to it) dedicated to it will make editing it a lot easier. The page also clearly states that the information on it is only mentioned and subject to minor changes in the future (around 90%-99% of the list is confirmed by Grum already). The whole goal of the page is to have something that will require only minor editing once the "flattening" actually drops so we can easily link to it in the snapshot / full release page. So I personally think it's fine. -- 11:14, 22 July 2017 (UTC)


 * By under 1.13, I was leaning more towards, espe cially since after 1.13 is released will just state the latest instead of old and  will state the old one s. <span class=nowrap>– ·  16:37, 23 July 2017 (UTC)


 * I'm fine with, I went with mostly because the French wiki did the same. --  21:54, 23 July 2017 (UTC)

Transcludable game element data — part two
On the Russian wiki I have created a new original module intended to be used on articles instead of transcluding subpages like, which use the Block state table template. The new system has been approved by on the Russian wiki’s IRC channel (#ruminecraftwiki); right now it is only used on, ,  articles and articles about special variants of stone. The block state data is located instead on the subpages of the module itself, e. g.. This system is an implementation of the idea of removing article subpages about game element data and moving it elsewhere (in this case into the Module namespace), something I have proposed. I’m sure this piece of technology, a 100 % Russian wiki invention, may be of interest to other wiki projects. Any thoughts? — <span class="nowrap"> ( | ru.Wiki Admin) 13:43, 24 July 2017 (UTC)
 * I had this idea as well and wanted to create a module like this on the German wiki too. Good to know that this exists already, so I now know where to steal from when we add all of the block states information to the articles :P (if I'm allowed to of course) Apart from that, a small suggestion about this module: Wouldn't it be better to put all the blocks on a single module? It made sense that they were split up previously since they were included via /BS, but now the module can load them directly from another module and you wouldn't have to create a new module for every new block that comes to the game. | 16:47, 24 July 2017 (UTC)


 * What real benefit does this offer? You still have subpages for each variant, so its simply moving the markup to a harder to reach place. Switching to this system as well would be about as much work as simply moving them to the template namespace, so I see little gain while it gives the loss of convenience. <span class=nowrap>– · 18:29, 24 July 2017 (UTC)


 * I stick with my original statement that keeping the data associated with the page is more useful. Further to that, I would rather put the content on the actual page, and extract it out with DPL. This was the original plan for before LST was broken in Curse's fork of DPL, then removed. I never got around to getting LST itself installed, or finding another way to do it with DPL. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>  05:12, 25 July 2017 (UTC)


 * That may sound like a variant, but I’m not quite familiar with DPL (although I was interested in it at some time: I proposed to use it for listing other edition versions of the same number on the Russian equivalent of Version nav, but I have abandoned it since then). Plus, since you say that Labeled Section Transclusion is broken, it would require Curse’s technical staff assistance to get it working (if it’s going to be installed as a separate extension, I request installing it on the Russian wiki too). But I do know that DPL is used in in order to list crafting recipes; in fact, I have myself translated that module to Russian (like most of Inventory slot and UI things, although it is all now outdated), although there are some problems which are to be discussed elsewhere. At the very least, I proved myself able to create original modules.
 * Requesting to participate in the discussion. — <span class="nowrap"> ( | ru.Wiki Admin) 06:01, 25 July 2017 (UTC)


 * I think it's best if the data are on the page itself and extracted with DPL/LST. If the extension(s) used are properly documented, development and maintenance of the extracting templates/modules should not be a significant problem. -- 10:25, 25 July 2017 (UTC)

Beta 1.7.1 / 1.7_01
After much research, I've found that is actually called Beta 1.7_01.

Here is a snapshot from the Internet Archive showing that back in July 2011, the page was called 1.7_01: https://web.archive.org/web/20110705083059/http://www.minecraftwiki.net:80/wiki/Version_History#Beta. I feel like editors from the time the update was released can be trusted more than the editors who worked on the Gamepedia page in 2014.

Also, the JAR available from the is Beta 1.7_01. I have a 6.5 GB collection of many, many vanilla JAR files and none of them are Beta 1.7.1.

Should this page be moved/renamed?

―  17:38, 30 July 2017 (UTC)


 * The naming scheme in the wiki is a bit messy to be honest. The original name of each version isn't necessarily used in an attempt to unify the naming scheme (e. g. "1.9-pre1" is actually called "1.9 Prerelease"), but this unified scheme was only applied for beta 1.7 and later. "1.7.1" follows the wikis' scheme, versions prior to it like "1.5_01" don't. So just changing 1.7.1 wouldn't make too much sense, you'd either have to change every version to its original name ("1.7_01" in your case) or all the missing versions to this unified scheme (e. g. "1.5_01" to "1.5.1"). – 18:43, 30 July 2017 (UTC)


 * My opinion is that all versions should be moved to the original name, as shown ingame if available (e.g. 1.5_01, 1.9-pre1, etc); redirects should be added for the wiki's unified scheme (and the launcher's name, if it differs from the ingame name - the only occurrence I know of this is b1.3b . --  18:50, 30 July 2017 (UTC)


 * I agree. The wiki should refer to versions by their in-game name (e.g. Beta 1.7_01). Redirects should be created for the launcher's names (e.g. b1.7_01 -> Beta 1.7_01). ―  19:46, 30 July 2017 (UTC)


 * I don't have a problem with using the original name. I never understood why the wiki needed to change this anyways. Pokechu22@undefined The in-game name for the first pre-release for beta 1.9 is "1.9 Prerelease", not "1.9-pre1" as I already mentioned in my first comment. "1.9-pre1" is what the wiki as well as the launcher currently use. – 20:35, 30 July 2017 (UTC)


 * How do we make these changes, then? ―  18:16, 31 July 2017 (UTC)

Account rename
Yesterday I have changed my nickname from NickTheRed37 to BabylonAS. Since I have already went through this process in late 2014 – early 2015 (when renaming from naista2002), this is the second time when my account has been renamed. But I am again meeting problems: this time, edits in the time span ranging from December 23, 2014 to February 6, 2015 (which is the time period of the “phantom account” issue that I had during the previous rename) are (but hey, at least [ the old user profile] is not present unlike in 2014/15). — <span class="nowrap"> ( | ru.Wiki Admin) (fka NickTheRed37) 07:12, 1 August 2017 (UTC)


 * And on top of that, I can’t use my new nickname when logging in to Gamepedia via centralized login page, only my email., , , can you resolve these problems? — <span class="nowrap"> ( | ru.Wiki Admin) (fka NickTheRed37) 07:33, 4 August 2017 (UTC)
 * Did this get resolved? -- 15:37, 2 September 2017 (UTC)
 * I didn’t check that. — <span class="nowrap"> ( | ru.Wiki Admin) (fka NickTheRed37) 16:07, 2 September 2017 (UTC)

is outdated
Notch's page on mojang.com was removed, so was the plash text about his birthday. undefined 13:56, 1 August 2017 (UTC)

Commons images
At, I used images from commons. They seem to have disappeared. Where have they gone? –    02:30, 2 August 2017 (UTC)
 * Seems to be fixed now... what happened? –    19:24, 5 August 2017 (UTC)
 * The issue has directly been forwarded to Gamepedia staff (you weren't the only one who noticed it) and been fixed last thursday. | 21:14, 5 August 2017 (UTC)

GIF rendering
Animated GIF images with frame disposal of "combine" are buggy when scaled. Those frames seem to retain the original size of the image, instead of the scaled size of the image. An example is, which I made the frame disposal to "replace", so it won't seem buggy. <font face="'Open Sans',sans-serif">– undefinedundefined 13:17, 3 August 2017 (UTC)

Should we create a dark theme?
Some time ago a trend for creating dark themes has established. One dark theme has been created for the, now also has one. There is a discussion on the Russian wiki about creating a dark theme. has created some styling for a hypothetical dark theme in his, but I would like to see a complete dark theme that is similar to the current default theme (which has been created by ), except being dark. (The direct request to Majr for creating a dark theme variant is .) Any ideas? — <span class="nowrap"> ( | ru.Wiki Admin) (fka NickTheRed37) 10:11, 9 August 2017 (UTC)
 * I would certainly love to see dark theme. This is something that has been missing on Minecraft Wikis since ever.  10:17, 9 August 2017 (UTC)
 * Sure, why not?  Sysop Minecraft Wiki Polska 14:39, 9 August 2017 (UTC)
 * I do not like dark themes but I don't think anyone can argue against having it as an option. If you want one, the hardest part is creating it.  15:01, 9 August 2017 (UTC)
 * As I already said at (Why did you create three seperate discussions for the same topic?), I already made a dark theme (sort of) on the German wiki as a Gadget. The problem with dark themes is that not only the skin has to be made darker, but also all of the UI elements which are white and not defined by the Minecraft Wiki skin have to be made darker, so they don't stick out. You'll never have a complete dark skin for a page which is intended to be white. |  17:05, 9 August 2017 (UTC)
 * It'll certainly take some work, but I don't think it is impossible. On the FTB Wiki, pretty much everything is covered by the dark skin, and seemingly covered well; both the other admins use it, as well a fair amount of other editors, with little complaint about certain parts being certain colors. The is not too monstrous. The Minecraft Wiki would probably have many more special cases than us, but how bad could it be?   19:42, 9 August 2017 (UTC)
 * I know that it's possible, it's just not very easy to style, especially if some colors are hardcoded in wikitext. | 11:54, 10 August 2017 (UTC)
 * Yeah, that all needs to be adjusted and whatnot.  19:50, 10 August 2017 (UTC)

did we just update our Mediawiki?
The save, show preview and show changes buttons now visually match the show preview button, and the refresh watchlist is async now. – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 23:20, 9 August 2017 (UTC)


 * Yes. There was a banner about it for at least yesterday.  --  23:31, 9 August 2017 (UTC)


 * Fail... maybe I shouldn't immediately hit 'hide' on those notices X( – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 03:11, 10 August 2017 (UTC)

What counts as minor edit?
First of all some personal semantics: I'd like to share how much I love being a part of all this. I seriously enjoy Minecraft and I also really like helping people. This is a good combination of that if you ask me. This wiki has been my favorite for many years, so yeah.. had to share :)

Minor edit => I just want to ensure that I'm on the right track here. For me a 'minor' edit doesn't necessarily account for how many lines I added (or removed) but more so for what I am editing. There are several pages on this wiki which I hold in high esteem so for me editing them is a big deal. Correcting syntax or spelling errors nearly almost accounts for a minor edit, but everything else definitely depends on context and contents.

I read Wikipedia's stance on all this, but I just want to ensure that those descriptions also apply here.

And thanks in advance for any feedback!

--  19:39, 12 August 2017 (UTC)


 * I call an edit minor if it only changes a few words, pipelinks, or is only a few bytes. –    19:40, 12 August 2017 (UTC)


 * My thought on this is that a minor edit is one where if you were reading the history, you wouldn't immediately care about it when checking the diff - as you mentioned, correcting typos, updating links for redirects (when needed), etc. It's also useful when rolling back vandalism.  There can be some large edits that make sense to mark as minor, but generally you wouldn't do that.  (I don't have a good example of this here, but over on wiki.vg, I used it when I manually redirected an old draft article in my userspace, which was a large edit in terms of bytes but not that large in terms of content) --  23:17, 12 August 2017 (UTC)

Mojang edits and official sources
The says that "Edits made by Mojang employees can be used as sources."

Meanwhile, since Minecraft was created by Mojang, this may cause a between Mojang employees and regular wiki users. Moreover, some unobvious information added by Mojang might not have any other referenced sources, which may cause doubt in that information’s verifiability. Because of this, I don’t think that equating Mojang edits to official sources is a good idea.

I suggest that edits by Mojang employees should be subject to the same verifiability guidelines any other edits. This means they should add references to reliable sources, like anybody else. Any thoughts? I’d like to invite as the most active Mojang employee on the wiki in the moment. — <span class="nowrap"> ( | ru.Wiki Admin) (fka NickTheRed37) 12:12, 18 August 2017 (UTC)


 * How would I verify something that I know but I can't link to because it's not publicly available? For instance, I know that Jason Major likes root beer but there's never been a news article or anything on him saying he likes root beer- but I know this because I work with him. How would I source that? How would I source something that goes into detail about how something works even if it's never been in a press release because it's not really something the press would care about? Or our documentation- we are literally just posting documentation on here rather than on another website because we feel (and I think rightfully so) that this is the best place to put our official documentation. -- 01:32, 6 September 2017 (UTC)


 * So like a tweet saying its true? Because an edit diff is the exactly the same thing. –    19:15, 18 August 2017 (UTC)


 * We have never had an issue in the past with Mojang employees adding information which shouldn't be here or is not correct. Some of the most common edits are correcting information on person articles as much of that is not known outside the wiki. In addition, its easy to cite it to a page diff. --– · 01:18, 19 August 2017 (UTC)


 * While it’s easy to reference an edit, it doesn’t make it more verifiable: it itself must have a source, or else its credibility will be subject to question. Also, edits by Mojang may cause a wrong impression of a wiki that is controlled by the studio, instead of being an independent community-driven project.
 * Requesting to participate in the discussion. — <span class="nowrap"> ( | ru.Wiki Admin) (fka NickTheRed37) 14:02, 20 August 2017 (UTC)


 * So for example they would have to tweet out their message and then reference their own tweet? Seems very silly to me. -- 14:04, 20 August 2017 (UTC)


 * I’m not sure should they ever add their information to articles at all. — <span class="nowrap"> ( | ru.Wiki Admin) (fka NickTheRed37) 14:09, 20 August 2017 (UTC)


 * I fail to see how a tweet or some other social network post is more trustworthy than a wiki edit.
 * Mojang can most definitely destroy any Minecraft-related site if they wish. We are not quite independent. -- 14:36, 20 August 2017 (UTC)


 * Do you seriously not want us to put official documentation up here and instead have to spin up a website just to do it? Also, I've been editing articles here and contributing before I was even an employee. We actually have a few employees who were wiki contributors before they were hired. So we ARE part of the community and have been part of this community project. I think it's actually pretty insulting and elitist to say that we have to stop contributing when we get hired as employees. We have more information to share, not less. -- 01:32, 6 September 2017 (UTC)


 * The Mojang employees don't hold any special powers on the wikis, I also fail to see how a tweet is different than edit. Both can come from verified source and are only different in terms of medium. Also, as to COI, I feel like gaming wikis are a lot less affected by conflicts of interests. Wikis about gaming focus on games, not politics, controversial topics, public figures. There is not much you can do to push your agenda/biases in here.  14:46, 20 August 2017 (UTC)


 * Are there any Minecraft employee edits in particular that seem to you like they need additional support, and can't be simply trusted on the word of that employee? A practical example. – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 16:01, 20 August 2017 (UTC)
 * And could you describe a realistic situation where a conflict-of-interest could occur -- what interests would be at stake and how could that arise? – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 16:03, 20 August 2017 (UTC)


 * In my (completely weightless) opinion: This isn't wikipedia. COI editing does not apply here. A "COI" where an employee fluffs up pages about the company or even just his own page to hypothetically make it look good for, I don't know, shareholders? won't have much effect. Nobody No visitor will expect this wiki to be unbiased towards minecraft, Mojang, or its employees. Additionally when information sourced by an employee-edit is contested by external sources it shouldn't be hard to weigh the two. On verifiability I agree with the consensus of the thread so far. 17:03, 20 August 2017 (UTC)


 * I'm still quite new here, but still wanted to comment.. I think we should be grateful for any update(s) done by Mojang employees instead of trying to apply (too?) much extra regulations on their efforts. Maybe a somewhat simplistic opinion, but in the end this is still their ballgame so to speak. Keeping this option open to them could even create the possibility where certain specific information finds its way here sooner than normal (just a theory of course). But most of all I'd like to go with: "If it isn't broke, why try to fix it?". -  03:20, 21 August 2017 (UTC)


 * This is a solution (given whatever you're proposing as a "solution" here; it's really not clear to me at all) in search of a problem. Edits by Mojang-controlled accounts are identical to tweets, Facebook posts, blog posts, etc: primary sources. If your concern is verifying that the account is actually controlled by a Mojang employee, the current practice of just asking for confirmation from already-confirmed accounts (either here or on Twitter, etc.) are more than adequate for the task. If your concern is instead verifying the content of edits, then what exactly would make any other source more reliable than edits on the wiki from verified accounts? I fail to see the problem you're trying to address, and it's clear from the other comments here that I'm not alone in that regard. <span class="nowrap">「」· 07:19, 6 September 2017 (UTC)


 * On the other hand, if we allow Mojang to edit, it will not be obvious that the text is actually added by Mojang and is considered an official statement. Also, it is possible that such text might be edited by other users, which will cause problems with verifying it. As a compromise, I suggest creating a template directly saying that a piece of text has been added or confirmed as an edit by Mojang, with the ability to reference specific diffs. — <span class="nowrap"> ( | ru.Wiki Admin) (fka NickTheRed37) 16:29, 19 September 2017 (UTC)
 * Otherwise, It would look like unsourced information. This especially works now that links to Mojang users have a special icon. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 14:24, 20 September 2017 (UTC)
 * if this were in the citation itself. Like or something.  Except it ought to have the capability to go grey, when they leave, for instance, so we may have reference the css class that handles this.  Does someone know if that's possible? –  <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 17:10, 20 September 2017 (UTC)
 * Sure, just use the class  in the link's text:, . Would probably be best to make a template so we are not typing user names three or so times, something like userlink is wh at I always called it as long as it disambigs from user or ping. <span class=nowrap>– ·  23:42, 12 October 2017 (UTC)


 * Support this as a method of verification, but only for things that actually need citations, not for literally every edit.  for use within citation tags. --  17:15, 20 September 2017 (UTC)
 * Yes, I mean edits that include information on versions, released products, upcoming content etc. Anything that would not involve referencing Mojang as an outer source doesn’t require this type of marking, because it can be done by any user. — <span class="nowrap"> ( | ru.Wiki Admin) (fka NickTheRed37) 15:05, 11 October 2017 (UTC)


 * So your concern is that an official account might make an edit, adding some information, then someone else might come along and edit that information to say something different, and subsequent readers/editors might point to the edited version as the official statement? Why exactly can't we just reference the edit made by the official account? There's no need for any special template for this. This is a wiki, and as such, with a few, limited exceptions, anyone can edit anything at any time; we don't worry about people inserting false information because it's trivially easy to check and revert, and people trying to twist edits made by official accounts is no different. But for starters, I might as well ask if you can point to any specific instance of this happening somewhere, either on this wiki or on the Russian wiki (or any of the other language wikis, for that matter). <span class="nowrap">「」· 01:17, 1 November 2017 (UTC)

parameter}} set to  in order to adjust the way a gallery looks like. By default, the images are scaled down to fit into small square white boxes, which makes it hard to see them on the actual page. In packed galleries, however, images take the most optimal size, which is larger than on the usual galleries. Here’s a decent comparison (gallery taken from the ): {| class="collapsible collapsed" ! Packed


 * <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 04:00, 21 August 2017 (UTC)
 * I haven’t experienced any problems with page jumping. Also, judging by the comment below, a packed gallery works good with small screens. — <span class="nowrap"> ( | ru.Wiki Admin) (fka NickTheRed37) 16:14, 21 August 2017 (UTC)
 * For me, the  mode is better than normal gallery in mobile view, due to small screens. <font face="'Open Sans',sans-serif">– undefined 10:09, 21 August 2017 (UTC)
 * I am experiencing some jumps on packed ones. undefined 09:54, 1 September 2017 (UTC)

Image requests
Where's the best place to go to request an image? ―  21:17, 27 August 2017 (UTC)
 * At . <font face="'Open Sans',sans-serif">– undefined 04:11, 28 August 2017 (UTC)

Welcome Bot
It would be better (for me) if there is a welcoming bot that welcomes all new users to the wiki, as not everyone involved in is not active (I think I'm the only one active as of now). <font face="'Open Sans',sans-serif">– undefined 11:17, 10 September 2017 (UTC)


 * . I think the welcome message should appear after the user made at least one edit to the wiki. If that possible though. – ⟨|⟩ 12:00, 10 September 2017 (UTC)
 * I accidentally visited the [//ms.wikipedia.org/wiki/Laman_Utama Malay Wikipedia], and [//ms.wikipedia.org/wiki/Pengguna:HsfBot a bot] has welcomed me instantly as soon as I entered into the wiki. ([//ms.wikipedia.org/wiki/Perbincangan_pengguna:LR_Guanzon source]) <font face="'Open Sans',sans-serif">– undefined 13:41, 10 September 2017 (UTC)


 * : I'm not a fan of welcoming people with a template (it feels soulless, you should write something yourself and not substitute a template!), but if it's done, it should definitely be done after someone makes their first edit (even Welcome docs say that!) - keep in mind you can make an account on any Gamepedia wiki accidentally, by just visiting it while logged in. -- 12:31, 10 September 2017 (UTC)
 * I would support a welcoming bot. However, there are many users who make no more than one or two edits. A welcome message is only useful if the user actually wants to join the wiki. Therefore, I would advise for the bot to give the welcome after a user has made five edits. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 14:52, 10 September 2017 (UTC)
 * Five edits which have not been undone by someone, because someone can simply create a vandalism-only account. <font face="'Open Sans',sans-serif">– undefined 14:58, 10 September 2017 (UTC)
 * Well, that goes without saying. If you vandalize you should get welcome message :P -   21:18, 10 September 2017 (UTC)
 * . IMO the message is threatening people who gets this message. <font face="'Open Sans',sans-serif">– undefined 16:09, 24 September 2017 (UTC)


 * I’m not keen on welcoming new users lately, but continuing to give links to key pages like community portal and rules manually can get old. I think templates can only be used with welcoming if they add a navigation box to these pages, pages with help information etc. These templates will be ideally integrated into a fully situative, manually written welcome message, which can reference what the user has exactly done.
 * I think users should be welcomed only when doing something significant, aside from minor edits like grammar fixes. — <span class="nowrap"> ( | ru.Wiki Admin) (fka NickTheRed37) 15:33, 25 September 2017 (UTC)

About Chinese Edition
Now many of apps on MCPE platforms have been putting off from stores in Mainland China. I'm thinking about creating a Chinese Edition page and it's in my sandbox in zh. Should it be an exclusive article only in zh or on every language? --  zh.patroller 02:06, 16 September 2017 (UTC)


 * IMO creating a single article about it on every language seems reasonable, but the actual version differences shouldn't be put into each individual article (e.g. there shouldn't be a notice on that it is only present in PC, PE, and console, and not in Chinese Edition), as that would get fairly cluttered for an edition that most would not play.  (A similar case would probably be, and maybe also ) --  02:13, 16 September 2017 (UTC)
 * . --  05:04, 16 September 2017 (UTC)


 * . – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 16:57, 20 September 2017 (UTC)

Change animated block/mob variants to tabs
Currently it cycles through different appearances of a block (for example wooden plank) or mobs (for example villager professions) but in case of for example wool it's inconvenient because there are so many variants of it. I suggest a tabs solution like they have on this wikia here: http://mlp.wikia.com/wiki/Starlight You can click specific tabs to see variants of the same entity. 14:33, 16 September 2017 (UTC)


 * If we manage to use the from, then something like that would be possible. By the way, it is suggested to use radio buttons for processing grids (like crafting) on the Russian wiki. — <span class="nowrap"> ( | ru.Wiki Admin) (fka NickTheRed37) 16:06, 16 September 2017 (UTC)

Custom programs for creating some files
created a custom program to automate the generation of. I guess it should also be done on, but I'm a newbie on coding , the programming language in which his program was created. <font face="'Open Sans',sans-serif">– undefined 05:26, 25 September 2017 (UTC)
 * Pinging some people:, , <font face="'Open Sans',sans-serif">– undefined 17:06, 5 October 2017 (UTC)


 * I think an entirely separate program, not necessarily based on Jocopa3's, would have to be made to generate Template1. I would guess that image has been built by hand, using image editors, and if that's the case, in my opinion it should continue to be done that way. –  <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 02:38, 6 October 2017 (UTC)
 * The reason for me recommending for a custom program is because it can make the generation easier, and it is rarely updated. The current and previous revisions have a date difference of 7 months, and it has still not been updated yet to the current version; one of the reasons is because it is hard to create via image editing softwares. <font face="'Open Sans',sans-serif">– undefined 11:44, 6 October 2017 (UTC)

Deleting an image
How do I mark an image for deletion? ―  18:43, 26 October 2017 (UTC)
 * Would it be acceptable to use delete on the page of that image? I'm not sure where to find guidelines for this either. – ( • • ) 18:51, 26 October 2017 (UTC)
 * Yes. -- 19:18, 26 October 2017 (UTC)

A change to
On this wiki, rule 4 currently prohibits the insertion of "parody/comedic/nonsense/hoax information". I personally find all those overly descriptive terms unnecessary, especially since in the context of wikis they all relate to the same thing: they are all acts of falsification. Therefore I propose that the rule be simplified to "false/hoax information". Who's with me? <em class="plainlinks" style="margin-left: 0.5em; font-size: 90%;">( • • [ logs]) 🐷🥕☮️ 19:54, 31 October 2017 (UTC)


 * I think it's important that the rule is concise and has covering as well, of all or most sub-intentions it could possibly mean. Making it concise makes it come off as firm, but have it cover most scenarios makes sure people can't cheat the definition. But most of all the rule should be enforced firmly as well. So I don't think it should be reduced, but it could possibly be reworded to split it into concise and full-coverage parts. – ( • • ) 20:41, 31 October 2017 (UTC)


 * WHY ARE YOU ALL IGNORING ME? <em class="plainlinks" style="margin-left: 0.5em; font-size: 90%;">( •  • [ logs]) 🐷🥕☮️ 17:09, 2 November 2017 (UTC)


 * Wow calm down, please give people some time to react. I gave you my own response straight away, others may be busy with other stuff or IRL stuff. It's going to be all right, just please be patient with communications. – ( • • ) 17:13, 2 November 2017 (UTC)


 * I don't see any benefit to be had from your suggested change; as currently worded, it seems perfectly clear and concise to me. And throwing a temper tantrum when people don't comment on your proposal (especially when only a couple of days have passed) is not going to win you any support. <span class="nowrap">「」· 18:35, 2 November 2017 (UTC)


 * Is that the reason why you are not supporting? <em class="plainlinks" style="margin-left: 0.5em; font-size: 90%;">( •  • [ logs]) 🐷🥕☮️ 21:27, 2 November 2017 (UTC)


 * I led my comment with my reason for not supporting. The second part was addressing your attitude and nothing more. <span class="nowrap">「」· 23:33, 2 November 2017 (UTC)


 * I bet you would have supported this had I not thrown that tantrum. Am I right? <em class="plainlinks" style="margin-left: 0.5em; font-size: 90%;">( •  • [ logs]) 🐷🥕☮️ 14:50, 3 November 2017 (UTC)


 * No. <span class="nowrap">「」· 20:07, 3 November 2017 (UTC)


 * You shouldn't even have addressed my attitude in the first place. With that said, could you please give a detailed explanation as to why you refuse to support my good idea? <em class="plainlinks" style="margin-left: 0.5em; font-size: 90%;">( •  • [ logs]) 🐷🥕☮️ 20:38, 9 November 2017 (UTC)


 * Anyone could have called you out on your attitude, and indeed Jack McKalling did before I commented. The same holds true for anyone sporting an attitude like that, even admins. No one is above criticism in this regard.
 * What part exactly of "I don't see any benefit to be had from your suggested change; as currently worded, it seems perfectly clear and concise to me" is not detailed enough for you? I could certainly add more words to that, but none of them would actually add anything to my statement. Other than myself and Jack, no one else has commented on this proposal, which is quite telling particularly because no one has commented to disagree with either of us. <span class="nowrap">「」· 20:49, 9 November 2017 (UTC)


 * I support keeping the text as it is. Parody, comedy, nonsense, hoaxes and false statements aren't equivalent concepts. –  <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 20:59, 9 November 2017 (UTC)
 * The rule needs no changes. <span style="font-size:50%; vertical-align:middle; text-align:center;"> 21:20, 9 November 2017 (UTC)


 * FYI, making a rule as descriptive as possible does not allow own interpretation all that easily. I think this rule follows that - describing exactly what should not be put on the Wiki. &lt;offtopic>We have that in the Netherlands. Every law has to be described as precise as possible, else people will likely make their own interpretation.&lt;/offtopic> Therefore I oppose to making rule #4 less descriptive, as it is better to have an overly-described one that does not allow own interpretation all that easily than one that is vague and *does* allow that. --<span class=nowrap> NL Admin ( ♦ ) 21:31, 9 November 2017 (UTC)


 * The thing is, I feel that all those words I propose to replace with "false" are already sufficiently covered by Rule #2 (Vandalism). Still unconvinced? Read ; more specifically, . <em class="plainlinks" style="margin-left: 0.5em; font-size: 90%;">( •  • [ logs]) 🐷🥕☮️ 21:50, 9 November 2017 (UTC)


 * (no ad hominem intended, I just don't know how to bring it differently) What you're basically saying, is that based on your feelings, rule #4 must be reduced to "false/hoax information", because rule #2 covers most of it. However, other people may feel or see it the other way, that rule #4 adds on to rule #2 or see rule #4 separate from rule #2 (I think most people do one way or the other, based on the discussion above).
 * (no ad hominem intended, I just don't know how to bring it differently) What you're basically saying, is that based on your feelings, rule #4 must be reduced to "false/hoax information", because rule #2 covers most of it. However, other people may feel or see it the other way, that rule #4 adds on to rule #2 or see rule #4 separate from rule #2 (I think most people do one way or the other, based on the discussion above).


 * Personally I would expand rule #4 to contain "...parody/comedic/nonsense/hoax or any type of false information...". This way it still forbids the insertion of those four things already present in the rule and it forbids the insertion of any type of false information that might've not been covered by those previous four.


 * Also remember that the insertion of "parody/comedic/nonsense/hoax information" may have been from people with and therefor it cannot be just "vandalism/spam/disruptive editing". However, if they do continue to insert false information, even after (kind) messages or warnings to not continue these practices, then, and only then, it may be considered as vandalism, spam and/or disruptive editing. I'm not saying that every rollbacked edit is from someone with good intentions, however. --<span class=nowrap> NL Admin ( ♦ ) 01:08, 11 November 2017 (UTC)

AWS migration
On November 14th (Tuesday), this wiki will be read-only for ten hours as the wiki migrates to AWS (see ). This was announced on the Gamepedia Slack but many/most of you aren't there, so here it is since I don't think any admin announced it. -   20:56, 9 November 2017 (UTC)
 * Aah, good call announcing it here. <span class="nowrap">「」· 20:57, 9 November 2017 (UTC)


 * Thanks for letting know. I was actually still awaiting news about this, having seen the gamepedia notice, wondering about the ETA and duration. A lot of other wikis had already been moved. I also wondered whether this would have any additional benefits, or if it would just allow more wikis to be created or something? – ( • • ) 21:30, 9 November 2017 (UTC)


 * Easier for them to expand and be faster and whatnot. Cheaper, since they have the "family" discount (Amazon owns AWS and also Twitch which owns Curse which owns Gamepedia). -   01:47, 10 November 2017 (UTC)


 * Is there any information on the exact time of the beginning of the migration process? Will such information be made available later?
 * Should a site notice be written (at least on non-English wikis)? -- 09:37, 10 November 2017 (UTC)


 * They haven't given any information on the exact time, no. It'll probably be some time around when Californians are awake, but I imagine they don't want to give an exact time so they can be as ready as they need to before going ahead with it. As for a site notice, I'd personally recommend it on all wikis, but only the day before or early on the day. -   13:56, 10 November 2017 (UTC)

I have a problem with Minecraft Korean WIKI template:Crafting...
Hello. I am a user of Korean version Minecraft WIKI. I'm sorry but, there are some problems that we couldn't solve in Korean Minecraft wiki, so I am writing to ask for some help. The following link is about Fermented spider eye. https://minecraft-ko.gamepedia.com/%EB%B0%9C%ED%9A%A8%EB%90%9C_%EA%B1%B0%EB%AF%B8_%EB%88%88 However, Crafting recipe(제작 재료) image is not displayed... It is just an empty space. I and other users add many module and template for it, but it still does not appear. Could you help me? Anyone who know the solution please leave a comment here or edit the Korran minecraft wiki... Thank you. -- 14:29, 13 November 2017 (UTC)
 * I am sorry that I'm not good at English..


 * Hmm... After I had a look into the code that generates the layout and such for the template, it appears to me that no CSS styling is associated with classes and id's the template uses. This is supported by the fact that no style rules for those classes and id's exist in either your  or . I hope that helps. --<span class=nowrap> NL Admin ( ♦ ) 15:54, 13 November 2017 (UTC)


 * Edit: The code needed, is present at on this Wiki. It can be found under   and then from subsection   to subsection   (or, when you don't want/need hotbar-specific styling, to subsection  ) --<span class=nowrap> NL Admin ( ♦ ) 16:28, 13 November 2017 (UTC)


 * Thank you for your help! I'll try the method and let you know the results later!--  12:58, 14 November 2017 (UTC)


 * The picture problem was solved!  But could I ask you one more question? At the template:Crafting of the above fermented spider eyes, when I mouse over the item icon, the box showing the item name does not appear. Do you know why?


 * P.S:Thanks for your help!-- 07:48, 15 November 2017 (UTC)


 * I'll have a look into it in about 6-7 hours, as I have something else to do now. --<span class=nowrap> NL Admin ( ♦ ) 07:53, 15 November 2017 (UTC)


 * OK. Thank you.-- 08:21, 15 November 2017 (UTC)


 * I think I've found the culprit. Everything appears to be working correctly, only the tooltip's JavaScript appears to be outdated. The updated code can also be found on this Wiki, in, under section.


 * Depending on whether or not you have JavaScript enabled and if everything goes well, you should either see a fancy, Minecraft-like tooltip or just a plain one like you have currently.


 * (Though not very useful for Wikis using non-Latin scripts, but importing the Minecraft font in the CSS might be a good idea, just in case...) --<span class=nowrap> NL Admin ( ♦ ) 14:25, 15 November 2017 (UTC)


 * Thank you very much! It is well solved and is now normally displayed. Thank you very much for your help.-- 09:06, 16 November 2017 (UTC)


 * I'm glad it worked the way you wanted it to work :) --<span class=nowrap> NL Admin ( ♦ ) 16:03, 16 November 2017 (UTC)

How to implement "Edit Sprite" tabs as in Template:BlockSprite?
It would be a very handy if the feature is implemented in the Korean Wiki. -- — ko.Admin 16:55, 14 November 2017 (UTC)
 * It seems that there is no [//github.com/HydraWiki/SpriteSheet SpriteSheet] extension installed in the Korean wiki. Probably you can (let someone) have it installed in the Korean wiki.
 * You can check the list of extensions installed in a certain wiki by going to its . <font face="'Open Sans',sans-serif">– undefined 09:55, 17 November 2017 (UTC)


 * We do not really use the sprite sheet extension last I checked. The sprite editor is handled through Javascript instead. <span class=nowrap>– · 05:33, 18 November 2017 (UTC)


 * Yes, the gadget is responsible for visual sprite editing. Such a gadget  on the Russian wiki, but I’m not sure does it work correctly, maybe because no sprite editing has been made lately. — <span class="nowrap"> ( | ru.Wiki Admin) (fka NickTheRed37) 16:57, 18 November 2017 (UTC)

Edit other people's user pages for maintenance tasks?
Although the wiki warns you if you attempt to edit someone else's user pages, I don't know how strict I should interprete this warning. What if there is a maintenance task I'd be working on like eliminating non-existing template calls on pages, and someone has one such red link on one of their user pages, am I supposed to leave it there then because the page is not mine? Or am I allowed to edit user pages for that kind of purposes if it fixes red links (and thereby reduce clogged up special pages)? Secondly, is there any policy I could read up about this, maybe on wikipedia, and would the same policy apply to all (minecraft) wikis or would it be unique to every wiki? – ( • • ) 10:29, 20 November 2017 (UTC)
 * A cursory search on Wikipedia policy pages led me to . This paragraph only mentions significant edits. I am unaware of actual Wikipedia practices on maintenance edits in others' userspace.
 * Personally, I see no reason whatsoever to prohibit editing others' user pages for maintenance purposes. Especially if that user is inactive for a long time and/or cannot be reached. -- 10:41, 20 November 2017 (UTC)
 * . <font face="'Open Sans',sans-serif">– undefined 10:53, 20 November 2017 (UTC)
 * Ok, thanks. This will help me perform some maintenance on a lot of red links. – ( • • ) 11:44, 20 November 2017 (UTC)
 * I suggest creating a to speed up this process. – undefined 12:56, 20 November 2017 (UTC)

Deleted pages
Now that I've read through the pages you mentioned, I'm still wondering about certain red links in particular that I've come across, however. If someone mentions a template using tl, and the template has been deleted afterwards (not just when it is moved), creating a red link there, I wouldn't be able to resolve the link by renaming or removing it. The link would be discontinued altogether, but it would still show up in. I've noticed this often happens on old talk pages, in the middle of a discussion. It would not be advised to edit such links, but what else could I do then? – ( • • ) 11:44, 20 November 2017 (UTC)
 * Instead of deleting those, you can simply comment them out (enclose them in  and   tags). <font face="'Open Sans',sans-serif">– undefined 11:57, 20 November 2017 (UTC)
 * There is also tcode (which does not create a link), but it's not widely used. -- 12:01, 20 November 2017 (UTC)
 * Thanks, both of those methods could work for me. Awesome! – ( • • ) 12:05, 20 November 2017 (UTC)

Translated pages
I'm sorry if this is getting annoying, but I really like to be absolutely sure about what I do or should do. When I attempt to work on the task of eliminating red linked template calls, usually I use the special pages to form a list. But on this English wiki, this list is totally cluttered with template calls on translated subpages, like, which calls the non-existing. Although I can see these translations are very old and also have their own interwiki (by now), and that these subpages could possibly be moved or removed altogether from the English wiki, I don't necessarily want to become involved in their translation process. There are a lot of these pages, and they are making our unusable. What could be done about these unused, "clutter" pages, all having non-existing template calls? – ( • • ) 12:21, 20 November 2017 (UTC)
 * Since some of them already have their own interwiki by now, I think you are allowed to remove these links, but only to the links which are supposed to be part of these interwikis, to avoid conflicts. – undefined 12:26, 20 November 2017 (UTC)
 * Actually, my above example was not an instance that has its own interwiki, I cannot find the "minecraft-ua" wiki. I did find an example that does, like using, eventhough there is an [//minecraft-it.gamepedia.com Italian interwiki]. But I'm wondering more about those UA subpages, because there are a lot of them, probably because they should create an interwiki instead. –  ( • • ) 12:36, 20 November 2017 (UTC)
 * Be careful in your example,, that's the Lithuanian language project, not Italian. – <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">undefined/undefined 12:49, 20 November 2017 (UTC)
 * Woops! The i was atually an L, I'll remember that when searching for appropriate translations next time. – ( • • ) 15:12, 20 November 2017 (UTC)


 * If a translated page is old enough, it may be removed so that a user may be able to translate the latest version of the English page into their chosen language. This also reduces the red links. – undefined 12:53, 20 November 2017 (UTC)
 * I could swear I remember that templates weren't supposed to be translated until a project got its own subdomain... If that was the case, I could see it being inconsistently enforced, though.
 * If you come across translation subpages for languages that have their own subdomain, double-check that the page is on the language's wiki, and if it is, tag the subpage here for deletion. There's no reason for us to keep copies of these pages when there's already a dedicated subdomain for them. <span class="nowrap">「」· 15:14, 20 November 2017 (UTC)
 * Ok thanks, I will check up on that. But if a language doesn't have their own interwiki/subdomain yet, they're not supposed to translate templates yet, and I can resolve their template red links on these subpages here by modifying them to point to our english versions? – ( • • ) 15:21, 20 November 2017 (UTC)
 * That's just how I remember things; I would want to find a discussion in which that is explicitly stated before I was comfortable enforcing it as a rule. Hvaing just checked, I didn't see anything relevant mentioned on . <span class="nowrap">「」· 15:32, 20 November 2017 (UTC)

Problems with Wiki
Today, the look of the Minecraft wiki changed. Of course, the look by itself would be fine, but it also removed a lot of editing features and created many loading problems. It made it much harder to access subpages, because they aren't shown at the top of the page anymore, and did not allow visual editing - anytime I clicked on "Edit", it would stay at the reader's point of view. Also, when I tried to edit the source, which is the only editing available right now, there was no tool bar, which makes it very difficult to add images or references. Finally, ever since the look changed, the Minecraft wiki is loading much, much slower, and a lot of the time when I click "Show Preview" or "Save Changes" after an edit, it says that an error has occurred. All of this started just today.

Is the Minecraft wiki like this for anybody else, or is it just my personal computer? Also, does anybody know why this is or if there is a solution to it? Thanks. 14:45, 25 November 2017 (UTC)Madminecrafter12  14:45, 25 November 2017 (UTC)
 * Gamepedia wikis experience many problems right now. Up to the point where I need to look at recent changes with the API. Nothing we can do. Gamepedia staff is aware of all of the issues.  17:10, 25 November 2017 (UTC)
 * Good to know, thanks for clarifying!  19:44, 25 November 2017 (UTC)
 * Should be all good now!  20:00, 25 November 2017 (UTC)

Block renders.
Does anyone know who creates the block renders on the wiki and how they're created? -- 18:03, 27 November 2017 (UTC)
 * This page might be helpfull for you ;) . –Preceding unsigned comment was added by ( • ) at 19:12, 27 November 2017 (UTC). Please sign your posts with
 * Yes, thank you very much :D. -- 20:20, 27 November 2017 (UTC)

Demoting inactive admins
Currently, there are [ 12 admin accounts] (ignoring the special account, the staff accounts and , and Majr's adminbot ), of which five have not edited or performed any log actions in the past year (and of those five, four have been inactive for at least two years). A complete list of current admins, with date of their last edit or log action, follows: I propose to demote admins who have been inactive for a year or longer, as well as admins who have an extremely low rate of activity and haven't made use of any admin tools in at least a year. In these cases, a message would be left on the user's talk page, and (if possible) emailed to them, telling them their admin usergroup is about to be removed, and they would be given a month or so to respond if they wish; answering that they want to keep the group would be enough to prevent it from being removed. In addition, any admin who had their group removed purely because of inactivity would be able to request it back if they become active again.
 * - July 30, 2014
 * - today
 * - last month
 * - November 27, 2013
 * - June 22, 2011
 * - December 11, 2013
 * - September 27, 2016
 * - last month
 * - last week
 * - yesterday
 * - April 2, 2017
 * - January 19, 2017

The accounts who would immediately be eligible for demotion under this procedure include the five admins who've been inactive for at least a year (Citricsquid, Hower64, IKJames, Kanegasi, Kizzycocoa), as well as the three who've had a very low level of activity without any admin actions for a year (Oliver Scholz, Powup333, Quatroking). In the case of Citricsquid and Quatroking, their bureaucrat and checkuser usergroups would also be removed, and they would be able to request the groups back at any time, just like with the admin group.

For those accounts who are not admins/bureaucrats on (Hower64, IKJames, Kanegasi, Kizzycocoa), this demotion would also include removal of the Directors usergroup. Activity on other wikis isn't being considered either; it's not my goal to implement this on any wiki but the English one (though other language wikis who want to implement their own inactive admin demotion process should feel free to do so regardless).

Note that this was inspired by (where I also cobbed a lot of the details for this initial proposal from), and the 's similar process (though I don't have a relevant link for it); both of these have been running for some time now without apparent issues. Thoughts? <span class="nowrap">「」· 19:05, 27 November 2017 (UTC)


 * Sounds reasonable to me. To be clear, I wouldn't consider this as any sort of punishment for being inactive – life circumstances and interests change over time. (Personally, I know I don't have as much time to spend here as I used to.) Rather, it's de-cluttering the list of admins and making the wiki friendlier for new users. The abuse filter and other messages direct users to contact an administrator for assitance; if they try to contact an admin who hasn't been active in years (and possibly no longer uses the email address on file), they aren't likely to get a helpful response. I agree with the reinstatement policy: they've all proven trustworthy enough to be admins in the past, so if they want to be involved with the wiki again, I see no reason not to let them. -- undefined 20:17, 27 November 2017 (UTC)


 * Yes, I probably didn't make it clear enough myself, but this wouldn't be a black mark on an admin's file or anything of the sort; being demoted for inactivity would be a purely procedural affair and shouldn't reflect on the admin themself.
 * Another argument for doing this is security: having inactive accounts lying around with these extra permissions is an unnecessary risk, in the event e.g. an account is compromised; or if a formerly-active admin has become disillusioned with the franchise or community or whatever, and decides to use their account's extra privileges to vandalize, or give it to someone who will; etc. <span class="nowrap">「」· 20:28, 27 November 2017 (UTC)
 * This all sounds appropriate to me ^^ -   23:15, 27 November 2017 (UTC)


 * This also sounds reasonable to me, especially since it would more accurately represent the amount of admins on this wiki. It is worth asking what would happen with Citricsquid's and Quatroking's rights on other language? In addition, I assume director rights would go with that? – · 05:23, 28 November 2017 (UTC)


 * I explained both of those in my opening: this would have no effect on other language wikis (though they'd be perfectly free to pursue demotions for inactivity themselves), and Director would be removed from admins if they have no rights on any other wikis. <span class="nowrap">「」· 06:03, 28 November 2017 (UTC)


 * Oh, missed that one paragraph. – · 06:45, 28 November 2017 (UTC)


 * Looks good. A similar proposal is requested on the Russian Minecraft Wiki by AttemptToCallNil. — <span class="nowrap"> ( | ru.Wiki Admin) (fka NickTheRed37) 14:28, 28 November 2017 (UTC)


 * Can you link the Russian proposal, by chance? <span class="nowrap">「」· 19:17, 28 November 2017 (UTC)


 * was actually inspired by this one. -- 20:05, 28 November 2017 (UTC)


 * Aah, thanks for the link. Looks like both proposals are on-track to be implemented. (Also, good idea pointing out that admins will need to answer on-wiki whether they want to keep their rights or not; I thought about that after the discussion here was underway.) <span class="nowrap">「」· 20:24, 28 November 2017 (UTC)


 * Sounds good to me, for the reasons stated above. - (&#124;)  19:01, 28 November 2017 (UTC)


 * Sounds good to me too so far, but I wonder about a few things. What describes inacitivity exactly, or how do we decide when it is in effect? How exactly do we detect it, like by automated signal from the system or by manual inspection? And who detects it, a bot, a random user, or another admin? What is exactly done, when, and by whom, and where would we describe this process publicly? What if there is no active admin left to change user groups, that by some chance the last admin has become inactive by our previously determined definition? Will there be exception possibilities to inactivity? Lots of questions, but I guess that'd be the perfectionist in me and maybe not necessary ones. – ( • • ) 20:46, 28 November 2017 (UTC)


 * Everything's handled manually; we don't have enough admins to justify getting anything automatic set up (unless someone with the ability to do so, really really wants to).
 * As I explained above, "inactive" means no edits or log actions for at least a year, or a very low level of activity in the past year, without any admin actions in that time. This is determined just by looking at the admin's contributions and log actions. Anyone can check for inactive admins in this way, though there's no real reason to check very often.
 * Inactive admins are notified on their talk page (and by email, if they have it enabled) and given a month to respond; if they don't respond, or they answer saying to go ahead and remove their rights, a bureaucrat will remove the admin group, any other privileged groups (bureaucrat and checkuser currently), and (if the inactive admin is not an admin/bureaucrat on any other-language Minecraft wikis) the director group. If they answer instead that they want to keep their rights, the process stops there for them and they won't be demoted at that time.
 * Unless someone wanted to write up an administration/administrator project page where this could go, for now probably this discussion will serve as the public description of the process. If someone can point out a page we already have where it would be a good it, that would also be an option.
 * Even if all current admins/bureaucrats end up inactive for a year (pretty unlikely, but not impossible), staff can still remove rights if that's what the community wants, and then later promote someone else to admin/bureaucrat.
 * I think that's everything, please let me know if I missed something or if I didn't explain something very well. =) <span class="nowrap">「」· 22:05, 28 November 2017 (UTC)


 * Hello, inactive admin here. I hold no strong objections, though it will be a shame, having worked on this wiki for quite some time.
 * I was kept on, because the old Gamepedia rep Wynthyst (Rest in peace) said that it was useful to have old admins on the books, in the case of emergencies. I've been open to step in during such emergencies. but, I doubt I will ever retain any full-time moderation here. If it is the policy of the Minecraft Wiki to remove my adminship, I've no objections.
 * my only concern is that, in being demoted, I will no longer be able to pop in now and then to curate the Herobrine page specifically, of which I have quite a history. I was banned by fellow mods at least twice for creating the page, in an attempt to address "Herospam" (which, as I predicted, is now largely ancient history, as the page eradicated any need to vandalise other pages). I have also run interviews for the page with previous community figures who were involved in the initial hoax. I am a trusted editor for that page, and will not vandalise it. It is one of my proudest contributions to the Minecraft community, second only to the in-game implementation of Cake after my Quest for Cake campaign on ModDB.
 * If it is within the admin's power at all, I would like to retain access to that specific page so I can do some cleanup on it as and when updates arise and I find myself on the MCWiki, viewing that page. Beyond that, I do not feel I will need any access to the admin tools in the long run, unless I am needed in an emergency. So again, if it's the policy of the MCWiki, I have no objections to being demoted. --<font color="blue" style="text-shadow: 0px 0px 8px #00FF00;"> 03:22, 29 November 2017 (UTC)


 * Keep in mind that being demoted for inactivity isn't a black mark on you as an editor; it would be purely procedural and you could ask for the right back at any time if you needed it again. =)
 * I note that the protection on hasn't been touched since mid-2011; I'd be willing to try and see if it can be lowered to semi now, if no one thinks that would be problematic. Another option would be for you to retain the Directors group, which would allow you to continue editing Herobrine (and other protected pages) without requiring the protection level to be dropped. <span class="nowrap">「」· 04:26, 29 November 2017 (UTC)
 * Oh, not at all. I fully understand this isn't a black mark. People just, shift interests. I was interested in Minecraft, then drifted onto Portal, then FNaF and now, sorta drifting a little. these things change.
 * I would strongly advise against unprotecting Herobrine. I feel that page is a vandalism magnet, and that allowing it to be edited would be a bad idea.
 * I would be perfectly happy with the Director solution, provided this is not objectionable to the Minecraft Wiki community and moderation. --<font color="blue" style="text-shadow: 0px 0px 8px #00FF00;"> 12:26, 30 November 2017 (UTC)
 * I'd like to second this suggestion (in relation to keeping Herobrine protected). I've seen what the name 'Herobrine' can do on the forums and if not a vandalism magnet then I cannot help share my worries about pranks and such. Some topics can be toxic.  14:32, 30 November 2017 (UTC)


 * Yeah, I agree the director solution would make sense. You are easily reachable and still use your account, so it is not like it is admin rights lying around on an inactive account. I also feel like with your editing style, unless you plan to stay for awhile, requesting rights back to make one quick edit is not really practical (might as well request the edit), so I support you keeping the ability to edit . <span class=nowrap>– · 19:41, 30 November 2017 (UTC)


 * Sounds reasonable to me as well, however I do want to make one comment: do be careful that we don't favour quantity over quality. With this I'm specifically referring to the second part of the suggestion regarding "low rate of activity", sometimes quality heavily outweighs quantity. However, I definitely agree that no activity within one whole year easily accounts for that. But still wanted to share.  13:04, 29 November 2017 (UTC)

Merge with
Just want to get some more opinions on it, see. A user named has also been trying to make pages for the smooth blocks that finally got an item form in the 1.13 snapshots (but were in the game as blocks for a while). I think these smooth blocks can just go under the block page they are the smooth "variant" of, no need for a separate page. -- 12:38, 9 December 2017 (UTC)

I have a problem with Korean wiki, So I would like to ask for help.
Hello, I'm a korean wiki users. I need some help, so I write this article. At the Obtaining(구하기) section In the Mushroom (block) page in korean wiki, the color of the table(red, green etc.) is not displayed and strange words('style="background:') are displayed. Other documents(Documentation of template:version, too. Why happens this problem? I couldn't find the answer. Anyone who know the solution please leave a comment here. Thank you. –Preceding unsigned comment was added by ( • ) at 7:18, 13 December 2017 (UTC). Please sign your posts with
 * I added the english names back to because they are used by some templates. That fixed your problem.      08:09, 13 December 2017 (UTC)
 * Thank you! Now it works fine !! Thank you for editing :-)-- 12:01, 13 December 2017 (UTC)

Second level horizontal lists no longer use small font
<div class="hlist" style="display: table; border: 1px solid blue; padding: 4px; background-color: rgba(0, 0, 0, 0.15)">
 * L1_1
 * L2_1
 * L2_2
 * L2_3
 * L1_2

produces:

<div class="hlist" style="display: table; border: 1px solid blue; padding: 4px; background-color: rgba(0, 0, 0, 0.15)">
 * L1_1
 * L2_1
 * L2_2
 * L2_3
 * L1_2

(The styles are to differentiate the output from the rest of the text.)

There's also an extra space after opening parentheses of such lists which can be removed if the first sublist element is written without any space after the initial asterisks.

There is also some extra space before closing parentheses which cannot be selected or removed via code formatting changes. -- 19:16, 15 December 2017 (UTC)
 * Edit: I primarily meant navboxes. I definitely recall them using small font for inner lists. -- 19:23, 15 December 2017 (UTC)


 * Don't you mean third level horizontal list that is made smaller?

<div class="hlist" style="display: table; border: 1px solid blue; padding: 4px; background-color: rgba(0, 0, 0, 0.15)">
 * L1_1
 * L2_1
 * L2_2
 * L3_1
 * L3_2
 * L2_3
 * L1_2


 * namely produces:

<div class="hlist" style="display: table; border: 1px solid blue; padding: 4px; background-color: rgba(0, 0, 0, 0.15)">
 * L1_1
 * L2_1
 * L2_2
 * L3_1
 * L3_2
 * L2_3
 * L1_2
 * which, to me, seems like it has always been the case. Second-level horizontal list is put between parentheses and normal font size and third-level horizontal list is put between parentheses and smaller font size. As for the spaces between the parentheses and the text, I think it is a CSS issue (especially the right parenthese), likely something with  in several CSS rules that determine how the horizontal list looks like. --<span class=nowrap> NL Admin ( ♦ ) 19:35, 15 December 2017 (UTC)
 * Doesn't that mean navboxes used to use third level lists? Or am I too tired to remember correctly, and typical navbox sublists were never written in small font in first place? -- 05:43, 16 December 2017 (UTC)


 * I do recall seeing some navboxes using third level lists in the past. It seems they don't use the third level lists anymore, maybe because the text was a tad too small to click or tap on properly. At least, for navboxes that are used on most pages. Navboxes from mod, for example, do use third level lists and maybe some other mod pages too. --<span class=nowrap> NL Admin ( ♦ ) 13:40, 16 December 2017 (UTC)


 * The spacing that is mentioned has been changed recently to fix a small issue in navboxes, see . – <span class="plainlinks" title="Jack McKalling's User Profile">[ <span class="gamepedia_pro_user">Jack McKalling ] [   ] 13:53, 16 December 2017 (UTC)