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)

should’ve chimed in sooner, but generally i don’t think many users get much use out of spoiler tagging on the wiki. in my opinion, descriptions of endings and extremely important events (like, FACE probably? i’m not being very helpful), but otherwise, they really just make things harder to read --Gusterrr (talk) 23:23, 27 March 2025 (UTC)

User:Nekosoul has written a response to the rewrite, unfortunately off the talk page. I have copied the response here:

I strongly disagree with some of the changes laid down in the new style guide, and I'll be expressing my opinions below. This change arrived very suddenly and on short notice, and I've seen basically only backlash and very few points to defend some of the changes. Overall, it feels like the general public (You know? The people who are the most impacted by these changes?) were only informed of the new style guide AFTER it was implemented, while the decision itself was taken on the Wikicord, a place with, at the time of writing, 84 members (of which not many likely contributed to the change), a place which is practically never even as far as mentioned on yume.wiki and doesn't even appear in many "link channels" like #the-nexus of the Yume 2kki International Discord.

1. Spoilers

According to the new style guide, spoiler text should be removed in most instances, as they are "unnecessary". Bear with me here for a moment:

You are a Yume 2kki player experiencing the game in the 'intended' way-you only ever visit the wiki if you happen to be stuck in a place for hours or to check if a route continues past a certain point. You do not know who Wataru or 710 are, and you may not have all effects even after dozens upon dozens of hours of playtime. You arrive in board game islands for the first time, and, after enough exploration you start to wonder whether there's anything left to explore. What would you rather see when opening the wiki?

a. "Using the dice effect at any point while in the area will cause canned applause to play. If the Dice's red eye is revealed (random chance upon rolling), ||spoiler||"

b. "Using the dice effect at any point while in the area will cause canned applause to play. If the Dice's red eye is revealed (random chance upon rolling), spoiler"

One makes you curious for the effects, and does not spoil the surprise. The other immediately does.

The argument of "You are using the wiki to gain information, not for information to be hidden from you" is flawed. Imagine your friend just watched a movie you are looking forward to, and you ask them how their experience was. By that logic, it would be totally okay for your friend to instantly start talking about all the twists, plot and ending of the movie, since if you weren't looking for the information you wouldn't have asked your friend.

The only understandable reason for global removal of spoilered text is the 'accessibility issue'. Now, although I have personally only now heard of this issue, and have never once seen an actual case of it occur, apparently spoilered text is simply not shown on some devices. While extremely uncommon, this IS indeed quite impactful, but the approach to remove all spoilered text because of it is completely wrong. You're tarnishing the experience for EVERY reader in favor of an extremely small minority (who will also have their experience tarnished because they're also getting spoiled...)

1.5 Why do you edit wikis?

Earlier, I mentioned how this decision was made by a small group of wiki moderators, administrators, and prominent members. *They* believe these changes are beneficial, but I want to ask: who are these changes for? The experienced moderators, or the players? Since this decision was taken within a small group of people who are either veterans of the fandom or fangame developers themselves, how can it be expected to serve *everyone*? Again, this was only publicly stated after it was decided, so the readers, the people who should be the ones making this decision, were left in the dark. People don't edit the wiki for themselves, they edit it for others. Readers find something new and add it so others can know it too. Moderators and Administrators have absolutely 0 rights above any other reader, and are simply volunteers which maintain order. They should not decide things for other readers. A wiki is not a place which can be "owned", it is a collaborative webpage for everyone, so changes should be discussed with players as opposed to groups of experienced editors (to contact the "players", a banner on the main page of yume.wiki which leads to a talk page or something could work)

2. Fan theories

From the perspective of someone who would literally never read a fan theory, the global removal feels like an odd choice. Maybe just add them under a specific category? The 'protagonist' page on the main page of pretty much every game seems like a good place, listed under a "fan theories" dropdown or something, though I do agree that fan theories shouldn't be listed in world pages.

The whole "Developer sources must be credible" thing feels a bit excessive though, like I know it's made with good intentions but discrediting everything developers say on Discord (which also happens to be the only place to contact a lot of developers) is a bit much?

3. Tone&format changes

I find this one to be justified, but the 'neutral, emotionless tone' feels a bit jarring here. There's a reason for why the 'impersonal, no hearsay' tone is common practice on wikis, but on a wiki for Yume Nikki&Fangames it just feels out of place. Say, what feels more fun to read?

a. [x] is a beautiful and massive swamp-like world, with glowing fireflies and detailed trees;
After witnessing this surprising event, you'll end up in an area clearly referencing Yume Nikki's ||ending||;

b. [x] is a world shaped like a large swamp, littered with fireflies and trees;
After witnessing the event, the player will arrive in an area reminiscent of Yume Nikki's Ending;

The second one sounds more ""professional"", though I myself would rather actually get a detailed and pure, human description compared to a 12th grade physics textbook.

Key points:

• Spoilers should stay; regarding the accesibility issue, maybe contact MediaWiki about it? In the worst case scenario, we could swap some spoilers out for dropdown boxes;
• Changes to yume.wiki should be properly discussed with the readers the wiki is for, not dropped out of the blue by veterans;
• Instead of straight-up removing them, maybe fan theories could be moved to their own page under the 'protagonist' page?
• While the neutral tone is more proffessional, we're a fan wiki for funny dream games, not Wikipedia. I find a pure and factual tone to be much better as opposed to the 'emotionless' one.

Also, as a suggestion to ADD something to the style guide, if it's not already there, I always found the layout of the bottom of pages to be quite jarring, since the 'Old Images' practically always come before the "Gallery" part. I'd suggest we move the old images UNDER the gallery, since having them as the first photo gallery you see can be confusing, and it's weird having a large collection of images separate from the actual Gallery.

Example: https://yume.wiki/2kki/Night_World

Example of a page I edited a while back to have a more clear gallery: https://yume.wiki/2kki/Cog_Maze

Again, this response is by Nekosoul, not myself. --ZASNK (talk) 14:33, 26 March 2025 (UTC)

Going to respond to this step by step.

First paragraph: When we first started the rewrite we put up a post proposing the removal of theories. This is in the Community page linked in the menu tabs (available on every page). It received only two responses. Both users were in the Yume Wiki Discord. Additionally, the Discord is linked from the Main Page, which is the most visible page on the wiki. Regarding backlash: I have not seen any, which tells me it must all be contained in the Yume 2kki Discord, the only Discord I am not in. If people there do have things to say, they are welcome to say it as you did. Thanks, by the way. You also mention this communication issue in point 1.5 so consider this a response to that as well.

Regarding point 1: Spoilers: Very interesting you use Board Game Islands as an example. That part you suggested to be hidden, is not hidden on the page. People interpreted the whole event as something major enough to be kept visible. Somehow, the other, related event was interpreted to be too much of a spoiler and was put under a collapsible section. This is despite it also being a major event in the world. And then this page also happens to spoiler tag the - quite normal - NPC reaction to the Chainsaw effect, despite the vast majority of pages never hiding such info. The page you chose to use is actually a really good example of why we want to remove spoilers entirely. There are no rules on what is "a major feature of the world", what is "a secret event or interaction", what a player "wants to see", or what a player "wants to be surprised about". There is no consistency whatsoever. And this is a completely useless system if we don't have a consistent way to apply it.

As for why we decided to remove them entirely. Your reasoning for keeping them is contradictory to the fundamental of a wiki.

"You are a Yume 2kki player experiencing the game in the 'intended' way-you only ever visit the wiki if you happen to be stuck in a place…"

In what way is this "intentional"? Do the game developers design their game around Yume Wiki? And by what manner do you decide that people should be visiting the wiki only for a "first step" in guiding them further into the game? The wiki can be used by people like that, sure, but also by people who want to read about the world entirely without care for spoilers, and by people who want to explore it fully, and by people who want to learn more about the game as a whole, and by people who want to be inspired by the game - I could go on. Suggesting that the wiki should be written contradictory to its purpose of showing all relevant information, so it can cater to a very specific type of player, is not at all productive.

You also give an example of someone asking their friend about a movie. This is a wiki, not your friend. In the same way the Wikipedia page on a movie will have a plot summary, the Yume Wiki page on a world will have an event summary. In the same way a person opening the Wikipedia page will find all relevant information there, a person opening the Yume Wiki page will find all relevant information there.

What I'm getting at is: it doesn't make sense to turn the page into a friendly personal guide when it does not know who you are, does not know what you consider a spoiler, does not know what you want guidance for, and does not even know if you are here for guidance in the first place.

Regarding fan theories: the community post explains the problems pretty well, but in short: pages of speculation with no basis being hosted on a wiki of factual info is contradictory and misleading. It has misinformed and misled people already.

"…discrediting everything developers say on Discord (which also happens to be the only place to contact a lot of developers) is a bit much?"

I agreed with this actually. I didn't like how Discord was being removed as a source for the same reason you mention. I was however assured that this did not mean the information couldn't be written down at all. It just means you can't use Discord to prove something because it's not a public source. In the same way "the dev said so in a VC" is not a source because it's not provable.

Regarding tone:

"[x] is a beautiful and massive swamp-like world, with glowing fireflies and detailed trees;
After witnessing this surprising event, you'll end up in an area clearly referencing Yume Nikki's ||ending||;"

This is again a good example of the opposite of your point: calling the event "surprising" tells the reader how to feel and "clearly referencing" is suggesting the event is too similar. Impersonal tone avoids making suggestions to the reader; they can think for themselves. The rest of it, though, I think is fine. Although "beautiful" is also pretty subjective.

Ultimately the intention with the tone rule is to avoid subjectivity and sounding condescending, because trying to discern between issues like that and "flavor" is not worth the time and effort. It's not a "NO FUN ALLOWED" rule, it's a "Let's not waste our time fixing stuff that was supposed to just be fun" rule.

Last thing is your suggestion for old images. We had been putting it in trivia because that's where version history is included. Moving it to a separate gallery at the end of the "Gallery" section might be a good idea. I suggest proposing it in the community page as a change. I personally like the idea.

I'm sorry for the huge wall of text, I just really feel strong about these changes, same as you. I hope it's readable and I'd love to see a response from you, or from anyone else as well. And if you need to post a response off-site again I'd still be willing to copy it here. --ZASNK (talk) 21:03, 26 March 2025 (UTC)

Hi, I'm Nekosoul, I finally figured out how to write here lol

Regarding spoilers, I still believe that adding some grounded rules is better than removing them entirely, though I do understand that subjectivity will make almost every spoiler inconsistent between pages. At the very least, though, spoilers should stay when directly discussing endings (though simple mentions like "You must see [Ending] to enter this world" could do without spoilered text in most instances).

I also don't really find 'subjectivity' to be a huge problem by itself. I only find inconsistency to be an issue in very drastic cases, like in Yume 2kki's Sink Catalog, where one effect action is spoilered while the other isn't, and the former has its requirements listed UNDER the event itself so the spoiler is almost useless. I find it better to just directly edit these pages to make them more readable as opposed to removing spoilers globally because some pages don't use them well.

Other than that, I fully agree with most of your points, I just don't want the tone changes to outright ban calling areas "beautiful" or "simple", but instead simply discourage condescending phrases (which I actually see a problem with). --teo (talk) 10:52, 27 March 2025 (UTC)

Nice to see you here!

Adding grounded rules for spoilers is our main concern with them. Unfortunately leaving it case-by-case is going to cause too much disagreement. It's better for the wiki to come up with a global, hard rule for what counts as "good usage". For example I personally agree with hiding or otherwise obscuring ending spoilers on non-ending pages, such as how the Jellyfish page I mentioned does it. There is still much to consider, such as what should be spoiled - if anything - on the ending page itself. And even then, perhaps hiding how the Jellyfish appear in the ending is still too much, considering that is a major part of their characterisation and lore?

Hence why when writing a style guide to make a wiki consistent we agreed to axe the whole thing. If someone can come up with a good rule that we can all follow - and doesn't face major disagreement - we would need to add it to the style guide. Right now, though, one user would hide a sentence and another user would spoil it. We disagree too much on how to use spoiler tags and collapsibles.

I don't want to spoil the whole game for someone on a random page, but I also don't want to play a game of "is this an NPC reaction or an ending spoiler?" Nor do I want to hide half a page under a button that most people on the page would likely want to read anyways… would they be likely to read it?? ;-)

On the topic of tone, the rule is just to avoid judgemental or biased phrases, which these two words can be sometimes. Perhaps "simple" or "detailed" can describe the chosen art style, and "beautiful" can be a descriptor in contrast to the "harsh" style of some worlds. It's not outright banned, but it needs more thought. You don't want to make a judgement of the world on behalf of the reader, but you do need to describe it. I've seen people are mostly good with this anyways.

I hope I made my points clear. It's not that I'm entirely against what you say, more that it needs a lot more thought to develop into an understandable guideline for the style guide. --ZASNK (talk) 12:55, 27 March 2025 (UTC)

Just a heads up, I made a community post about the old images in trivia part since it has confused me before and I agree with you on it perhaps needing more thought. Feel free to read and continue the discussion on the topic here: YumeWiki:Community#Old Images in Trivia (mostly so it doesn't derail the spoiler conversation). Uksi (talk) 03:11, 28 March 2025 (UTC)

Spoiler policy

Splitting from the above topic about the rewrite as a whole, we want to focus on spoilers. This is a controversial issue and has been brought up multiple times. I want to a make clear post about the issue and an invitation for people to discuss it.

It should go without saying that decisions on the wiki are made by reaching an informed consensus through discussion. The discussion that led to spoiler text and sections being banned had major points in favour of that decision. I must mention that the majority of our wikis have a spoiler warning on their main page, and that the website disclaimer has one too.

The current spoiler policy is a global and consistent rule that follows the purpose of the wiki being a website dedicated to documenting all relevant information of YNFG content.

The inconsistency of the old spoiler methods was the primary reason for adopting the current policy. It was entirely subjective whether the wiki should show or hide an event, subarea, NPC interaction, puzzle solution, maze path, or mentions of the game's ending(s). It was also unclear why such content would be hidden in the first place. If a location has an event that relates to the game's ending, that would all be information that is relevant to the location, equally relevant to how the location is laid out (which is usually not spoiled). Sometimes content was hidden on pages entirely dedicated to listing said content. An endings page should be expected to have the content of the endings; a location page should be expected to guide you through the location; the events page should be expected to explain the game's events; etc., yet sometimes this was hidden too.

The argument for spoilers is that people might want to read only part of a page. Some readers would, for example, want the condition of an ending without a description of what happens. Users reading a location page might want to reach a puzzle subarea without seeing the puzzle solution.

The problems with this argument:

1. It is not possible to determine what a particular user would consider a spoiler or not, as people expect different levels of detail.
2. There must be global rule; an inconsistent application of spoiler sections would make it impossible for readers to know what content may be hidden. (e.g. it is not possible to know whether the hidden text near an NPC name is spoiling an effect reaction or the game's ending unless the spoiler is shown and read)
3. As a new spoiler policy would need to effect all content of a particular type — without any subjective interpretation — it may lead to compromises that call into question the usefulness of spoilers.

For example, if we decide location events should be hidden to keep Uncanny World's event a secret, then events such as Takofuusen would also need to be hidden, despite being much less "exciting". This is unless we also decide on a method of objectively measuring how much of a spoiler each feature is — this goes back to the problem of not being able to cater to all readers and their varied definitions of spoiler content. People naturally have different ideas for what is "secretive", "special", "exciting", or "surprising" enough to be considered a spoiler.

To summarise, the spoiler policy was adopted because spoilers were extremely inconsistent to the point of nullifying their own uses, and no consistent and objective rules for hiding page content on the wiki could be agreed upon. We felt readers would benefit more from knowing that Yume Wiki reliably covers all content, rather than playing a game of guess-the-spoiler with every page and reading pages organised by the subjective opinions of the editor.

I have so far written this message from the perspective of supporting the current policy. I want to be clear that the spoiler policy will change if a new consensus is reached. This means any issues with spoilers, such as the ones I listed, must be addressed. On the other hand, those who wish to keep the current policy need to properly consider the impact it has on readers of the wiki. Complaints about the current policy show that it is not suiting all the wiki's readers. I am sure everyone on the wiki wants the best solution, so I hope we can discuss this civily and reach an agreement, whatever it may be.

As a side note, I would like to mention that although the wiki's talk pages remain the primary method of discussion, much of the thought and decision-making has been made on the wiki's official Discord server linked from the Main Page. Real-time discussion is usually less formal and developed, but the fast nature means a lot more can be said. I do recommend people to join it if possible, but remember to still share your opinion here so it can be visible. --ZASNK (talk) 06:05, 3 April 2025 (UTC)

I also lean towards supporting the current policy but I think we need to reach a compromise for which I shared a possible solution under the topic above. You said ”I must mention that the majority of our wikis have a spoiler warning on their main page, and that the website disclaimer has one too." Another valid point that was brought on the Discord as well was that these are hard to see for users. Main page disclaimers are hard to miss but this is the first time I’m seeing the general disclaimer on this site. And even main page disclaimers are easy to miss if you access an individual article from any other way like a link shared by a friend or during an Yume Nikki Online Project session.

In the previous discussion I advocated for a spoiler disclaimer that doesn’t block page content used within page text.

• Template:SpoilerWarning

or a less disruptive example from Finnish Wikipedia.

• Malline:Juonipaljastus and in action on The Legend of Zelda: Ocarina of Time Story (Translation: Warning: Next writing reveals plot details. (text) Plot details end here.)

But since we have a lot of pages we could have a global banner about it as well like the one asking users to review the new guidelines. Besides spoilers it could mention flashing images, loud audio files, suggestive content or whatever else you want it to have. --Uksi (talk) 06:54, 3 April 2025 (UTC)

The spoiler disclaimer for sections has the same problem of inconsistency. I think it would still be a bad thing for the wiki to warn people about certain sections, unless there is a clear and understandable rule for what should have a warning. Even if that's possible, I believe it's redundant.
As for a more visible global disclaimer. One idea I have is to use the MediaWiki:Anonnotice message. It should display exactly like the site notice we currently have, but only for users that aren't logged in. It supercedes the site notice. Basically my idea is to give users that aren't logged in the anon notice which acts as a disclaimer for content. Meanwhile, logged in users are already familiar with the wiki, so it would be fine for them to see the site notice instead. Tell me if you think this idea can address your concern. --ZASNK (talk) 07:45, 3 April 2025 (UTC)

It might indeed be redundant. A global disclaimer would remove the need for any page specific spoiler disclaimers and possibly could make writing page content a lot more liberating. As for who sees a disclaimer, it might as well be shown for everyone since I don’t see any harm in that. The current style guide banner is not disruptive at all to me. --Uksi (talk) 08:04, 3 April 2025 (UTC)

Reiterating what I've said before here for transparency. So I do think we need some kind of disclaimer somewhere on the wiki just so we can say that we did do our due diligence. We do have disclaimers on the front page of most (not all, which should be the case) namespaces warning people that they may be deprived of an intangible and subjective "sense of discovery" by consulting the wiki, and advising that if they aren't okay with this, they ought to not check the wiki. In a vacuum, this is to me, sufficient; however, some users have pointed out that accessing the wiki through YNOProject, which I'm willing to bet money on accounts for most of our traffic, bypasses the front page and so that warning is usually unseen. A more visible warning needs to be somewhere.

Moving on, I think ZASNK has made more or less the same arguments I would make regarding the feasability of really aggressive and highly granular spoiler tagging policy. To summarize: A) It is extraordinarily subjective what should be considered a "spoiler", and it's very hard to write a workable policy that describes what one is in a way that can be consistently applied and isn't potentially thousands of words of weird edge case descriptions; B) once you hide content, it's fairly difficult to determine on the user end what's being hidden, and due to the aforementioned lack of consistency in what counts as a spoiler, the user has no idea whether a spoiler is safe to click; C) there's no consistent template for spoilers across the wiki, and all of them have their own issues and drawbacks for unclear benefit D) many pages with spoiler warnings on them should, to a sensible and reasonable viewer, contain spoilers, such as "Endings" or pages dedicated to describing the contents of events; adding spoilers would thus be redundant; E) choosing to mark something as a spoiler asks us to make a subjective judgment of content's excitement, mystery, or some other intangible quality of wonder, which falls afoul of neutrality guidelines (which I think are far more important for ensuring quality on the wiki, avoiding fanboyism, avoiding puffery, etc); and F) some content in games interacts so heavily with the game's structure that the only workable solution would be to hide massive amounts of article content in that namespace, which feels like it defeats the purpose of the wiki to begin with and makes for an unpleasant and clunky reading experience.

I'd like to also add a couple of other counterarguments here, namely G) I am uncertain how much the average user cares about this issue. Arguments have been made about affecting the average user experience, but notably, most of them haven't been from average users; they've been made by game developers, who obviously have a very different perspective and motivation for wanting their content hidden, as they would have an "intended experience" in mind they're approaching this issue with. This is not to say that these concerns are invalid, by the way, far from it, but this represents a minority view, and due to past incidents we've had, I'm wary of trying to tailor the wiki to force an "intended experience" on a user; this is not really the wiki's place to do.

Finally, I'd like to add H) We have technically already tried having spoilers on the wiki. We did not have a formal policy in place regulating it exactly, but we had nothing forbidding it, and editors tend to follow suit on style, which is a good thing (it means that I don't need to dictate exactly how every page needs to be laid out, as most regular editors are smart enough to infer that the pages they're editing should look like the other ones), but the upshot is that we had spoilers being put into place without being explicitly told to do so. The problem is that the system in place is a complete mess of questionable use to anyone. Granted, it's unregulated, but I'm having difficulty imagining a massive improvement without equally massive legislation. Selva (talk) 22:54, 6 April 2025 (UTC)

I will also be reiterating my thoughts on the matter.

As a YNO player, when I'm playing a fangame blind I avoid using the wiki as much as possible. The first wiki aspect I rely on is annotated maps -which I access from within YNO- whenever I feel I'm done with exploring a location blindly. If the annotated map does not have enough information I will start opening location pages and looking exclusively at the infobox for information on collectibles, events and connections. As a last resort I will open the effects and events pages and rely on the table of contents to know what I'm missing. If I can help it, I avoid reading what I don't want spoiled by only reading the bolded text first, but I understand this skill can vary from person to person.

When it comes to games with endings, I find that I always need to check the corresponding page to know the conditions of certain endings. Some games can have very obscure and non-standard conditions such as Mikan Muzou's Ending #4, Muma Rope's Ending #4 and If's Ending #3. This is my major point of contention with the current spoiler policy.

I avoid the wiki as much as possible and when I do use it, I expect to be accidentally spoiled. But when it comes to endings, I find there's not much I can do to avoid accidental spoilers and these are the ones that upset me when they happen. Like I've said, if it wasn't for the wiki I'd be unable to trigger some of the endings by myself and I find coming to Yume Wiki (and YNFG Wiki for that matter) is a better compromise than asking other players. If I ask other players, I run the risk of receiving more information that I bargained for but here in the wiki I can know what to expect, provided the pages are formatted equally. I also don't rely on player presence or availability so I can just check the ending conditions and move on with my day.

All this to say: I want ending pages to have some way to prevent players from accidentally reading paragraphs that narrate what unfolds in an ending. It doesn't have to be done with collapsibles or hover texts, I've previously proposed the idea of simply formatting the page so conditions are a separate sentence to the rest. It can be done similarly to how effect pages are formatted where there's a preceding text in bold telling you what you're about to read. I worry this might not be enough for some people however, so I think adding some empty lines to separate the condition from the rest of the text would also help. I was also proposed the idea of using headers instead, which I think might be a better choice. As for media: It would have to always be put below all text pertaining to its ending. Some ending pages such as Someday and Yume Tsushin currently have images aligned to the right, which makes it harder to avert one's eyes from. --NadaAfterwards (talk) 01:02, 7 April 2025 (UTC)