Fire Emblem Heroes Wiki:Guidelines

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.

Community Rules
Following the rules below is a mandatory in order to post anything on this wiki. Please note that any content which does not follow those rules will eventually be deleted. Recidivism will lead to a temporary ban, or permanent ban if judged necessary. If you are unsure about something, you can ask the wiki staff on discord, channel.
 * Do not post Not Safe For Work (NSFW) nor Not Safe For Life (NSFL) content. Keep in mind this is an open community, involving all kind of real people from various age, gender, sexual orientation, nationality, religion, etc. Take care of what is posted, including on personal pages.
 * Do not post anything which may hurt other. Do not attack, insult, nor scorn others. We are not here to despise peoples, but to share a pleasant moment or collect informations about something we like. If you have something to say, keep it polite and instructive, rather than aggressive and belittling.
 * Be open-minded and in good faith. This wiki is open to edit by anyone. Whether they are beginners or advanced editors, Edelgard followers or Grima adepts, everyone is allowed to participate. Get rid of your prejudices and be friendly with everyone. Keep any conversation exempt of blames, and be instructive whenever someone makes mistake.
 * Do not engage in excessive self-promotion. This wiki is a collaborative community resource. It is NOT a free place to advertise your related website, YouTube channel, blog, etc. If you want to share them, do it on your personal page, and only there.

Manual of Style
See the Manual of Style for various standards/conventions.

Future-proofing text
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
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
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
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:
 * -- Sekuiya talk 01:02, 20 February 2017 (EST)

Editing user pages
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 modules can be invoked in a similar way, e.g..

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:
 * All user pages, as defined above:
 * All pages in the UserProfile namespace and all Talk namespaces;
 * All deprecated templates and candidates for deletion.

Special subpages
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  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  call with , 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 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
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:
 * (mainly used for simple images such as File:Green_check.svg, see this page for more information)
 * (the majority of assets will be in this format)


 * Avoid using these lossy formats:
 * (lossy, no support for transparency)
 * (worse compression than, 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
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  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  vorbis instead)

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

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
'''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 instead of  in templates, as calling the template with  and  will produce different results with the second method instead of the first.

Parameters
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
 * everywhere, including inside a HTML attribute
 * inside a script tag
 * inside a script tag outside of a string
 * outside a script tag if  appears anywhere afterwards in the page.

The following have not been found to be unsafe:
 * Using
 * Using  if the character set for the data is very small to remove all characters not in that set.
 * Using  inside a script inside a string
 * Putting the data in a data attribute with

Wiki page structure
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
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;  cannot be used to load JavaScript from a namespace that is not MediaWiki or User.

JavaScript
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  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, though it may access other fields if two different widgets need to communicate.

Minification
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: