Template talk:Navbox list

From GodWiki
Jump to: navigation, search

An idea

It occurs to me that there could be an even more streamlined way of creating Navbox lists, when all of the arguments will be wikilinked, by making the actual wikilinking automatic. IOW, something like this:

{{Navbox wikilist|Basement Cat|Cat Herder|Dogmatic Cat|Fat Cat}}

would produce:

Basement Cat Cat Herder Dogmatic Cat Fat Cat

...The only thing I can't quite decide is how it should be implemented. {{Navbox wikilist}}? {{Navbox list|mode=wikilink}}? The second is (arguably) cleaner implementation-wise and avoids having to duplicate the code for things like |bullet=. The first is (again arguably) nicer to the users. -- FeRDNYC (talk) 21:43, 5 January 2019 (UTC)

(I should add, {{Navbox list|mode=}} is "arguably cleaner", but actually it makes the code significantly uglier since there end up having to be a ton of conditionals. With a separate {{Navbox wikilist}} template the code for both actually becomes way simpler.) -- FeRDNYC (talk) 21:48, 5 January 2019 (UTC)
So, I've thought about this quite a bit. Reluctantly, it's obvious to me in retrospect that automatically applying wikilinking to the list contents always should have been the default behaviour. I was mostly allowing for pipe linking which is A) rare in navboxes, only used (IINM) in navboxes for backstage or technical pages, never for user content, where {{Navbox list}} automation is most useful anyway, and B) can be accomodated regardless by simply inserting an escaped pipe: {{Autolinking Navbox list|pipe{{!}}link}}.
I think switching the behaviour to wikilinking by default will need a three-stage approach.
  1. Add a |mode=wikilink/manual which, at first, defaults to manual
  2. Edit each instance of {{Navbox link}} currently in use to work in |mode=wikilink
  3. Then change the default |mode= behaviour to wikilink
That way there won't be a period where all the navboxes are suddenly broken at once, and a scramble to fix them as quickly as possible (particularly with elevated wiki foot traffic, like now). I'll try and fix the automatic wikilinking and non-breaking bullet behaviours together and promptly, so that a leisurely process of updating the navboxes can proceed without too much fuss. -- Djonni (talk) 16:59, 7 January 2019 (UTC)
So the code isn't really that ugly at all. In my first pass making this I made it far too complicated, I think.
{{#if: {{yesno|{{{item-wrap|}}}}}|<span style="white-space: nowrap;">}}{{#ifeq:{{{mode|manual}}}|wikilink|[[}}{{{1|}}}{{#ifeq:{{{mode|manual}}}|wikilink|]]}}{{#ifeq: {{yesno|{{{item-wrap}}}}}|</span>}}<!--

-->{{#if: {{{2|}}}|&nbsp;{{{bullet|{{Navbox list/Bullet}}}}}&#32;{{yesno|{{{item-wrap|}}}}}|<span style="white-space: nowrap;">}}{{#ifeq:{{{mode|manual}}}|wikilink|[[}}{{{2}}}{{#ifeq:{{{mode|manual}}}|wikilink|]]}}}}{{#ifeq: {{yesno|{{{item-wrap}}}}}|</span>}}<!--

-->{{#if: {{{3|}}}|&nbsp;...
This differs from the existing {{Navbox list}} in these ways:
|space= is no more. The template simply places an &nbsp; before every bullet, and a &#32; after. The bullet will always wrap with the preceding word, and never be orphaned.
|bullet-wrap= never made sense, and is gone.
|item-wrap={{yesno}} works as you would intuitively expect (I think? If your intuition differs tell me): yes will mean that a list item's words will break across lines (for long list items like quests); no (the default behaviour) will mean that a list item's words will be kept together on one line (white-space: nowrap).
  • Is |item-wrap= the right nomenclature for this option? Will users for whom terms like "wrapping" or "nowrap" are unfamiliar understand it? For that matter, is it important for users who aren't very technical to understand it?
  • Should nowrap of list items be the default behaviour?
|mode= as discussed above, takes wikilink or manual (technically, wikilink or anything else, but for docs purposes, manual). For now, |mode=manual is the default behaviour. Once existing navboxes using {{Navbox list}} have been converted to |mode=wikilink, the default will be switched.
Have I missed anything? I feel like I'm missing something. -- Djonni (talk) 18:08, 7 January 2019 (UTC)

I think switching the behaviour to wikilinking by default will need a three-stage approach.

  1. Add a |mode=wikilink/manual which, at first, defaults to manual
  2. Edit each instance of {{Navbox link}} currently in use to work in |mode=wikilink
  3. Then change the default |mode= behaviour to wikilink

That way there won't be a period where all the navboxes are suddenly broken at once, and a scramble to fix them as quickly as possible

Honestly, I think you're overcomplicating it doing it that way. There doesn't have to be a scramble to edit content — indeed, content doesn't need to be edited at all —- if you develop the auto-linking template as a new template name. Leave {{Navbox list}} the way it is, create a new {{Navbox items}} (or whatever) that automatically links, and nothing has to be edited at all. New navboxes can be coded with {{Navbox items}}. The old ones continue to work with {{Navbox list}}. As those old Navboxes are modified, their lists can be converted from {{Navbox list}} to {{Navbox items}} at editors' leisure, whenever they feel it's appropriate. Eventually, when there are no more {{Navbox list}} transclusions anywhere, it can be redirected to {{Navbox items}} as an alternate name.
...That's how I'd do it. -- FeRDNYC (talk) 02:44, 8 January 2019 (UTC)
({{Navbox items}} can still have a |mode=nolink, BTW, to still support lists where not everything is a wikilink. That'd also help with the post-development conversion away from {{Navbox list}}, since those old transclusions can always just be edited to {{Navbox items|mode=nolink}}.) -- FeRDNYC (talk) 03:08, 8 January 2019 (UTC)
This is especially applicable, BTW, if you're planning to radically change the rest of the template's parameter semantics. Things like |bullet-wrap= are in use now, so the easiest way to deprecate them is to leave the parameter(s) in {{Navbox list}} (even if they don't all work exactly the way they're expected to), and just implement the new replacement template with different parameters. -- FeRDNYC (talk) 03:13, 8 January 2019 (UTC)
  • Is |item-wrap= the right nomenclature for this option? Will users for whom terms like "wrapping" or "nowrap" are unfamiliar understand it? For that matter, is it important for users who aren't very technical to understand it?
  • Should nowrap of list items be the default behaviour?
Rather than |item-wrap= I'd probably go with either |wrap-items= or simply |wrap=, where "no" would turn on nowrap for individual items. The name's still not perfect, but it's not an easy feature to name perfectly because there are a lot of negatives involved.
I would make "yes" the default, because you don't expect article titles to be protected from wrapping unless you explicitly protect them. It's weird if the default in navboxes is different from everywhere else in the wiki, where article titles are allowed to wrap freely.
Users for whom terms like "wrapping" are unfamiliar probably shouldn't be writing navbox code (they can edit it, but they'll be following the existing template), and anyway they can read the template docs. I'm really not worried about trying to make templates completely self-explanatory. -- FeRDNYC (talk) 03:04, 8 January 2019 (UTC)
You're right, of course. I was reluctant to create a second, so similarly named template ({{Navbox list}} and {{Navbox items}}) with different semantics, but turning the old into a redirect to the new once it's no longer in use with its current behaviour is perfectly reasonable and a good solution. That's exactly what I'll do.
The name's still not perfect, but it's not an easy feature to name perfectly because there are a lot of negatives involved. and Users for whom terms like "wrapping" are unfamiliar probably shouldn't be writing navbox code. Agreed (enough) on both, and so the question is begged, why try to finegle the double-negatives at all? I could just make it |white-space=free text, defaulting to normal. If some loose cannon really wants |white-space=pre-wrap, well then, I'll not stand in their way! (I mean, standing in front of a cannon of any sort seems self-evidently unwise, metaphorical or otherwise. Huh... I just remembered that I got hit by a cannonball, once. True story. Sounds much more dramatic than it really was, of course, but gosh doesn't it sound dramatic?)
I'll sort out {{Navbox items}} now, and pending testing and consensus on |white-space=, we can put it in place on {{Navbox JanuWiki 2019}} and solve the quest wrapping issues proper-like. -- Djonni (talk) 17:44, 8 January 2019 (UTC)
Weeeeeelllll... I kind of feel like there's a balance to be struck between non-techincal and overly technical, and |white-space=pre-nowrap may come down on the overly-technical side of that line. Heck, if you're going to do that, better to implement a generic |item-style= param that takes any CSS, and stick it at the end of the <span style="$YOURSTYLES {{{item-style|}}}"> — that's even more flexible.
But, even having provided that, I think there's room for an on/off/yes/no/true/false/etc. parameter that makes it relatively simple for non-CSS-savvy editors to simply control the wrapping of items, by causing $YOURSTYLES to contain either white-space:nowrap; or white-space:normal;. (Which the savvy ones can still override with |item-style=white-space:pre-nowrap; since it'll be placed after.) And while "wrap[ping]" may not be familiar to everyone, "white-space" is about as unintuitive a name for the wrapping control as you can possibly get. -- FeRDNYC (talk) 04:47, 9 January 2019 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────I've got a working draft at {{Navbox items}} supporting 20 parameters with brief {{doc|content=}} of the parameters. Took me a while to find {{!(}}, heh. I've got real-world work to catch up on sadly, so will come back to it for testing. (Feel free to tinker if you spot an issue, of course.) -- Djonni (talk) 10:12, 9 January 2019 (UTC)

Meanwhile I was adding some streamlining suggestions at Template talk:Navbox items, so I guess we crossed streams on that one. They're kind of extensive (and untested, since I was writing on-the-fly), so I'll leave well enough alone until you have a chance to check them out. Overall looks good, and Special:ExpandTemplates seems to indicate that it Does exactly what it says on the tin. 👍 -- FeRDNYC (talk) 10:36, 9 January 2019 (UTC)