Minecraft Wiki talk:Community portal

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

Achievement Images

Heyo, I recently decided to start working on changing the images for the achievements to what they look like now, rather than what they used to look like on PC Edition. I now have all the images required ready for upload but that's where the problem is. As much as I'd love to say "I have uploaded more than 102 of the images used on the wiki", there'll still be much difficult actually uploading all 102 images. I could proceed to upload these images seperately, but what I'm thinking we could do is (if possible) create a template similar to InvSprite.png, and then use that, so that we would have all 102 achievements in just 1 file. So, what I'm asking here is, is it possible to create a template for it similar to InvSprite.png, and if it is, is that what we should do? LevitatingSheep (talk) 10:59, 18 June 2017 (UTC)

Templates have other benefits too, like reducing the number of image requests from the browser to the server. With the setup we have at the moment, it requires them all to be the same size. Are all the images the same size? And what size is that? It occurs to me that PlayStation and Xbox and pocket and wiiu trophies might be different sizes and different visual styles. – Sealbudsman ^talk/_contr 17:08, 18 June 2017 (UTC)

All the images are the same size except for "Collect All Trophies" achievement for PlayStation, which can easily be downscaled. The images are all 188x188(except PS Trophy one) and should(if possible, i still dont know how it sprite sheets work) be displayed as 47x47 on the page, Sealbudsman. -- LevitatingSheep (talk) 16:39, 20 June 2017 (UTC)

LevitatingSheep there's now a {{AchievementSprite}} template that takes 188x188 images and displays them by default at 47x47. You can go ahead and use the Edit Sprite button at the top of that page to 1. change the image and name from 'dummy' to a real advancement and 2. upload the rest of the advancements. I would recommend using an all-lowercase name with spaces instead of dashes, that directly matches the actual achievement name, for instance, bake-bread or getting-an-upgrade. It will make it easier to integrate with {{Achievements}}.

From there me or someone can figure out how to integrate it with {{Achievements}}. – Sealbudsman ^talk/_contr 20:11, 20 June 2017 (UTC)

Cool, I'll work on getting the images stiched together into a sheet now, thanks! LevitatingSheep (talk) 04:44, 21 June 2017 (UTC)

You misunderstand, the images are individual. The sprite editor stitches them together. –Majr ᐸ Talk
Contribs 07:10, 21 June 2017 (UTC)

Well then I still don't quite understand. What am I supposed to do now? (also, sry for late reply, wiki kept telling me I was having "session problems") LevitatingSheep (talk) 16:26, 21 June 2017 (UTC)

If you go to the {{AchievementSprite}} page, there's a button at the top, Edit Sprite. It puts the page into a different edit mode, a sprite-sheet editing mode. Using that method you don't have to edit the module file that hooks up the sprites to their names, and you don't have to do any image editing of the larger sprite sheet itself. You just upload individual sprites and name them, one at a time.

Once in Edit Sprite mode, scroll to where (right now) it says "dummy". That's a placeholder name I put there, that refers to position 1. Click on the image and a menu will come up, it will have an option like "upload new image". Then you would pick the file from your computer. To rename a sprite, just click it's name and type.

To add new ones, there's a button on the green bar named "new image". Each additional achievement can be uploaded and named this way. You can upload all 102 if you want, and preview the names you want to give them, before hitting Save, up in the green bar.

Gamepedia is going to have some issues where after you save, it's not going to show you the new image and sprites until it works its way through the cache, which can take a number of hours. That is the case whether using the sprite editor or not. – Sealbudsman ^talk/_contr 20:21, 21 June 2017 (UTC)

In case it isn't clear: you can select multiple images at once, or just use drag and drop, it doesn't need to be done one-by-one. The sprite names will be whatever the file names are (minus extension), so you can save yourself some time by appropriately naming the files before adding them. –Majr ᐸ Talk
Contribs 07:23, 22 June 2017 (UTC)

M'kay I did it right this time. But how do I add it to the Achievements page? LevitatingSheep (talk) 07:02, 23 June 2017 (UTC)

I just done adding it into the page. But all I see is just a tiny little-sprite and a blank image all around the place. I don't know what's going on. – ItsPlantseed ⟨₰|₢⟩ 11:08, 23 June 2017 (UTC)

Cache is what's going on, but my cache problems seem to have cleared up now. LevitatingSheep (talk) 22:58, 23 June 2017 (UTC)

Just got cleared up for me. But at the {{AchievementSprite}} appears to be an error, and the icon were offset from its original image. – ItsPlantseed ⟨₰|₢⟩ 23:07, 23 June 2017 (UTC)

Well it appears that cache is still going on, and that IP addresses seem to have a lot to do with it. When I said they looked fine to me, I was visiting my grandma, and then when I've come home, they're not only still caching, but also appear distorted. So I went back to my grandma's to get my theory confirmed and yup, it's some serious cache issues that is going on rn. LevitatingSheep (talk) 10:26, 24 June 2017 (UTC)

That's just your client-side cache, hitting F5 on the page will fix that. We're talking about cloudflare's server-side image cache (that we have no control over), which is completely separate. –Majr ᐸ Talk
Contribs 11:06, 24 June 2017 (UTC)

I would support a sprite sheet. There may be other times when a bunch of sprites need updating at once. The Blobs 22:04, 18 June 2017 (UTC)

What kind of image? The icon itself, or with the plain like File:The Deep End.png? If without the plain, the sprite scale must be 32×32. Nvm, but {{achievement}} will be useless now. – ItsPlantseed ⟨₰|₢⟩ 05:11, 21 June 2017 (UTC)

Yeah, technically redundant since all pages use either {{achievementSprite}} or {{advancement}}. Since the functionality is practically the same, would there be any issues with just redirecting it to {{advancement}}? Otherwise it can be marked deprecated and eventually deleted. –KnightMiner · (t) 20:10, 1 July 2017 (UTC)

Error: String exceeds 1,000 character limit.

Just like at Mods#Bugs -> Crash Report. Probably remove the character limit? DentedHarp90041^tc 10:49, 19 June 2017 (UTC)

@Blobs2:: 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 Template:Cr. Special:Diff/1113606 should have removed that restriction, but may have re-added another bug (that parser function was added in Special:Diff/372264, 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. --AttemptToCallNil (report bug, view backtrace) 15:12, 19 June 2017 (UTC)

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

Porting templates with variables to Scribunto

If a template is using #vardefine and #var 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 mw:LUAREF.

And another (somewhat related) question: can there be technical reasons not to port a template to Scribunto? --AttemptToCallNil (report bug, view backtrace) 21:06, 25 June 2017 (UTC)

Edit: missed that frame:callParserFunction() has return values. --AttemptToCallNil (report bug, view backtrace) 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. –Majr ᐸ Talk
Contribs 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). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 17:54, 30 June 2017 (UTC)

Actually, state can be preserved by using DPL vars, as is already used in Module:Recipe table. –Majr ᐸ Talk
Contribs 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). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 17:42, 1 July 2017 (UTC)

Low InvSprite quality

The InvSprites 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? | violine1101^(Talk) 14:50, 30 June 2017 (UTC)

I don't think it has low quality. Probably your cache is outdated. – DentedHarp90041^tc 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 //instart.cursecdn.com/minecraft.gamepedia.com/4/44/InvSprite.png when I use Firefox, which is the one with the lower quality. The sprite background when using Edge or Chrome is //hydra-media.cursecdn.com/minecraft.gamepedia.com/4/44/InvSprite.png which is fine. Gamepedia seems to mess things up. | violine1101^(Talk) 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). --AttemptToCallNil (report bug, view backtrace) 10:10, 1 July 2017 (UTC)

And when I try to save this section, hydra-media.cursecdn.com is always replaced by instart.cursecdn.com. Weird. | violine1101^(Talk) 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 MediaWiki:Common.css (first added). –Majr ᐸ Talk
Contribs 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. | violine1101^(Talk) 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. –Majr ᐸ Talk
Contribs 11:42, 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.
It's not on the German wiki though, only here. | violine1101^(Talk) 11:52, 1 July 2017 (UTC)

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? –Majr ᐸ Talk
Contribs 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. | violine1101^(Talk) 12:24, 1 July 2017 (UTC)

Yes, I see it on both. | violine1101^(Talk) 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 cake 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? /54.87.181.129 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. –Majr ᐸ Talk
Contribs 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) /83.255.21.112 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. –Majr ᐸ Talk
Contribs 11:28, 8 July 2017 (UTC)

Redirect policy

I've recently deleted a bunch of pages from Category:Pending deletion, 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? –Goandgoo ᐸ Talk
Contribs 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 redirect cleanup project 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 wolves or minecarts with chest (that aren't simple plurals: you don't just tack an "s" onto the end) is a good thing
• Keeping simple plurals like creepers is in conflict with the Style Guide on linking, because you should be writing such links like: [[creeper]]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 [[Block of Gold|block of gold]], and this is a good thing.

Maybe you could also look at:

• Minecraft_Wiki_talk:Projects/Redirect_cleanup#Banner_redirects. 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.

– Sealbudsman ^talk/_contr 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. -BDJP ^(t|c) 11:18, 7 July 2017 (UTC)

Assuming its the CDN. User talk:Majr#Protocol stripping?. –Majr ᐸ Talk
Contribs 11:39, 7 July 2017 (UTC)

Translation cleanup

Reviving this topic: MCT:Community portal/Archive 19#Translation projects

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):

• Arabic
• Bulgarian
• Catalan
• Croatian
• Danish
• Estonian
• Farsi
• Greek
• Hebrew
• Icelandic
• Indonesian
• Irish
• Romanian
• 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.

• Esperanto
• Finnish
• Lithuanian
• Norwegian
• Tagalog
• Slovak
• Swedish
• Ukrainian
• Vietnamese

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.

• Czech
• Thai
• Turkish

Pings:

RentoKraft, HafidzNur, MustaphaTR, ByBluera, Hywoid and LambayaFunfDe, 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.

Thehedorn, Thejuusoboy, ARTacp, Gustisz, Ixeer, 16patsle, Holroy, Serecola, Dentedharp90041, Storymodefan0315, MinecrafterSK0121, Kikino745, Tobik2200, Einusch, Evgen2015, WorldPedia, YarVish, Seva74chel, Phjtieudoc, Phuccom000 and Trangthing573, 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.

–Majr ᐸ Talk
Contribs 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? – Sealbudsman ^talk/_contr 06:07, 9 July 2017 (UTC)

Correct, I only counted edits which actually translated the page. –Majr ᐸ Talk
Contribs 06:09, 9 July 2017 (UTC)

The Turkish Main page has been fully translated and updated by LambayaFunfDe, so the project should not be deleted anymore. Let's see how active the translation will become. | violine1101^(Talk) 18:43, 11 July 2017 (UTC)

Ok, I have asked for the three wikis to be moved. –Majr ᐸ Talk
Contribs 10:03, 15 July 2017 (UTC)

 Done! cs:, th:, tr:. I'll delete the project pages and email all the translators tomorrow. –Majr ᐸ Talk
Contribs 13:29, 17 July 2017 (UTC)

Great! I'll try to help setting those up if I have some time. Maybe minecraft-cz.gamepedia.com should redirect to the Czech wiki as cz is the code for the Czech Republic while cs is the code for the language. This could cause some confusion. (See Minecraft Wiki:Admin noticeboard/Archive 26#Czech wiki) | violine1101^(Talk) 14:47, 17 July 2017 (UTC)

The project pages have been deleted, and the translators I could find have been emailed. Rechris, Prem4826 and LambayaFunfDe 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. –Majr ᐸ Talk
Contribs 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 Stone/tr to Taş (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 the one FTB Wiki uses 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 Greek wiki. — NickTheRed37 (talk) 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. –Majr ᐸ Talk
Contribs 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. — NickTheRed37 (talk) 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. | violine1101^(Talk) 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. –Majr ᐸ Talk
Contribs 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 Extension:Translate? (I’m not a fan of this extension myself, but someone would necessarily mention it.) — NickTheRed37 (talk) 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? | violine1101^(Talk) 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. | violine1101^(Talk) 14:39, 18 July 2017 (UTC)

I also agree with Majr. 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. –KnightMiner · (t) 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. – Nixinova 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 Translation:Ukrainian/Камінь. 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 Translation:Language/ 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)! — NickTheRed37 (talk | 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? – Nixinova 07:49, 19 July 2017 (UTC)

Mods. Off-topic ends here, don’t reply. — NickTheRed37 (talk | 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. L4bbogdanbarbu (talk) 11:27, 19 July 2017 (UTC)

@L4bbogdanbarbu:: 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. -Xbony2 (talk) 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. L4bbogdanbarbu (talk) 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 MediaWiki, Wikimedia’s Meta, 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 <translate> 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. — NickTheRed37 (talk | 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 (mw:), 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: ftb:User:Xbony2/T3, 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. -Xbony2 (talk) 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, ftb:Special:WantedTemplates for example. Using the translate extension here is absolutely out of the question. –Majr ᐸ Talk
Contribs 01:47, 23 July 2017 (UTC)

Minecraft Wiki:Admin noticeboard#New Language Persian. Habedi requested to create the Farsi (Persian) section after the respective project has been removed. This is the first proposal of such kind. — NickTheRed37 (talk | RU) 16:11, 23 July 2017 (UTC)

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

One and a half months passed. The Turkish wiki has become inactive, just like the Greek wiki (updating Module:Version/Numbers doesn’t count). What I see there is only pointless edits like empty article creation by anons, Game widow 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, LambayaFunfDe 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. — BabylonAS (talk | ru.Wiki Admin) (fka NickTheRed37) 09:28, 31 August 2017 (UTC)

Take it up with Majr — Game widow ^(talk) 12:07, 31 August 2017 (UTC)

File:Ghast.gif

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? VeenM64 (talk) 00:29, 13 July 2017 (UTC)

 Support This would show the attack animation. The Blobs 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. — NickTheRed37 (talk) 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! Fusseel (talk) 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? - MinecraftPhotos4U (talk) 10:50, 13 July 2017 (UTC)

Special:UnusedFiles; which can also be reached through the 'special pages' link in the left sidebar. -- Orthotope^talk 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}}? --Beans1512_{Talk/Contribs} 05:15, 16 July 2017 (UTC)

I am neutral, but if they were to be added, the navboxes should have a "Joke features" section. The Blobs 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. –KnightMiner · (t) 01:17, 17 July 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? – Nixinova 03:44, 19 July 2017 (UTC)

The videos are shown because Curse wants to have them for their commercial interests. Damn capitalism. — NickTheRed37 (talk | 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. – Sealbudsman ^talk/_contr 11:08, 19 July 2017 (UTC)

Proposal to restrict bureaucrat’s rights

This is a revival of the original suggestion of about a year ago.

Since nobody has discussed that idea, I want to revive it. It’s about restricting what rights can be set or unset by bureaucrats. AttemptToCallNil 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 Majr, CrsBenjamin and Game widow 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. — NickTheRed37 (talk | RU) 15:32, 20 July 2017 (UTC)

One question. Why? What's wrong with the current bureaucrat's rights? | violine1101^(Talk) 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). --AttemptToCallNil (report bug, view backtrace) 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 Special:UserGroupRights, 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. -- Orthotope^talk 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. –Majr ᐸ Talk
Contribs 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. — NickTheRed37 (talk | RU) 13:50, 21 July 2017 (UTC)

Yes, and there is a ticket already in asking to do that. –Majr ᐸ Talk
Contribs 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. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 19:56, 21 July 2017 (UTC)

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

So, how far this idea goes? — NickTheRed37 (talk | 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. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 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. — BabylonAS (talk | 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? | violine1101^(Talk) 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 autopatrol group membership.

I am neutral with regards to this question. --AttemptToCallNil (report bug, view backtrace) 11:32, 3 August 2017 (UTC)

Majr, do you ever intend to implement my suggestion regarding autopatrol status? Ivan-r already had to request Game widow 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. — BabylonAS (talk | 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. –Majr ᐸ Talk
Contribs 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 implemented this change. — BabylonAS (talk | 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. –Majr ᐸ Talk
Contribs 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 here.) Majr, do you know how to fix? --Beans1512_{Talk/Contribs} 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. — NickTheRed37 (talk | RU) 09:44, 21 July 2017 (UTC)

I understand. After all, the wiki is often unstable ... Even before this, the server was out ´д` ; --Beans1512_{Talk/Contribs} 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 Fusseel) Do I have an outdated cache or the wiki has something wrong? – Dentedharp90041^tc 11:12, 21 July 2017 (UTC)

Uploaded a new file, but the scaled version is dark. I guess something's wrong with the wiki. – Dentedharp90041^tc 11:20, 21 July 2017 (UTC)

Not so sure what is going on, even some of the old files from File:Hopper.png 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. Fusseel (talk) 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 workaround to MW. We can workaround the issue locally by not optimising images to greyscale. –Majr ᐸ Talk
Contribs 11:34, 21 July 2017 (UTC)

Still not fixed. – Dentedharp90041^tce 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 1.13 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). --Pepijn (talk) 18:09, 21 July 2017 (UTC)

We've created Data values/1.13. --Pepijn (talk) 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: {{/row|1|Stone|stone|Stone;Granite;Diorite|stone;granite;diorite}}. Throw in a few defaults and it will be quite clean to use –KnightMiner · (t) 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. --Pepijn (talk) 11:14, 22 July 2017 (UTC)

By under 1.13, I was leaning more towards 1.13/Data values, especially since after 1.13 is released Data values will just state the latest instead of old and Data values/Before 1.13 will state the old ones. –KnightMiner · (t) 16:37, 23 July 2017 (UTC)

I'm fine with 1.13/Data values, I went with Data values/1.13 mostly because the French wiki did the same. --Pepijn (talk) 21:54, 23 July 2017 (UTC)

Transcludable game element data — part two

This is related to this discussion.

On the Russian wiki I have created a new original module (Состояния блока / Block states) intended to be used on articles instead of transcluding subpages like Stone/BS, which use the {{Block state table}} template. The new system has been approved by AttemptToCallNil on the Russian wiki’s IRC channel (#ruminecraftwiki); right now it is only used on Wood, Cobblestone Wall, Stone articles and articles about special variants of stone. The block state data is located instead on the subpages of the module itself, e. g. ru:Модуль:Состояния блока/minecraft:cobblestone_wall. 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 earlier. I’m sure this piece of technology, a 100 % Russian wiki invention, may be of interest to other wiki projects. Any thoughts? — NickTheRed37 (talk | 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. | violine1101^(Talk) 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. –KnightMiner · (t) 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 chunk format 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. –Majr ᐸ Talk
Contribs 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 Module:Crafting usage 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 AttemptToCallNil to participate in the discussion. — NickTheRed37 (talk | 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. --AttemptToCallNil (report bug, view backtrace) 10:25, 25 July 2017 (UTC)

Beta 1.7.1 / 1.7_01

After much research, I've found that Beta 1.7.1 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 launcher 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?

―HalfOfAKebab ^{(talk, contribs)} 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"). – Fusseel 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 (MCL-7885). --Pokechu22 (talk) 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). ―HalfOfAKebab ^{(talk, contribs)} 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: 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. – Fusseel 20:35, 30 July 2017 (UTC)

How do we make these changes, then? ―HalfOfAKebab ^{(talk, contribs)} 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 still attributed to the old nickname (but hey, at least the old user profile is not present unlike in 2014/15). — BabylonAS (talk | 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. Game widow, Alianin, CrsBenjamin, can you resolve these problems? — BabylonAS (talk | ru.Wiki Admin) (fka NickTheRed37) 07:33, 4 August 2017 (UTC)

Markus Persson is outdated

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

Commons images

At my userspace, I used images from commons. They seem to have disappeared. Where have they gone? – Nixinova 02:30, 2 August 2017 (UTC)

Seems to be fixed now... what happened? – Nixinova 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. | violine1101^(Talk) 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 File:Chain Command Block.gif, which I made the frame disposal to "replace", so it won't seem buggy. – Dentedharp90041^tc 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 Gamepedia Help Wiki, FTB Wiki now also has one. There is a discussion on the Russian wiki about creating a dark theme. AttemptToCallNil has created some styling for a hypothetical dark theme in his common.css, but I would like to see a complete dark theme that is similar to the current default theme (which has been created by Majr), except being dark. (The direct request to Majr for creating a dark theme variant is here.) Any ideas? — BabylonAS (talk | ru.Wiki Admin) (fka NickTheRed37) 10:11, 9 August 2017 (UTC)

 Yes I would certainly love to see dark theme. This is something that has been missing on Minecraft Wikis since ever. piotrex43 (Talk page) 10:17, 9 August 2017 (UTC)

Sure, why not? NTBG (talk) ^{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. -Xbony2 (talk) 15:01, 9 August 2017 (UTC)

As I already said at Minecraft Wiki talk:Directors#Dark theme (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. | violine1101^(Talk) 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 CSS needed for it is not too monstrous. The Minecraft Wiki would probably have many more special cases than us, but how bad could it be? -Xbony2 (talk) 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. | violine1101^(Talk) 11:54, 10 August 2017 (UTC)

Yeah, that all needs to be adjusted and whatnot. -Xbony2 (talk) 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. – Sealbudsman ^talk/_contr 23:20, 9 August 2017 (UTC)

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

Fail... maybe I shouldn't immediately hit 'hide' on those notices X( – Sealbudsman ^talk/_contr 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 (Player.dat, Chunk format, Advancements, Enchanting) 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!

-- ShelLuser (talk) 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. – Nixinova 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) --Pokechu22 (talk) 23:17, 12 August 2017 (UTC)

Mojang edits and official sources

The official sources guide says that

“	Edits made by Mojang employees can be used as sources.	„
	— Help:Official sources#Minecraft Wiki

Meanwhile, since Minecraft was created by Mojang, this may cause a conflict of interest 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 HelenAngel as the most active Mojang employee on the wiki in the moment. — BabylonAS (talk | ru.Wiki Admin) (fka NickTheRed37) 12:12, 18 August 2017 (UTC)

So like a tweet saying its true? Because an edit diff is the exactly the same thing. – Nixinova 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. --–KnightMiner · (t) 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 AttemptToCallNil to participate in the discussion. — BabylonAS (talk | 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. --Pepijn (talk) 14:04, 20 August 2017 (UTC)

I’m not sure should they ever add their information to articles at all. — BabylonAS (talk | 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. --AttemptToCallNil (report bug, view backtrace) 14:36, 20 August 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. piotrex43 (Talk page) 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. – Sealbudsman ^talk/_contr 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? – Sealbudsman ^talk/_contr 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. 86.82.30.109 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?". - ShelLuser (talk) 03:20, 21 August 2017 (UTC)

Should we compress images that were taken from official sources?

Should we compress images that were taken from official sources? For example, see "File:JasperCraftingTablesAndWood.png".

On one hand, it would be nice to losslessly compress a large image. On the other hand, I think it's important to preserve the "as-is"-ness of things taken from official sources.

Opinions?

―HalfOfAKebab ^{(talk, contribs)} 01:20, 19 August 2017 (UTC)

Never in regards to JPEG/other lossy compression. But for optimizing a PNG (losslessly) I see no issues. (I think, but don't quote me on this, that mediawiki already does some of that kind of compression, so aiming for byte-for-byte equality isn't worth it and in any case the source is linked). --Pokechu22 (talk) 01:45, 19 August 2017 (UTC)

Can someone verify the automatic compression thing? ―HalfOfAKebab ^{(talk, contribs)} 03:52, 19 August 2017 (UTC)

No compression is performed on upload. JPEG thumbnails are transformed with a particular quality setting; PNG thumbnails don't have any compression AFAIK. –Majr ᐸ Talk
Contribs 04:30, 19 August 2017 (UTC)

For the most part, compressing images is pointless as most images are displayed as a thumbnail, which obviously isn't affected by the source being compressed. –Majr ᐸ Talk
Contribs 01:50, 19 August 2017 (UTC)

Yes, but the user has all rights to watch the full version. And while not all images are of HD size, nothing’s bad if the image is being compressed in order to take minimal byte size on the server. — BabylonAS (talk | ru.Wiki Admin) (fka NickTheRed37) 14:08, 20 August 2017 (UTC)

If server storage is a concern, images should be compressed before they are first uploaded. Re-uploading a compressed version always uses more storage space, since the previous versions are still present.

In the handful that I looked at, thumbnails of compressed images are not necessarily smaller than thumbnails of the same, uncompressed image. Unless a file is normally shown at full size, compressing it won't help with either server load or page loading time. -- Orthotope^talk 18:14, 20 August 2017 (UTC)

Packed gallery

See also: ru:Обсуждение Minecraft Wiki:Портал сообщества/Архив 10 § Замена формата галереи

Over a year ago the Russian wiki switched to use packed galleries. This is a special feature which utilizes the mode parameter set to "packed" 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 Features section on Far Lands):

Packed

A view within the Far Lands. “The Stack" at X/Z ±32,000,000. Above lies the top layer. A bird's eye view of the top layer of the Corner Far Lands, or “The Stack". The middle layer of the Corner Far Lands, or “The Stack", using mods for visibility. The bottom layer of the Corner Far Lands, or “The Stack", using mods for visibility. An overhead view of the Edge Far Lands, or "The Loop". Inside the Edge Far Lands beyond X/Z 32,000,000, where there are no trees, mobs, or lighting. “The ocean" within the Edge Far Lands. A bisection of the Corner Far Lands, showing the 3 different layers. A bird's eye view of the Far Lands' corner. 20110608124514.png The "end of the world" as seen from the third person mode.

versus

Classic

A view within the Far Lands. “The Stack" at X/Z ±32,000,000. Above lies the top layer. A bird's eye view of the top layer of the Corner Far Lands, or “The Stack". The middle layer of the Corner Far Lands, or “The Stack", using mods for visibility. The bottom layer of the Corner Far Lands, or “The Stack", using mods for visibility. An overhead view of the Edge Far Lands, or "The Loop". Inside the Edge Far Lands beyond X/Z 32,000,000, where there are no trees, mobs, or lighting. “The ocean" within the Edge Far Lands. A bisection of the Corner Far Lands, showing the 3 different layers. A bird's eye view of the Far Lands' corner. 20110608124514.png The "end of the world" as seen from the third person mode.

This new type of gallery is already being used in two sections on the mentioned Far Lands article (while most galleries are traditional), on the TNT cannon article section covering piston-reloadable TNT cannons, and recently I changed the gallery to this variant on Lava. I would like to hear any objections and ideas regarding establishing usage of packed galleries as the standard. — BabylonAS (talk | ru.Wiki Admin) (fka NickTheRed37) 14:22, 20 August 2017 (UTC)

 Oppose The packed version decreases the number of images that can be seen at once. The Blobs 17:33, 20 August 2017 (UTC)

And what’s the problem with it? — BabylonAS (talk | ru.Wiki Admin) (fka NickTheRed37) 16:14, 21 August 2017 (UTC)

Galleries with lots of wide-aspect-ratio screenshots are more visible when packed, but also take up more space on the page. Square images are not significantly more visible when packed, and galleries with a mix of different image sizes look cleaner when not packed. I don't think we need a strict rule on this; let editors use whichever mode looks better in a given article. -- Orthotope^talk 18:14, 20 August 2017 (UTC)

 Oppose. Packed galleries, while nice looking, don't have the best usability due to using JS to dynamically scale the images, which causes the page to jump, and use oversized thumbnails, which take longer to load. If you just want bigger thumbnails, use the widths and heights parameters, and the nolines mode to save space (although this doesn't make them all the same height).

• 

  A view within the Far Lands.

• 

  “The Stack" at X/Z ±32,000,000. Above lies the top layer.

• 

  A bird's eye view of the top layer of the Corner Far Lands, or “The Stack".

• 

  The middle layer of the Corner Far Lands, or “The Stack", using mods for visibility.

• 

  The bottom layer of the Corner Far Lands, or “The Stack", using mods for visibility.

• 

  An overhead view of the Edge Far Lands, or "The Loop".

• 

  Inside the Edge Far Lands beyond X/Z 32,000,000, where there are no trees, mobs, or lighting.

• 

  “The ocean" within the Edge Far Lands.

• 

  A bisection of the Corner Far Lands, showing the 3 different layers.

• 

  A bird's eye view of the Far Lands' corner.

• 20110608124514.png

  The "end of the world" as seen from the third person mode.

–Majr ᐸ Talk
Contribs 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. — BabylonAS (talk | ru.Wiki Admin) (fka NickTheRed37) 16:14, 21 August 2017 (UTC)

For me, the packed mode is better than normal gallery in mobile view, due to small screens. – Dentedharp90041^tce 10:09, 21 August 2017 (UTC)

Image requests

Where's the best place to go to request an image? ―HalfOfAKebab ^{(talk, contribs)} 21:17, 27 August 2017 (UTC)

At Minecraft Wiki:Community portal#Wanted pages. – Dentedharp90041^tce 04:11, 28 August 2017 (UTC)