Talk: Only

Adding categories to text without this tag[]

I noticed that Sealbudsman has been adding the relevant category to some pages that use an inline approach to describe exclusive features rather than the tag. Would it be supported to add a {{{text}}} parameter to this template kinda like {{upcoming}} does to make this a bit more uniform, or alternatively just a flag or use template that makes it display simply "In the X Edition"? I've never been a fan of placing categories in the middle of a page's text myself so it would be nice to use the template for consistency. –KnightMiner ^t/_c 02:26, 10 July 2017 (UTC)

I was kind of thinking originally, because people kept preferring to use prose like "in the X edition", rather than the only tag: why not create another mode for this template that just makes it invisible yet still places the category. Or make a mode that simply read ^[exclusive] when putting it in front of prose. In the end I didn't think ^[exclusive] would be well received, and then I didn't see how using a bare category would be any different from an invisible template that places the category -- so that's what I ended up doing. (I probably should have actually talked about it)

So then what if there were just a flag that made it say 'exclusive' rather than what it says now -- is that sort of what you're getting at? – Sealbudsman ^talk/_contr 02:45, 10 July 2017 (UTC)

I was thinking some flag that makes it say "In the X edition" or even just "X Edition" as that's probably a bit easier to work into prose, or possible just wrapping the whole sentence in this. I guess the awkward part is when it comes down to it, its hard to use this template in prose without making it a bit more awkward to write if no tag is desired, but I also find categories directly in paragraphs to be awkward.

Maybe if the page option to hide version exclusive text goes through it will be wrapped in some template so we can better do something like this. –KnightMiner ^t/_c 03:00, 10 July 2017 (UTC)

Adding a complementary template of {{not}}[]

I would like to propose to add another template to help distinguish if you know for a fact something __not__ working in a given edition, whilst knowing that most likely it works in the other edition. A typical exampled would be redstone circuits using quasi-connectivity. These doesn't work in Bedrock, but they do work in other versions. Instead of marking this as {{only|Java|Legacy Console|Education Edition}} (and what about Nintendo or other possibly new editions, I would like to mark this using {{not|bedrock}}, with a result text like: ^{Not bedrock}

Such a template would also be easier to add for someone proficient in just one of the Minecraft version, instead of claiming it works in all other versions which is the current situation. I'm imagening this __not__ template (or whatever name we'd choose) would be a simple replica of this template, but I'm not wanting to add it as I'm a rather new editor on this Wiki. I do however know that I would use it to help discriminate not working redstone circuitry, and some other non-bedrock features here and there. Holroy (talk) 22:43, 6 June 2018 (UTC)

An undecided debate on a similar subject can be seen here. Holroy (talk) 22:45, 6 June 2018 (UTC)

I like it, I have had these exact struggles, and I had thought a template just like 'not' would fit in the ecosystem. Though I had thought of it as an 'except' template, as in 'except bedrock'.

As a side note, it would be good to go over the existing 'only' templates and check: for the ones that say 'only java and console', you can't distinguish between the intent 'only java and console' and the intent 'Java and console yes, bedrock we don't know'. Those would be good ones for you to sort out if you found yourself interested.

– Sealbudsman talk | contribs 02:10, 7 June 2018 (UTC)

Good point, Sealbudsman. And I agree we have a certain need for marking exclusive editions as not. But as an alternative to a different template, it could also possibly work if this existing template allowed such a notation with an invert of the parameters with an exclamation mark. Like, if you'd want to declare it doesn't apply to Bedrock, you'd write {{only|!bedrock}}. Such could then appear as ^{[not Bedrock Edition]}. This way editors don't have to confuse themselves on which template to use, and all annotations that need to be declared on a single statement can be specified by the single template as a side effect. However I do not know if this would make the template too complicated or difficult to maintain. – Jack McKalling [ ] 07:28, 7 June 2018 (UTC)

I definitely prefer the idea of enhancing {{only}} rather than creating another template — and not isn't a good name for somebody looking for the right template, so even if we do create a distinct template I'd prefer a better name (maybe "except"?).

But let me play devil's advocate for a moment. During the Renaming project we talked about how our tools for marking version and platform dependencies were inadequate. They aren't flexible enough to use for all scopes (page, section, paragraph, group of sentences, single sentence), all contexts (headings, inline text, table entries, captions, etc.), and all semantics (the more versions it applies to, the longer the resulting template expansion, and it can easily overwhelm the actual text it describes and become disruptive). We didn't have time to address those issues for the Renaming project, but it still needs to be done. The proposed template would help fix a tiny aspect of this problem, but if we keep fixing tiny aspects with templates we'll wind up with a tangled mass of inconsistent templates that nobody can figure out how to use effectively. So while I don't think one more template is necessarily a bad idea, I worry that if we keep this up we're digging straight down. Are we at a point where it might be time to look at the bigger problem again? – Auldrick (talk · contribs) 09:10, 7 June 2018 (UTC)

Thinking about how this/these templates could be reworked to fix the mentioned problems, I got some ideas.

Firstly I was also thinking of shortening the text between the brackets of the resulting expanded template, like shortening the edition names to JE, BE, EE, LCE etc. Like we already are doing in infoboxes to distinguish differing block/item/entity IDs. That would help when it is overwelming the actual text.

Secondly, if multiple tags like "only" and "exclusive" and possibly "except" used closely together in a paragraph would become an inconsistent, tangled mass, could we change it to block-level notes? Like leave the paragraph of text that applies to all editions, and then add a short message block below it explaining the edition-specific differences with a heading explaining the related edition configuration. For example, see the "caution" message block on this MediaWiki page, but with better/compact styling. This way we could document the differences between editions separated from the main text, without having to add dosens of tags between sentences. I would imagine this as a replacement to the current template, but using both could maybe work too if revised. – Jack McKalling [ ] 09:44, 7 June 2018 (UTC)

I was thinking along the same lines. The hard part is refactoring articles to move the version-dependent information out of the mainline descriptive prose without making it look and sound choppy, and without putting undue emphasis on the version info by making it take up more room than necessary. Perhaps a standardized sidebar would work? For background, you might like to read this talk page discussion and review Majr's suggested format. – Auldrick (talk · contribs) 13:33, 7 June 2018 (UTC)

Agreed that shortening the edition names is a good idea.

Agreed that block-level distinctions (see Boat#Behavior for example) is better for reading. It would still be important to cleanly add 'Category:XYZ Edition specific information' in the correct places; that's the other purpose 'only' serves: attempting to organize all the differences. I had gone through and added the categories manually to a lot of places (like Boat#behavior) where the tag was absent/inappropriate, for the sake of completion, but Majr (I believe it was) warned that sprinkling bare categories throughout the text is a bad solution. So a template-oriented block-level way of keeping it organized is still yet to be seen. – Sealbudsman talk | contribs 18:00, 7 June 2018 (UTC)

It wasn't my intention to derail discussion on the template addition/change by enlarging its scope here. I think we need to have such a discussion, but it should be elsewhere and needn't stop discussion of the "not" template. Meanwhile, while we're discussing the {{only}} template, it might also need to be updated for Education Edition and New Nintendo 3DS Edition, since those are sufficiently distinct from Bedrock. – Auldrick (talk · contribs) 13:54, 7 June 2018 (UTC)

Agreed; a 'not' template is a good improvement, and if it's revamped later for some reason, as part of an overhaul with deeper scope, then so be it.

Agreed on updating 'only' and 'not' for use with EE and 3ds. – Sealbudsman talk | contribs 18:00, 7 June 2018 (UTC)

Requested: implement a CSS class for the template so users can hide it?[]

Requested here. I'm not certain what should be done. --AttemptToCallNil (report bug, view backtrace) 10:48, 6 November 2018 (UTC)

It doesn't sound like a very good idea to me. There are cases where we have back-to-back contradictory statements, tagged for different editions. Without the template showing, the text would just contradict itself and there's be no way the reader could know which one applies to them. – Auldrick (talk · contribs) 11:14, 6 November 2018 (UTC)

Is it OK that I can add the CSS class in the template? I are worried that my edit might be reverted if I add the CSS class to the template without discussing here. -- Philip57sundfors TALK CONTRIBUTIONS 11:13, 6 December 2018 (UTC)

Wait for a consensus. FVbico (talk) 11:17, 6 December 2018 (UTC)

 Opposing for the reason Auldrick mentioned. FVbico (talk) 11:17, 6 December 2018 (UTC)

 Strong oppose. Your argument here is for personal preference and not helpful to the wiki at all, Philip57sundfors. What you're trying to do will be confusing for other editors, as they wouldn't know what the classname is used for. If you want to improve the look and feel or the purpose of the template, I suggest you join in on the edition specific information project, and help it address this specific template more in line with the bigger picture. – Jack McKalling [ ] 11:38, 6 December 2018 (UTC)

Deprecate pc, computer and pocket values for arguments[]

This should really be done, as they are alliases of java, java and bedrock anyway, and really shouldn’t be used anymore nowadays. FVbico (talk) 10:15, 25 February 2019 (UTC)

I agree, however "pocket" could still be used for content that only existed before it was renamed to Bedrock Edition? Don't know if that's useful to have. But if you add a categorizer to the template if pages use it with deprecated values, it'll be super easy to find those deprecated uses. – Jack McKalling [ ] 10:17, 25 February 2019 (UTC)

If they only existed in pocket edition, it’d be on Bedrock Edition removed features, making the {{only}} template quite redundant.

I’m aware of how it’s done, just wanted some opinions before I started doing that. FVbico (talk) 10:31, 25 February 2019 (UTC)

Ok, that was my only concern, so hereby my full support. – Jack McKalling [ ] 11:00, 25 February 2019 (UTC)

I have no objection, but if you do this please remember to update the template documentation as well. It's often neglected in cases like this. – Auldrick (talk · contribs) 16:10, 25 February 2019 (UTC)

It's been completed already, and removed as if never added, and the deprecated values were removed from the template. If you think it should be returned, even if just for the deprecation mechanic only, please tell me. – Jack McKalling [ ] 19:38, 25 February 2019 (UTC)

Removing a comma messed up the template[]

I wanted to removed the incorrect comma in front of " and", but that somehow messed up the template. I don't really understand how it works, it looks like very complex wiki magic. Can someone please remove the comma in a way that doesn't make "and" a link, removed a space for no reason and generally messes up the template? Fabian42 (talk) 22:20, 14 April 2019 (UTC)

Spaces at the start and end of the wiki language are trimmed, you either have to use another way to define a space, IE unicode, or make it a non-breaking space. FVbico (talk) 22:22, 14 April 2019 (UTC)

It worked! \o/ Fabian42 (talk) 22:24, 14 April 2019 (UTC)

The optional comma before "and" in a series, which is called the 'Oxford' or 'serial' comma, should not have been removed simply because you prefer that style. It is not an error, and is both recommended and disrecommended by style guides in every English-speaking country. – Auldrick (talk · contribs) 22:33, 14 April 2019 (UTC)

You use it optionally in lists with 3+ elements, you never use it in a list with 2 elements; this template can have both amounts, so not adding it is always correct. FVbico (talk) 22:37, 14 April 2019 (UTC)

When I rewrote the template years ago, I made it omit the comma in such cases. If it wasn't working that way, somebody broke it in a later update. Regardless, I wrote it that way because I prefer the serial comma. Removing it simply because that's your personal preference is arrogant and rude, since either style is correct. I'm sure if I went around inserting them everywhere, you'd feel as annoyed as I do and wouldn't hesitate to complain. Incidentally, the "short" version that was added since I worked on it was broken, as can be seen in the documentation examples, when somebody else apparently couldn't tolerate the serial comma. – Auldrick (talk · contribs) 23:00, 14 April 2019 (UTC)

You just completely ignored the fact that the serial comma is wrong in a list of 2 entries... FVbico (talk) 05:03, 15 April 2019 (UTC)

I don't know if by "just" you mean "just now" (referring to my previous comment) or "merely" (referring to the edits I did to the template, years ago), but I believe your statement is false under either interpretation. Besides that, you're distracting from the real issue, which is whether it's acceptable to make edits with the sole purpose of enforcing a personal preference that other editors disprefer. I don't make edits just to "fix" serial commas, and I don't think others should either. – Auldrick (talk · contribs) 11:37, 15 April 2019 (UTC)

And by saying it's personal preference again, you've again shown you didn't read/understand my point; the serial comma is not allowed with 2 entries listed, that's what the template did, it added the serial comma for every time; the comma is optional for 3+ entries, which, only for this situation, would be personal preference. What was done here today was fixing a grammatical error, the comma showed up in every instance, now it shows up in none; only removing it for the "2 entries" situation would require a much larger edit, and new sections in the template, this was just an actual grammatical fix. FVbico (talk) 12:04, 15 April 2019 (UTC)

I see now. I didn't understand your point because you've been defining the comma between 2 entries as a serial comma. It isn't. Wikipedia defines a serial comma as "a comma placed immediately before the coordinating conjunction...in a series of three or more terms" (emphasis added). By that definition, whether to use a serial comma is a simple preference and what you're talking about is just an error.

Re "would require a much larger edit": Compared to the edits that implemented 'short=1' and 'upcoming', it's trivial. And again you ignore the real issue. – Auldrick (talk · contribs) 17:41, 15 April 2019 (UTC)

There is no issue with the edit, as I said it before it was an edit for fixing a list of 2 entries. You can go ahead and re-add the oxford comma, but make sure it’s not there for a list of 2. FVbico (talk) 18:05, 15 April 2019 (UTC)