Xeno Series Wiki:Manual of Style

This is a guideline, a principle that all users should be aware of and try to follow. Do not edit this page unless you have consensus about it on the talk page.

This is the manual of style for the wiki. It defines guidelines for how text should be written, images should be taken, and that sort of thing.

Article titles

• Titles should be singular rather than plural.
• Titles should be nouns rather than verbs.
• If a multi-word title is not a proper noun, then the words should not all be capitalized.
• If a page requires disambiguation, first try to resolve it by specifying the game in question (e.g. "Back Slash (XC1)"). If this is not sufficient, how to proceed further will depend on the subject. "By character" or "by largest unambiguous location" are the primary next steps.
  • If there needs to be multiple sets of parentheses, prefer doing (just) (that), rather than (something else, like this).

Non-article titles

• Categories should be plural.
• Templates, extra data pages, and other such pages (those which are generally referred to instead of being read directly) should share naming conventions with other related pages. For example, if most infoboxes are named "Infobox (game) (thing)", then an infobox called "Infobox (thing) (game)" is not ideal.
  • Similarly, images need to have consistent names if a template or something needs to find them. Otherwise, image names don't matter that much.

Headers

• Because article titles are level-one headers, articles should only contain level-two headers and below.
• Subsections should be one level offset than their parent, not more.
• Like article titles, headers should not capitalize all the words if they are not proper nouns.
• Headers should be kept short.
• If possible, headers should be unique - no two headers on one page should be the same. This is because any links will only go to the first header of any that share a name. This is not always feasible, and it's not a big deal if the header is unlikely to be linked to (such as a gallery).

Text

• Paragraphs should be used to break up long stretches of text.
• The article's subject should be in bold text in the first sentence. Using bold text to emphasize names in lists is acceptable (if they are not links). Bold text should be otherwise generally avoided, as it attracts too much attention.
• Italics should be used to mark the names of games. Using italics for emphasis can be acceptable.
• Other forms of text decoration (e.g. underlines or colours) should not be used.

Exceptions

• If a piece of text is taken directly from the original source, it is more acceptable to use styles and colours so it looks as it did there, regardless of the above. Enlarged text is still very strongly discouraged, use bold for it instead if possible.
• When transcribing dialogue, thoughts are traditionally written in italics, even if the source uses some other formatting to show it. If the game's text boxes support an "angry" or "shouting" visual, it is bolded. (Don't use bold like this for voiced scenes that don't have formatted text boxes - it's too subjective whether it's yelling enough to count.)

Writing style

• While formality is generally best, an amount of flippancy is acceptable. All work no play make Riki a sad boy. Edits that do nothing but serious-up a piece of text are not cool.
• Profanity should be avoided when possible. It is almost always possible; the only exception is in direct quotations.
• For summaries of in-game events, present tense should be used whenever possible.
• Abbreviations should be spelt out in full the first time they are used in an article, and perhaps again at the start of a long section.
• Avoid second-person writing (e.g. "you can do this") in favour of third-person (e.g. "the player can do this" or "[character] can do this").
• In regards to American vs. British English spelling differences, the preference is to match that of the article's subject (e.g. articles relating to Xenoblade Chronicles should use British English because this is what the game uses). If the article has no such obvious affiliation, either is acceptable, as long as the whole article is self-consistent. One should not edit a page solely to change one spelling to another. Be wary of words that are not commonly known to differ in this way, such as "skilful" vs. "skillful".
• Similarly, in-game units are likely to remain in metric even if Nintendo of America displays them otherwise. Always note the metric number as the primary, and only show the non-metric one as a sidenote.
• Dates should be formatted as "DD month YYYY". Use Template:Date, which automatically converts it to the correct formatting, whenever possible.

Internal links

• Articles only need to be linked to once, or maybe again at the start of a later section.
• Use efficient links where possible. [[Item|items]] isn't necessary when [[item]]s works, and [[Page#Specific section|text]] isn't necessary if [[Specific section]] is a functional redirect - especially because "Specific section" might later be split into its own page, and doing it this way means less work repointing existing links. Redirects in general are harmless.
  • It may be preferable to make exceptions to the "use redirects" guideline for navbox templates, as redirects do not apply the "current page is bold" formatting to links.

Translations

When translating text from other languages:

• Always include the original text in some way. The two main ways are "original followed by translation" and "translation with original in the notes/references", but depending on the context other methods are fine.
• If there is an official translation, it has priority. But there are cases where an additional non-official translation may provide additional information.
• Do not simply paste in a machine translation (e.g. Google Translate), especially for Japanese.
• Avoid translating only part of something. Save your work somewhere if you don't have the time to finish it, but "all-or-nothing" is the preferred method for pages. Among other reasons, partial translations make it hard for things like templates to detect whether a page should be marked as "needs translation" or not.
• Try to avoid copying a translation from elsewhere. We'd rather not depend on the accuracy of other sources. In a perfect world, all of the wiki's translations would be made "in-house".

For the "meaning" of language tables such as Template:In other languages:

• Be reasonably literal, but include non-literal comparisons if it improves understanding.
• A language table isn't needed on pages such as "Person (boss)", as it would be exactly the same as the one on "Person". But if it's "Person the Prudent", that's different.
• Translate only the part that's relevant on this page. For example:
  • The "Bunnit" page explains the meaning of "lapix". The "Little Bunnit" page does not need to duplicate this effort, so for the entry on "petit lapix", the meaning is shown as "Little Bunnit".
  • While the literal translation of アーケディア人 would be "person from Acedia", we would have to take a second "step" to explain that "Acedia" is localized as "Indol". Therefore, the meaning skips this step, saying only "Indoline".
• No meaning is needed if the original is exactly identical to the English, such as many proper nouns.

Sourcing

It is generally expected that any information found in an article does not require to be explicitly sourced if it can be easily (if perhaps not quickly) verified by anyone with access to the subject. If it is not so easy, it becomes more important to state the source.

• If the information is present in the work, but hard or impossible for the average person to find and verify, sourcing is not required but appreciated.
  • Examples: hidden dialogue only visible under difficult conditions, datamined information
• If the information is not present in the work, the source must be specified in the text alongside the information. An exception can be made for infobox entries; they can be allowed to get away with only a rollover or a footnote tag.
  • Examples: crossover game, artbook, developers' interview, model kit
• If the information is about something that isn't part of a work, sourcing is strongly recommended. If it's information about a real-world person, sourcing is mandatory.
  • Examples: articles about a game itself, articles about developers

DLC counts as the same work as the base game; a sequel does not.

Files

• Files should generally be unedited. We would like to be as accurate to the original source as is reasonable.
  • Converting images from weird formats to standard formats (such as .jpg or .png) is okay, as long as care is taken that there is no noticable change. By the same token, converting between standard formats (e.g. from .jpg to .png) is also okay if there is no visible change, but there should probably be a reason for the change.
  • Cropping is fine if most of the image is irrelevant to a context, or if there's a long gap of silence to start/end a sound that doesn't need to be aligned with another sound.
  • Cutting out a background (to make it transparent) should be done with caution, but is probably fine for artwork with defined edges.
  • It's possible that a file from the game was intentionally saved in a format that looks wrong when viewed "raw". For example, video files in the Wii version of XC1 are 640 x 499, but sized down to 640 x 360 when displayed, so the originals appear vertically stretched. It is okay to transform such files to match how they appear in-game, as long as the uploader is very sure they're doing it correctly.
• It's okay to take screenshots from emulators, but they shouldn't use any features that would make it "invalid" to get from a real console (e.g. higher resolution). Exceptions can be made if the subject cannot be shown legit, such as using a camera hack to show a model normally hidden offscreen, if the point of the image is to show this.
• Screenshots should be of the best quality the console can provide.
  • Wii U screenshots should always be taken from the TV. Only take screenshots of the GamePad if the content literally cannot be shown on the TV.
  • Nintendo Switch screenshots should be taken in docked mode. Handheld screenshots are acceptable as a stopgap, but should be tagged with Template:Low quality image and replaced when possible.
• Voice clips and other sounds are only to be uploaded for specific illustrative purposes. Do not upload all of a character's lines just for the purpose of us having all the lines.
• No music. Sounds and voice clips only. If we want to display music we can link to some YouTube video or similar, we are not hosting music on the wiki itself.

Galleries

• Galleries are placed at the bottom of the article. If it grows too large (around 50 images), it should be split into its own page.
• Galleries should only contain images not used elsewhere on the page. This rule does not apply if the gallery was already moved to its own page.
• Unless the gallery only contains a few images, it should be split into subsections.
  • If applicable, the first section should be for official artwork across all games. Subsequent sections should first be divided by game, then by type (screenshot, concept art, render, etc.).

Article splitting/merging

Sometimes it can be debated whether two subjects should share a page, or whether they should have individual pages. Keeping them on separate pages is the default action because this makes it easy to comply with our spoiler policy, but sometimes it makes more sense to merge the two into one page. If all three of these are true, then merging should be considered:

• One page redirecting to the other (in either direction) is not a spoiler in and of itself.
• The source material makes little or no attempt to hide that the two subjects are the same.
• The subjects are not of equal importance when compared to each other (in other words, it is easy to choose which one should be the page's main title/identity).

Of course, every case is unique, and the less clear-cut situations will need discussion to judge consensus.