Forum:On Template:Growth stages

From Old School RuneScape Wiki
Jump to navigation Jump to search
Forums: Redwood Grove > On Template:Growth stages

Every seed page on the wiki has a nice table showing each stage of that seed's growth, including diseased and dead variants. All the images are consistent and high-quality, thanks to the third-party renderer we now use to generate images of in-game items, objects, and NPCs directly from the cache. The formatting for these growth stage tables was fairly consistent across pretty much every seed page, so about a week ago Joeytje50 created Template:Growth stages, which allows for these tables to be created from just a handful of parameters. This had the immediate effect of significantly shrinking the size of many of these pages, like Watermelon seed which had more than 1,000 bytes of wikitable replaced by a 53 byte string.

Soon after this change, some other editors in the Discord voiced concerns about the flexibility and clarity of this new template, especially with how inconsistent the plant names and sizes tend to be. These concerns have been bounced back and forth within the Discord for a while, and it's getting a bit hard to follow, so I figured I'd make this forum post so we can at least have all the discussion in one place. The three main options that have been proposed are as follows:

Current Template - Created by Joeytje50, this replaces the entire table with a short template, and has optional parameters in place to handle odd naming or sizing concerns. More information can be found at Template:Growth stages/doc, and an example of this template's formatting can be seen below:

Explicit Template - Created by Riblet15, this template has a specific paramater for each image, with the images following standard wikitext formatting. Mockups for this template can be seen at User:Riblet15/Sandbox4, with an example below:

Comprehensive template - Alternative format created by Joeytje50, this template allows for much more customisation than the current format, while still omitting as much duplicate wikitext as possible. Crops that have different names in different growth stages or as their diseased form can get their default name overridden. Sizes can be set for each growth stage, not for individual images. Documentation for this template can be seen at User:Joeytje50/Module, with an example below:

Old Wikitables - For comparison, these seed growth stage tables were originally handled by large wikitables on each seed page. The formatting of these tables was fairly consistent across every seed, with a few oddball exceptions like the Hespori seed. An example of the wikitext for the old tables is as follows:

I'll leave any further pros and cons of these different formats to the discussion section, and I'm hoping we can figure out which approach is the best for the wiki! :)


Now stop sending textwalls about this in #wiki-osrs you goobs. BigDiesel2m (talk) 20:49, 25 March 2021 (UTC)

Support comprehensive template, or wikitables otherwise - I originally built the current syntax under the assumption that having a different plant name for the first growth stage and the diseased form would be enough to cover all farming plants in the game having the correct filename, but after finding Red rose seed which has a different name for its second stage too, it was clear that this syntax is not flexible enough to support all different types of plants. Just today, I found out that Strawberry seed is named "Strawberry" when it's fully grown, while being named "Strawberry plant" for all of its other stages. Yet another example of why I think we all can agree that the current syntax is not flexible enough.

However, I do like the very short syntax, so that's why I came up with the 'comprehensive template' format, which fills in almost everything automatically. But, it also allows customisation for every single growth stage name, diseased form, dead form, and allows each growth stage to have a custom image size. This works very well to reduce the very repetitive wikitext the wikitable syntax is, while maintaining the functionality we've used for all growth stage tables up to now.

With an addition to the module I made just today, it's also possible to handle different file sizes for individual images, although I would agree that if indeed every single image would need a different size, this would probably only increase bloat. But, with almost every single farming crop just needing a single image size per growth stage, it should keep almost every page's source code a lot cleaner (e.g. all watermelons of the same growth stage are the same size, so those would do just fine with a single size parameter).

I mainly like the simplicity of this syntax, while still keeping full flexibility in the other proposed syntax (as of today's module edits). While I expect nobody would write out either the wikitable or the explicit template format without using copy and paste a bunch of times, the comprehensive format can be as simple as {{Growth stages|stages=6|name=redberry bush}} to generate the most basic table (try it; this actually generates a fully functional redberry bush table, albeit without custom image sizes). Additional fine-tuning can then be done through the addition of size parameters for each of the relevant stages. One situation where I loved being able to just type out this simple syntax was in this edit where I didn't have to go to another existing page to copy and paste the huge wikitable, but instead was just able to type out the much simpler syntax.

The reason I support wikitables as an alternative, if the comprehensive template syntax does not get used, is because in my opinion the explicit syntax doesn't provide enough benefits to weigh up against the disadvantages. Those disadvantages being that the template syntax uses more characters than the wikitable syntax (meaning that it's even less friendly to people typing it out from scratch), and the template syntax also does not allow individual images to be edited using the visual editor. With syntax like that, which basically only adds the top and bottom of the table, and the "Growth stage" number, it is (in my opinion) basically the same from the Source editor's standpoint as just having the table. At least the table syntax would then have the benefit of supporting the visual editor's built-in table editor. Joeytje50 talk Santa hat.png 22:44, 25 March 2021 (UTC)

While I like the general idea that we shouldn't break the visual editor if possible, I don't think we should weigh that too heavily in this case. After it was brought up in the Discord last week that the old wikitable format was better for visual editing because it worked with the visual editor's image editing interface, I scraped the last 1,000 visual edits to see how much of an issue this could cause. In the last 1,000 visual edits, I found only 11 that seem to have used the visual editor to edit images. Of those 11, one of them was a test edit I made to make sure my script worked, and only three of them (14027208, 14029692, 14031059) were mainspace edits. I think it's a reasonable conclusion to say that changing these tables to templates is unlikely to have any effect on visual editors. BigDiesel2m (talk) 01:28, 29 March 2021 (UTC)

Support explicit template - The explicit template condenses the table syntax into a more visually structured format and keeps it immediately obvious how the inputs correspond to the output files and sizes. It reduces the overall vertical space without sacrificing clarity on the weird cases that pop up in growth stages.

My biggest concern with the comprehensive template is the level of indirection between the input and output. For any variation of the most basic pattern, the special case parameters require the editor to look into the template documentation. Just by reading the source, it's not at all clear that |name1=watermelon seed corresponds to File:Watermelon seed stage 1.png getting used on the page. For images sizes, fully supporting growth stage cases requires customizing the size on each stage, and sometimes 3 different values for the live/diseased/dead sizes on the same stage. The common wikitext pattern with |100px in the file string makes it obvious how this works when using the table or explicit syntax. In the comprehensive syntax, the reader has to look up the docs to see how this is possble using custom params like dead4size. It's less code to type on an article, but the code takes more conceptual overhead to understand since all the special cases use custom parameters.

For both manual and automated tasks, it's beneficial to be able to easily extract the actual filenames used on the article. When writing a bot task to determine the proportional filesizes for each image, I had to carefully follow the comprehensive module's implementation to parse the syntax myself. This ended up being pretty complicated, due to the number of special cases the module handles.

I think clarity on articles is better than complexity in the module. There's always a balance between being clear and being redundant, but I find that the number of weird cases in growth stages makes the comprehensive template too complex for the problem it's solving. I don't think the visedit concerns are super compelling, because you can still edit a clear file string for changing the name or size of an image. The template wraps the other table behavior, so you don't really need features like reordering or deleting columns. Riblet15 (talk) 02:54, 27 March 2021 (UTC)

To be honest, I completely agree that having to figure out all of the edge cases in the current template syntax is not trivial, so I can understand that writing your bot for the task you describe here was not as easy as it'd ideally be. However I do think that the current syntax is easy enough to understand from just a quick look at the docs, which clearly have all possible parameters and syntax shown in the box at the top, which removes the need to dig through the module. Joeytje50 talk Santa hat.png 23:59, 28 March 2021 (UTC)
The complexity of the module had to be mirrored by the complexity in my code; the docs are about the same length as the code (>1 page) so it didn't make a big difference which one I followed. I agree that the docs are thorough and clear, but they are also describing a whole lot of cases that I'd rather not need to understand in this way. I personally wouldn't classify this as a "quick look" because it's quite a bit to read. Riblet15 (talk) 07:40, 29 March 2021 (UTC)

Support explicit - Wikitables as a second choice, been thinking on it for a while and I rly don't like how complex the current and comprehensive are for no actual benefit. Manual typing speed is irrelevant, the size of the page source when it's something this small and simple is irrelevant, they're not intuitive templates and will need a fuck load of overrides for sizes and names anyways... just really no reason for me to support those over explicit which has the benefit of using existing intuitive syntax, is WAY less complex, and way more maintainable than them. Wikitables as a second choice just cause I don't really care about viseditor, which is the only benefit of wikitables that apparently exists. zTUG5mD.png Crow  20:12, 28 March 2021 (UTC)

Support table or explicit - I liked the very first iteration of Joey's template when it basically required no unique parameters, but it became clear over time that the inconsistent object names (and the desire to make the sizes proportional) resulted in a convoluted template that had a hard-to-follow implementation and non-obvious special-casing parameters. I don't think that direction is salvageable. In general I don't really see why we can't just use the existing tables – the only reason I'd like to see it templated is so we could have a nice semantic representation of the different objects, but I suspect that eventually that will be a job for some version of Infobox Scenery... ʞooɔ 00:14, 29 March 2021 (UTC)

Do you think these seed pages should have these tables at all? Or do you think these different growth stages and images should be on scenery pages for the Farming plants? Right now our coverage of Farming plants isn't very good, with most of the plant names redirecting either to the seed page or a related item page. Even for the plants that do have their own pages, there's a lot of inconsistency in how the different stages are handled WRT the infobox (see Pineapple plant, Apple tree, Oak (Farming) for some examples). I guess I'm curious how you think the best way to handle this situation would be in the long run, and whether or not that approach involves these tables we're spending all this time talking about. :P BigDiesel2m (talk) 01:28, 29 March 2021 (UTC)
In my opinion: they definitely should be on the crop pages. I have been begging for an OSWF task to create Farming scenery pages for a couple of weeks now. My plan was to remove the growth tables from the seed pages once there is a (near) complete coverage for the crops, but currently with the crop pages severely lacking I think it's good to at least have one consistent place to find the growth tables for now. The inconsistency between the three pages you have linked should be ironed out through such an OSWF task, or perhaps the cleanup afterwards. Ideally, in my opinion, Apple tree is the way the pages should look. Joeytje50 talk Santa hat.png 01:52, 29 March 2021 (UTC)
I think there's still value in semantic labeling with a growth stages template as well as the infobox, though maybe less so if we decide to have a separate infobox version for every stage. The infobox at Apple tree right now seems decently useful to the reader, but only has 5 of the images represented (each infobox version has multiple comma separated IDs). Having it templated lets you use WhatLinksHere and gives a more reliable way to extract out the images vs. a wikitable. Riblet15 (talk) 07:40, 29 March 2021 (UTC)

Support table or explicit - Whichever is more convenient for bot editing, pick that one. Not concerned about page source length here. -Towelcat (talk) 06:23, 7 April 2021 (UTC)

Closed - It appears that we will be going with the explicit option for this template/formatting. -Legaia 2 Pla · ʟ · 00:10, 19 April 2021 (UTC)