Path of Exile Wiki:Manual of Style

This is draft, discuss it on the talk page

Article titles

Article titles should generally follow the rules of capitalisation for the English language. Titles should appear in sentence case when referring to concepts (common nouns), and in title case when referring to proper nouns. There are many instances where this differs from the capitalisation used in game, since the game's user interface capitalises certain words to emphasise them as game mechanics or concepts. For example, damage, resistance, area of effect and duration are usually capitalised in game. These are not capitalised on the wiki because they are concepts not proper nouns.

Sometimes there are edge cases that make it difficult to determine which capitalisation to use. Chilled ground is a game concept although it sounds as though it might be a proper noun. On the other hand, Corrupted Blood and Glimpse of Eternity are the names of specific debuffs, which makes them proper nouns. For such edge cases, use your best judgment and try to follow what other editors are doing.

When distinguishing between different item variants name them after their stats and not their appearance, for example Avian Twins Talisman (Fire Damage taken as Cold Damage).

Article layout

Order of article elements

The following are standardised article elements listed in the order that they should appear on the page. Articles are not required to have all of these elements.

1. Header
   1. Hatnotes
   2. Message boxes
   3. Infoboxes
2. Article content
   1. Lead section
   2. Table of contents
   3. Body sections
   4. Gallery
   5. Version history
3. Appendices
   1. See also
   2. Notes
   3. References
   4. External links
4. Footer
   1. Navboxes
   2. Categories
   3. Interwikis

Section headings

Do not use level 1 section headings like = Section title =. Your top-level section headings should be level 2; work downward from there.

== Top-level section ==
=== Subsection ===
==== Sub-subsection ====

Writing articles

Consistent style

When creating new pages, try to keep to the same style as other similar pages. This helps both readers and editors. Readers get accustomed to where they can find what they're looking for, and editors can quickly create pages by copy and pasting from other pages.

Things to try and keep similar are

• Headings
• Section order
• Referencing style
• Navigation boxes
• Categories

Article creation templates

There are templates available that make it easier to create certain types of articles.

• {{Create passive skill article}}

The following article creation templates do exist, although it is highly recommended to use PyPoE to create these types of articles instead.

• {{Preload area article}}
• {{Preload map article}}
• {{Preload skill gem article}}

Future proof your text

When writing explanations of mechanics or other things ask the question "Will this be correct next patch also?" with a slightly pessimistic mindset. Path of Exile is an ever changing game and therefore exact numbers changes all the time but the underlying mechanic often stays the same.

The solution is simply to avoid going too specific, for example:

• Instead of writing "+(2-4)% increased Damage" write "#% increased Damage".
• Link to the pages that deals with the specifics. Instead of "(2-4)% increased Damage" write "increases Damage".

If you insist on using exact numbers try to use any of our querying templates so the number stays updated even after patches.

Use British English

British English should be used throughout the wiki to remain consistent with the spelling variants used in Path of Exile. For example, use "defence" rather than "defense", "armour" rather than "armor", and "jewellery" rather than "jewelry". Where appropriate, create redirects from American English spellings to their British English spellings.

Version history

See also: Path of Exile Wiki:Upcoming content

The main text of the page should always reference the current game version. Therefore it becomes redundant to keep using phrases such "As of release 3.0.0, (...)" or "With the 3.1 changes (...)". Construct a version history table using {{Version history table header}} and {{Version history table row}}. Place the table in a section titled "Version history" near the bottom of the page to mention any noteworthy changes. The "Version history" section may include a summary of changes over time, in addition to the version history table.

"Character" vs "player"

• Use "character" when describing things that arise as a result of gameplay such as attributes, damage, etc.
  • Good: "Chaos Inoculation makes the character immune to chaos damage"
  • Bad: "Chaos Inoculation makes the player immune to chaos damage"
• Use "player" when describing things related to the interface of the game
  • Good: "The player can identify an item with a Scroll of Wisdom"
  • Bad: "The character can identify an item with a Scroll of Wisdom"

Sandbox

Use sandboxes for experimental wiki editing.

• For general page editing use User:YourUserName/sandbox. They can be created in your own userspace. Click on My User Page and create subpages from there.
• For template editing see Template:Sandbox.
• For module editing see Module:Sandbox.

Path of Exile specific editing

• {{il|Ritual Splinter}} is used for items links e.g. Ritual SplinterRitual SplinterStack Size: 100Combine 100 Splinters to create a Ritual Vessel.
• {{sl|Tentacle Whip}} is used for skill e.g. Tentacle Whip
• {{c|mod|+1 to radius}} is used for modifiers e.g. +1 to radius
• {{c|normal|normal}} is used for rarity normal e.g. normal
• {{c|magic|magic}} is used for rarity magic e.g. magic
• {{c|rare|rare}} is used for rarity rare e.g. rare
• {{c|unique|unique}} is used for rarity unique e.g. unique

Providing references

Often when you want to contribute something to a topic it is new knowledge you've recently learnt that the wiki was missing. We, the readers, would like to know as well where you got that information from to determine how reliable the statement is now. When citing sources it is common practice to include page address, author, page title, publisher, date and the date when you read the source.

Defining a reference

To avoid clutter, use list-defined references with {{reflist}} and use {{cite web}} when citing websites.

Below is an example with the preferred style and templates:

Dual StrikeDual StrikeCritical, Attack, Melee, Strike
Level: (1-20)
Cost: 5 Mana
Attack Speed: 70% of base
Attack Damage: (125-244)% of base
Effectiveness of Added Damage: (125-244)%Attacks with both weapons, dealing the damage of both in one strike. Dual wield only. Does not work with wands.100% more Critical Strike Chance against Enemies that are on Full Life
60% more Damage with Hits and Ailments against Enemies that are on Full Life

Additional Effects From 1-20% Quality:
+(1.5-30)% more Damage with Hits and Ailments against Enemies that are on Full LifePlace into an item socket of the right colour to gain this skill. Right click to remove from a socket. only deals damage once, equal to the sum of calculated damage from each weapon.

Dual strike only deals damage once, equal to the sum of calculated damage from each weapon.<ref name="DualStrike" />
(...)
==References==
{{reflist|refs=
<ref name = "DualStrike">{{cite web
| author = Mark_GGG
| date = Sep 10, 2012
| title = Dual Strike
| url = https://www.pathofexile.com/forum/view-thread/13701/filter-account-type/staff/page/2#p635984 
| publisher = Official Path of Exile Website
| accessdate = June 29, 2017
}}</ref>
}}

Quality of references

Before referencing, some thought about the quality of the references should be given. Primarily, a reference should be from a trustworthy and recent source.

Trustworthiness

• Optimal: Primary sources i.e. from the developers themselves always take the highest priority:
  • Posts from any known Grinding Gear Games employees on social media (such as reddit, official forums, etc).
  • Pages on the official website (excluding the forums).
  • Videos where one of the developers talks about the game.

• Good: Sources like information given to the press or other persons by the developers also get a high priority, however, if possible direct information should be preferred:
  • News articles from known websites sites that are based on information that was specifically given to the press (for example, from press-only events about upcoming releases.
  • Collaboration between the developers and third party sources, as long this can be verified (for example, collaboration between ZiggyD and Grinding Gear Games. Please note that this goes only for the productions in which content from the developers are involved and not content from the same source otherwise.

• Questionable: Sources from any regular user or a member of community. Please note that if the information is replicable by any other user there is no citation needed (such as information from the game itself or it's data). This kind of source should always have some kind of evidence included in the source and not just claims by a user:
  • Video showing in game content and explaining it; this serves as evidence and is generally acceptable.

Age

Age of a reference is an important factor for Path of Exile, since the game is reviving constant patches and something that may have been true in the past may get outdated soon. In particular, if there mentions of changes in a patch note and the information given in a source is outdated, the source should no longer be cited.

Please note that how much the age matters also depends on the topic in question; numerical information (such as explicit damage values) is highly subject to change, while mechanical information (how something works in general) tends to only change in major updates.

Determining the age of a reference:

• Optimally the version of the game should be visible in the publication, such as the league version on the top right corner of the screen.
• When from an official source (such as the developers), the date of the publication was made can be used
• When from an unofficial source, the date of when the information was released can serve as a base line, however please be aware that information may have been released from an old version of the game then what the date on the publication may indicate. Publications may also have been edited retroactively.

Avoid referencing

Avoid referencing information from sources that:

• can be verified with very little ease (for example, there doesn't need to be a citation on the name of an item, because everyone can just find this value in game easily)
• have been known to manipulate users or change their information to suit their own needs (such as market manipulation)
• have issues with their methodology of obtaining said information (for example, poor use of statistics, such as "I've killed 5 monsters and got 1 exalted orb, as such the drop rate of exalted orbs is 1/5")
• dismiss certain aspects of information

Writing Templates

General

• Always document templates on the respective /doc page (see Template documentation for details)
• Complicated templates should be implemented in lua
• Add categories to the /doc page
• Use English words for naming separated by a space
• Do not capitalize all words

Template Documentation

• Always document the template you are creating
• Create a list of arguments the template takes and a description of what they do (and if they are optional)
• Add appropriate categories to the template (NOT the /doc subpage, i.e. use <includeonly></includeonly> tags)
  • For lua based templates add Template:Lua at the top

Template Test Cases

• Please create the testcases page and add test cases for new templates! It makes things much easier to maintain.
• Please put the {{Testcases notice}} template at the top of the testcases page.
• The {{Test case}} template makes it easy to write test cases that run the same tests against both the main and the sandbox version of the template. See the documentation to find out how it works.

Writing Modules

General

• Use underscore_naming for variables and functions
• Use 4 spaces for indentation
• Add extension documentation to /doc if possible, however this is not required if the code is readable
• If implementing a template in lua
  • Add to the lua comments which template(s) are implemented by the function
  • Add to the /doc page which templates are implemented
  • Add to a link from the template's /doc page using Template:Lua

Module Documenation

• Add appropriate categories to the template (NOT the /doc subpage, i.e. use <includeonly></includeonly> tags)
  • For templates for inclusion in other templates add Template:ProgrammingModule

Coding Style

Define variables as local unless they are otherwise needed

As the title suggest try to define locally in the scope they are needed.

Compress boolean statements if possible

This may be require some basic familiarity with Boolean algebra.

• Examples

  -- Bad
  not (a == b)
  -- Good
  a ~= b
  
  -- Bad
  not (a ~= b)
  -- Good
  a == b
  
  -- Bad
  a and (a or b)
  -- Good
  a
  
  -- Bad
  a or (a and b)
  -- Good
  a
  

Strings connecting

There are 3 basic rules:

• If the string is very long to connect, use a table and table.concat. This is faster and more readable

  -- Don't
  local out = ''
  out = out .. 'a'
  out = out .. 'b'
  out = out .. 'c'
  out = out .. 'd'
  out = out .. 'e'
  out = out .. 'f'
  return out
  -- Do
  local out = {}
  out[#out+1] = 'a'
  out[#out+1] = 'b'
  out[#out+1] = 'c'
  out[#out+1] = 'd'
  out[#out+1] = 'e'
  out[#out+1] = 'f'
  return table.concat(out, '')
  

• If the string is short, but has multiple arguments, use string.format, while it may be a bit slower, it is much more readable

  -- Hard to read
  "#ask:[[Is event::" .. args.type .. "]] [[Has release date::<" .. args.release_date .. "]]"
  -- Better to read
  string.format("#ask:[[Is event::%s]] [[Has release date::<%s]]", args.type, args.release_date)
  

• Use .. for other simple cases

  -- This is ok
  myvar .. other_var .. whatever
  

Avoid code duplication

Please try to avoid any form of repeated (in particular 'spaghetti') code. Minor repeats where required are, but large portions of the code repeating itself should be avoided.

Consider the following techniques:

• Use library modules to reduce code duplication
• Use poe wiki library modules like Module:Util, Module:Game to reduce code duplication
• Move code that is used regularly into a function; if the code is used...:
  • ... only used in that module, add as local, non callable function to the module
  • ... used primarily in that module, but may be used in others, add it to the return table
  • ... is generally useful for a lot of various modules consider adding it to Module:Util (discuss on talk page first)
• For formatting strings based on conditions, consider moving the formatting itself outside of the conditions if it is the same
• For long if ... elseif ... elseif ... elseif ... end that execute similar code create a table and loop trough the table

Subpages

• Path of Exile Wiki:Manual of Style/item
• Path of Exile Wiki:Manual of Style/item/doc