YumeWiki talk:Style Guide

Epilepsy protection

also wait epilepsy protection was a thing? this one tho uhh  ~prod|zpod 17:47, 19 November 2023 (UTC)

I hid it under a warning. Thanks for pointing it out. There should probably be a system for this sort of thing. --ZASNK (talk) 01:43, 20 November 2023 (UTC)

Rewrite

The Style Guide has been rewritten by User:Selva after a long effort and with a bit of discussion from, in my own words, some of the more nerdy editors. Selva has also written a cheatsheet intended to be spread in several of the yume discord servers, which I've copied in case someone is looking here for a summary:

Style Guide Change Cheatsheet

[Show/Hide]

Introduction

The Yume Wiki has made some big changes in the Style Guide over the last month and a half. Some of them are to prevent issues we foresee coming up, some are to fill gaps in understanding, some are to clarify positions we’ve long held, and some are to address issues that have occurred or are still ongoing.

While we hope every contributor to the wiki becomes familiar with the contents of the Style Guide and adheres to its guidelines, we understand that realistically, this is not going to happen, especially now that the document has ballooned in size. Regardless, we still strongly recommend all contributors read the entire thing.

This document provides a brief overview of the changes we’ve made.

1. Spelling and Typography

We built this section out a fair bit to answer some inquiries or issues we’ve run into over the years, in addition to filling in a few gaps. Most of the changes here are minor, involving things like punctuation, capitalization, and spacing.

The most important changes are the following:

• Try to avoid using abbreviations where you can (unless those abbreviations are really common, like DNA or NPC or something like that). Don’t use Latin-style abbreviations like “i.e.”, “e.g.”, “n.b.” (etc. is okay).
• Use italics to emphasize things, not bold or all-caps or stuff like that.
• Quoted text should be as close to the original text as possible. There’s a lot of new detail on the best way to handle quoting text. Check out Section 1.8 for specifics!
• We expanded our standards for how to handle writing numbers to try to solve consistency issues we’ve been seeing, especially when it comes to writing out currency.
• The general rule is that numbers above 20 should be written as numerals (unless they can be described in two words, like “ten million”), and numbers when used before units or as part of a time or date expression should always be numerals. See Section 1.10 for specifics!
• We have adopted the Revised Hepburn romanization standard as our standard for romanizing Japanese. This means putting macrons over most long vowels. Long o should be romanized as ō, not ou.
• We also want to remind everyone that machine translation for romanization or translation is not acceptable practice. We’ve seen a few cases now where Google Translate or DeepL was clearly used to translate a location name, with limited success. Please don’t do this.

2. Grammar and Usage

This section is pretty short, but discusses things like tense and pronoun use. There aren’t many changes from the original Style Guide, but the main points are as follows:

• Only use the third person when writing articles. That means not using “you” to refer to the reader!
• Make sure you clearly differentiate between something happening to the player character and the player.
• In general, use the present tense, except for content that’s no longer available.
• Avoid using contractions like “can’t”, “don’t”, “they’d”, etc.

3. Tone

A brand new section about the kind of tone we’d like to see from articles. There are some important changes in here, and we’re going to prioritize issues with tone when we see them.

The last section (3.8) is especially important, so be sure to check it out.

An overview:

• We want articles to be neutral. In a nutshell, this means that articles should be written in an unbiased, unemotional manner. This means we want to avoid telling the reader how to feel about information; for example, we don’t want to use “surprisingly” or “interestingly” to talk about facts, and we don’t want to call maps “beautiful” or “impressive” or other adjectives that are just puffery.
• We want articles to be professional. In other words, articles should be written to the same standards you’d write a paper or business email to. That means no slang and keeping the jokes restricted to image captions.
• We want articles to be clear. Basically, write in plain, easy-to-understand language with straightforward sentence structure. There’s no need to overthink it or get too fancy.
• We want articles to be precise. Be specific when you’re describing important information like unlock or trigger conditions. Mentioning something has a 10% chance is always better than just saying “sometimes”.
• We want articles to be direct. That means avoiding unnecessary phrases or pointless qualifiers like “seems to be”. It weakens your writing and pads out the length of sentences.
• We want articles to be inclusive. Use the correct pronouns for characters and use gender-neutral language when possible. Don’t be a jerk.
• We want articles to be detached. They aren’t textbooks or personal essays, and the “narrator” of an article should be “invisible” to the reader. We also want to avoid saying stuff that makes assumptions about what the reader knows, like “obviously”, “clearly”, “of course”, etc.
• We want articles to be grounded. That means they should only contain uncontested or sourced facts, not speculation. We’ve upgraded our verifiability standards to reflect this. Sources of info not directly found in the game or the games’ files now need to be independently verifiable, found in a public place off-wiki and able to be archived using the Wayback Machine. Basically, if there’s a claim being made, people need to be able to verify it themselves by looking at a snapshot of a good, reliable source for it. Otherwise it’s a little too easy for people to just make stuff up, unfortunately.
  • From now on, fan theories will not be allowed on the wiki.
  • If we repeat developer statements on their work as official, those statements need to meet our verifiability standards. Because of this, we will no longer be accepting screenshots of Discord chats as valid official sources.
  • Developers should edit articles about their work to correct minor inaccuracies, but we strongly discourage the practice of sharing new details about your work via editing the wiki.

4. Links

There are basically no major changes to this section. It may be worth re-reading if you need a refresher on when and how to use links.

5. Titles and Article Organization

This section deals with the content, naming, and layout of articles. We’ve added some new restrictions here to deal with a couple of issues that have come up and to preempt issues we really hope we don’t have to deal with.

The big changes are as follows:

• We now have a list of stuff we don’t want as articles (Section 5.1). The general gist is that articles should be factual and explanatory in nature and about a specific topic. Don’t use articles for personal use, please.
• Don’t use your personal user page to build out a website or blog.
• Article titles should be concise, natural, and easy to search.
• The characters #, <, >, [, ], {, }, |, _, ?, & cannot be used in article titles.
• Developers still have the right to request an official name be used on the wiki for in-game content, but we now have a few restrictions to avoid headaches or usability issues. See Section 5.2.3 for more info.
• We added a few links to page templates.

6. Location Pages

This section deals with the Locationbox template and making maps. The practices for the Locationbox template haven’t changed much. However, in response to numerous complaints about the uneven quality of maps on the wiki, we’ve put some guidelines in place for making new maps, located in Section 6.2. If you’re going to make maps, please read this section in full.

Here are some of the highlights:

• All important features on the map need to have some kind of annotation.
• Labels should be easy to read and typed, preferably in a bubble of some kind.
• Color coding should generally be avoided due to the accessibility issues it causes.
• All internal connections need to be included on a map, not just the ones on the main path.
• Giant long connecting lines between warps are now considered poor practice.
• From here on out, the practice of marking internal connections using color-coded dots is abolished.
• Instead, we prefer to use letters or numbers to mark warps.
• Color contrast ratios should be a minimum of 4.5:1 for any kind of navigation path.

There are many more guidelines about map-making practices not listed, so be sure to read them all.

7. Media

The main changes in this section involve the properties of images uploaded to the wiki, particularly screenshots. The basic changes are as follows:

• Players should not have effects or masks on that drastically alter the player character’s appearance, especially if those masks could be confused for another character.
• In all games that are not Collective Unconscious, other players from YNO should not appear in any screenshots used in articles.
• For multiplayer CU screenshots, nametags must be turned off, the image needs to mention there are other players in its caption, and the presence of other players shouldn’t be confusing or undermine the image’s purpose. If the image is supposed to show where an NPC is located and there’s 30 Minnat in it cluttering the screenshot, that is a problem.
• Image filenames should be neutral and easy to remember and search. We’ve had a few issues with people putting jokes or insults in image filenames now, so we felt it was worth telling people not to do this.
• Images should have alt text. We have guidance on good alt text in Section 7.1.3.2.

8. Outdated or Unused Content

This section’s guidance has not changed, but it has been reorganized to make it easier to read and understand. It’s worth checking out if you found this section hard to follow.

9. Miscellaneous

A section for a few miscellaneous guidelines that we couldn’t fit anywhere else.

Important stuff:

• Keep markup consistent and predictable between pages. Fulfill your urge to write a wiki article in Zapfino elsewhere.
• Don’t use colored text in articles. For colored text in infoboxes, make sure it has a 4.5:1 color contrast ratio.
• Don’t hide article text under collapsibles, spoiler tags, scrolling lists, making the text color really hard to read, etc. We will likely have a disclaimer on spoiler content near the top page in the future, but we’ve found that spoiler warnings and hiding spoiler content are usually unnecessary, hard to enforce, and make reading and editing pages more difficult.
• That said, we will likely formulate some policies to make sure people aren’t getting spoiled from looking up information totally unrelated to endgame content.
• Don’t put important article text in an image. If that image fails to load, users can’t read part of the article.

Conclusion

This revamp of the Style Guide was the result of nearly two months of hard work by several regular, active contributors to the Yume Wiki. We hope that it is informative, clear, and improves the overall quality of the average page on the wiki. The full Style Guide can be found on the front page of the Yume Wiki for your perusal at any time.

Thank you for taking the time to read this overview.

Wow, even the summary needs a summary. The gist is: stuff we knew was right is written down, stuff we knew was wrong is explicitly banned, stuff we used to allow but shouldn't ever have should now be changed, and ultimately editing the wiki is the same. Unless you make maps, in which case may the Lord help you (and I mean that seriously).

Really I just want to break the ice on the discussion of this awesome new style guide. If anyone has any strong thoughts, say them here! --ZASNK (talk) 06:31, 24 March 2025 (UTC)