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)
 * I support too. Good train of thoughts, we need to stay focussed on intention before presentation. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 09:13, 4 August 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)
 * I've thought about that too, but it has a logic flaw. It's fine if you have full information for every edition (i.e. it's a yes/no proposition), but if it's yes/no/don't know, it ends up implying knowledge you don't have. For example, if the template generates "This statement applies to all but Java Edition", but it's unknown whether it applies to, say, Nintendo 3DS, then it asserts something definite about the 3DS whether or not you include it in the template. That general problem occurs any time you have 3-valued logic and try to define sets by exclusion. So unless you have complete information for every edition, you can't use such a template. And of course, we often don't have complete information, either as individual editors or collectively. You can warn people about the problem in the template documentation, but not everybody will read that, so we'll end up making false statements that can be quite hard to spot and correct. – Auldrick (talk &middot; contribs) 13:41, 7 July 2018 (UTC)
 * Well, in the given example of redstone circuitry based upon Quasi-connectivity, marking them with  is the correct option, as my knowledge is particular to Bedrock. For me it would be better to have the option to mark something as not correct for a version which I know, instead of asking a question to verify for other editions, or to mark as only in other editions (which is a much more likely to be a false statement).  Holroy talk◆contribs  19:10, 7 July 2018 (UTC)
 * But don't you that that something like Quasi-connectivity allows you to indirectly power pistons.[Not in Bedrock Edition] implies that QC does exist in Nintendo 3DS Edition, when in fact it doesn't? At least that's how I would read it, but perhaps others would agree with you. (I'm an old programmer, so I tend to think in terms of formal logic more than most people.) – Auldrick (talk &middot; contribs) 00:25, 8 July 2018 (UTC)
 * I'm a programmer too, and the precise statement of "Not in Bedrock" does have an implication of being present in others, but the current alternative is to use the negative, "Only in Java and Legacy", which has a larger connotation and implication. And what does then happen when you introduce New Nintendo 3DS" or "Education Edition" into the mix? This latter is not describing the given scenario, it describes the opposite on false premises. I might not know anything about those editions, but I didn't have the option to declare what I knew, namely that it doesn't work in Bedrock. Holroy talk◆contribs 08:04, 8 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)
 * I think such recommendations are definitely within the project's scope, though how prescriptive the resulting guidance should be will depend on how thoroughly we feel we've covered the issues. I'm currently working (slowly) on a draft document of examples and I'm finding a lot of specific use cases. Some are "just" stylistic choices, but I'd rather not dictate style just to achieve quality. I'd rather give editors options than rules. [Edit] More specifically addressing the question in the topic head, I think we will probably need to modify the existing templates and may need to create additional ones, though templates can't solve all the issues we want to look at. – Auldrick (talk &middot; contribs) 13:54, 7 July 2018 (UTC)
 * With template in the heading I was thinking of templates as in example templates, not as in . Albeit, some actual templates would of course need to be updated eventually. Maybe example frameworks, would be better wording?Holroy talk◆contribs  19:13, 7 July 2018 (UTC)
 * I think you're referring to the same thing I termed "use cases", similar problems that can be fixed with the same solution. I'm currently experimenting with a way to classify them according to grouping (how many/which edition(s)s it applies/doesn't apply to), structural context (whether it covers the page, a section, a table entry, etc.), and semantic context (whether the facts are standalone or presented as contrasting/conflicting statements). Each combination of these properties could potentially be a use case for which we'd want to look for a good way to write it. If editors prefer another term to "use case", I'd have no problem with adopting it. – Auldrick (talk &middot; contribs) 00:43, 8 July 2018 (UTC)

For reference, please also consider these older discussions
Hi there! I wanted to post my full support for this project! I really think the edition specific information deserve a lot of attention to fixing, because the information is spread literally everywhere and makes the wiki pages very difficult to read sometimes. For my feedback, regarding our previous discussions, I would like to suggest to not forget to summarize or otherwise account for, the important keypoints of this old discussion as well as this one. They discuss the same subject from different angles, and might provide some interesting partial solutions to the full problem if you hadn't already thought of these. I've already provided some of my ideas there as well. This project identifies a lot more aspects of the full problem however, so in time I may want to participate more, but I'm currently too occupied so I'll get back later. – Jack McKalling 09:02, 4 August 2018 (UTC)