Styleguide: Difference between revisions

From Yogstation-13
Jump to navigation Jump to search
imported>Atlanta-Ned
(Style guides for the style gods. Still a WIP.)
 
(Added content from Guide to contributing to the wiki)
Line 1: Line 1:
A guide for editing pages on the wiki
== About ==
Guidelines for editing pages on the wiki for consistent quality and style.


= Articles =  
== 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: <code>Rephrased foreword for increased readability.</code>


== Guides ==
=== 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'''


= Images =  
=== Categories ===
You can put articles into categores by inserting the appropriate command like <code><nowiki>[[Category:Guides]]</nowiki></code>. 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.


Most images can be found in the [https://github.com/tgstation/-tg-station/tree/master/icons source code icons directory]. <code>.dmi</code> 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.
=== Article Quality ===
When revising and writing articles try to consider the following things:


Most <code>.dmi</code> files are composed of a grid of 32px by 32px squares.  
{| class="wikitable"
!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.


==Sprites==


== Images ==
Most images can be found in the '''icons/''' source code icons directory. <code>.dmi</code> 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:
<pre>Extracted from icons/obj/storage.dmi
Evidence bag</pre>
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.
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==
=== 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.
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.
Refer to the images below for further guidance.


[[File:Badcrop.png|frame|256px|This is a poorly cropped map image.]]
{| class="wikitable"
[[File:Goodcrop.png|frame|256px|This is a correctly cropped map image.]]
!Good
!Bad
|-
|[[File:Goodcrop.png]]
|[[File:Badcrop.png]]
|}
 
== 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.

Revision as of 11:15, 4 May 2020

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
Goodcrop.png Badcrop.png

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.