Spelling and Typography • Grammar and Usage • Tone • Links • Titles and Article Organization • Location Pages • Media • Outdated or Unused Content • Miscellaneous
This section of the Style Guide concerns the tone Yume Wiki articles should use. We want articles to be written using an encyclopedic tone. In other words, they should be unbiased, professional, informative, and well-grounded in verifiable facts.
Neutrality
Write articles using a neutral, unbiased tone. Avoid terms that are loaded, judgemental, or biased. For example, avoid calling a map or game "impressive", "ugly", "unpleasant", "innovative", "controversial", "iconic", etc., or an author "talented", "skilled", "amateurish", "derivative", etc.
Similarly, avoid the use of emotional language about a subject such as "terrifying", "creepy", "relaxing", "frustrating", etc.
Avoid language that could be interpreted as expressing doubt (such as "so-called", "supposedly", "allegedly", "it is believed that...", or the use of scare quotes), especially about uncontested facts.
Do not use language that tells the reader how to feel about information, such as "amusingly", "amazingly", "interestingly", "surprisingly", "ironically", etc. Just present the information as-is.
In general, do not state opinions or contested assertions as facts. Do not state well-established facts as opinions, either.
Professionalism
Presentability
Ensure that all articles represent a good grasp of the basics of English spelling, grammar, and punctuation. If you are unsure of your language skills, consider asking other editors for help, or consulting one of the many websites and books dedicated to that purpose. The Style Guide also provides advice on some of these topics.
Slang
Do not use slang, memes, or other informal language in article bodies. Words like "kinda", "ain't", "sorta", "vibes", etc. should not appear in articles. Do not use obscenities or profanity unless its inclusion is absolutely necessary in an article (for example, when directly quoting in-game text).
In other words, the same standards that apply to writing a professional email or an academic essay apply here as well.
Humor
Contain any jokes to the captions on images. Do not write jokes into the body of an article for any reason. This includes the use of editorial irony, dry humor, and Internet memes.
Captions on images should be in good taste and should not belittle the subject for any reason. If useful information can be provided in a caption (such as labeling a map connection), skip the joke and provide information instead.
Captions may be removed by moderators at any time for any reason.
Clarity
Write using clear, plain, concise language. Choose vocabulary and phrases that can be understood by a broad general audience familiar with English.
Be specific and precise in your descriptions, but avoid bloating descriptions with flowery language or unnecessary detail.
Remember, the purpose of a wiki is communication.
In general, avoid the following:
- Clichés and idioms. For example, "to bear fruit", "elephant in the room", "picture-perfect", "by any stretch of the imagination", and phrases like these are vague, overused, and occasionally confusing to speakers of English as a second language.
- Euphemisms, such as "passed away" or "croaked". These pose the same issues as idioms.
- Relative time references, such as "recently", "not long ago", "next month", or "soon". These are both imprecise and lose their meaning as time passes from the time of writing.
- Neologisms, unless they're directly related to terminology used in-game.
- Jargon and technical terminology where a simple description will do.
- Flowery, poetic descriptions using words mainly found in literary fiction, or worse, have gone extinct entirely.
- Excessively detailed descriptions of characters or objects, especially if there is a picture on the page of the thing being described.
- Using easily confused words incorrectly, such as using "exaggerate" to mean "exacerbate", or "infer" to mean "imply". There are a number of lists available online clarifying these terms. When in doubt, consult the dictionary or rewrite.
- Long sentences with multiple subclauses or heavily nested descriptions. These are often difficult to parse even for native English speakers. If you're not sure if a sentence is easy to understand, try reading it out loud. If it sounds awkward or you need to keep pausing to catch your breath, it probably needs to be rewritten.
- Any of the numerous and unnecessary synonyms for "said".
Group ideas together in paragraphs. Sentences within paragraphs should logically flow from one to the next. Avoid ambiguous constructions.
If events occur in sequence, describe them in chronological order. For example, "If Madotsuki attacks Toriningen with the Knife effect, they will become hostile and chase her." is a better sentence than "Toriningen become hostile and chase Madotsuki if she attacks them with the Knife effect.", because the first sentence describes events in chronological order.
Precision
Be specific in your descriptions, especially for descriptions involving player actions or unlock conditions. Avoid being vague.
Precise figures for time are preferable to "a while", "some time", "a long time", etc.
Similarly, precision when describing random chance is preferable to "sometimes", "rarely", "occasionally", etc. If it is known when a random variable is generated, include this information as well (such as upon entering a room, upon interacting with an object, upon going to sleep, every second the protagonist remains in a location, etc.).
For example, instead of writing "By waiting a long time, an event will begin.", write "By waiting in the exterior without leaving for six uninterrupted minutes, the Figure in the Flames event will begin."
Avoid weasel words such as "some have suggested that...", "it is thought that...", "it is reasonable to assume that...". They are nonspecific, misleading, and provide imaginary authority to otherwise unfounded statements.
Directness
Be direct in your language. Avoid unnecessary phrases and clauses wherever possible.
Do not use qualifying expressions like "seemingly", "appears to be...", "could possibly be...", etc., unless there is genuine uncertainty about your description. For example, do not write "The room has what appears to be two beds and some sort of table." if the furniture in the room is clearly two beds and a table, even if those objects are strange or otherworldly in appearance (such as being a strange color or made out of an unusual material, etc.).
Where possible, avoid the use of the medium of the player's or the protagonist's senses for description, such as by writing "the player can see that...", "...is visible", "will hear the sound of...", etc. Write the description directly. For example, write "This room contains two NPCs.", not "The player will see two NPCs after entering the room." or "There are two NPCs visible in the room."
Inclusivity
As stated in the guidance on Gender, use preferred or official pronouns when referring to a person or character.
Additionally, use gender-neutral language where possible. When referring to the player or a generic person, use singular they, rather than he or she. For example, write "The player can customize their wallpaper." not "The player can customize his wallpaper."
Detachment
Avoid using language that creates a strong narrator. Use language where the writer of the article is invisible to the reader.
Self-Reference
Do not break the fourth wall or use self-referential language when writing articles. Do not refer to the Yume Wiki, or the contents of a page as being part of an encyclopedia article. It is usually completely unnecessary. For administrative articles such as this one, this rule does not apply.
Do not use language such as "we", "this editor", or "I" to refer to yourself or the Yume Wiki as an entity.
Presumptuousness
Avoid language that makes assumptions about a reader's knowledge, such as "clearly", "obviously", "as the name implies", "of course", etc. It is condescending.
Instructional and Pedagogical Language
Avoid language that addresses the reader directly with an instruction, such as "note that...", "it is important to know that...", "it is significant that...", "remember that...", etc, which is usually unnecessary.
For guides, instructional language is permitted, but use it sparingly and stick to actions the reader needs to take.
Do not use rhetorical questions, as is typical in textbooks, to introduce a subject.
Groundedness
Include only grounded, uncontested facts in articles. Avoid including speculation, contested information, or unverifiable or unsourced claims about an author or their work. Do not use persuasive writing advocating for a particular interpretation of a work.
Theories
Do not use the Yume Wiki as a venue for posting fan theories or other unsubstantiated claims about characters, locations, or creators. Do not create sections in articles, or create pages dedicated to this purpose. Do not create entries in Trivia sections speculating on the meaning or purpose of locations, characters, or other content.
Homages and References
Speculation or claims about homages and references to other media (including other Yume Nikki fangames) are permitted, but they must be well-sourced and substantiated by the evidence provided. The more extraordinary the claim, the more extraordinary the evidence required.
If the reference/homage involves Yume Nikki or another fangame, link to the appropriate page(s) on the Yume Wiki or YNFG Wiki. If the reference involves a piece of media outside the scope of the Yume Wiki, link to an external source providing evidence of your claim. Do not upload images unrelated to Yume Nikki or Yume Nikki fangames to the Yume Wiki and add them to pages to prove your point.
For example, if you claim that an NPC's appearance is a reference to a character's appearance from a non-Yume Nikki-related piece of media, link to an external source providing an image of that character that backs up your claim beyond reasonable doubt.
Developer Statements
If a developer makes a statement about their work, you may include a summary of their statement in the Trivia section of the relevant article, along with links to the source of that statement. There is usually no need to quote the statement directly unless the statement cannot reasonably be expressed otherwise.
Sources for developer statements must be posted in a public space off-wiki, must be independently verifiable, and must be able to be hyperlinked and archived using the Wayback Machine. This includes tweets, blog posts, official websites, media outlets, or archived video. Private, temporary, or gated sources such as Discord chat logs, Google Docs, Pastebins, phone calls, emails, unarchived livestreams, and so on are not considered reliable sources, because they cannot be linked, archived, or independently verified. Do not use screenshots as sources, because screenshots are easily faked and can be difficult to verify.
Statements must come directly from the developer themselves or from a reliable independent source (such as a magazine article). Hearsay ("I heard that...", "The author told me that...", etc.) does not constitute sourcing, even if this hearsay is published off the Yume Wiki.
As with other translation work, if the statement is in a language you are not proficient in, do not use machine translation. Consult another editor for help, or refrain from sharing that statement until it is certain that their intent has been correctly translated into English.
There is currently no set style for citations on the Yume Wiki, but all sourced statements that cite URLs should include a direct link to the website, as well as an archive.org snapshot of the page as it appears at the time of writing in case the page is modified or taken down.
Developer Editing
If you are a developer of a Yume Nikki fangame, in general, avoid editing pages related to content you created or contributed to. Do not add new information about your content not found in-game or reliably sourced outside the Yume Wiki. The Yume Wiki covers already-existing information, and should not be the primary medium used to share new details about your work.
We encourage developers to correct minor formatting or small factual errors on pages related to their content. However, more substantial editing on pages related to their content is generally discouraged.