Manor Lords Official Wiki:Style guide

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.

A 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.

Stick to sentence case. Capitalize only the first word of a sentence and proper nouns. Keep everything else, like common nouns and other words, in lowercase. That means, treat building, resource, policy names etc. as common nouns. This ensures more uniform and readable writing.

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 Templates and MediaWiki magic words to make translations more accessible. To do that, please create internal links by adding a template in front of the link parameter tl

Example: (to show the difference between a normal link, and translation friendly link)

Normal (translatable) link : [[Forager hut|<translate>Forager hut</translate>]]

Translation friendly link: [[{{tl}}Forager hut|<translate>Forager hut</translate>]]

• Green: Translation template, it will prepend Special:MyLanguage/ before the link (red), if the language is different than English
• Red: Page name (this should stay always English)
• Blue: Localized page name (always English in the source code, by putting that part in <code><translate></code> tags, you will make that part translatable).

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:

• General page editing: User:YourSteamID/Sandbox
• Template editing: Template:Sandbox
• Module editing: Module:Sandbox

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.