Template talk:Segment

Category Handling
I don't personally agree with how the category handling is done here (automatically adding the category if it doesn't fall into a given list of exceptions). I think it would be better to either use an explicit field to add the category or maybe only include the category if a page exists for the title field. It's the same issue as that Yahoo Submitter name replacement logic, but I'd expect the category logic here to pop up more frequently than the name thing. Was editing Episode 282: Candlenights 2015 when this came up, since "Audience Question" and "Outro" weren't part of the listed exceptions. "Formspring" and "Twitter" are also notably absent from the exception list, but there's an argument to be made there in favor of having a category for episodes that sourced questions from those places.

- Stuffinmud (talk) 23:31, 30 December 2020 (UTC)


 * Let's talk then. What are the problems with automatically handling the category? I think there's value in being able to easily see which episodes have have an uncommon segment type (like a Sad Libs, or seeing which episodes actually have a Formspring or Twitter question). While those can be handled with explicit categories, those are hard to maintain, and aren't always consistent. The #ifexists magic word is supposed to be a little on the resource-intensive side, so not an ideal solution for a template that gets used multiple times in a page. An explicit category field seems like it would just lead to having the same data for multiple parameter fields (e.g. ) - it seems a little unnecessary.


 * Good catch with the Audience Question, but since Outro's are an uncommon segment (and not necessarily specific to live shows, like Audience Questions are), I would think they should be categorized too. I'm open to being convinced otherwise, though. -- BoxDroppingManApe (talk) 05:35, 31 December 2020 (UTC)


 * My issue with categories is that it feels like they tend to get bloated really easily, and I think the problem scales non-linearly (going from 1 category to 2 adds very little noise, but 13 categories feels way worse than 12 to me). If an episode has categories Episode + Face 2 Face + Munch Squad + Guestspert + some number of topics like Pokemon/Video Games/etc, having another category like "Outro" might cross the threshold of adding less signal than noise. That's just my opinion though. I think I just have some very particular ideals that might not be realistic in practice.
 * Additionally, the list of exceptions in the template source code is just ugly, but again, maybe that's not a realistic standard. The wiki tools are what they are.
 * My thinking for adding an explicit field would be a boolean value, in which case it wouldn't really be duplicated entry.
 * I think one of the biggest advantages of having the category being handled automatically is that it's one less thing for a new person to learn if/when someone else takes over more of the load in editing this wiki, but someone who's doing that would probably pick it up pretty quickly anyway.
 * Overall, I don't feel so strongly about it that I'd try to insist on making a change, but those are some of my thoughts.
 * Check out the change I just made. I flipped the #pos statement so that it's checking for inside the comma-separated string. This is easier to read, but the behavior isn't exactly 1:1. For instance, the original  would not create a category for "Intro Music", but the new logic will create the category. -- Stuffinmud (talk) 09:30, 31 December 2020 (UTC)


 * Good point on the category bloat. I don't really know what the "typical" user experience looks like with regard to categories, and I'm not seeing a lot of guidelines for it on Fandom or Wikipedia, so it's hard for me to say how many is too many. Since categories are a bit more reliable than the existing search tool, I tend to err on the side of having too many, but that's not going to be too helpful if users can't find the category in a mess of other categories.


 * The exception code (pre-edit) is definitely ugly. I'm having to bend over backwards to make some of this code work with the built-in parser functions, especially since I don't have the loops and variable extensions enabled. That's another thing I should probably ultimately move to a lua module (though keep the template as a middle-man so as to not break anything).


 * Clever change to the exceptions, I like it.


 * A boolean approach is good. I have vague concerns about its maintainability (e.g. someone deletes a question, forgets to flip a boolean, or whatnot) but no strong objection to it. I might do that, but have it be an optional field with the default be true (or 'yes'? Not 100% sure how/if booleans work with template data) so experienced users can disable that behavior if desired. That might also be ideal for some of the other heavily automated templates (like PodcastInfobox and Yahoo).


 * I'm also wondering if it's a good idea to make many of those segment categories (and other categories) into hidden categories, which will get displayed on a dedicated stub page with the #categorytree magic word (or #dpl, which I'm hoping to get enabled). It's hard for me to say which categories should be made hidden though - the analytics give me very limited info on which categories get browsed. I can see that most category traffic goes to various Yahoo Warriors, so those should stay visible. I'm also seeing a chunk of traffic for a couple topics (Bees, for the last month, weirdly) and a couple segments (mainly Munch Squad right now, though Haunted Doll Watch and Sad Libs also show up from time to time). -- BoxDroppingManApe (talk) 19:16, 1 January 2021 (UTC)