Style Guide: Difference between revisions
Appearance
m Updated categories to match standard Tag: 2017 source edit |
No edit summary Tag: 2017 source edit |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{ | {{#eveaccess:public}} | ||
'''F4L5E G0DS EVE-EMU wiki style guide''' | '''F4L5E G0DS EVE-EMU wiki style guide''' | ||
| Line 13: | Line 14: | ||
|- | |- | ||
| Primary standard | | Primary standard | ||
| F4L5E G0DS EVE-EMU Standard Guide | | [[F4L5E G0DS EVE-EMU Standard Guide]] | ||
|- | |- | ||
| Prepared date | | Prepared date | ||
Latest revision as of 17:13, 6 July 2026
F4L5E G0DS EVE-EMU wiki style guide
House style for clear, consistent, and maintainable EVE Online wiki pages.
| Field | Value |
|---|---|
| Wiki platform | MediaWiki / Wikimedia-style wikitext source editing |
| Primary standard | F4L5E G0DS EVE-EMU Standard Guide |
| Prepared date | 2026-07-05 |
This style guide defines the house style for F4L5E G0DS EVE-EMU wiki pages. It is based on practical technical writing: clear purpose, direct language, consistent terms, and verifiable instructions.
Core writing principles
- Write for the player who needs to act, not for the expert who already understands the subject.
- Prefer practical instructions over long theory.
- Use plain English and avoid unnecessary complexity.
- Separate game mechanics from corporation, alliance, or coalition policy.
- State assumptions, risks, prerequisites, and exceptions.
- Use examples that could actually occur in EVE Online.
- Keep pages maintainable by using consistent sections and categories.
Headings and page layout
| Rule | Standard |
|---|---|
| Page title | Use the actual page title or DISPLAYTITLE only when needed. |
| Lead | Use a short lead before the first heading. |
| Heading level | Do not use Level 1 headings inside the article body. Start sections with Level 2 headings. |
| Heading case | Use sentence-case headings. |
| Table of contents | Let MediaWiki generate the table of contents automatically. |
| Section order | Use quick start, requirements, procedure, mistakes, troubleshooting, references, and see also for most guides. |
Standard terminology
| Use | Avoid or correct |
|---|---|
| F4L5E G0DS | False Gods unless quoting a source that uses that spelling |
| Fenris Creations (FC) on first use, then FC | Undefined FC or alternate organization names |
| High Sec | highsec, high-sec, high security unless quoting a source |
| Low Sec | lowsec, low-sec, low security unless quoting a source |
| Null | nullsec or null-sec unless a page title or source requires it |
| WH / J Space | wormhole space, J-space, jspace mixed inconsistently |
| ISK | isk |
| EVE Online | Eve Online |
| EVE-EMU | eve emu, EVEEMU |
Abbreviations
Define abbreviations at first meaningful use unless the abbreviation is universally understood in the article context.
Fenris Creations (FC) operates the service. FC maintains the approved access list. Tech II (T2) invention requires datacores and blueprint copies.
- Do not use an abbreviation in a page title unless the abbreviation is the normal search term.
- Do not capitalize a full term only because its abbreviation is capitalized.
- Use one abbreviation consistently throughout the page.
Links
- Use internal links on the first meaningful occurrence of a topic.
- Do not link every repeated occurrence of the same term.
- Do not put links inside headings.
- Use external links only when they add value, support verification, or point to a required tool.
- Use descriptive link text rather than raw URLs in normal prose.
- When linking to a category page from prose, use a leading colon so the current page is not categorized by accident.
Good internal link: [[Blueprint copy|blueprint copies]] are used for invention. Good category link in prose: See [[:Category:Industry|Industry]] for related pages.
Lists, procedures, and decision tables
- Use numbered lists for ordered tasks.
- Use bullet lists for unordered options, requirements, or examples.
- Use decision tables when the reader must choose between options.
- Keep each step action-oriented. Start with a verb where possible.
- Add an expected result after complex steps.
| Situation | Use this option | Avoid this option | Reason |
|---|---|---|---|
| Reader must follow actions in order | Numbered procedure | Paragraph-only explanation | Order matters and missed steps create errors. |
| Reader must compare choices | Decision table | Long prose comparison | Tables reduce ambiguity. |
| Reader needs definitions | Term table | Inline definitions spread across page | Readers can scan terms quickly. |
Tables
- Use tables for structured comparisons, requirements, risks, troubleshooting, and calculations.
- Every table must have clear header cells.
- Avoid very wide tables on normal article pages.
- Do not use tables only for visual alignment when a list would be easier to maintain.
Calculations and formulas
Market, industry, hauling, reprocessing, and tax pages should show assumptions before results. Use simple formula blocks when the math matters.
Net profit = Gross revenue - Taxes - Broker fees - Material cost - Hauling cost - Replacement risk
- Define each input before using it in a formula.
- State the market, date, structure, tax, and system cost assumptions when relevant.
- Do not present spreadsheet outputs as universal truths without assumptions.
Tone and point of view
- Use neutral, instructional language.
- Avoid personal insults, recruitment pressure, and unsupported claims.
- Write policy pages as policy, not as opinion.
- Use warnings for concrete risks, not for dramatic emphasis.
- Do not bury major risk information in footnotes or side comments.
References and evidence
- Use references for mechanics, patch-related facts, formulas, and claims that may change.
- Prefer current in-game verification, official support pages, patch notes, reliable wiki pages, or maintained internal documents.
- Add under the References heading when using ref tags.
- Do not cite unverifiable Discord hearsay as a factual authority. If Discord is the source of a local policy decision, identify it as internal policy rather than game mechanics.
Style checklist
- Headings are sentence case.
- The page begins with a short lead.
- No Level 1 body headings are used.
- Internal links are useful and not repeated excessively.
- External links are necessary and named clearly.
- Terminology is consistent across High Sec, Low Sec, Null, and WH / J Space.
- FC is defined before being used as an abbreviation.
- Tables have headers and are not needlessly wide.
- Calculations state their assumptions.
- The article distinguishes mechanics, policy, opinion, and example values.
Sources consulted
The document adapts standards to the F4L5E G0DS EVE-EMU context rather than copying external guide text. Sources consulted for structure and practices:
| Source | Location |
|---|---|
| F4L5E G0DS EVE-EMU Standard Guide Template | Attached file: eve_emu_standard_guide_template.mediawiki |
| MediaWiki Help:Starting a new page | https://www.mediawiki.org/wiki/Help:Starting_a_new_page |
| MediaWiki Help:SourceEditor/User guide | https://www.mediawiki.org/wiki/Help:SourceEditor/User_guide/en |
| MediaWiki Help:Categories | https://www.mediawiki.org/wiki/Help:Categories |