HRWiki:Projects/Nav Template Automation

From Homestar Runner Wiki

HRWiki:Projects (Talk) (v)
Unfinished and Ongoing
DVD commentary transcripts Image summary cleanup Toon Descriptions Possible Page Disambiguations Inside Jokes vs Running Gags Yello Dello/KOT Conventions Main page redesign @StrongBadActual Bot Interwiki-style updates Edit link issue Podstar Runner pages SBEmail Infoboxes
Completed or overruled
Navigation templates Introducing a new Interwiki link Underscores Nav Template Automation HRWiki:The Stick (Talk) HRWiki:Da Basement (Talk)

See HRWiki:Projects/Navigation templates for background

As some of you may have noticed, I've created a new category that contains a few templates aimed at automating the generation of the previous/next links in navigation templates (and other things). The reason I started this project was that given all the shuffling around caused by the post-Flash site update many links and other things have to be updated and one of them are navigation templates.

This process is prone to errors and issues (as I myself discovered to have caused) because anywhere from 3-5 pages have to be updated when moving a single page around (the page itself + prev*2 + next*2). The templates created make this easier by providing a single location where the nav ordering can be set! To my surprise I had forgotten that Strong Bad Emails already had such a system! Because emails have a numerical order, they're somewhat easy to code, but even Character pages can have a sort as shown in {{charnav-lookup}}.

Finally, since most pages still use the original templates, i created new templates that use the original templates. Eventually we can fold the code of each template into a single template but we should keep the old templates so that we don't break how page history looks.

Here's an outline of the work needed and completed thus far:

• Completed: {{ahrenav}}, {{amamnav}}
• In Progress: {{acharnav}}
• Pending: Everything else.

Here's a list of steps I've taken to update each nav:

1. Create the lookup template. The standard I've been using for the template name has been {{sourcenav-lookup}}. Please feel free to use {{charnav-lookup}} as the reference template. Please use the Toons page or a relevant template in order to figure out the most appropriate ordering.
2. Update the {{{link}}} parameter in the {{sourcenav}} template so that it handles empty parameters correctly during transclusion. Please use this diff as reference.
3. Create the automation wrapper template. The standard I've been using for the template name has been {{asourcenav}}. This allows gradual updates to the affected articles and for page history rendering to remain unaffected. Please feel free to use {{acharnav}} as the reference template. Also notice how the lookup template can also be used to get the current reference name or identifier.
4. Update each page to use the new template with the new numeric parameter corresponding to its order in the sequence. Here's a recent example.

I think I'm done for the day so please feel free to continue where I left off! Feel free to ask questions here! --Stux 12:31, 24 January 2021 (UTC)

I like this idea, but I do have some questions. Would it be possible to create one singular "lookup" template for all toons? (For Hremails it could be something like {{nav-lookup|hre}}, for Answering Machines {{nav-lookup|mam}}, etc.) Likewise, could the navigation templates be combined as well? That would be a more efficient use of space, using one page instead of multiple, and would cut down on the number of templates required.

Secondly, I notice that the lookup templates are determined by numbers, which makes it easy to add new entries at the end, but what about the middle? Let's pretend the shorts use this automated method, and the total number of shorts is 72. Suddenly, Hremail 7 is added in the middle, at #58, bumping the total up to 73. Would this require editing the pages of shorts 59-73 to reflect their new numbers, or would we only need to update the lookup template? (Does that make any sense?) Gfdgsgxgzgdrc 23:21, 24 January 2021 (UTC)

Regarding the singular template: I had originally thought of than then I decided not too thinking that a single global template would be "too big". This was taking into consideration the size of the SB Emails list and before I learned {{sbemail}} already existed. To be honest I am on the fence about this, slightly leaning towards keeping them separate: having one place for many small lists might be convenient in some ways but it might also be too brittle: a typo might break the nav for all pages invovled, not just the set being worked on. And I've been learning the hard way how easy it is to break something when multiple templates and parser functions are involved. Also, more page caches would be invalidated by the template change. Instead of just pages in the nav being recreated, all toons in the template would be recreated after every edit, adding a bit more strain on the server than necessary. On the other hand, it would make it easier to spin off new nav groups and use generic nav group templates. This may need to be the solution for the different toon categories anyway.

"(Does that make any sense?)" Oh! That makes total sense! I hadn't thought about that! Or I think I forgot. In my original plan I had two templates: the nav-lookup template that returns an item name based on its index, and an index-lookup template that would give you the index based on the page name. I actually wanted a single template with both data points next to each other (easier to update this in a single location) but I couldn't think of a way to solve this. I then thought it would be enough to just have the current nav-lookup setup until you brought this point up! Sequential items such as SBEmails, HRemails (sequential by release date) and MAM don't suffer from this problem, but the other lists would!

So this actually adds a bit of complexity: I think we need the second look up (from name back to index) but instead of two templates that I had originally thought of, we should do everything on one template (better to update everything in a single place). The problem then becomes that a combined nav-lookup template would be kind of tricky: one #switch for the list type, one #switch/if for selecting the lookup type (by name or by index) and then the two lists for each lookup. Maybe something like:

{{#switch:{{{cat}}}
|shorts= ...
|tgs= ...
|pbtc=...
|bigtoons=
{{#if:{{{n|}}}
|{{#switch:{{{1}}}<!-- lookup big toons by name -->
|Toon X=1
|Toon Y=2
}}<!-- end switch {{{1}}} -->
|{{#switch:{{{1}}}<!-- lookup big toons by index -->
|0
|17=Toon Zed
.
.
.
|3=Bubs
|2=Toon X
|1|#default=Toon Y
}}<!-- end switch {{{1}}} -->
}}<!-- end if -->
}}<!-- end switch cat -->

Still not a great solution but at the very least there's only one place to update when adding new toons. I don't know if using #count to dynamically generate IDs would work, not work or if it would just kill the wiki due to performance issues. If the wiki had like SQL querying support, this would be a cinch XD! If we keep separate templates then we'd only need to worry about adding the if and the second switch. In any case, the count version might look something like this:

{{#resetcount:idx}}
{{#if:{{{n|}}}
|{{#switch:{{{1}}}<!-- lookup big toons by name -->
|Toon X={{#count:idx}}
|Toon Y={{#count:idx}}
}}<!-- end switch {{{1}}} -->
|{{#switch:{{{1}}}<!-- lookup big toons by index -->
|{{#count:idx}}|#default=Toon Y
|{{#count:idx}}=Toon X
|{{#count:idx}}=Bubs
.
.
.
|0
|{{#count:idx}}=Toon Zed
}}<!-- end switch {{{1}}} -->
}}<!-- end if -->

Since the if should only select one switch, it *might* be okay to use a single index, but perhaps having two different counters might be better (the counters might execute prior to the switch, or not at all). We'd have to do thorough testing to see if that dynamic method would work. Of course that would mean that if any of the toons are out-of-sync between the name lookup and the idx lookup then very weird things will happen! So perhaps this counter idea should be shelved until we have a more unified system where we can have both |Toon X=1 and |1=Toon X on the same line. I hope my technical explanation made sense and I would appreciate any help you can provide! --Stux 00:28, 25 January 2021 (UTC)

I made a parser function, {{#navlist:}}, to look up page names from a list. All the -lookup templates can be converted to simple bulleted lists. I implemented it on {{charnav-lookup}} and {{acharnav}}. See the help page for instructions and let me know if you have any questions or feature requests. — It's dot com 20:47, 28 January 2021 (UTC)

That's pretty cool! Thank you for providing such an elegant solution :). I don't know anything about the internals of the parser function but one thing I'm wondering if why it doesn't work well when browsing a page's history. However it works fine during show preview and that was my main concern so with this I can continue the work much more quickly :). Thanks again Dot com! --Stux 07:37, 29 January 2021 (UTC)

There was a variable that was being set implicitly that needed to be set explicitly. It's fixed now. — It's dot com 17:21, 29 January 2021 (UTC)

Ah, I see. Good, it works now in the page history too! :) I wonder if that's the same issue or same kind of issue with auto redirect not working in page history? Anyway, in either case, thanks again for making this process 1000x easier! Also, thank you for unleashing The Cheatbot to replace all the regular nav instances with autonav instances! This saves everybody a lot of time! I've created {{apuppetnav}} and will work on the {{gamenav}} replacement soon-ish so if you could direct The Cheatbot to help with those, I'd be much obliged. That should leave us with Shorts, PBTC and any other toon category I can't think of off the top of my head. Again, many, many thanks! --Stux 11:55, 31 January 2021 (UTC)