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)

Strong thought #1 is on spoilers, so let me share my thoughts on them.

The wiki has the same main goal as any other, which is providing as much information as possible.

There was previously no given reason for people to add spoiler tags.

People added spoilers for:

• Endings
• "Endgame" content
• Unlockable content
• Rare events
• Hard to find rooms/passages
• NPC interactions
• Trivia that related to the nature of a location or character
• Theories that had implications on a character or world's theme

Without a consistent reason for adding spoilers, they become literally useless - what is "too much of a spoiler" on one page is "normal info" on another. A consistent rule has to be made. Consistency - consensus - is a fundamental of a wiki.

So, when it came to whether spoilers should be allowed, why was the consensus - at the time - to remove them? The reason was that hiding information on a website that is solely maintained to share information was seen as counterintuitive.

If you are reading the wiki, you are using it to gain information. If you are editing the wiki, you are using it to show information. The wiki is being run and maintained specifically for this. So we had no reason to believe that spoiler tags or warnings serve any purpose.

Speaking of tags and warnings: the latter is a bit less certain, because although we have a warning on the main page people aren't necessarily coming into the wiki from there. Perhaps we do need some kind of global spoiler warning. This is moreso a point of discussion than with tags.

Of course if anyone has a reason to keep spoiler tags, that can be consistent with the purpose of the wiki, they should share it.

--ZASNK (talk) 17:55, 25 March 2025 (UTC)

I’ve been thinking of usage of spoiler templates that do not make reading and editing pages more difficult and I looked back to the Finnish Wikipedia (again). They add a text warning before a spoiler and a small text when the spoiler section is over. It’s used often when describing plots of movies or books. I don’t see why it wouldn’t apply to the plots of video games and on more unconventional games like these it would apply the most to Endings, Events or Main character pages.

The template page for Malline:Juonipaljastus and in action on The Legend of Zelda: Ocarina of Time Story

• Warning: the following writing reveals details of the plot.
• Spoiler reveals end here.

It doesn’t interrupt reading of the text by hovering over spoiler blocks or opening collapsibles and it doesn’t have accessibility concerns. I agree that templates with these issues should not be used as I've had hard time reading information using them before. Besides having three different spoiler templates on the same article is excessive. As for consistency I would limit the use of it to full sections since it would look awkward mid-sentence on a regular location article’s description.

My suggestion for meeting a middle-ground is to keep using the current Template:SpoilerWarning banner template on appropriate articles (Endings, Events, Main Character pages, possibly more) but make it less loud by making it look like regular text with an indention. The text of our template can stay the same. --Uksi (talk) 19:18, 25 March 2025 (UTC)

I was thinking a lot about what you wrote and I like the suggestion of the new spoiler warning. I think mainly the problem is we would need a concrete definition of what counts as a spoiler and what doesn't. Allow me to ramble a bit here:

On the Yume Nikki:Jellyfish page (at the time of me writing this message) the page casually mentions that the Jellyish appear in the ending. Would this be a spoiler of the contents of the ending? The page then has a spoiler warning for the section interpreting their role in the ending. I admit this one I agree with warning about. We could remake the spoiler section templates to act like your suggestion. But there are still concerns. Should the Ending page have a warning? The page is literally titled "Ending", its of course going to talk about the ending. What is the warning for in that case? Then some people argue that the ending page shouldn't have a warning for the whole contents, but the section explaining the ending itself should be hidden - despite being a major feature of the page. They say only the condition should be visible with no warning. Does this make sense to do on a page that exists specifically to explain the ending? Then we have cases where the ending is talked about often because of postgame content. If I'm playing .flow, I can eventually unlock Rust. Why is the wiki acting super secretive about this second part? It's a major part of the game. Yet all mentions are spoilered because it happens after the first end. Does it make sense to spoiler half a game on its own wiki? On another topic, why do events need a warning if the point of an "Events" page is to list all the events? Or should events related to the ending have a warning, but not the rest?

I think we need to address spoilers in order of:

1. What counts as a spoiler?
2. When should it have a warning?
3. How should we warn about it? → You addressed this part, and I do like what you suggest.
4. Are there any consistently identifiable exceptions to possible spoiler rules? (For example: if an ending unlocks post-game content, it's then fine to talk about the ending. Just an example.)

I know this is a lot I'm saying all at once, but this is really an issue for a lot of pages, so I want to say everything I can. --ZASNK (talk) 20:45, 25 March 2025 (UTC)

In response to ZASNK's message above me. It seems my approach to usage of spoiler warnings has been misguided as I thought they fell under spoiler tags too which are to be removed. While you liked what I suggest I’ve been rethinking the suggestion of a simpler spoiler warning template since endings are described much more concisely on Yume Wiki than a multiple paragraphs long plot synopsis of a video game on Wikipedia. On Yume Tsushin:Endings the big images are more visible than a small spoiler warning would be. The current template draws my attention better. But we could always have two. You make a lot of good questions I don’t know how to answer and should be decided collectively. For the Jellyfish page a smaller spoiler template would fit better and the player who hasn’t seen the ending doesn’t know what role they play in it. It’s meaningless information to them.

Yume Nikki’s Ending spoilers is simple while the Yume Tsushin Endings spoilers mentions the conditions in the actual template.

• "ENDING SPOILERS AHEAD. DO NOT READ UNTIL YOU HAVE COLLECTED ALL THE EFFECTS."

If we ever reach a conclusion on spoiler rules it should be specified on the style guide. This is an open point adressed on the cheatsheet and the :::main style guide doesn't talk about the spoiler warnings.

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

I think the part "spoiler warnings — are usually unnecessary" and the negative reaction lead me to a conclusion that we wouldn’t mark spoilers at all in the future. And I wasn’t sure what the top page means: is it the home page, the namespace home page or each location space. --Uksi (talk) 00:06, 26 March 2025 (UTC)