Soyjak Wiki:Template Manual of Style

Template What are templates? Deleted templates Template Question 1 Template Question 2 Template Question 3 Template Manual of Style

This topic relates to this very wikiHere be edit wars, censorship and template spam.

This page provides a set of basic pointers on the creation of templates. New users should avoid making templates because they are highly likely to be coal. Templates are supposed to be used on multiple articles, therefore templates have a higher standard than articles.

Types of templates

See: Soyjak Wiki:Template

Usecase

This is the single most important aspect of a template. Why should your new template exist and be used? Does it justify the vertical space taken up on the article? Is there another template that already has the same purpose? You need to consider these questions before you even begin making your template, or it may be deleted. Check the template list and deleted template list to see if someone else already had your idea, which they probably did.

There are 3 main parts of a template's usecase that you'll need to consider.

• Scope: How many pages can it fit on without being out of place or barely related to the subject at hand? If a template's only relevant for a few pages, it's not really necessary for it to be standalone and not just a soybox variation. On the other hand, if something can be applied to a large number of pages, it'd be better off as a category or navbox footer.
  • As a rule of thumb, ask yourself if your template's usecase would have at least 10 distinct main namespace pages the template could fit on without looking like it's filler or shoehorned in.
  • If your template's usecase is meant to cover a broad topic as opposed to page specific information, consider making a navigation box footer instead of a header.
• Information density: Does the template tell viewers anything that requires the attention grabbing properties and screen real estate of a template? If not then you're better off just mentioning it in the article's intro paragraph or infobox.
• Relevance: Is the template actually necessary, or can another existing template do its job? Keep in mind that the vast majority of templates don't need opposite versions made; especially if the intended usecase is for a thing/adjective/quality (on whatever it can apply to in the first place) that's so common that the lack of/aversion of it would be more notable instead.

If your template idea doesn't have good answers to those 3 questions, just use Template:Soybox or a close enough existing template instead. Virtually all possible and necessary usecases are already covered by existing templates, or could be covered by taking existing templates and editing their parameters instead. Another category of bad usecases is stuff about the page itself - it's a lot easier and better for the wiki to fix a page's problems than it is to make a template to complain about said problems, to say nothing of how any problems common enough to warrant a template have already had a template made.

Gimmick templates

For specific usecases where a template would not exactly fit the Scope subpoint, you may create a gimmick one-time-use template under a subpage of the desired article, and later inserted using {{:{{PAGENAME}}/TEMPLATE}} along with the appropriate template.
These should only be placed on pages that deserve it, for example a splinter that has practically no mention outside of it's own page. See the "Pages using gimmick templates" category if you need an example.

While the Manual of Style is not super strict when it comes to these, it should still be followed. We highly recommend using the Soybox template as an easy base for creating a relatively standardised template.

Code

• Do not use inefficient code like spamming <big> multiple times instead of using font-size.
  • We recommend you don't use presentational markup at all; use CSS instead.
• Use {{Soybox}} or flexboxes instead of tables where possible.
  • If making a box template that uses flexboxes instead of {{Soybox}}, make it the same width as a soybox (either width: clamp(0, 28rem, 100%); or width: clamp(0, 28rem, 100%);).
• If possible, the template should be a single cell or div that does not use rowspan in order to minimize wasted vertical space brought about by cellpadding and cellspacing and improve readability.
• The template should have a margin of 5px auto if it is a header or footer. This is simply to match the margins of most other templates.
• All colors should be in hexcode. For transparent colors, use 8 digit hex notation instead.
• Add suitable categories such [[Category:Template]] to the template page itself via <noinclude>. Make sure not to leave a newline between the noinclude and the template code or it might stack up with another newline from a different template being transcluded once it is on an article and cause an irremovable space to appear between templates and article text.
• Use template parameters and parser functions in order to make the text of the template suitably customizable.
• Write documentation, don't be a SLF and expect others to figure out how your template works by reading the code.

Documentation Pages

Documentation is key to any well made template, they not only help others maintain your template, but also tells all the nuswa using the visual editor how to use the template, and makes editing this very wiki a pain when it isn't done.

• Add the {{Documentation}} template wrapped in a <noinclude>, typically at the bottom.
• Once added there's a dedicated button to [create] the documentation subpage.
• Here you will add the <templatedata> tag, in which you can write a JSON object that describes the template and it's parameters. The object is generally structured like this:

<templatedata>
{
  "description": "A relevant description of what type of template this is.",
  "params": {
    "1": {
      "label": "Name of the parameter",
      "description": "Does a thing, makes it keyed o algo",
      "type": "string",
      "suggestedvalues": [
        "keyed",
        "o algo"
      ],
      "required": false
    }
  }
}
</templatedata>

• Each parameter needs to have it's name be the same as it is in the template wikicode.
  • "label": Has to be set to a descriptive, user-friendly name, not just "1" like it is in the wikicode.
  • "description": Has to describe what the parameter does, and note any common pitfalls.
  • "type": Has to be set to the type of input it expects. "string" is the most common, other common types are "number", and "boolean" (true or false).
  • "required": Has to be either true or false depending on if the variable is required for the template to function properly.
  • "suggestedvalues": Optional, typically used when there are few valid inputs.
  • "example": Optional but highly encouraged, should be a valid example input to clear up any confusion in the description.

Templatestyles

is an incredibly powerful tool that can be used to effectively manage and reuse your CSS code and allows for certain features like @keyframe animations and @media queries to change the layout of a template for mobile and desktop. It has some notable pitfalls that you must avoid in order to have a properly functioning template:

• You must NEVER target html tags that aren't a child of a parent class, this will cause all of those tags to have their styling applied across the entire page.
• Unlike some modern CSS frameworks, MediaWiki templatestyles do not feature any kind of deduplication to avoid styling clashes from reused class names. Some care has to be taken in order to not disrupt other templates that use the same class names in the same article. To avoid this you can either scope all generic class names to be a child of the parent class in CSS or prefix your class names.

Bad	Good
.template-example { background-color: black; } .header { color: white; } This is bad as all templates on the page with using the class name of "header" will now be white.	.template-example { background-color: black; } .template-example .header { color: white; } This is good, now only the "header" class name that have the parent of "template-example" will be affected. .template-example { background-color: black; } .template-example__header { color: white; } Prefixing is also acceptable.
a { color: red; } This is bad as now all links on the entire page will be red.	.template-example a { color: red; } Now only the links in the template will be red.

Guide

• Create a page for your CSS styling, usually as a subpage of your template: i.e. Template:Example/styles.css
• When you've written your CSS you must change the content model from CSS to Sanitized CSS.
• Add to your template.
• Add the {{Template styles}} with a link to the styles.css page in your Documentation for easier editing.

Categories

If your template includes categories to be included into a page, you MUST allow the user to disable the categorization and make the template purely decorative using the following code snippet: {{#if:{{{nocat|}}}||[[Category:Category name]]}}

If you find any templates still using the old {{{cat|[[Category:Category name]]}}} system or that don't have it at all, you VVILL update it to the current system.

Visuals

• Templates MUST be functional and aesthetically pleasing on phone screens.
• The template should not have extremely saturated colors.
  • On hexadecimal color, consider adding to the other values to reduce saturation, or subtracting from your main (highest) color value.
• Do not use dark fonts on dark backgrounds or light fonts on light backgrounds.
  • Otherwise it'll be hard to read.
  • If your text is hard to read, increase the contrast between text and background colors on all three values, by at least 3 levels.

YOU WILL NOT DO THIS.
The colours look very displeasing. Note that this was an older version of the spoilers template. See the 2026 archive. If you ever do this, you VILL be oxxed and aped by him.

• The template should not be excessively tall or wide.
• The template should not be overly eye-catchy or flashy to the point that it looks headache-inducing or overstimulating to look at. Try to save eye-catching/flashy templates for information that really is urgent for viewers.
• You should not make an upgraded (aka. "worse") version of existing templates unless necessary, as it will "award" the thing it is talking about. For example, see: {{Superpedo}}
  • This also goes against the usecase guidelines listed earlier in this manual.
• Use suitable padding so that template contents do not encroach upon borders.
• The text contents of the template itself should be informative, funny, and creative.
  • "Don't <verb> any <noun> you see. <verb> every <noun> in this article's history to <action>" is an extremely unoriginal phrase.
• Images should be large enough for posters to be able to clearly see what they're supposed to be without needing to zoom in or check the template code. If this would require making the image large enough to increase the template's size to something larger than it needs to be, consider using a cropped version of the image or a different one altogether.
  • Transparent backgrounds on template images are preferred wherever possible.

HyperDoctos is an example of what a really bad template looks like. If you unironically make and/or use a template like this we VVILL do unspeakable things to you.

Remember that you can always help Gem up a template instead of waiting for someone to archive it, maybe do dis:

This is a very displeasing and low-quality template. You vvill gem it up.

This is an example of a perfectly fine template. It doesnt really need changing that much o algo.

Archival

When a template loses its relevance or its usecase is found to be poor, jannies should whenever possible archive the template instead of outright deleting it, so wiki history isn't lost and to lessen load on the already heavy deleted templates page by using the {{Archived template}} template. Up-to-date instructions on how to use it properly can be found here.