User:Selva/Sandbox

Style Guide Draft

BEGIN QUOTED TEXT:

The Style Guide is the descriptive standard for Yume Wiki's style and formatting conventions to ensure users edit consistently.

If you have questions, concerns, or suggestions about these guidelines, please use the talk page.

Although following the guide is highly encouraged, most (but not all) questions of style are usually left "to the discretion of the editor," as long as it is consistent within an article.

1. Spelling and Typography

1.1 General Guidelines

In order to maintain minimum quality standards, we expect articles published on Yume Wiki [something about how the articles need to represent "good English". We don't want people throwing up articles that need extensive copyediting. You'd think this should go without saying, but...]

1.2 Variations in Standard English

It is up to your discretion whether to use American, British, or other English spelling, grammatical, or mechanical conventions. This guideline includes mechanical variations such as the Oxford comma. Do not edit articles to exchange one variety of English for another.

Keep spelling, grammatical, and mechanical conventions consistent across an article. For example, do not mix British and American spellings within the same article.

Where possible, use vocabulary common to all varieties of English over regional vocabulary. For example, use "200,000" over "two lakh" (Indian English).

If there are multiple possible acceptable ways to spell a word, use the most common spelling. For example, while "coöperate" is technically a valid spelling, it is archaic and is almost obsolete. Use "cooperate" instead.

Avoid slang, unless related to general gaming, RPG Maker, or Yume Nikki Fangames.

1.3 Capitalization

1.3.1 The

Do not capitalize "the" midsentence, unless it is part of a title of a work. For example, write "Minnatsuki can enter the Nexus.", not "Minnatsuki can enter The Nexus."

1.3.2 Emphasis

Do not use capitalization for emphasis. This includes the use of all-caps and initial capitalization. For example, do not write, "Effects CANNOT be used here."

1.3.x Effect Names

For effect names, capitalize the name of the effect, but not the word effect. For example, "Wolf effect".

If the name of the effect contains the word "and", do not capitalize "and". For example, "Hat and Scarf effect".

1.3.x Location Names

For location names, capitalize the name of the location in the same manner it is capitalized in the lead paragraph of its respective article. For example, capitalize RED DREAD DEATH in exactly this manner in all content pages referring to it.

1.4 Ligatures

If the word is from a language where the use of ligatures (such as æ or œ) is standard (such as French), use ligatures. Otherwise, do not use ligatures. For example, write "aether", not "æther".

1.5 Abbreviations

Avoid using abbreviations wherever possible, unless the abbreviation is part of a proper name. For example, FC Fields. Common abbreviations such as "DNA", "CPU", "PDF", etc. are exceptions to this rule.

If an uncommon abbreviation must be used, introduce it by writing out the entire expression followed by the abbreviation in parentheses. For example, "The RPGMaker 2003 run time package (RTP)". Do not capitalize each word of the initialism.

Do not use periods or any other punctuation in between the letters of initialisms. Do not use apostrophes to form plurals. For example, write "NPCs", not "N.P.C.'s" or "NPC's".

Do not use abbreviations for Latin phrases, such as "i.e.", "e.g.", "viz.", and so on, unless they are used in the title of a work. For example, write out "versus" for "vs.", and "for example" for "e.g."

The exception is "etc.", short for et cetera, which may be used at the end of non-exhaustive lists. Do not spell this as "ect."

1.6 Ampersands (&) and Octothorpes (#)

Do not use ampersands (&) or octothorpes (#) unless they are part of a proper name or quoted text.

Instead, use "and" for ampersands.

Similarly, instead of writing "#4", write "number four".

1.7 Italics and Other Emphasis

1.7.1 Emphasis

When emphasizing text, use italics. Do not use bold, underline, or all-caps to emphasize. However, if the emphasis occurs in quoted text, retain the original emphasis.

Do not italicize punctuation surrounding emphasized text.

1.7.2 Frequency

Avoid the overuse of italics, because the effect diminishes over time.

Avoid italicizing large blocks of text, because this makes the text difficult to read.

1.7.3 Foreign words

If the foreign word is in a Latin script, italicize the foreign word. Otherwise, do not italicize the word. [example?]

1.7.4 Titles

When referring to the title of a work, italicize the name of the title, even if the text is written in non-Latin characters. For example, "Minnatsuki is the protagonist of Collective Unconscious."

1.8 Quotations

[Essentially describe the principle of minimal change here and say that many rules about style do not need to be applied to quotations, such as that of in-game text. This section might not be necessary, as very few fangames have text to quote in the first place.]

1.9 Punctuation

1.9.1 Spacing

Place a single space before the beginning of a new sentence, items in a list separated by commas, and after colons and semicolons.

For example, write "There are hats in different colors. The colors available are: red, green, blue, and yellow.", not "There are hats in different colors.The colors available are:red,green,blue,and yellow."

Do not place any spaces before any punctuation marks.

For example, write "The colors available are: red, green, blue, and yellow.", not "The colors available are : red , green , blue , and yellow ."

1.9.2 Apostrophes

Use straight apostrophes ('). Do not use curly apostrophes (’), backticks (`), or accent marks (´) as apostrophes.

If a foreign word or proper noun contains an apostrophe-like mark such as the ʻokina (ʻ), use the appropriate symbol and not an apostrophe.

1.9.3 Quotation marks

Use straight quotation marks (").

Do not use:

• curly quotation marks (“” or ‘’)
• low-high quotation marks („ “)
• guillemets (« »)
• square quotes (「」or 『』)
• backticks (``)
• accent marks (´)
• or two apostrophes ('')

When quoting, prefer double quotes (") over single quotes (') to introduce a quote. Quotations within quotations should use single quotes (').

1.9.4 Brackets and parentheses

Avoid having sets of parentheses or square brackets right next to each other. [example]

If a sentence ends in closing parentheses or square brackets, it must end in a period outside the brackets, regardless of whether there is punctuation inside of the parentheses. For example, "(x, y, z, etc.)."

Ask yourself if the information is really parenthetical to the sentence, or if it can stand alone as its own sentence. If it is not, rewrite.

1.9.x Terminal punctuation

Avoid the use of exclamation points (!) and question marks (?) unless they are part of a proper noun or a quotation.

Do not use ellipses, unless they are part of a quotation, or to indicate that text has been omitted from a quotation.

Do not use inverted exclamation points or question marks.

1.10 Numbers

Write out numbers from 0-20 as words, unless in a mathematical or statistical context, or when specifying an amount of currency. [move to own sections?] For example, "6" should usually be written as "six"; however, write "$20" and not "twenty dollars".

Write out numbers greater than 20 as numerals. For example, "one hundred and twenty-three" should always be written as "123". [What about large numbers than can be expressed in one or two words, such as four billion?]

For numbers with five or more digits, use a comma every three digits from the right. For example, write "2,313,879", not "2313879".

The cut off is generally between twenty and twenty-one, because hyphenated numbers are best written using numerals for ease of reading and spelling. The important thing is to be consistent in the article.

1.10.x Percentages

Use the percent sign (%) when indicating percentages, rather than writing out "percent" or "per cent". Do not put a space before the percent sign.

1.10.x Version Numbers

[This needs an extensive rewrite, as this paragraph conveys almost no information.]

Refer to versions using the version number and letter, e.g. "0.100a" or "version 0.100a." Don't use ".100a," or "100a," or "ver0.100a" in articles. In the case of patches, write out the word patch then the number, e.g. "0.100a patch 3." If a wiki consistently uses a different format, stay consistent with the wiki and do not change all its pages to the format outlined here.

1.11 Romanization and Translation

Where foreign text appears, provide a romanization (if applicable) and translation. If you lack the required language skills, contact an editor who has them for assistance.

If the Japanese text appears in the body of an article, enclose the romanization and translation in parentheses, separating them with a comma. Place translations after the romanization. For example, "ゆめにっき (Yume Nikki, Dream Diary)".

If a romanization appears in the body of an article, enclose the original Japanese text and translation in parentheses, separating them with a comma. Place translations after the original text. For example, "Yume Nikki (ゆめにっき, Dream Diary)".

1.11.1 Romanization

1.11.1.1 Standard

When providing a romanization, use the Revised Hepburn standard.

Notable features of the Revised Hepburn standard:

• Long vowels are usually indicated by a macron over the lengthened vowel. For example, お弁当 is romanized as obentō. Note that いい is still usually romanized as ii and えい is romanized as ei. Vowels followed by a lengthening marker (ー) always have a macron over them.
• Repeating vowels across morpheme boundaries are left separate. For example, 邪悪 is romanized as jaaku.
• Consonants that change sound before i or u are written phonetically. For example, ふ is romanized as fu, not hu. Similarly, じゃ is romanized as ja, not zya.
• Long consonants are doubled. Note that っち is romanized as tchi, not cchi.
• Moraic n (ん) is always written as n; it does not change to m before b, p, or m. For example, romanize 先輩 as senpai, not sempai.
• Before (and only before) vowels and や、ゆ、よ, an apostrophe is written after moraic n. For example, 千円 romanizes as sen'en, and 案内 romanizes as annai.

Do not omit macrons where prescribed by the standard. For example, romanize 教室 as "Kyōshitsu", not "Kyoshitsu", "Kyoushitsu" or "Kyositu".

For further details about the standard, see the linked Wikipedia article above.

1.11.1.2 Capitalization

If a phrase contains katakana, do not romanize the katakana in all caps. For example, romanize タイル通路 as "Tairu Tsūro", not "TAIRU Tsūro".

When providing a romanization for a proper name, capitalize each word, unless that word is a suffix or a particle. Italicize the romanization. For example, romanize [example] as [example]

1.11.1.3 Loanwords and romāji

If the phrase contains a word in romāji, transcribe it exactly as it is written. For example, romanize ＦＣ世界 as "FC Sekai", not "Efu Shī Sekai", and 真っ白umi as "Masshiro umi", not "Masshiro Umi".

If a phrase contains a foreign loanword in katakana, transcribe it fully. For example, romanize ブロックの世界 as "Burokku no Sekai", not "Block no Sekai".

There is one exception to this. If the phrase is a title or other important proper name, you may romanize the loanword as its translation. For this exception, map locations are not considered important proper names. For example, ユメ‐グラフィティ may be romanized as "Yume Graffiti" rather than "Yume Gurafiti", because it is the title of a game.

1.11.2 Translation

When providing a translation, ensure it is accurate.

Do not use machine translation (such as Google Translate or DeepL) or large language models (such as ChatGPT or DeepSeek) to make translations for you, because they are prone to error and routinely fail to understand context.

If you do not know the target language, please leave the translation work to someone who does.

Be careful when creating page titles based on translations. Do not create a page title or rename a page based on a translation unless you are absolutely sure it is correct.

2. Grammar and Usage

2.1 Pronouns

2.1.1 The first person

Do not use first person pronouns (I, we, our, etc.) to refer to the editor(s) or reader(s) of an article.

2.1.2 The second person

Avoid the use of the second-person pronoun "you" when referring to the player or reader(s) of an article.

Prefer the use of "one", "a person", or the passive voice when referring to "anyone" as a subject.

2.1.3 The third person

2.1.3.1 Gender

When referring to a person or character, use the pronouns that match their self-identification (or official sources in the case of a character). If the person or character is non-binary, use singular they.

If a person or character's gender identity is not known, use singular they.

2.1.3.2 Protagonist versus Player

For actions done by the game protagonist, use the name or the appropriate gendered pronouns (such as she/her). For example, in Yume Nikki, the protagonist falls asleep, not the player, so use "Madotsuki falls asleep."

For actions done by or to the player, use the phrase "the player", the passive voice, or second-person pronouns . For example, the player interacts with the menu, not the protagonist, so use "The player can open the menu." or "The menu can be opened."

In cases where either the player or the protagonist are valid actors in a sentence, use your discretion. Be consistent. For example, if a section states the protagonist interacted with an NPC, ensure all text in this section refers to the protagonist and does not suddenly switch to referring to the player.

2.2 Tense

By default, when referring to content that is currently available, use the present tense. For example, "The FC Worlds are a set of worlds that all feature simplified, NES/Famicom-styled graphics."

When referring to content that is no longer available or present, or when discussing something that no longer exists, use the past tense. For example, "The Droplets World was an area accessible from Character World."

2.3 Contractions

Where possible, avoid using contractions. For example, use "do not", instead of "don't", "it is" instead of "it's", and so on.

Contractions which are compulsory in the English language, such as "o'clock" and "'s" for possessives, are allowed.

3. Tone

3.1 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.

3.2 Professionalism

3.2.1 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.

3.2.1 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.

3.2.2 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.

3.3 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, "bear fruit", "elephant in the room", "by any stretch of the imagination", and phrases like these are vague, overused, and possibly 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", 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.

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.

3.4 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."

3.5 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 obviously 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."

3.6 Inclusivity

As stated above, 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."

3.7 Detachment

Avoid using language that creates a strong narrator. Use language where the writer of the article is invisible to the reader.

3.7.1 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.

3.7.2 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.

3.7.3 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.

3.8 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.

3.8.1 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.

3.8.2 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. 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.

3.8.3 Author Statements

If an author makes a statement about their work, you may include a summary of their statement in the Trivia section of the relevant article, along with a link to the source of that statement. There is usually no need to quote the statement directly unless the statement cannot reasonably be expressed otherwise.

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.

4. Links

4.1 Internal Links

4.1.1 Frequency

When using internal links to other wiki pages in articles, only the first mention of the topic should be a link. Do not link to the same page multiple times within the same article.

Some exceptions to this rule apply:

• Infoboxes should have links even if the link already exists in the article.
• Locations listed in the "Directions" section of location pages should have links, except the first and last locations.
• Image captions in galleries may repeat links, at the discretion of the editor.

4.1.2 Linking to Effects

When linking the names of effects, make the effect name a link, but not the word "effect" itself. For example, "Urotsuki can use the Chainsaw effect."

4.2 External Links

If possible, when linking to Wikipedia or other external wikis, use interwiki links. If an interwiki link is available, do not use a URL. Currently, the only interwiki link available is [[wikipedia:Example]].

If you wish to mimic the look of internal links when using external links, use <span class="plainlinks"> </span>.

5. Titles and Article Organization

[THIS SECTION REALLY NEEDS SOME HELP OH NO]

When creating a page on Yume Wiki, the name should represent the subject of the article.

It is good policy to check the names other people in the community are using, if any. For example, Yume 2kki locations may have names suggested in Version History or Map IDs. If no name has been adopted by the community, or declared officially by the author, the editor must invent a name for the wiki.

When naming a page, it should generally be based on its original (probably Japanese) name, which can be found in a few possible ways:

1. Opening the game using its engine and checking the internal name of the map or event.
2. Checking the name of the assets used, such as a map's ChipSet or a character's event CharSet.
3. In a changelog file, if any (for Yume 2kki it is changelog.txt)

There are many exceptions to using the original name, such as it being too similar to another name (in which case it should be something else to avoid confusion), if the original name sounds awkward when translated into English, or if the name is generic or missing.

All articles should be named in title case, except when using official names. The editor who creates (or moves) the page should ideally mention the method used to (re)name it.

Never use special characters like & or ?; these are reserved URL parameter delimiters, and doing otherwise may break APIs (e.g. those used in external projects like Yume 2kki Explorer or YNOproject) making use of wiki content. Alternate names will need to be chosen. For example, the character page ***-tsuki uses that name instead of the more common ???-tsuki due to this limitation.

Grammatical Articles

Avoid naming a page using grammatical articles, such as the definite article "The", even if it appears to make sense grammatically: using it makes it harder to find, sort, and link to the page. For example, Yume 2kki:Spaceship is always referred to as "the Spaceship," but does not include "The" in the page name. There are some exceptions such as when the name is a title; see Wikipedia's guidance for further details, which may be applied to Yume Wiki.

Pages using official names are not expected to follow this guideline.

Yume 2kki page names may include grammatical articles due to either using an official name or because changing the name would cause issues in YNOproject's expedition feature. The community has agreed to avoid renaming these pages. Discussion may still be opened to rename, but it requires notifying the YNOproject developers in the official Discord server.

In cases where an article is included at the start of the page name, the {{DEFAULTSORT:}} function should be used.

The function should be placed at the end of the page, and if any categories are listed at the end, the function should be placed in the first line.

The following example is taken from the page of Yume 2kki's The Magic Nexus:

==Gallery==
<gallery>
…
</gallery>

{{DEFAULTSORT:Magic Nexus, The}}
[[Category:Yume 2kki In Development]]
[[Category:Open for Cross-Author Connections]]
[[Category:Yume 2kki Hub Worlds]]
[[Category:Yume 2kki Connecting Maps]]

Official Names

Page names may be changed according to the wishes of the content's author(s). Some wikis, such as Collective Unconscious Wiki, use official names in a majority of cases. For most content on Yume Wiki, it is not required to ask authors for permission to name things, although it is courteous to do so when possible.

Page names using official names are not expected to follow some of the preceding guidelines.

• They may include the definite article "The" and should not be renamed to omit it. This is unlike pages named by users, which should mostly avoid using grammatical articles.
• They may be in a different case than the normal title case, such as .flow's hole in girl using lowercase or Collective Unconscious' RED DREAD DEATH using uppercase.

The reason behind these exceptions is to preserve the author's intention completely.

Editors should mention that the name is officially requested by the author in the edit summary of the page creation (or page move).

Yume 2kki Page Naming

For Yume 2kki worlds, in the official Discord server, there is a naming process for locations that involves a suggestion phase and a voting phase. The idea of the naming process is to have a dedicated space for community members to discuss, suggest, and vote on world names.

After at least 24 hours have passed since the new content has been made available to download, a thread will be created for each location. In each thread, users can suggest names for the location. After at least 72 hours have passed since the thread has been created, a poll will be created for each location using all of the suggestions, limited to one suggestion per user. These polls last for 72 hours, with the winner being chosen as the name of the location. A tiebreaker poll will be held in case of tied results.

6. Location Pages

6.1 The Locationbox Template

Every location page must use the Locationbox template. This template presents the basic information of the location. The template is used heavily to supply information for APIs.

The only location pages that should not use the template are multi-page locations.

6.1.1 JapaneseName

This field is used to display a location's Japanese name in the Yume 2kki Explorer for Japanese-language users.

For Yume 2kki maps, you must fill in the JapaneseName field. Use exactly one value, which is the map's original name written in Japanese. Do not add multiple values to this field.

If the map's equivalent name is available on the JP wiki, use the name provided there.

If the map is counted as a sub-area on the JP wiki, include the parent area's name, separating the names with the ： full-width colon. Use the format "[Parent area name]：[Child area name]".

6.1.2 Name

If a map's original name is not the same as the name used on the wiki, provide the map's original name(s) in the Name field.

If the map's original name is already listed in the JapaneseName field, do not list it again in the Name field.

If necessary, provide a romanization and/or translation of the map's original name, separating each item with a comma. For example, "Madotsuki no Heya, Madotsuki's Room".

6.1.3 Connections

The Connections field (and RemovedConnections field) of the Locationbox template makes use of the Connection template for each connection. The parameters are explained in the template documentation. For a full guide, see Help:Connections.

6.1.4 BGM

The BGM field must use the BGM template.

The title of the BGM is usually the name used in the game files. The filename is instead the name of the uploaded audio file on the wiki. More information can be found on the template page.

BGM field syntax:

{{BGM|title = examplesong|filename = game_examplesong_100.ogg|label = Plays in a subarea|soundroom = 008C}}

For more details on naming and uploading files to Yume Wiki, see Section [section number, with link].

6.1.5 Authors and Contributing

The following guidelines apply to games with multiple authors, such as Collective Unconscious, Muma|Rope, Uneven Dream, and Yume 2kki.

6.1.5.1 Authors

[Define an "author"].

Always use the original capitalization of an author's name, but do not include any special characters that are usually omitted from page or category names.

6.1.5.2 Contributing

If an author has made additions to an existing map that isn't theirs, or has only implemented a map by proxy without actually "authoring" it, that author should be listed in the Contributing field.

6.2 Maps

Insert all world maps intended for use in navigation by using the LocationMap template.

Image editing and digital painting software such as GIMP and Medibang are free to use. See help on creating location maps for more advice.

6.2.1 Labels

Add labels to all important features on the map. Important features include:

• Connections to other worlds
• Connections to subareas
• Notable NPCs
• Events
• In-game collectibles such as effects, menu themes, items, wallpapers, etc.
• Other points of interest

Do not include badges in map labels.

There is no need to include wallpapers or other collectibles obtained simply for entering a map. Only include collectibles that require players to reach a certain location on a map or to perform an action at a certain location on a map.

6.2.1.1 Label Formatting

Labels are usually white bubbles with black text.

For accessibility reasons, avoid the use of color-coded text to convey information.

If the text is not black text on a white background, ensure the color contrast is high enough for the text to be easily readable. This tool by WebAIM can be used to check contrast ratios between two colors. We recommend a color contrast ratio of at least 4.5:1.

Use a simple, easy-to-read typeface like Arial, Century Gothic, Courier, Times New Roman, or Comic Sans. Do not use decorative, calligraphic, or otherwise hard-to-read typefaces, such as Jokerman, Mistral, Chiller, or Papyrus. Do not handwrite labels.

6.2.2 Internal Connections

For maps with internal connections (such as doors, warps, screen transitions, etc.), all connections need to be clearly indicated. Do not omit connections that are not on the shortest/main path to a point of interest. A map must be usable no matter where a player is located on it.

Internal connections may be indicated by either using labels, lines connecting the two endpoints, or by using matching sets of symbols such as letters or numbers.

6.2.2.1 Labels

Labels are best used for locations with relatively few internal connections. All the advice for labels used for other purposes applies here as well.

If a map has a connection to a subarea that is mapped on a different file, use a label to indicate this. If an exit to the world is located in this subarea, indicate this too.

If the connection is one-way, indicate this as well.

If a connection has a requirement (such as effects, random variables, or some other prerequisite), indicate this with a label near the endpoint(s) this condition affects. If this condition is highly complex and cannot easily fit near the connection, expand on it in navigation instructions.

6.2.2.2 Connecting Lines

Connecting lines are best used for internal connections that are relatively close together. They are most useful for doors that are close together on the map, screen transitions where the screens are placed next to each other, and warps that are near each other.

Connecting lines between endpoints should usually be the same color throughout the map. Color coding these lines is usually superfluous and often confusing. The lines should contrast with the background enough to be clearly visible. We recommend a minimum contrast ratio of 4.5:1.

If the connection is one-way, this can be indicated by using a one-sided arrow. Two-way connections can be indicated using either double-sided arrows or a simple line. If a connection has a requirement (such as effects, random variables, or some other prerequisite), indicate this with a label near the endpoint(s) this condition affects. If this condition is highly complex and cannot easily fit near the connection, expand on it in navigation instructions.

As with labels, be careful not to accidentally cover important map features with connecting lines.

If two connecting lines are near each other or have to cross each other, using different dash weights for them can reduce visual confusion. However, if three or more lines are near each other, consider redrawing the lines or using symbols instead.

If the endpoints of a connection are far away from each other, it is not recommended to use connecting lines. Use symbols instead. If you find yourself making a map with several crisscrossing lines, or needing to draw long lines around the edges of rooms or the map itself, this may be a sign that connecting lines are not a good fit for these connections.

6.2.2.3 Symbols

Matching pairs of symbols such as numbers or letters are best used for maps with many connections, or for connections that are distant to each other. For example, if a warp pad connects to a distant warp pad on the far end of the map, you might place the letter A next to both warp pads.

It is best to enclose the letter or number within a circle or box. The conventions for label legibility apply to symbol text as well.

Do not indicate connections by using matching colored dots or shapes. Use text.

If the connection is one-way, indicate this. If a connection has a requirement (such as effects, random variables, or some other prerequisite), indicate this with a label near the endpoint(s) this condition affects. If this condition is highly complex and cannot easily fit near the connection, expand on it in navigation instructions.

6.2.4 Navigation Paths

For mazes, maps with many internal connections (such as teleport pads or doors), or maps that are otherwise difficult to navigate, draw navigation paths from the entrance(s) of the world to its important features, especially exits.

Do not use only color to convey important information about navigation paths. If navigation paths must be color-coded, include a legend explaining color correspondences. It is also recommended to use different dash weights to further differentiate navigation paths from each other.

As with labels, ensure the color chosen contrasts with the background enough for the navigation path to appear clearly. We recommend a color contrast ratio of at least 4.5:1 here as well.

Additionally, if you use color-coded branching navigation paths, ensure that branches contrast with the colors of the navigation paths they are connected to. In general, prefer red and blue or black and white over other combinations of colors for the sharpest contrast.

Avoid juxtaposing red with orange, brown, yellow, or green wherever possible. Similarly, avoid juxtaposing blue with violet or green. These color combinations can be hard to distinguish for people with red-green colorblindness or blue-yellow colorblindness.

Be careful not to accidentally cover important features of the maps or labels with drawn paths.

6.2.6 Editing Maps

Although maps are ideally as accurate to the game as possible, readability takes priority. Remember, an unreadable map is useless.

You may edit the appearance of maps to make their content more clear.

This includes:

• Changing the background from the parallax background to a solid color. This is recommended if the background is cluttered or makes it difficult to distinguish between foreground and background objects.
• Dimming or desaturating bright panoramas or maps. This is recommended for very bright or pastel maps where it can be hard to create contrast.
• Dimming useless paths in mazes. This is recommended for mazes of dense visual complexity. However, make sure that the dimmed paths are still readable so a player can still use the map if they wander off the path.
• Circling or otherwise highlighting notable content that is hard to see. This is recommended for large maps or maps with dense visuals.
• Moving rooms around to better draw paths between them. This is recommended for maps where the rooms are arranged extremely non-linearly, but connect in a linear fashion.

6.2.7 Older Versions

Maps that are included for trivia or other purposes, such as maps of older versions, do not have the same policies as described above, and should not use the LocationMap template.

6.3 Directions

6.3.1 Priority

When listing the directions to an area, list the shortest possible path (in terms of worlds visited) that does not require any prerequisites (e.g. effects or unlockable shortcuts) first.

If there is a shorter path that has prerequisites to reaching it, it should be listed in addition, specifying what would be required to follow that path.

There may be even more alternate paths for worlds with multiple shortcuts that rely on different prerequisites to become available. If these exist, list them too.

If there are multiple paths tied for the shortest length, list them all.

Example:

Nexus → Location A → Location B → Location C → Location D → Location E

*With the <effectname> effect equipped:
Nexus → Location A → Location X → Location E

6.3.2 Formatting and Links

All world names in the "Directions" section must be links to the location pages, excluding the initial location (usually the Nexus) and the location the article is about. This applies even if a world name appears multiple times across the multiple paths.

Do not bold any location names in the section, with the exception of locations at the end of the path (Location E shown in the example, commonly seen on pages for Yume 2kki worlds).

6.4 Location Categories

The Locationbox template used in location pages automatically inserts the appropriate Locations category for that game, as well as inserting the primary author's category if one specified.

Locations that currently connect to the game's Nexus (or Nexus equivalent) should be categorized under the wiki's specific Nexus Worlds category.

Locations must be categorized under the wiki's specific In Development category if a future update to the world is confirmed.

Removed content of any kind should be under the wiki's specific Removed Content category.

7. Media

7.1 Images

7.1.1 Image Properties

Screenshots of games must be at least 640x480 in pixel size. Replace screenshots that are smaller.

If possible, scale the screenshot to a multiple of the game resolution to avoid blur or artifacts.

7.1.2 Image Filenames

Filenames of images should describe what they contain, but should be short enough to be convenient.

Avoid generic names, such as connection2.png, which make the file hard to use and keep track of. Choose a name for the file that is unlikely to be chosen for any other purpose. Abbreviating the game name or world names is a common way to make the name short but unique.

Although there is no current rule on case, Title Case and lowercase see common usage. [?????????????]

Do not use filenames that are vulgar or insulting.

7.1.3 Captions and Alt Text

7.1.3.1 Captions

Humorous captions on images can be acceptable, but if useful information or descriptions can be given instead, skip the joke and provide that information.

YumeWiki strives to be both informative and professional first and foremost, so practice good judgment in caption selection.

7.1.3.2 Alt Text

Where appropriate, use alt text describing the contents of an image for readers using technology like screen readers.

Good alt text typically

• Is 1-2 sentences
• Is written in clear, neutral language
• Only focuses on the most important features of the image, rather than describing everything in detail
• Doesn't begin with "image of" or "picture of"
• Has proper punctuation, including ending in a period
• Doesn't contain text that is adjacent to the image in the article

7.2 Audio

7.3.1 Audio Properties

BGM tracks uploaded for use in Locationbox and soundtracks must be edited to meet the following requirements:

• Speed (along with pitch) must match the in-game track.
• The file must be converted to the .ogg file format.
• Looping tracks must be extended to at least 1 minute. This is not needed for full-length tracks or those that do not loop.
• Do not add fade in or fade out.

BGM uploaded for other purposes, such as trivia, must also follow these guidelines.

SFX should also be edited to match the speed in-game, unless the purpose is to show the original file for comparison.

7.3.2 Audio Filenames

All audio files uploaded to the wiki should use the following format:

[game name]_[original name]_[speed].ogg

For example:

Yume_Nikki_【FC】BGM_003_90.ogg

• Yume Nikki is the game name as written on the wiki
• 【FC】BGM_003 is the original name in the game files
• 90 is the speed setting used in-game (meaning 90% speed)

If the speed is unchanged, the filename should still have _100 appended. In MediaWiki, spaces and underscores are interchangeable.

It is not recommended to move or rename any already uploaded file to fit this naming scheme, because any page using the file would also need to be updated afterwards.

Animated Media

Exercise caution in including animated images and videos, especially those containing rapid flashes. It can distract or annoy readers, and is especially a problem for any readers with photosensitive epilepsy. Consider using the Photosensitive Epilepsy Analysis Tool (PEAT) to test if the animated content is safe for viewing given such conditions. An additional guide can be found here. It may be necessary to hide the flashing image under a collapsible section with a clear warning of the contents.

Galleries

Pictures in galleries should be present in the current version of the game or else moved to the "Trivia" section in accordance with Outdated or Unused Content.

Normal galleries are usually preferred over slideshows. The MultimediaViewer feature allows users to interact with the gallery as a slideshow, and is enabled by default, making slideshow style galleries redundant.

Media Categories

Currently, there is no site-wide standard for file categories. There is a suggested structure for images that has limited use in the Amillusion wiki, but this has not been formally adopted. For now, files are not expected to have any categories on their pages.

Outdated or Unused Content

Outdated or unused content should go in the "Trivia" section of the article if it may interest users, or else be removed completely. Images showcasing outdated content, such as old screenshots and maps, may be included in a subheading titled "Old Images" under "Trivia," separate from the main "Gallery." However, placing these images in the normal gallery is still accepted, and may be favourable if there are only a couple images.

If a location is removed, update the connections of that location to be removed connections. This includes updating the connections from other location pages to the removed one. In the article's introductory paragraph, note that the world is removed. There is also a VersionRemoved parameter in Locationbox that must be added.

In addition, if you are writing a page for a location that has already been removed (for example, the page Yume 2kki:Droplets World was written long after the world itself was removed), you should use past tense. Changing all the tenses from present to past in a location page that was removed later on is not an urgent matter, but does improve the article.