Resonite Wiki:Style guide

From Resonite Wiki
Revision as of 10:31, 7 December 2024 by Yosh (talk | contribs) (create initial draft)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The Resonite Wiki has to cover a large swaft of information about the game, and a key part of making this information as accessible as possible is consistency. As such, the purpose of this page is to establish a consistent style for use across the wiki.

General Style

  • Use American English
  • Link to other articles
    • Avoid using "Click here", "here" or "page" when linking, use natural linking such as:
  • Use headings to separate pages into sections, which helps readability.
    • Start headings at the second level (== My heading ==) as the title of the page is already the first heading
  • Make use of lists when appropriate
  • Use tables for data or small amounts of text
  • Write proper sentences and use Wiki Style
    • No over capitalization
    • Write for the reader. Don't use "I"; use "we" and "you" instead
    • Do not start a page with "Hello guys, today we're gonna see what is X"
      • This is textual documentation, not a YouTube video
    • Avoid sentences in article names. "ProtoFlux" is better than "What is ProtoFlux" as the page "ProtoFlux" would contain what it is in the introduction
    • Avoid having an "Introduction" heading, the first paragraphs of the page are the introduction
    • Avoid using "Note" or "Please note", instead use the note template
  • Break content into digestible paragraphs. Huge walls of text are impossible to read

When in doubt, visit Wikipedia and see how existing articles are written.

Formatting

Due to the ever changing nature of the wiki and its internationalization requirements, we'll need you to format things in a certain way.

You can find a quick guide to Wikitext formatting on the MediaWiki Formatting help page.

MediaWiki doesn't supports Markdown, please use Wikitext instead.

Here's the key points:

  • Use the correct semantic tags for their purpose
  • Avoid using ancient HTML tags:
    • Instead of <b>, use '''.
    • Instead of <i>, use ''.
    • Never use <div><p> for regular article text.
  • If you need a line break, add a literal line break.
  • Avoid starting a page with a heading which is a copy of the page name. The title of the page is the page name, not the first heading.
  • Be careful with your use of font modifiers such as bold and italics:
    • Do not use '' or ''' for emphasis.
    • If everything is bold, then nothing is bold. Avoid overuse of emphasis.
    • Refer to Wikipedia's Text Formatting guide for more information on bold and italics.
      • Here on the Resonite wiki, bold and italics are interchangeable for emphasis. This may change in the future.
    • Never use <u> for emphasis. This can be confused as a link within the web space.

Component Pages

Component pages should generally follow these guidelines:

  • Titles should not include the generic argument (e.g. `1) except as a means for disambiguation between two unrelated components, such as the case for Slider and Slider`1.
  • Content should adhere to the following structure:
{{Infobox Component
|Image=BagEditorComponent.png
|Name=Bag Editor
}}

<!-- General overview of the component -->
The '''ComponentName''' component...

== Fields ==
{{Table ComponentFields
|Field1|FieldType1|Field 1 Description.
|Field2|FieldType2|Field 2 Description.
}}

<!-- Add this section if applicable. Not all components have these. -->
== Sync Delegates ==
{{Table ComponentTriggers
|Delegate1()|[[Type:DelegateType|DelegateType]]|Delegate Description
}}

== Usage ==

General usage of the component and how it works.

== Examples ==

<!-- Change the widths and heights to snugly fit the examples. Should not be larger than 540px x 480px -->
<gallery widths=480px heights=320px>
File:Component_example_ComponentName.png|Overall purpose of the example
<!-- ...more examples as needed -->
</gallery>

<!--
This section is used for linking to related wiki pages or external links that can either help understand the component, work with the component, or do something similar to the component.
Do NOT remove the namespace of links here, as it allows for the destination type to be clear before visiting it.
-->
== See Also ==

* [[Component:RelatedComponent]]
* [[ProtoFlux:Related Node]]
* [https://learn.microsoft.com/en-us/dotnet/csharp/ Related Microsoft Documentation]

[[Category:Components]]
[[Category:Components:Path:To:Component:Directory]]

For good examples of this structure, see ValueGradientDriver, ValueMultiplexer, and PhotoMetadata.

ProtoFlux Node Pages

ProtoFlux node pages should generally follow these guidelines:

  • Titles should follow the in-game node editor names with a space between each capitalized word.
  • Titles should not include the generic indicator (e.g. `1) except as a means for disambiguation between two unrelated nodes.
  • For nodes with multiple versions selectable via a purple menu option in the node browser, there should only be one page with the name of the menu that covers all nodes inside the menu. An example of this is the Write page covering ValueWrite<C, T>, ValueWrite<T>, ObjectWrite<C, T>, and ObjectWrite<T>.
{{#Invoke:ProtoFlux|GenerateUI
|Name=Node Name
|Category=Base Category of the Node
|Inputs=
[
{"Name": "Input 1 Name", "Type": "InputType"},
]
|Outputs=
[
{"Name": "Output 1 Name", "Type":"OutputType"}
]
|}}

<!-- General overview of the node -->
The '''Node Name''' node...

== Inputs ==

=== Input 1 Name ([[Type:InputType|InputType]]) ===

Purpose of this input in the node.

== Outputs ==

=== Output 1 Name ([[Type:OutputType|OutputType]]) ===

What this output is and how it comes to be in the node.

== Examples ==

<gallery widths=480px heights=320px>
File:Protoflux_example_node_name.png|Overall purpose of the example
...
</gallery>

== See Also ==

* [[Component:RelatedComponent]]
* [[ProtoFlux:Related Node]]

[[Category:ProtoFlux:Path:To:Node:Directory]]

For good examples of this structure, see Field As Variable, Clamp 01, or Ray To Line Intersection. There will of course be exceptions to this, such as the Source node, but every standard node should follow this structure.