Fire Emblem Heroes Wiki:Guidelines

From Fire Emblem Heroes Wiki
Jump to: navigation, search

This page was created in order to help editors by giving them an idea of how things should be formatted and a clearer image of what we're looking for in this Wiki. By following these guidelines, maintaining consistency throughout the site will be much easier for everyone and will, hopefully, decrease the number of questions asked -- as well as any confusion one may encounter. Note: These are merely guidelines and not hard inflexible rules, make sure to exercise proper judgment for special circumstances and in general. Sometimes guidelines are not fulfilled due to technical restrictions or because an exception has been made for a certain thing.

Manual of Style[edit source]

See the Manual of Style for various standards/conventions.

Future-proofing text[edit source]

When adding information on the wiki, make sure your text is "future-proof", that it is not likely to be outdated with time. This game is in active development and new content can always be released.

Green check.svgCorrect: "Robin: Fell Vessel is the first Colorless Breath unit to be added to the game."
Dark Red x.svgIncorrect: "Robin: Fell Vessel is the only Colorless Breath unit in the game."
  • A new Colorless Breath unit can always be added.
Dark Red x.svgIncorrect: "[Insert Hero here] has the highest total stats in the game, tied with [Insert Hero here]."
  • More Heroes with higher total stats can also be added, and if not, other Heroes with the same amount of total stats could be added as well. Having high stats, a certain generic skill, or a movement and weapon type combination is not an inherently unique trait to the Hero and eventually, there may be so many added that the comparison is pointless.

Rumors and unconfirmed information[edit source]

Do not make assumptions when adding content to the wiki (for example, assuming the BGM of a map since others in the group have the same one or filling in unknown skill data, editors have been wrong before).

Misinformation is worse than no information, if you cannot confirm a piece of information, it is better to leave it blank. Any likely conclusions you can come to are conclusions the reader can draw as well, so it is pointless to fill in assumed information and it is better to leave unknown fields blank until information can be confirmed. In addition, misinformation is much worse because of the potential for it to go unnoticed. It is easy to see if a field is not filled out, but much harder to recognize one has been filled out incorrectly.

Unofficial content[edit source]

The scope of this wiki is to cover pages about official content. Please keep unofficial content (fanfiction, etc.), off the wiki's main namespace.

Comments, Talk pages, and Discussion pages[edit source]

Sign all comments you make on Talk and Discussion pages by typing four tildes ( ~~~~ )!

  • Reason:
    • It's tedious going through the page history just to find out who wrote what.
    • It's easier to respond to someone if you know who said it.
    • Please also avoid deleting or editing anything previously signed, especially so if someone has replied. Instead, you can add a follow-up comment.
  • Example:
    • Sekuiya posts a comment on a discussion page and types ~~~~ at the end of his comment, producing the following:
    • --Sekuiyatalk 01:02, 20 February 2017 (EST)

Editing user pages[edit source]

Each user has a unique page under the User namespace where they can put anything, and the user is also allowed to use its subpages. For example, a user called "ABC" is allowed to create and edit these pages:

  • "User:ABC"
  • "User:ABC/sandbox"
  • "User:ABC/MyNewTemplate/test"

Additionally, each user is allowed to claim their own module page and subpages, using their full user name as the article title, including the "User:" prefix. These pages are considered to be user pages for the purpose of wiki administration. Pages that fail to comply will not be treated as user pages and are not granted the same protection rights as user pages, so they may be moved, edited, or deleted by other users like any other page.

For example, the user "ABC" is also allowed to create and edit these pages:

  • "Module:User:ABC"
  • "Module:User:ABC/MyNewModule/doc"

User templates can be transcluded by using the full article title, e.g. {{User:ABC/MyNewTemplate}}. User modules can be invoked in a similar way, e.g. {{#invoke:User:ABC/MyNewModule|function}}.

With minimal restrictions, users are free to put any content on their userpage at their discretion. However, user pages should not affect the "outside" workings of the the wiki in any way. This means that:

  • User pages should not add themselves to non-maintenance categories intended for mainspace content
  • User pages should not declare Cargo tables, or store rows into Cargo tables
  • User templates and modules should not be used for mainspace content

It is the users' responsibility to ensure that their user pages fulfill these conditions, by either modifying templates that store data or displaying data in a different way that does not affect the Cargo database. Editors reserve the rights to revert or remove content from user pages that fail to comply with the above rules.

Please do not edit User pages owned by other users, unless written consent is provided by the page owner.

Other users are not allowed to modify these pages unless ABC explicitly says so on the respective pages. Anonymous edits on User pages are disallowed and the page owners reserve full rights to revert any such edits.

As an exception, users who make infrastructural changes to the wiki (e.g. modifying file names, removing redirects) should inform affected users of the planned changes at least 3 days in advance, on the respective Discussion tabs of the affected pages, or User talk pages if multiple pages are to be modified together due to the change. The user is allowed to carry out the planned changes if no objections are received during that period.

This wiki does not expose a stable API; in general, categories, templates, modules, and Cargo tables intended for mainspace may be modified without considering their impact on the following pages:

Special subpages[edit source]

The following subpages are reserved for special uses on the wiki:

  • /doc: Template or module documentation. Documentation should link directly to other templates and modules, rather than their documentation pages. Template documentation pages should be enclosed within the header and footer templates {{doc/start}} and {{doc/end}}. The base templates themselves should manually transclude the documentation by using {{doc}} inside their <noinclude> sections; templates should do so even when the corresponding documentation article does not exist. Module documentation is embedded automatically and should not use any of the documentation templates.
  • /format: Used by the base template as the template parameter to a #cargo_query call with format=template, to provide customized query output using templates alone. To improve performance, these formatting templates should not themselves query the Cargo tables.
  • /NoCargo: Used to indicate that a template uses different template parameters to produce the same result as its base template, except that it does not query any Cargo tables. This is different from the no cargo template parameter, see Fire Emblem Heroes Wiki:Tutorials/Cargo#Preventing stores for details.
  • /sandbox: Scratchpad page used exclusively to test the behaviour of the base template or module. Note, however, that the sandbox for a module is still a Lua module, unless an administrator changes the content model of that sandbox page.
  • /test: Development version of the base template or module. Used when the template or module is not ready for deployment, or an alternate but functionally equivalent version of the base page needs to be kept at all times.
  • /testcases: Unit tests for modules, using Module:ScribuntoUnit. Automatically linked from the base module page.

Images[edit source]

Only upload high-quality images!

  • Try to use datamined images as much as possible as those come with the best quality we will ever find. Screenshots are allowed if no better alternative can be found.

Please upload images in lossless file formats, and avoid using lossy file formats.

  • Acceptable lossless file formats:
    • .svg (mainly used for simple images such as File:Green_check.svg, see this page for more information)
    • .png (the majority of assets will be in this format)
  • Avoid using these lossy formats:
    • .jpg (lossy, no support for transparency)
    • .gif (worse compression than .png, limited palette of colors, however this is the most supported for animations so you may want to use this for animated files)

If a lossless file is too big, try optimizing it first before resorting to uploading in a lossy format.

If you are uploading a file that is already in a lossy format, there is generally no need to convert it to a lossless format because the data has already been lost when it was initially saved in a lossy format, and converting it to a lossless format won't restore the lost data. However, you may still do so if you wish.

Audio files[edit source]

Please upload audio in lossless file formats, and avoid using lossy file formats.

  • Acceptable lossless file formats:
    • FLAC (for compressed audio, same quality but lower file size)
    • WAV (for uncompressed audio, very large file size)
      • If you are uploading a .wav file, encode it is 16 bit instead of 32 bit, for more compatibility with browsers (some browsers cannot play 32 bit), especially important since this wiki is for a mobile game and many readers may be on a mobile device.
  • Avoid using these lossy formats:
    • OGG Vorbis
    • MP3 (avoid using completely, if you need a file in a lossy format use .ogg vorbis instead)

This table contains sample formats for testing, they have all been encoded from the same audio source.

Format Audio Size (KB)
16 bit depth
24 bit depth
16 bit
32 bit
OGG Vorbis
Quality level: 5

If a lossless file is too big, try optimizing it first before resorting to uploading in a lossy format.

If you are uploading a file that is already in a lossy format, there is generally no need to convert it to a lossless format because the data has already been lost when it was initially saved in a lossy format, and converting it to a lossless format won't restore the lost data. However, you may still do so if you wish, for reasons such as consistency.

Templates[edit source]

Rather than typing or copy-and-pasting the same code over and over again, we have templates. Users typically get to do whatever they want in regards to making templates, but please ask yourself the following questions when making templates:

  • Do you understand it?!
    • Make sure you understand what your template does. Do not touch or reuse code you do not understand as it may have unintended consequences.

General guidelines for making templates:

  • Generally templates on the wiki should be created such that they are able to handle missing information. Make sure you are able to make a distinction between unknown information and empty,N/A,0 or other information of similar nature. The map pages are a good example of this. Enemies that do not have any Assist equipped are marked with a - to show that their assist is empty (alternatively, many templates show a blank). This is not the same as not knowing what assist they have, which is marked with a ? in that case, showing that the field is incomplete. If your template fails to distinguish these two cases and consider a blank to be an empty slot, then it is impossible to tell whether that enemy has no assist or if the wiki is just missing information. The wiki is always growing and new content is always released, your template should never assume all fields are filled in.
  • Use {{#if:{{{param|}}}|{{{param}}}|default text}} instead of {{{param|default text}}} in templates, as calling the template with {{template}} and {{template|param=}} will produce different results with the second method instead of the first.

Widgets[edit source]

Parameters[edit source]

Parameters for widgets must always be escaped properly, otherwise anyone can execute malicious JS on any wiki page by calling a widget.

The following modifiers have been tested to be unsafe and must be avoided:

  • No modifiers
  • escape:'quotes' everywhere, including inside a HTML attribute
  • escape:'html' inside a script tag
  • escape:'javascript' inside a script tag outside of a string
  • escape:'javascript' outside a script tag if </script> appears anywhere afterwards in the page.

The following have not been found to be unsafe:

  • Using validate
  • Using regex_replace if the character set for the data is very small to remove all characters not in that set.
  • Using escape:'javascript' inside a script inside a string
  • Putting the data in a data attribute with escape:'html'

Wiki page structure[edit source]

Documentation for widgets will be hosted on the Project namespace instead of on the widget page or its subpages. This is because the widget namespace is locked to editing by only sysops and widget editors for security reasons, but the documentation needs no such restriction, so it is hosted on the project namespace to allow anyone to edit.

A widget may have a mirror page, which hosts a copy of the source code of the widget on a different namespace, so that others may edit and improve the widget. Anyone can create or edit the mirror page. A sysop will incorporate the changes into the widget after verification.

Given the widget located at Widget:WidgetName for example:

  • The documentation will be at Project:Widget:WidgetName/doc.
  • The mirror will be at Project:Widget:WidgetName.

JavaScript libraries[edit source]

JavaScript libraries that can be used by multiple widgets are hosted on the subpages of MediaWiki:JavaScript libraries. This is also enforced by the software itself; mw.loader.load cannot be used to load JavaScript from a namespace that is not MediaWiki or User.

JavaScript[edit source]

ECMAScript edition 5.1 should be the highest compliance level. This was chosen because the oldest version of Android that Fire Emblem Heroes supports is 4.2.

Put code inside a immediately invoked function expression to avoid polluting the global scope.

The fehwiki variable is reserved as an object for widgets where it is necessary for data to persist among multiple widget invocations. It is the only global variable that should be created or modified by widgets. It is not guaranteed to be initialized. To minimize collisions, widgets should only operate on fehwiki.<widget name>, though it may access other fields if two different widgets need to communicate.

Minification[edit source]

High traffic widgets that is planned to be run by a lot of people (on the main page, in sitenotice, etc.) should ideally be minified. Regardless of whether this is done, the unminified source code must be present somewhere. A typical minified widget page source may look like this:

<includeonly><!-- Minified HTML/JS --></includeonly><noinclude>
<syntaxhighlight lang="html"><!-- Unminified HTML/JS --></syntaxhighlight>