Difference between revisions of "Talk:Main Page/Archive"

From GodWiki
Jump to navigation Jump to search
m (Archived)
m (space patrol)
(17 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Love the new main page! Thanks Spode
* [[Talk:Main Page/Archive/2011-2017|2011-2017]]
* [[Talk:Main Page/Archive/2018|2018]]
* [[Talk:Main Page/Archive/2019|2019]]
* [[Talk:Main Page/Archive/2020|2020]]
Sorry for the complete lack of wiki experience, but I logged in today and noticed that the main page had been blanked.  I reverted to the latest non-blank instance I found, if that is not the proper procedure, please let me know and fix it correctly.  My edit doesn't have the random picture set up correctly.  Same thing with this edit, I'm brand new at this, any information on the "proper" way to use the talk page would be appreciated. -Function
* [[Talk:Main Page/Archive/2021|2021]]
This wiki needs a lot of work. Most of the articles here are rubbish. There are about 900 articles total, but about 700 are guild pages (most of which are only a few lines long).  Another 100 or so have been marked for deletion because they aren't related to the game.  That leaves about 100 pages of actual real game content. Moreover, a ton of the articles don't have categories.  I've been trying to add categories, but I can't do it alone.  Ultimately, we just need people to write articles on game subjects and stop writing guild articles. Wanna see what I've done, click [http://wiki.godvillegame.com/index.php?title=Special:Contributions&limit=500&target=BlueStapler here].  I've given up writing summaries of my edits too. -–[[User:BlueStapler|BlueStapler]]
The article count on the main page appears to be wrong. Right now, it says there are 961 articles. I think this number is too low.  Specifically, there are 874 "Guilds" articles and 164 "Monsters" articles. Those two combined equal 1038 articles (which is obviously more than 961).  I also know that articles from those two categories don't overlap because I've looked at nearly all of them. Add in all the other articles that have been categorized and I estimate there are around 2000 articles.  -–[[User:BlueStapler|BlueStapler]]
What was the purpose of the 2 September 2012 changes? --[[User:BlueStapler|BlueStapler]] 11:14, 2 September 2012 (BST)
Why were the "Picture of the Day" and the "You will be logged in automatically . . ." language removed yesterday?  Since I didn't see an explanation of why they were removed, I put them back by reverting to the 15 September 2012 version of the page.  If they were removed for a purpose, sorry. Feel free to just undo my 29 September 2012 edits. --[[User:BlueStapler|BlueStapler]] 03:51, 29 September 2012 (BST)
im requesting a article about this game to wikipedia about this game hopefully editors in wikipedia with the experience to start one will notice --[[User:Hanz24|Hanz24]] ([[User talk:Hanz24|talk]]) 18:59, 13 April 2016 (UTC)Hanz24
====Sidebar problem====
The "Main page" link on the sidebar is actually a link to "INVALID-PAGE," which in turn is a redirect to the appropriate Main_Page link. This seems like it should be fine, but it has the unfortunate side effect of leaving "Redirected from INVALID-TITLE" at the top of the main page after you've used the link. It also causes problems with namespaces, which you can see if you visit a page under a different namespace and then click on "Main page."
I'm not sure how to fix this, so if someone with sufficient rights could check this out, that would be great. [[User:Benjamaster1|Benjamaster1]] ([[User talk:Benjamaster1|talk]]) 22:48, 18 February 2016 (UTC)
: So, it turns out that the redirect through '''INVALID-TITLE''' happens because [https://wiki.godvillegame.com/index.php?title=Special%3AAllMessages&prefix=&filter=modified&lang=en&limit=100&offset=Anonymous someone set] the <code>mainpage</code> System Message to an empty string. This message, which is meant to contain the title of the main wiki page, and which the sidebar _uses_ to create its link to the main page, cannot be blank because that is, in fact, an invalid title.
: ''Why'' that was done, one can only guess. My suspicion is that it was an attempt to get [[Main Page]] to show up ''without'' a title at the top of the page — which, you'll notice, didn't work since the title still shows as 'Main Page'. But whatever the reason, it doesn't work as intended due to the fact that the invalid title causes MediaWiki to revert back to its default string, and it should really be reset to clear up these issues. But, only a wiki admin can do that. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 13:14, 31 July 2018 (UTC)
::Impressive sleuthing to discover that's the issue without actually having said admin access. Hopefully this will help the ''Hypothetical Future Admin'' resolve the issue quickly and easily at some point in future! --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 08:56, 2 August 2018 (UTC)
::: I submitted a note about the issue, and a pointer to this discussion, via the Ideabox "fix a bug" option, so hopefully that'll get some attention from Godville admins. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 23:26, 2 August 2018 (UTC)
:::: Well thanks to your investigation and bug report this issue [https://wiki.godvillegame.com/index.php?title=MediaWiki:Mainpage&curid=9&diff=86223&oldid=19 appears to have been fixed]! Thank you {{god|Godville}} and {{god|FeRDNYC}}!
:::: I'm moving this topic to the archive as it's resolved. --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 05:41, 4 August 2018 (UTC)
It would be great if the [https://wiki.godvillegame.com/Omnibus_List Omnibus List] could be returned to drop down boxes instead of this ugly jumbled lists which are not mobile friendly that [[User:Rizizuns]] broke. --[[User:ICancerous|ICancerous]] ([[User talk:ICancerous|talk]]) 03:09, 7 July 2017 (UTC)
:Archiving this since the Omnibus layout has since been redone. You will also, in fact, find the [[Talk:Omnibus List|Omnibus List talk page]] has an active discussion of potential future changes to the Omnibus' structure. --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 09:04, 9 June 2018 (UTC)
== Formatting Infoboxes in the mobile view ==
I'm considering a rather radical change to how the formatting is done to embed Infoboxes in wiki articles. (Infoboxes are the boxes in the upper-right corner of many articles, generated via templates like {{tl|Monster}} or {{tl|Town}}, that present some basic stats common to articles of that type in a structured format.) This change would hopefully be virtually invisible in the desktop view, but it would greatly affect the mobile skin, for reasons I'll explain.
So, because this would be such a big change, I wanted to seek out input and feedback on both the theoretical and practical aspects:
# The ''idea itself''
#: Do people feel this is actually an improvement, or do they prefer the way it is now?
# The ''implementation''
#: Any bugs or technical issues that show up for people using different browsers/devices/etc.
Basically, the current mobile skin has a few unusual CSS rules that were thrown into it, no doubt to work around issues with formatting in the app browser. One of them, and IMHO the most problematic, is the one that forces all HTML tables in the article content to fill the entire width of the display. Since Infoboxes are tables, they're all affected by this rule, and the results are IMNSHO extremely poor. But, since it's in the site CSS, there's no way to turn that rule off without admin acces to edit that CSS.
However, I've found that it's possible to ''work around'' the rule, by abusing (I'll admit it) the code that handles right-aligned, thumbnail-sized embedded images. Those images are displayed in a very '''smart''' bit of code (in contrast to the heavy-handed table overrides) that responds to the width of the display device, formatting them normally (right-aligned, with text flowing to their left) when there's room, and automatically pulling them into the center of the screen with '''no''' text on either side if the display is narrower. In my testing I've discovered that the same logic can be activated for Infoboxes, and I feel it looks far better on both wide and narrow devices.
I've put two examples of my proposed formatting change onto a single page, [[User:FeRDNYC/TestMonster]] (ignore the name). There you can see copies of the body content for both the [[Ballpoint Penguin]] and [[Herowin]] articles, but with the Infoboxes updated to leverage the responsive image-alignment code.
If you view that test page on a mobile device, or in the mobile skin on the desktop (by scrolling to the very bottom and clicking "Mobile view"), you'll be able to see how the Infoboxes would be formatted following this change. Both original articles are linked to, so you can compare them to my version.
If anyone has a moment, please do check it out, especially if you have access to any type of mobile device. I've tested it in Google Chrome on my computer, and my Android phone, but I'd love to hear feedback from anyone who looks at it using an iPhone, iPad, or any other tablet device, as I don't have access to any of those devices to test it myself.
My thinking is, if people like this change and it doesn't cause any problems, that all of the Infobox templates across the wiki would be updated to override that <code>width=100%</code> styling and make use of the responsive formatting. Some other templates, like {{tl|Diary}} and {{tl|Diaryquest}} would probably also be included, though they'd default to being left-aligned instead. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 15:09, 1 July 2018 (UTC)
:I have noticed problems with infobox formatting on mobile too, and wondered how amenable it would be to improvement. I admire your creative adaptation of existing features into unexpected implementations ;)
:I'll have a chance to test it on an android tablet screen and in a handful of desktop browsers in the next day or two, but I've decommissioned all my iOS devices so someone else will need to take up that testing. Meanwhile, I might try to hunt for some of those infoboxes where I found myself cringing on mobile, if I can find them again, and try to view the test examples you've made up in as many various ways as I'm able. --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 03:14, 2 July 2018 (UTC)
:: Cool, thanks. For the most part, the ones that have seemed problematic on mobile were probably ones where the forced width causes weird explosions of the table borders. Like, you'll have an infobox that randomly grows a big empty column to the right of its content. There's a bunch of that scattered around the wiki.
:: If the width is no longer being forcibly expanded (or, if it '''is''', but only within the <code>&lt;div&gt;</code> container that holds it, which is where the width is constrained) that should no longer happen. Honestly that issue is the main impetus for me doing this, as there's no good way to account for a CSS-forced <code>width=100% !important</code> from within the HTML source. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 11:48, 3 July 2018 (UTC)
== It's time: Diary and Diaryquest templates now default to new "superhero" style ==
I've just updated both templates to use the new superhero style by default. As a result, all quest and diary boxes on the wiki should now go from looking like this:
{{Diaryquest | style= hero | number = 42 | status = 24 | text = Invent the wheel}}
{{Diary | style=hero | text = 4:20 Wrote something irreverent and snarky about a town or quest or whatever}}
To looking like this:
{{Diaryquest | number = 42 | status = 24 | text = Invent the wheel}}
{{Diary | text = 4:20 Wrote something irreverent and snarky about a town or quest or whatever}}
You can revert boxes to the old style by adding "<tt>style=hero</tt>" to the template parameters. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 08:47, 10 June 2018 (UTC)
== Larger images in {{tl|Monster}} and {{tl|Pet}} articles ==
You may notice that [[:Category:Monsters|Monster]] and [[:Category:Pets|Pet]] articles show off their subjects a little better now. I've increased the infobox image width from <code>200px</code> to <code>300px</code>, a 50% size increase that better fits the infoboxes' <code>25em</code> width. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 01:29, 3 August 2018 (UTC)
:Looks much better now on both desktop and mobile (6" android w/ chrome). The monsters will look even better once the code has been tidied up to remove the dead right-hand column :) --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 02:04, 3 August 2018 (UTC)
==Mobile layout of main page==
I'd be great if this wiki could have a "mobile version" or something, but I don't know how to properly check for that. --[[User:ElectroChip|ElectroChip]] ([[User talk:ElectroChip|talk]]) 15:10, 9 May 2017 (UTC)
:I agree (as do most users, I think) that the main page has some significant layout problems on mobile (mainly around the grey '''Welcome to the GodWiki''' block at the top). Reading [[User:FeRDNYC|FeRDNYC]]'s [[#HTML layout and the width attribute|brief summary below]] of the challenges of setting layouts can give you some idea why, but the root of the problem is that, with no active admin at the moment, there's nobody right now with the powers required to modernise the site's CSS to be responsive to the dimensions of the window. Anything we do in the meantime will be a kludgy hack that ''might'' improve some layout issues, but generally we'll have to choose between the front page looking great on desktop ''or'' on mobile, not both.
:That said, if anybody wants to take a bash at a rebuild of said grey block, please do! I'd suggest pasting any proposed changes into this talk page first so that we can all compare how they go on our various desktop and mobile screens first :) --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 09:04, 9 June 2018 (UTC)
:: See [[User:FeRDNYC/Sandbox]] — it's very much a WIP, but in my testing it ''sizes'' properly (but not "formats" 100% properly, '''yet''') on mobile devices. The gray-box bulleted items are coded as a single bulleted list, which uses a fairly new (past 3-4 years) CSS column-formatting feature to split itself up according to the available space. So, hopefully it's supported everywhere it needs to be. <strike>I already have a plan to clean up the strip of links at the bottom of the gray box, and</strike> I'm still working out the balancing of the various sections ''below'' the gray box so that they don't get chopped up by the column balancing. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 22:35, 2 August 2018 (UTC)
::: Never mind the struck-out part, I sorted that out. I removed a couple of items from the horizontal list (the Guidebook and the Categories list), because (a) they're both available in the sidebar, and (b) in the case of the Guidebook, I just feel it's a ''lot'' dated, and could really use some updating if we want to point people at it.
::: That part of the box is formatted as four one-item columns, which reduces a '''''little''''' weirdly as it narrows. (It first goes down to three columns, but since there are only four items it only fills the left two of them, leaving a big empty area to the right. Then it drops to two columns and everything balances again.) But honestly, as a tradeoff for it being readable on all screen sizes I think that's acceptable. Please do weigh in if you have any thoughts, though. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 23:20, 2 August 2018 (UTC)
::::I admit, I had noticed the edits to your sandbox and had a peek the other day. I'm excited about the changes and progress, and look forward to a modernised main page! :) One note &mdash; with the 2 columns reflowing in the lower section, on desktop I am currently seeing "Edition May 14, 2018" orphaned at the top of the second column. I'm not sure if there's any sane way to prevent that behaviour, just worth noting at this stage.
::::And yes, the Guidebook pages need a ''huge'' amount of work. I'd mentally earmarked that... for mañana. --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 02:12, 3 August 2018 (UTC)
::::: Yeah, that issue is what I was referring to, with my (somewhat redundant, as I balance the balanced balancing) note about "working out the balancing of the various sections ''below'' the gray box so that they don't get chopped up by the column balancing." It's not ''meant'' to do that — and honestly, if it '''wasn't''' doing that I'd probably consider it complete, since with the horizontal list "fixed" well enough it's kind of the only issue left — but currently, it still '''is''' doing that. And I suspect is going to keep doing that, as long as I'm (ab)using columns for that part of the layout.
::::: I'll probably have to switch that section from CSS columns to a different layout system, possibly CSS flexbox, to make it keep those DIVs intact. Just as soon as I work out how (or if) I can convince flexbox-or-whatever to auto-adjust to width, the way columns does so nicely. (And without requiring any media queries, which inline styling can't use.) -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 02:52, 3 August 2018 (UTC)
{{outdent|::::::}}Okay, checkout [[User:FeRDNYC/Sandbox]] again, which I think is now ready as a complete reimplementation of the [[Main Page]] that works at all display widths, including on mobile. It depends on two new-''er'' technologies, CSS columns and CSS flexbox, but support for both of those was sorted out long enough ago that everything seems to support them now, including the Godville app's browser (at least on Android). So, it should reflow to a comfortable layout everywhere, on screens both wide and narrow. On very narrow screens, note that the Intro to Godwiki section actually places itself '''before''' the Featured Article section, an enhancement made possible by flexbox. (The top row is actually a two-item flexbox, flowing in row-'''reverse''' order, and the Intro section is the ''first'' item in that part of the page.) -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 02:07, 6 August 2018 (UTC)
: So, all of this nonsense with the new infoboxes makes me realize that I'll need to check how [[User:FeRDNYC/Sandbox]] looks in the WPTouch skin, in addition to the other two (Vector/desktop and Minerva/mobile). Not looking forward to that, so I think I'll put it off until another day. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 21:10, 7 August 2018 (UTC)
::While on hold on my phone (sigh) I took the time to check this all out and it looks just fine to me. I mean... [https://imgur.com/a/jYHkInm for given value of fine].
::It looks fantastic on desktop and mobile browser (Vector & Minerva) and I think it should go live immediately. The only thing worth considering is to add a note to the bottom with the [http://wiki.godvillegame.com/index.php?title=Talk:Main_Page&mobileaction=toggle_view_mobile magic link] for WPTouch users. Perhaps:
:::<code><nowiki>Enable [http://wiki.godvillegame.com/index.php?title=Main_Page&mobileaction=toggle_view_mobile mobile-friendly view].</nowiki></code>
::or something similarly straightforward would be enough? --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 06:00, 13 August 2018 (UTC)
::: Yeah, I was thinking I'd look in the CSS for a class that might only be visible in WPTouch, in which case that link could be hidden behind that. There might not be one, but it can't hurt to look. It just means I have to dig through the three governing CSS files, which I haven't done yet.
::: As far as bringing it live... based on your screenshots (thanks!), I ''may'' be able to improve the WPTouch rendering a bit, first. Like, the squished-together lettering of the title is clearly a line-height issue, I should be able to specify a value to get it to stop doing that, so let me see if I can squeeze that in.
::: I don't know why the random image isn't... like... randoming. Or image-ing. One of those. But I'll try to figure it out. (Just, not very hard, because I care thiiiis 👌 much TBH.) -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 06:40, 14 August 2018 (UTC)
:::: OK, significant changes. I fixed the line height for the first two parts of the gray-box header. And, this?
::::: "I was thinking I'd look in the CSS for a class that might only be visible in WPTouch..."
:::: Believe it or not, I found one. Or, a combination of a class and an ID, each of which is hidden in either Vector or Minerva, but neither in WPTouch. So, by abusing those together, I've set it up so that at the ''far, far'' bottom of the page, a link to switch to the mobile skin should appear '''only''' when the page is viewed with the WPTouch skin.
:::: Haven't really looked at the random image thing all that closely, yet. It seems to be mostly working OK for me, so it's ''possible'' nothing's wrong, and you just caught a bad image pull when you took the screenshot. Possible. (Unlikely.) -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 09:02, 14 August 2018 (UTC)
:::: Oh, DUH. Actually, there was nothing wrong with the randomimage in your screenshot, it just happened to catch that tiny "fast-forward" type icon, so the caption squished underneath it. Well, that'll happen. (I actually could move the text ''out'' of the image caption, now that I've got the page resizing properly, and it wouldn't do that anymore. I'll mull it over. Wouldn't really make too-small image pulls all '''that''' much prettier, anyway.)
:::: So, I guess this is maybe ready already, now? Hmm. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 09:05, 14 August 2018 (UTC)
::::: What the hey. Taking live. If it breaks anything I'm '''sure''' we'll hear about it. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 05:33, 16 August 2018 (UTC)
::::: I got rid of the text in the random image box entirely, BTW. It's already titled "Random Image", so the caption was really kind of redundant. And it had a tendency to format poorly with different sized images, and/or different sized screens/skins. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 06:40, 17 August 2018 (UTC)
{{Outdent|:::::}}My goodness it looks '''SO''' good. Haven't checked it in WPTouch (because ''yech'') but certainly on all my devices in both of the other stylesheets it looks outstanding.
Though a part of me kinda misses how inaccurately named the ''Featured Article of the Week'' was 😋 --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 17:37, 17 August 2018 (UTC)
:Yup, even on ''yech'' WPTouch it looks fantastic (and is even more noticeable in contrast to how it was). One thing I've only just realised — on the mobile skins there's no link to [[Talk:Main Page]]. It lacks the normal "Discuss" button at the bottom. I'm so used to coming here from [[Special:RecentChanges|recent changes]] that I'd never even noticed that before. Makes it harder for folks on mobile devices to find this, or even know it's here. '''#mobileproblems''' --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 17:54, 17 August 2018 (UTC)
:: Heh. "Though a part of me kinda misses how inaccurately named the ''Featured Article of the Week'' was" — I'd actually changed that last week, on the old version, so that predates this update.
:: I had, at some point, noticed that there's no link here from the main page, making it an especially poor place to use for announcements and such. Oh well. I'm developing a very zen ability to just not really care about mobile's foibles, as there are so many. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 20:22, 17 August 2018 (UTC)
::: I added a note at the bottom of {{tl|Mainpageintro}} about the main page's Discussion area, with a link to it for mobile users. Which makes the Intro box quite a bit longer than the Featured Article box, but... meh. Now we have the option to feature longer portions of the selected article, if we want. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 04:37, 18 August 2018 (UTC)
== New shortcuts for numbers with superscripted ordinal (e.g. {{1st}}) ==
I just borrowed the {{tl|Ordinal}} template from Wikipedia, and created convenience templates {{tl|1st}} {{tl|2nd}} and {{tl|3rd}} for anyone who wants to write numbers all ''fancy'', like:
{|class="wikitable" style="text-align: right"
! Code !! Output
| <code><nowiki>{{1st}}</nowiki></code> || {{1st}}
| <code><nowiki>5{{2nd}}</nowiki></code> || 5{{2nd}}
| <code><nowiki>-10{{3rd}}</nowiki></code> || -10{{3rd}}
| <code><nowiki>{{Ordinal|57}}</nowiki></code> || {{Ordinal|57}}
'''NOTE:''' Please do not use these shortcuts in links or template calls. "{{1st}}" is not the same as "1st", and they cannot be interchanged in code, i.e.:
* The [[1st Line of Defense]] guild article '''cannot''' be linked to with <code><nowiki>[[{{1st}} Line of Defense]]</nowiki></code>.
* If you wish to get extra-fancy, you can write:
::<code><nowiki>[[1st Line of Defense|{{1st}} Line of Defense]]</nowiki></code>
: which produces: [[1st Line of Defense|{{Ordinal|1}} Line of Defense]].
Also, be aware that unlike Wikipedia's Ordinal, ours only does superscripts. They're always enabled. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 06:10, 10 July 2018 (UTC)
:: I've put this neat little template [[Djonni#Vitalstatistix|to use]] in my page's infobox! Very nice :) --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 08:54, 2 August 2018 (UTC)
== First two mobile-friendly infoboxes are live! (Please test!!) ==
Everyone, the first mobile-friendly Infobox (see [[Talk:Main Page/Archive#Formatting Infoboxes in the mobile view|"Formatting Infoboxes in the mobile view"]]) is now live. All [[:Category:Pets|Pets]] articles that use a [[Template:Pet]] infobox (that would be [https://wiki.godvillegame.com/index.php?title=Special:WhatLinksHere/Template:Pet&hidelinks=1 all of these]) will now have an infobox that will adapt to your screen size when viewing the page.
: '''Update:''' As of 23 July 2018 02:45 (UTC), [[Template:Town]] is also upgraded with the mobile-friendly layout , so on any page that uses {{tl|Town}} the infobox should adapt to the screen size automatically. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 02:50, 23 July 2018 (UTC)
I'd like to ask as many users as possible, if they have a chance, to look at as many Pet articles as they can, and on as many types of devices as we can get sampling from. Whether it's a tablet device, any model iPhone or Android phone, heck even an old Palm Pre or whatever. And if you just want to check it out but don't have access to any of those, you can use the Mobile view link at the bottom of any page in the Godwiki to switch into the mobile skin from your desktop browser. In fact, that can be some of the best testing, because then you can change the window size and see how the page responds.
What you ''should'' see, if there are no problems, are:
# Right off the bat, the infobox is cleaner in ways you probably won't notice, but trust me, it's there. While I was updating the code I corrected a lot of structural errors that were causing lots of extra table rows, double borders, etc. All of that should be gone.
# '''Other than''' that, in the desktop browser view there should be no visible difference whatsoever.
# In the mobile view, what you should see is a page that keeps the normal formatting with the infobox on the right and text flowing to its left, ''unless'' the window/screen becomes too narrow, in which case the infobox will center itself on the page and push the text down below it. This should happen pretty seamlessly in a web browser (in mobile view) as you narrow the window.
# On a phone, most likely the page will start out with the centered, no-text-alongside infobox, as it's meant to.
Please report any issues you see, either here or on my [[User talk:FeRDNYC|talk page]]. I'd like to get the rest of the infoboxes updated next week, if there are no concerns about the Pet articles. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 02:54, 21 July 2018 (UTC)
: I just fixed a couple of issues with the {{tl|Pet}} infobox sizing on mobile, one that blew out the frame too wide on narrower devices, the other that made the box too _narrow_ on wider screens (like tablets). -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 10:20, 22 July 2018 (UTC)
:: I checked on your update to the pet template, and on my iPhone 5S, the box is blown out to the left. It does look a lot better, minus the shift to the left -- [[User:Holy Spirit of Hell|Holy Spirit of Hell]] ([[User talk:Holy Spirit of Hell|talk]]) 01:08, 24 July 2018 (UTC)
::: Hmm, thanks. I'll take a look. Not immediately showing up on my phone, but I'll poke around with the mobile browser skin, and some device simulators if need be. Did you happen to notice if it was the same on every pet page (or, if you looked at more than one, all of those)? -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 03:29, 26 July 2018 (UTC)
::: Sorry, H.S.H., I can't seem to replicate. I tested the site in Safari on an emulated iPhone 5 and an emulated iPad Air, ''as well as'' in '''both''' Safari and Firefox on a ''real'' iPhone 6S (thank you, BrowserStack free trial!), and in every case the infoboxes looked as expected in both device orientations.
::: I captured a screenshot of the [[Terror Bull]] article on every one of those platforms/browsers I mentioned, in both orientations. There's a gallery post showing all of them here: https://imgur.com/a/P6qMfGO — can you take a look and let me know if anything there fails to match what you're seeing on your 5S? -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 04:28, 26 July 2018 (UTC)
::: In re-reading your comment, H.S.H, I realized I should maybe define "blown out" as I used it to describe the old infoboxes. The issue with the existing Infobox templates (the ones I haven't updated) is that the wiki mobile skin forces them to 100% width on any smaller-width screens. That can cause the columns of the infobox to become stretched wider than intended in ugly, weird ways. For example, here's the [[Bully Mammoth]] article on my Galaxy S6, in landscape orientation: https://imgur.com/a/WEA4uea . You can see that there's a large box to the right of the infobox, because the table that contains it is forced to be the entire width of the screen.
::: With the new infobox changes, that won't happen. (or, it's not supposed to, unless there's a bug in my changes.) Instead, what's ''supposed'' to happen is that the box will keep its specified width and just center itself on the page. If you're seeing boxes '''shifted''' to the left, but not distorted (improperly sized)... well, I'm not sure what's going on there, since as I said in my previous post I wasn't able to reproduce it in Safari or Firefox on BrowserStack's emulator farm. But, since I wasn't running the Godville app on iOS, it's possible that browser is slightly different. Still, if you can give me more details on the issue you were seeing, I'll try to look into it further. Thanks. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 06:15, 29 July 2018 (UTC)
:::: It's now been a week since Holy Spirit of Hell's report of iPhone issues with the new infoboxes, and still no word back. H.S.H. doesn't appear to have been around the wiki much in that time, though... I guess I'll wait to the end of the week, and then decide how to proceed if I still haven't heard anything. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 01:30, 2 August 2018 (UTC)
::: <span id=Djonni_20180802>{{god|Holy Spirit of Hell}}</span>, when you say "on iPhone", are you using the Godville app's built-in browser for viewing the wiki? And, if yes, have you told the built-in browser you want the "desktop" view?
::: I ask because, for unfathomable reasons, the app's built-in browser's 'desktop' view uses totally unique CSS that is '''''just awful''''' and breaks a lot of basic Wiki formatting. What you describe sounds like standard SNAFU behaviour in that use case. --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 08:51, 2 August 2018 (UTC)
: Apologies for (re)joining the conversation on this late, I've been organising a move to a different hemisphere and it's taken more cognitive budget than I had available on a daily basis. While I'm not finished, I've passed enough milestones that my brain has a little more space again!
:Taking a look at the Pets and Towns infoboxes live across a sampling of pages they look good so far on a 6" device (Chrome on Android) and a 5" device (Chrome on Android). All my other mobile devices are packed into storage, sadly!
:I'd say it's ready to be rolled out further, pending HSH adding further information above! --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 08:51, 2 August 2018 (UTC)
:: Well, no word back from Holy Spirit of Hell after a week and a half. I left a talk page message (only just now), hoping that might get their attention, but I'm inclined to go ahead with this as-is. I'll convert the rest of the infoboxes when time permits, and if we do hear anything back I'll look into it. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 02:15, 6 August 2018 (UTC)
::: Done, [[Talk:Main_Page#Remaining_Infoboxes_updated_with_mobile-friendly_code|see below]]. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 11:19, 7 August 2018 (UTC)
{{outdent|::::}} Over on Holy Spirit of Hell's [[User talk:Holy Spirit of Hell|talk page]], H.S.H provided [https://imgur.com/kPAbuA9 this screenshot] of the [[Terror Bull]] rendering, which is definitely not how it's supposed to look. Still investigating. I've requested a survey of how various other Infobox configurations render on the same device, now that they're all upgraded with the new code, so I can hopefully get a handle on exactly what circumstances lead to that glitch. Hopefully that'll get us closer to figuring out the "why", and then we can work out how to prevent it. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 19:50, 7 August 2018 (UTC)
: <span id="HSH_glitch_explained">'''Ohhhhhhhh''', I see what's happening!</span>
: The rendering that H.S.H screenshot only occurs if you view the wiki using the ''desktop skin'' on a phone-sized mobile device, which isn't really wide enough to render that skin properly. If you view the pages using the mobile skin, they look fine.
: One complication seems to be, if you switch to the desktop view in the Godville app mobile browser, it doesn't look like there's '''any way''' to get back to the mobile skin! The links that would normally be shown at the bottom of the page aren't there. However, this link should return the browser to the mobile skin: [http://wiki.godvillegame.com/index.php?title=Talk:Main_Page&mobileaction=toggle_view_mobile Switch to Mobile Skin].
: I'm not sure how to prioritize solving the rendering issue with desktop-skin-on-mobile. My initial inclination is to not really worry about it (and instead focus on getting people switched back to the mobile skin). -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 20:11, 7 August 2018 (UTC)
:: The issue, in a nutshell, is that the Godwiki can be rendered in one of '''three''' skins:
::* The standard desktop-browser skin, Vector
::* The mobile skin, Minerva
::* The desktop-site-requested-on-a-mobile-device skin, WPTouch
:: Without access to edit the site/skin CSS itself, it's generally possible to optimize for one or, at most, ''two'' of those, at the risk of causing issues in the third. Which is what we're seeing here. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 20:52, 7 August 2018 (UTC)
::: This is what I was trying (without much success) to refer to [[#Djonni_20180802|above]]. That ''switch to mobile skin'' link you found/crafted {{god|FeRDNYC}} is '''pure gold''', I and many others have had to delete and reinstall the app to fix that! That deserves its own (pinned) Talk topic here on this page, honestly. That skin (WPTouch) causes lots of layout and formatting problems, all over the place. Hitting ''switch to desktop'' on the GodWiki in the GV app's built-in browser effectively breaks the wiki, with no (until now!) way to switch back. --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 02:21, 9 August 2018 (UTC)
== Remaining Infoboxes updated with mobile-friendly code ==
I've just finished updating the {{tl|Monster}}, {{tl|Artifact}}, {{tl|Beastie}}, and {{tl|Guild}} Infobox templates with the same mobile-friendly code that was already in place on {{tl|Town}}, {{tl|Pet}}, and (the so-far-unused) {{tl|Equipment}}. That covers every article-space infobox in the system, the only remaining ones are {{tl|Hero}} and {{tl|Usergod}}/{{tl|Usergoddess}}, which I may get to at some point in the future, but they're lower priority.
Along the way, I cleaned up the code in all of them, to varying degrees (dependent on how bad the existing code was). And, some specific items of note:
* '''For {{tl|Artifact}}:'''
:: I fixed the auto-categorization for the specialty categories ([[:Category:Bold Artifacts]], [[:Category:Healing Artifacts]], [[:Category:Activatable Artifacts]]), which was completely broken as it was dependent on nonexistent parameters.
:: It now works off the <code>|type=</code> parameter, case-insensitively and ignoring whitespace, as follows:
::* If <code>|type = Bold</code>, place in [[:Category:Bold Artifacts]]
::* If <code>|type = Healing</code>, place in [[:Category:Healing Artifacts]]
::* If <code>|type = Activatable</code>, place in [[:Category:Activatable Artifacts]]
:: Also, <code>| monster = <i>something</i></code> will cause the article to be placed in [[:Category:Monsters' Artifacts]]. (This is in addition to always placing the article in [[:Category:Artifacts]].)
:: This means that it should no longer be necessary to manually place Categories in Artifact articles ''at all'' (if they are using {{tl|Artifact}}), and when editing an article that uses the template it is preferable to '''remove''' redundant manual categories. This is so that, if there is a mistake in the template data that changes the category when corrected, there will be no conflict between the categories exported by the template and the categories placed in the article.
* '''For {{tl|Guild}}:'''
:: This template got the biggest changes of all. In addition to '''''massive''''' code cleanup (it was a MESS)...
::* I completely re-wrote the processing of the multiple <code>|founder=</code> (plus <code>|founder2=</code>...<code>|founder5=</code>) parameters, to create a bulleted list of all the provided founders.
::* I re-wrote both the <code>|friend1=</code>...<code>|friend8=</code> and <code>|foe1=</code>...<code>|foe5=</code> processing, so that both Allies and Rivals are displayed as a bulleted list taking up a ''single'' cell, instead of one-row-per-entry like the previous code.
::* I increased the infobox width to <code>25em</code>. I felt that was a better fit with the new bulleted Founder(s) list, as it tends to be wider.
::* <code>|position=left</code> is no longer available for this template, due to the mobile-friendly code change. That's true of all the infobox templates, post-change, but this template seems to be the one where <code>position=</code> was most used. Any guild pages designed around left-aligned {{tl|Guild}} infoboxes will need to be redesigned to accommodate the right-aligned infobox. I apologize for the inconvenience, but I'm afraid it's a necessary tradeoff to get proper formatting on mobile screens.
If any of my changes tonight are going to be problematic for people, it's likely the changes to {{tl|Guild}}, either technically (there might be bugs) or philosophically (you might object to the decisions I made). In either case, please bring up the issues here and we'll come to a resolution. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 11:18, 7 August 2018 (UTC)
== [[Template:Navboxboss-monsters]] renamed to [[Template:Navboxbosses]] ==
The name {{tl|Navboxboss-monsters}} just struck me as long and awkward to type, so I've renamed the template to {{tl|Navboxbosses}}. The old name is now a redirect, so existing calls will still work and you can continue to use the old, longer name if you prefer. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 09:22, 14 August 2018 (UTC)
== Reformat [[List of Quests]]? ==
{{m|done}} — The table is now a single-column list of quests and quest type. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 21:52, 11 September 2018 (UTC)
So, after determining that [[List of Quests]] looks basically awful in either mobile skin, with all of the columns squished into narrow oblivion, I'm considering reformatting it from the current doubled-up format to a single-column table like all the others. It'll make the page ''seem'' longer (and in truth they will be ''slightly'' longer in the desktop view), but that will be offset to an extent because all of the rows that are currently wrapping to two lines would flatten out to a single line. So, it won't actually be as ''much'' longer as it may seem.
And more to the point, it'll be vaguely readable in the mobile skin(s), which seems worth the extra length. Plus, it'll allow for column sorting and other niceties that the current format ruins.
I'd do the actual edit with a regular expression find/replace algorithm, downloading a copy of the page source and then re-uploading the reformatted version, I'm not crazy enough to do all that by hand. So, it wouldn't be too much of a chore. Still... any thoughts or feelings one way or the other? -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 20:19, 26 August 2018 (UTC)
: The silence was deafening, so I've asked at [[Talk:List of Quests#Reformat?|Talk:List of Quests]] as well. If I don't hear anything there in a few days, I'll just go for it. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 13:56, 1 September 2018 (UTC)
::All sounds good, I say go ahead. —[[User:Holy Spirit of Hell|Holy Spirit of Hell]] ([[User talk:Holy Spirit of Hell|talk]]) 00:51, 3 September 2018 (UTC)
== New [[Template:Equipment]] ==
I admit, it's not ''super'' necessary, but it just felt weird that we didn't have a [[Template:Equipment]] to go with all of the other infoboxes. So, now we do. It's very simplistic, but with 117 articles in [[:Category:Equipment]] it felt right to start standardizing them. I'll probably try to go through and apply the template to those 117 articles starting next week.
Three items of note:
# This template is unique among the infoboxes in that it uses a generic image, if one is not supplied in the template call. (You can see the image on the template page.) However, it's definitely preferable to supply a specific image to override the generic one.
# I included the "Durability" stat that I noticed was already listed on ''many'' existing Equipment articles, even though TBH I'm not really sure that actually means anything. (Meaning, I suspect that equipment items can be found at any durability level. But, I could be wrong!)
# This template uses the [[Talk:Main Page#First two mobile-friendly infoboxes are live.21 .28Please test.21.21.29|new infobox code for mobile browsers]].
As always, please report issues, either here or at [[Template talk:Equipment]]. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 01:15, 3 August 2018 (UTC)
:The absence of an equipment infobox template has occured to me as odd more than once, and I ''love'' the default image (both in principle and in the specific choice). I feel like a default image is worth considering for other infoboxes, it's a quick way to add a little polish to stubs. Perhaps the default image field might include a caption with a link to upload a {{tl|PAGENAME}}.jpg...? We've discussed #ifexists being expensive before, and it's probably unwise to include them in template defaults, but it sure would be elegant if a template found an existing PAGENAME.jpg file. Just brainstorming :) --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 01:58, 3 August 2018 (UTC)
:: I'd be reluctant to do that (the <code>{{{PAGENAME}}}.jpg</code> thing) for two reasons. No, three. None of which have anything to do with the code performance.
::# The images might not be JPGs. They might be .PNG files, or GIFs.
::# It's preferable to let people use their own filenames for uploads.
::# The previous is '''especially''' true when ''replacing'' images.
:: Say someone uploads a <code>Terror Bull.jpg</code> image. That image may be used somewhere in some '''other''' article. Now, if someone wants to replace the image in the [[Terror Bull]] infobox, the way to do it would be to upload a new image (with a unique filename), and update the template call. If they're given the impression the image "should be" named <code>Terror Bull.jpg</code>, and they upload their new image to ''overwrite'' the old one, then it gets changed everywhere, which may not be desirable to anyone who's used that image elsewhere.
:: I think we could have generic, "default" images for the other infoboxes, but they should be just that: A generic image that's used '''unless''' an image filename is specified. Typing a filename into the template call isn't particularly onerous. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 02:38, 3 August 2018 (UTC)
:::Mmm, you make good points there, particularly about replacing images. Perhaps just something like <code><nowiki><small>[[Special:Upload|Upload]] an image.</small></nowiki></code> would be enough. And a <code><nowiki>[[Category:Pictures needed]]</nowiki></code> might be clever, come to think of it? --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 08:47, 3 August 2018 (UTC)
:::: I think showing an upload link makes sense — good idea. Right now {{tl|Picture}} only shows a page-edit link, which is only useful if you've already uploaded the file. Guiding people to [[Special:Upload]] as the first step in adding photos is probably more useful.
:::: In fact, it ''might'' be possible to auto-template the page as {{tl|Picture}}-needed if the default image is used. (Or just whenever the <code>|image=</code> parameter is missing, even in infoboxes that don't have a default image.) Whether or not that will '''actually''' work depends on whether the Godwiki css includes some form of the same classes that Wikipedia uses for message boxes, that forces them to the top of the page no matter where they're placed in the article source. Which, come to think of it, I bet it doesn't. ...Still, I can just stick the {{tl|Picture}} template '''before''' the infobox code, and it should end up in the right place.
:::: I'll take a swing at adding that (along with a parameter to override it, I guess, just for peace of mind) to some of the infoboxes, starting with {{tl|Equipment}}. And also have them do auto-categorization into a sub-[[:Category:Infobox picture needed]] on the same criteria. (Although {{tl|Picture}} will auto-categorize the page into the general [[:Category:Pictures needed]], so maybe both is overkill.) This way, the modifications to the add-an-image flow (pointing to [[Special:Upload]] before / instead-of the edit link) can be made in the {{tl|Picture}} box instead, and they'll benefit all pages it's used on. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 10:55, 3 August 2018 (UTC)
{{outdent|::::}} Yesss, putting {{tl|picture}} at the head of the infobox is a ''very'' clever approach. And I don't hate having a special category for infobox pictures, I think that's a good category to have available when one's looking for some quick improvements to make. I personally would say that an infobox without a picture rises to a higher priority than a general stub without a picture, I don't think having it categorised both ways is overkill.
This is one of those times that having already updated the Guidebook would be helpful &mdash; {{tl|picture}} ''could'' point to an upload-and-edit guide. Maybe it's worth touching that specific part of the guidebook up immediately. {{m|notnow}} (TODO) --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 05:35, 4 August 2018 (UTC)
:It's good ''enough'', I think, to have {{tl|picture}} point into [[Creators_Manual#Images]] without rewriting. Notwithstanding that it could be improved there. --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 05:57, 4 August 2018 (UTC)
:: For the ''general'' case of "this article needs pictures", agreed, but actually for the Infobox case specifically it's kind of overkill, because they don't actually need to worry about '''any''' of that. To add an image to an infobox all you do is upload the file and enter the filename, you're spared having to worry about the intricacies of <code><nowiki>[[Image]]</nowiki></code> linking.
:: (And even when it comes to the syntax, if only the explanation at the top of [[Special:Upload]] actually demonstrated <code><nowiki>[[Image]]</nowiki></code> syntax instead of <code><nowiki>[[File]]</nowiki></code> and <code><nowiki>[[Media]]</nowiki></code>, I might say it's as good as the one in the Creators Manual.) But, regardless, because infobox image-adding is even simpler, maybe we should have a special version of / path through {{tl|Picture}}, where we just instruct them to upload a file and paste the filename into the template as an <code>|&nbsp;image=</code> parameter, rather than dumping all the rest of that noise on them? -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 10:08, 4 August 2018 (UTC)
::: Limited on time right now, but wanted to say: 1) Yes, actually, that makes sense (not to point editors to the Creator's Manual just to add an infobox image). Perhaps a short, sweet <code><nowiki> ===Adding an image to the template=== </nowiki></code> should be in each <code><nowiki>Template:XX/documentation</nowiki></code> page, with a link in the default image table cell (e.g., <code><nowiki><small>[[Special:Upload|Upload]] an image and [[Template:XX/documentation#Adding_an_image_to_the_template|put it here]].</small></nowiki></code>)? --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 02:34, 9 August 2018 (UTC)
::: Oh yeah, and point 2) I will (I ''will'' I ''will'') start adding {{tl|equipment}} to existing pages, aaaany day now. --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 02:35, 9 August 2018 (UTC)
:::: [[Mace of amnesia|Tadah!]] --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 08:03, 13 August 2018 (UTC)
::::: And [https://wiki.godvillegame.com/index.php?title=Special:WhatLinksHere/Template:Equipment&hidelinks=1 already up to 9 pages] now, woo! 🤩 I shall honor your diligence by being lazy and continuing to not do any of those myself. 😏 You're Welcome™! (But maybe I'll get to that {{tl|Picture}} stuff we discussed... after I sort out those last issues with the new Main Page.) -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 08:12, 14 August 2018 (UTC)
:::::: Hey... hold off, if you can, before doing any more of these. [https://wiki.godvillegame.com/Talk:Djonni#Template:Equipment_subcategorization I just had an idea]. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 13:08, 14 August 2018 (UTC)
::::::: Never mind, idea implemented! -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 16:12, 14 August 2018 (UTC)
:::::::: Also, BTW, I didn't realize I'd broken the parameter check so that you couldn't include a blank <code>image</code> parameter without breaking the default image, but I've fixed that now. So, feel free to make an empty <code>| image =</code> part of your boilerplate, it'll work fine! -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 16:14, 14 August 2018 (UTC)
{{outdent|::::::::}} {{m|done}} The auto-{{tl|picture}} templating we'd discussed is now in place on {{tl|Equipment}}. For the moment it just uses the standard [[Template:Picture]], that can be adjusted later on if we develop any specific new flows. I've already taken the liberty of removing the manual (now-redundant) {{tl|picture}} transclusions from the Equipment articles where you'd already added it (there were only a couple). -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 04:11, 15 August 2018 (UTC)
: The automatic {{tl|picture}}ing looks better than I feared, looks seamless. If I notice any funny edge cases or anything as it gets rolled out I'll bring it to your attention but I can't imagine what. 👌 --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 17:42, 17 August 2018 (UTC)
==Many GodWiki pages need to be deleted==
There are a lot of junk/clickbait pages that just redirect to the main page. Perhaps a moderator/administrator could look into removing them? --[[User:ElectroChip|ElectroChip]] ([[User talk:ElectroChip|talk]]) 16:22, 9 May 2017 (UTC)
:There are certainly a lot of dead pages on the Wiki, which sadly right now doesn't have an active administrator other than the actual Godville Admin team who spending all their time hard at work on improving the actual game and its content for us all.
:For now, we all can help a hypothetical future administrator do a deep clean of the wiki by adding the {{tl|delete}} template to any page that you think an admin should remove one day. It's probably wise to provide a reason why you feel a page deserves deleting too, by doing something like <code><nowiki>{{delete|This page violates CP-symmetry and may cause vacuum decay, ending the Universe.}}</nowiki></code>
:All pages that have the {{tl|delete}} template on them appear in [[:Category:Marked for deletion]]. This list will be one of the first stops, I expect, for any future admin to do a clean-out. (''Hello hypothetical future admin, please know, if you're reading this, that we understand the very large pile of work you've been left with and deeply appreciate your hypothetical future work!'')--[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 09:04, 9 June 2018 (UTC)
:: Just as a point of information, the pages that [[User:ElectroChip|ElectroChip]] is talking about that "just redirect to the main page" most likely ''have'' been deleted, which is '''why''' they redirect to the main page -- without adminship, other users can't delete pages, but they can replace spammy/inappropriate page content with a quick <code><nowiki>#redirect[[Main Page]]</nowiki></code> to obliterate everything except the page title. I know that [[User:BlueStapler|BlueStapler]], and probably others, have taken the initiative to wipe out page-level spam and vandalism in that way, when necessary.
:: For truly deletion-worthy articles that just shouldn't be here at all, that's probably a better approach than setting the delete template since, right now, there's simply no expectation that'll ever be responded to.
:: The delete template still has its purpose, as it's a good way to indicate things like Templates that are no longer useful, or userspace subpages that the user no longer needs (since we can't even delete pages from our own userspace, annoyingly). -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 14:43, 1 July 2018 (UTC)
:::I actually find it a little disorienting when an otherwise blank page simply redirects to the Main Page, particularly on mobile where redirects aren't breadcrumbed. Perhaps it's a preference-driven thing &mdash; I'd rather a clear {{tl|delete}} tag on a dead page than an unexplained redirect to an unrelated default page. I also imagine a Hypothetical Future Admin finding a straightforward (if large) list of [[:Category:Marked for deletion|pages marked for deletion]] a little simpler than having to also go through the list of  [https://wiki.godvillegame.com/index.php?title=Special:WhatLinksHere/Main_Page&hidelinks=1&hidetrans=1 pages that redirect to the Main Page], though perhaps I'm too optimistic about the advent of the HFA. I seem to be an HFA Adventist, come to think of it, and act as if I believe that I can immanentize the coming of the HFA by preparing the Godwiki for His or Her manifestation... Hmmm. --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 03:29, 2 July 2018 (UTC)
:::: I won't dispute that it's disorienting, but how frequently does this really come up, in '''normal''' wiki use? Meaning, if you're not someone poking around behind the scenes?
:::: Those articles shouldn't be linked to from anywhere, so the only way they're likely to be found by normal users is in search results. For those users, landing on a {{tl|delete}} page dead-ends them while showing no useful information. They don't '''care''' that a page is flagged for deletion. OTOH, being redirected to the main page means they can continue browsing the wiki. For the average user with no interest in the administrivia of the wiki, that's likely the preferable outcome. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 12:29, 3 July 2018 (UTC)
===Defunct Guild pages===
A ''very'' large proportion of [[Special:FewestRevisions|dead]], [[Special:ShortPages|short]], [[Special:LonelyPages|unlinked]], [[Special:UncategorizedPages|uncategorised]] pages are stubs that were created for guilds that no longer exist. I'm in two minds about how these pages should be treated, but I have a proposal.
* I think we should have a new '''Dead guilds''' category (as sub-category of [[:Category:Guilds]])
* I think we should have a new {{tl|deadguild}} template that:
** Uses the {{tl|delete}} template as a basis, with similar design;
** States that this guild is "not widely known on Godville";
** Gives a link back to the https://godvillegame.com/stats/guild/(guild_name) so it's easy to check if the guild remains dead at any time;
** Categorises the tagged page as a dead guild, obviously.
That way these pages aren't ''necessarily'' [[:Category:Marked for deletion|marked for deletion]] as such, but they are ready for a hypothetical future admin (HFA) to do a spring clean if the HFA decides to slough off that particular kind of dead weight. (''Hello HFA, thanks again for your hypothetical future work!)
I would likewise propose that a page only be a candidate for tagging with {{tl|deadguild}} if:
* The URL for the guild states that it is "not widely known on Godville";
* There have been no edits to the page for... lets say, 6 months? 12 months? This would allow baby guilds to grow enough to have a stat page.
The guild page could easily be checked by editing the candidate page, inserting the template, previewing the edit, and clicking the link in the template before saving your change.
Specifically, as an example:
|img=RIP-gravestone grey.png
|title=This article is for a guild that doesn't appear to exist.
|text=The [http://godvillegame.com/stats/guild/Alcyone guild stats page] matching this article states that ''The “Alcyone” guild is not widely known in Godville.'' If you are a member of this guild, or can confirm that the guild now exists, please remove this template.
<!--  |text=The [http://godvillegame.com/stats/guild/{{BASEPAGENAME}} guild stats page] matching this article states that ''The “{{BASEPAGENAME}}” guild is not widely known in Godville.'' If you are a member of this guild, or can confirm that the guild now exists, please remove this template.-->
<!-- Note: the use of {{BASEPAGENAME}} here allows the template to work as intended even if used on a talk page. -->
<!--  |cat=Dead guilds -->
Any thoughts on this from anyone? --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 00:40, 10 June 2018 (UTC)
==HTML layout and the <code>width</code> attribute==
It's months old, but I'm manually reversing one of [[User:Holy Spirit of Hell|Holy Spirit of Hell]]'s [https://wiki.godvillegame.com/index.php?title=Main_Page&diff=prev&oldid=76563 good-faith edits] to the layout of the main page, because it blew out the width of the page beyond the right edge of the viewport. In doing so, I wanted to drop a quick note about dimensions in HTML layout and the <code>width</code> attribute. (This isn't meant to shame you or call you out, [[User:Holy Spirit of Hell|Holy Spirit of Hell]], and the whole reason I'm posting this info '''here''', instead of on your talk page or similar, is that I'm sure there are multiple people who could benefit from it.)
Also, let me say that the following is at the very least '''vastly''' oversimplified. (Yes, even considering how long it is.) You should really be getting this sort of knowledge from good sources like [https://developer.mozilla.org/ Mozilla Developer Network (MDN)] or even "meh" sources like [http://w3schools.com w3schools], not from me. Hell, I'm sure at ''least'' one thing I'm about to say is just plain wrong... I just don't know which one(s)!
Specifying dimensions for layout elements in HTML is generally fraught with peril. But there are different levels of peril:
* Specifying exact '''pixel''' dimensions (e.g. <code>width="640px"</code>) is ''evil'' and should be avoided at all costs, it's one of the main things that makes pages lay out improperly in mobile browsers, just for starters. (Image dimensions are ''somewhat'' of an exception to this, though even there it's problematic if images are placed at fixed sizes with no regard for how they affect the content layout on different size screens.) '''Point''' size dimensions (<code>width="10pt"</code>) fall into the same category, as points are a fixed-size unit that doesn't scale.
* Specifying dimensions in '''em''' units (<code>width="10em"</code>) is slightly better, as ems are related to the font size the content is displayed at, so they'll be autoscaled to match the device's base font size (as long as the font size isn't overridden using a pixel or point size!) Still, while these dimensions autoscale to fit the display size, they're frequently not predictable enough to use for layout. There is also the '''rem''' unit (<code>width="10rem"</code>) which is relative to the ''root'' font size, making it slightly more predictable since it means the same thing everywhere on the page, no matter what font size is set for that content.
* Specifying dimensions in '''percentages''', if one must specify dimensions at all, is best, and for the most part it's how Godwiki is laid out. But it's important to know what those percentages mean.
** A percentage width in HTML is interpreted ''relative to the width of the element's container''.
** For that reason, <code>width="100%"</code> is '''by far''' the most commonly-used dimension in HTML layout, and it simply means "expand to fill all of the horizontal space available to me".
** Percentages ''less'' than 100% are used when elements are placed side-by-side within the same container, to adjust how how the available space is allocated among them. Generally, if percentage widths less than 100% are used, they should be specified on multiple elements laid out horizontally, so that they all '''add up''' to no more than 100%, and ideally to exactly 100%.
** Percentages ''greater'' than 100% tell an element to grow larger than its container, which is almost never what you want to do and will cause all sorts of problems, from elements overlapping to elements sticking out past the edge of the screen. Browsers will try to correct for some of this (by autosizing child elements to smaller than the >100% container size, for example) but at the very least you'll end up with a jorizontal scroll bar for no good reason.)
So, that's why changing two <code>width="100%"</code> elements to <code>width="110%"</code> and <code>width="90%"</code> will '''never''' look as intended. The percentages still add up to the same (200%). The total '''width''' of the elements is ''nearly'' the same. (If their containers are different widths it won't be ''exactly'' the same, though. Observe: 110% of <code>600px</code> is <code>660px</code> but 90% of <code>400px</code> is <code>360px</code>, so the total width increased from 600+400 = <code>1000px</code> to 660+360 = <code>1020px</code>.) But instead of two balanced elements, we've now got one element that doesn't fill its container, and leaves wasted space alongside it, and another element that sticks out of its container and disturbs the layout of the surrounding content. The correct way to adjust the width of <code>width="100%"</code> elements is to find which of their ''containers'' define the respective widths (using something other than <code>width="100%"</code>, either smaller percentages or specific units) and adjust '''those''' dimensions, while leaving the elements in question set to <code>width="100%"</code> as, again, that just means "fill my available space".
Oh, and last but far from least:
* Best by far is when we can avoid specifying widths at all, and allow HTML to flow the elements automatically. The width of block elements will automatically expand to fit the content they contain, up to the size of ''their'' containers. That's usually what we want. <code>width="auto"</code> makes this explicit, and specifying it can be useful if explicit widths were set elsewhere that need to be uninherited. <code>width="auto"</code> is also better than <code>width="100%"</code> because it accounts for things like padding and margins, whereas setting 100% width can force elements into those spacers (or force those spacers beyond the screen borders) under certain circumstances.
-- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 14:04, 3 December 2017 (UTC)
I'm actually going to amend this, some, to say that when talking about the '''entire''' page width (or, the entire content-area width, not counting things like sidebars), percentage widths are ''also'' some of the worst things you can use. In those contexts, "real" dimensions like <code>em</code> widths are far better than percentages, because those widths scale intelligently with the screen size, whereas percentage widths '''don't'''.
Some of the biggest problems we've had with formatting the wiki to be mobile-friendly have been with content formatted with something like <code>width=60%</code> or whatever. The problem is that the same content is going to take up 60% of the width of '''any''' screen it's displayed on — which is probably fine, for a desktop browser, but clearly is going to be a problem in a phone browser.
In fact, it was only by setting the width of {{tl|Diary}} and {{tl|Diaryquest}} to pixel values that I was able to make them readable on mobile browsers. (And I'm experimenting now with changing those widths to <code>em</code> widths, to better scale to different pixel densities.) By the same token, updating the [[Main Page]] sections to use <code>em</code> widths instead of <code>width=55%</code> and <code>width=45%</code> was a big part of creating the new mobile-friendly layout. (The other part was formatting them with CSS flexbox, so that they'll automatically rearrange themselves vertically if there isn't enough room on the screen to fit them side-by-side.) -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 10:04, 17 August 2018 (UTC)
:: {{tl|Diary}} and {{tl|Diaryquest}} now both specify their minimum width or width (respectively) as <code>18em</code>, to better scale with different screen dimensions '''and''' pixel densities. That has almost certainly changed the size of your existing boxes, and may even have changed it ''differently'' on different screens. Sorry, but OTOH this can also serve as a reminder that the Web is not a desktop publishing platform, and is not intended to be laid out like a magazine. Web content will always be resized and reformatted to serve the needs and interests of the reader, not the author — and this is as it should be. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 15:22, 20 August 2018 (UTC)
== New mobile-friendly [[Main Page]] ==
The [[Main Page]] of the wiki is using a new layout that should automatically size itself to your screen, even on mobile devices. Please kick the tires, but if we get a flat it's '''''your fault'''''! 😜
The page will look not-great-at-all in the "Desktop" mode on a mobile browser. That skin is just terrible and nothing will ever look very good in it. However, in the interest of saving people from its awfulness, when you are viewing the site with that skin (only), the bottom of the main page will now include a link to "Switch back to the [https://wiki.godvillegame.com/index.php?title=Talk:Main_Page&mobileaction=toggle_view_mobile mobile skin]". -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 05:51, 16 August 2018 (UTC)
:Right now, the ‘desktop skin’ for mobile is much easier to navigate around, due to the smaller font, the mobile version has a lot of scrolling around. For any further improvement, I’d suggest making the mobile fonts show up smaller if possible —[[User:Holy Spirit of Hell|Holy Spirit of Hell]] ([[User talk:Holy Spirit of Hell|talk]]) 03:52, 25 August 2018 (UTC)
::Hmmm 🤔 I'd be pretty hesitant to permanently reduce font sizes on a particular platform like that (and without an admin, I doubt it's feasible). But you might find that opening the page in your phone browser, rather than the app, gives you more control over font sizing. I know in Safari on iOS it's pretty straightforward, less so on Chrome or Firefox, but still possible.
:: Considering how many Godville users are using low-cost devices with small screens, or have a vision impairment or other accessibility need, making text size and touch target size smaller than default seems a little problematic to me. --[[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 06:18, 25 August 2018 (UTC)
::: I agree there are certain areas where the fonts are a little oversized, though the most glaring ones are things like section headings which we ''especially'' have no control over. We could change the body text size, but I'm not sure how much benefit there would be, and as Djonni says it could cause issues for other people using the wiki.
:::: And when I say that, I mean we totally ''couldn't'' change the body text size, either — except by doing something completely insane, like editing every individual page to add some code. But even '''if''' we could (which we can't, realistically)... -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 19:15, 28 August 2018 (UTC)
::: But it's true, the WPtouch skin definitely packs more text onto the screen, though I personally feel it's at the expense of comfortable navigation. Lists, in particular, are squeezed way too tightly together, making it difficult to tap on any individual item without potentially hitting an adjacent one. The mobile skin adds extra space between each item to help stave off that problem, and though I don't feel it's done in the most attractive way I do appreciate the effort.
::: I don't know if you've explored the mobile skin ''lately'', H.S.H, but IMHO it's a '''lot''' better now that basically all pages reformat themselves to fit the display so there's no horizontal scrolling. Like I said, it definitely isn't as compact and space-efficient as WPtouch, but I feel it makes the right choices for the most part. Especially when you're browsing by touch, there is such a thing as ''too'' compact. The way the Godwiki mobile skin renders is pretty much equivalent to standard Wikipedia's mobile rendering, in terms of font size and etc., and I trust them to have looked at the issue and come up with the solution that works for the majority of people.
::: One big ''difference'' between Godwiki and Wikipedia mobile sites is that on Wikipedia, tapping the Desktop link at the bottom of the page switches you to the '''real''' desktop-browser interface: impossibly tiny text, huge page layouts, the works, exactly as it looks in Chrome or Firefox on my computer. Personally I'd prefer that for Godwiki, if the user really wants a desktop interface they should get it. Better than this halfway-measures WPtouch abomination. But, again, that's completely out of our control I'm afraid. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 19:01, 28 August 2018 (UTC)
== New convenience template for referencing Godville Blog posts ==
Since the {{Cite blog}} is one of the few outside resources we ever cite as a reference on this wiki (see [[History]], especially), and in the interest of encouraging more of that (where appropriate), I've created a new convenience template {{tl|Cite blog}} for creating links to Godville Blog posts.
Just give it a post number, and it'll create a link to that post. If you leave out the post number, it'll just provide a general link to the blog (as seen in my opening paragraph):
{| class="wikitable"
! Wikicode !! Renders as
| {{Tlx|Cite blog|117}} || {{Cite blog|117}}
| {{Tlx|Cite blog|116|To the Point}} || {{Cite blog|116|To the Point}}
| {{Tlx|Cite blog}} || {{Cite blog}}
More documentation, including an example of how the template can be used in creating citation references in articles, can be found on the [[Template:Cite blog|template page]]. I may add additional parameters, like the ability to provide a title for the linked post, if there's any interest. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 13:50, 1 September 2018 (UTC)
: Worth mentioning that {{God|Djonni}} later added the ability to include post <var>title</var>s as well, for even nicer citation formatting. See the second example in the table above. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 23:04, 14 November 2018 (UTC)
== Main Page styling tweaks ==
I just tweaked a bunch of style/layout code on the [[Main Page]], all minor changes individually but they add up to a perceptible difference, hopefully for the better. In case anyone notices there have been changes and is curious what they were, details of the changes made:
* Styling of section boxes cleaned up:
** The heading is now "attached" to the border on three sides, and shares its color; hopefully that looks a bit cleaner
** Some boxes had mismatched header/border colors, I've fixed all that up
** The inner spacing/margins was also inconsistent between boxes, now they use identical outer margins and (except for 'Random Image') identical internal padding
* Section colors updated:
** 'Random Image' now matches: purple header/borders, light purple background (the background and borders were light blue, before)
** 'Did You Know?' now has a color scheme of its own, in shades of orange (just because)
** The blues of 'Intro...' are bluer, the greens of 'Featured...' are greener
* The boxes no longer touch each other (it always looked weird with the different border colors)
* '<code>rem</code>' units are used much more extensively (rather than '<code>em</code>' or '<code>px</code>'), which should give more consistent scaling
I should really make a "Godwiki Announcements" template/page for this stuff, instead of stuffing it on the Talk page. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 00:51, 8 September 2018 (UTC)
== Deprecation of [[Template:Pet]] ==
Following [[Talk:Boss-monsters#Boss "Class" vs. "Level"|some discussion]], we've decided to retire the {{tl|Pet}} template, and instead use {{tl|Monster}} for '''all''' Monster articles (including Boss-Monsters and Pets), so that improvements will be shared among the various types automatically.
I've placed the following notice at the top of the {{tl|Pet}} documentation:
{{Sign| width=100| title = This Template Is Deprecated — USE {{tlx|Monster|pet{{=}}yes}} INSTEAD | text = {{tl|Monster}} can now create Pet infoboxes (since all Pets are Monsters), it should be used instead of this template. The syntax is exactly the same, simply add {{para|pet|yes}} to the code. So, for example...<br> '''OLD:''' <code><nowiki>{{Pet|image=example.jpg |description=A beast |levels=12-32 |totem=A Guild}}</nowiki></code><br>'''NEW:''' <code><nowiki>{{Monster|image=example.jpg |description=A beast |pet=yes |levels=12-32 |totem=A Guild}}</nowiki></code><br>See [[Template:Monster]] for full documentation.<br>This change will allow Pet articles to benefit from any improvements made to {{tl|Monster}}. | outerbordercolor = f00 | bordercolor = f00 }}
I'll go through and convert the existing [[:Category:Pets]] articles that use {{tl|Pet}} over to {{tlx|Monster|pet{{=}}yes}} when I can (except for [[Alpha Centaur]] which is already converted), but please use {{tlx|Monster|pet{{=}}yes}} on new Pet articles (or updated ones), and feel free to convert any uses of {{tl|Pet}} that you happen to come across. Thanks! -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 00:52, 18 September 2018 (UTC)
: Oh, and just for the record, {{para|pet}} can actually be set to any common positive-state value, so {{para|pet|y}}, {{para|pet|true}}, {{para|pet|1}}, {{para|pet|on}}, etc. are all just as good. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 00:55, 18 September 2018 (UTC)
<strike> {{m|partlydone}} — I'm now about 2/3 of the way through the Pet articles, [[Special:WhatLinksHere/Template:Pet|15 more to go]].</strike> -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 00:46, 19 September 2018 (UTC)
{{m|done}} — As of now, there are no articles on the wiki containing {{tl|Pet}} transclusions. All Pet articles which feature an infobox are now using {{tlx|Monster|pet{{=}}yes}}. Please stick to that format when updating or adding new Pet articles. {{tl|Pet}} should no longer be used. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 21:00, 20 September 2018 (UTC)
== New, reformatted Omnibus List==
{{m|done}} - The new [[Omnibus List]] design is live.
; Previous update
: See [[Talk:Omnibus List#New, flexible Omnibus List with responsive formatting (large- and small-screen friendly!)|today's announcement at Talk:Omnibus List]] regarding a new version of the Omnibus List that's now in testing. It uses a modernized, responsive (size-adaptive) layout, to better fit screen sizes both large and small.
:'''A testing/demo version of the new Omnibus List can be found at: [[User:FeRDNYC/Sandbox]]'''
:Please leave any/all feedback at [[Talk:Omnibus List]]. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 01:00, 22 October 2018 (UTC)
-- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 13:42, 29 October 2018 (UTC)
== Templates for he-or-she in articles ==
I had a bad idea, which I didn't think through, and took too far. So, here you go: a set of templates to allow The [[Great Random]] to choose the gender of the pronouns in your GodWiki writing!
In brief:
* {{Tlx|He or She}}: You'll get either <code>He</code> or <code>She</code>, chosen at <small>kinda-</small>random.
* {{Tlx|he or she}}: You'll get either <code>he</code> or <code>she</code>, chosen at <small>kinda-</small>random.
If you're with me so far, I'll assume you can extrapolate to understand the following templates too:
* {{Tlx|Him or Her}} and {{Tlx|him or her}}
* {{Tlx|His or Hers}} and {{Tlx|his or hers}}
* {{Tlx|Hero or Heroine}} and {{Tlx|hero or heroine}}
* {{Tlx|Heroes or Heroines}} and {{Tlx|heroes or heroines}}
Every one of these can take the optional parameter {{para|or|<var>anything at all</var>}} (as in, for example, {{Tlx|he or she|or{{=}}1}}). If  {{para|or|<var>anything</var>}} is present, you'll instead get either <code>he or she</code> or <code>she or he</code> instead.
These are safe to use inline with combining forms. As in: <code>Now {{Tl|he or she}}'s the winner!</code> will produce the expected <code>Now he's the winner!</code> or <code>Now she's the winner!</code>.
There's more information (and an important note about an error I can't fix, which could cause you to panic unnecessarily) in the [[Template:He-or-she/Documentation|documentation for <nowiki>{{he or she}}</nowiki>]] (and if you can fix that error, brilliant!).
'''''Great, [[Djonni]], but what's the point?'''''
Rather than every single wiki page using ''he'' (or even ''he or she'') as a default choice, this can allow you to have the choice made for you as to what gender will be used in an article. These templates will ''consistently'' choose the same pronoun for a given page; you can be sure that it will consistently choose the same {{he or she}}, {{him or her}}, {{his or hers}}, {{hero or heroine}}, etc, and won't switch unexpectedly between them. Then, if you copy-paste the same wiki-code into another page (or transclude it), it will be consistent with ''that'' page. Or, if you prefer, just use it to set an article gender once, and follow that gender choice through the rest of the text, whatever you like. It's a 50/50 diceroll for the gender of a page, to use however you want.
'''''If you want more'''''
I'm done with this collection of templates for now (it was a ''much'' larger set that I first expected already), but if people indicate they would like to use templates like this in a more use cases, these further templates could be made pretty easily:
* {{Tlf|God or Goddess}} and corresponding lowercases, plurals, and possessives (a full paradigm of 6 templates altogether)
* The inverted order templates, for when you want to (e.g.) refer to a secondary character, ''he'', that your primary protagonist, ''she'', interacts with. These would be structured as {{Tlf|She or He}}, etc. That set expands out to another 10 templates, plus 6 more for {{Tlf|Goddess or God}}
I'll do the work if there's an indication that anyone likes this idea and would want to use them! :)
'''''Dude, they're ''still'' binary genders.'''''
Yeah, I know. ''All'' of Godville is binary gendered, and it's out-of-scope for me to fix that with a couple of cute little templates. Sorry. If you can propose a ''sensible'' way that I can promote inclusion of non-binary gender anywhere then I'm honestly all ears, I don't have any ideas, good ''or'' bad. But this at least offers something to erode the monotony of male-gendered content on the GodWiki. And hey, since I haven't built the {{Tlf|she or he}} counterpart templates, I guess by default I'm also not promoting heteronormativity, so... Yeah, there's that.
Okay, I'm gonna go do something else now. If you have questions, comments, criticism, or requests, please let me know, here, [[Talk:Djonni|here]], or by direct message on Godville. -- [[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 13:46, 1 November 2018 (UTC)
: I've used the {{Tlx|he or she}} family of templates in today's update to the [[Template:Featured|Featured Article]] on the main page. It should read fairly seamlessly, and give a concrete example of how it might be used. You'll also note that when appearing on the [[Main Page]] and in the original [[Template:Featured]] page the templates render as <code>he</code> in both places. So speaketh the [[Great Random]]!
: If there are any issues with these templates in the Featured Article at all, I encourage you to [https://wiki.godvillegame.com/index.php?title=Template:Featured&action=edit&undoafter=88986&undo=88987 undo the edit] where I put them in, and to [https://wiki.godvillegame.com/index.php?title=Talk:Main_Page&action=edit&section=9 explain the problem] here for us. -- [[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 10:56, 2 November 2018 (UTC)
:: {{m|idea}} It wouldn't be difficult to implement a parameter {{para|daily|<var>anything</var>}} that will switch the gender every day. I kind of like that idea, it's perfect for use cases like the Main Page etc. -- [[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 11:18, 2 November 2018 (UTC)
::: {{m|done}} The existing set of templates now support a parameter, {{para|daily|<var>anything</var>}}, which switches the gender for the text each day. If you want to see it in action, the current (at the time of this note) [[Template:Featured|Featured Article]] snippet on the [[Main Page]] is now using it, and so each day when the cache of the Main Page is refreshed, the text of the Featured Article will change gender. (I am here assuming that the cache is refreshed daily. That may not be the case; a couple of days observation will reveal the real behaviour.)
::: {{m|thankyou}} Also, after some effort by the talented {{god|FeRDNYC}}, the error described in the docs is no longer an issue. I'll update the docs to explain how the template behaves before a new page is saved.
::: Finally, both of these changes make the creation of the inverted template set (<code>{{Tlf|she-or-he}}</code> et cetera) a must. So I'll get to work on that too. (Probably before I update the docs, so I only gotta do that once.) I think I'll make them as essentially wrappers for the current set, though, using a new {{para|reverse|<var>anything</var>}} option, so that improvements are less arduous. (Perhaps I should simply implement a master function (<code>{{Tlf|m-or-f}}</code>?) which takes {{para|male|<var>him</var>}} and {{para|female|<var>her</var>}} text inputs? Then behaviour changes would be completely consistent to the entire set. Hmmm.) -- [[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 13:15, 3 November 2018 (UTC)
:::: {{m|done}} Instead of making an entire set of {{tlf|she or he}}, each of the gender-selection templates now supports the {{para|invert|<var>anything</var>}} parameter to switch the focus of the gender when required to write sensible sentences. More detail and examples are given in the documentation for the {{tl|m-or-f}} template which is now the basis of the whole set (and can be used to construct your own God-or-Goddess or any function you like. More info in the docs.)
:::: Oh, and while writing the docs I realised I'd missed the possessive adjectives, so I've added {{tl|his or her}} and {{tl|His or Her}} to the set. So now, {{he or she|daily=1}} can hold {{his or her|daily=1|invert=1}} hand in the moonlight, and make sense.
:::: I'm going to start subtly including these templates in some key places around the GodWiki, especially for content in highly-visible places like the Main Page. But they're there for everyone's use, so if you want to, enjoy!
:::: Please leave any relevant comments, questions, or requests here. For now, I consider this little template project concluded. :) Cheers -- [[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 17:05, 3 November 2018 (UTC)
{{outdent|:::::}} {{tqi|If you can propose a ''sensible'' way that I can promote inclusion of non-binary gender anywhere then I'm honestly all ears|q=yes}} Personally I've become pretty big on singular "they" (and equivalent forms), for the general case of genderless pronoun usage. And it doesn't even require any templates! 😉
You do have to get used to reading things like, "The hero brushed themself off and continued on their way," which parses pretty weird at first. Also, '''holy ''wow''''' do some people get irrationally pissed off at that usage, accusing you of everything from PC capitulation to eroding the fabric of society. But I say screw those people, since they insist on being <nowiki>{{dicks-and-or-vaginas}}</nowiki>. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 13:07, 4 November 2018 (UTC)
: (Note that my example also requires the reader to consider "hero" a genderless noun, which is a topic about which there has been plenty of debate, and strong arguments made on both sides.) -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 13:21, 4 November 2018 (UTC)
:: Oh I absolutely agree on "they", but as you also pointed out, it's not, erm... ''universally'' agreed upon. ;) The genderlessness of "hero" is also interesting, but since all of Godville differentiates between {{heroes or heroines|daily=1}} and {{heroes or heroines|daily=1|invert=1}}, I feel like defaulting to 'hero' in the Goville context is defaulting to male-focussed language.
:: But! If any editor wishes to, ''they'' are welcome to use any language they like when describing or failing to describe the gender of any characters. Of course. :) -- [[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 14:09, 4 November 2018 (UTC)
::: [[Image:cross.png]] "Not that there's anything wrong with that!"
::: [[Image:tick.png]] "No, of course not!" -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 19:57, 5 November 2018 (UTC)
{{outdent|::::}} Whoops! Thanks for fixing that up {{u|WardPhoenix}}, not sure what happened with that heading while I was editing the transclusions. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 03:15, 19 February 2019 (UTC)
== Guild infoboxes now automatically link to guild pages ==
[[User:Djonni|Djonni]] had the excellent idea to have {{tl|Guild}} generate links to guild pages ''automatically'', instead of requiring a {{para|stats}} argument to provide the URL. So, that's now in place, and a lot of Guild articles should contain '''Guild Page:''' links that didn't have them before.
If for some reason you would prefer '''not''' to have that link shown on a guild article, passing a {{para|stats|no}} argument to the {{tl|Guild}} template will disable the automatic link generation.
And if the automatic link is generated ''wrong'' for some reason, {{para|stats|<var>url</var>}} still works to manually supply a URL. (This also means that older guild articles that include a {{para|stats|<var>url</var>}} argument will continue to function same as always. But {{para|stats|<var>url</var>}} is no longer '''necessary''' to have a '''Guild Page:''' link show up.)
For most Guild articles, {{para|stats}} should '''not''' be included in the template arguments anymore. It's easier to just let the template generate the link automatically. (It's up to the editors of existing guild articles, whether you remove {{para|stats}} if it's already set.)
The other link parameter, {{para|forum|<var>url</var>}}, is still required if you want to display a forum link. There's no way the template can automatically determine the correct URL for guild forums. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 12:53, 4 November 2018 (UTC)
== A new link template for Guild pages ==
A new linking template, {{tlx|Guild link}}, has been added to the wiki. Use it to conveniently link to the official Godville page for the named [[Guilds|Guild]].
The same way: {{tlx|God|<var>God name</var>|}} => {{God|<var>God name</var>}}
You can now use: {{tlx|Guild link|<var>Guild name</var>|}} => {{Guild link|<var>Guild name</var>}}
(Hopefully the emoji shield in front of the Guild's name shows up everywhere. If not, in particular if you see an empty rectangle or any sort of question-mark symbol, please reply and let me know — include the details of what browser, device, operating system, etc. you're using.)
For example: {{tlx|Guild link|Bobius|}} => {{Guild link|Bobius}}
There's also a plaintext mode, just add {{para|plain|yes}}. {{tlx|Guild link|Eternal|plain{{=}}yes}} => {{Guild link|Eternal|plain=yes}}.
(That's used in the {{tlx|Guild}} infobox template, to generate the '''Guild Page:''' links.)
Full details, including available parameters and more examples, are in the documentation at {{tlx|Guild link}}. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 15:53, 11 November 2018 (UTC)
== And a new link template for Pantheon positions... ==
... just to complete the set!
{{Tl|Pantheon link}} can now be used to create a nicely formatted (or plain) link to a Pantheon on the Godville game page, and can optionally link directly to a specific position in that pantheon. It is expected to be used primarily on [[:Category:Gods|God]] or [[:Category:Guilds|Guild]] pages, though be aware that if your pantheon position is volatile you may prefer not to link directly to it.
So now, just as {{tlx|God|<var>God name</var>}} => {{God|<var>God name</var>}}<br />
and {{tlx|Guild link|<var>Guild name</var>}} => {{Guild link|<var>Guild name</var>}},
now {{tlx|Pantheon link|<var>pantheon</var>}} => {{Pantheon link|pantheon}}
And, more usefully, to link to a specific pantheon position:<br />
{{tlx|Pantheon link|<var>pantheon</var>|15}} => {{Pantheon link|pantheon|15}}.
As with the shield in {{Tl|Guild link}}, hopefully the trophy emoji appears correctly on any device. Should it not, reply here and let us know, with what browser, device, operating system, etc. you're using.
Some quick examples:
:{{Tlx|Pantheon link|taming|237}} => {{Pantheon link|taming|237}}
:{{Tlx|Pantheon link|savings|20|text{{=}}short}} => {{Pantheon link|savings|20|text=short}}
:{{Tlx|Pantheon link|wood|1102|plain{{=}}yes}} => {{Pantheon link|wood|1102|plain=yes}}
:{{Tlx|Pantheon link|storytelling|51|text{{=}}none|plain{{=}}yes}} => {{Pantheon link|storytelling|51|text=none|plain=yes}}
:<code><nowiki>[[Pantheon of Gratitude]]: '''</nowiki>{{tlp|Pantheon link|gratitude|123|text{{=}}none|plain{{=}}yes}}<nowiki>'''</nowiki></code> => [[Pantheon of Gratitude]]: '''{{Pantheon link|gratitude|123|text=none|plain=yes}}'''
More details and examples are in the documentation at the {{tl|Pantheon link}} page. Take a quick look there to see how to use it with any pantheon you'd like (though it best suits pantheons where your position is quite stable, as it can't update itself magically with your current position). If you have any questions not covered in the documentation, please feel free to ask, either here or on [[Template talk:Pantheon link]]. -- [[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 13:16, 13 November 2018 (UTC)
== Decorations were hung on the artifacts with care ==
'''''Note:''' this template has since been renamed more generally as {{tlx|Decorate item}}''
Inspired by the [[Halloween 2018]] article's extensive use of example pumpkin-decorated artifact names, and by the fact that just ''writing'' e.g. "🎃[[golden pumpkin]]🎃" doesn't quite look right (the pumpkins are too close to the text), I've created a new set of templates specifically to produce these "decorated" strings, but with nicer formatting and line-wrapping protection.
The general-purpose template is {{tlx|decorate artifact}}, but more convenient wrappers have been created for known Godville decorations:
* {{tlx|pumpkins}}: for decorating Halloween artifacts, e.g.
:: {{tlx|pumpkins|<nowiki>[[golden pumpkin]]</nowiki>|}} → {{pumpkins|[[golden pumpkin]]}}
* {{tlx|party}}: for decorating celebration-related artifacts (like the anniversary specials), e.g.
:: {{tlx|party|<nowiki>[[3000-days gold coin]]</nowiki>|}} → {{party|[[3000-days gold coin]]}}
Templates for additional standard decorations will be added as they appear, or [[Template talk:Decorate artifact|upon request]]. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 15:39, 7 November 2018 (UTC)
:* {{tlx|turkey}} was aded for Thanksgiving, and produces the first one-sided decoration:
::: {{tlx|turkey|<nowiki>[[roasted turkey]]</nowiki>}} → {{turkey|[[roasted turkey]]}} -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 04:13, 4 December 2018 (UTC)
== Default picture and auto-templating for Artifact and Monster infoboxes ==
Just like {{tlx|Equipment}} since its inception, {{tlx|Artifact}} and {{tlx|Monster}} now have default "generic" images that they will use whenever an image is not supplied via {{para|image|<var>filename</var>}}. They will also (again just like {{tlx|Equipment}}) auto-template those articles as {{tlx|Picture}}-needed, adding them to the [[:Category:Pictures needed|Pictures needed]] hidden category.
To avoid double-templating, I removed the manual {{tlx|Picture}} templating from any {{tlx|Artifact}}-using articles which already had it. (There were only two, [[Orange bag]] and [[Heart warmer]].)
I tried to also get all of the {{tlx|Monster}} articles which contained manual {{tlx|Picture}} templates. There were far more of those, and I can't promise I didn't miss any. If you see any articles with '''two''' "Pictures needed" hatnotes (that's a message box at the top of the page), please edit the article source to remove the "{{tlx|Picture}}" template, as the infobox is now automatically supplying it. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 02:45, 23 November 2018 (UTC)
== A humble proposal ==
This proposal and discussion has been archived to [[Talk:JanuWiki 2019/Archive]].
== Navbar line on navboxes ==
Now that we have a {{tlx|Navbar}} template (which I imported for use with the new {{tlx|Infobox}} code, though that isn't ready yet), we can have our Navbox templates show links to make them easier to modify. I've installed a Navbar on just {{tlx|Navboxauras}} for now, as an experiment. It's the three letters (for View • Talk • Edit) in the upper left corner that let you access the navbox template more easily:
Navbars on ''infoboxes'' tend to have fallen out of favor on MediaWiki sites (and I may still end up disabling them on our new infoboxes, before they're released), because they lead to people who want to update infobox data trying to edit the template ''code'', when they '''should''' be editing the template ''transclusion'' in the article they're reading.
But with Navboxes, there's nothing to edit in the article, and you ''do'' need to edit the template code to modify them. So, it's a little different. There is still the danger, though, that the links will lead to inexperienced people messing up the Navbox templates more frequently. So I guess that's one reason for experimenting on just one template, first, to see if {{tlx|Navboxauras}} becomes the target of increased problem editing.
Let me know if anyone has any thoughts or objections. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 05:25, 25 November 2018 (UTC)
:How about we have a version for Infoboxes that simply omits the 'edit' option? I think there's definitely merit in a clear link directly to the documentation and talk pages for an infobox. -- [[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 16:16, 25 November 2018 (UTC)
:: Hmm, that's definitely an option technically, so yeah that could be one way to go. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 05:27, 26 November 2018 (UTC)
== <strike>Preview</strike> Rollout of new Infoboxes ==
For a while now, I've been working on adapting the master {{tlx|Infobox}} code from the English Wikipedia for use here at the GodWiki, with the aim being to reimplement our Infoboxes. Using {{tlx|Infobox}} as the base template gives us access to more advanced features and formatting, and gives the infoboxes a more modern and cohesive look.
For this first round I'm focusing only on the three main infoboxes — certainly {{tlx|Town}} would also be updated, and most likely {{tlx|Guild}}, the user infoboxes, etc. as well, but that would all come later.
There's some initial discussion between [[User:Djonni|Djonni]] and myself at [[Talk:Djonni#Preview Release!]] for anyone interested, but the real point is that I feel like the effort has progressed far enough to seek commentary and input from a wider audience.
Anyone interested is welcome to take a look at [[User:FeRDNYC/Sandbox]], which contains a series of Artifact, Equipment, and Monster articles showcasing different possible forms of the new infobox templates for those articles. Where there are differences between them, or different versions of the same thing, it means that I'm trying out different possible formattings. As it says in the intro to that page, any and all input is welcome and encouraged — there's a link to the associated Talk page if anyone has any thoughts, positive or negative, on any or all of the infoboxes shown there.
'''Most''' helpful to me, at this stage, would be firm preferences of the form, "I like (this formatting) much better than (that formatting), you should definitely go with the first one." But, as I said, ''any'' input is welcome. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 03:50, 29 November 2018 (UTC)
: {{m|started}}
: The new {{tlx|Town}} is now live. I spot-checked a bunch of articles and saw no obvious problems, but if you '''do''', please feel free to use the "T" link in the bottom-right corner of the infobox to access [[Template talk:Town]]. You can report problems or anything else there.
: If all goes well, I'll hopefully take at least {{tlx|Artifact}} and {{tlx|Equipment}} live later today, with {{tlx|Monster}} to follow shortly after. Thanks especially to {{god|Djonni}} and {{god|SourceRunner}}, who provided invaluable feedback and advice during testing. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 17:59, 16 December 2018 (UTC)
:: {{m|doing}}
:: {{tlx|Artifact}} and {{tlx|Equipment}} are also now updated. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 02:43, 17 December 2018 (UTC)
::: {{m|done}}
::: With the deployment of {{tlx|Monster}}, the four main article infoboxes are now updated and live. Please use the 'T' link at the bottom of any of them, to report problems on the associated Talk page. Other wiki infoboxes (guild/user-related) will be updated time permitting. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]])
:::: The new infoboxes look SO GOOD in the wild! You put a ''lot'' of work and thought into them and it really shows. Thank you '''''so''''' much for your effort on these.
:::: Amazing what a nice fresh coat of paint will do around the place! -- [[User:Djonni|Djonni]] ([[User talk:Djonni|talk]]) 06:26, 19 December 2018 (UTC)
== Sign template updates requiring page edits ==
{{Sign|title=This template needs to be fixed|text=These fixes will require the editing of Guild articles by a non-Guild-member (specifically, me — [[User:FeRDNYC|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 {{tlx|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 [[Template talk:Sign|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 {{tlx|Sign}} in Godwiki articles.
===What this means for you (the editor of an article containing {{tlx|Sign}})===
# If your article contains a sign transclusion with parameters like {{tlx|Sign|bordercolor{{=}}red}} or {{tlx|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 {{para|bgcolor}}, {{para|bordercolor}}, or {{para|outerbordercolor}} arguments so that the sign will use the default values, like it was previously.
# If your article contains a transclusion with parameters like {{para|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. {{para|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 {{tlx|Sign}} parameters '''''only'''''.
If there are any affected {{tlx|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... -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 21:56, 18 November 2018 (UTC)
: <strike>{{m|partlydone}}</strike>
: The color-parameter changes are complete. {{tlx|Sign|bgcolor{{=}}|bordercolor{{=}}|outerbordercolor{{=}}}} now accepts '''any''' valid CSS color string, e.g. {{para|bgcolor|red}} or {{para|bordercolor|rgb(100,150,0)}}. If specifying color by hex color value (i.e. <code>#RGB</code> or <code>#RRGGBB</code>), you ''must'' include  the leading <code>#</code> sign.
:; Guild pages edited
:* [[The Ancestry Knight]]
:* [[Lucky God Casino]] (three places)
:* [[I AM]] (two places)
:* [[Open Bar]]
:* [[404]]
: The only change that remains to be done is the fix to {{para|imgwidth}}, and the only page that will be affected ''there'' is [[Open Bar]] (again). I'll get to that another time. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 00:24, 23 November 2018 (UTC)
:: {{m|done}}
:: Completely done, {{para|imgwidth}} syntax is updated in {{tlx|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. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk: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:
* The second, fourth, and sixth images in [https://imgur.com/a/bWh75T4 this set of screenshots] from {{god|S624}}
* [https://imgur.com/a/zDv7djX These screenshots] also from {{god|S624}}
* [https://imgur.com/a/8dTiBXT This screenshot] or [https://imgur.com/a/6JNnEBS this screenshot] from {{god|Terezka}}
I've also written up [[User:FeRDNYC/Administrative requests#Content obscured by infoboxes on mobile|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 ({{tlx|Monster}}, {{tlx|Equipment}}, {{tlx|Artifact}}, {{tlx|Town}}, {{tlx|Guild}}, {{tlx|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 '''[https://imgur.com/a/A47nhQg 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 "<code>div</code>" 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? -- [[User:FeRDNYC|FeRDNYC]] ([[User talk: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! [[User:WardPhoenix|WardPhoenix]] ([[User talk: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. -- [[User:SourceRunner|SourceRunner]] ([[User talk: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 {{tlx|Infobox}} itself — rather than the derived templates like {{tlx|Monster}} and {{tlx|Town}} etc. — then that covers 95% of the problem instances in one shot.)
:::: @SourceRunner: The width is specified as <code>15em</code>, 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 [https://i.imgur.com/NIdHi8t.png this] or [https://i.imgur.com/7g9Alrb.png 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:
<div style="border:1px solid gray;padding:0.2em;width:20em;float:left;margin-right:1em;margin-left:8em;">
<div style="float:right;background-color:#88f;width:15em;height:8em;"> </div>
<div style="display:inline-block;min-width:4em;height:1px;"> </div>
<div style="font-size: 1.5em; font-family: Georgia,Times,serif; margin-top: 1em; margin-bottom: 0.25em; line-height: 1.3; padding: 0; border-bottom: 1px solid #AAAAAA; overflow: hidden;">Too narrow, heading truncated</div>
<div style="border:1px solid gray;padding:0.2em;width:20em;float:left;margin-right:1em;">
<div style="float:right;background-color:#88f;width:5em;height:8em;"> </div>
<div style="display:inline-block;min-width:16em;height:1px;"> </div>
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 <code>min-width</code> value to achieve the proper balance is completely a matter of intuition / trial-and-error. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 19:04, 17 January 2019 (UTC)
::::: (By using a width in <code>em</code> 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: <span style="white-space:no-wrap;background-color:black;color:#3f3;">mmmmmmmmmmmmmmm</span>.) -- [[User:FeRDNYC|FeRDNYC]] ([[User talk: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 : https://imgur.com/a/2TTpUYv —[[User:Holy Spirit of Hell|Holy Spirit of Hell]] ([[User talk:Holy 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. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk: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 <span style="font-family:monospace; font-weight:bold;">¯\_(ツ)_/¯</span>. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk: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. —[[User:Holy Spirit of Hell|Holy Spirit of Hell]] ([[User talk: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 [[User:Holy Spirit of Hell|Holy Spirit of Hell]] ([[User talk: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. --[[User:Terezka|Terezka]] ([[User talk:Terezka|talk]]) 20:23, 18 January 2019 (UTC)
::::: Agreed on good workaround. Congrats [[User:FeRDNYC|FeRDNYC]]. -- [[User:S624|S624]] ([[User talk:S624|talk]]) 20:27, 18 January 2019 (UTC)
{{outdent|:::::}} Thanks, all. This fix is now in place for {{tlx|Archives}} and all templates based on {{tlx|Infobox}}: {{tlx|Monster}}, {{tlx|Equipment}}, {{tlx|Artifact}}, {{tlx|Town}}. (That list will expand to include {{tlx|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 {{tlx|Usergod}}/{{tlx|Usergoddess}} or {{tlx|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 {{tlx|spacer}} addition can be disabled on any page where it's causing a problem by adding {{para|spacer|no}} to the template arguments, and it can be disabled globally by undoing the appropriate edit at [[Template:Archives]] and/or [[Template:Infobox]]. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 15:38, 19 January 2019 (UTC)
: Re: {{god|Holy Spirit of Hell}}'s comments, above, which use the [[Beerburglar]] page as an example (but are '''not''' limited to that page, I understand)...
: {{tqb|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 [https://wiki.godvillegame.com/index.php?title=Template:Infobox&action=history Template:Infobox] and [https://wiki.godvillegame.com/index.php?title=Template:Monster&action=history 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.
: {{tqb|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 [https://www.howtogeek.com/184283/why-third-party-browsers-will-always-be-inferior-to-safari-on-iphone-and-ipad/ 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 ([https://imgur.com/a/prOgKo2 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''' [https://wiki.godvillegame.com/index.php?title=Template:Infobox_image&action=history on December 9] so it would be weird if it's only coming up now. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 23:26, 19 January 2019 (UTC)
:: {{god|FeRDNYC}}, 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 —[[User:Holy Spirit of Hell|Holy Spirit of Hell]] ([[User talk: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. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 04:49, 20 January 2019 (UTC)
{{outdent|::::}} Apropos of nothing at all, really, I just captured [http://imgur.com/gallery/eNrHpfQ 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.) -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 23:13, 21 February 2019 (UTC)
== Formatting g.e. dates ==
Inspired by the work {{god|WardPhoenix}} and {{god|SourceRunner}} 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:
# 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.
# That's something that a template can easily take care of.
My initial idea was to just change template {{tlx|ge}} so it would add "<code>&amp;nbsp;g.e.</code>" 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 {{tlx|date ge}} — it works like {{tlx|ge}} in many ways, '''except''' it always appends "<code>&amp;nbsp;g.e.</code>" to its output, and you can use {{tlx|date ge|<var>number</var>}} to format a g.e. date without conversion.
So, to borrow some examples from [[Template:GE/Documentation#Examples of use|the documentation]]:
<div style="margin-left:1.6em;border:1px solid #888;padding:0.2em;">
;<code><nowiki>[[</nowiki>Godville (game)|Godville]] was born on {{tlf|date ge|ge{{=}}0}}!</code> {{nobold|''appears as:''}}
: [[Godville (game)|Godville]] was born on {{date ge|ge=0}}!
;<code>The 5th of August 2013 was {{tlf|date ge|1183}}</code> {{nobold|''appears as:''}}
:The 5th of August 2013 was {{date ge|1183}}
;<code>The 15th of December 2011 was {{tlf|date ge|12|15|2011}}</code> {{nobold|''appears as:''}}
:The 15th of December 2011 was {{date ge|12|52|2011}}
'''TL;DR''': Basically,
# Anywhere you're writing "<code><var>number</var> g.e.</code>", you can instead use {{tlx|date ge|<var>number</var>}} and the date will be formatted properly to protect against line wrapping.
# Anywhere you're writing "<code>{{tlf|ge|<var>mm</var>|<var>dd</var>|<var>yyyy</var>}} g.e.</code>" can become "{{tlx|date ge|<var>mm</var>|<var>dd</var>|<var>yyyy</var>}}" to take advantage of the same protection.
And to illustrate the main reason for this template (besides the fact that typing "<code>&amp;nbsp;g.e.</code>" constantly is a pain), here's the difference vs. just typing "{{tlx|ge|1|26|2019}}<code> g.e.</code>" or "<code><var>number</var> g.e.</code>" with a normal space:
<div style="margin-left:1.6em;border:1px solid #888;padding:0.2em;width:9em;float:left;">
<div style="margin-left:1.6em;border:1px solid #888;padding:0.2em;width:9em;float:left;">
:Written&nbsp;on<br>{{date ge|1|26|2019}}
-- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 21:26, 26 January 2019 (UTC)
== Activation cost in Artifact infobox ==
The {{tlx|Artifact}} template now supports a {{para|cost}} parameter, used to specify the activation cost of [[activatable artifacts]]. Possible values are:
:{{para|cost|0}} – Requires no godpower to activate (can also be: <code>free</code>,<code>none</code>,<code>0%</code>)
:{{para|cost|50}} – Requires 50% of godpower to activate (can also be: <code>50%</code>)
See it in use at [[Subplot thickener]].
-- [[User:FeRDNYC|FeRDNYC]] ([[User talk: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 {{tlx|monster}} template is now upgraded so that it's no longer '''required''' that the sub-type be explicitly activated with {{para|pet|yes}}, {{para|boss|yes}}, or {{para|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
*: {{tlx|monster|pet{{=}}yes|levels{{=}}18-25}} or {{tlx|monster|pet{{=}}yes|feature{{=}}rideable}}
*;Instead write
*: {{tlx|monster|pet-levels{{=}}18-25}} or {{tlx|monster|pet-feature{{=}}rideable}}
*;It's no longer necessary to write: {{tlx|monster|boss{{=}}yes|boss-type{{=}}underground}}
*;Instead write: {{tlx|monster|boss-type{{=}}underground}}
*;It's no longer necessary to write:{{tlx|monster|sea{{=}}yes|names{{=}}1}}
*;Instead write: {{tlx|monster|sea-names{{=}}1}}
But, again, you '''must''' set {{para|boss|yes}} to create a [[boss-monster]] article if you are '''not''' setting a value for {{para|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]]. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 22:22, 16 February 2019 (UTC)
:: Seems to work on the few cases i tried it, shortens the edits a little. Thanks! --[[User:WardPhoenix|WardPhoenix]] ([[User talk: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 [[User talk:WardPhoenix|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! --[[User:WardPhoenix|WardPhoenix]] ([[User talk: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) ? --[[User:WardPhoenix|WardPhoenix]] ([[User talk: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.) -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 16:45, 13 March 2019 (UTC)
:: [[Gaolkeeper]] redirecting to [[Ghoulkeeper]], that one doesn't really make sense to me. {{u|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. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk: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.
--[[User:WardPhoenix|WardPhoenix]] ([[User talk: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 <strike>cheaters</strike> solvers, so to heck with my reluctance. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 07:31, 26 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 {{ordinal|100,000}} edit! -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 07:41, 26 March 2019 (UTC)
== Misnamed monster? ==
Does anyone have any thoughts on my [[Talk:Space_Invader#Wrong_name.3F|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 [[Talk:Space_Invader#Wrong_name.3F|article talk-page post]].) All input welcome. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk: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. --[[User:WardPhoenix|WardPhoenix]] ([[User talk:WardPhoenix|talk]]) 13:45, 22 March 2019 (UTC)
:: Pretty sure that you're right, [[User:FeRDNYC|FeRDNYC]]. I've never seen it as just a space invader. -- [[User:SourceRunner|SourceRunner]] ([[User talk: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. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 06:08, 26 March 2019 (UTC)
:::: Had to happen eh.
{{Diary|text=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. --[[User:WardPhoenix|WardPhoenix]] ([[User talk: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?) -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 09:21, 30 March 2019 (UTC)
::::::: I'd say there is a high probability that both actually exist. --[[User:WardPhoenix|WardPhoenix]] ([[User talk: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. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk: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 {{tlx|Guild}} Infobox!) First up: More enhancements to the {{tlx|Artifact}} template for [[Activatable Artifacts]]!
The {{para|cost}} parameter was introduced a little while ago. Now the template supports a companion {{para|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 [[Template talk:Artifact#Activation cost parameter|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 {{tlx|Monster}}.
'''See it in use at [[Portable Tunnel]]'''.
Complete template documentation at {{tlx|Artifact}}. Report issues on the template's [[Template talk:Artifact|Talk page]], which can be reached using the "'''[[Template talk:Artifact|T]]'''" link at the bottom of the infobox. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk: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. --[[User:WardPhoenix|WardPhoenix]] ([[User talk: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. --[[User:WardPhoenix|WardPhoenix]] ([[User talk:WardPhoenix|talk]]) 09:44, 7 April 2019 (UTC)
== Adjustable-width spacers and the featured article box ==
Since the {{tlx|Featured}} box is now allowed to be narrower when placed alongside the {{tlx|Mainpageintro}} box (to give the longer intro text more space), the default <code>15em</code> width used for {{tlx|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 {{tag|div}}, and {{tlx|spacer|width{{=}}8em}} is now the documented recommendation for formatting articles in [[Template:Featured]]. {{para|width}} can be any supported CSS length value, see documentation at [[Template:Spacer]]. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk: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? --[[User:WardPhoenix|WardPhoenix]] ([[User talk: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. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk: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 [[User:FeRDNYC|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! --[[User:WardPhoenix|WardPhoenix]] ([[User talk: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 [https://css-tricks.com/ 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: https://imgur.com/a/q2B1gD1 — 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. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk: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: https://imgur.com/qG1Z8pY. 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. --[[User:WardPhoenix|WardPhoenix]] ([[User talk: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. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 20:03, 20 April 2019 (UTC)
:::: (For some reason, the Godville devs eliminated the <code>padding-inline-start</code> 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.) -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 20:09, 20 April 2019 (UTC)
{{outdent|:::::}} 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. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk: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. -- [[User:WardPhoenix|WardPhoenix]] ([[User talk: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 {{tag|div|open}} ''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?
<div style="margin-left:3.2em; border: 1px solid #aaa; padding: 0.2em; columns: 2 5em; column-gap: 0.5em; overflow: auto;">
<ul style="margin-top: 0;">
<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>
<li>Item 4</li>
<li>Item 5</li></ul>
:: And how about here?
<div style="margin-left:3.2em; border: 1px solid #aaa; padding: 0.2em;">
<ul style="margin-top: 0; columns: 2 5em; column-gap: 0.5em; overflow: auto; padding-inline-start: 1em;">
<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>
<li>Item 4</li>
<li>Item 5</li></ul>
:: -- [[User:FeRDNYC|FeRDNYC]] ([[User talk: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. --[[User:WardPhoenix|WardPhoenix]] ([[User talk:WardPhoenix|talk]]) 11:51, 22 April 2019 (UTC)
:::: Actually went with the changes, and there was no contestation sooo... xD --[[User:WardPhoenix|WardPhoenix]] ([[User talk:WardPhoenix|talk]]) 14:05, 30 April 2019 (UTC)

Latest revision as of 12:04, 14 April 2021