Talk:Main Page

From GodWiki
Revision as of 02:16, 18 January 2019 by Holy Spirit of Hell (talk | contribs) (New problem)
Jump to: navigation, search

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

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

This page has an /Archive

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

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:

  • {{He-or-She}}: You'll get either He or She, chosen at kinda-random.
  • {{he-or-she}}: You'll get either he or she, chosen at kinda-random.

If you're with me so far, I'll assume you can extrapolate to understand the following templates too:

Every one of these can take the optional parameter |or=anything at all (as in, for example, {{he-or-she|or=1}}). If |or=anything is present, you'll instead get either he or she or she or he instead.

These are safe to use inline with combining forms. As in: Now {{he-or-she}}'s the winner! will produce the expected Now he's the winner! or Now she's the winner!.

There's more information (and an important note about an error I can't fix, which could cause you to panic unnecessarily) in the documentation for {{he-or-she}} (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, him, his, hero, 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:

  • {{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 {{She-or-He}}, etc. That set expands out to another 10 templates, plus 6 more for {{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 {{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, here, or by direct message on Godville. -- Djonni (talk) 13:46, 1 November 2018 (UTC)

I've used the {{he-or-she}} family of templates in today's update to the 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 he 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 undo the edit where I put them in, and to explain the problem here for us. -- Djonni (talk) 10:56, 2 November 2018 (UTC)
Ideaicon.png Idea: It wouldn't be difficult to implement a parameter |daily=anything that will switch the gender every day. I kind of like that idea, it's perfect for use cases like the Main Page etc. -- Djonni (talk) 11:18, 2 November 2018 (UTC)
Tick.png Done The existing set of templates now support a parameter, |daily=anything, 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) 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.)
Smiley.png Thank you Also, after some effort by the talented GodFerdNYC , 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 ({{she-or-he}} 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 |reverse=anything option, so that improvements are less arduous. (Perhaps I should simply implement a master function ({{m-or-f}}?) which takes |male=him and |female=her text inputs? Then behaviour changes would be completely consistent to the entire set. Hmmm.) -- Djonni (talk) 13:15, 3 November 2018 (UTC)
Tick.png Done Instead of making an entire set of {{she-or-he}}, each of the gender-selection templates now supports the |invert=anything 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 {{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 {{his-or-her}} and {{His-or-Her}} to the set. So now, he can hold her 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 -- Djonni (talk) 17:05, 3 November 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── If you can propose a sensible way that I can promote inclusion of non-binary gender anywhere then I'm honestly all ears 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 {{dicks-and-or-vaginas}}. -- 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.) -- 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 and heroines, 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. :) -- Djonni (talk) 14:09, 4 November 2018 (UTC)
Cross.png "Not that there's anything wrong with that!"
Tick.png "No, of course not!" -- FeRDNYC (talk) 19:57, 5 November 2018 (UTC)

Guild infoboxes now automatically link to guild pages

Djonni had the excellent idea to have {{Guild}} generate links to guild pages automatically, instead of requiring a |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 |stats=no argument to the {{Guild}} template will disable the automatic link generation.

And if the automatic link is generated wrong for some reason, |stats=url still works to manually supply a URL. (This also means that older guild articles that include a |stats=url argument will continue to function same as always. But |stats=url is no longer necessary to have a Guild Page: link show up.)

For most Guild articles, |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 |stats= if it's already set.)

The other link parameter, |forum=url, 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. -- FeRDNYC (talk) 12:53, 4 November 2018 (UTC)

Decorations were hung on the artifacts with care

Note: this template has since been renamed more generally as {{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 {{decorate artifact}}, but more convenient wrappers have been created for known Godville decorations:

  • {{pumpkins}}: for decorating Halloween artifacts, e.g.
{{pumpkins|[[golden pumpkin]]}}🎃golden pumpkin🎃
  • {{party}}: for decorating celebration-related artifacts (like the anniversary specials), e.g.
{{party|[[3000-days gold coin]]}}🎉3000-days gold coin🎉

Templates for additional standard decorations will be added as they appear, or upon request. -- FeRDNYC (talk) 15:39, 7 November 2018 (UTC)

  • {{turkey}} was aded for Thanksgiving, and produces the first one-sided decoration:
{{turkey|[[roasted turkey]]}}🦃roasted turkey -- FeRDNYC (talk) 04:13, 4 December 2018 (UTC)

A new link template for Guild pages

A new linking template, {{Guild link}}, has been added to the wiki. Use it to conveniently link to the official Godville page for the named Guild.

The same way: {{God|God name}} => GodGod name

You can now use: {{Guild link|Guild name}} => ⚜️ Guild name

(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: {{Guild link|Bobius}} => ⚜️ Bobius 

There's also a plaintext mode, just add |plain=yes. {{Guild link|Eternal|plain=yes}} => Eternal .

(That's used in the {{Guild}} infobox template, to generate the Guild Page: links.)

Full details, including available parameters and more examples, are in the documentation at {{Guild link}}. -- FeRDNYC (talk) 15:53, 11 November 2018 (UTC)

And a new link template for Pantheon positions...

... just to complete the set!

{{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 God or 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 {{God|God name}} => GodGod name
and {{Guild link|Guild name}} => ⚜️ Guild name,

now {{Pantheon link|pantheon}} => 🏆 Pantheon of Pantheon

And, more usefully, to link to a specific pantheon position:
{{Pantheon link|pantheon|15}} => 🏆 Pantheon of Pantheon: 15th.

As with the shield in {{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:

{{Pantheon link|taming|237}} => 🏆 Pantheon of Taming: 237th
{{Pantheon link|savings|20|text=short}} => 🏆 Savings: 20th
{{Pantheon link|wood|1102|plain=yes}} => Pantheon of Arkeology: 1102nd
{{Pantheon link|storytelling|51|text=none|plain=yes}} => 51st
[[Pantheon of Gratitude]]: '''{{Pantheon link|gratitude|123|text=none|plain=yes}}''' => Pantheon of Gratitude: 123rd

More details and examples are in the documentation at the {{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. -- Djonni (talk) 13:16, 13 November 2018 (UTC)

Sign template updates requiring page edits


This template needs to be fixed

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

The plan

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

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

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

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

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

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

Default picture and auto-templating for Artifact and Monster infoboxes

Just like {{Equipment}} since its inception, {{Artifact}} and {{Monster}} now have default "generic" images that they will use whenever an image is not supplied via |image=filename. They will also (again just like {{Equipment}}) auto-template those articles as {{Picture}}-needed, adding them to the Pictures needed hidden category.

To avoid double-templating, I removed the manual {{Picture}} templating from any {{Artifact}}-using articles which already had it. (There were only two, Orange bag and Heart warmer.)

I tried to also get all of the {{Monster}} articles which contained manual {{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 "{{Picture}}" template, as the infobox is now automatically supplying it. -- FeRDNYC (talk) 02:45, 23 November 2018 (UTC)

Navbar line on navboxes

Now that we have a {{Navbar}} template (which I imported for use with the new {{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 {{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:

Standard Auras Abstinence Audibility Baiting Bliss Concussion Confusion Curiosity Hoarding Huckstering Hunting Immortality Pacifism Rage Reviving Spookiness Totemism Trail
Event Auras Censorship ██████████‎

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 {{Navboxauras}} becomes the target of increased problem editing.

Let me know if anyone has any thoughts or objections. -- 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. -- Djonni (talk) 16:16, 25 November 2018 (UTC)
Hmm, that's definitely an option technically, so yeah that could be one way to go. -- FeRDNYC (talk) 05:27, 26 November 2018 (UTC)

Preview Rollout of new Infoboxes

For a while now, I've been working on adapting the master {{Infobox}} code from the English Wikipedia for use here at the GodWiki, with the aim being to reimplement our Infoboxes. Using {{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 {{Town}} would also be updated, and most likely {{Guild}}, the user infoboxes, etc. as well, but that would all come later.

There's some initial discussion between 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. -- FeRDNYC (talk) 03:50, 29 November 2018 (UTC)

Started.png Started
The new {{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 {{Artifact}} and {{Equipment}} live later today, with {{Monster}} to follow shortly after. Thanks especially to GodDjonni  and GodSourceRunner , who provided invaluable feedback and advice during testing. -- FeRDNYC (talk) 17:59, 16 December 2018 (UTC)
Doing.png Doing...
{{Artifact}} and {{Equipment}} are also now updated. -- FeRDNYC (talk) 02:43, 17 December 2018 (UTC)
Tick.png Done
With the deployment of {{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. -- 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! -- Djonni (talk) 06:26, 19 December 2018 (UTC)

A humble proposal

This proposal and discussion has been archived to Talk:JanuWiki 2019/Archive.

Fixes for mobile content layout

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

For those not familiar with the issue, see:

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

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

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

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

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

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

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

...Keeping in mind that the width of the left-hand space in those boxes will vary by quite a lot, based on factors like screen size, orientation, etc. Choosing the right min-width value to achieve the proper balance is completely a matter of intuition / trial-and-error. -- FeRDNYC (talk) 19:04, 17 January 2019 (UTC)
(By using a width in em units, the size of the spacer is defined based on the font size in use. Specifically, it's the width of 15 letter 'm' characters. So, currently, the minimum available space to render text to the left of floated content would be this large: mmmmmmmmmmmmmmm.) -- FeRDNYC (talk) 19:12, 17 January 2019 (UTC)
This seems to have introduced a new problem, at least on my iPhone 5S using the vector skin. The info box now appears not at the top, but after the first paragraph, so sometime half way down the page, and also, the box is cut off on the right side of the screen. Here’s a screenshot of the problem : (—Holy Spirit of Hell (talk) 02:16, 18 January 2019 (UTC)