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)

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)