⚠ NOTICE

The game has been released in Early Access on 26th of April, 2024.
Please keep in mind that any information provided on this Wiki may be incomplete or subject to change as the game progresses.

Manor Lords Official Wiki:Style guide

From Manor Lords Official Wiki
Revision as of 07:41, 5 May 2024 by JKM (talk | contribs) (Created page with "== Introduction == The purpose of this style guide is to set forth guidelines that can be consistently applied to present information, enhance readers' understanding of game concepts and terminology, and support authors in their writing endeavors. While not obligatory, it's recommended to check out [https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style Wikipedia Manual of Style] for thorough guidance and adhere to the style conventions outlined there, unless specifie...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Introduction

The purpose of this style guide is to set forth guidelines that can be consistently applied to present information, enhance readers' understanding of game concepts and terminology, and support authors in their writing endeavors.

While not obligatory, it's recommended to check out Wikipedia Manual of Style for thorough guidance and adhere to the style conventions outlined there, unless specified otherwise in this Guide.

Article titles

Article titles should generally follow English capitalization rules. Use sentence case for concepts and title case for proper nouns.

Couple of examples how to name pages:

Burgage plot instead of Burgage Plot
Forager hut instead of Forager Hut


There are some edge cases where it's tricky to decide on capitalization. When something is actually a game concept, use capitalization present in the game. When unsure, follow the lead of other editors and use your best judgment - after all, it's only capitalization, it always can be corrected later.

Article layout

Articles should follow a standardized layout. Not all pages need to include all of these elements.

Header

  1. Hatnotes
  2. Message boxes
  3. Info boxes

Content

  1. Lead section
  2. Table of contents
  3. Body sections
  4. Galleries
  5. Upcoming changes

Appendices

  1. See also
  2. Notes
  3. References
  4. External links

Footer

  1. Navboxes
  2. Categories

Headings

Avoid using level 1 section headings (single "=" sign). Start with level 2 headings (==) and work downward from there.

Writing articles

Maintain a consistent style with already existing pages, this applies not only to source code (EN), but also translations. Keep headings, section order, referencing style, navigation boxes, and categories similar to other pages.

Templates are available to simplify article creation, feel free to create new templates when you find it necessary or useful, although keep in mind they should be compatible with translation extension.

Avoid hardcoding styles

Avoid specifying unique styling for images, tables, etc., as it may lead to unforeseen appearance issues when CSS changes are implemented. Whenever possible, utilize MediaWiki markup for images using [[File:File_Name.png]] and for tables use {| table_code |} with minimal customization, make them simple and linear, to maximize the readability and understandability of them.

Similarly, refrain from manually inserting line breaks. If your article includes large image thumbnails, use a clearing div to indicate where whitespace should be added to prevent weird wrapping.

<div style="clear: both" aria-hidden="true" />

Future-proofing

Consider whether your explanations will remain accurate in future patches. Manor Lords is still a game in active development, it evolves, changes and expands, therefore aim for timeless explanations. Instead of specific numbers, use general terms and link to specific pages or external sources for details if possible. External sources can be for example: tweets from the Dev, specific messages on Discord - especially if something is experimental.

American English

Use American English throughout the wiki to align with the game's spelling variants. For example:

  1. defense (not defence)
  2. armor (not armour)
  3. neighbor (neighbour)
  4. color (not colour)

Version of the game/Upcoming changes

Articles should describe the current game version. Avoid comparing current and past versions in the main body of the page. You can mention that something will change in one of the upcoming patches, but clearly mark it's not currently in the game or use a special template for this.

Translation linking

Use MediaWiki magic words to make translations more accessible.

Utilize /{{PAGELANGUAGE}} in internal links. A proper link look like this: [[Forager hut/{{PAGELANGUAGE}}|Forager hut]]

  • Green: Page name (always English, in the source page as well as translations)
  • Red: User language "magic word", it will be replaced by language code of the current user.
  • Blue: Localized page name (always English in the source code, but should be in the respective language in translated version of that page)

When adding a translatable page to a category, use magic word {{translation:}} at the end of the category name. For example: [[Category:Buildings{{translation:}}]] . That will create separate categories for each language. Buildings/de, Buildings/fr etc.

Quotation marks

Use "straight" quotation marks for consistency and predictable text searching.

File naming

Use simple and descriptive names, without special characters or spaces. Use underscore "_" to separate words or start each word with uppercase letter. When necessary, add version number or other relevant numeration. For example: Burgage_plot, BurgagePlotLevel2.png etc

Sandbox

Use sandboxes for experimental editing, do not try/experiment on live content:

Providing references

Cite sources to ensure reliability. Use list-defined references, added manually to source code or using special template. It's customary to incorporate the URL, author, page title, publishing entity, publication date when referencing a source.

Quality of references

Prioritize primary sources (e.g., developers' posts/messages), then reliable secondary sources (historical references used by developer). Consider the age of references, especially for numerical information which could be often a subject to change. Avoid referencing unreliable sources or those with questionable methodology. Guesses or "wishes" of random community members, are not good references.