Talk:Main Page

From GodWiki
Jump to navigation Jump to search

This is the talk page for discussing improvements to the Main Page article.
This is not a forum for general discussion about the article's subject.

Article policies
  • Opinionated research if possible
  • Neutral point of view when appropriate
  • Humour
  • Verifiability
  • Be polite
  • Assume good faith
  • No personal attacks
  • Do not bite the newcomers
  • Respond in a mature manner
  • Be welcoming
  • Maintain civility at all times

This page has an archive

Old and/or inactive discussions have been moved to the /Archive subpage.

Encouraging use of user talk pages

So, I've written this message, which I'm thinking of going around and (manually) placing on the User talk pages of everyone whose User: page is redirected to the main-article space, to point out that they won't receive talk-page message notifications unless they use their corresponding user talk page.

(This covers two types of users:)

  1. Those with user talk pages like User talk:BlueStapler, User talk:Hershey Almighty, etc. that are redirected to Talk:BlueStapler, Talk:Hershey Almighty, etc.
  2. Users like User:Hairplug4men, User:EJ Rose, etc. with redirected User pages, who have no redirect for their user talk page.

Basically it's about 50 people, I have a whole list. Most of them are probably not active users, but I'd plan to contact them all regardless. If they never see it, oh well. If they do, then great.

I just wanted to solicit feedback before I start.

With Special:ExpandTemplates, you can see what the message would look like when it's placed on Djonni's talk page (as an example). Click the following url:

You'll see the formatted message at the bottom of the page. -- FeRDNYC (talk) 01:51, 17 February 2019 (UTC)

It seems some people keeps on redirect their user page to another page for some reasons, tried to leave messages but it don't seem to reach through. Well it's not really a serious issue but still happens. --WardPhoenix (talk) 16:03, 12 March 2019 (UTC)
Honestly, though, that's fine and if people want to do it then more power to 'em. (There are all sorts of reasons why someone might want to, including intending their user page to be editable by other people. That's the reason Djonni (talkcontribs) specifically gives on his talk page.) If people want to keep a "god" page in the article namespace, as long as it's properly categorized no harm done. It's only when the corresponding talk page isn't redirected back to User talk: space that there's a down side. But it works just fine to maintain a non-User:Foo userpage at Foo, with a Talk:Foo page that redirects to User talk:foo, and doing that means they won't miss notifications. -- FeRDNYC (talk) 20:49, 12 March 2019 (UTC)
Sorry, the example-message URL above was "down" for a couple of weeks, as I'd repurposed the page in question to do canvassing for the JanuWiki post-mortem and forgot to set it back afterwards. Anyway, it's working again now. -- FeRDNYC (talk) 16:54, 13 March 2019 (UTC)

Misnamed monster?

Does anyone have any thoughts on my rename suggestion for Space Invader? (Evidence appears to indicate that Personal Space Invader is actually the correct monster name. More details can be found in my article talk-page post.) All input welcome. -- FeRDNYC (talk) 01:09, 22 March 2019 (UTC)

I guess a page-move is the appropriate things to do if it's true. Don't remember seeing that monster in both name so i trust you on the matter. --WardPhoenix (talk) 13:45, 22 March 2019 (UTC)
Pretty sure that you're right, FeRDNYC. I've never seen it as just a space invader. -- SourceRunner (talk) 20:23, 23 March 2019 (UTC)
Thanks all. I've moved the article, updated it for the new name (superficially; it's still pretty much written about "space invaders" the game and could use a reworking), and corrected the relevant list articles and redirect targets. -- FeRDNYC (talk) 06:08, 26 March 2019 (UTC)
Had to happen eh.
!Hero's Diary
18:49 Stood over the slaughtered Space Invader and delivered a heartfelt requiem for its departed warrior soul. I then looted 6 coins and a recovery disk from the twitching corpse, which I think is a fair fee for a requiem these days.

I feel sorry for your edits. --WardPhoenix (talk) 17:51, 27 March 2019 (UTC)

Eh! Reverts and move-backs are easy. At least now we know, thanks! I'll incorporate your diary entry into the article as well, in place of the obviously-outdated one there. (...Ooh. Unless we think both Monsters exist?) -- FeRDNYC (talk) 09:21, 30 March 2019 (UTC)
I'd say there is a high probability that both actually exist. --WardPhoenix (talk) 10:41, 30 March 2019 (UTC)
Mmm, well I won't add Personal Space Invader back to List of Monsters yet since it redirects to Space Invader now (and will until someone replaces the redirect with an article). If we get confirmation we can at least stick a stub with a diary entry in there. -- FeRDNYC (talk) 10:46, 30 March 2019 (UTC)

Theming or Other Event Brainstorms

FeRDNYC makes a really good point above that two big events a year would be amazing, but that there's also opportunities for smaller events. With the basis that JanuWiki should now be an annual event, perhaps this should be a list of other event or drive ideas (big and small) that we could do, to figure out how we could space things to still get necessary stuff done. -- SourceRunner (talk) 17:37, 23 March 2019 (UTC)

  • JanuWiki 2020: Year of the WikiGnome/GodWikiStmas -- Big event. Next JanuWiki. Starts when? Ends January 31, 2020. Wrap-up ends February 29, 2020. Theming granularity? Process certainties?
  • Guidelines and Guide Resources Drive

(Please expand)

  • Easter Interlink Special -- Small event. EIS Eternal would be willing to sponsor a small wiki event during the Easter week or two weeks, with the object of adding links between pages on GodWiki (with reasonable reasons for doing so). One of the wiki strengths is the ability to create an ecosystem of lore, and the best way to explore that is following links between pages. So there could be the a specific event that GodWiki editors and content creators each chose a pair of pages to interlink, and write the lore between them that explains their relationships in the ecosystem and links the two. A report to the "Help Request" page when finished a pairing would make the pair's linker eligible for a reward of some sort after EIS checks that it has been done and does make sense.
  • Trans-Lore-Ation -- Small event. A lot of Godville lore is in the forums and tucked away in little sections of personal chronicles. As players, we in common tend to "know" this lore to be true, but not have it on GodWiki. How about a small event where people scavenger-hunt their favorite descriptions of towns, taverns, monsters, and Godville myths from the older parts of forums and the crannies of guild and personal pages, then add excerpts and possible links to the applicable pages in GodWiki.
  • Stub It Out -- Large event. Survey what articles with the "Stub" tag are still stubs, and remove tags where appropriate. Expand articles that are still stubs.
  • "Wherefore ART Thou?" -- Large event(?). Adding art to the "picture needed" category articles. Some artists need a long time to plan, so this may need to be a slow or multi-phase event.
Could be associated with the stub event maybe?

Sounds like there is some good ideas ready for the oven. I'd say that if you want to throw an event, just go for it. Create a page for it and allow us to help for the preparation.
Maybe we should make like a planner for upcomming events. By the way, talks about upcomming event may be more appropriate on the main talk
As for JanuWiki2020 (or GodWikiStmas maybe), I'd say we have the time to see it coming. Let's care of other event before.
--WardPhoenix (talk) 23:55, 25 March 2019 (UTC)
As another idea for a possible event (I don't even know if it would be considered big or small), Category:Pictures needed is up to 314 entries. That's 314 existing articles (primarily ones that use {{Monster}}, {{Artifact}}, or {{Equipment}}) which don't have an image to go with their subject. Trimming that list down a bit could also be a good way to get non-writers involved in creating wiki content. -- FeRDNYC (talk) 06:39, 26 March 2019 (UTC)
Oh, yes, and Category:Stubs is up to 552 articles that (in theory) need fleshing-out.
I say "in theory" because some of them may not really be stubs, having been expanded since they were tagged that way. In the "Advanced options" at the bottom of the appearance preferences is the option "Threshold for stub link formatting". It takes a length (in bytes) an article's source must be so it's not considered a stub. Links to all articles shorter than that threshold will be colored with a darker shade of red than the standard redlink coloring.
I currently have that preference set to 1000 bytes, and still some of the items in Category:Stubs are colored blue. It's certainly possible for an article that's over 1000 bytes long to also be a stub, but it's also possible that there's already plenty of content there and the stub designation is outdated / overzealous. I'd say maybe 10-15% of the category's members show non-stub link coloring. -- FeRDNYC (talk) 07:00, 26 March 2019 (UTC)
These are great ideas for events, WardPhoenix and FeRDNYC. I've added them to the bullet point list above, and tried to evaluate them as large or small, based on your descriptions. Please feel free to expand or change what's in the bullet list.
WardPhoenix, good suggestion about the planner/calendar for events. Is something like that possible in GodWiki, FeRDNYC? --SourceRunner (talk) 15:21, 26 March 2019 (UTC)

I'd say that if you want to throw an event, just go for it. Create a page for it and allow us to help for the preparation.
— User:WardPhoenix

I would agree with that, with one small adjustment: When you decide you definitely are throwing an event, creating a page for it would be the first step in preparing for it, and can serve as the formal announcement of the upcoming event.
I think Djonni worked up to JanuWiki 2019 exactly the right way (whether intentionally or by pure luck): He put out feelers on the forums and in a proposal here at Talk:Main Page, and used those discussions to solicit feedback and take the community's temperature on the idea. Then once he was sure there was sufficient interest that he could commit to definitely doing an event, he pulled the trigger on creating the event page, at which point he had someplace he could link to as a "more information" resource when he made the official announcement(s) about the upcoming event.
At any stage of planning, there's always the possibility that an event could end up getting cancelled for lack of involvement or interest. Things happen. But that risk can be minimized by getting at least a core team on board before putting a lot of work into constructing an event framework for a "maybe" or "possible" event. -- FeRDNYC (talk) 14:43, 27 March 2019 (UTC)

Moved this to the main page as it is more appropriate place and also easier to reach (yeah I'm lazy to reach for januwiki page every time on my phone). By the way I think the EIS event would be quite interesting, and as easter is coming i'd suggest we start thinking about it if you really want to kick it. On a side note, I don't think a guideline event would be appropriate. Guidelines are supposed to be wrote by experimented and active users for beginners. That's more something we have to work on with experimented users I'd say. -- WardPhoenix (talk) 23:02, 26 March 2019 (UTC)

That's a fair point, re: the Guidelines. I guess it depends how broadly you define "event". Certainly, you're right, guidelines-updates aren't the sort of free-for-all activity where we'd put out a call to the entire Godville user community for participation. Maybe "an effort", or "a sprint" (to employ some of my least-favorite software development jargon), among those experienced users.
That being said...
  1. A lot of what's lacking in the current Guidelines articles just comes down to formatting, copyediting, structure, and layout fixes — things that could be done by almost anyone, especially with guidance, as there's no real expertise needed. (However, as they also need major content updates, they're definitely not entirely fixable by casual editors alone. But they could be vastly improved.)
  2. Because (as you say) the target audience for the Guidelines is inexperienced users, in my experience it's a huge mistake to write them without any input from users at or near that level. One of the things I learned in software development is that you never have the senior programmer, the one who wrote most of the code and knows every aspect of the software inside-and-out, write the instruction manual. If they try, 90% of the time it'll end up being unintelligible to the "average users" it's supposed to be written for.

    (It's the same reason you NEVER sign up for a freshman-level "Intro to Whatever" class if it's taught by that department's most senior, most published, most brilliant researcher. Very few people whose knowledge of a topic is at that level will be capable of "dumbing things down" sufficiently that they can effectively teach it to students who have virtually no background in the subject. Everything will go right over their heads.)

The two trickiest problems in documentation don't have anything to do with knowledge or accuracy of information: The first is figuring out exactly where your target audience is at in terms of background knowledge and skill level, so that you know which things need to be explained, vs. what they probably already know so you don't waste their time repeating it. The other problem, then, is being able to explain things at that level, without leaving out any of the information they need because it's just implicitly assumed or seems "obvious" to someone with more experience.
...But, all that being said I agree that Guidelines updates wouldn't make sense as an "event" in the JanuWiki mold, where we try to solicit come-one-come-all participation from as many users as possible. Heck, they may not be a very good fit for any sort of organized "group effort" at all — our best bet may be for someone to eventually just dive in and start making Bold changes to define an updated, improved structure for the content. Even if they only update a single Guideline article, once there's an example to work off of, other editors can pitch in to apply the same changes to the rest of the Guidelines. (That sort of example-based, follow-the-leader model is how most content-wide changes propagate here, really. Djonni created the {{hero or heroine}} template set, but he's responsible for only a handful of edits that applied those templates to article content.) -- FeRDNYC (talk) 14:43, 27 March 2019 (UTC)

Reducing article cruft while raising content visibility

There are two different goals that have been rattling around in my head for a while, and I've recently come to realize that it's possible to actually work towards both of them simultaneously.

Goal 1: Raise the visibility of our actionable Categories

This is something WardPhoenix took steps towards recently, by adding Category:Stubs and Category:Pictures needed to the Main Page intro box. That's a start, but I think we can do more.

Note that this is about what I call "actionable" categories, meaning categories in which a page's presence means that it requires action in some form — usually, editing or maintenance. The two categories I just mentioned are the primary ones, but there could be others in the future. Special:WantedPages is the somewhat-reductive ur example of an actionable category.

The other type of category, which I'll call "collective" categories, are the ones where membership is just a way of classifying articles. Those are less useful to the average reader, because the wiki's coverage is so lacking for most categories.

Category:Towns contains at least nearly every town in the game, sure. But Category:Monsters only contains a tiny subset of all the known monsters, unlike List of Monsters which is much more complete. That issue is even worse for, say, Category:Activatable Artifacts, which only contains the artifact articles that use {{Artifact}} and properly indicate the subject's activatable status, which is a an even smaller subset of the already very small subset of artifacts that have an article at all.

Anyway, point is there's not much value to the average visitor in being pointed at those categories. But the actionable categories, those we do want people to know about, and explore, and hopefully perhaps be inspired to pitch in and thin their membership out a bit.

What's the point of all this, though? Well, that brings me to goal #2...

Goal 2: Reduce both the presence and visibility of ancient "technical" cruft

A few pages on the wiki, to be blunt, just shouldn't be articles. They're not about anything to do with Godville, mostly they're wiki-internal Category:Technical articles containing content hastily copypasted from Wikipedia, offering poor coverage of general wiki concepts in a way that isn't helpful to our users. (If we want people to read about wiki concepts, we should point them at the actual Wikipedia documentation on those concepts, which is far more readable, polished, and useful. Horse's mouth and all that.) Worse, they usually haven't been updated in several years, and they weren't very good to begin with.

These articles mostly seem to have been created to give notice templates about their related concepts something to link to, which I guess felt necessary at the time. I'm talking about articles like:

  • Stub (which the {{stub}} template's message links to)
  • Merge which is linked to from {{Merge}}
  • Redirect which is linked to from Merge and also uselessly sucky
  • Picture which is one of the like 17 different picture-uploading explanations on the wiki, and is linked to from {{picture}} and several of the Guidelines articles as well. (Even though Creators Manual#Images is also a thing, and IMHO Picture dumbs it down a bit too far.)
  • (and probably others, this isn't presented as a comprehensive list)

Several such articles correspond to a tracking (and therefore actionable) category, so they typically refer the reader to it with a poorly-formatted, easy to miss link. Stub, for instance, has "List of Stubs" tucked away at the bottom of the intro section. Merge, OTOH, doesn't even do the courtesy of linking to Category:Proposed mergers — despite the fact that it would be good to have people know what, if any, pages are in that category.

The proposal

So, like I said, it occurs to me that those two goals can be achieved in tandem. Here's what I think we should do:

  1. Take what little useful content those articles contain, and place it at the top of the associated actionable-category page. So the tiny bit of stuff from Stub that isn't just badly-Xeroxed Wikipedia policy would go onto the Category:Stubs page, so that it displays above the listing of category members.
  2. Do away with those articles completely, redirecting them to the Category page.

So that way, when {{stub}} says "This article is a stub.", clicking that link won't take the user to an article of minimal value. Instead, it'll take them directly to the list of stubs at Category:Stubs, with a brief explanation of how to create, expand, tag, and un-tag stub articles displayed right there at the top. It can even direct anyone interested to the Wikipedia:Stub article "for much more information".

Thoughts? -- FeRDNYC (talk) 13:36, 30 March 2019 (UTC)


Basically, can't disagree. Not really much more to say, you said everything. --WardPhoenix (talk) 15:24, 30 March 2019 (UTC)

Acutally did a first round of edits, Stub have been redirect to Category:Stubs and all Categories Quest/Monster/Equipment/Artifact/Skills have been redirect to their list.--WardPhoenix (talk) 15:48, 30 March 2019 (UTC)
Woah, regarding your recent edits, I think there may have been some miscommunication.
  1. You can't redirect category pages to articles. (Because then, how would you see the list of members?)
  2. You can't even redirect categories to other categories.
    (It's a MediaWiki limitation. Instead of doing what you probably intend, it just breaks things.)
  3. We wouldn't want to redirect the categories, anyway. What would be the point of having them, if we did?
This proposal was about going in the other direction — redirecting e.g. Stub to Category:Stubs (after moving the useful information to the Category:Stubs page first). But not doing anything with the collective Categories. They serve their purpose as-is, the only thing we've changed in the past is linking less to, say, Category:Monsters and more to List of Monsters (as the more useful of the two).
But a #REDIRECT should never be placed on any page in the Category: namespace. It won't actually redirect (if it goes outside that namespace), and it won't do the right thing if it's within the namespace. -- FeRDNYC (talk) 15:56, 30 March 2019 (UTC)
This is when a live chat would be useful xD Anyway we did the revert, and for the stubs article there was no useful information so just redirected quickly. --WardPhoenix (talk) 16:00, 30 March 2019 (UTC)
Easy enough to clean up, and no harm done. Yeah, MediaWiki's treatment of Category pages is... just weird, and creates a lot of issues that require them to be handled specially. You can point anything you like to the Category pages, and even treat them as article pages if you like (which is what gave me the idea to move our technical content there, where it made sense), but there are a lot of traps in what will work from Category pages (and only Category pages) to the rest of the wiki. -- FeRDNYC (talk) 16:03, 30 March 2019 (UTC)

Effect field for activatable artifacts in infobox

I've decided to try and get through some of my backlog of "things I've been meaning to do". (Your day will come, new {{Guild}} Infobox!) First up: More enhancements to the {{Artifact}} template for Activatable Artifacts!

The |cost= parameter was introduced a little while ago. Now the template supports a companion |effect= parameter, to (succinctly) document what happens when the artifact is activated. For now it's just a free-form text field, though a set of standard arguments has been discussed and may still be implemented.

Along with this new parameter come styling and layout changes for the activation details, to group them together and make them stand out — much like the different monster types in {{Monster}}.

See it in use at Portable Tunnel.

Complete template documentation at {{Artifact}}. Report issues on the template's Talk page, which can be reached using the "T" link at the bottom of the infobox. -- FeRDNYC (talk) 16:16, 2 April 2019 (UTC)

Good job and thanks! Looks like I need to get back my GodWiki Gnome badge and I'll do some standardization when I can. --WardPhoenix (talk) 18:13, 2 April 2019 (UTC)
As for now, most of articles have been templated with the new infobox. Which means most (not to say all) monsters, artifacts and equipments articles have the new infobox on them. --WardPhoenix (talk) 09:44, 7 April 2019 (UTC)

Adjustable-width spacers and the featured article box

Since the {{Featured}} box is now allowed to be narrower when placed alongside the {{Mainpageintro}} box (to give the longer intro text more space), the default 15em width used for {{spacer}} won't allow the featured article text to fit alongside its image in many cases.

So, I expanded the spacer template with an optional parameter to adjust the size of the spacer <div>...</div>, and {{spacer|width=8em}} is now the documented recommendation for formatting articles in Template:Featured. |width= can be any supported CSS length value, see documentation at Template:Spacer. -- FeRDNYC (talk) 02:19, 3 April 2019 (UTC)

Merging of related main contents articles

I already put it in the equipment talk page, but then i noticed most of the main contents articles : Monster, Equipment, Artifact, Quest, Skills and maybe some other articles have a similar "issue": Information spread into differents articles.

As for exemple, there is a Quest article, an Epic-quest article and finally a Mini-quest article. I think it would be better to have all of this into one article. as it would look probably better and we can still put direct redirect to the headers. Thoughts? --WardPhoenix (talk) 09:54, 7 April 2019 (UTC)

In general I absolutely feel the same way: fewer more comprehensive articles are preferable to lots of bouncing from page to page to page. As long as each article is well-organized, links and redirects can always be pointed to specific sections within the larger whole. Like, really, skills is a pretty poor article, and could easily contain an overall explanation as well as information about the three subtypes.
The only reason I'd be reluctant to consolidate all of the Quest articles is due to the unfathomable amount of crufty detal people have shoved into Mini-quests. I definitely think Quests should cover all three types, instead of sort of forgetting Epic Quests and Mini-quests exist except for a brief "Related" link. But a lot of what's found at Mini-quests now might be better off renamed to "List of mini-quests" or something, and still kept separate from the main article. -- FeRDNYC (talk) 18:33, 7 April 2019 (UTC)

Say "Hi" to the Skill Infobox Template!

As title say, the Template:Skill is born after a lot of copy-paste from an other template made by FeRDNYC (thanks to him for his advices by the way) and a good amount of frustration after loosing more than half an hour because I forgot a damn }} in the code and failed to notice it earlier...

Seriously, I almost cry out of joy when it started working correctly...*Ahem*

While quite simple since skills have only one paramater, this template allows skills articles to looks as good as the others article (except quests ones they are next on the line) as you can see in the Quantum fireball.

If you're not fond of the color/wording/placeholder picture/emoji of categories please feel free to say so. Upgrades are always possible and feedback always welcome! --WardPhoenix (talk) 23:52, 7 April 2019 (UTC)

Quest Infobox was already there.

Aside from the global issues of Mini-quests (see Talk:Mini-quests), the {{Quest}} infobox seems quite ready to deploy and is perfectly usable on every kind of quest article (type=mini/normal/epic).

Maybe the template will have additionnal parameters for mini-quest later on, but not in short term.

Catch the worm before the early bird is the first to receive the template if you want an exemple.

As always, any feedback is welcome. --WardPhoenix (talk) 13:52, 18 April 2019 (UTC)

That looks great, WardPhoenix. Nice work.
I see that there's an option for ignoring that there is no image... is there a way to insert the quest-progress template to display where the picture would be, if someone did not want to create a pic? --SourceRunner (talk) 15:50, 18 April 2019 (UTC)
I didn't found a way to add the {{Diaryquest}} at the same place as the picture yet (it doesn't display properly). But it is possible to insert it in the description parameter. Then it's possible to add |ignore-no-image=yes to not have the picture needed banner and leave the article with the placeholder image. Obviously, t's also placable in the introduction of the text, one template doesn't prohibit the other I think. I'll try to dig if I found something, or maybe User:FeRDNYC will know a solution. --WardPhoenix (talk) 18:30, 18 April 2019 (UTC)
You're awesome. Thanks for being willing to figure something out. It's not a dire thing, I was just thinking that some quest writers might just want to put the progress bar where the picture is, instead. But hey, we could make it in a sandbox, screen-shot it, and then load the screenshot in as the picture, right?
Seriously, you've done great work on this, Ward. --SourceRunner (talk) 13:30, 19 April 2019 (UTC)
I guess a screenshot would work, but I would have prefered to have a more direct way. By the way, I noticed that {{Diaryquest}} can also be put as a caption and so will appear just below the placeholder picture. It doesn't look really great but still something.
Didn't found a way to hide the picture without ruining everything, this exceeds my meager skills in the coding of that template (and I tried every stupid idea I thought about). --WardPhoenix (talk) 14:57, 19 April 2019 (UTC)
I'll take a look, I can definitely come up with a special |mode=infobox switch for {{Diaryquest}} that formats it all special-like, if nothing else. I'd definitely prefer that to a screenshot. -- FeRDNYC (talk) 18:03, 20 April 2019 (UTC)
I have posted an Idea™ over at the template Talk page. -- FeRDNYC (talk) 20:01, 20 April 2019 (UTC)

Formatting change on Main Page

I'm trying something new with the set of links at the bottom of the gray box, on the main page. See what you think.

I never liked the way that section of the page rebalanced itself when shrinking, since its contents weren't all the same width (being different-length strings) and they got all wonky when they had to wrap. But I got inspired by some techniques I saw at CSS Tricks and decided to try again. Finally admitting to myself that there was no way to make it look good without a border around each link was the key.

It's not perfect, since with exactly the wrong page width you can still end up in this situation: — but with six items, there's really no way to avoid that. Can't win 'em all. I think it looks a lot better for the 4-wide, 3-wide, and 2-wide cases, though. -- FeRDNYC (talk) 18:03, 20 April 2019 (UTC)

Not gonna lie, it looks WAY better on mobile view right now. Good job! And now, I'm even asking myself if the same couldn't be done for the first part of the banner because right now it looks like this: Having them in columns (which somehow is the case on desktop view but not on the mobile interface) would make the banner way more mobile friendly. --WardPhoenix (talk) 18:29, 20 April 2019 (UTC)
Whoops! Sorry, that was actually my fault, a different change I was testing snuck in. Check it now, should be back to two columns. -- FeRDNYC (talk) 20:03, 20 April 2019 (UTC)
(For some reason, the Godville devs eliminated the padding-inline-start width that normally protects the bullet character on lists. So, depending on the page width, it's possible for the bullets in the left column to slide right off the edge of the box. I was looking at trying to put the padding back, on that list. But I need to adjust the width for mobile, for that to work, so I'd intended to remove it until I could. Then I forgot.) -- FeRDNYC (talk) 20:09, 20 April 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Okay, I re-applied that change to the bullet list, but in a way that lets the columns wrap a lot tighter. The bullets should now be protected from falling off the page, and mobile devices should now see at least two columns, possibly all 3 for devices with wider screens. -- FeRDNYC (talk) 01:07, 21 April 2019 (UTC)