Styleguide
About
Guidelines for editing pages on the wiki for consistent quality and style.
Articles
Edits
Every time you save your edit a commit is made. This commit will be reviewed by administrators. To make their lives easier try not to split your changes into dozens of separate commits but do them all in one go. Another thing that really helps is adding a summary (aka 'Comment') and make proper use of the minor edit option. Both will tell the administrator what to look for when checking the edit. Stating your intention as well, can prevent misunderstandings like: Rephrased foreword for increased readability.
New Pages
Avoid duplicates by thoroughly searching in the wiki and asking if need be. Try to following the existing naming schemes including capitalization. Here is an example, if you were to write a guide of how to walk properly:
- Bad: Walk
- A bit closer: How to Walk
- Almost there: Guide to walking
- Good: Guide to Walking
Jokes
Some pages are intended to be entertaining, but when writing guides, please remember that a new player might not realize that something is a joke or sarcasm and will instead take it at face value. For more practical guides, less jokes are better. Where it is more discretionary, please think about where jokes fit and where they don't, and if you are updating someone else's joke, think whether yours is actually funnier.
Terminology
Try to be consistent with any terminology and ask for clarification if need be:
- Use tick instead of cycle
Categories
You can put articles into categores by inserting the appropriate command like [[Category:Guides]]. This should be done at the bottom of the page. Please refrain from creating new categories or editing article-categories without talking about it with the wiki-staff first. This is necessary for categories to be consistent.
Article Quality
When revising and writing articles try to consider the following things:
| Correct Language | Check grammar / punctuation / typos. Basically make sure it feels like authentic english |
|---|---|
| Consistent Capitalisation | For recipes and lists of ingredients capitalize the first letter if it's a multiword statement (Lime juice), but if it's a proper name (Beepsky Smash / Quadruple Sec), capitalize both. For mixed ingredients only capitalize the actual item ("coil of Wire"). |
| Consistent language | Some articles are packed with humour, while others are rather technical. Both is perfectly fine. Try to stay compatible when editing articles. |
| Ressources | Check for broken / outdated images and links. Make sure the style of used icons is consistent. |
| Correctness | Making sure that anything stated is true and isn't outdated. Best checked by experienced players and reading the game-code. |
| Scope / Completeness | Anything described should either be complete, or it should be obvious that it isn't meant to be complete. The best example for the latter are things that are meant to be explored by the players. Best checked by experienced players, developers and reading the code. Remember, that guides are not meant to convert the reader into a ultrarobust powergaming machine by spoonfeeding optimized strategies. |
| Lore | While there is not fixed lore-concept, it does not hurt to provide slight lore-related hints once in a while. This can best be done for non-technical descriptions and whenever reasoning is given for things being how they are (besides 'science' / 'magic') |
| Design | Even the best article will feel boring without the proper use of icons and formatting. Proper Highlighting, templates and standard structures are to be used to increase readability without being excessive |
| Learning-Context | Make sure that basic guides stay basic. Guides should reveal their content by being read top to bottom without prior knowledge and link-jumping. They should still have structured sections that are good to look up for experienced players, too. |
Having someone proofread an article for a second opinion never hurt anyone.
Images
Most images can be found in the icons/ source code icons directory. .dmi files are png images with some extra metadata that BYOND uses to handle animations etc. You can easily change the extension and open them with your image editor of choice. When uploading images extracted from gamefiles it can be helpful to comment the source and the content like:
Extracted from icons/obj/storage.dmi Evidence bag
The content is especially useful if the image name is not intuitive.
Do not upload duplicate files. Update them instead. When uploading new versions of images it can take a while for them to get cached by the wiki. There is no need for repeated uploads. This can take quite a while.
Sprites
Where possible, sprites should be uploaded as a 32px by 32px PNG graphic (for static images) or a 32px by 32px GIF image for animated images. All images should be on an alpha (transparent) background where possible.
Map Images
Should consist of the area being covered and its immediate surrounding walls. Always include full tiles. A quality crop can be easily achieved by using a 32px by 32px grid and the marquee tool set to snap to said grid.
Refer to the images below for further guidance.
| Good | Bad |
|---|---|
|
|
Collaboration
Private pages / sandboxes
It is considered rude to change anything on another users private page without prior explicit permission. If you like someones draft you can copy and edit it in your sandbox.
To use your sandbox use Special:MyPage/Sandbox to be redirected to your own sandbox. You can create as many private sandboxes as you want. Just create an article in the appropriate namespace like: https://wiki.yogstation.net/wiki/User:YourUserName/YourSandboxName
Editing templates
Be very careful when editing templates, as breaking them will look really bad. It is easy to miss relevant use cases - use your sandbox to tinker with a copy and coordinate with the wiki-staff before applying bigger changes.
And as always, make sure to update the documentation.