Minecraft Wiki talk:Projects/Refactoring edition specific information

Suggestion for a guiding principle
I propose that as we discuss how to organize and present edition specific information, we be guided by the following principle: "Strive to maintain a distinction between the structure and the form of edition-specific information. Structure refers to how the information fits into the article as a whole and how it relates to similar information for other editions. Form refers to how it's presented on the page."

This is adapted from the principle that the World Wide Web Consortium (W3C) used to separate the CSS language from HTML, and it enormously simplifies both the encoding of the information itself and the customization of its layout for different devices and reader preferences. Every modern web site, including this wiki, depends on this distinction to enable it to generate responsive pages that automatically reformat themselves for the device presenting them.

A special advantage for our purpose is that when information is appropriately marked, our registered readers can customize their Appearances preferences with custom CSS and JavaScript to change how edition-specific information is shown. For instance, they might choose to display their preferred edition's information in a box or a special color, or they might decide to hide information for editions they aren't using. It's simply a matter of changing their preferences at view time, provided our wikitext is properly tagged with structure information. We will still have to decide on a default layout, but at a future time we can design alternate layouts for readers to adopt if they like, or they can create their own, and there won't be any need to change our markup in articles to accomplish the reformatting.

For this project, what this principle means is that we need to identify the different kinds of structure for our edition-specific information, but we can postpone details about how it should appear on the page until later. We can think about its layout to help us visualize, but everybody can visualize it however they like; we don't need to agree on it until much later, possibly even after we've done all the markup changes. I think adhering to this principle will make this project—or any project, because it can apply to lots of them—a lot less likely to get bogged down in its early stages by trying to decide too much too soon. – Auldrick (talk &middot; contribs) 15:10, 9 June 2018 (UTC)


 * Essentially, don't worry about how it looks and behaves so much as how it's organized from an editorial standpoint? – Sealbudsman talk | contribs 02:04, 10 June 2018 (UTC)


 * Yes, I think you've got the idea. In the early stages, we need to identify categories of edition-specific information based on characteristics such as its size (data value, sentence, paragraph, section, ...) and how it groups by editions (each edition is unique/most are the same but one is different/several sets of editions each have their own facts). These are the same factors that we already look at when we're choosing the best way to arrange information on a page. The difference is that with this approach, we explicitly identify those characteristics and translate them into markup, so that the decision of how to lay them out can be made later, when the page is viewed. It takes a little getting used to, because it involves making explicit something that previously was mostly subconscious, but it doesn't take long to get the hang of it. In fact, if you code in HTML5 you've already been doing it. – Auldrick (talk &middot; contribs) 02:54, 10 June 2018 (UTC)


 * Let me give a familiar, concrete example that might make what I'm talking about clearer. Consider the msgbox template. The template does not mean "present this information in a centered box with a yellow background above the following paragraphs". What it means is "present this information in a way that sets it off from the article body, draws the eye, and identifies it as metadata". Most of us don't realize it, but any user can change their Appearance preferences to make a msgbox appear in a completely different way. All that matters is that it conforms to the intent expressed by the second meaning. What I'm advocating is that we think in terms like the second meaning, so we don't get stuck on details of formatting and so our readers can choose how edition-specific information is presented to them. – Auldrick (talk &middot; contribs) 03:19, 10 June 2018 (UTC)


 * This is a good principle. Support.  Hopefully we can abstract out principles from implentation. – Sealbudsman talk | contribs 20:54, 19 June 2018 (UTC)

Getting started
Our current task is to identify the shortcomings of our current methods, which rely mostly on the exclusive and only templates with additional involvement of upcoming and possibly other templates. It is expected that the final list will help us conceptualize the various ways that edition-specific facts need to blend and contrast with each other and with information common to all editions, which will suggest a set of ways we need to be able to organize them for different contexts. Editors are invited to add to the list of shortcomings on the project page and to discuss them here. – Auldrick (talk &middot; contribs) 20:37, 19 June 2018 (UTC)
 * In a few places, I've also argued for adding something like a  template in those cases were an editor know for sure it doesn't apply to a given version, but are unsure on others. An example is marking redstone circuitry based upon Quasi-connectivity which for certain doesn't work in Bedrock. Holroy talk◆contribs  09:44, 7 July 2018 (UTC)

Is presenting new templates to be part of this?
I'm wondering whether it's for this project not only to identify areas of concern, but also to build new templates/examples on how to present edition specific information. Like how we propose to change the history boxes, or presentation of Data Values. Holroy talk◆contribs 09:50, 7 July 2018 (UTC)