Minecraft Wiki talk:Community portal/Archive 36 - minecraft.fandom.com

Jump to navigation Jump to search
Treść tej podstrony pochodzi z artykułu „Minecraft Wiki talk:Community portal/Archive 36” w domenie minecraft.fandom.com na licencji CC BY-NC-SA 3.0
This page is an archive of past discussions. Do not edit the contents of this page. 
If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Flavors of "renewability"

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
The original idea was  Rejected. With the change to the placement of the renewability question ( Agreed on), there is a discussion here, making this discussion irrelevant and ready for archivation

I see a lot of infoboxes listing a resource as "renewable", and simply having a single label for everything renewable gives a false impression about practicality.

It might be useful to readers to have some distinctions between flavors of renewability. Logs are easily renewable by planting the saplings dropped from trees when harvesting them. While it's difficult to get a trident, the only way to get one is from a drowned. But is anybody really going to go through the agony of going into the Nether to defeat a wither skeleton just to get some coal? Technically coal is renewable, but practically it isn't, so it's kind of misleading to give it the same label as an oak log in terms of renewability.

Seeing "Renewable: Yes" in an infobox, therefore, is not useful information to me as a player. I'd like to see some qualifiers, like "Renewability: Easy/Moderate/Hard", indicating the effort and risk required to obtain the resource by means other than mining, in Survival mode.

Examples:

  • Bee nest: Renewability is easy, requiring a small amount of low-risk effort (albeit by grinding) to plant oak or birch trees near flowers.
  • Cobblestone: Renewability is easy, requiring resources to obtain a bucket for water and lava.
  • Iron ingot: Renewability is moderately difficult given that one generally needs several ingots. One can build a basic iron farm in survival mode, but it's a low risk activity that takes effort and time.
  • String: Renewability has variable effort and risk. Risk can be high (going to the Nether to barter, or hunting spiders) or time consuming (relying on chance from fishing, bartering, cat gifts). In my experience, string is one resource I'd like to have early in the game but in some games I have found it extremely difficult to obtain.
  • Sand: I'd say moderate; it's technically renewable by trading, but considering the value of emeralds it's a poor exchange, especially if you need a lot of sand and there is no village available.
  • Mob heads: Renewability is hard. This is something that is renewable more by accident than intentionally. Not practical at all.
  • Clay: Hard, high risk. The only renewable way to get it is to gain Hero of the Village, and then you can get it only if the village has a mason who survived the raid.

I realize there's a lot of subjectivity here, but maybe we could come up with more objective criteria. One idea might be to plot items on a grid with axes representing effort and risk or cost. Amatulic (talk) 18:57, 25 March 2021 (UTC)

@Amatulic:, I have 1 problem, this is opinion based. Also, how do you even make a graph, a poll? At the very most, do something like {{biome}} where it shows only a few options, not something all out.Humiebeetalk contribs 19:08, 25 March 2021 (UTC)
 Oppose, simply too subjective to implement; it's not a game definition, so it is entirely opinion based.
People can judge for themselves by reading the obtaining sections. Dhranios (talk) (Join the wiki videos project!) 19:21, 25 March 2021 (UTC)
 Oppose making changes to the infobox field aside from possibly removing it. I agree that the current information isn't super useful (e.g. it's hardly practical to get renewable resources through the wandering trader), but classifying by cost or risk is subjective, and I can't think of many other classifications that would both be useful and clear enough to not warrant an explanation (which would be too much for an infobox field). I wouldn't be opposed to making a bigger deal on renewability in the obtaining sections, especially for items like concrete powder where it's not immediately obvious without reading the pages of its crafting ingredients. –Sonicwave talk 20:18, 25 March 2021 (UTC)
 Support moving the renewability out of the infobox and into obtaining. Dhranios (talk) (Join the wiki videos project!) 22:45, 25 March 2021 (UTC)
 Support moving the renewability out of the infobox and into obtaining. It does require more explanation than a simple yes/no. --MentalMouse42 (talk) 02:28, 26 March 2021 (UTC)
 Comment The general issue of difficulty in renewability is something that has come up before; the biggest factor in difficulty is actually gating. In general, an up-front investment can reduce the "cost" (time, effort) of most resources by at least one order of magnitude and sometimes more.
  • E.g., String is difficult to obtain in the early game, but once the player has iron armor and weapons, spiders are little threat... and once they can find and farm a spider spawner, it's trivial.
  • Likewise for iron -- early in the game it's just easier to mine for it, but once the player has enough resources to manhandle villagers and build an iron farm....
  • A similar pattern applies to tradeables in general -- initially subject to random chance, but once you invest the time and resources (cash-crop farms, a trading hall, cultivated trades), that gate is basically passed -- the emerald cost of something turns into "how many do you need?".
    • The wandering trader represents a slightly special case, in that you need to wait for a desired offer, and can only get a limited supply.
  • That said, there certainly are a few things where even farming leaves them pretty costly. Nether stars are the poster boy for those...
    • Even on smaller scales: E.g, I recently built a basic music disk farm, where I still need to wait for creepers to come by, lure them into the killing yard, then dodge arrows from my named skelly for a bit. Way better than fooling around in the open night, but not quite trivial.
    • Witch farms probably qualify in this category too, in that the scaling basically means that you really do need to "go big or go home".
  • And when the effort for something is totally out of proportion to the value (e.g., the clay example), it might technically be renewable, but not in practical terms.
--MentalMouse42 (talk) 02:28, 26 March 2021 (UTC)
Addendum: Knowledge also matters a lot: E.g., iron golem farms require a lot of technical knowledge (or exact adherence to a plan), witch farms a little less, and (pigman-based) gold farms a fair bit. --MentalMouse42 (talk) 02:52, 26 March 2021 (UTC)
...which is odd, because I can easily create an iron farm but I have never ever gotten a witch farm to work. For gold, I get all I need from drowned farming with a zombie spawner, which is probably less complicated than doing it in the Nether. Amatulic (talk) 00:34, 31 May 2021 (UTC)
 Support removing from infobox and adding to obtaining. Also, string is definatly easier to obtain than bee nests.Humiebeetalk contribs 18:57, 26 March 2021 (UTC)
 Support moving from the infobox to the obtaining section. Some items definitely need a more thorough explanation rather than a simple yes/no.--Capopanzo (talk) 00:08, 2 April 2021 (UTC)
 Support (as the person who started this discussion): removing the renewability parameter from the infobox in favor of explaining the renewability in the article text. There are too many flavors of renewability for a single infobox parameter. Amatulic (talk) 00:31, 31 May 2021 (UTC)
To add to all of this, pretty much everything renewable (with the exception of wandering trader exclusives) has a farm. String - has a farm. Bee nests? - has a farm. Villager goods? - make an emerald farm. Clay? - make a raid farm. Beacons? - Obsidian farms exist, nether star farms exist (which is quite OP) and glass can be obtained via trading (emerald farm). Dirt? - make an azalea tree farm or something. Renewablility changes as you progress through the game. Humiebeetalk contribs 13:49, 31 May 2021 (UTC)
 Neutral about the removal of the template part, but  Support adding a new "renewability" subsection. Renewability should be both in the infobox and obtaining section, because if someone wanted to check renewability for coal, they could go to the wiki page for it, see "Renewable: yes" and then go to the obtaining section to see how they can reobtain it again. Removing the infobox section could remove a useful identifier, because then if someone wanted to check if something was renewable and it wasn't, they could stop reading as soon as they see "Renewable: No" and not have to search through the obtaining section. Supeika (talk) 02:36, 3 July 2021 (UTC)
Gosh, and I thought this was pretty much settled that we would remove the non-informative parameter from the template. It's useless unless it can be made into something more than a binary indicator, and as has been pointed out, that is impractical because of the subjectivity and complexity. A section in the article is sufficient. Amatulic (talk) 04:40, 3 July 2021 (UTC)
Our infoboxes also can show their row descriptions when a Discord bot like Wiki-bot reads them. Removing the "Renewable" section from the infobox would make difficult to users who use Discord to see if the block is renewable or not without going to the page. It's worth to consider things like that because on our Discord server we use Wiki-bot a lot. Supeika (talk) 05:40, 3 July 2021 (UTC)
 Both removal of the template and infobox part, and adding the sub-section. The sub-section can be established to always start with the sentence "[the item] is/is not renewable", keeping finding the information easy and quick. Blue Banana whotookthisname (talk) 09:59, 15 July 2021 (UTC)
Remember that our infoboxes also can show their row descriptions when a Discord bot like Wiki-bot reads them, like Wiki-bot, so removing the "Renewable" section from the infobox wouldn't be the best idea. Also, infoboxes are supposed to give just a few wiew of things, not to be actual complete information sections, which makes the simple "Renewable: Yes" make sense. Supeika (talk) 13:19, 15 July 2021 (UTC)
It doesn't matter. The parameter is not mandatory, so if it's missing, it shouldn't mess up any bot that needs to read it. "Renewable: Yes" is meaningless and non-informative, as amply discussed above. It's best to remove it completely, and add a section about it. Amatulic (talk) 05:54, 26 July 2021 (UTC)

Add-on documentation is obsolete and needs to be deleted

I've been discussing what needs to be done to the Add-on page with MetalManiacMc, but the issues have become broader and I think more people need to be invited to the discussion.

The Add-on article was originally the official landing page for Mojang's documentation on Bedrock add-ons. It has links to a couple dozen articles on specific technical topics for creating add-ons. All of this documentation was authored by Mojang staff and used to be maintained by them (mostly by replacing the entire page content) every time a Bedrock release or Beta release came out.

A couple of years ago, Mojang moved their documentation to the Microsoft Documentation site and stopped updating our articles. Wiki editors have made attempts to keep some of it updated, but these are only cosmetic changes as far as I can see. The documentation is now years out of date and is no longer official.

So I think we need to delete all those technical articles and the links to them from the Add-on page. (I don't think it's practical to consider maintaining shadow documentation on the wiki, but I won't go into why unless somebody asks.) I'm asking for consensus because it's a lot of material we'd be deleting.

That leaves the question of what to do with the Add-on article itself. I think MetalManiacMc and I agree that it's still a topic that should be represented on the wiki, but henceforth it should just be an introduction to what add-ons are and what can be done with them, with links to the existing Resource Pack and Skin pack pages. (A Bedrock add-on is installable community-written module containing customizations implemented in the form of resource packs, behavior packs, and skin packs. It should be noted that the existing Resource Pack and Skin pack articles are not Bedrock-specific. We don't currently have a Behavior Pack article, and probably should add it.)

Thoughts? — Auldrick (talk · contribs) 18:10, 17 December 2021 (UTC)

I don't see the point of maintaining information that duplicates information that is curated elsewhere. Also if the information we have is obsolete, and a better source of information already exists, there is no point in keeping it, as it would simply mislead others. Amatulic (talk) 20:45, 17 December 2021 (UTC)
Yes as Amatulic said it's important to find a way to represent add-ons, but we can't provide a documentation, and even less keep it up to date. There are websites and wikis such as bedrock.dev that do, but they mostly sync their docs with Microsoft's and then add tutorials on their wiki. Our current information is useless and misleading we need to somehow find a middle ground between sufficient info and info we don't need to rewrite every week--MetalManiacMc at your service fellow human! (talk) 22:22, 17 December 2021 (UTC)

Minecraft Plus Classic Grass Block Texture

I was on Minecraft plus (the moving block one the bounces around the screen) & I saw a side texture for the classic grass block texture. I'm not sure whether it was the Alpha version or Beta version I only saw it briefly, I just know it was the old texture & was bright green. Unfortunately I could not get a screenshot of it but if I see it again I will make sure to take one. I have not seen this anywhere else or on the wiki. I don't know if this is where I should put this but I just wanted to let some people know about it. It was one of these textures (ignore the top, just the side): [1] [2] KCenderhead (talk) 22:39, 19 January 2022 (UTC) [Edit: Here is the image of the grass [3] KCenderhead (talk) 23:04, 21 January 2022 (UTC)

History

Moved from Admin noticeboard

Should history have Minecraft Education? I was looking at MCW:STYLE and I can't really find an answer to this. Humiebeetalk contribs 00:26, 6 March 2022 (UTC)

I would say yes. I imagine it isn't part of the history because most people assume Education Edition is part of Bedrock (you can flip a switch and you get Education Edition features). Amatulic (talk) 01:05, 6 March 2022 (UTC)
The issue is, pretty much every single block, item, entity, biome, feature, etc would need to be updated which would take days. Things like the Texture Update would also need to be accounted for. Is there a way for a bot to like copy any change from BE to EE? (1.18.0 -> 1.18.10, 1.17.0 to 1.17.30, etc) I might just copy-paste the history from bedrock, making changes if nessecary. Humiebeetalk contribs 01:13, 6 March 2022 (UTC)

Combat Tests

Proposal: Should we consider Combat Tests experimental snapshots? As of now, they're listed simply as snapshots, despite having everything in common with experimental snapshots: they're not found in the launcher, they need to be downloaded from minecraft.net, they're forks of existing versions, and are mostly not compatible with other releases.

Affected pages: Category:Java Edition Combat Tests snapshots.

Deadline: March 26, 2022. – Unsigned comment added by Spectrogram (talk • contribs) at 05:11, 14 March 2022 (UTC). Sign comments with ~~~~

 Oppose - they are explicitly not referred to as experimental snapshots. BDJP (t|c) 15:22, 14 March 2022 (UTC)
 Neutral They were never snapshots, but they are also not experimental snapshots. I would be  More happy with putting them to "Tests" category.
Additionally,  Strong Support for removing their reference from main page's "Development versions" section (they seem to be long dead) and removing the section in {{Java Edition versions}}. Instead, there should be a link to the general page at the top of the infobox.--TreeIsLife (talk) 15:26, 14 March 2022 (UTC)

Adding inventory slots templates to the articles for main releases

Back in December 2020 I already proposed it, but it didn't get many attention as it may get now, so, I will try to propose it once again.

I think that adding inventory slots templates to articles about main releases (ex. Java Edition 1.17) would be a great way to make it easier to see directly what was added in an update, and it would also make everything more accessible.

Here's what it would look like:

1.xx AdditionsSculk Sensor
It could have historical value, but when the release article is created, often the graphic assets aren't available right away.
For me, though, I personally don't find a sea of icons useful or informative. I'd rather just see a text list. Amatulic (talk) 16:20, 17 March 2022 (UTC)
 Strong Oppose As I said at least 3 times. It is just less, than it is in similar version guides. In InvSlots, you can document blocks and items, but you can't document mobs (so Additions is even a misleading title). On other hand, if you really want to have graphical assets there, you can just put images before the actual names of the blocks/items/mobs, as it was done in pre-1.0 version pages. --TreeIsLife (talk) 19:56, 18 March 2022 (UTC)

Potentially Moving Wiki Hosts

Hi, I know there have been a lot of frustrations with Fandom over time, so I was wondering what the position on moving hosts is. Terraria's official wiki just moved to wiki.gg (announcement by them here) in order to have better control over the wiki (design + less obtrusive advertising). Personally, I much preferred how the wiki was originally on Curse and I think that re-platforming might help move back in a better direction. 155.33.78.19 02:03, 21 March 2022 (UTC)

We have already discussed that, though not on the community portal. It's not if we didn't want to move, but instead more about what would be the consequences of it. Also, we have interwikis, and we should care about them too. Also, per the Minecraft Wiki:Community portal/Microsoft status update page, it's something we have to discuss even more. Supeika (talk) 02:58, 21 March 2022 (UTC)
So let's talk about it. TBH, it will be really risky to do so. We're not supported by Mojang nor Microsoft, so the actual migration may overturn that Mojang will create a new "official" wiki. That would just split the traffic between 3 wikis. After that, there may be problem with interwikis. Actually, just with one wiki - that may be the Spanish one. As of now, it already has a competition (a wiki, originating from Fandom, didn't merge). Also, Spanish community seems to have more open hands to do things. Otherwise, there are more positives then negatives, so I won't be against --TreeIsLife (talk) 20:57, 28 March 2022 (UTC)
Forking the wiki is not something that is best for anyone short- or long-term. But it might be able to be done so long as a) the content is copied to a new host (or self-host); b) the Fandom wiki is locked and permanently redirects to the new URL; and c) Mojang/Microsoft reenters the agreement to make the new one "official". It'd take a lot of cooperation between Fandom and Mj/Msft--Fandom to be willing to lose traffic and revenue and Microsoft willing to let its trademarks be used. Though the wiki's license allows for forking, the maintenance on Mojang's end to maintain a fork is something I'd dismiss as unlikely to happen. So that would leave the big concern regarding Fandom being willing to let us go.
But what we would gain from it is significant. We could have proper language support à la Wikidata. Be unconcerned of Fandom's changes affecting us. A UI that doesn't suck. Control over our MediaWiki instance. SWinxy (talk) 06:06, 13 April 2022 (UTC)
Neither of those things seems likely to happen.  Nixinova   T   C   06:17, 13 April 2022 (UTC)
 Mostly agree with Nixinova. The a) has to happen (otherwise the fork wouldn't be a fork). I never heard of Fandom deleting/archiving any wiki in other way than 2 wikis on platform merged or there were ToU violations. Fandom won't (in any way) support any external wiki (because that wiki is their competition). The c) may happen, but the agreenment won't make the new wiki official (since I hope you read the reason why Microsoft canceled that agreenment). I am sure that it could guarantee Minecraft Wiki support from Mojang (i.e. "the new wiki is our recommended wiki"). Also, your "WikiData" integration won't work since the Wikibase would require much more work being done, since it is complicated and slow as Semantic MediaWiki.--TreeIsLife (talk) 15:15, 16 April 2022 (UTC)

Is it fair use to use Minecraft related images from movies and shows?

There's a scene in Spider-Man: No Way Home that has a Spider-Man skin made out of Perler beads amongst some other Spider-Man related art. I don't know if it would infringe copyright to upload an image of it to put on the Skin page or something. I'm sure that as time goes on that there will be other Minecraft references in movies as well. -Yekulten (talk)

The concept of "fair use" probably doesn't come into play in this case. Nowadays it's pretty much guaranteed that any appearance of a brand or brand-identifiable thing in a movie scene has already been negotiated and paid for. Usually a brand pays for prominent exposure in a film, otherwise the film producers license the brief appearance. Amatulic (talk) 19:26, 2 April 2022 (UTC)
So it would be fine? I know it's super trivial, but that's my kind of thing. I don't like to leave things out. -Yekulten (talk) 22:28, 2 April 2022 (UTC)
Fine for what? I thought you were referring to a movie's use of Minecraft branding. I see now you meant you intend to include an image from a film into this wiki. If so, and the image is not required in the article because other means of conveying the information are available (like text), then no, it probably isn't fine. More information on fair use in relation to wikis can be found on Wikipedia at WP:FAIRUSE. Because the Minecraft Wiki uses the same software with the same licensing, I imagine the same policy would be applicable here as well. Amatulic (talk) 01:10, 3 April 2022 (UTC)
I support it being included as text, and it's completely fine actually, because we already have a section on the article called Minecraft#References in popular culture and its purpose is for exactly what you are saying. While I agree with Amatulic that the image for now isn't needed, I don't see the need to follow Wikipedia's rules and policies, or at least not as actual rules but just as simple guidelines, since we're a completely different community and we have our own policies which are specifically made for us and by us. Also, I'd be completely fine if we added images about the references in other media, as long as it's only one of them and has explicitly a minecraft-like character (not just textual mentions or references), but that's up to people to decide in another discussion post. Supeika (talk) 03:28, 3 April 2022 (UTC)
I agree we need not follow Wikipedia's policies. However, in this case, the policies concerning copyright are grounded in actual law, so we should take care when departing from them. Copyright law is complex, and the Wikipedia community has worked long and hard, with the help of experts, to arrive at a policy that protects the Wikimedia Foundation from running afoul of the laws. I would not want to put the Minecraft Wiki at legal risk just for the convenience of having an image that someone happens to like. Amatulic (talk) 05:50, 3 April 2022 (UTC)
I'd say that just putting some few images that are exclusively about Minecraft content being referenced using a Minecraft-shaped character (not just textual references/mentions, since that'd be difficult to manage and wouldn't fit us) would be a nice adittion. Also, Wikipedia is a large wiki which has thousands of users, and that's why I don't think we should follow them since we are a different wiki with a different focus and their policies are huge compare to what a small wiki needs (I know that there are many policies that would be pretty useful here, though, but usually the communities themselves develop their own policies), but as I said, that's for another discussion topic. Supeika (talk) 13:47, 4 April 2022 (UTC)
And while those points are valid, none of them are germaine to the fact that we still need to abide by copyright laws. Just because Wikipedia is huge and this wiki is comparitively small does not exempt us from the same regulations; they apply to everyone, all the time. The Wikipedia polices regarding fair use have been carefully crafted to ensure compliance with copyright law. Absent any corresponding polices on this wiki, we need to follow what Wikipedia does where legal issues are concerned. Amatulic (talk) 03:51, 24 April 2022 (UTC)
It's understandable, but I dislike comments like "we need to base this on Wikipedia policy because it was carefully constructed" because it causes a dependency from Wikipedia. What we should do should be saying "we need to do this this way because -this policy- allows or unallows us to do this" instead. Supeika (talk) 04:07, 24 April 2022 (UTC)

Names in other languages

There should be a Names in Other Languages section of pages that lists the names of the topic of the page in other languages similer to whats found on the Pokemon wiki and Mario wiki. --67.81.132.165 14:39, 21 May 2022 (UTC)

Unnecessary. At the top right of any article, there is a drop-down menu for that same article in other languages. Amatulic (talk) 16:49, 21 May 2022 (UTC)
Ok and? Not every language has a wiki. 67.81.132.165 19:19, 21 May 2022 (UTC)
And Minecraft isn't available in every language either. More to the point, it is unlikely that anyone knows translations of all topics in every language either, so any section added to an article would likely be as incomplete as the existing drop-down list. If you know what a topic is called in every language, feel free to add a section to that article topic yourself. Otherwise the drop-down list of available languages is sufficient. Amatulic (talk) 19:34, 21 May 2022 (UTC)
Actually wouldn’t we only use official translation from the languages that are in Minecraft? Everything else would be fan made information. 172.56.34.112 12:22, 23 May 2022 (UTC)
All Minecraft wikis are basically fan-made, regardless of the language. For example, many people in Croatia know German or Italian and they may play Minecraft in either of those languages because Croatian isn't available, and nothing prevents a Croatian wiki from being created if there is a demand for it. Most of the terms used in Minecraft have analogous terms in other languages. Amatulic (talk) 14:28, 23 May 2022 (UTC)
That’s not what we are looking for. A names in other language is not a list of wiki pages. It literally just a list of what something is called in other language. If Minecraft isn’t in a language then we wouldn’t list it because that’s not information from the game Minecraft (unless there is other official information in that language).
 Comment: The thing is, who would be maintaining it? A list of that type requires a lot of maintenance. Second, you'd need to consider that Java is translated by community members and translations may change at any time, and Bedrock is known to have pretty bad translations that the ocmmunity just ignore. I don't know if this would be appropiate, because it also wouldn't help the non-english Minecraft Wikis, instead making them lose readers because the info is in the english variant. This could have some benefits, but the cost is too high as of now, at least for me. Supeika (talk) 13:47, 25 May 2022 (UTC)
Who reads the non-english Minecraft Wikis for the sole reason of finding what something is called in a language.Knowing that Dirt is called Terre in French won't make people who speak French not read the French wiki. Also even if the community members don't like bedrock's info doesn't make it any less valid. 67.81.132.165 20:56, 27 May 2022 (UTC)

The future of Official Pages

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
 Agreed on moving pages outside of Official pages. Pages are now in MCW NS.--TreeIsLife (talk) 19:42, 3 June 2022 (UTC)

As you may know, until 2019, Mojang sometimes edited MCW's pages, including "Official pages", that were created by them. In 2019, they stopped editing/updating them. I barely see a edit on this wiki by someone working in Mojang. And after they stopped treat the wiki as an official one, it seems they're not interested at looking at those pages.

Right now, there are only 3 pages left, but that's not enough to keep it as some sort of officials, when 2 of them are defintely Mojang-forbidden.

So my suggestion is to move all of those pages to a more visible place with a template stating that page was maintained by Mojang, but they stopped it after 2019 and 2021 respectively.

BE flattening

Will be moved to "Bedrock Edition flattening". The JE variant will be moved out of 1.13 subpage to its own page with similar name to BE variant.

Official pages/Java Edition unintuitive ID list

TBA

Official pages/Parity issue list

Will be moved to "Parity issue list".

All of these subpages of Official pages will have a permanent redirect to their successor page.

With official pages, this should stay as it is, just it should be more about how wiki was once official and Mojang edited pages. --TreeIsLife (talk) 13:59, 22 May 2022 (UTC)

 Support per above --TreeIsLife (talk) 13:59, 22 May 2022 (UTC)
 Oppose moving them into the mainspace – I'd prefer moving them under "Community pages" since that's what they've been anyway: community compiled lists. –Sonicwave talk 19:18, 22 May 2022 (UTC)
 Comment: I think it would be better to move those to the Project:/Minecraft Wiki: namespace per Sonicwave's comment. Having those in the project namespace would help us to keep them visible, while keeping them separated from mainspace. Supeika (talk) 05:25, 23 May 2022 (UTC)
 Oppose moving them into article space. These are meta-information pages, only indirectly about playing the game. I  Support moving them into the Project namespace. Amatulic (talk) 14:32, 23 May 2022 (UTC)
 Oppose moving into article namespace. I support moving them behind the project namespace. BDJP (t|c) 14:34, 23 May 2022 (UTC)

Theme updates and version pages

Note: I know this topic was posted by my many times, but I think we should finally do something about it

"Theme Update" refers to big thematic updates, ex.: Nether Update, The Wild Update (WU), Village & Pillage (V&P),...

TBH, from my perspective, the way this wiki handles update pages for last updates sucks (a lot). The Theme update pages for C&C and WU are absolute jokes. The notable changes (that should contain notable changes) contains everything in that version. Come on... That's just duplication of content. We basically have the same content on 3 pages (+ guides). And the worst thing I saw was an inclusion of: <onlyinclude>, which really drove me crazy.

I think we should finally force people to use pages as they are supposed to, without creating duplicatives

So there are options that can the wiki choose from:

  1. The feel of theme update pages will look the same, as they were with V&P update and earlier
  2. The theme page will become a disambiguation - just linking to other pages
  3. The theme update will become the home for major (and minor) releases (ex. JE 1.19 and BE 1.19 will link to Wild Update page, the same with minor versions)
  4. The theme page will be completely recreated from scratch, focusing on other things (like reception, or a more turorial-like approach for things)
  5. Other options

So I think there's nothing else I can say except: "Vote". --TreeIsLife (talk) 20:27, 30 May 2022 (UTC)

 Support Option 4. I think the entire "notable changes" section was already in 2019 with Guides, that provides easy way to compare changes. The new aproach to the page is definetely requiees, but it shouldn't be a page we transclude stuff --TreeIsLife (talk) 20:27, 30 May 2022 (UTC)

Categorizing audio files

The current way audio files are categorized on this wiki is awful. Most of them are categorized directly into Category:Soundtrack without any subcategories, and that category is also used for articles about the Minecraft soundtrack. I could add more specific categories to each audio file, but that would take a long time, and I would lose track of which audio files still need subcategories, since there is no way to remove the default categorization from {{License Mojang}} unless the entire template is removed. See my proposed changes to the template on its talk page, have an admin implement them, and I could start organizing the audio files. Fadyblok240 (talk) 22:11, 30 May 2022 (UTC)

 Comment I haven't understood what you want to do right now. --TreeIsLife (talk) 20:51, 31 May 2022 (UTC)
Template talk:License Mojang is the talk page Fadyblok240 is referring to. That may help you understand. SLScool 21:16, 31 May 2022 (UTC)
I've added a nocat parameter to the template. If you want to split into even more specific sound file categories beyond sound and music (since you've created Category:Entity sounds) then it might be worth removing auto-categorization altogether. In fact it's probably worth considering removing the image auto-categorization as well, since the majority of the files on this wiki are Minecraft images and a category of 37,000+ images is very unlikely to be useful. –Sonicwave talk 06:09, 7 June 2022 (UTC)

I feel like this wiki needs to add tabs for each minecraft version

I've noticed that this wiki seems to just overwrite their pages with information relating to the most recent version of minecraft.

IMO, this is a bad idea. Someone looking for information on older versions of minecraft will struggle to find anything useful, and the action of overwriting already-existing content takes a lot of time and is likely to result in mistakes and missed information.

something like this

something like this

Instead, we should add some sort of tabs to the top of each wiki page. The tabs will state each major version of minecraft, and clicking them will direct you to <pagename>/<version> which will hold the relevant information.

This will allow us to serve information about older versions of minecraft, and it will also help clean up a lot of the messy pages that have the "This article needs to be updated" header by helping organize the data (which will help up recognize what information we are missing or is incompatible with the version we are writing about)

TLDR; add tabs and/or subpages to each wiki page so we can show information pertaining to each different version of minecraft. (for example "minewiki.pl/en:Potion/1.12")

QuestwalkerKO (talk) 22:22, 23 April 2022 (UTC)

That already exists in the infoboxes in articles on each version. See Bedrock Edition 1.18.10 for example. The infobox has a version navigation widget at the bottom.
I would be opposed to maintaining separate articles for every block and entity for each version. Amatulic (talk) 03:45, 24 April 2022 (UTC)
While there are definitely valid reasons for playing on older versions (e.g. mods), keeping old articles for everything in the game is unlikely to be feasible. You'd have to create hundreds of pages (or copies of pages for tabs) every time an update releases, and consider all of them every time you make potentially breaking changes to images or templates, unless you're okay with them falling into disrepair.
There usually isn't that many changes to any given item in an update to warrant a complete rewrite as opposed to just documenting them in the history section, and pages with more significant changes do tend to get subpages, such as Trading/Before Village & Pillage. I agree that the presentation of current release vs upcoming information tends to be a mess (which could trickle into outdated content being left upon the next release), but I think that can be improved by putting more care into how it's presented; e.g. splitting current and upcoming information in different sections instead of mixing them together and throwing {{upcoming}} tags everywhere. –Sonicwave talk 05:47, 24 April 2022 (UTC)
I  Strong oppose this as it would mean maintaining WAY more pages than before, and would be extremely confusing if we have to make the tabs for Java AND for Bedrock, since both evolved differently. The History section should be enough to get all information of a previous version. --MetalManiacMc at your service fellow human! (talk) 09:17, 24 April 2022 (UTC)
There's hundreds of releases of Minecraft, this would be way too tedious and wouldn't be worth it. If you really need info as of some version, look at when that version was out and use the Wayback Machine or the page history to view the page as of that time.  Nixinova   T   C   10:29, 7 May 2022 (UTC)

Edit requests

I created a template called {{edit protected}} over a year ago, originally intended to make it easier for editors to request edits to protected pages. Aside from an update on the template's color, there have been no other edits on the template, and an earlier topic about the template was archived long ago. I also have requested pages of MediaWiki pages at User:Fadyblok240/MediaWiki, which includes edit request prompts. Are edit requests a good idea? Fadyblok240 (talk) 15:03, 15 May 2022 (UTC)

I have mixed feelings about it.
On one hand, a newbie cannot be expected to know to use that template. If a user has the 'edit' button enabled but cannot edit the article, the automatic editnotice should inform users about using that tag on the talk page.
The only advantage to that tag is that it would add un-answered edit requests into a category page. But then, other users would need to remember to monitor that page to find open edit requests.
So the usefulness of this tag is limited. Most people just make a request on the talk page, without the tag, and it eventually gets answered. I see tags like this used a lot on Wikipedia, but of the many edit requests I have answered here on the Minecraft Wiki, I don't recall a single one that used the edit request tag. Amatulic (talk) 16:55, 15 May 2022 (UTC)
I also don't see much point. It adds another category that editors would have to monitor for it to be useful and complicates the process of talk page requests, which is foreign enough to non-editors unfamiliar with talk page syntax. We also have few protected articles where this would actually be useful. –Sonicwave talk 03:49, 16 May 2022 (UTC)
Most of the pages that I want edited aren't even articles. They are mostly MediaWiki pages. Talk pages of these pages are pretty much inactive but I shouldn't use this page to request edits to these pages because edit requests only concern 1 page each. Should I request my proposed changes here? Fadyblok240 (talk) 21:54, 17 May 2022 (UTC)
Retrieved from "https://minewiki.pl/Specjalna:Obcojęzyczne/minecraft.fandom.com,Minecraft_Wiki_talk:Community_portal/Archive_36"