Minecraft Wiki talk:Community portal

From Minecraft Wiki
Jump to: navigation, search

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 feedback site.

Did these versions actually exist?[edit]

Following the recent rediscovery of Alpha v1.0.2 I've been in the process of adding evidence of existence of various versions from Alpha which are no longer available in the launcher. There is currently one remaining version which I am yet to find any proof for:

I can't seem to find any particularly solid ground on this version's case. I've searched through various YouTube videos, but it appears to be elusive, and I'm not being too successful with finding sources on Notch's blog either. General googling also provides no relevant results, photographic or otherwise.

There's also a few versions that can be presumed to exist due to later patches, but don't have pages, and I have also had no success verifying:

Can anyone help provide proof (video, screenshot, blog post or otherwise) that any of these four versions existed? - MinecraftPhotos4U (talk) 14:35, 21 March 2018 (UTC)

I can provide some history from the wiki, which seems to show that it doesn't exist: a1.0.15 was added to version history in revision 13802 and included the changes given to a1.0.14_01. But it was put before multiplayer instead of after, so there were two a1.0.15 versions listed, and this was also an after-the-fact revision (dated 25 August 2010). (n.b. I bypassed the broken username in version history by just manually editing the date)
This was later converted into a table in revision 15910, and that changed the second a1.0.15 to a1.0.14 (probably by accident), so that there were two a1.0.14's listed; this is also when it was given a release date of August 03 2010. This duplicate entry continues on for years, until the articles are split off in revision 212986. The alpha history was put here. And, it was eventually the unique _01 name in revision 370385 when Fenhl refactored the links in the article.
As one more point of evidence, check the history of Patch history. There is only Seecret Friday 7 (with the last edit on 31 July 2010) and Seecret Friday 8 on 20 August 2010. No a1.0.14_01. And, finally, it just doesn't make sense; the changes for a1.0.14_01 include "Can enter the IP for a server other than Mojang's server", yet a1.0.15 is supposed to be the version that introduced support for multiplayer.
Basically, it is pretty clear to me that this version doesn't actually exist, and all of the changes listed for it are actually part of a1.0.15. No comment for the other versions yet. --Pokechu22 (talk) 18:18, 21 March 2018 (UTC)
Alpha v1.0.14_01 doesn't exist, the only blog post that would be fitting belongs to Alpha 1.0.15. The post is mislabeled as Alpha 1.0.14 though, but comparing the dates of the jars and the timestamps of various blog posts it becomes clear that this one is indeed for Alpha 1.0.15. – Fuzs 19:26, 21 March 2018 (UTC)

On a similar topic, it seems as though the versions 0.30_01, 0.30_02 and 0.30_03, as listed in Version history/Classic, are all misnomers/conjectural; these were all called 0.30 in the page's initial revision, and looking at the corresponding blog posts on Word of Notch showed that they also shared the 0.30 title ingame. The situation with the 0.24 versions is identical. Does this affect any other versions? - MinecraftPhotos4U (talk) 18:58, 22 March 2018 (UTC)


I appear to have found the proof that Alpha 1.0.17_01 does indeed exist, as per here: https://i.imgur.com/SAkZp.png sourced from here: https://www.reddit.com/r/Minecraft/comments/d3fmt/double_tree_what_does_this_mean/ 44trent2 (talk) 08:14, 25 April 2018 (UTC)

added! There's one that can be crossed off of the list.
Now that we're also keeping track of Classic versions now, here's an updated list of conjectural versions:

And the "no-proof-so-they-might-as-well-be-fakes":

Would this be better split off into its own project? - MinecraftPhotos4U (talk) 10:30, 25 April 2018 (UTC)

Probably, yes. – Nixinova Grid Book and Quill.png Grid Diamond Pickaxe.png Grid Map.png 05:51, 26 April 2018 (UTC)
I'll get around to setting it up at somewhere along the lines of Minecraft Wiki:Projects/Proving missing versions sooner or later. - MinecraftPhotos4U (talk) 15:22, 5 May 2018 (UTC)

I'm still having major difficulty finding proof for Alpha v1.2.3_03; looking through several old forum threads hasn't turned up any screenshots, and while I've found mentions of it none seem to imply strongly enough that it existed. - MinecraftPhotos4U (talk) 19:46, 12 July 2018 (UTC)

Page locks to signal protection[edit]

This was proposed about a week ago and it only got a few responses, so I'm starting a new community portal topic. The original discussion can be seen at Template talk:Protected.

So basically, AttemptToCallNil and I came up with the idea to have locks as indicators in the top right corner of any protected page. How it would work is for each level of protection, it will show a different lock color, title, link, and category. A demonstration of this can be seen in my sandbox. The reasons I think locks should be used is because the current {{protected}} template is kind of distracting and it's not really clear where to use it. It seems to be used on only a few pages, and is kind of big, making it distracting to readers. Also, it would be confusing if it were used on templates, as readers may think that it's the actual template, rather than signifying a state that applies to the template. However, using locks instead would solve all these problems - just simply add the template to pages that are protected in any way at any level. I haven't come across any problems so far with my experimenting, although I'm sure there's something.

Anybody who wants to discuss is welcome to do so either here or at Template talk:Protected. This will be quite a big change, so it would be nice to have some feedback and opinions. =)-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 20:04, 2 June 2018 (UTC)

Support - Wikipedia does the exact same thing and I don't see why we shouldn't. --Marioprotvi (talk) 20:12, 2 June 2018 (UTC)
Well, this idea seems to be fully supported with no opposition. The question is, what do we do now? Should we wait till somebody finds a way to add the template to every page automatically, or go ahead and move it to the template namespace? (I support the second). But if we do the second, should we move it to a temporary title (such as Template:Protected 2) as a work-in-progress until we have the details worked out and possibly found an automatic way to add it? Or should we go ahead and delete the current Template:Protected (obviously removing the pages that use it as well) and move my sandbox to that title?-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:07, 7 June 2018 (UTC)
Lets figure out first how to add the template to every page automatically. If a new template is introduced before it's achieved its goal, people will start using it wrongly, introducing even more overhead work. And removing the use of the current template from pages leaves those pages (as it currently works now) without any visual clue as to the protection level. So, how can a template be transcluded automatically on a page, depending on some parser function criteria? – Jack McKalling [ Talk Contrib ] 14:20, 7 June 2018 (UTC)
By the way, page status indicators for protection levels are already limitedly used on the Russian wiki and even referenced in the page protection guidelines. I don’t think we will ever get a working automatic protection indicator only using wikitext/template means, in my vision it necessarily needs some JavaScript code (and I’m not used to program in JS). The question says: is using JS means worth it? Administrators can “hang the locks” while changing protection levels, and a specifically designed program can place these templates en masse automatically, if run via a bot account with admin privileges. — BabylonAS (talk | ru.Wiki Admin) 14:42, 7 June 2018 (UTC)

 Agree with BabylonAS. I don't think we should be prevented from doing this just because we will need complicated JS code to add it automatically. Just noting, on Wikipedia all administrators are expected to add the locks as soon as they protect a page - though sometimes they forget. There are no bots that automatically add locks - but if a protection has expired, a bot will remove the lock from the page. However, this is solved with Category:Unprotected pages using Template:Protected, and all admins would have to do is look through that category every now and then.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:56, 7 June 2018 (UTC)
It does indeed require complicated JS code. The indicator element is a virtual one in wikitext, you cannot append it to an existing page with JS, it has to be processed by the wikitext parser first (or simulated as such). I'm not saying "no" to the idea, however. I'd just really like to see this thing automated when protecting pages. It removes the need for an admin to manually edit the page to reflect the new protection level (as you've mentioned already, sometimes this is forgotten). A bot helps, but are there maybe more direct ways to make it automated? Similar to how you could show a form of message box during editing for particular situations by abusing system messages. I haven't got an idea myself, as I'm not familiar enough with all the options we got. – Jack McKalling [ Talk Contrib ] 15:04, 7 June 2018 (UTC)
To change a large amount of pages at a time, we can use bots, but I am not sure if bots are allowed here... Lê Duy Quang (Make some words | Contributions)

New idea[edit]

This idea doesn't seem to currently be going anywhere, but I have a different but sort of related idea. Currently, when one edits a page they do not have permission they edit, they just get the following message: "The page has been protected to prevent editing and other actions." I'm thinking we kind of do closer to what Wikipedia does but omit the stuff about edit requests, etc. - mainly say the level of the protection, link to the protection log, and if it's a semi-protected page, suggest that the reader create an account. I think this would be very helpful. The great thing here is we wouldn't need a bot - it would automatically be generated with MediaWiki:Protectedpagetext. I'm going to experiment a bit with this in my sandbox.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 22:49, 16 June 2018 (UTC)

Anybody want to comment on this matter? You can see some demonstrations of this in my sandbox. Improvement suggestions are welcome.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 13:04, 27 June 2018 (UTC)
Message boxes are horrible IMO. They're centered on the screen (which means small boxes leave a lot of space on wide screens), and text inside them is also centered (which looks terrible on small screens, and on wide screens when the last word (or two) is the only one on its line. They also have quite a lot of margin and padding, which makes them take even more space. Why not just use plain text? --AttemptToCallNil (report bug, view backtrace) 13:20, 27 June 2018 (UTC)
Do you think what I have in my sandbox now is better?-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 13:46, 27 June 2018 (UTC)
Better, though I would consider splitting the "if you think the page doesn't need to be protected anymore" part into its separate bullet point. Also: 1) "Directors are any user..." has inconsistent singular/plural; 2) the talk page is linked twice, this may be unnecessary. --AttemptToCallNil (report bug, view backtrace) 14:01, 27 June 2018 (UTC)
I still prefer the "Another idea"'s locks to these huge message boxes. And we could make some sort of expanding the details when the lock is clicked. Lê Duy Quang (Make some words | Contributions) 14:07, 27 June 2018 (UTC)
@AttemptToCallNil: Better now? Also, Leduyquang753, this wouldn't be huge message boxes anymore, just normal text - additionally, in case you didn't know, this would not actually show up when viewing the page normally; it would only show up in replace of the "This page has been protected to prevent editing or other actions" when editing an article that you don't have permission to edit.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:15, 27 June 2018 (UTC)
@Madminecrafter12: But still, we need a kind of indicator to add to the View mode that the page is locked. –Preceding unsigned comment was added by Leduyquang753 (talkcontribs) at 14:19, 27 June 2018 (UTC). Please sign your posts with ~~~~
@Madminecrafter12: Better, but it seems you are using the protection variable in your examples, and the variable is not defined. If that's the same as the reason variable, I have no further objections. --AttemptToCallNil (report bug, view backtrace) 14:21, 27 June 2018 (UTC)
When I changed the name of that defined variable, I forgot to update all of the cases in the template using it. :( Fixed that now.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:24, 27 June 2018 (UTC)
Jack McKalling - sorry for the ping, but because you didn't seem to think it would be a good idea to use locks to signal page protection until we can figure out a way to automate it, I would be curious to see what you think about this idea.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 18:58, 28 June 2018 (UTC)
I may make a script to automate this. Just need some learning about Lua and MediaWiki... Lê Duy Quang (Make some words | Contributions) 14:17, 29 June 2018 (UTC)
I definitively think what MadMinecrafter12 made on his sandbox page is a big step in the right direction. Locks on the main page are not really necessary, particularly if it's not possible to make it automatic. However, indicating to users why they cannot edit their pages is absolutely necessary, and giving them instructions to discuss about changes. It may sounds simple, but it's not something obvious for someone new. Perhaps you could reduce a bit the text length and link to the admin list for the third case — but otherwise, I really like his suggestion. JSBM (talk) 14:32, 29 June 2018 (UTC)
JSBM - I've added the text "or contact an administrator directly" linking to the list of administrators. Also, do you have any specific suggestions of how to reduce the text length?-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 13:32, 30 June 2018 (UTC)
Ok, so, this is my take on the three messages:
This page is protected so that only registered users can edit it.
To edit this page, you'll need to create an account. You can also request change on the article's talk page.
You can discuss about the protection on the article's talk page or the admin noticeboard.
(See the page's protection log for more details about the protection.)
This page is protected so that only directors can edit it.
You can request change on the article's talk page.
You can discuss about the protection on the article's talk page or the admin noticeboard.
(See the page's protection log for more details about the protection.)
This page is protected so that only administrators can edit it.
You can request change on the article's talk page.
You can discuss about the protection on the article's talk page or the admin noticeboard.
(See the page's protection log for more details about the protection.)
Yes, I'm too lazy to actually make links. Also, I feel some of the working (« You can request change ») isn't really working in English, so feel free to adapt as you want. But I feel a shorter version would do a better job at providing the information. JSBM (talk) 16:57, 30 June 2018 (UTC)
Just an overview of all the changes you made and what I think of them: I like having a bulleted list - it looks cleaner, so I'm opposed to changing that. I support making the intro text bigger, like you did. I also like how you were able to condense the "creating an account" and "requesting an edit" into 1 line, so I support that part as well. I am opposed to putting the protection log information just as small text in parentheses at the end - although perhaps we should move that down a bit from where it currently is, as I do think knowing how the page can be edited is more important than the reason for the protection. I'm neutral about removing the directors definition - it's certainly nice and convenient to have there, but it is a bit out of place and it does link to the MCW:Directors page right there, which contains an explanation.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 17:07, 30 June 2018 (UTC)
I've done this for the protected page text interface page on the RollerCoaster Tycoon World Wiki, another wiki I'm an administrator on. It works great, and actually looks fairly decent. You can see it in action here.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 13:44, 30 June 2018 (UTC)
It would have looked even better if the list bullets weren't barely distinguishable from the background. --AttemptToCallNil (report bug, view backtrace) 14:12, 30 June 2018 (UTC)
That's just exclusive to that wiki - wouldn't be a problem here. Yeah, there are a lot of CSS skin problems on that wiki.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:16, 30 June 2018 (UTC)
This looks good! I already implemented it on the German wiki. The old text really was not informative at all. | violine1101(Talk) 15:41, 30 June 2018 (UTC)
So, this discussion has been up for 2 weeks. It seems that the clear consensus is to definitely give more of a description on the MediaWiki:Protectedpagetext page. This proposal has not gotten any strong objections and seems to have mostly support, and nobody seemed to think that what I had in my sandbox was problematic, after I had modified it to comply with what people thought about it. Also, remember that these actions are easily reversible - if a mob of users suddenly come and for some reason say that we should just have that one old non-descriptive sentence, I or another admin can just modify that page. Likewise, if a lot of people think a change needs to be made to this, which is something I'm definitely expecting, we can easily do that as well.
So, please comment if you think this needs to be changed, tweaked, removed, etc., but for now I've
 Done what I had in my sandbox.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 16:05, 30 June 2018 (UTC)
I think the padlocks we use as indicators at the top of protected pages, could be added to that page with the padlock and the text why the page is protected, and I could think the text could be:

Semi protected:

The page you are trying to edit is semi-protected This page is protected so that only registered users can edit it.
To edit this page, you'll need to create an account or sign in. You can also request a change on the article's talk page.
You can discuss about the protection on the article's talk page or the admin noticeboard.
(See the page's protection log for more details about the protection.)

Full protected:

The page you are trying to edit is protected This page is protected so that only administrators can edit it.
You can request change on the article's talk page.
You can discuss about the protection on the article's talk page or the admin noticeboard.
(See the page's protection log for more details about the protection.)

Directors only protected:

The page you are trying to edit is directors-only protected This page is protected so that only directors can edit it.
You can request change on the article's talk page.
You can discuss about the protection on the article's talk page or the admin noticeboard.
(See the page's protection log for more details about the protection.)

- psl85 (☎ Talk | ✏️ Contribs) 06:33, 2 July 2018 (UTC)

@Madminecrafter12:, I definitely like the system message solution. It is automatic and doesn't need any additional admin action during protecting. I really like the more condensed version of JSBM as well. It is too much to read if there are 4 bullets below the main line, 2 lines would be ideal. That line about the protection log can be further simplified as a single link like this:
This page is semi-protected This page is protected so that only registered users can edit it [protection log]
I believe this is enough for all three cases, only differing in the usergroup in the bold text, with a link for the directors. No need to explain what directors are, this message/page is not responsible or related to the definition of each usergroup. The link should be fine. I combined JSBM's table here with your bullets, because I really like the offset background so that it pops up and it definitely deserves that. It doesn't need to be centered but I think this way it shows the importance of the message, as opposed by regular text. I also added Psl85's padlocks, it provides a fast message at glance to reduce the need to read even more. But I'm not sure about the table border between. I don't want this to turn into a centered message box though, I agree this one needs to be left aligned along with the text there. – Jack McKalling [ Talk Contrib ] 08:01, 2 July 2018 (UTC)
In my last few edits to the page, I went ahead and condensed the information into two bullet points. I also removed the protection log bullet point and added the link to the log in the first line instead. Finally, I made the "This page has been protected so that only [X] can edit it" text bigger. I'm not too sure about implementing it into a table. And as for the locks, I do think that would be a good idea. I like what Psl85 did, I just think they should probably be a little bit smaller. If we do end up using a table, I'm against putting the lock in a separate cell from the text - I just think it would look much better if the lock and the text are together.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 13:11, 2 July 2018 (UTC)
Here's kind of what I'm thinking for incorporating the locks:
The page you are trying to edit is semi-protectedThis page is protected so that only registered users can edit it.(see the protection log)
-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 13:22, 2 July 2018 (UTC)
Good message, but the text "to edit this page, you'll need to create an account." could be changed to "to edit this page, you'll need to create an account or sign in" to add a link to allow signing in from that link instead of only a link for creating an account, and I would also be able to edit those Mediawiki: messages instead of only admins and wiki guardians, this wiki and other Gamepedia wikis could add a interface editor user group and users in that group could be able to edit the Mediawiki: messages, and could be given through requesting the right, is this possible??? psl85 (☎ Talk | ✏️ Contribs) 17:43, 2 July 2018 (UTC)

Another idea[edit]

I have also a new idea - the padlocks could be replaced with blocks in Minecraft - iron block on semi-protected page, gold block on fully protected page, coal block on directors protected page, emerald block on move protected page, and lapis lazuli block on upload protected file, and those soes not needed to be uploaded, and only be used on the top right corner on protected page, and the Mediawiki:protectedtext could be a message box, with padlock/the blocks mentioned before image, and information about the protection, reason, and then add a link to suggest the reader to create an account/submit a edit request using a new template {{edit request}}, and a link to the admin noticeboard to remove the protection if the protection is not needed anymore, I planned to experiment with the edit request template and the new protection messages in my sandbox - psl85 (☎ Talk | ✏️ Contribs) 06:06, 27 June 2018 (UTC)

The Minecraft-themed protection locks would certainly be an interesting idea. It's still not addressing the problem about adding the locks automatically, which is something that many people seem to think is necessary (although I personally don't think it is). I've tried to see if MediaWiki:Protectedpagetext can detect protection levels on another wiki, and it definitely works! I'm not really that supportive of creating the edit request template, though - there's not really much need for it on such a small wiki, and we don't need to have all of the complex systems that Wikipedia has.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 12:50, 27 June 2018 (UTC)
Maintenance issue. We in general should not use images of game content as part of wiki design for the following reason:
If the depicted object's appearance is changed, the image has to be reuploaded. Allowing regular users upload system images is a risk due to potential severe harm from vandalism. Disallowing this would require administrators to upload the image, rendering them not uploadable by regular community members for essentially no good reason. Keeping duplicates used solely in the interface will make the engine unhappy (it will list the files as duplicates), or cause discrepancy between these two files, which would have to either be kept (for no reason) or fixed by having administrators upload the protected copy (creating a duplicate with restricted maintenance). Images which can never be updated, such as locks, solve all the aforementioned issues.
--AttemptToCallNil (report bug, view backtrace) 12:57, 27 June 2018 (UTC)
Definitely a good point. We don't want anybody who's logged in to be able to overwrite an important skin image, nor do we restrict the ability to reupload several images that would appear on Minecraft-related articles (that may need to be updated to comply with new versions), to administrators. Therefore, I have to withdraw my support to use Minecraft icons to signal page protection.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 13:01, 27 June 2018 (UTC)
I can try drawing 16x16 padlock icons to make them look like Minecraft... Lê Duy Quang (Make some words | Contributions) 14:27, 27 June 2018 (UTC)
For more appealing results you could just extract the padlock from this file and recolorize the body. Just a suggestion. – ItsPlantseed|⟩ 15:32, 27 June 2018 (UTC)
Madminecrafter12: See my sandbox now, I created some differently-coloured message boxes with the blocks I mentioned above, and some links on the message boxes to suggest the reader to create account/log in, request edit or unprotection, and I will now try to start working on the edit request template I mentioned above on the sandbox - psl85 (☎ Talk | ✏️ Contribs) 15:51, 27 June 2018 (UTC)
As you can see above, Nil pointed out that the message boxes are a bit disruptive and messy, and it would be better to use plain text. As shown in my sandbox, I've used plain text instead - as I agree with this. Also, note that GRASP aren't able to edit fully-protected pages - only admins and wiki guardians can. And I personally don't think an edit request template would be necessary, as I've said above. I do like where you're going with this, though. :)-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 15:58, 27 June 2018 (UTC)
Madminecrafter12 I will use plain text, but I created some differently coloured message boxes, and I think those not was too messy an ugly, I can add the protection block and plain text- psl85 (☎ Talk | ✏️ Contribs) 16:04, 27 June 2018 (UTC)
@psl85: I have made the locks, which you can preview here:
All locks.PNG
Lê Duy Quang (Make some words | Contributions) 16:14, 27 June 2018 (UTC)
Leduyquang753 Cool locks, and I would use those, the only need is only have one file/padlock - psl85 (☎ Talk | ✏️ Contribs) 16:22, 27 June 2018 (UTC)
I fail to understand the insistence on styling everything like Minecraft. The current locks are already perfectly functional, the choice is purely stylistic (following an unstated and pointless guideline), so creating new images where other already exist and are capable of doing their job is a wasted effort. --AttemptToCallNil (report bug, view backtrace) 16:55, 27 June 2018 (UTC)
psl85. Here are 10 icons in the preview colored according to Wikipedia's protection locks with description of what they do. You can try using them in your sandbox messages. And AttemptToCallNil, if this wiki doesn't need anything to look like Minecraft at all, why does the Hydra skin exist? And the icons near the links in the mainpage. They all have the same purpose to make this Wiki look more like a Minecraft wiki, don't they? Lê Duy Quang (Make some words | Contributions) 01:22, 28 June 2018 (UTC)


 Comment I don't see the point of having that padlock template at all, it's just adding more workload to the admins who have to change the template every time they change the protection. Apart from that, it's rather obvious if a page is protected or not, protected pages have "View source", unprotected pages have "Edit" (and "Edit source" if you've enabled the visual editor).
My point is, we aren't Wikipedia. I don't see the point in creating meta-templates which add nothing to the contents of the page. It will just make everything messier.
Lastly, Leduyquang, I appreciate the work you put into pixeling the padlocks, but in my eyes, they don't fit to Minecraft at all and also look a little clumsy. As I mentioned on Discord before, it would make more sense and look better if you just used the padlock texture that's included in Minecraft anyway (given that it's decided that such a template is needed in the first place). | violine1101(Talk) 09:45, 28 June 2018 (UTC)

"doesn't need anything to look like Minecraft at all" means "shouldn't have elements which look like Minecraft", the opposite of which is "may have elements which look like Minecraft". What you're trying to accomplish is "shouldn't have elements which don't look like Minecraft", which is not a valid opposite.
And yes, why bother adding locks if we can just change the protected edit message? --AttemptToCallNil (report bug, view backtrace) 10:05, 28 June 2018 (UTC)
Adding locks gives a nice, compact indicator to the users about the protection state of a page. Having a massive message box (a small one is still big and distracting in this case) at the top isn't good for focusing on the below content. And the difference between "Edit source" and "View source" only indicates whether the user can edit it or not. Lê Duy Quang (Make some words | Contributions) 14:05, 29 June 2018 (UTC)
And also using the vanilla's lock icon doesn't give a nice result because it needs to be recolored to indicate different protection states. The lock's texture looks like gray stone, so recoloring it makes it ugly. Lê Duy Quang (Make some words | Contributions) 14:08, 29 June 2018 (UTC)
My main point was that admins would have needed to update the template on the page every time. This problem has been solved with AttemptToCallNil's proposal below. Locks are fine with me, but to be honest, I still don't like your pixel arts.
The question now is, which indicators do we need? Should the colors mean something or should they be random? Let's take a look at your proposal from User:Leduyquang753/locks:
Color Default Your proposal My proposal Meaning Notes
Gold Fully-protected page lock.png Fully Protected Pixelart Lock.png Minecraft protection lock full.png Fully protected Gold makes sense, but your color looks a little dull at the moment.
Green Move protected page lock.png Move Protected Pixelart Lock.png -- Move protected Do we really need a seperate lock for move protected pages?
Silver Semi-protected page lock.png Semi Protected Pixelart Lock.png Minecraft protection lock semi.png Semi protected Makes sense, but the gray is a little dark.
Pink -- Template Protected Pixelart Lock.png -- Template protected What's the difference to normal protection? Besides, this protection level doesn't exist here as far as I know. Also, the pink is too similar to the purple of the Upload Protected lock.
Purple Upload protected page lock.png Upload Protected Pixelart Lock.png -- Upload protected Again, what's the difference to normal protection? Why do we need a seperate lock for this? Do there actually exist pages which are upload protected. Also, the purple is too similar to the pink of the Template Protected lock.
Light blue -- Cascade Protected Pixelart Lock.png -- Cascade protected Every page which is cascade protected is also normally protected. Why do we need an extra lock for this? Also, the light blue is too similar to the cyan of the Create Protected Lock.
Cyan -- Create Protected Pixelart Lock.png -- Create protected Again. Why an extra lock? Also, the cyan is too similar to the light blue of the Cascade Protected Lock.
Blue -- Extended Confirmed Protected Pixelart Lock.png -- Extended confirmed protected What is this? I don't think this protection level exists here.
White -- Pending Changes Protected Pixelart Lock.png -- Pending changes protected No such protection level exists on the Minecraft wiki.
Black Director-protected page lock.png Office Protected Pixelart Lock.png Minecraft protection lock full.png Office protected (directors and above) I would use the same icon as for full protection; there's just a small amount of users to whom it matters whether a page is fully protected or protected on directors level.
| violine1101(Talk) 14:57, 29 June 2018 (UTC)

Support your icons. They are exactly what we need, they are clear and stay Minecraft enough. (We just need them a bit bigger) (And yup, only 2 of them is enough, the other categories are really optional, they don't need a specific lock) JSBM (talk) 15:20, 29 June 2018 (UTC)
Cascade protection used to be used with the main page onto various templates, but in most cases its a bit difficult to tell why a page is protected if its just marked with regular protection (difference between "we think this page is a target" and "we think this page may be used to target another page") so it might be worth a separate lock to mark. Hard part is its slow to fetch anyways compared to regular protection data.
Otherwise, I prefer the locks that are actual sprites over the pixelated ones. Between the antialiasing and the black borders they don't really match Minecraft's style in my opinion. KnightMiner · (t) 18:46, 29 June 2018 (UTC)

Yet another idea[edit]

JavaScript could be used to place locks on protected pages automatically. It saves the need for administrators to add a template every time a page is protected and remove the template when it expires or if it is removed. It could be implemented as a gadget.

This script I wrote (it's not exactly pretty, but I found no predefined functions to set indicators) uses the Wikipedia-style icons. As I have said before, these icons are perfectly functional, there's no point to create new ones as if just to conform with a nonexistent rule demanding we make every interface image Minecraft-styled. --AttemptToCallNil (report bug, view backtrace) 14:12, 29 June 2018 (UTC)

We should make a debate... Lê Duy Quang (Make some words | Contributions) 14:30, 29 June 2018 (UTC)

 Support This works really well, nice script! | violine1101(Talk) 14:57, 29 June 2018 (UTC)

 Nice script. That's a kind of script what I meant above. Whould this script fit in Mediawiki:Common.js? This would work very well for the main view of a page, and the system message from the New idea above would work for the edit view. – Jack McKalling [ Talk Contrib ] 08:48, 2 July 2018 (UTC)

"Twinkle" gadget on this wiki[edit]

Hello! I think that this wiki should have some new gadgets from Wikipedia, such as Twinkle, Navigation popups, wikEd (I edits with this gadget installed in the JavaScript subpage), and minor gadgets for syntax highlighting, mark blocked users and admins, and dropdown menu to easily choose edit summary while editing, think I to be added to this wiki, and I search for more gadgets, if Twinkle should be added, could it be customized for use on this wiki and its usage could be same as on Wikipedia, and it may need some lesser templates and only existing templates should be used by the gadget. psl85 ☎ Talk 14:14, 5 June 2018 (UTC)



 Support. These could be great things to keep the Wiki fresh and clean. Lê Duy Quang (Make some words | Contributions) 01:21, 24 June 2018 (UTC)

 Support twinkle and navigation popups.
 No opinion on wikEd as I generally don't use any type of visual editor, although I will note that the correct link is User:Cacycle/wikEd, not User:Azatoth. Also, I'll note that I tried to use twinkle via user JS and that didn't work, though that was a while ago; the module would be very nice (but it definitely would need editing for the list of templates). --Pokechu22 (talk) 01:41, 24 June 2018 (UTC)

What if Minecraft appears in another game?[edit]

What shall we do if Minecraft appears in another game, like the upcoming Super Smash Bros.? Should we create an article for the game? Hugman_76 [ User page Talk page Contributions ] 16:07, 9 June 2018 (UTC)

There is a section about Minecraft references in other games (Minecraft#References_in_popular_culture) :) • Yanis48 (talk) 16:23, 9 June 2018 (UTC)
To give a more general answer, no. This wiki exists to document what's in Minecraft, not what's in other works. Besides, that "news" is just a rumor from DasVergeben, who isn't a particularly reliable source according to this GameRant article. – Auldrick (talk · contribs) 16:51, 9 June 2018 (UTC)

Development versions or current version for names, images, sprites, etc.[edit]

There seems to be some dispute as to whether the title of images, the texture of images, the texture of sprites, and the word used in articles for a certain title of a feature or texture of a feature, as to whether it should be the one in the latest development version or in the latest full-release version. It seems like the description of the actual functionality of features is always how they work in the current version (except for statements marked with {{upcoming}}), so it seems like the names and textures should be the same way. I've been trying to keep them as they are in the current version, because it seems to make the most sense - a few times this has gotten reverted, but most of the time it hasn't. Here are some examples:

  • In this edit, all instances of "fish" were replaced with "cod." I changed this back later, and this time it was actually undisputed. However, it had stayed at the 1.13 name for a long time.
  • As can be seen here, the image was reuploaded in February to comply with the new 1.13 texture. I reverted it back, explaining my reasoning. However, that was reverted again by somebody else, because File:Pufferfish 13w43a-18w08b.png exists. I didn't re-revert, because I didn't want to start an upload war.
  • All of the fish textures and sprites were updated to the 1.13 textures. I changed them back after many months of being on the 1.13 names, and most of the changing back was undisputed; in fact, I actually got a few thanks for it. However, many of the sprites now seem to use the 1.13 name - but again, I don't want to start a sprite-edit war.

In my opinion, we should try to have both the texture and name in the current development version and the current full version, but the one in the full version should always take priority. For images, the actual in-game names, such as File:Water.png and File:Pufferfish.png should be the texture of the current version, not the latest development version. However, I think there should also be separate files, e.g. File:Water in 18w15a.png and File:Pufferfish 18w08b.png, for the textures in the latest development version. For the sprite names, I think that both the name in the current dev version and the current full version should be aliases for each other - however, I think that the current name is what should be used in articles, which is not the case right now. For sprite textures I feel the same way as I do for the images - the main one should be of the texture in the current full version, but there should be an additional one with the texture in the latest dev.

My reason for this is, 1.12.2 is still the current version the game is on right now - so no matter what crazy features have been added in development versions, the names/textures in 1.12.2 are the names and textures in the game. Another reason is for consistency with the actual description of features. The descriptions of the features is mainly how it is in the current version - with upcoming changes marked with {{upcoming}}. I don't see why textures, names, and sprites should be any different. However, I do think it can't hurt to prepare for 1.13 - which is why I support adding the dev names as aliases in sprites, and upload the new textures as separate files.

I propose that we discuss this here so that we can come to a decision once and for all.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 13:49, 13 June 2018 (UTC)

I mostly agree. In my own words, I think all files and other assets that are named in-game, should always carry the same name as in the latest full release. Any new name for them introduced in development builds/snapshots/releases should be an alternate name with the relevant version in it. If the graphic was not changed, the development name should redirect, otherwise, it should be an alternate file/asset altogether. As for the text on the articles, this should always reflect the latest full release, with specific {{upcoming}} notations/history entries being the only exceptions to that. – Jack McKalling [ Talk Contrib ] 14:34, 13 June 2018 (UTC)
In my opinion, we should try to have both the texture and name in the current development version and the current full version, but the one in the full version should always take priority. The highlight of the message, and I agree with it.
I think there should also be separate files, e.g. File:Water in 18w15a.png and File:Pufferfish 18w08b.png, for the textures in the latest development version. Also agree.
For the sprite names, I think that both the name in the current dev version and the current full version should be aliases for each other - however, I think that the current name is what should be used in articles, which is not the case right now. Agree with everything but one case. If development versions for one full version change both the name and the texture, no full version exists where the new name corresponds to an item with the old texture. This is why I think that, in such cases, the new name should be mapped only to the sprite with the new texture.
--AttemptToCallNil (report bug, view backtrace) 14:58, 13 June 2018 (UTC)
I agree that upcoming textures and names should both not be used until a release. In my opinion MCW:FUTURE already applies to feature names and textures as well direct information. At the very least we should add on the style guide that it specifically applies to textures and names as well. KnightMiner · (t) 15:10, 13 June 2018 (UTC)
Ah yes, I was going to mention in the post but I forgot - whatever the consensus is, I think we should add it to the style guide. That way it will be clear to everybody that it is an official guideline, rather than just one user thinking that it makes sense one way.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 15:16, 13 June 2018 (UTC)
(Edit conflict) In the past, it clearly made better sense to stick to released versions' names and images, because those are familiar to everybody whereas updated versions might not be. Unfortunately, this rule is no longer tenable because there is no longer a clear line between released and development usage. You all may not have thought of this, given that you equate "1.12.2" with "released version" and "1.13" with "development version" (sadly, one of the many examples of insidious Java elitism among the editors on this wiki), but different editions have different chronologies and any feature can be in both states at the same time. For example, the new Pufferfish texture is already in the release version in Bedrock but still in development in Java. (The last time I looked, the Fish (mob) infobox bizarrely had the new texture but the old sprite.) Given this conflict, I think we need to be more flexible. I suggest that a texture or sprite be allowed if it has been released on any version, or used consistently across several development versions in one or more editions. – Auldrick (talk · contribs) 15:31, 13 June 2018 (UTC)
I say that makes sense to extend the idea to being released in any version. Since we can not easily just use all sprites, the one that makes most sense is whatever is the current texture, so a priority system to show the texture from the latest release makes sense. Just as long as we clearly show that it has not changed in all editions yet. KnightMiner · (t) 15:49, 13 June 2018 (UTC)
Agree with the proposed edition-related amendment. What if an item has different names and/or textures in different editions? That case isn't covered. --AttemptToCallNil (report bug, view backtrace) 16:10, 13 June 2018 (UTC)
I think if we stick to just moving the images, it's fine (which is atthis moment basically already done (only Tall Grass -> Grass and Double Tallgrass -> Tall Grass left); the actual pages themselves shouldn't be moved yet until 1.13 release though. Without a doubt the bedrock (and possibly legacy console) editions will start following the new names soon. FVbico (talk) 18:40, 25 June 2018 (UTC)
As AttemptToCallNil mentioned 2 comments above this, at time of writing, what if the names and/or textures are different in different released editions? Currently relevant to the discussed on Talk:Monster_Spawner#Recent_Move_suggestion. I personally would be comfortable picking the name that any of the Minecraft team say is going to be going forward. For instance if two editions call it Fish, and one calls it Cod, but Helen for instance attests that they plan to rename it all Cod, that would be sufficient for me. Sufficient, but maybe not necessary. There may be other ways to decide it, and maybe there are counterarguments to that whole Helen thing. I only offer it here because FVBico offered it as a reason in the other discussion and I happened to agree. What do people think? – Sealbudsman talk | contribs 18:10, 17 July 2018 (UTC)
For article names, as long as the old article name is kept as a redirect to the renamed article, I'm fine with assuming the new name (like Cod instead of Fish). It's much easier than keeping a conflict between editions. However for the name occuring within text, I'm not sure. Would it be easy to understand what is meant with "Cod" in the middle of a sentence, where the reader is used to only know "Fish"? Of course they could click it and learn about it, but is that enough? – Jack McKalling [ Talk Contrib ] 18:43, 17 July 2018 (UTC)

Zombie hurt.ogg[edit]

The file doesn't work on the Zombie page. –Preceding unsigned comment was added by Enderdespawnmite (talkcontribs) at 3:50, 17 June 2018 (UTC). Please sign your posts with ~~~~

Works fine for me. KnightMiner · (t) 04:05, 17 June 2018 (UTC)

Moving mod files to a sprite sheet[edit]

Hi! In my desire to improve the mods part on the wiki, I wanted to find a solution about all these mod files, mainly grids, used only once. So I thought about making a sprite sheet for that. With the agreement and help of Madminecrafter12, I tested it and it works exactly like InvSprite. It is currently called ModSprite.png, with the corresponding template and module.

So, what do you think about that? Do you agree to move the maximum number of mod files into this sprite sheet? • Yanis48 (talk) 15:20, 17 June 2018 (UTC)

The Russian wiki creates a sprite sheet for every mod which contains sprites just for that mod. The English version of Module:Inventory slot should have similar support.
Note that some people have been moving to deprecate mod support and eventually migrate all mod articles from the wiki. --AttemptToCallNil (report bug, view backtrace) 15:33, 17 June 2018 (UTC)
I definitely that would be a good idea if we decide to keep mod content here, but there's not much point of working hard on a sprite for mods only to have all mods removed or migrated.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 15:50, 17 June 2018 (UTC)

 Opinion Hi there. i personally think that we should keep mod articles here. Any objections or support?--TheCreeperStrikes (talk) 17:49, 17 June 2018 (UTC)
I personally would be in favour of removing mod content from this wiki, but setting up a sister wiki dedicated to mod, fandom, etc, content. - MinecraftPhotos4U (talk) 17:53, 17 June 2018 (UTC)
What should we do?, Anyone? - - TheCreeperStrikes (talk) 18:05, 17 June 2018 (UTC)
Its worth mentioning this wiki has an unofficial partnership with the Feed the Beast Gamepedia, which covers many mods both in Feed The Beast packs and some independent ones. I personally would rather just drop modded content in favor of not duplicating effort between this wiki and that one. They have a much better framework set up for mods (including support for Forge features like the oredictionary in modded recipes), plus it saves us from having to make a list of guidelines about what makes a mod notable. Additionally, with how poorly maintained the mod pages are here, I doubt we would have an easy time finding enough editors to handle all the mods, most editors tend to just handle a couple mods they personally play. KnightMiner · (t) 18:23, 17 June 2018 (UTC)
😞 I spent so much effort uploading all those images and they’ll just get DROPPED? Like that?!, *deep breath* Sorry, just went a little overboard there *sigh*
-TheCreeperStrikes (talk) 18:33, 17 June 2018 (UTC)
Hmmm… maybe we could make a wiki for each individual mod (not everything)?-TheCreeperStrikes (talk) 07:52, 18 June 2018 (UTC)
Wiki for each individual mod? That's not really a great idea IMHO - seeing how much the FTB Wiki relies on some common stuff (common templates like infoboxes, navbox and oredict frameworks, vanilla Minecraft crafting templates and tilesheet, etc. - imagine syncing changes to that...) and that many mods have integration with other mods (copying a template for some machine across 10 wikis to show some mod integration?). Keeping that stuff in sync would me more trouble than it is worth. Also, you'd have a lot more than one recent changes page to keep track of. Modded content doesn't really have enough wiki manpower for splitting it like that in my opinion. --Hubry (talk) 08:24, 18 June 2018 (UTC)
Agreed with Hubry. We don't need another wiki for each mod on here. The Feed The Beast wiki already covers a great deal of the mods, it would not be a bad decision to relocate all our mod content over to that wiki, or delete if it's already there/outdated. Our wiki isn't really suitable for mods, we're just documenting the game itself. – Jack McKalling [ Talk Contrib ] 09:46, 18 June 2018 (UTC)
Then we could just export {{ModSprite}} there.-TheCreeperStrikes (talk) 14:33, 18 June 2018 (UTC)

Project announcement[edit]

MCW:Projects/Refactoring edition specific information is a new project intended to explore ways we can structure edition-specific information to yield smooth, natural prose in articles, and later to clean up articles that need it. Interested editors are encouraged to join by adding their names to the Members list on the project page. – Auldrick (talk · contribs) 02:00, 20 June 2018 (UTC)

Elements and existing pages with the same name[edit]

Here's a couple of pages that I think should be moved to free up space for element redirects

I don't think there are any other pages like this, but I'd like some input before I (or someone else) move these. Kienan (talkcontribs) 19:20, 20 June 2018 (UTC)


 No support for redirecting the pages to the element. I suspect that the majority of users entering Gold or Iron as a URL would not want to see the element, but instead a disambiguation.
 Maybe support moving the articles and having Gold redirect to Gold (disambiguation), and including the element on there. But maybe it's just better to leave it as-is. Wikipedia seems to just not use the (disambiguation) suffix in that case (in fact, they redirect the disambiguation page back); for instance Mercury and Mercury (disambiguation). In fact, that gives a fairly good case for it, in that mercury itself is an element. --Pokechu22 (talk) 19:32, 20 June 2018 (UTC)

 Oppose moving. The primary meaning for non-Education Edition-oriented readers (which I expect to be the majority of the wiki's audience) would most likely be the resource in general, not the element. Redirecting Name to Name (disambiguation) would be completely pointless, same with the reverse redirect; or, to be more accurate, these redirects are only useful if some program code we can't modify handles "(disambiguation)" titles in a desirable special manner, and I am not aware of any such distinction. --AttemptToCallNil (report bug, view backtrace) 19:51, 20 June 2018 (UTC)

 Weak oppose. If we were to be perfectly consistent and always use the in-game names, the pages should be moved, which is why my oppose is weak. However, I really think readers searching for gold are much, much more likely to want to go to gold ingot or gold ore than the element page. In my opinion, this is more important than being perfectly consistent and always using the in-game names.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 01:52, 21 June 2018 (UTC)

 Oppose moving; while it has to be acknowledged that they are in-game names, they're not something from the core gameplay. The existing pages for gold and iron have to take precedence in ambiguous situations like this because they are based in the core gameplay. – Sealbudsman talk | contribs 02:46, 21 June 2018 (UTC)

 Oppose move. The disambiguation suffix should only be used for pages like this when there are other articles with the same name, but as said above, the term "gold" and "iron" are only a partial use for in-game names. Those elements from Education Edition are basicaslly edition exclusive and that's not enough reason to override that partially used in-game name. Having a link to Gold (element) and Iron (element) on the Gold and Iron pages respectively is the best way here, IMO. – Jack McKalling [ Talk Contrib ] 08:54, 21 June 2018 (UTC)

 Oppose. We should instead keep the page Gold (element) for the element, like
Clay (block)
, and leave the Gold page alone. Lê Duy Quang (Make some words | Contributions) 01:16, 24 June 2018 (UTC)

Item stack general format[edit]

So, when a high amount of item is expressed in the Wiki, it would be "x stack(s) and y item(s) (n total items)", which is a bit complicated. So I am thinking of a template that we could write it as for example "2s35" with the hover comment "2 stacks and 35 items (163 total)". Improvements can be made as long as they make sense, then this would make the Wiki more compact. Lê Duy Quang (Make some words | Contributions) 02:36, 24 June 2018 (UTC)

Question about sparklers[edit]

According to the text:"When lit, the sparkler will emit colored particles; the durability meter depletes while the sparkler is burning.",is that means sparklers have it's item durability? (In zh,it displays "?")--Wth213 (talk) 08:24, 28 June 2018 (UTC)

Absolutely, it only burns when you hold it in your hand though. – ItsPlantseed|⟩ 10:30, 28 June 2018 (UTC)
Well,how should we express it?If not,please tell me reasons.--Wth213 (talk) 02:56, 29 June 2018 (UTC)

Weird spacing and bullet formatting on templates[edit]

I'm not entirely sure where to post this so I guess I'll post this here: On navboxes, the formatting seems to be a bit bugged with creating additional bullet points - while it does make it in parentheses, at the end it has a weird space before the ")" and it creates a space between that and the next item. You can see this better on the Bedrock Edition versions template. It just seems off so if this can be fixed that would be great. --Marioprotvi (talk) 20:16, 28 June 2018 (UTC)

It's been the case since tidy was broken, and tidy is a requirement for hlists to work properly, so nothing we can do about it. MajrTalk
Contribs
07:52, 30 June 2018 (UTC)

Replace edition abbreviation links with templates[edit]

Replacing edition abbreviations links like BE with templates like {{BE}} would be useful as we can have the template link to the full page name, so the title says the full name rather than just the abbreviation to make it clearer to readers what it means. It also provides the opportunity to add some styling to the links (like a background colour or icon). MajrTalk
Contribs
08:01, 30 June 2018 (UTC)

File naming consensus[edit]

There doesn't seem to be any file naming consensus except for things from mods (suffixing with "(<mod name>)").
There's files in all different naming conventions:
runninglowercase
lowercase with spaces
Capitalrunning
Capital On Every Word
Capital on first word
etc.
Even file extensions have the FULLCAPS and nocaps variants used interchangably.
Alongside this inconsistent naming, there is no telling if the file is a user file by name (or from who it is in general).

I propose the following naming convention:
File:<user name in case it's a user file> Capital On Every Word (<mod name>).lowercase extension
Examples:

  • File:FVbico Some Funny Meme.gif
  • File:Computer (ComputerCraft).png
  • File:Skeleton Riding Spider.png

Of course, changing all existing files will take a long time, so when a naming convention is chosen, I (potentially others too) will go through all files and move to the proper naming. FVbico (talk) 12:51, 1 July 2018 (UTC)

I
 Support it, though I might take it a step further; for user files, call it like: File:User FVbico Some Funny Meme.gif. Just so that it's more obvious in case someone's username is something ambiguous like Indev. –Preceding unsigned comment was added by Sealbudsman (talkcontribs) at 17:13, 1 July 2018‎ (UTC). Please sign your posts with ~~~~
Actually that’s a good point, didn’t think of that. FVbico (talk) 18:32, 1 July 2018 (UTC)

 Neutral. I would be open to having a message when uploading a file, telling the uploader to give the file a detailed name that describes the image clearly, AND use whitespace where you normally would. We could also add that little bit to MCW:IMAGES. However, I don't think the userspace and capitalization restrictions would be necessary, so I'm against making that part a formal guideline.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 13:43, 3 July 2018 (UTC)

 Neutral: I like the idea of consistent naming, but I really don't think there is much benefit to moving a bunch of old files just to match that as it just clutters the move log and potentially breaks usage on user/translation pages (as from what I have seen of recent moves users tend to ignore fixing those links). Most of the files get just use on one article so if its a poor name no one really needs to deal with it. I would be in favor of documenting a proper standard for new files, probably just having them use the article title rules at that, but I don't feel it should be enforced to heavily. KnightMiner · (t) 21:04, 14 July 2018 (UTC)

 Support, even if I'm not sure if it should be applied too much... We can let people have some liberty, for example with the capital at each words, and perhaps not change all previously uploaded files unless they are really too much different from that system. JSBM (talk) 21:23, 14 July 2018 (UTC)

Drowned and Zombie[edit]

The information for the Drowned is on the Zombie page, so why not merge the pages? EDSM.png Talk.png Edits.png 02:34, 3 July 2018 (UTC)

If so, it should also applies to Husk. Hugman_76 [ User page Talk page Contributions ] 14:27, 3 July 2018 (UTC)

 Comment Husk has already been merged into the zombie page.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:29, 3 July 2018 (UTC)

 Oppose. Drowned currently is actually quite a long page as far as content goes, with a lot of detail about spawning, drops, and behavior, much of which is very different than zombies. Merging the two would make the zombie page more cluttered, with little benefit.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:39, 3 July 2018 (UTC)

 Oppose. It's pretty clear that they are different mobs. Also, merging all entities that could fit under the term "zombie" doesn't help much with adding more information to the wiki, but only clutters it up with so much information that it gets confusing. (Hence I also disagree with Husk and Zombie villager being part of the Zombie article. They aren't real zombies either and have their own special properties.)
On an unrelated note, this should be on Talk:Drowned, not here. | violine1101(Talk) 15:32, 3 July 2018 (UTC)
Note - the same thing is currently being discussed here.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 12:46, 4 July 2018 (UTC)

 Oppose - why is Husk on the same page as Zombie, anyway? - MinecraftPhotos4U (talk) 17:13, 5 July 2018 (UTC)

 Oppose. Also,
 Note that the inverse thing is also being discussed on Talk:Zombie#Split Zombie variants off from this article, with unanimous support for splitting. --Pokechu22 (talk) 05:27, 14 July 2018 (UTC)

Using artworks instead of renders in some info boxes[edit]

Dolphin
Dolphin Artwork.png
Health points

10 (Heart.svgHeart.svgHeart.svgHeart.svgHeart.svg)

Attack strength

Easy: 2 (Heart.svg)
Normal: 3 (Heart.svgHalf Heart.svg)
Hard: 4 (Heart.svgHeart.svg)

Spawn

All ocean biomes except frozen oceans

Common drops
Experience

0

Internal ID

N/A

Entity ID

dolphin

Some entities got official artworks. I was wondering, why don't we use these in 'Entity Boxes'? I've put an example on the right side to prove you how it could render, but it can works with other mobs with official artworks, like Turtle Artwork.png, Pufferfish Artwork.png or even Steve & Alex Aquatic Update Artwork.png. Hugman_76 [ User page Talk page Contributions ] 17:51, 3 July 2018 (UTC)

While I can definitely understand the appeal of this, I'm not sure if this will fit well in an unofficial encyclopedic context (especially given these are not honest in-game appearances), and the fact that we don't have artworks for absolutely everything would cause major inconsistencies. I otherwise wouldn't mind this if it weren't for these problems. - MinecraftPhotos4U (talk) 15:40, 3 July 2018 (UTC)
Take the encyclopedic context out of the cage. Does other game wikis will choose a T-Pose of the mob in question? Nope, and we're litterally doing this. Also I don't think they aren't honest in-game appearances, and even so, again, the other wikis does this as well. For the inconsistencies, we could keep the 'T-Pose' renders under the first paragraph or something like that, or even make an image2 in the infobox. Hugman_76 [ User page Talk page Contributions ] 17:51, 3 July 2018 (UTC)
My opinion: This looks nice, and arguably better than the renders from the game we have now. However, the wiki is supposed to document the game as it is. Ironically, Minecraft's artworks have a different artstyle than the actual game, it uses even more simplified textures for everything. Therefore, I don't think that it would be a good idea to change the images in the info boxes so that they are different from the game.
Also, there's the question of where to get the artworks from – we can make the renders by ourselves, for the artworks we would need to wait for Mojang or Microsoft to come along and create one. | violine1101(Talk) 18:05, 3 July 2018 (UTC)
We could display these artworks somewhere else, like in the second image of the info box template to not remove the render. Or even add it under the first paragraph of the article. Hugman_76 [ User page Talk page Contributions ] 18:48, 3 July 2018 (UTC)
I have to agree with Violine1101 here. I definitely see where you're going with this, and I like how they look - however, I really think it's better to use the exact in-game textures for infoboxes, as they are right now. Also, I don't really see much benefit for having the artwork as the second image in the infobox. However, I do like the idea of including the artworks in the gallery.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 12:50, 4 July 2018 (UTC)

A patroller user group[edit]

This was suggested on Discord and seemed to be supported. Pinging JSBM and MarkusRost, as both of these users participated and voiced their opinions in the discussion, so it would be great if they could do the same here.

So as you can see above a proposal was made to create a new user group that can semi-protect pages. However, there were a number of concerns raised about this on Discord that I agree with. First of all, I could easily see this being abused in edit wars even by an experienced user - one user thinks they're right so they just semi-protect the page. Second, many experienced users may semi-protect incorrectly - e.g., because of 2 IPs vandalizing twice in the last month, or one IP vandalizing 5 times. Also, protecting usually isn't the answer to vandalism - it's usually actually blocking. So if we give somebody the access to semi-protect, they may do that when blocking is really the answer - because they don't have permission to block. And if we allow them to protect AND block, then we might as well just go ahead and give them admin. Finally, I'm not sure if it's possible to allow editors to only protect pages for a short amount of time - we would likely have to create a whole new user permission, as currently it's just listed under one: protect. And is it really worth it, especially considering protecting really isn't usually the way to go in cases of vandalism? Many of these concerns I have are shared here.

However, I support creating a new user group called "Patrollers" that gives the following rights:

  • Mark others' edits as patrolled (patrol)
    • What this does: It allows to click the button "Mark as patrolled" in a diff. In recent changes, any unpatrolled edits have a red exclamation mark next to them. This allows admins (and possibly soon patrollers) to see the edit, look over it, and know that it has not yet been reviewed, or the administrator who reviewed it doesn't know if the information is accurate or not. Although this isn't a necessary feature, I definitely think it would be helpful.
    • Reason: The patrol backlog is very large right now. Dinoguy and I are pretty much the only ones patrolling, and about half of all edits remain unpatrolled by the end of the day. I could see this being very helpful for users who can't look at every edit in recent changes - they would be able to see which edits have been reviewed or not, so that the unpatrolled can take priority. Patrolling isn't a necessary feature, but I do think it's a good idea and helpful in many circumstances.
  • Quickly rollback the edits of the last user who edited a particular page (rollback)
    • What this does: On the latest diff of a page, there is a "rollback" button. When this is clicked, it will revert all of the last consecutive edits by that user. This will also automatically mark the user's rolled-back edits as patrolled. Additionally, Majr created a wonderful script that allows for a custom rollback summary without having to load any new screens. This is very helpful for reverting bad edits that were likely made in good faith, which would usually warrant an edit summary
    • Reason: Rollbacking is much, much quicker. Especially for multiple edits. If a normal user finds a user who made multiple vandal edits, they must navigate to the diff before their edits, reload several screens, click the edit button, wait for that screen to load, put in the edit summary something like "Rvv last 3 edits," click save changes, and wait for that to load. With rollback, all of that's in a single click. Additionally, you can revert multiple good faith edits using rollback much quicker as well, as long as you don't disable to editable rollback summary gadget. Instead of doing the same thing as for vandal edits except adding an extra custom edit summary, just click the pencil button next to the rollback link, quickly edit the summary, press save, and the edits will be reverted right away. Additionally, rollbacking automatically marks edits as patrolled, which is another reason why having a user group that can rollback edits would be helpful.

-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 13:41, 5 July 2018 (UTC)


 Support Frisk (Talk page) 13:46, 5 July 2018 (UTC)

 Support david92003 (talk) 13:50, 5 July 2018 (UTC)

 Support also --Wikipedia-logo.png psl85 (profile | talk | contribs | send email) 14:25, 5 July 2018 (UTC)

 Support  HorseHead.png MarkusRost (talk) 14:38, 5 July 2018 (UTC)

 Support And officially, I want to get all the credit for that idea! JSBM (talk) 17:21, 5 July 2018 (UTC)

 Support sounds great. – Sealbudsman talk | contribs 03:47, 6 July 2018 (UTC)

 Support. In addition, I see no reason for any user to have patrol and not autopatrol rights. Maybe we could also grant autopatrol rights to the group, or alternatively, make sure every member of the group is also a member of the autopatrolled group? --AttemptToCallNil (report bug, view backtrace) 14:49, 6 July 2018 (UTC)
I do think it would be better to keep them separate, just in case for some odd reason one may think a user could be trusted with patroller but not autopatrol, which would be rare. But yeah, in most cases, users would get both user rights - and there's not much of a problem with that; literately the only difference is a bureaucrat checking off one extra box when changing user rights.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:36, 8 July 2018 (UTC)

 Support. I would really like to participate patrolling in my favourite set of pages. It's what I'm already doing basically anyway, without the actual applied hint. And this has nothing to do with my autopatrol usergroup, nor with achievements. I'd like to see it as guarding pages against all kinds of imperfections and what not that I could find as a voluntary task. Besides, it's a built-in feature already to actually patrol edits anyway, why not use it more if admins can't cover it enough. – Jack McKalling [ Talk Contrib ] 23:23, 9 July 2018 (UTC)

 Support as well. | violine1101(Talk) 19:32, 12 July 2018 (UTC)
Group created and populated July 12, 2018 — Game widow (talk) 19:39, 12 July 2018 (UTC)

What should we patrol?[edit]

Since this proposal is heavily based on edits being patrolled, both manually and automatically during reverts, we should come to a consensus about what makes an edit worthy of being patrolled.

On one end of the spectrum, we could patrol everything as long as it isn't blatantly disruptive and/or against the rules. This will result in stealth vandalism being patrollable, not to count various errors.

On the other end, we could patrol only edits which don't require any further fixes, including spelling, grammar, facts... Needless to say, this effectively defeats the purpose of patrolling, making it massively difficult to patrol new edits.

I'm finding it difficult to even draft a proposal. Any suggestions? --AttemptToCallNil (report bug, view backtrace) 15:19, 6 July 2018 (UTC)

I definitely think that more than just blatant vandalism should be checked when patrolling, but I wouldn't necessarily say only edits don't require any further fixes should be patrolled. So I'm probably in between those two points, but closer to the second. Also, note that because I am an active editor of this wiki and have a lot of time to edit it, I often check for a lot more when patrolling than even what I personally think is necessary. I would say mainly check for and fix factual errors, wiki-code formatting errors (e.g., not closing a table causing the whole page to be messed up), and maybe very major prose issues, before patrolling. However, like I said, I have the time to be nitpicky, so I personally like to check for less important grammar errors, spelling errors, etc. as well.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 13:21, 10 July 2018 (UTC)
Rule violations, vandalism, invalid html structures (destruction of the webpage), wrong or misleading facts (false information), I think should all be checked. But stuff like rephrasing, spell checks, other maintenance, does not need patrolling. I imagine this from (humorously) analysing the picture that gamepedia gave to the patrolling achievements, namely an officer enforcing order. You basically patrol pages to check them off as being non-rule breaking. And if an edit violates something, to finish patrolling such edit you revert it or make another edit. And when you do, I believe this should not automatically mark all prior edits as patrolled (sometimes you check an edit that isn't necessarily the first unpatrolled one). However a quick rollback is most suitable to an automatic mark as patrolled for the related edits. – Jack McKalling [ Talk Contrib ] 14:20, 10 July 2018 (UTC)
Also, I'm assuming the patrol mechanism requires the patroller to eventually mark all edits whatsoever as patrolled, disregarding whether they originally had rule-breaking content. In the case they had, you'd of course fix it by reverting or another edit, before you manually mark the edit as patrolled. – Jack McKalling [ Talk Contrib ] 14:25, 10 July 2018 (UTC)
No edits are required to be patrolled. In fact, looking at the patrol log, the wiki didn't use the patrol feature hardly at all before December 2017, besides administrators having their edits automatically marked as patrolled. And even now, about half of the edits on the wiki remain unpatrolled, due to the huge backlog of edits and the very small number of administrators who actually patrol edits on a normal basis. However, it is definitely helpful to see what edits have been reviewed and which have not, specifically for people who may not have time to take a look at every single edit out there. Also, rollbacking edits automatically marks the rolled-back edits as patrolled (but undoing doesn't).-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:39, 10 July 2018 (UTC)
One thing I will say, is that I do really think that major grammatical errors need to be fixed before marked as patrolled. For example, if somebody adds "Ghast fireball shoot players," I really think that marking it as patrolled as it is, and telling all other editors that it's been reviewed, doesn't seem quite right. A minor grammatical error, such as "Ghasts will shoot fireballs at player," is fine being marked as patrolled. Imo, a patrolled edit doesn't mean it's worded perfectly, but it should mean that the edit has been reviewed and any major problems have been fixed.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 15:46, 11 July 2018 (UTC)
I agree a certain level of grammatical fixes may need to be applied before the mark. But there is a serious issue in determining what classifies as such. So I would say to solve this no grammatics need be fixed before marking as patrolled, unless the grammatical error(s) cannot get the intention across of the content. If you can still determine the meaning and people can add more words to make it complete, it may be patrolled. But if the edit would break the information due to ambiguity, potential misinterpretation or false information, it should not be patrolled before fixing it. Would that be better? In other words, assume "patrolling" means making sure the content is "correct(ly interpreted)" (and also non-rule breaking, but we already established that). – Jack McKalling [ Talk Contrib ] 10:27, 12 July 2018 (UTC)
With regards to "wrong or misleading facts (false information)": I think this is probably the most important use-case for patrolling. If an IP user (any user, but most recently it's been IPs that have been doing this) adds in some dubious information, it shouldn't be marked as patrolled until someone verifies that it's actually correct. That'd be an improvement over the current case, where such information can be added; someone will see it and thing "I should verify this"; and then they forget what they're doing and the information gets stuck. --Pokechu22 (talk) 16:37, 12 July 2018 (UTC)

Suggestions to the Minecraft Wiki[edit]

Here have I some suggestions to the Minecraft Wiki:

  • Make so autoconfirmed users can view abuse filters and the abuse log instead of only sysops, GRASP and wiki guardians
  • Make so the wiki have the "Minecraft" font or "Minecraft"-like font as default font
  • Some more skins, usually one "Minecraft" skin with the Minecraft font, stone background with white text, and other Minecraft items, and a skin with the sky as background and default font
  • Change the "Watch" tab to a Minecraft book instead of a default star
  • Add a "Interface editor" user group that users in that group can edit the MediaWiki: pages and create/edit editnotices
  • Make so users can create custom editnotices (as on Wikipedia [1]) for their user and talk spaces as notice while an editor trying to edit the page
  • More gadgets (wikEd, Twinkle (should be modified to use on this wiki), Navpops, dropdown menu to choose subject/edit summary while editing a page, ProtectionStatus (padlock on top right corner on protected pages), HotCat, a "AutoRefresh" tickbox on Special:RecentChanges to automatically refresh the page instead of reloading the page)
  • A "Translate" extension on this wiki (as on ftb wiki, mediawiki, meta wiki) instead of creating translation projects

Please add comments below --Wikipedia-logo.png psl85 (profile | talk | contribs | send email) 16:02, 5 July 2018 (UTC)

No. --Pcj (talk) 16:14, 5 July 2018 (UTC)
I am going to go by number so its easier to reply to:
  1. I see no reason to grant more people abuse filter rights, especially since some of the abuse filters apply to auto-confirmed users and they rarely need changes.
  2. The Minecraft font would drastically decrease text readability, plus does not support many special characters. I would encourage you to enable this in your own custom CSS instead
  3. Mostly neutral on alternate skins. They serve little benefit and require modifying templates to support them though (plus users may make visual changes to reflect their personal skin), so leaning against having them. You can easily make one in your custom CSS though.
  4. I have that in my personal CSS and it looks pretty good, but when I proposed it before the consensus was it was not immediately clear the book represented watch.
  5. I see no reason to have an interface editor group, they need rare enough edits that you can just ask one of our admins
  6. I feel like custom edit notices has potential for abuse, but mostly neutral.
  7. If you want a gadget here, feel free to port it using your custom JavaScript then propose the ported script. I personally would not use any of them so I don't see myself porting any of them.
  8. The translate extension is terribly complicated to use and makes the markup terrible. I think it discourages edits from all users over encouraging translations.
KnightMiner · (t) 16:22, 5 July 2018 (UTC)
Autoconfirmed users could only view abuse filters and the abuse log, not modify the filters. Wikipedia-logo.png psl85 (profile | talk | contribs | send email) 16:39, 5 July 2018 (UTC)
Just a thought - as you can see above I suggested that a new group called "Patrollers" be added, what if only this user group was allowed to view abuse filters and the abuse log (and not allow them to modify the filters)? Also, I may comment on the rest later - I just wanted to bring this up.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 16:42, 5 July 2018 (UTC)
To what end? There isn't really any reason for them to be able to view them. --Pcj (talk) 16:58, 5 July 2018 (UTC)
My opinions:
  1. No. Users would be able to circumvent the abuse filters then. There's no reason for non-admins to see them. Besides, most filters are globally managed by Gamepedia anyway and can't even be seen by admins.
  2. No. The font looks well ingame, but it is horrible for reading larger texts.
  3. Neutral. But it doesn't really make much sense to have 10 different skins. There's a winter skin currently, so maybe we could add one or two more, but it's not really necessary. In my opinion, special skins for special occasions (such as Halloween) would be a great idea. (We do this on the German wiki)
  4. Although I think the star doesn't really fit the skin, a book wouldn't be good to represent "watching". I think an ender pearl / an ender eye would be a good option too. But, really, it's just something visual that every editor should be able to decide for themselves.
  5. No. Why? Just more maintenance work for basically no gain at all.
  6. No. If you need them, add them to your personal JavaScript.
  7. NO. This extension is horrible. (And breaks stuff.)
| violine1101(Talk) 17:29, 5 July 2018 (UTC)
Here are my opinions:
  1. Not for autoconfirmed users. Possibly for a patroller user group.
  2. Agree with KnightMiner. Possibly make it a gadget for registered users to use, but I don't think it should be the default.
  3. I do think more skins would be nice. I don't think having every possible skin imaginable would really be practical, but I do think a dark skin would be really nice.
  4. Meh. I think people are used to the standard star, and I don't think it helps much making it a book or even an eye. Again, though, having it as a gadget not on by default might be nice.
  5. Don't really see the point and doesn't seem necessary. Anybody can request for an admin to edit an interface page, and editing the interface seems like one of the most hazardous right that admins have.
  6. Possibly, not really sure if it's worth it though.
  7. Neutral.
  8. I don't know much about it, but based on what I've heard, it doesn't seem popular! xD-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 15:56, 6 July 2018 (UTC)

New wiki skin proposal[edit]

I'd like to propose my poorly written stylesheet to be used as the official wiki skin. I have created two themes such as the normal and the winter theme. It's been a long journey since the last time it was changed. So I figured that now is the perfect time to move on from the minecraft forum style. Any kind of suggestions are welcomed. Link to the imageItsPlantseed|⟩ 07:37, 6 July 2018 (UTC)

Would you mind posting some screenshots so people don't have to modify their CSS to comment?
Also, what is the goal of the new skins? The only real difference I could see, apart from some font changes, was most of the background images are zoomed in more. I personally think the current wiki skin is pretty iconic and does not need to match Minecraft.net, since it is very recognizable as Minecraft. KnightMiner · (t) 14:45, 6 July 2018 (UTC)
I agree with KnightMiner. We don't need to match the style of minecraft.net. We never even tried to match it, the wiki always had its unique design. | violine1101(Talk) 14:58, 6 July 2018 (UTC)
Link to the image
The current theme is considerably "classic" from a certain perspective. I'm totally fine with the current design, there is nothing to blame about. However, this is not all about emulating the minecraft.net. This is just a minor change for what I called an improvement, that is aimed to make the web equalified with the metro style or whatever you may call it. There's always be a negative side of this and it might decrease the readability of an article. I understand if we don't really need a redesign, but there is always a room for improvement. – ItsPlantseed|⟩ 15:53, 6 July 2018 (UTC)
I think my biggest complaint is the inconsistency in the resolutions. The grass side is mostly the same scale as before, but the dirt is now four times the size and stone eight times, despite all connecting to each other directly. Also, I am not sure how I feel about the green links. It looks okay in the main text area, but clashes a bit with the edition boxes, plus I think most users these days are used to blue links so its not immediately obvious that green is a link. KnightMiner · (t) 16:04, 6 July 2018 (UTC)
The inconsistency of the resolution is mostly intentional, I thought that the nonuniformity will devote a different feeling to readers. As for the green links, I'm not too proud of that either. I just wanted to see how that will look for a long period. That's all I can say right now. I might do another round by changing the links and include others suggestion. Thanks for the feedback anyways. – ItsPlantseed|⟩ 16:39, 6 July 2018 (UTC)

 Support - I now have this skin on since almost 2 weeks an honestly feels very fitting. However, the background might have too much noise. - Hugman_76 [ User page Talk page Contributions ] 13:49, 13 July 2018 (UTC)
Thank you! This helps me to improve my design even more. I'm glad you like it. – ItsPlantseed|⟩ 02:38, 14 July 2018 (UTC)

 Oppose: the proposal and the author's comments are internally inconsistent; the proposal also fails to point out any specific objective issue with the current design, which makes the change unwarranted. --AttemptToCallNil (report bug, view backtrace) 16:25, 13 July 2018 (UTC)
You're not wrong. I didn't state the objections quite clearly. This requires public attention besides the community. Hence I can have the main issue more explicitly. – ItsPlantseed|⟩ 02:38, 14 July 2018 (UTC)

 Oppose as well, the current skin is fine and the new skin doesn't have any advantages over it. Also, it's obviously unfinished and would require quite a lot of work before it could be implemented. Besides, the design of the wiki is iconic by now. We don't need to imitate minecraft.net as closely as possible. I also don't think that the different resolutions of the graphics look good, I find it quite annoying. It doesn't improve the current design in my eyes. | violine1101(Talk) 16:51, 13 July 2018 (UTC)
Thanks for the feedback. I'll improve my current design as good as possible in the future (and make it appealing to your eyes). – ItsPlantseed|⟩ 02:38, 14 July 2018 (UTC)

Updating the Director page to show only the active directors.[edit]

Hi!

The directors' page is currently not updated at all and contain a lot of name of admins that are no longer active on their community, which is not really useful for the overall project and can actually make it more difficult to communicate with an admin from another language that will be able to answer to you, or whatever the director project do.

If you want, this page contain an update to this page where I removed inactive admins — if I made any mistake, point them out. We can simply use that page to replace the content of the real one.

For thos who feel it's important to know everyone on a Wiki who have the admins' rights, I just want to point out that a direct link to that list is placed on the template for every language to know this information. But I don't see any case where it could be useful.

Thanks! JSBM (talk) 03:51, 7 July 2018 (UTC)

I personally think it is still worth showing inactive administrators, but I am fine with distinguishing them. Maybe add an inactive background color or an inactive administrator header/section? KnightMiner · (t) 05:00, 7 July 2018 (UTC)
That's a good suggestion, that could be a good compromise.
If I may ask, however, what interest so you find to show inactive ones?
JSBM (talk) 05:46, 7 July 2018 (UTC)
The Directors page is supposed to be an overview of everyone who has any special rights on the Minecraft wikis. Changing the page to not show inactive admins would not only mean way more work for us to keep the page updated, but would also mean that it wouldn't actually list all directors. Then, there's the question, when is an admin inactive? After a month? After a year? After ten years? We would need to draw a line. It's the job of the respective wikis to demote inactive admins, not ours. To sum it up, I don't see much benefit in only listing active admins, all it does is creating more work for us.
And also, I think that if only active admins should be shown, we should somehow mark them as inactive instead of removing them from the list altogether. | violine1101(Talk) 09:09, 7 July 2018 (UTC)
I'm definitely not a fan of removing inactive admins completely. However, I'm not opposed to distinguishing them somehow, whether that's giving them a different color or putting them in a whole different section. But yeah, we would need to decide what counts as "inactive." 3 months maybe?-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 13:12, 7 July 2018 (UTC)
I would suggest a longer period, as on a slow moving site maybe 3 months is enough for an admin. This is why I on Discord suggested displaying the last contribution date, which I understood would be hard to add sadly. I think maybe 1 year, would be better. Then you could update it quarterly, and not created as much extra work for the updating of this enhancement. With 3 months, you would need to update (bi-)/monthly. Holroy talkcontribs 19:21, 7 July 2018 (UTC)
Would it be possible to generate this page in Lua based upon the various lists linked in the title sections? Or make a script to update it monthly? If that could be done, it would be a lot less work, and we could possibly add the last contribution date to the list, so that viewers could decide for themselves which admins are active or not. Holroy talkcontribs 19:21, 7 July 2018 (UTC)
I think that the date of last contribution could be shown automatically with something along the lines of {{#explode:{{Special:Contributions/Jahunsbe|limit=1}}| (| 0}} However, #explode and other string functions don't seem to be able to parse templates passed as parameters. I am not sure how to fix that. Alternatively a lua function should be easily creatable. Jahunsbe (Talk) 01:52, 8 July 2018 (UTC)
It might be possible to make a template or module that can parse that, but it would only work for this wiki; there's no way to transclude pages from other wikis. I don't recall where the discussion of it is, but at least on this wiki there has been more effort to demote inactive admins recently. Rather than trying to create a policy for which users with directors permissions should be listed on the directors page, I think it would make more sense to focus on demoting inactive admins and updating the directors page to match actual permissions. -- Orthotopetalk 02:36, 8 July 2018 (UTC)
We are carrying out the inactive demotion process now (see Special:UserRights/IKJames, Special:UserRights/Kanegasi, and Special:UserRights/Hower64), but of course it does not apply to admins on other wikis. For reference, the original proposal can be found here.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 02:39, 8 July 2018 (UTC)

Block and unblock templates[edit]

Psl85 recently created {{Blocked}} and {{Unblock}}. If we are going to keep these templates, there are several things we have to do:

  • Make it clear to administrators to use {{Blocked}} after blocking a user.
  • Change the admin noticeboard message "If you believe you have been wrongfully blocked, please visit an admin's userpage and send them an email using the left sidebar" (which I personally disagree with, considering how most blocks are made to IPs) to mentioning the {{unblock}} template instead.
  • Actually create Category:Requests for unblock
  • Decide whether we need {{unblock on hold}}, {{unblock reviewed}}, and {{Unblocked}}.
    • If we don't decide to create these, we need to remove the part mentioning these from {{unblock}}

If we do these things, however, it will kind of make this an official guideline. Therefore, I do think it would be nice to get consensus from the community about this before making all of this official.

I personally weakly
 Support having {{blocked}}. I feel like this would be helpful for making it clear to editors why they were blocked and how long it is. For {{unblock}}, I'm a bit
 Neutral. I see the point of it, and it could be helpful, but is it really necessary? As for the others, I don't see the problem with admins just replying to the {{unblock}} template with whatever the result is - I don't see any reason why the template needs to be replaced or anything; it would just make it consistent with Wikipedia, which is not a good reason at all. And if we don't decide to create {{unblock}}, we definitely don't need them.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:32, 8 July 2018 (UTC)


 Weak support {{blocked}}, for registered users only (we can't have this template with finite blocks due to maintenance complexity, and we can't block IPs indefinitely).
removed on 15:41, 12 July 2018 (UTC)
 Oppose {{unblock}}: I would expect blocking administrators to watch the talk page of an indefinitely blocked user if some probability of an unblock exists (e. g. not a sockpuppet of an indefinitely blocked cross-wiki vandal). --AttemptToCallNil (report bug, view backtrace) 14:40, 8 July 2018 (UTC)
Could you clarify what you mean by "maintenance complexity?" It seems to work just fine in my sandbox when I set the first parameter to something non-infinite.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:44, 8 July 2018 (UTC)
I mean removing the template when the block expires. Unless you mean for the template to be the content of a message informing the user of a block instead of a state tag like the one for inactive users. --AttemptToCallNil (report bug, view backtrace) 14:53, 8 July 2018 (UTC)
Oh, I see what you mean now, but I actually was thinking for the template to be more like what you said about "content of a message informing the user of a block." Specifically, the block template stays on their until somebody removes it or archives it - informing the user of their block instead of a state tag.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:59, 8 July 2018 (UTC)
In that case, why is this even necessary? Blocked users get all this information whenever they try to perform a write action. --AttemptToCallNil (report bug, view backtrace) 15:27, 8 July 2018 (UTC)
Imo, although the blocked text does provide a bit of information, it seems better for users if they get a clear talk page message explaining everything from an actual user as soon as their blocked, rather than just one day they try to edit and for some strange reason they can't - and they just see something that says they've been blocked and gives them some information about it.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 15:33, 8 July 2018 (UTC)
Revoked my support for the template. I have reconsidered and
 Oppose it now. Messages to blocked users about blocks should include reasoning about why the block has been performed (which can't be made into a template), not duplicate information found in public logs and displayed whenever the blocked user tries to perform a write action. --AttemptToCallNil (report bug, view backtrace) 15:41, 12 July 2018 (UTC)

┌───────────────────────┘
If I'm understanding correctly, you're saying that the reason why the block was performed can't be made into a template? It's actually in the template already, just use {{Blocked|[Reason here]}}, see the template's documentation.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 15:45, 12 July 2018 (UTC)

I would say the reason is the key thing this template is useful for, and given that it has to be a parameter, pretty much the rest of the entire template is superfluous. If we do implement it, we should definitely make it more lightweight, similar to the user warning template we already have. --AttemptToCallNil (report bug, view backtrace) 16:13, 12 July 2018 (UTC)


 Oppose. On procedure: users should not be creating de facto policies that the rest of the wiki is expected to follow without any prior discussion. On principle: we don't need every complex bureaucratic process that Wikipedia has. On content: MediaWiki:blockedtext already contains more information than {{blocked}} does, and is displayed and removed automatically. If more information needs to be given to a user, admins can always leave a message on their talk page, though I think it's usually not needed. Most blocks are for deliberate vandalism, or are given to users who have been repeatedly warned about their behavior; in either case, being blocked should come as no surprise. -- Orthotopetalk 18:47, 8 July 2018 (UTC)
I would like to point out that I've seen several instances where users who were almost certainly acting in good faith were blocked for a while without any warnings. Fortunately, though, I haven't seen as much of this recently, and when I personally block users, I always try to warn first, especially when it's not blatant vandalism.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 18:58, 8 July 2018 (UTC)
@User:Madminecrafter12, User:Orthotope and User:AttemptToCallNil: I would think that we could still use the blocked template, and users could still request unblock using {{unblock}} instead of sending mail to the blocking administrator or another administrator. Current requests for unblock could administrators check periodly and review them, and I think to add a image to the top right corner on blocked user's pages to see if the user is blocked, instead of checking block log and so, and why do you not mention me by using @Psl85: or so, I would be notified about this event so I can easily respond here, Wikipedia-logo.png psl85 (profile | talk | contribs | send email) 06:31, 9 July 2018 (UTC)
I do think that we should modify the admin noticeboard text saying "If you believe you have been wrongfully blocked, please visit an admin's userpage and send them an email using the left sidebar." Most blocked users are IPs, and many registered users don't have email enabled. I think something like "If you believe you have been wrongfully blocked, please post your unblock reason on your talk page and notify the blocking admin using {{ping}}" or something similar, would be better.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 15:51, 11 July 2018 (UTC)

Delete Norwegian translation project[edit]

As a Norwegian I've looked into MCW:Projects/Norwegian_translation, and it's obsolete and outdated, and I believe that this project could be deleted all together.

I've looked through Category:Norwegian_translation, and checked each of them for the last edit date, and found that almost all of those pages were last edited in the period 2014-2016. Some of them have newer edit dates, but that is from two distinct reasons: 1) Fixing broken file links, and 2) Adding other translation links. In the few exceptions to being old edits, just very minor details has been changed since 2016.

To add to this, I would also argue that most Norwegians are proficient enough in English, that there really isn't a need for a Norwegian translation which is poorly translated and outdated. Therefore I suggest to close down this project, and cleanup/delete related pages. Holroy talkcontribs 20:29, 8 July 2018 (UTC)

Deletion templates to redirects[edit]

This has been brought up a few times on Discord, but I've never gotten around to drafting a proposal. The proposal is that when adding {{delete}} to redirects, that it always goes BELOW the redirect, UNLESS it is a blatant violation of Rules #1 or #2. As many of you know, this will make the redirect actually functional, so that any readers searching for it will automatically be redirected to the target page, but the redirect will still show up in Category:Pending deletion. Here are my reasons:

  1. For alternate capitalization redirects, when a deletion template is on them, readers will be taken to the page that's pending deletion when they search for the title. However, if they are actually deleted, the reader will automatically be taken to the alternate capitalization page that EXISTS.
  2. It's more confusing for newbie readers to come across a page with this giant red box and a link, than if they just searched for it. The second would be the case if the redirect were actually deleted, the first would be if it were just marked for deletion. Also, pages that are marked for deletion show up as search suggestions, so it's likely that readers would click on those.
  3. Some redirects in the deletion category are marked because of a mistake, a misunderstanding, etc. and really should not be deleted at all.
  4. As redirect links in categories appear italicized, this would be very helpful for marking what pages in the deletion category are redirects and which are not. I try to patrol and delete pages in the deletion category as often as possible, especially non-controversial ones (e.g. author's request), but it is difficult with all of the redirects clogging it up.

Curious what others think about this.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 16:54, 9 July 2018 (UTC)

Why would this be a question? I'd say that placing the redirection code somewhere other than at the very top should only be done when it is necessary to disrupt the redirect because the fact that A redirects to B is itself damaging (e. g. if someone redirected a page to Special:Logout). --AttemptToCallNil (report bug, view backtrace) 17:40, 9 July 2018 (UTC)
Are you suggesting a new template, aka {{redirectdelete}} or a new policy? If new template, would it be used? How to trigger it usage? If new policy, some of the same apply. In general, I do believe you've got some valid points, though. Holroy talkcontribs 20:00, 9 July 2018 (UTC)
Holroy - actually, I'm not suggesting a new template. All I'm saying is that when people add the normal {{delete}} to a redirect page, they should add it below the actual redirect instead of above, so that the redirect is functional.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 20:03, 9 July 2018 (UTC)
In other words, you're trying to educate the users to do {{delete}} below the redirect, which is sound advice, but hard to get out to the people. Holroy talkcontribs 21:25, 9 July 2018 (UTC)
If this gets mostly support, we can kindly tell users on their talk page to place {{delete}} below the actual redirect if they don't, and reference this discussion. We could also add it to the template's documentation.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 02:22, 10 July 2018 (UTC)

 Yeah. The way I see it, a pending deletion is just that: pending. It's a maintenance request. Having {{delete}} break a redirect is just as damaging as if {{delete}} also wiped the content of a normal page, like Stone. So yeah, that would be a good rule on the template documentation. – Sealbudsman talk | contribs 02:19, 10 July 2018 (UTC)

 Support all of the above. The template must go below the redirect. When the template is placed to break the mechanism of a redirect, it's like saying with arrogance that the request has to take effect immediately without waiting for input from the admin(s) that are notified by it. – Jack McKalling [ Talk Contrib ] 11:18, 10 July 2018 (UTC)
I
 Agree with this as well, no point breaking a redirect until we decide whether to keep it or not. This is especially true of template redirects as that makes anything transcluding it now transclude {{delete}} and file redirects as it breaks anything linking the file (though none of these should be marked if still in use anyways).
Its also worth mentioning that the deletion pending redirects show up in Special:RandomRootPage which is not beneficial to the readers. KnightMiner · (t) 15:03, 10 July 2018 (UTC)
Under the same principle of not breaking things, I'd like to add that when tagging pages for deletion, the page content should not be removed. The exception (similar to what AttemptToCallNil mentioned above) is if the presence of the page content is immediately harmful (personal information, abusive content, etc.). -- Orthotopetalk 01:32, 11 July 2018 (UTC)

 Agree. Actually, after thinking about this more, I think that redirects should only be broken or pages blanked if they contain private/sensitive information (e.g. an 8 year old's address), solely attack a living person, or consists only of a copyright violation, rather than just any violation of rule #2. More or less, only pages that would require revision deletion if they were added to an existing page should be blanked. It's helpful for admins to know what the content of a page was without having to dig into the history.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 16:01, 11 July 2018 (UTC)
I know this proposal seems to be accepted, but I do have two more reasons I've come across:
5. If it really is a bad redirect, than adding {{delete}} above it will actually make it show up in the search suggestions in circumstances where it wouldn't if put below.
6. Many times people will add a deletion template to a redirect with the summary "Might should be deleted, but may still be useful." In these cases of ambiguity, it doesn't make sense to completely break the redirect.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:05, 13 July 2018 (UTC)

Image animation don't work in Template:Mod/Block[edit]

While you can do some animation with images in infoboxes by using, for example |image=White Wool.png;Red Wool.png with the Template:Block, this feature doesn't works in Template:Mod/Block. Could someone check in what's wrong and probably fix it? I can't easily manipulate this sort of code as some of you do. Thanks! - Hugman_76 [ User page Talk page Contributions ] 13:14, 10 July 2018 (UTC)


 Done   HorseHead.png MarkusRost (talk) 13:17, 11 July 2018 (UTC)

Should completely untranslated pages in translation projects be deleted?[edit]

I've been marking some of these for deletion lately. It seems like many pages from translation projects (particularly Lithuanian and Vietnamese) have not seen a single attempt at any form of translation, despite existing for several years. Unlike redirects, these pages also clog up the search bar, and being taken to an outdated copy of an article from clicking one of these pages could end up being confusing to new users.

I see no benefit to keeping these pages - they clog up the search bar, are completely useless, are more than likely outdated in comparison to their current English counterparts which could be considerably harmful if someone were to try translating said outdated information, and by deleting them we're not losing anything important since they can be recreated with more up-to-date information. - MinecraftPhotos4U (talk) 20:41, 10 July 2018 (UTC)

In that specific case, it seems reasonnable to delete them, if and only if there is absolutely no translation made on it. JSBM (talk) 20:47, 10 July 2018 (UTC)
I
 Support deleting any translation pages under the following conditions: they were created over a year ago, and no translation, nor any attempt of translation, has been made to them, per the reasons provided.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 20:49, 10 July 2018 (UTC)

 Support deletion of translation subpages inactive for over a month if there was no translated content on the page. I put a month instead of a year because such pages should only be works in progress, any reasonable work in translation subpages is made in the language of the translation project, and a month of no translation edits is more than enough to say there's no work in progress on that page. --AttemptToCallNil (report bug, view backtrace) 15:32, 12 July 2018 (UTC)
I agree with that. Also
 Support. Having all these basically (old) duplicates of pages deleted, cleans up a lot. – Jack McKalling [ Talk Contrib ] 15:36, 12 July 2018 (UTC)
Makes sense. -Xbony2 (GRASP) (FTB Wiki Admin) (talk) 15:47, 12 July 2018 (UTC)
I'm currently deleting some of the more extreme cases - e.g., absolutely no translation at all, no links, and existed for over 1 year.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 18:22, 12 July 2018 (UTC)
Should whether a page is linked to or not really be that much of a factor worth considering in this situation? - MinecraftPhotos4U (talk) 19:45, 12 July 2018 (UTC)

I believe I've marked every untranslated Lithuanian page for deletion now, so that's that cleared up. Currently looking through other projects. - MinecraftPhotos4U (talk) 13:28, 14 July 2018 (UTC)

On minimally translated pages[edit]

There exist pages such as Data values/fin, where only the very first sentence has been translated. While this undoubtedly counts as "translation work", should these also be considered eligible for deletion, due to containing overwhelming amounts of outdated information (that page has existed since 2011), and not having any work done besides the first sentence? - MinecraftPhotos4U (talk) 16:22, 12 July 2018 (UTC)

I think such pages should be deleted on a case-by-case basis only. I agree with the provided reasoning, and I'd say this page scores rather high on my "delete" scale, but I find no way to formalize the criteria for deleting or keeping such cases. --AttemptToCallNil (report bug, view backtrace) 16:37, 12 July 2018 (UTC)
I agree with AttemptToCallNil, it should really depend on the page. In that specific case, a single sentence is not enough to show that the page was translated, and it could be deleted. JSBM (talk) 16:53, 12 July 2018 (UTC)

Archive this talk page[edit]

It's the 50th topic, it might need a clearup. - Hugman_76 [ User page Talk page Contributions ] 12:01, 12 July 2018 (UTC)


 Support, I thinked it also, this talk page is getting very very long and needs archiving. Wikipedia-logo.png psl85 (profile | talk | contribs | send email) 12:33, 12 July 2018 (UTC)
The thing is, a lot of these topics are actually quite active. I think at best we could archive the first 11 topics. Maybe we could create an archive for July May - August (I swear I had put May there, but apparently I had put July - anyways, I meant May) right now, and then slowly add inactive conversations to it. Usually MCW creates an archive all at once, but to me archiving topics one by one (or five by five, etc.) seems like our best option here.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 12:39, 12 July 2018 (UTC)
The first subject is last updated in May, so I'd start from there already. Besides, it's the next from the last archive. – Jack McKalling [ Talk Contrib ] 14:49, 12 July 2018 (UTC)
I archived a bunch of topics that are no longer actively discussed; there have been way more posts on this community portal than usual during the last few months, so there's still a lot of topics that still might need comments. If those topics don't get any more comments, they can be added to the archive as well. | violine1101(Talk) 10:49, 13 July 2018 (UTC)
I'm not sure if the proposal for classifying edits to other's user pages should have been archived. No action was made concerning that, and the discussion never really stopped, it just didn't seem to get much traffic.-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 14:48, 14 July 2018 (UTC)
Indeed. Requesting extraction from the archive to the page itself. --AttemptToCallNil (report bug, view backtrace) 15:01, 14 July 2018 (UTC)
Go ahead, I just archived the topics that did not get any replies for the longest time, since this page was getting really long. But even if you unarchive this topic, I doubt it will get much more replies. | violine1101(Talk) 15:08, 14 July 2018 (UTC)
In that case, maybe we should just go ahead and implement that proposal? --AttemptToCallNil (report bug, view backtrace) 15:25, 14 July 2018 (UTC)
Just to clarify, does maintenance edits mean fixing links and files as well?-- Madminecrafter12Orange Glazed Terracotta.pngTalk to meLight Blue Glazed Terracotta.png 15:26, 14 July 2018 (UTC)
Maintenance edit would imply fixing any issue not intended by the owner which causes the user page to be added to any automatically generated list. Including the list of wanted pages or the category of pages with broken file links. --AttemptToCallNil (report bug, view backtrace) 15:34, 14 July 2018 (UTC)
Promotional Content