Talk:Main Page/Archive/2019

From GodWiki
Jump to navigation Jump to search

Sign template updates requiring page edits

Important.pngThis template needs to be fixed
These fixes will require the editing of Guild articles by a non-Guild-member (specifically, me — FeRDNYC), which is normally not permitted by the Godwiki rules. I request that everyone understand the reasons behind this one-time, limited violation of those rules.

The plan

The {{Sign}} template, which is used to create notices like the one above, has several issues with how its parameters are specified. You can find a long, detailed explanation of those issues at the Talk page for the template, if you're interested. But the important point here is, those issues are going to be fixed. The fixes, however, will affect existing uses of {{Sign}} in Godwiki articles.

What this means for you (the editor of an article containing {{Sign}})

  1. If your article contains a sign transclusion with parameters like {{Sign|bordercolor=red}} or {{Sign|bgcolor=#91A3B0}}, those parameters will start working, where up until now they have been ignored. This will change the appearance of the sign, perhaps in unwanted ways. If so, simply remove the |bgcolor=, |bordercolor=, or |outerbordercolor= arguments so that the sign will use the default values, like it was previously.
  2. If your article contains a transclusion with parameters like |bordercolor=ee8822, those parameters will break due to the changes. If this happens, I will fix them for you, by changing them to e.g. |bordercolor=#ee8822. You will not have to do anything. That is the reason for this announcement, and for the request that Guild members understand why a non-member will be editing their Guild page. My changes on any Guild articles will be limited to editing {{Sign}} parameters only.

If there are any affected {{Sign}} transclusions on user pages (it doesn't look like it, so far), I won't be able to fix them. I'll try to leave explanatory notes on the associated Talk pages, if those cases arise.

I don't plan to start these changes immediately (I want to give people time to digest this announcement, for one thing), but they will be happening soon and most likely will be completed by the end of the week. If anyone has any objections or issues, you have the floor... -- FeRDNYC (talk) 21:56, 18 November 2018 (UTC)

Yellowtick.png Partly done
The color-parameter changes are complete. {{Sign|bgcolor=|bordercolor=|outerbordercolor=}} now accepts any valid CSS color string, e.g. |bgcolor=red or |bordercolor=rgb(100,150,0). If specifying color by hex color value (i.e. #RGB or #RRGGBB), you must include the leading # sign.
Guild pages edited
The only change that remains to be done is the fix to |imgwidth=, and the only page that will be affected there is Open Bar (again). I'll get to that another time. -- FeRDNYC (talk) 00:24, 23 November 2018 (UTC)
Tick.png Done
Completely done, |imgwidth= syntax is updated in {{Sign}} and all three pages which make use of that parameter (Open Bar, Template:Godwiki event construction, and Template:Godwiki event review) have been modified accordingly. -- FeRDNYC (talk) 11:52, 12 January 2019 (UTC)

Fixes for mobile content layout

So, I have an idea for how to blanket address the general mobile-browser formatting issue of content/headings being hidden by, cut off by, or improperly squeezed in alongside infoboxes and other right-floated elements (like the Archive box on Talk pages), without having to modify individual pages. The correct way to solve this problem would be with modifications to the site CSS, but lacking the ability to make such modifications I'm proposing the following band-aid fix.

For those not familiar with the issue, see:

I've also written up an incomplete technical dissection of the issue for those interested. The later update also explains both my initial idea for addressing the issue, and this (rethought) second plan that I'm now proposing. The first plan involved editing each page where content was wrapping incorrectly, whereas the new plan involves only editing the handful of templates which create infoboxes or other floated content.

My proposal is to add an invisible spacer to the end of each template which creates floated content ({{Monster}}, {{Equipment}}, {{Artifact}}, {{Town}}, {{Guild}}, {{Archives}}, etc.), immediately following the floated block. Because this spacer will have a fixed minimum width, if it fits alongside the floated block then it will simply cause an empty paragraph's worth of vertical whitespace at the top-left of the float. However, if there isn't room for the spacer alongside the float, then it will push any content which follows it (whether headings, body text, etc.) down below the floated block, preventing any of the uncomfortable layouts seen in the screenshots above.

To visually demonstrate what I'm suggesting, I've created a screenshot gallery across a range of screen formats and orientations, and various wiki skins. The screenshots present examples of how a test page would render first without, and then with, the invisible spacer. (The location of the normally-invisible spacer is highlighted with a "div" callout in all screenshots starting from the fifth.)

Making this change should fix all affected pages, and hopefully on all affected devices, without any of the individual pages needing to be modified in any way.

Thoughts? -- FeRDNYC (talk) 14:41, 17 January 2019 (UTC)

Seems quite the revolution. It's gonna be a lot to add it to every concerned page, but in the end it will be way better it seems. Great thanks to you! WardPhoenix (talk) 15:02, 17 January 2019 (UTC)
Modifying the templates definitely sounds easier/less involved than editing each page. I like the look of the solution, too. Is there a reason behind choosing the fixed width to specifically be 180 px? (That's what I think I'm reading, at least.) It works well, but I'm curious. -- SourceRunner (talk) 15:11, 17 January 2019 (UTC)
@WardPhoenix: The advantage to the proposed fix is that it specifically doesn't require modifying every page — only a few templates. The alternative would be to correct every page which is rendering incorrectly, which would indeed be a huge chore. As proposed, as few as two templates need to be edited. (If I decide the right way to go is to stick the fix into {{Infobox}} itself — rather than the derived templates like {{Monster}} and {{Town}} etc. — then that covers 95% of the problem instances in one shot.)
@SourceRunner: The width is specified as 15em, so the exact size will vary based on device resolution, but the actual value is basically arbitrary. Its effect is to impose a required (minimum) width for the area to the left of a floated template, before it's allowed to have content placed alongside. The width used is certainly open to adjustment — my goal is to find a value that's wide enough to prevent situations like this or this, without leaving excessively-large blank areas next to infoboxes and the like. (Keeping in mind that any headings that are allowed to render in that space will be cut off unless the space is wide enough to wrap all of the words into it.)
Basically, I'm trying to avoid creating either of these situations:
Too narrow, heading truncated

Too wide, content pushed out when it could comfortably fit alongside.

...Keeping in mind that the width of the left-hand space in those boxes will vary by quite a lot, based on factors like screen size, orientation, etc. Choosing the right min-width value to achieve the proper balance is completely a matter of intuition / trial-and-error. -- FeRDNYC (talk) 19:04, 17 January 2019 (UTC)
(By using a width in em units, the size of the spacer is defined based on the font size in use. Specifically, it's the width of 15 letter 'm' characters. So, currently, the minimum available space to render text to the left of floated content would be this large: mmmmmmmmmmmmmmm.) -- FeRDNYC (talk) 19:12, 17 January 2019 (UTC)
This seems to have introduced a new problem, at least on my iPhone 5S using the vector skin. The info box now appears not at the top, but after the first paragraph, so sometime half way down the page, and also, the box is cut off on the right side of the screen. Here’s a screenshot of the problem : Spirit of Hell (talk) 02:16, 18 January 2019 (UTC)
@HSoH: This hasn't been done yet, so nothing's changed. That's just how the mobile skin lays the page out. The first content paragraph (the same one that would come before "Contents") gets placed before the infobox, in the mobile Vector rendering. (Doesn't happen with WPTouch, the mobile "Desktop" view.) That's another thing that's beyond our control.
If it seems like things have changed recently with a certain article's layout, most likely it previously had a JanuWiki header. When the header is in place, it becomes the "first paragraph", so the infobox renders immediately after it. Remove the header, and the first content paragraph moves up above the infobox. Been that way all along, and nothing we can do about it, alas. -- FeRDNYC (talk) 02:30, 18 January 2019 (UTC)
The infoboxes sticking off the left edge of the screen in the mobile app, that's also been happening all along, to varying degrees on various devices. It only happens in the Godville app browser — load the same page in mobile Chrome or Firefox, and it renders perfectly. I have no idea what the devs are doing to break page layout in their mobile app, but ¯\_(ツ)_/¯. -- FeRDNYC (talk) 02:30, 18 January 2019 (UTC)
No, this is definitely a new issue, it happens on all info boxes and all skins and did not look like this before. Before today, infoboxes were only slightly cut off, with the words sitting right on the margin, still legible. And the info box appearing halfway down the page is also something new and appears on all pages, even ones that haven’t been recently changed. Though if nothing about the info boxes themselves has changed, I have no clue what the cause could be.
I’ve now noticed that the pages do have the correct layout on the mobile version of the desktop, but the infoboxes are still the same. —Holy Spirit of Hell (talk) 19:31, 18 January 2019 (UTC)
On further experimentation, the page and all others render the exact same way in mobile Firefox and Chrome, it is broken in every fashion that I can access it with my iPhone 5S. Furthermore, using the mobile ‘desktop’ version, the infoboxes have shifted even further to the left side of the screen, cutting off more text, something has definitely changed Holy Spirit of Hell (talk) 21:06, 19 January 2019 (UTC)
I think that's a great and clever solution with the tools that are available! Even though it's a band-aid fix, I think it looks good and serves its purpose well. --Terezka (talk) 20:23, 18 January 2019 (UTC)
Agreed on good workaround. Congrats FeRDNYC. -- S624 (talk) 20:27, 18 January 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Thanks, all. This fix is now in place for {{Archives}} and all templates based on {{Infobox}}: {{Monster}}, {{Equipment}}, {{Artifact}}, {{Town}}. (That list will expand to include {{Guild}} when I release the new Guild template — see User:FeRDNYC/Sandbox — which will most likely happen some time this weekend.) I'm not planning to screw around with other templates like {{Usergod}}/{{Usergoddess}} or {{Hero}}, for the moment. If anyone can think of any right-floated templates other than the ones I just mentioned which would be candidates for this fix, please let me know. I'm currently not coming up with any.

The {{spacer}} addition can be disabled on any page where it's causing a problem by adding |spacer=no to the template arguments, and it can be disabled globally by undoing the appropriate edit at Template:Archives and/or Template:Infobox. -- FeRDNYC (talk) 15:38, 19 January 2019 (UTC)

Re: GodHoly Spirit of Hell 's comments, above, which use the Beerburglar page as an example (but are not limited to that page, I understand)...

Before today, infoboxes were only slightly cut off, with the words sitting right on the margin, still legible. And the info box appearing halfway down the page is also something new and appears on all pages, even ones that haven’t been recently changed. Though if nothing about the info boxes themselves has changed, I have no clue what the cause could be.

You can see from the edit history for Template:Infobox and Template:Monster that, before today (the 19th), the most recent changes of any sort were 6 days ago on the 13th (for Template:Infobox, not counting that edit on the 14th to undo the previous change), or 10 days ago (for Template:Monster) — nothing changed on the 18th (the day your "Before today" referenced) at all.
Those changes on the 13th could've affected infobox layout on the iPhone, though they shouldn't have since I just removed some DIVs that were put in place for the old Minerva mobile skin that's not in use anymore. More likely to have affected layout would be the changes on the 9th, which did involve changes to widths and font sizes. But if anything's been changed more recently than that, it must've been done outside of the wiki content.

On further experimentation, the page and all others render the exact same way in mobile Firefox and Chrome, it is broken in every fashion that I can access it with my iPhone 5S. Furthermore, using the mobile ‘desktop’ version, the infoboxes have shifted even further to the left side of the screen, cutting off more text, something has definitely changed

Yeah, sorry, that was me being unclear. The thing about Firefox/Chrome was Android-specific; it wouldn't apply to iPhone since all web browsers on iPhone use the Safari layout engine, so differences would not be expected or... well, possible really.
And as far as the iPhone, I'm still milking that free BrowserStack trial, and its screenshot service corroborates your experience regarding the cut-off infoboxes on iPhone 5 (screenshots) — but notice that it's only on iPhone 5, at least of the devices represented. (A sadly very limited list which I have no control over, now that I've exhausted the live-testing portion of my free trial.)
But on the question of why it's rendering like that on the iPhone: I have no idea, sorry. I don't have an iPhone or have access to an iPhone, and since I don't have any way to test on iOS devices (or a reasonable substitute) anymore, I don't have any way to reproduce or examine the issue. Which does not occur on any devices I do have access to.
Just looking at the screenshots, it sort of looks like the issue could be related to the image size, like it's too large for the display... but I last changed that on December 9 so it would be weird if it's only coming up now. -- FeRDNYC (talk) 23:26, 19 January 2019 (UTC)
GodFeRDNYC , the display size on the SE, which your simulator shows working correctly, if shifted downwards, has the same display size, so I don’t think the image size is the problem. The difference is in the processor and the RAM, with the SE being a lot more powerful, so that probably has something to do with it.

I’m not sure that I’ve looked at any normal GodWiki articles between the 13th and the day of my first reply, so the formatting change could be what has shifted the infoboxes, since there it has changed and there seems to be nothing else that could have caused it —Holy Spirit of Hell (talk) 01:55, 20 January 2019 (UTC)
Ah, sorry — the Imgur captions are below the images they respond to, so the first screenshot with the shifting-off-the-left-edge issue is actually the iPhone SE. I misremembered which model it was because 5 and S look the same and Apple's naming scheme is fucking moronic. All the rest of the screenshots are different Android devices. (The "Shifted down" on the next image — the Nexus 5 — is just because BrowserStack's Android device testbeds don't assemble long web content screenshots seamlessly, so there are visible page breaks every screen-length... the first of which happens to fall right before the infobox, on that device.)
If it's possible the issue started on the 13th, then it could be the removal of those DIVs I suppose. In which case, that sucks, because they were causing crazy-excessive margins around the infoboxes on desktop, so they really need to not be there. (They were never correct in the first place, I was abusing the CSS of the now-disabled mobile skin to avoid a table-sizing issue.) I'd suggest reporting the issue with infobox layout on iOS to the Godville devs. -- FeRDNYC (talk) 04:49, 20 January 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Apropos of nothing at all, really, I just captured this screenshot while reading an article from Stargate fan blog Gateworld on my phone. It weirdly makes me feel a little better that we're not the only ones fighting this issue. (Not that I ever thought we were.) -- FeRDNYC (talk) 23:13, 21 February 2019 (UTC)

Formatting g.e. dates

Inspired by the work GodWardPhoenix  and GodSourceRunner  were doing on the Godbuster article, which makes excellent use of g.e. dates, I realized that we should be doing more to assist with and standardize the formatting of those dates. (Why this article in particular triggered the idea, I can't say, but it happened to strike me while reading it.) Basically:

  1. The dates and the "g.e." after them should really be connected by a non-breaking space, so they won't be broken up by line-wrapping.
  2. That's something that a template can easily take care of.

My initial idea was to just change template {{ge}} so it would add " g.e." to the end of the output, but it's used all over the wiki in places where it's expected not to do that, and it would be a massive pain to change them all.

Instead I hacked up a new template {{date ge}} — it works like {{ge}} in many ways, except it always appends " g.e." to its output, and you can use {{date ge|number}} to format a g.e. date without conversion.

So, to borrow some examples from the documentation:

[[Godville (game)|Godville]] was born on {{date ge|ge=0}}! appears as:
Godville was born on 0 g.e.!
The 5th of August 2013 was {{date ge|1183}} appears as:
The 5th of August 2013 was 1183 g.e.
The 15th of December 2011 was {{date ge|12|15|2011}} appears as:
The 15th of December 2011 was 621 g.e.

TL;DR: Basically,

  1. Anywhere you're writing "number g.e.", you can instead use {{date ge|number}} and the date will be formatted properly to protect against line wrapping.
  2. Anywhere you're writing "{{ge|mm|dd|yyyy}} g.e." can become "{{date ge|mm|dd|yyyy}}" to take advantage of the same protection.

And to illustrate the main reason for this template (besides the fact that typing " g.e." constantly is a pain), here's the difference vs. just typing "{{ge|1|26|2019}} g.e." or "number g.e." with a normal space:


Written on 3183


Written on
3183 g.e.

-- FeRDNYC (talk) 21:26, 26 January 2019 (UTC)

Activation cost in Artifact infobox

The {{Artifact}} template now supports a |cost= parameter, used to specify the activation cost of activatable artifacts. Possible values are:

|cost=0 – Requires no godpower to activate (can also be: free,none,0%)
|cost=50 – Requires 50% of godpower to activate (can also be: 50%)

See it in use at Subplot thickener. -- FeRDNYC (talk) 23:02, 26 January 2019 (UTC)

Subtypes now implied in monster template

After a small coding error that briefly caused all monster articles to appear in Category:Boss-Monsters (whoops, sorry about that), the {{monster}} template is now upgraded so that it's no longer required that the sub-type be explicitly activated with |pet=yes, |boss=yes, or |sea=yes. If any of the parameters that correspond to that type are set, it will imply the corresponding sub-type. The switches may still be used to activate a sub-type, and must still be used if none of the subtype parameters can be set.

Because of this implication, the parameters that correspond to subtypes have been given new canonical names that include their subtype. The old names can still be used, but the new ones are preferred.

What that means, by example:

  • It's no longer necessary to write
    {{monster|pet=yes|levels=18-25}} or {{monster|pet=yes|feature=rideable}}
    Instead write
    {{monster|pet-levels=18-25}} or {{monster|pet-feature=rideable}}
  • It's no longer necessary to write
    Instead write
  • It's no longer necessary to write
    Instead write

But, again, you must set |boss=yes to create a boss-monster article if you are not setting a value for |boss-type= (including when you are leaving it blank). The same rule applies for the other subtype parameters.

Please report any issues caused by this change over at Template talk:Monster. -- FeRDNYC (talk) 22:22, 16 February 2019 (UTC)

Seems to work on the few cases i tried it, shortens the edits a little. Thanks! --WardPhoenix (talk) 14:01, 19 February 2019 (UTC)

Notes on potentials dupes on Lists

Forgot to post it here (even though i told myself i'll do it) so leaving a short resume. We have potential dupes in lists (Omnibus List and all the equipment/artifact/etc) such for exemple the case of death note or [[Snooze button] which are referenced as both equipment and artifact.

Another exemple is the double eye-pacth who was referenced as equipment in 3 differents spelling (inquiry show that atleast two of them co-exist) and also referenced as artifact ; or the Gaolkeeper who redirect to Ghoulkeeper but i have no certitude the former don't exist independently from the latter.

If you want to help gather infomations, please take a look at the list on my talk page and don't hesitate to leave a note here or on the relative talk on my page. Thanks in advance to those who'll help! --WardPhoenix (talk) 14:01, 19 February 2019 (UTC)

It's been almost a month since i made that list and while some of them have been resolved, some name are still only one of their homonyms found in the game.

Would you agree on conclude that the one yet not found doesn't currently exist? And so to proceed to their deletion on lists (omnibus and respective list) ? --WardPhoenix (talk) 16:03, 12 March 2019 (UTC)

Makes sense to me. In general, my feeling is that if something doesn't have an article, and we're reasonably sure it's redundant with another listed item, might as well drop the duplicate from the list(s). That entry can always be added back in again. (Obviously, if there's an existing article then that's a totally different story.) -- FeRDNYC (talk) 16:45, 13 March 2019 (UTC)
Gaolkeeper redirecting to Ghoulkeeper, that one doesn't really make sense to me. SourceRunner raised an objection to that redirect at one point, and I agree — while the two names are similar, they really don't have anything to do with each other. It's possible whoever made the redirect wasn't familiar with the word "Gaol" as an alternate form of "jail", and assumed it was a typo of the closest-named monster.
And I see that there's now a stub Gaolkeeper article to replace the redirect, so that solves that. -- FeRDNYC (talk) 16:51, 13 March 2019 (UTC).

Small Edits on Main banner

I went bold, but i'll post the why there in case someone have an objection. I remplaced some of the category that appeared in the bottom of the welcome banner. Here are my changes :

  • All Categories -> Guidelines
  • All Pages -> Help/Requests
  • Map of Godville -> Omnibus List

The 3 formers category are not really useful while the 3 remplacements may help for guidelines and help/request to have better exposure and for omnibus list to have a direct link especially for mobile user.

If someone have an objection, please undo and notify here.

--WardPhoenix (talk) 16:59, 24 March 2019 (UTC)

Makes sense to me. I have this weird reluctance to link to the Omnibus List directly from the Main Page, but I can't explain why and I certainly recognize the utility to crossword cheaters solvers, so to heck with my reluctance. -- FeRDNYC (talk) 07:31, 26 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)

A milestone approaches

I just happened to notice the following data point at Special:Statistics:

Page edits since GodWiki was set up 99,802

(And that'll be 99,803 with this post.) We're fast approaching the 100,000th edit! -- FeRDNYC (talk) 07:41, 26 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)

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)

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)

It keeps appearing as one column on my side, while the 6 below appear as two column. Maybe issue come from my screen size too. -- WardPhoenix (talk) 09:55, 21 April 2019 (UTC)
Perhaps, though judging by that screenshot I'm surprised it wouldn't be able to fit at least two columns now. I guess it's also possible your phone browser simply doesn't support CSS columns, or doesn't support their inheritance from surrounding elements. (The list isn't actually styled multi-column, instead the <div> containing the list is multi-column. ...The links below (the newly-boxed ones), like the four main page boxes, are stacked with Flexbox which is something else entirely.)
How many columns do you see here, on your phone?
  • Item 1
  • Item 2
  • Item 3
  • Item 4
  • Item 5
And how about here?
  • Item 1
  • Item 2
  • Item 3
  • Item 4
  • Item 5
-- FeRDNYC (talk) 11:22, 22 April 2019 (UTC)
Just checked, both appear as one column on my phone (on a side comment, dots doesn't appear on the second one on my phone). But as you say, my phone may not support some things as it is kinda old, the best would be to have more people feedback on this.
As a side note: I was wondering if we couldn't remove some categories that aren't really useful while you're trying to adjust that banner (and maybe trying to find a way for what we want people to see/use to be actually highlighted). Those categories to be removed IMHO would be:
  • Pantheons : Which is a subcategory of gameplay, and not specialy important.
  • Galleries : dead section
  • Backstage : It's too unspecific
  • Technical : I don't see the point to have this on the main banner except for advanced users
  • Gods/Heroes/Guilds : I don't think people check those page to search for others gods/heroes/guilds
That would make a less dense banner I think. --WardPhoenix (talk) 11:51, 22 April 2019 (UTC)
Actually went with the changes, and there was no contestation sooo... xD --WardPhoenix (talk) 14:05, 30 April 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)

Merge have been redirected to the template, with the documentation having a link to the wikipedia page. Picture have been redirected to the Creators Manual. Redirect have been redirected to the wikipedia page (ironic). --WardPhoenix (talk) 11:58, 7 May 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)

After some rework following the feedback (thanks SourceRunner!) , I'd say the template have reach a new state of finished, many thanks to FeRDNYC for his work. --WardPhoenix (talk) 14:16, 30 April 2019 (UTC)

The template you didn't know you needed

Added a new {{Top}} template to the GodWiki. This add a floating "Back to the top" button to, well, get back to the top of the page in a single click. Useful for very long page I'd say, like SummerWiki 2019 or the GodWiki's Lore Compendium.

What do you think about it? --WardPhoenix (talk) 14:04, 3 June 2019 (UTC)

++ -- S624 (talk) 16:32, 3 June 2019 (UTC)

Double Redirect Page Issue

After wandering through the red link page list, I stumbled upon the double redirect page. While I did fix one of them, the second one I'm afraid cannot be fixed without intervention by a database operator. The page in question has the title "Godville_(Town) " (which is the same as the Godville (Town) page just with an extra non-breaking white space at the end of it.)

The problem is that MediaWiki internally strips the extra white space off the end of the page title before actually doing anything with it. This means that from the front end, you can't access the erroneous Godville_(Town) page at all. From what I was able to recreate on my own private wiki, the only way to fix it is going into the "page" table in the database and looking for a row with "Godville_(Town) " or "476f6476696c6c655f28546f776e29c2a0" in the "page_title" column. (The "47...a0" is the url encoded version of "Godville_(Town) " which my wiki automatically changed it to after I manually edited a page on my private wiki to have that name.) A wiki/database operator would have to go in and manually change the page title of the relevant row to remove the trailing space so that we can actually edit/delete the erroneous page, or something. I've spent the past few hours trying to find a solution online and by experimenting on my own wiki and the only way I've been able to fix such an error on my wiki is by manually editing the database.

You can spot the two pages when you search for "Godville (Town)" (eg: this search)

It's not exactly a big problem, but, on the search results it means that two identical "Godville (Town)" pages are listed, one of them redirecting to Godville (Disambiguation) and the other being the page proper. It's more of an annoyance factor than an issue. Though, the million dollar question is how such pages actually managed to come into existence since MediaWiki sanitizes page titles...

Other pages with this issue:

Page Redirect? Search link Encoded equivalent
3D Interface redirect search 33445f496e74657266616365c2a0
Equipment redirect search 45717569706d656e74c2a0
Gold bricks redirect search 476f6c645f627269636b73c2a0
Grayscaled Dragon redirect search 477261797363616c65645f447261676f6ec2a0
Ideabox NOT a redirect search 49646561626f78c2a0
Lightasber-Toothed Tiger redirect search 4c6967687473616265722d546f6f746865645f5469676572c2a0
Pets redirect search 50657473c2a0
Probability redirect search 50726f626162696c697479c2a0
Temple redirect search 54656d706c65c2a0
Voice of god redirect search 566f6963655f6f665f676f64c2a0
Trollbridge redirect search 54726f6c6c627269646765c2a0
Godville (Town) redirect search 476f6476696c6c655f28546f776e29c2a0

I found these by searching the source of the all pages special page for "%C2%A0" in the web developer/inspector console in Firefox. these are only the ones in the main namespace, I did see that some pages in the Talk namespace were also affected though. Perhaps I should go in and comb through the talk pages to see which ones are affected in that namespace too if this is actually reported as a bug?

I'm not sure where to go with this, but I felt I couldn't just do nothing after researching it this much. From what I could see in the archive, should I just submit a bug report via the feedback menu in-game linking to this topic? Also, sorry if this topic is a bit bulky or long, or not in the right place -- Emptysora (talk) 04:26, 13 November 2019 (UTC)

That's the same issue already talked about at Talk:Ideabox. Basically, as you said, there is nothing we can do about it without admin access. I dunno if it was already reported as a bug to the admin, I'll leave that question to the oldest member. As for the why, those "phantom clone" exists, I'd take a guess and say they're probably artifacts of the starting years of the GodWiki, where countless of articles where created, and probably a lot of mistakes with it. --WardPhoenix (talk) 13:42, 13 November 2019 (UTC)
Sorry I didn't reply to this sooner, I'm travelling for work at the moment and spending most of my time in an environment with no internet access. :)
Emptysora, I think it's a very good idea to report this to the Devs under the Ideabox->Other category. When submitting reports like this to the devs, be very, very concise. Focus on a short description of the issue, and a clear action to resolve it. If they have any questions or need clarification they'll PM you on Godville (they ask me to explain more detail when I submit bug reps, other, and terrible awesome ideas all the time).
If I understand correctly, the table above that's introduced with Other pages with this issue: means that you've found other malformed page titles in the Godwiki? I added an {{anchor|malformed-pages}} so that if you need to you can link directly to when you message the Devs about it.
I've noticed that same issue with the Godville (town)&nbsp; page as well, and it's been somewhere on my mental list of stuff to dig into and chase down to report, so I'm absolutely delighted you've looked into it and really done the research to figure it out. I'm a massive dork and I really love bug hunting, which explains why I have 19 accepted bug reports in my Ideabox->Approved list, haha. I see that you have 1 Gratitude point, if you report this and it's fixed you'll earn yourself another one! 😄 -- Djonni (talk) 21:22, 13 November 2019 (UTC)
Just sent the bug report. I like finding bugs myself, so when I see things like this, I don't usually rest until I've figured out what is wrong. I'm pretty sure my gratitude point is from a different bug report (the extra "%" at the end of the "you need XX%% godpower" message on mobile). Well, all we can do is wait. if they use software like PhpMyAdmin (which my private wiki has) it'll be pretty easy to find and modify the pages, otherwise they'd have to use an SQL console. I noticed that whenever such pages are forcibly edited in, creating/deleting/moving a page (anything that updates the "page" table) causes those titles to become hex encoded. I basically suggested they be renamed on the pattern of "*_(old)" so we could go in later and deal with them if need be. I doubt we'll keep the pages since the last time they have been modified is in like 2010 / 2011. I find it funny, just a few days ago, I was too shy to even create my own user page, and now I'm doing this. Thanks Djonni and WardPhoenix. -- Emptysora (talk) 21:54, 13 November 2019 (UTC)
Great work, Emptysora, I'm glad we have your sharp eyes and detective skills on the case. In my experience, if a bug rep is going to be addressed, it will be done quite promptly, usually within a few days. If it hasn't been fixed in a couple of months, we can try reworking the report to be more succinct, or persuasive, or have a clearer resolution and call to action, and resubmit. But I expect we'll see this old problem cleared up pretty promptly now thanks to your work! -- Djonni (talk) 21:58, 13 November 2019 (UTC)
Yeah, if it doesn't go through, I'm going to email the support address directly since email can support images. Images can't be sent via the bug report form after all. That's kind of why I put the search links in there too. I hope it's resolved soon, that #PhantomPage as it was called on the Talk:Ideabox page was bugging me. -- Emptysora (talk) 22:03, 13 November 2019 (UTC)
Well, I guess I have good news. The bug report I submitted is listed in my "approved submissions" page, and I can't find the "phantom" pages anymore. Seems like I have to admit that the devs are awesome (although, we already know that), and thank them. Problem Resolved. -- Emptysora (talk) 17:11, 14 November 2019 (UTC)

Modification to navboxes

Before I go ahead and do this, I wanted some opinions on this idea (which certainly won’t be my last). It’s regarding the navboxes. With the way they are set up right now, on larger navboxes, like the Pets one, it is hard to see where the current page is listed in the navbox.

This can be a bit trying, for example, if you’re trying to see if your pet has an ability from the navbox. What I’m basically suggesting is a slight rewrite of the navboxes such that the links be changed to a template call like {{lnk|Link|Display}} instead of [[Link|Display]]. The “Lnk” template would then detect if the current page is the linked article, and either embolden or link the text based on that. A working demo is in my sandbox and shown below.

It would look like this: Link 1Link 2Link 3Link 4

(((((EDIT: The above Template calls have been removed to avoid having them break things when I modify the sandbox — Emptysora (talk) 15:43, 18 November 2019 (UTC))))))

What are your thoughts? — Emptysora (talk) 01:53, 17 November 2019 (UTC)

Errr..... I don't know if I am misunderstanding what you are trying to say but... Isn't that already the case? I mean when you are in a page which is included in navbox, the page name within the navbox is black instead of blue, which make it very noticeable.
If the link is not blacked (which is the case of the sun dog in pets for example) it's because the link in the navbox is actually a redirect and not the real page article (which is an error obviously, but I think it's actually the Sun dog that may need to be moved to Sun Dog).. -- WardPhoenix (talk) 09:46, 17 November 2019 (UTC)
Nevermind, Sun dog is actually the good capitalization, fixed the navbox link and the text of the pet. --WardPhoenix (talk) 10:34, 17 November 2019 (UTC)
So it apparently does do that, weird, it didn’t do it for me. However I guess that brings me to a different thing I wanted to bring up. I don’t feel like we should be having redirect pages for alternate capitalization. That’s not the point of a redirect. These redirects show up in the search autocomplete, which is annoying sometimes (try typing in “boss” and count how many unique pages are there). If a redirect has to be created just to achieve this, the template really should be modified. That’s not to mention the way that Navbox handles this linking process (See Template:Navbox items, it’s archaic. Ie: what if we have more than a hundred items in a Navbox? The hundredth and so on fails to be displayed. Not to mention, having to call a sub template like that doesn’t seem that intuitive. I guess, what I’ll do, is modify the Navbox template in my sandbox, and update here when I’m done for feedback.
Capitalization should not be a factor in whether or not the link is bold or linked. — Emptysora (talk) 20:34, 17 November 2019 (UTC)
I don't have the first clue about the behind the scenes creation of templates so staying away from that but seems that Sun Dog is the correct capitalization so undid the above change from WardPhoenix, moved pages & redirects around so that Sun Dog is the main page & the only things that link to Sun dog are deity, champion or guild pages. Both the pet & dogs navbox both show bold when on the Sun Dog page now. -- S624 (talk) 21:45, 17 November 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── It does seems that there is inconsistency between how the pets are nammed between diary entry and superhero page, which is why I assumed the false capitalization. I left a bug report about that to admins. Thanks for correcting S624. As for the redirects and navboxes, I don't really understand what you are trying to say there Emptysora. Many of those redirect page are born from people writing an already existing article or from recapitalization / typo / name change/ Obi-Wan Kenobi. And since we can't delete those pages, well they are here. Better to have redirect on them instead of blank pages. And I don't see the link you make between redirect and navboxes, they are differents things, abd ideally, a link in the navbox should lead to the correct page, not the redirect one. --WardPhoenix (talk) 21:58, 17 November 2019 (UTC)

No, what I’m saying is that capitalization shouldn’t matter in whether or not the page is linked or emboldened, eg: if the box says “Sun Dog” it should be bold on Sun dog and Sun Dog, even if one of those pages is a redirect. (which it currently doesn’t do). This is important because if the capitalization of the content page’s title ever changes, it breaks the navboxes. (EG: if Sun dog was moved to Sun Dog, or vice versa) I agree that the link in the navbox *should* point to the page and not a redirect, but whether or not it does shouldn’t break the template.
In other words, I’m trying to change the templates such that in-game capitalization does not dictate how we have to list things in navboxes. It’s just less of a chance for confusion. Arguably, the fact that this did confuse me, might be proof that is a decent thing to consider.
As for the redirects, I use Wikipedia a lot (which uses an extension called CirrusSearch) so they have redirects hidden from search results. I assumed this was default behavior in MW (which clearly isn’t the case). So, I doubt there’s a reasonable fix we can do to resolve that:
1) Either, we delete capitalization redirects. Search suggestions won’t display the five redirects all to Boss-monsters. But, if someone typed “Boss-M” Boss-monsters won’t appear. That leads into what you said about those pages existing because people created them assuming they didn’t exist. Ie: the pages are liable to be created again, ruining the point of deleting them. 2) We somehow manage to convince the admins to install an extension like CirrusSearch (which odds of happening, I bet, are 0%). This would transparently hide the redirects resolving *both* issues. This implies: 3) We do nothing. The redirects that clog the search suggestions potentially continue to either annoy or confuse readers, but since the redirects *are* present, nobody will get confused about whether or not a page exists.
Apparently, MW (until 1.23) used to have a setting you could change to hide redirects from search results. I’d love to hear why they thought it was brilliant to force wikis to always have redirects included instead of leaving srredirects and defaulting it to true.
Anyway, I’ll modify the templates in my sandbox and show you what I mean. We can discuss that after that. — Emptysora (talk) 23:59, 17 November 2019 (UTC)
I just modified Template:Navbox items/Documentation adding in example code for a slight hack to get 100+ items in a Navbox list (multiple items template calls, the second and subsequent omitting the first unnamed parameter) so, I guess we can ignore that one. I’m only going to try to do the bold thing. That way we don’t have to manually modify the navboxes each time the pages are moved and shuffled around.
I thought the navbox template hadn’t been edited in years which is why I thought to overhaul it. That’s not the case, however. No need to change something that already has been updated and works (which is why I’m going to do the bold thing) — Emptysora (talk) 02:13, 18 November 2019 (UTC)
Well, a couple things :)
Firstly, I do see your point about capitalisation in navboxes, but. Capitalisation changes infrequently in the game, and we consider capitalisation an important part of the Godwiki's accuracy. So the statement That way we don’t have to manually modify the navboxes each time the pages are moved and shuffled around actually doesn't make a lot of sense on this wiki: if the capitalisation of the navbox entry and the capitalisation of the page don't match, one is wrong and should be changed. In many wikis there are genuine debates about how something should be capitalised, but not here. If someone moves or corrects a page, then we do need to go around fixing capitalisation elsewhere that it's wrong, and that includes navboxes. That's what we did when you pointed out the Sun Dog issue. :)
Don't get me wrong, I approve of the general idea of making stuff work smarter, but personally I think that in this case, all it would really achieve is hiding an error, making it less likely to be fixed. Since game items do have a canonical capitalisation, both the page titles and navbox should reflect this and match. Anything else is wrong.
That said, I certainly invite improvements to templates and their documentation at any opportunity. But you'll often find there's clear reasons why some things are done some ways, such as {{navbox list}}:
  • Calling a sub-template allows for the entry of free text of necessary, because:
  • We don't have Lua, or string parser functions. So we have *very* limited techniques when it comes to intelligently figuring out what the content of a parameter is, other than a straight {{#ifeq: or {{#switch:. So,
  • No unlimited parameters here — any supported parameters must be hard-coded into templates.
And to a Wikipedia user, the word archaic would be pretty accurate for any Templates here; on Wikipedia, even the simplest templates were converted to Lua long ago, and do things like prettifying section links, that we straight-up can't do.
That's not intended to discourage you from figuring out ways to improve the navbox templates, and of something needs overhauling then that's cool too. :)
Oh, and another thing, heh. 1) Either, we delete capitalization redirects. Nope, "we" don't. No user has deletion rights, and I would be surprised (delighted, and surprised) of the Devs would have the time to do a minor perfect like that, as we have ~8 years of accumulated not-deleted pages to wade through. If at some point in future a new admin is appointed to replace the long-gone Spode, then that would definitely be something on his or her agenda.
Honestly, for Wikipedia users, this place has many frustrations quirks. It's somewhat less than a vanilla Wikimedia, as you've discovered. But switching off redirects in search results seems like an excellent thing to suggest (Ideabox->Other), as they are definitely a clutter! -- Djonni (talk) 03:35, 18 November 2019 (UTC)
Couple more things! :) Firstly, apologies if I'm not making complete sense, I'm gravely undercafiennated and just boarded a 4:30am train across the country, so I'm a touch addled. Which also contributes to, secondly, I hope my reply just now didn't seem curt or harsh in any way, it definitely wasn't meant to. And thirdly, on your point about no more than 100 terms in {{navbox items}}...
I can see a benefit to adding a recursive call to navbox items at the end, something like: Moving this to Template talk:Navbox items! -- Djonni (talk) 04:28, 18 November 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I had no idea recursive calls even worked, I thought they just result in the template name being included in bold...? Also, I’m not off-put. Though I definitely was concerned when I realized the template was recently edited. I used “archaic” not to mean “old in a rude way” (Sorry if I came off that way) more just “old.” I’ve been writing in my spare time recently, so words like that pop in when I’m not paying close attention.

As for the deletion, I know, I just typed that for form/convenience. (Ie: Mark for deletion).

As for capitalization, I can respect that, but, unless you explicitly have said pet, or encounter said monster, and reach the wiki from there, with the express intent of finding such an issue you’ll never realize the capitalization is off anyway, (and it will likely cause confusion as I experienced). If, despite this, you think we should still keep it the same, that’s fine. I just wanted to point out that there’s probably only a handful of people keeping it this way would matter to (namely us).

So, do we prioritize convenience for editors / maintaining consistency in-game, or do we prioritize convenience for readers. I’m fine with either, though, since I read a lot, I’m leaning the latter (obviously).

Heh, modifying templates for the better is one of the things I wanted to do. When I first made this topic, I barely read the source for it. Sorry. — Emptysora (talk) 08:18, 18 November 2019 (UTC)

One of the reasons I was confused by redirects, is because on mobile app Wikipedia, search results may say “Redirected from: X” but it doesn’t when it’s just a capitalization thing. That’s why I assumed the redirect thing was by default.
Also, I don’t think there’s a way to “turn off” redirects per se. if there is, I’d like to know, since it’s an issue on my private wiki, and I’m too lazy to install CirrusSearch right now. — Emptysora (talk) 08:35, 18 November 2019 (UTC)
Very short on time but just had to say: 😆 with the express intent of finding such an issue you’ll never realize the capitalization is off anyway...
The longer you spend pottering around the wiki, watching recent changes, and seeing the edits made by non-regu are wiki contributors, the more surprised you'll be able what people do and don't notice and keep track of here. This game definitely attracts cataloguers, meticulous record keepers, and attention-to-detail personalities... We would know, since most of those who read these words will be that kind of person! 😉 -- Djonni (talk) 08:54, 18 November 2019 (UTC)
I have a sudden random thought that remind me why capitalisation (or at least spelling ) is important. Double eyepatch, Double eye-patch and Double eye patch all exists and are different items. -- WardPhoenix (talk) 09:54, 18 November 2019 (UTC)
New personal goal:
Djonni's Diary
Submit "Double-eye patch" to the Ideabox and get it added to the game
;) -- Djonni (talk) 09:59, 18 November 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Heh. Maybe I should try double-eye-patch or double-eyepatch then.

In the very least, on the wiki, we should be consistent. I don’t know if there’s a GodWiki:Capitalization or similar page, which if none exists, we should probably create one. If we have, or make, one, we could link it in the Guideline articles. — Emptysora (talk) 10:47, 18 November 2019 (UTC)

Just modified the initial post to remove the template calls so they don’t break when I inevitably forget this discussion exists and change my sandbox.
I’ll abandon the link thing. I still think we should create a caps article if one doesn’t exist. It’d be a nice resource to reference while I’m editing metadata/redirects. — Emptysora (talk) 15:43, 18 November 2019 (UTC)

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)
I'm joining this conversation pretty late, and FeRDNYC hasn't been around the wiki since April... does anyone know if he went ahead with the plan? I think it's a very good idea, speaking from my own experience with an unredirected talk page! -- Djonni (talk) 09:03, 12 September 2019 (UTC)

I don't think he end up doing it, but I could be wrong.--WardPhoenix (talk) 13:29, 12 September 2019 (UTC)

Yeah, alright. I found his draft at User:FeRDNYC/User Talk Message. I think it's a bit wordy personally, and gets a little lost in the weeds about the history of notifications on mediawiki sites, and needs a heavy edit. But I think his idea is really good and we should work up a better draft and go ahead with it.
It's a shame he isn't around at the moment (I'll leave him a talkback regardless!) because he went to the trouble of compiling a list of the affected users and we don't have it! I'll have to do that myself. -- Djonni (talk) 15:07, 12 September 2019 (UTC)

{{Navboxlists}} update

So, on my Sandbox page, I have been working to see how we could improve the lists included in the {{navboxlists}}, I copy pasted the work above so you can see how the edit button appears and how the editable content would appear, while the 8 is how it is at the moment in the lists.

I also tried different format ,my personnal preference going to the one presented in the -2-. Adding the edit button directly in the list like in 5 or 6 are risky because it became easyy to break the whole thing.

The pros of this update:

  • Easier to update lists, since we can edit directly to the letter, instead of having to scroll to the whole alphabet in the edit box.
  • The deities with old phones that doesn't have enough RAM (like mine...) will no longer have crash issues when trying to update the lists from mobile.

The cons of this update:

  • Well, it's obviously not as good looking.
  • Columns width are inconsistent (maybe can be fixed)


I've been watching your work on this with interest, trying to think along with you about how best to handle this. I agree, it would be good to find an elegant solution.
I'll add one more point to the list of cons with separated tables:
  • List is no longer sortable in a useful way
Inconsistent column widths can be fixed, simply by setting fixed % widths to each column in each table.
I have an alternative solution that I've been working on mentally. It's very hard to give a demonstration, however, as the solution requires making a subpage for every section. And it definitely has its own pros and cons. I'll try and explain it as clearly as I can.
On the List of... page, you would have a table that looks like this:
{| class="wikitable sortable" style="width: 100%;"
|- id="Title"
! colspan="3" |<big>Artifacts</big>
|- id="Index"
!  colspan="3"  | <big>[[#s_0|0]] [[#s_1|1]] [[#s_2|2]] [[#s_5|5]] [[#s_6|6]] [[#s_8|8]] [[#s_A|A]] [[#s_B|B]] [[#s_C|C]] [[#s_D|D]] [[#s_E|E]] [[#s_F|F]] [[#s_G|G]] [[#s_H|H]] [[#s_I|I]] [[#s_J|J]] [[#s_K|K]] [[#s_L|L]] [[#s_M|M]] [[#s_N|N]] [[#s_O|O]] [[#s_P|P]] [[#s_Q|Q]] [[#s_R|R]] [[#s_S|S]] [[#s_T|T]] [[#s_U|U]] [[#s_V|V]] [[#s_W|W]] [[#s_X|X]] [[#s_Y|Y]] [[#s_Z|Z]] [[#s_ZZSpecial|Special]]</big>
|- id="sort separator"
| colspan="3" style="display: none" | <br>
|- id="s_0"
!  colspan="3"  style="text-align: center;" data-sort-value="0" | <big>- 0 -      </big><small>[[#Title|Top]]</small><div class="plainlinks" style="float:right;">[ Edit 0]</div>
{{:List of Artifacts/0}}
|- id="s_1"
!  colspan="3"  style="text-align: center;" data-sort-value="1" | <big>- 1 -      </big><small>[[#Title|Top]]</small><div class="plainlinks" style="float:right;">[ Edit 1]</div>
{{:List of Artifacts/1}}
|- id="s_2"
!  colspan="3"  style="text-align: center;" data-sort-value="2" | <big>- 2 -      </big><small>[[#Title|Top]]</small><div class="plainlinks" style="float:right;">[ Edit 2]</div>
{{:List of Artifacts/2}}
|- id="s_3"
!  colspan="3"  style="text-align: center;" data-sort-value="3" | <big>- 3 -      </big><small>[[#Title|Top]]</small><div class="plainlinks" style="float:right;">[ Edit 3]</div>
{{:List of Artifacts/3}}
0 1 2 5 6 8 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Special

- 0 -      Top
{{:List of Artifacts/0}}
- 1 -      Top
{{:List of Artifacts/1}}
- 2 -      Top
{{:List of Artifacts/2}}
- 3 -      Top
{{:List of Artifacts/3}}
etc. Then, you would have each subpage like this:
List of Artifacts/0
| [[0% discount coupon]]   ||   ||  
List of Artifacts/1
| [[1-calorie meal]]   ||   ||
| [[1-for-the-price-of-2 voucher]]   ||   ||  
| [[100-lb feather]]   ||   ||  
| [[12th step]]   ||   ||  
| [[19th hole]]   ||   ||  
| [[1x magnifying glass]]   ||   ||  
List of Artifacts/2
| [[2 pcs (2 pcs)]]   ||   || 
| [[24k goldfish]]   || B ||  
| [[25-hour clock]]   ||   ||  
| [[2D hologram]]   ||   ||  
etc. Each subpage is transcluded into the main page, and would be invisible until you look into the page's wikicode, or hit one of the "Edit x" links on the right.
  • The table remains intact, and attractive
  • Any problems/breakages are very easy to isolate and fix
  • Each sub-page has a clear and simple structure that you can easily contribute to without any wiki knowledge
  • The table doesn't need to have 30-something headers
  • The table will still be sortable
  • The sections are only editable on their subpages, you no longer have the option to edit the entire list together
  • The 'edit' button at the top of the List of... page becomes useless
  • The edit history of the list becomes spread across 30-something different pages
I'm not at all convinced that this is a good idea. But it's the only other approach I can think of than using headers throughout the lists. I offer it mostly for contrast and comment. -- Djonni (talk) 14:42, 25 November 2019 (UTC)
Take a look at this: Wikipedia:List of words having different meanings in American and British English (A–L). This is how the other wiki does long lists. I don’t think transcluding wiki markup for a table is a very bright idea, that can still easily break, and be nearly impossible to find why. Arguably, being split over 30+ pages makes it harder to find. It also means we have to manage 31+ pages—per list.
On bulbapedia their “List of Pokémon” article is done multiple times instead of being forced to use sorting.
Things in-game have no real categorical value aside from: normal (all), italic, bold, activatable (artifacts), strong, boss, beastie, pet, (monsters), [skill type] (skills), [equipment type] (equipment), Epic, mini (quests), and so on. We could have: List of Artifacts, List of Bold Artifacts, ..., List of special monsters by type, List of Skills by name, List of Skills by type, ... etc.
Those all make some amount of sense (not that your ideas don’t), and would be useful to the other users. Eg: instead of having to fish through, List of Artifacts on mobile when a clue says “Bold artifact” you can just go to “List of Bold Artifacts”.
I say List of Special Monsters by Type because, special monsters account for a minuscule fraction of monsters. It’s so few our navboxes handle that job. (Hence a combined page)
Personally, i don’t think there is a correct solution for this per se. I believe that a mixture of our ideas are the solution. That being said, there is a guideline on Wikipedia that says that large articles like Wikipedia:America should be split up into smaller ones. Our list articles (especially omnibus, though that’s the point of it) are massive.
Either way, whatever we do decide to do, we need to keep a very close eye on the List articles so items don’t go missing. — Emptysora (talk) 16:29, 25 November 2019 (UTC)
I can hardly go with your idea Djonni, when i have a full inventory of artifact and have a few to update, I don't really want to have to switch from 10 thousand pages! But thanks for sharing an idea for us!
I still prefer the header idea, like the 1st link on wikipedia that Emptysora shared. Safer, and it still sortable, we just need to put the first line every time, but that's not an issue IMO.
On a side note, I don't think it's necessary to create specific lists like "List of Bold Artifact" and co for numerous reasons:
  1. More lists/pages means more possibility of not being consistent across the wiki. We're already have sometimes issues with the "Lists of" and the Omnibus not being consistent (or even sometimes the article), no need to add more.
  2. More lists/pages means its, IMO, less user-friendly. Let's be honest, not many people are fluent with the wiki and may create mistakes.
  3. I don't think it's necessary to have specific lists like "by name", "by tape", when the table is sortable and when you have at the top of the page, links to every letter, and at the bottom left a magnificent {{top}} template to jump back to it. If you really search something specific, there is nothing a CTRL-F can't do I think.
Still thanks for the feedback! Let's keep the idea coming! --WardPhoenix (talk) 19:00, 25 November 2019 (UTC)
I happily drop my suggestion then! The header sections are the best approach. I'll get over the fact that I can't sort every bold item in the list to the top. 😅
It's worth noting, though, that for most users there's no ctrl + f searching for text in a page. Most people just use the in-app browser, which is super limited and along the many things it can't do is search within a page.
Also... maybe it's just me being an old crank, but I strongly resist things that turn the Godwiki into a glorified crossword solver. So, thinking about that... perhaps it's actually great if the big lists are no longer sortable for bold/strong etc 😈 -- Djonni (talk) 19:20, 25 November 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Sorry, was going to respond sooner, but then I found myself in hel—I mean, updating my private wiki.

Anyway, I agree, the Wiki isn’t a crossword solver. Anything we can do to prevent that is welcome in my opinion. I use the “Open in Safari” option when clicking the export/share button to access Safari’s “Find In Page” feature on that export/share menu. The find feature sucks though. It only searches from word boundaries at the start of words eg: searching for “onster” will not match “monster”. No way to change it.

The multi article list thing would work, if it wasn’t for the fact the items on our lists change more than daily. Ie: a gen IV national dex list will always have the same 493 entries on it. Ours, well... we have hundreds of items, and the exact number keeps growing. Asking someone to edit five plus articles at a time consistently is a pretty tall order.

The reason I suggested that was because searching for bold, activatable, etc. artifacts is annoying on mobile.

My vote goes for the == Headers == approach. Like on the other wiki.

Emptysora (talk) 23:39, 25 November 2019 (UTC)

Changed the List of Artifacts, feel free to check for errors and possible improvement! --WardPhoenix (talk) 10:50, 26 November 2019 (UTC)
Awesome WardPhoenix, absolutely fantastic change to the page. I made a, erm, possible improvement or two, emphasis on possible.
Two minor changes, I've made every section table collapsible, and made the navigation links point to the new headers.
One fairly significant change: I've added an experimental index down the right-hand side of the page. Now, on desktop it seems to work fine for me. But on my mobile device, the list gets down as far as U before being cut off. So, we can either scrap it (but I feel it's quite useful?) or perhaps change it to be two columns wide instead, and take up a little more screen real estate. Any thoughts? (If your thoughts are "that's a terrible idea" I won't take it personally at all.) -- Djonni (talk) 11:24, 27 November 2019 (UTC)
So that we can compare the options, I updated it into a two-column format. The page's current version has two columns, and the previous version has one, you can try both out.
On my mobile device's screen, the two column fits better, but obscures just enough of the right hand side of the screen to be a little bit annoying. -- Djonni (talk) 11:45, 27 November 2019 (UTC)
Thanks for placing the link to the headers, it's way better! I dunno if the collaspable is useful, but well, if some want it, it's there.
As for the Index, I REALLY like that idea, but I think it may need tweaks. First, on my mobile I can't have access of the last row (! and ↑) because it's hidden behind the zoom options (but that may be only me). Secondly, as you pointed out, it's eating on the right side. Maybe we can change the value of the table to have a total of, let's say, 90%, instead of 100% so the tables and the index wouldn't interfere?
As for the one or two-column format, for me it's a no brainer. Two column. One column doesn't display entirely on phone. --WardPhoenix (talk) 15:25, 27 November 2019 (UTC)
Okay, assuming we're sticking with the two columns then! :) I narrowed the tables to 95%, which is about right on my device, but obviously that can be tweaked. How is that width for you? -- Djonni (talk) 16:07, 27 November 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Looks fine on my side, that index is defintely one of the greatest idea you had. The index do cut a little on the table, but it doesn't cut any character. If we keep the lateral index, do you think it's necessary to keep the main one (and thus linking the ↑ to the type maybe?) Well, this needs even more feedback. --WardPhoenix (talk) 17:08, 27 November 2019 (UTC)

So, the list-article have been updated with the index (not the finger) Djonni provided and with headers, making it easier to edit. --WardPhoenix (talk) 14:51, 2 December 2019 (UTC)

Justifying the new list pages

I have some... concerns, I guess, about the new list pages created recently: List of Diary Phrases, List of Earthly News, and List of Greetings. (I'm going to explicitly invite the creator of the new pages, Uni34, to join this conversation (Hi! 👋), and I really want to start by saying that I don't think Uni34 has done anything wrong! She saw a gap in the wiki, she was bold, and she created the pages she felt were missing. That's good. 😊 But as per paragraph three of the Be Bold page, sometimes we all end up doing things that need further discussion. 😊)

I refer to the last paragraph of the Godwiki Guidebook, which I think sums it up:

Refrain from making lists of items instead of articles. Having just a list of game objects will only reduce the fun of discovering them in the game. Having an interesting (and not necessarily real or serious) article about the game object will be much better.

Now, obviously, we do have lists of game items that have always formed the backbone of the wiki, and not just the obvious ones. We have, of course, lists of artifacts, monsters, boss monsters, equipment, skills, towns, achievements, quests, and the omnibus list, and there are other lower profile lists in navboxes and hidden all over the place. Each list has its uses to players, obviously some more useful than others. And all except the omnibus do something very important for the Godwiki — they are a linked index of the pages that do and don't exist for their respective game items, allowing world-building Godwiki content written by players to be created and found.

My main problem with the three new lists is that, as far as I can see, they achieve neither of the things that justify making a list (be useful to players; be an index for Godwiki content), and they duplicate content from the diary/game that I, for one, would really rather not have popping up in search results, for exactly the reason above — it spoils part of the fun of the game. I can't really think of a use for those lists, and nobody's going to be writing Godwiki articles about every Diary entry, piece of Earthly News, or Greeting in the game.

I also think that the Diary and Earthly News lists will be extremely challenging to meaningfully maintain. We already have major problems with the accuracy of the list of quests, every single little correction submitted by any of the ~15k players would make those lists less and less accurate over time.

But, of course, I might not be seeing a good reason to keep some or all of them. If there are good reasons to keep them, then we need to explain that reason on each of the lists, because honestly, I suspect the Devs will delete the pages when they see them.

So, everyone's input is useful here. Are there reasons for keeping any/some/all of the new lists? How are they useful to players? -- Djonni (talk) 12:05, 4 December 2019 (UTC)

Agreeing with everything said but one thing. It could be useful for ideaboxer, especially those who try to find their approved idea in the game. But, is it enough to make those lists worth? I don’t know. -- WardPhoenix (talk) 12:31, 4 December 2019 (UTC)
The Ideabox is the main reason I created these lists. But it's not the only reason. And the fact that the lists may be spoilers is not sufficient reason to delete them. A lot of content on GodWiki is spoilers. I'm sure there are a lot of users who don't want to see a list of quests, for example. But do we delete it? No, because some people want it. It's the same here. The only difference, I guess, is that quests have articles and diary phrases/greetings/earthly news don't. But come to think of it, most quests don't have articles and I can see the items in the new lists having articles too. --Uni34 (talk) 08:49, 7 December 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Well... Looks like the devs passed by and decided otherwise, nothing we can do about it. Though a warning or an explanation for the deletion would have be kind of nice we got neither but only a blunt deletion log, which is an answer in a way i guess. --WardPhoenix (talk) 14:25, 9 December 2019 (UTC)

The Monstrous Recapitalisation of 2019

So, the way the game handles capitalisation after a hyphen in a monster name has changed recently. The Ideabox has always automatically capitalised monster ideas, but it didn't historically treat a hyphen as a word break, and it does now... Mostly. A word after a hyphen will be capitalised if it is at least 3 (or maybe it's 4) characters long. This is an attempt to make sure that articles and short prepositions in hyphenated words are not capitalised, according to traditional title caps rules. And, of course, ER editors can manually change capitalisation in cases where that simple rule hasn't quite got something right, as they always could.

At the same time, existing monster names in the game have been recapitalised to match normal English typography. The recapitalisation seems to follow these rough rules:

  1. Where something after a hyphen was already capitalised, it has stayed that way (the only changes are to previously lowercase letters immediately after a hyphen)
  2. Articles and prepositions after a hyphen remain lowercase, as they would in a title (e.g. Monster-in-Law), but not entirely consistently (see point 1, e.g. Missing-In-Action Figure)
  3. Word fragments, e.g. Arrgh-onaut, remain uncapitalised, but not entirely consistently (see point 1, e.g. Flame-Ingo)
  4. Otherwise, words after a hyphen have been capitalised pretty consistently.

This post here is essentially to signal that there will be some monster pages that need to be moved to their new capitalisation, and edits being made to List of Monsters as well as monster articles as required. I'm going to do a lot of this, but even taking advantage of some extra external resources I probably won't catch everything, and there's a chance I might move or correct things to a wrong capitalisation.

If you see a hyphenated monster name in the game, and that monster is capitalised differently on the Godwiki, then we need to fix it! It can be a bit of work to make those changes, though, so if you spot something wrong but don't have the opportunity (or perhaps knowledge) to do it yourself, please leave a note about it (right here, or on the monster article's talk page if that's easier) and another editor should get the changes done mañana.

That said... if you think you don't have the skills you're probably wrong. Be Bold, try to do it yourself, and if someone can see you're struggling or not getting it right they'll clean up after you. No muss, no fuss, no worries. It's really not more work for an experienced editor to fix a mistake someone else makes, than for that editor to do the work in the first place, so you're never creating more work for someone else!

A brief checklist for myself and others:

  • If the monster has an article:
    • The article must be moved to the correct name. (Looking at original article, the "More" menu in the top right has the "Move" action. Is this also true on mobile? Can't recall and can't currently check.)
    • Text in article body corrected as needed. {{Monster}} infobox should be fine, as it uses the {{PAGENAME}} magic word by default, but double-check for |title= parameters or unusual description text.
  • List of Monsters to be updated.
  • Check for a relevant navbox and update. (A text search will only include the main namespace by default, but hitting 'Everything' or 'Advanced' in the results will allow searching of templates.)
  • If time permits, search for text in pages with the old capitalisation. Put quotes "..." around the name to get the right results. (Two birds with one stone: correcting the capitalisation and an opportunity to increase interlinking if the monster has an article.)
  • If time permits (lowest priority though, I think), update Omnibus List. The main users of the Omnibus are crossword solvers, to whom capitalisation is irrelevant.

(Please feel free to add to or alter that checklist if I've missed something.)

Obviously, this is a fairly low priority and on-going project, so it'll take a while and a bit of work to get done together. :) -- Djonni (talk) 08:44, 12 September 2019 (UTC)

Call for feedback on new {{Usergod}} template

Notey.png Feedback required

Hello all!

This is an official call for anyone interested to test and give feedback on the draft of the new {{Usergod}} template. If you want to get stuck in straight away, you can leap to the fully documented draft at User:Djonni/Template sandbox.

To begin testing the new template straight away, if you already have the Usergod template on your page you can simply replace {{Usergod with {{User:Djonni/Template sandbox to see how it will look with the new template.

In short, the {{Usergod}} and {{Usergoddess}} templates haven't been updated since 2013, and they really need it. We have modernised and made pretty all of the {{Monster}}, {{Artifact}}, {{Equipment}}, etc. infobox templates, and with the lessons we've learned there, it's time to get to work on the big ones: {{Usergod}}, {{Hero}}, and {{Guild}}. This is the first of those to hit the bench.

In the redesign I have tried to keep to several principles:

  • Don't mess up existing pages. The Usergod template is currently used on 203 Godwiki pages. Many of those pages have made very specific choices about colours, styles, backgrounds, etc. This is why, by default, the new Usergod template will be transparent: the old template has been transparent for over 8 years, and it should be entirely up to you, the template user, how your Usergod infobox looks. Which leads to:
  • Allow for a large amount of customisation, as simply as possible. I have investigated quite deeply (I think) how those existing 203 users of the template have used it, and tried to look at what they wanted but couldn't get from the existing template. The replacement has a large and flexible suite of colouring, styling, and creative options there to use, all of which are completely optional. It can be as elaborate and detailed as you like, or just a quick, simple summary of your most interesting and important features. Whatever you want.
  • Try not to force any decisions onto you, including gender norms. Don't want to be called either God or Goddess? No problem, set |title=The Great and Powerful, or =The Divine, or =Furmeister General, or anything you want. Don't want your minion to be called Hero or Heroine? Great, |herolabel=Champion, or =Minion, or =Kōhai, or whatever you like. If you see a way to make the template more customisable, please say so, and if I can realistically do so, I shall.
  • Expect the unexpected. I have not tried to guess everything you'll want to do with the template. Instead, I've tried to make the template capable of doing anything you might want. There are options to create fully customised sections of the infobox, which you could use to: embed your hero(ine)'s details into it; prominently feature forum roleplaying character sheets; proudly display your pets, ark, achievements, skills, pet peeves, anything. People really tried to get creative with the old Usergod template, and it just didn't allow them to. So, this one does.

As implied above, updating {{Usergod}} is phase one; after the new Usergod is finalised and put in place, phase two will be {{Hero}}. Depending on the feedback received, my observations of how the new templates are used (or not used), and the level of interest, phase two may also involve designing some additional related templates: {{Pet}}, {{Lab boss}}, {{Ark}}. Then finally, after a lot of feedback and testing, the {{Guild}} template will be updated. This will be the most difficult and controvertial, as it's the most heavily used template on the Godwiki (at this moment, there are exactly 500 pages using the Guild template), and for many people, their guild page is the only thing they interact with on Godwiki.

Feedback, discussion, and questions about the new template can be given right here, or at User talk:Djonni/Template sandbox. You'll also find some discussion and feedback from early testers at User talk:Djonni and User talk:WardPhoenix/Sandbox if you're interested.

I'm looking forward to hearing from folks about everything that's wrong with the new Usergod template, so that we can make it better together! -- Djonni (talk) 08:43, 3 November 2019 (UTC)

Update: Just a quick note about a couple of additions made recently to the test template, and about feedback I'm getting publicly and privately!
Firstly, I noticed that some user pages have chosen to specify pronouns, and some people have been modifying or adapting existing infoboxes to do so. So the Usergod test template now supports a |pronoun= parameter, which, if specified, will appear below the row where gender appears (if specified). As with all parameters on the new template, it's optional. I've included the parameter in the documentation example, set to the intentionally slightly silly and non-specific |pronouns=Hey/Oi. If anyone wants to suggest a more suitable example, please do.
On a personal note, I'm a bit embarrassed to admit that, as a cis-gendered person who has never in my life needed to specify my pronouns, it took me a long time to realise that for a number of our users that could be important. If anyone can point out other simple things I've missed which may increase the inclusivity and accessibility of the Godwiki/{{Usergod}}, those things are extremely important to me and I'm always open to listening and acting. I have always tried and will keep trying to put inclusivity and accessibility to the front of all the work I do here.
Secondly, after feedback and discussion with some testers (thanks everyone!), I've added the Guild pantheons for those who want to show them, in the spirit of "let people do what they want to with the template". The docs have been updated to reflect the changes, and they are exactly what you would expect them to be: |unity=, |popularity=, |duelery= and |adventure=. As with the other pantheon groups, |pantheonsubheaders=yes/no will explicitly enable or disable the group subheader.
Finally, a lot of the feedback (more thanks to everyone!) has pointed out that the template could be a little overwhelming or intimidating for new users. I completely agree. What I'd like to do, just before launching the new template, is restructure the documentation so that there's a very simple section at the top with only the basic options, and perhaps a couple of suggested colour options, and then additional sections below with the rest. Hopefully it's obvious that the way the documentation is set up now is just for testing, and testers. A complete rewrite of the docs will be, I suspect, the biggest job left before launching the new template. Doing.png In progress...
On which last point, I would love to get the template in place before December so that it's out of the way for the run-up to JanuWiki, which is rapidly sneaking up on us! The JanuWiki prep will become my no. 1 Godwiki priority for December! 😄
Thanks again to everyone who's been testing the new template. Even if you haven't given me any direct feedback, just seeing what people are (and aren't) doing with it, how they're using it, and what they're finding difficult or confusing about it is really helping. So please, keep playing with it, breaking it, and pushing its limits! -- Djonni (talk) 08:07, 21 November 2019 (UTC)
A few small changes I made today to the test template.
While working on other infoboxes recently, I realised that none of them have a full colon : at the end of the labels. Which, y'know, makes sense, and should have been obvious to me. So, to keep in style with the existing infoboxes, I've taken the colons off the labels throughout the infobox.
I've also removed the fairly useless linking of the Pantheon names to the Pantheon pages (I doubt anyone's really going to discover a Pantheon they didn't know about from a User page). This is to allow for better colour styling: since link colours cannot be changed, the more links there are, the harder it is to style colours.
And so, I've also added two new parameters, |guildlink=no And |herolink=no. If set, the guild and hero names won't be made into links. This allows people to set any values they like without a link to a dead page, as well as allowing those who want to colour their text to do so.
For anyone interested, Emptysora suggested a way to have both coloured text and a link, which you can find at User talk:Djonni/Template sandbox § A bit of a hack for the link colors.
As the end of the month approaches, I'm getting closer to releasing the template into the wild. So please be sure to make any last minute suggestions or complaints ASAP! I'm going to expand the supported length of the custom section for 40 rows to... Well, more rows, but aside from that I'm pretty great to go.
My biggest hesitation right now is the width issue on very narrow screens, as reported by GodHoly Spirit of Hell  in the forum. It really bothers me, I'm sure it's solvable somehow... But it's always the image widths not being dynamic that ends up as the breaking problem. |upright= unfortunately doesn't help here. -- Djonni (talk) 11:44, 25 November 2019 (UTC)
Alright, I've been procrastinating on this for too long now. Last chance to voice concerns, otherwise I'm going to go ahead and launch the new template tomorrow or the next day
The narrow-screen issue can't be solved without access to site CSS, which is something discussed with and rejected by the Devs many times in the past. Perhaps we'll have a proper Godwiki player admin at some point in the future — until then, we can't fix that, I'm afraid. -- Djonni (talk) 17:08, 11 December 2019 (UTC)
I have not been shy in experimenting with it and voicing ideas and criticism. Overall it is a very good improvement and I approve. As more people use it, we will get more feedback going forward and can't make improvements until then. I am anxious for you to move on to hero's and guilds. ;) Thank you --Sand Devil (talk) 18:08, 11 December 2019 (UTC)
Well, the new template is now live, with reworked documentation to try to give a beginner an easy start.
Not just yet, but soon I will be using the User:Djonni/Template sandbox page for the next project. If you've tested the template, firstly, thank you very much. Many of you gave me really helpful suggestions, feedback, advice, requests, criticism, and reports of unexpected behaviour. Even if you didn't actively give me feedback, by watching what people were doing with the template I learned a lot about what it should be doing.
Please point all your {{User:Djonni/Template sandbox}}es to now use {{Usergod}}. In a few days I'll leave talk messages for anyone who's still using the old sandbox page. Thanks again everyone, and hopefully the general Godwiki populace likes the change to the new template. It can still be undone if necessary, of course. -- Djonni (talk) 20:15, 12 December 2019 (UTC)

Articles about content that's no longer in the game

So, we've started finding more and more articles that are about content (artifacts, monsters, equipment, quests, skills, pantheons...) that is no longer in the game for various reasons. I think it's time we worked out what we do with these things.

Firstly, I think that deleting a contributor's creativity and work on the Godwiki because the item's gone is a shame. My vote is that articles are preserved, with a hatnote, and possibly categorised (perhaps Category:Articles about things that are no longer in the game).

However, I would equally argue that deleted items should be removed from the relevent 'List of...', and the Omnibus. If they aren't in the game any more, then they shouldn't really be there, I think.

A hatnote could look something like this:


This article is about something which is no longer in the game

This subject of this article was once a part of Godville, but is no longer. It is kept here for its historical or creative value. Please do not delete this note or the article's content without discussing it on the talk page first, however, creative contributions and additional accurate details are still welcome.

No styles applied to that example, of course, we can decide on that if we like the general idea. Whaddaya think? -- Djonni (talk) 12:57, 25 November 2019 (UTC)

I definitely like that. I feel bad about going through and effectively playing god with “what gets to stay, and what gets deleted.” I mean, it’s one thing if the creator of something blanks a page (which is somehow systematically done), but, if it’s just left there, I don’t want to just get rid of it. A lot of guilds put a lot of effort into their pages. It’s a shame to permanently delete them. — Emptysora (talk) 13:20, 25 November 2019 (UTC)
For guilds in particular we need to tweak the message. After all, a guild with the same name that used to exist but now doesn’t, could come into existence again. We shouldn’t bar them from editing their own guild page because someone else had a guild with the same name.
Things removed from the game should unquestionably be removed from lists whose sole purpose is detailing things existing in the game. It’s just clutter at that point. However, I think we should add another list page “List of content removed from the game” with headers for Monsters, Equipment, Pantheons, etc.. At least that way, something links to those articles and they won’t just be dead. We could actually use THAT talk page to discuss whether to move items there. — Emptysora (talk) 13:27, 25 November 2019 (UTC)
Well, just to clarify, we already have guilds covered with {{Delete guild}}. Inactive deities and their heroes and heroines can remain here until the day they return to the game or the sun explodes, whichever comes first.1 I'm not talking about user (god, hero, guild) pages here, I'm talking about objects or mechanics from the game that have been removed.
Note 1: There is one important exception to this. If a god no longer exists in Godville at all, they have requested that their account and all of its data be deleted under GDRP. If we stumble upon a User page with no corresponding User, an Ideabox -> Other should be submitted to alert the Devs, and they can decide what should be done for GDRP compliance. -- Djonni (talk) 14:06, 25 November 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I suggest {{Outdated}} as a name for the template. Should we use the {{Sign}} template as a base or do we start from the hatnote Djonni made just above? --WardPhoenix (talk) 16:45, 15 December 2019 (UTC)

Oh well, I managed to allow {{Sign}} to use emoji instead of a picture when we want it.... So that new template will probably end up as another Sign child I guess 😅 -- WardPhoenix (talk) 23:47, 17 December 2019 (UTC)
{{Historical}}, changed my mind about the name 😅 --WardPhoenix (talk) 13:57, 18 December 2019 (UTC)

Subpages for main namespace

According to MW:Help:Subpages, subpages are disabled for the main namespace. Should I submit a Feedback => Other asking for them to add the Main namespace to $wgNamespacesWithSubpages?

If we are going to suggest that guilds use subpages instead of not subpages, shouldn’t they be enabled...? I only noticed this now as I was dealing with HM’s main namespace pages and didn’t see the breadcrumb links. — Emptysora (talk) 21:43, 18 December 2019 (UTC)

That seems like a good thing to submit, though it may not be accepted. Since there are already subpages being used in practice in Main, the primary advantages would be:
  • Better breadcrumb navigation (or, breadcrumb navigation in Main at all)
  • Correct subpage moves if required
The only subpages I know of in Main are Guild (off the top of my head, ref. the HM subpages, Russia/statistics, TFL subpages) and some user pages in the main namespace (including my own Djonni/Shared sandbox... We'll see if the Devs feel it's worth enabling for those cases. With the changes to user templates that are being discussed and worked on, subpages with infobox templates may become more common for guilds. -- Djonni (talk) 13:27, 19 December 2019 (UTC)
Submitted~! — Emptysora (talk) 15:52, 19 December 2019 (UTC)

Hero namespace

I noticed that this wiki has a Hero namespace. Why doesn't anyone use it, and is it okay to move hero pages to it? --Uni34 (talk) 08:23, 21 December 2019 (UTC)

P.S. What would be the implications of using the Hero namespace? Are subpages allowed, for example? Is the editting and creation of hero pages limited to the hero's god, similar to god pages? --Uni34 (talk) 08:28, 21 December 2019 (UTC)
Well, is it okay to move hero pages to it? is a hard no. Absolutely don't mess with other people's God, Hero, or Guild pages without permission, except for the simplest of maintenance (e.g., adding [[Category:Guilds]] to new guild pages; the occasional courtesy fix to inactive players' pages if we change the parameters of a template they use, but even that's a bit iffy). So, no moving hero pages. We use Talk pages to give friendly, helpful advice as needed, and no more.
As for the Hero namespace, well. As you can see, it has literally never been used. There's no need for it whatsoever. The reason we have it is, like so many of the Godwiki's weird stuff, because of the idiosyncrasy of the Godwiki's first admin, who is now inactive. But for the first half decade or so of the Godwiki, it was run by someone who was very unfriendly and unhelpful, made a bunch of weird decisions (redirecting blanked and unneeded pages to the Main Page? Yep, that was his rule), made the Godwiki a difficult and unpleasant place to be, and made the majority of our community's best people feel really negative about the Godwiki. It'll still be years before we finish undoing the weirdness, and the harm.
As far as I know, nobody has any permission to create or edit in the Hero namespace. Try going to Hero:Dora34 or Hero:Uni34 and see, I know I can't create Hero:Djonniboy or Hero:Djonni. It's just one more annoying quirk we've inherited from bygone days. I suspect that the idea was that one could create and edit the page for one's own hero, but when he realised that was not technically possible (since the Godwiki has no means whatsoever of getting metadata from Godville beyond your login token), he just abandoned the category instead of cleaning up afterhimself and removing it. So, we just have to carry on like it's not there. -- Djonni (talk) 08:56, 21 December 2019 (UTC)

File namespace pass (pass to mark images for deletion)

Shortly, I will be going through the file namespace (specifically the items listed on Special:UnusedFiles) and mass marking files for deletion.

According to Rules:

4. GodWiki is not an image-hosting platform, and images should never be uploaded "in case they're useful" or "to be used at some point" but only for immediate use in an article. Images which are not used in articles may be deleted without notice.
— Rules

I interpret this to mean that anything in the Special:UnusedFiles report can be safely marked for deletion under the Images which are not used in articles may be deleted without notice. sentence. However, the keyword there is may. That means that images won't necessarily be deleted just for not being on a page. I've been trying to think of scenarios where images would be kept vs deleted (since some of the images in Special:UnusedFiles might be worth keeping).

So far, I've come up with these scenarios:

  • Images with watermarks (eg: File:Greyscale.jpg)
  • Images not related to the game at all (excluding images of heroes/gods) (perhaps: File:104866108.jpg)
  • Images related to the game but do not have an article created (eg: File:Feralpetrock.jpg)
  • Images related to the game but not included on any page (eg: File:Undead garden gnome.jpg)
  • Images of diary entries and other in-games screens (which otherwise have no purpose since the diary and diaryquest templates exist, eg: File:Dust Kitty.png)
  • Images of formulas that are not listed on any page (eg: File:Fo3.gif)
    • If necessary, I can go through and try to determine what these formulas are (eg: the linked one above is probably a formula to estimate temple completion)
  • Images with no discernible purpose or description (eg: File:Founder.jpg)
  • Images that appear to be duplicates of other images (eg: File:Beer-bottle-tree.jpg and File:Beer-bottle-tree1.jpg)
    • If they're perfectly identical, I can just mark one of them for deletion
    • If they're different sizes, I can mark the smaller one for deletion

Unfortunately, I can't detect if an image used to be on any pages by nature of MediaWiki. (I was thinking about exporting the diffs of each page and searching them for [[Image:xxx]]] or [[File:xxx]]. But I don't want to do that because that would put a lot of strain on the database/website [probably], and I don't want to be responsible for if anything happens.)

I'll be considering the nature of the images (as listed in the scenarios above), as well as the age of the image, who uploaded it (mainly to see if Spode or a few others uploaded it. Spode created a bunch of templates and other things that have since been marked for deletion (Usually Spode was the one to mark his templates as such))

Worst case, you'll be able to see which ones I have marked for deletion in Category:Marked for deletion and on my dummy page (User talk:Emptysora/dummy) when I add them there (which will be as I go along, but I'll save after every couple hundred or so). If you feel a file shouldn't be on there, feel free to discuss it here or on the file's talk page.

The main reason I have been going through the Special:UnusedTemplates, Special:UnusedFiles, and Special:UnusedCategories special pages is so that we can actually use those reports as intended. Ie: I'm adding everything that has been marked for deletion to my dummy page such that they're removed from those reports. The page is in User talk because the User namespace is semi-protected (but User talk isn't). IE: If I go off for a month and things are unnominated or the devs actually clear the category out, you'll be able to modify the page to remove the deleted pages from the Special:Wanted reports.

Before I start "pruning" (mass-marking these images for deletion), I wanted to hear some opinions about this. To be safe, if there's anything I'm not sure about, I'll post a reply to this thread asking for more opinions on a case-by-case basis. To start out, I've listed the example images from above. -- Emptysora (talk) 21:08, 19 November 2019 (UTC)

I don't think there is something wrong about marking any unused pictures with "To delete". That whats the Recommandation #4 say that happens to those pictures anyway, we can still upload new pictures when needed.... The problem remains the same, we can't delete them ourselves. I don't know if that's something easy to do/useful from dev POV though. -- WardPhoenix (talk) 22:41, 19 November 2019 (UTC)
What I was thinking about is if we could perhaps every so often submit an "Other" report to the devs via feedback and ask them to clear out Category:Marked for deletion. (Eg: maybe once a year). From a dev perspective, I don't think there's an easy way to batch the deletion. At least not without installing extensions such as DeleteBatch or Nuke. The only thing I can think of is if we made a template that would link to the confirmed delete action and create a page where all they had to do was to click links to delete the pages. That poses an issue of, say, if a malicious actor modified the page before the admins get to it (not that our special category doesn't have that risk either). Aside from that, the devs would have to go into each page, drop down the "More" menu, and click the "Delete" option that's listed for them.
I just think that just because we can't delete pages doesn't mean we shouldn't be looking to (hence why I'm doing this). -- Emptysora (talk) 23:03, 19 November 2019 (UTC)
Passed through the list and whittled it down to 317 (when it used to be at 1200~). Gonna apologize now since that action probably will make people's lives miserable when they check Special:RecentChanges. Tip: Set "namespace" to "File" and check the "Invert selection" box (which might not work on mobile) to hide my recent File edits (which is over 800). I'll do some more tomorrow. -- Emptysora (talk) 02:10, 20 November 2019 (UTC)
Nobody's been willing to go through this so thoroughly in ever, Emptysora, so 👏👏👏 well done! I have a small suggestion as to how to best use all this work of yours. I think it's worth trying to turn this into a genuine cleanup, and make it as easy as possible for the Devs to do that big batch delete. I've always had a concern that there's quite a lot of material in those old pictures that is copyrighted or lacks suitable licensing, and shouldn't be here.
We could, if we want to be generous, post a message on the forum about this and give fokls a grace period to come and rescue anything they wanted kept. I also think it's wise to exclude anything which is a screenshot of the game, as there are lots of genuine reasons why someone may have one of those uploaded without being in use on a page (and, since they're material from the game, they pose no threat of copyright or licencing violations at all). But, assuming those two things are done, I think that it's worth you submitting an Ideabox->Other to the Devs asking them to do a batch delete (with links to those extensions, as they might find that useful).
To make it as easy as possible for that deletion to go ahead, I can modify {{delete}} so that it checks if it's on an image page (i.e., in the File: namespace), and adds those images to a new [[Category:Files marked for deletion]], which will make not just this batch deletion easier, but future image cleanups as well. We will then in future simply be able to drop a {{delete}} onto images as needed, and once there's enough to make it worth the trouble, pop a fresh request through to the Devs.
I suspect they will actually be glad for the opportunity to clear all that old junk out, especially if we point out that there's copyrighted and unlicensed material sprinkled through it. For most of the Godwiki's history, image licensing issues have never been adequately emphasised, but I really think it needs to be something we're much more assiduous about, and this big image cleanup will really help with that. 👏 again! -- Djonni (talk) 11:02, 20 November 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── The only screenshots of the game I propose to mark for deletion unquestionably is things like screenshots of the diary, pantheon rankings, and hero stats screens. The rules state this isn’t a hosting website, and generally, those kinds of images are mostly uploaded to share “hey, this happened” or “I’m number one on the Destruction pantheon” or “I’m rich.” So, those ones should be almost certainly deleted. Things like inventory screens etc. I can see keeping. There was one I caught after the fact but forgot to remove the template that showed some holiday exclusive items. There’s also what appears to be dungeon maps and strategies/guides (I assume that’s what that is, I’m 92 bricks until I can see that mechanic.)

I also agree that a warning (especially if this is a regular thing from now on) on the forums is important. I forgot to suggest that in my OP (despite alluding to it). If people on the site have a desire to keep their images, they’ll check. It allows us to prune the inactive images and old content. If you do put a message on the forums, you should specify that they should add their images to their user page or something so they aren’t marked for deletion. If they want to hide it there, you can tell them the 1x1 trick we thought of on your page.

I hope the moderators don’t have to go through a lot of trouble to batch it.

Eventually, I’ll be going through the entire File list for inappropriate images, copyrighted content, etc. and marking those accordingly. That’s... another day though.

Personally, and as heartless as this is, nobody has the right to complain if their image is removed since GV doesn’t ever guarantee it’ll stay, has provisions for removing images, and states it’s not a hosting platform. They can, however, get mad at us for marking it to be deleted (Especially me since I just went through and added 800 to the category).

Well, I guess I’ll call this Project Cleanup 2019 I guess, if this is going to become a full cleanup operation. I’m only one person, so, I could use all the help I can get anyway. Honestly, I had planned to do a cleanup of all three for this reason. No offense to anyone, but there’s a lot of old “junk” left around. It bugs me when I see stuff like that (especially with the unused reports), so... you know (;一_一)

Lastly, the image licensing we definitely need to pay attention to. I hate copyright law enough to know that some people and companies CAN and WILL take action against people for this stuff **cough cough** RIAA/MPAA **cough cough** (though those two are music and video, and our at risk files are mostly anime images)

Glad to help with all of this, though. — Emptysora (talk) 11:41, 20 November 2019 (UTC)

I'm going to gently but quite firmly argue again that material that's clearly directly related to Godville — screenshots, etc — has an implicit but clear reason to be here, regardless of whether it appears on Special:UnusedFiles. There are plenty of places around the wiki (Hall of records spring to mind) where a large number of players with zero experience (or interest) in wikis and how they work have simply made trial-and-error guesses about how to do stuff, and come up with some creative solutions that will mean files that are, in fact, in use will erroneously appear on that report. And that's not even to mention when people upload an image to the Godwiki to be linked from the forums, or in a private message, or in the discord(s), which does happen, and which is, in my opinion, a totally reasonable thing for a player to do. Because, in fact, why shouldn't people use the Godwiki as a place to put those kinds of images... uploaded to share “hey, this happened” or “I’m number one on the Destruction pantheon” or “I’m rich”? Proudly displaying your achievements as a God or a Guild is one of the Godwiki's most-used purposes.
Granted that the Godwiki isn't an image-hosting platform1, but if you're a Godville player, you have a totally reasonable expectation that it's a place you could safely put game-related material, regardless of whether you have 1) ever seen those guidelines or even realise that they exist (most don't), and 2) have the slightest idea how wikis work. And both of those are things we can continue to expect from the majority of occasional Godwiki contributors forever, as there's really nothing we could (or should) do about it if we want people to feel like they can use the Godwiki freely.
There's a reason why Special:UnusedFiles is separate to the marked-for-deletion categories. Any mediawiki installation would have use cases for images to be present that should not be deleted, and this is definitely one of them for us. Regardless of whether we like having things on that report, it is, nonetheless, simply a report, and doesn't always require action to be taken to "fix" it. 😊
Of course, I realise that this might mean that someone has to go through every file that's been marked for deletion and un-mark anything that is clearly game related, and I don't mind doing that work in the next while. 😊
Footnote 1: That wording actually comes from the bad old days, and in my opinion, we should actually rethink it with the above in mind. Because all mediawikis are an image-hosting platform, if they have any images at all. The wording is sarcastic, and was put there just to be a stick to hit people with (ref: {{Warning}}) if they uploaded something that a certain someone didn't like. The rule is sound in principle, but should reflect a more reasonable, friendlier tone. -- Djonni (talk) 12:09, 20 November 2019 (UTC)
I’ll go through it later, don’t worry.
My only comment is that I don’t think that just because it’s a screenshot of the game or directly related to the game, that we unconditionally keep the image on the site. All the rules state is that it’s not a hosting platform, things should be for immediate use, and content unrelated can be deleted without warning. Ie: it doesn’t say “Anything related to the game will always stay” (as silly or implicit such a rule would be)
What I’ll do is go through and individually find the applicable images and evaluate based on your comments so far, if they would have a use or would be necessary to keep. I’ll even search the forums (assuming I can actually search for links like that and automate it) and see if any are linked, automatically removing the template etc.. I’ll post here if I have questions.
I know why Unused is not called pending delete or similar. I never treated it as such (or else there’d be nothing left in that report). In such cases, we could still add them to a page like my dummy page so they don’t show up in the report.
The problem is that while some of the images MAY be in use despite being on that report, there’s no way for us to tell. We can’t just not delete any files because they could be used elsewhere. Things directly related to GV I understand. But, with other images, there’s just no way to tell. This is why I think a forum post is a good idea. At least then we gave people a chance to see if their image is pending deletion and potentially remove it.
Regardless, I think the rules are a bit too vague in this situation. They’re too broadly written. It allows people to interpret them too extremely. I kind of wish we had an admin’s opinion on this. That would certainly clarify some of this. — Emptysora (talk) 14:57, 20 November 2019 (UTC)
Sorry if I’m coming off harsh... I’m half asleep and really need to sleep. I **will** go through them later and put the applicable files into a temporary purgatory of sorts.
Honestly, I’m playing devil’s advocate for the most part (just offering a counterargument). at least this discussion will allow us to not have to fuss about it as much. There’s just too many hidden variables with this.
From what I read, you feel that if it’s game related, it almost certainly stays (nearly regardless of the image itself), and that some images shouldn’t be deleted just because they aren’t used (that one... is hard to deal with).
Our main issue is the fact that we have nearly zero categorized images, we don’t know what any of them are for. We should start categorizing images based on where they’re located (into the appropriate existing categories)
in the very least, once we deal with the unused file report, in the future, we’ll be able to see which files were uploaded to be used on the wiki. This allows us to pretty easily determine what to do with most of the files. The uncategorized files we can, for the most part, assume are used elsewhere off the site (Eg: forums). This can allow us to make a better decision on what to do with those.
Ideally, the only thing I’d like in that report, is files that are new, or are not on the site for use on the wiki. (Or images that have since been removed with categories)
We just need to clean up the mess from “the bad old days” as you put it.
As for rule changes. I don’t think there’s anything wrong with allowing game-related images to be hosted. We should probably word it, “GodWiki is not an image hosting website. Images unrelated to the game, it’s contents, gods, and guilds can be removed without warning. In the event you do not think your image will be in use soon, please put a description with the image when you upload it so others that come after you know what you intended. Any content that breaks TOS can be removed without warning.” (Ie: be specific about what is considered unrelated content, and put a note to uploaders letting them know to describe what they’re uploading if it’s not going to be immediately used.)
For this first purge, I think the unused guild, god, and content images (Eg: monsters, artifacts) be included too (excluding other content related to the game like screenshots.) we then do a forum post so that people can pull what they want out (Eg: grace period of a month). After this, ideally, we categorize uploads so we know WHAT is on the report (since half the time it isn’t clear.) — Emptysora (talk) 15:25, 20 November 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Heh, don't worry about it. It happens to the best of us me all the time, I often reread stuff I wrote when tired and wonder why anyone still talks to me, or how they could have possibly understood what I'd hoped to say. 😐

And in which spirit, I want to be more clear about what I mean, as I'm not sure we have ended up on the same page. I'm really talking very specifically about screenshots of the game, or of game material which was generated by Godville itself in some way. And there is a more general way to talk about this which might draw a clearer picture.

To me, it comes down to this: why do we wish to clear out old images? What's our purpose? It can't just be to clear the special report pages, or keep things "tidy". In fact, there's very little reason why one should want to do this, other than general fastidious (which I am in general down with, but not in this case).

The most legitimate purpose for clearing out old images is to prevent potential future problems to do with licensing and copyright. Because in the end, at some point, someone had a reason to put every single one of those images up in the Godwiki, and it's not possible for us to know what they were, nor if the pictures are still important to someone. So to remove any image we need to justify the choice. And honestly, the only justification I think is reasonable is a precautionary one against legal threats to Godville.

Material generated by the game or by the game's players doesn't pose that threat. There is, I argue, simply no justification for removing it.

Organise it? Absolutely! Find a way to better use it? No question! Find a way to take them off the reports, so those reports become useful again? Great idea! Delete someone else's contribution or achievement just... because we decided to? Nah.

What I'm trying to say is that simply not being displayed with [[File:...]]] (the report's metric for "in use") isn't a reason to delete a file. But it's absolutely a reason to take a look and figure out whether it's safe to keep. And if it's not safe, it should go. If it poses no risk at all, which includes any screenshots or game-created content, we don't have a reason to remove something that someone choose to put here. 😊 That's all I'm trying to say. -- Djonni (talk) 18:29, 20 November 2019 (UTC)

It's basically a case by case issue. I know I uploaded a screenshot that could be deleted because it have no use now (need to find it back to mark it). I don't think there is any good middle ground since deleting is kinda permanent. And copyright haven't been a major issue here so far thanks whatever (Gosh if would be drama if all copyrighted images were deleted).
There's also a lot of duplicate (guilty as charged for one...) that could be deleted without much thoughts. I'd tend to say that unused screenshot intended for the hall of records could be deleted, but well I can understand the objection of Djonni.
But, I'd object that objection by saying that most of the people who posted those unused screenshot are unlikely watching at them or at the Godwiki on a regular basis (far fetched argument I know).
But I also understand there is no emergency at deleting pictures, unless the devs says otherwise (when i need a pic, i try to search if there is something down there i can use instead of upload, like i did for {{Geography}}), it would just make it cleaner.
Categorizing the pictures can be useful I guess, but that's gonna be quite the monumental task. (And I guess we need to define those category firsthand). -- WardPhoenix (talk) 23:26, 20 November 2019 (UTC)
Djonni I ask myself that question everyday... heh. I see what you mean. I’ll definitely add the categorization to my list of things to. I like monumental tasks. For the most part, we can use Category:Gods, Category:Guilds and so on for nearly everything. There’s no real reason to create new categories explicitly for images.
My reason for deleting files was never to clear out the Special:UnusedFiles report. That was simply the first place I looked through as those images were not in use (Ie: people wouldn’t care as much if those were gone through)
I understood what you meant by the game generated content. Yes, those generally would not cause us legal issues, but, there’s other reasons to delete things than just because of legal issues. As WardPhoenix pointed out, there’s duplicate file issues too. Aside from that, there’s also the potential storage space issue. I’m not sure how the devs are handling that one though, and since they haven’t said anything, it’s likely not a problem yet. We should ask them for their opinion on this at some point, though.
The general assumption I had when I was going through that report was that “since they were unused, the uploaders either don’t need, or want the images anymore.” (That obviously doesn’t work in the case of forum messages.) If somebody worked hard and contributed by uploading a file, you would at least assume they would want to show that file off. The fact that such images appear on that report defies that very idea. In many cases, people have uploaded replacements to be used instead of their original uploads (such as hero/god avatars, guild banners, especially HM, and some bird one I can’t remember the name of.). I kind of want to hear a scenario where this logic would not hold true for the unused file report (at least for the older images, and ones not of game content itself). I’m not suggesting people don’t care about their achievements, but that, in many cases, that doesn’t apply.
As WardPhoenix said, there’s no rush to delete the images (and I was thinking at least a couple month grace period for the forum post since not everyone comes on everyday like we seem to).
Sorry for the “late” reply, I’ve been dealing with some legal things these past few weeks (I alluded to it on my user page Monday). I’ve been a bit busy.
Ugh, this topic is getting long. REALLY long. For some reason the TOC doesn’t show up on the mobile skin, so scrolling to the “edit” link for this section, is a big hassle. — Preceding unsigned comment added by Emptysora (talkcontribs) Thursday November 21
Hey, no problems, real life always comes first here. Everyone's among friends here, you take any time you need. As one of my old mentors here once patiently told me, the Godwiki will always be here. 😊 We all hope you're okay, and if you need anything, we're here.
As WardPhoenix pointed out, there’s duplicate file issues too: Yes, absolutely, there's some common sense actions that can safely be taken to clear out dupes, etc. 👍
there’s also the potential storage space issue: This doesn't concern me at all, for a few reasons. Firstly, it's not our concern. 🤷‍♂️ If the space used by the Mediawiki installation had ever been a concern for the Devs, they could have popped in at any time in the last eight years and nuked every unused file. They haven't. Not on Godwiki-en, nor on Godwiki-ru, which is much busier and larger than ours. Secondly, a careful inspection of the Godwiki deletion logs reveals that, even at times where deleting offensive images was necessary (and it's worth noting that that's the only reason an image has ever been deleted), they were very selective in deleting only the historical revision of the [[File: that was offensive, and leaving behind the pointless placeholder that was uploaded to obscure the offensive file. They have clearly demonstrated that they strongly prefer for all user content to be kept, even the pointless stuff, unless there's a clear and compelling reason to remove it. Y'see? We don't need to ask the Devs opinion on this stuff, we've got it demonstrated if we just look.
you would at least assume they would want to show that file off. The fact that such images appear on that report defies that very idea: Well, I think I've expressed my disagreement with this enough. 😊 The key word there really is "assume" — we simply shouldn't be assuming what those users wanted, or want, with the file. And we shouldn't assume that a correctly formatted [[File: is the only way the images have been used.
such as hero/god avatars, guild banners, especially HM, and...: I don't believe we ever really disagreed on that. 👍 Unless for some weird reason a guild used a screenshot for their emblem, which 🤷‍♂️ sure, if they did, I'd be arguing for it's preservation.
On the matter of guilds, though, it's not difficult to imagine a scenario where someone would be angry about this. Take: the newly elected guild leader, keen to revitalise the guild's symbols and wiki page for recruitment, goes looking for all the old emblems and banners for some retro inspiration, or to cherry pick the best to reuse. For the last eight years, there's been no problem doing that. We are about to change the de facto rules, to bring them more in line with the de jure, in a way that could, and one day certainly will, disrupt and frustrate people. It really is something we need to remember. Indifference to user experience has damages the Godwiki's reputation again and again, year after year, and we really mustn't repeat those mistakes
Btw, I'm not arguing that we keep all the old guild rubbish files. Just highlighting that the expectations of our fellow users need to be kept in mind at all times. Fair warning on the forums will suffice, for cases like that suggested above. Before we take this to the forums, though, we really need to develop a very clear and easy way people can rescue any files they want kept.
Okay, okay, I'm procrastinating because I'm having a bad day. Must. Get. Back. To. Work. -- Djonni (talk) 12:04, 21 November 2019 (UTC)

Let's place a header here because duck scrolling

──────────────────────────────────────────────────────────────────────────────────────────────────── I... forgot to sign my comment... oops.

Thanks for kind of understanding what I meant when I asked for a scenario. I wasn’t being combative at all (even though it probably looks like that), I just figured, if there WAS a reason, I just want to know, since I can’t think of such a reason. You make a good point about going through for past inspiration. Basically, I just wanted a counterargument to what I argued.

I think we should change our perspective on this. We’re currently taking a “delete first, ask users to save their stuff later” kind of thing. Let’s flip it. Instead of that, let’s “Save first, and ask people and guilds to go through their uploads to see what they don’t need/want anymore.” You’ve already shown that there’s far more scenarios where keeping the files is the de facto norm. Instead of trying to arbitrarily decide who gets to keep their stuff and who doesn’t, I feel we should instead categorize everything, and ask people to look into their uploads for stuff they don’t want to. The only things we will auto-flag for removal are: 1) copyrighted content (which would likely, and, unfortunately include memes), 2) inappropriate content, 3) and duplicate content (putting a redirect on the dup’s page to the kept file). User content isn’t a problem in most cases, I’ve noticed that most of the outdated user content is handmade, not from copyrighted material anyway. There’s no pressing reason for us to push this. Space isn’t an issue. Most of the content doesn’t violate copyright, and generally poses no issue. And, as a result, simply asking for people to go through their uploads, will get the so called “file purge” I have been devising, while not upsetting anyone (hopefully).

For guilds in particular, I think we should suggest that final authority on whether things like banners be removed be delegated to the original uploader/guild master/majority of the guild (Ie: that they use the guild council and forums to debate whether they need to keep their content on here.)

I’d say that we should stress that most of the content is perfectly fine and can stay, but, that, we’re trying to do something about the vast number of unused files, whether that be just to hear, “yeah, it’s not in use, but we’d like to keep it” or “Oh, that? You can get rid of it.” We all like this game, and most of us definitely want to see this wiki improve (I for one want to live to see the Special:WantedPages show a single digit red link count), so, if we simply organize this as a sort of “spring cleaning” I have no doubt that the interested parties will at least look through their stuff.

I’m going to start going through and categorizing all of the files into their appropriate categories. Files that can be categorized and don’t fit into the above listed auto-flag scenarios will be removed from Category:Marked for deletion.

After this is all done, we should write some form of guideline article for uploading files (reminding people to put descriptions, categorize, avoid uploading duplicates, etc.). We could even create templates to be used in the file namespace explicitly, such as a {{Quality}} template which could say, “The quality of this image does not fit the guidelines for images on this wiki. Reason: (((reason))). If you can provide a better image, please replace this file.” Or similar, (reasons can be, “Image has watermark” “resolution too poor” or similar).

Your thoughts? — Emptysora (talk) 19:55, 21 November 2019 (UTC)

Created a working demo of the "FileUse" template. It's in my sandbox. example:
{{User:Emptysora/sandbox|no-category=yes|type=hero|god=Emptysora|hero=Sora Amasaki|hero-link=User:Emptysora/Sora Amasaki|hero-gender=female}}
Picturecamera.pngThis file is an image.
This content is associated with the goddess Emptysora's heroine Sora Amasaki. Please do not delete or modify this content without permission. To suggest changes, please add a topic on this article's talk page, the goddess's talk page, or their heroine's talk page.

The template uses the {{gender:[username]|ifmale|iffemale|ifneutral}} magic word to automatically detect the gender preference from the user's settings to decide whether to call the user "god" "goddess" or "almighty" (gender neutral). This setting is found on Special:Preferences the section titled "How do you prefer to be described?". I chose this example because it explains all of the fringe usages of the parameters in the template (namely hero-link). The template, as suggested by no-category=yes, by default, automatically categorizes the file into categories (namely: Category:Guilds Category:Gods Category:Heroes and Category:Backstage) Feedback and suggestions can be left on my sandbox's talk page.
Type currently supports: god, hero, guild, and forum. If you have any other suggestions for file uses, please tell me. I want this template to be as complete as possible from the get-go.
-- Emptysora (talk) 00:06, 23 November 2019 (UTC)
There is already an existing guideline for the upload file within the Creators Manual, it just needs improvement (I did my best, but obviously I missed some points when I rewrote that whole article).
Categorizing the image is ok, obviously. But as Djonni pointed, is there really a need to mark for delete except for unused obvious dupes and unused copyrighted content?
As for your template, as impressive it is technically (great work seriously), I don't see the point apart from polluting the file page (please don't take it bad, I know i kind of say that too blunt) and it feels a little... agressive somehow.
In theory, files won't be changed by people, unless by mistake or by vandalism.
The former will be worried about the warning and may takes it the bad way, while the later will not care obviously.
But as revert is quite easy it's not an issue. Basically, I'd say that changing any file upload by another user falls into Rules#2. And if the file is deleted, it will be by the Devs, who will never be wrong if they delete a file. --WardPhoenix (talk) 00:42, 23 November 2019 (UTC)
I don't see how it would pollute the file page. The purpose of the template is to provide information about what the file is, and where it is used. It presents this information in a clear, easy to understand, way. If you click a photo on a monster article and see said file, you obviously understand that the image is an image of a monster. Say you click on the "random image" link on the Main page, without looking at the file name, description provided by the uploader, and the pages linking to the image, it's impossible to tell what the image is. And, in the case of images on Special:UnusedFiles, all you have to go on is the description provided by the uploader (which is, in the vast majority of cases, missing), and the file name. Even if modifying files uploaded by other users falls into Rules#2, if all you do is look at the file page, and have never seen the Rules page (which is most of the people in this game), you won't know that.
The "Please do not delete or modify this content without permission" message is supposed to just tell the user not to make edits or flag for deletion without contacting the owner/discussing it. That's why it links to the appropriate talk pages. I understand the verbiage sounds aggressive, but verbiage can be changed. We shouldn't not do something just because the first incarnation of it can be considered aggressive and taken the wrong way. That goes against everything a wiki stands for: collaboration.
"But as Djonni pointed, is there really a need to mark for delete except for unused obvious dupes and unused copyrighted content?", I'm not exactly sure what you mean by this. The only things I suggested be marked for deletion is duplicate files, copyrighted content, and content that is against the ToU/ToS of the site. Aside from the last item, that's exactly what I said (when I agreed with him). What I'm suggesting is that we call on users to see if they have any files or whatever they want to get rid of, before we send the request to the devs to do a mass deletion, since there's likely not going to be another opportunity to remove files for a long time. IE: I want to at least give the others a chance to get rid of anything they don't want anymore instead of just not telling them we did this.
While the "This file is an image." title may seem redundant, it's not because images aren't the only thing that can be uploaded (even if the allowed extensions only permit images). Not to mention, I simply couldn't think of what to put there. I can either remove or edit the message so it's not so useless, which is, again, why I wanted feedback.
-- Emptysora (talk) 01:21, 23 November 2019 (UTC)
Cool template. :)
It's been a long time since I've actually set up my Godwiki preferences. Is the gender preference from the users settings automatically populated from their God/Goddess status, or does it default to something (hopefully gender neutral)? I would also suggest removing the link to the hero(ine) talk page, as messages left their won't trigger an alert to the user when they next visit, so 99% would never be seen.
I know that a bunch of image use templates are used on wikipedia and a lot of other wikis. They've never been used here, obviously, and I thing there's some reasons for that. My main question about the file use template, which isn't obvious to me... who is expected to be placing these templates on images, and when? And within 'who', I'm bundling in a question about how familiar that group of intended users are with templates, parameters, etc, and how they will find out about the template.
Is it intended to be a part of the spring clean effort, a way for people to mark their images as still wanted? Because if that's the case, I think it's way too hard to use (our target group there is likely to have very little wiki literacy). I honestly would think that simply removing the {{delete}} template from an image they want kept will be at the upper limits of what folks will figure out how to do. If this is the intended use, I would really aim for purest of simplicity. E.g., something named along the lines of {{Keep image}} with one optional unnamed parameter for the username, with documentation that recommends placing in pages like so: {{Keep image|~~~}}. (An {{#ifexist: User:{{{1}}}}} would catch cases where a username is manually entered.)
My biggest concern is that it will just not be used. Or, more specifically, that it will become another thing that we wiki gardeners will need to do on every uploaded image, just for our own benefit, in which case I wonder if we would actually take the time use it, switching between screens and copy-pasting stuff to fill in all those parameters with other people's information...? Does it offer us materially more information than the "File usage" section at the bottom? -- Djonni (talk) 10:42, 23 November 2019 (UTC)
In arelated vein, ref this edit comment: after said guilds no longer exist...? What do we do with these? Redirect to Main Page certainly isn't the answer
I completely agree, and it's something we've discussed a little (at Talk:Main_Page/Archive#Many_GodWiki_pages_need_to_be_deleted, which we should consider un-archiving as part of the spring clean). As you'll see there, I agree that the main page redirects are a terrible solution, and have already argued that those redirects should be removed, but we didn't reach consensus. It was a part of why I created {{Delete guild}}, and arged that these pages should go into a special Category. (I suggested 'Category:Dead guilds' at the time, but I don't think that 'dead' is the right word anymore, and would argue for 'Category:Guilds not widely known on Godville', in light of later discussion with WardPhoenix at Template talk:Delete guild.) -- Djonni (talk) 11:23, 23 November 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I’ve seen a few edits by people who have done such redirects with the excuse “it’s not going to be deleted anyway.” Aside from how pessimistic or cynical that is, redirecting pages to Main Page without using “Delete” when, at the time, it actually existed, seems a bit... weird and arbitrary.

The preference defaults to gender neutral.

Ideally, I would like the template on all images (and I can rewrite it to make it easier to use for inexperienced editors). In other words, it would (hopefully) be something the uploader can just copy and paste into the “description” box when they upload (ie: in the same vein as the article infobox templates). It’s purpose isn’t to mark things as “to keep” but to show the purpose of an image in a clear manner. The only place I’d really say it’s required is when images are no longer in use, or images uploaded for the forums. Like with other other guideline articles, we can move the image guidelines to a separate, dedicated, article, and describe how to use the template. Alternatively, we can add a “Images” subheading to the guideline articles, describing a case-by-case use of the template.

Really, though, I don’t think it’s that important if the template is on the monster, artifact, equipment, and quests. Those are half obvious. The message is pretty redundant and unnecessary on those anyway, I only added those parameters for consistency with the types of images uploaded. Ie: I would only suggest putting them on guild/god/hero images.

What I could also do is split up the template into “guild-file” “god-file” and “hero-file” templates making the usage much easier (like we do with the already split guild, usergod, hero, and the other templates.)

The “File usage” at the bottom, especially if the files aren’t used, gives *no* information (and neither does the description in most cases). Anything the template says would be information that section cannot provide. Not to mention, this information wouldn’t disappear as soon as the file goes into disuse.

Though, I don’t see how the usage of this template really affects our spring cleaning. Like I did with stubs, if we ultimately decide to use the template (if even in a subset of files), we can remove the category references if we add said template.

Emptysora (talk) 15:37, 23 November 2019 (UTC)

As a side note, I've started categorizing the files. I started from most recently uploaded to the least recently uploaded. If you guys see new files on the wiki that haven't been categorized, do you mind categorizing them (that's why I started from most recent, I'll eventually clear through my 4,786 image backlog and then we only need to worry about new images)
I'm putting notes on my edits where possible, you all might want to read them as they contain ideas/suggestions, potential copyright issues, etc.. Recent changes only shows up to 500 edits, so to see all of mine, you'll have to go to my contributions. They're all in the format "categorizing: {categories} [(notes)]". Similarly to hide my file edits on Recent changes, you have to select "File" from the namespace menu, and check "Invert Selection".
As per usual, I uploaded the script I'm using to my website, so you can download it if you want. Details on how it works are on my user page. (all the way at the bottom)
I'm planning on going through roughly 500 images a day (might only do 300 today because of how late it is right now), so I should be completely done in under two weeks.
I quick overview of the script: Scrapes the list of files on the server using Special:ListFiles, provides a semi-automatic way to edit images. It provides a sidebar with a bunch of buttons that can add/remove categories from the page, and another sidebar that views the "Read" page of the file (so you can see the image/description/file usages/etc.). It removes the copyright warning in the editor so the "Save changes" button is in-view (less scrolling). It removes the "delete|unused" template call automatically. and automatically sets the edit to "minor" and the summary to "categorizing: [categories]" (auto-updated). Every time you save the page (or click "Read" to exit the editor), the script moves on to the next image on the site, allowing you to sequentially batch edit the files. (EDIT) Screenshot.
-- Emptysora (talk) 02:20, 24 November 2019 (UTC)
Touching this thread just to let people know I haven’t forgotten about it. I will get to this. Kind of been busy lately, sorry. You can see my user page for a more up to date status of this project (and other projects I’m working on). — Emptysora (talk) 02:42, 18 December 2019 (UTC)

Pages marked for deletion tend to redirect here

I don't think this is a good practice. See this page for a list of redirects to the main page. --Uni34 (talk) 08:14, 21 December 2019 (UTC)

Yup, I completely agree. The main page redirects came first in most cases, and were then marked for deletion. I argued for the redirects to simply be replaced with {{Delete}}, as I felt then and still do that those redirects are very disorientating for people especially for people who don't understand how wikis work. But this conversation happened a while ago, (I can't find it now) and folks didn't seem to agree with me, so I started adding {{Delete}} to those redirects as I came across them, leaving the redirects in place.
But, since someone else has brought it up again... I completely agree, redirecting hundreds of random unneeded pages to the Main Page instead of marking then for deletion with a clear reason was, I think, always a bad idea! I'd love to get rid of aaallllll those redirects if those here now agree that it's a good idea. -- Djonni (talk) 08:33, 21 December 2019 (UTC)
👍-- WardPhoenix (talk) 01:53, 29 December 2019 (UTC)