This wiki is a XML full dump clone of "Heroes Wiki", the main wiki about the Heroes saga that has been shut down permanently since June 1, 2020. The purpose of this wiki is to keep online an exhaustive and accurate database about the franchise.

User talk:Hardvice/Guest stars

From Heroes Wiki
Jump to navigation Jump to search



If we standardize the image names, find a way to match the cell size, and sort out this duplicate problem, this could totally work. We should be able to use a string function to get the number of characters in a name, and if it's less than X, automatically add nonlinktext.--Hardvice (talk) 00:03, 30 November 2007 (EST)

  • Right, and there's a few sort functions in Winter that we might be able to use. I left a comment on your talk page.--MiamiVolts (talk) 00:09, 30 November 2007 (EST)
    • No need. I just didn't read their documentation very well. Sort is working, duplicates are fixed. All we need are standard image names and to set up the auto nonlinktext.--Hardvice (talk) 01:09, 30 November 2007 (EST)
      • Most of the names are pretty standard. I think you tend to use lowercase and I use uppercase--can that be fixed using ucfirst or any of those other fun tricks? It looks like there's only three so far for this season that would need to be fixed: Héctor Luis Bustamante, Oscar Gutierrez, and Kiko Kiko. But that brings up two other issues: guest stars who don't have real-world portraits, and guest stars for whom articles do not yet exist. -- RyanGibsonStewart (talk) 01:20, 30 November 2007 (EST)
        • Yeah, since it's generating the page, there's no good way to override it. We can add a separate copy of the image for those with no out-of-character images (for example, re-upload Image:Monty Petrelli.jpg as Image:Jackson Wurth.jpg), which would actually make things easier once we get an OOC image. Folks who don't exist yet aren't going to appear in the portals, but they will appear as soon as they're added, which is kind of nice. And on the off chance that we need to override somebody's name, we can read individual variables from templates called by an article, so we could add a "portalname" variable to template:infobox cast and use that to fill text=--Hardvice (talk) 01:30, 30 November 2007 (EST)
          • Couldn't we just add image redirects for those?--MiamiVolts (talk) 01:34, 30 November 2007 (EST)
            • In the case where the name is simply different (i.e. Rey Mysterio.jpg for Oscar Gutierrez), yes. In the case of nocastimage pages, it actually works much better if we upload a second copy because then, when we replace it with an out-of-character image, all pages update automatically.--Hardvice (talk) 01:41, 30 November 2007 (EST)
            • Actually, image redirects redirect the image page, not the image itself.--Hardvice (talk) 01:44, 30 November 2007 (EST)
              • Indeed. Just rediscovered that myself. But, except for nocastimage, the redirect will serve the purpose of not having to have the image in a category twice and re-adding the source information.--MiamiVolts (talk) 01:51, 30 November 2007 (EST)
          • I'm just reading through everything now, so bear with me as I might have multiple posts. On the subject of having an image called "Jackson Wurth.jpg" and an image called "Monty Petrelli.jpg", I think it's a great idea--I thought of that a long time ago to ease the process of updating pages once we get an OOC image, but didn't see it as a huge need, so I dismissed it. Especially now that we're getting actors who are in multiple seasons, it would be even more beneficial. The only thing I would suggest is that we make the "Jackson Wurth.jpg" and "Monty Petrelli.jpg" different images in some way, if possible. Maybe a different scene or a different pose or something. Some people (like Kiko Kiko) wouldn't make this very feasible since she's really only in one scene, but if we can swing varying images, we should. -- RyanGibsonStewart (talk) 06:33, 30 November 2007 (EST)

Cell size, text breaks

  • I copied the images for the two redirects. Not sure if we can fix the cell size or line breaks since that part is autogenerated. Perhaps if the autogenerator called a template, but I'm not sure that would be worth it.--MiamiVolts (talk) 02:07, 30 November 2007 (EST)
    • Cell size can be adjusted (some) by adjusting the number in the expr: on Template:PortalCharacter. Right now it's set to force an extra line if the name is less than 12 characters, which works on my browser, but if some cells are too small on yours, then we can tweak it.--Hardvice (talk) 02:10, 30 November 2007 (EST)
      • Mark Colson is showing up as three lines in my browser (Mark on one line, Colson on the one below it, and an empty line below that). Is that on purpose (it's only 11 characters with the space)? The rest are fine. Not all split the last and first names into seperate lines, but that's okay cause the cell is large enough to fit them on the same line.--MiamiVolts (talk) 02:23, 30 November 2007 (EST)
        • Drat, forgot to count the spaces. Should probably adjust to 11 instead of twelve. Of course, since it's OK on my browser, his name is probably exactly long enough to ruin this trick.--Hardvice (talk) 02:27, 30 November 2007 (EST)
          • Yeah, 11 makes Elya Baskin and co. not have any whitespace. There's another alternative. Hold on.--Hardvice (talk) 02:29, 30 November 2007 (EST)
            • There's option 2. Option 3 is to print the border but force the cell size.--Hardvice (talk) 02:33, 30 November 2007 (EST)


  • It's possible to have the navbar be automatically generated too -- again, with the caveat that it will need to be manually updated when it comes time to add a new page. It might be possible to make the cell sizes match, but I doubt it -- in this case, it's probably easier to just valign top all the cells and remove the border, and let the text run as long as it wants. Getting the letters for the small versions might be tough, but can probably be done with string functions--find the last space in the name (may require Winter to loop for this), take the next letter.--Hardvice (talk) 02:27, 30 November 2007 (EST)
    • I switched them to use table borders instead of no borders at all. I think it looks better that way. Feel free to revert it if you don't.--MiamiVolts (talk) 02:35, 30 November 2007 (EST)
      • Good idea. I switched to cell borders to make them less ... Stalinesque ... but it totally works.--Hardvice (talk) 02:38, 30 November 2007 (EST)
        • Yeah, the thin grey borders look great.--MiamiVolts (talk) 02:39, 30 November 2007 (EST)

Remaining issues

  1. Letters for small version of navbar. If we can print the sortkey and restrict the number of characters, cake.
  2. For characters, we'll need to cat minor, main, recurring, and supporting characters, which we should probably do anyway. We can add logic to the navbar, and have it default to "minor"--that way, we only have to update 20 or so pages for characters who aren't minor.
  3. Standardize any other odd image names
  4. If we want to add characters who aren't written, we can stub 'em, or we can have them magically appear when they are written. I personally prefer the latter--I don't really see the point of redlinks in the portals except to make sure things don't get forgotten or misplaced (and now they can't).
  5. Everybody needs to have sort= in their infobox for the auto navbar to work.--Hardvice (talk) 03:32, 30 November 2007 (EST)

--Hardvice (talk) 02:44, 30 November 2007 (EST) Otherwise, this should be well within our reach.

  • The first looks like the most trouble, as I'm not sure how to print the sortkey. The others seem only to require copying this code into another portal and customizing it for said portal. For the case where there are multiple portal pages for a single category, there should be a redlink that appears in the navbar when a new page is required. Defaulting to "minor" is a good idea. Standardizing the image names is straightforward, and I agree about having the new character pages appear when written. I assume it's possible to remove characters that are labelled with the spoilers category.--MiamiVolts (talk) 03:00, 30 November 2007 (EST)
    • We can actually grab the value of sort= out of the infobox, so #1 shouldn't be too hard. #Sub: (variable) | 0 | 1 ought to do it.--Hardvice (talk) 03:05, 30 November 2007 (EST)
    • OK, works great--so long as all of the pages have sort=.--Hardvice (talk) 03:32, 30 November 2007 (EST)
  • re: minor/supporting/recurring/main categories for characters, I'm assuming we use the most current season's status? How does this effect characters from multiple seasons who have more than one designation? For instance, D.L. was a main character last season, but a minor character this season--should he have two categories? re: allowing characters to appear automatically or forcing them to appear, I agree we should let them appear magically. This does make for a lot of extra images (character and actor portraits) in special:unusedimages, but that doesn't bother me too much. -- RyanGibsonStewart (talk) 06:41, 30 November 2007 (EST)
    • Regarding current vs. past seasons, we could add new categories "season one minor/supporting/recurring/main characters" and "season two minor/supporting/recurring/main characters". That's basically the only way I see to do it if we want it to be automatic. AdminBot might be a little helpful there, but since this is something new stored only by which portal a character currently is in, it might need to be done manually.--MiamiVolts (talk) 14:01, 30 November 2007 (EST)
    • Just like we do with the character navbar: if they're in the latest season, they're categorized for that. D.L. would have the bar for season 2 and be categorized as a season two minor character. He'd still be in the season one main characters portal because we're probably only going to generate minor character portals.--Hardvice (talk) 14:38, 30 November 2007 (EST)


Partly to enable this, and partly because it bugs the hell out of me, I added a lines variable to Template:PortalCharacter that will set the number of lines of linkspace to add to a cell. This way, we don't need to micromanage nonlinktext to get cell sizes to match; you can just assign "lines=3" to each cell on the page, and they'll all match. Also, the boxes will now scale with the text. Lines defaults to 2 and can currently be set for anything from 1-5; we can add more if we need them.--Hardvice (talk) 05:42, 30 November 2007 (EST)

  • I don't see the boxes/borders anymore, did you turn them off?--MiamiVolts (talk) 06:21, 30 November 2007 (EST)
    • They should have normal cell borders now.--Hardvice (talk) 14:35, 30 November 2007 (EST)
      • I'm not seeing normal cell borders. Is it a browser issue? (I thought I saw it earlier this morning on Firefox, but I could be wrong.) For what it's worth, I prefer the cell borders to be visible, if that's at all feasible. -- RyanGibsonStewart (talk) 14:41, 30 November 2007 (EST)
        • They are visible now for me. Check again, Ryan?--MiamiVolts (talk) 14:52, 30 November 2007 (EST)
  • Also, just looking at the Minor characters portal pages, some of the names are missing and we have several redlink pages...--MiamiVolts (talk) 06:28, 30 November 2007 (EST)
    • Everyone needs to have |season=Two on their navabr for this to work.--Hardvice (talk) 14:35, 30 November 2007 (EST)
      • It looks like some of the deceased characters have the name missing, is that a related issue? How will the code know to exclude the Main/Supporting/recurring/etc characters from the Minor portal?--MiamiVolts (talk) 14:52, 30 November 2007 (EST)
        • Because it looks for a match on two categories: minor/guest stars and season.--Hardvice (talk) 14:56, 30 November 2007 (EST)
          • I guess it might help if Category:Season Two Cast actually existed?--MiamiVolts (talk) 15:10, 30 November 2007 (EST)
            • It probably should have a page, but that doesn't affect the inclusion at all.--Hardvice (talk) 16:05, 30 November 2007 (EST)

Guest Stars

The only things left to do before this can be implemented for guest cast are:

  • Make sure everyone who appears in Season Two has |season=Two on the navbar call
  • Make sure everyone has a picture at (TITLE).jpg
    • Should we standardize it as Firstname Lastname.jpg? There are a few I've uploaded in my earlier days that are JPG (capitals), and there are some that you've uploaded that are lowercase. Would #ucfirst: or #lcfirst: work for these? -- RyanGibsonStewart (talk) 16:02, 30 November 2007 (EST)
      • Yeah, they should be (ARTICLE TITLE).jpg, which should be Firstname Lastname.jpg. There's a lot of case insensitivity stuff in the extension, but I'm not sure how well they'll work with links ... what happens if we have both "Kiko Kiko.jpg" and "Kiko kiko.jpg"? Does it try to print both?--Hardvice (talk) 16:08, 30 November 2007 (EST)
  • Make sure everyone has a |sort= in their infobox
  • Add a template for the final row to change the width and render only as many cells as needed
  • Make the navbar an actual template

--Hardvice (talk) 14:56, 30 November 2007 (EST)


If I understand it correctly, we have great control over what is printed. Mark Christopher Lawrence's superlong name is falling out of the portal cell on my browser. If we switch the sort on his actor page to just "Lawrence, Mark", would that work to fix the problem? -- RyanGibsonStewart (talk) 20:22, 30 November 2007 (EST)

  • Indeed it will. It pulls the sort for the text=--Hardvice (talk) 20:42, 30 November 2007 (EST)
  • We can also set |lines=3 in the template and everybody will add an extra line.--Hardvice (talk) 20:50, 30 November 2007 (EST)
    • I think three lines is too much. I'd rather just chop off Mark Christopher Lawrence's middle name than have all that extra space. -- RyanGibsonStewart (talk) 21:58, 30 November 2007 (EST)

portals with less than 15

It's too bad we can't get portal rows with less than 5 images to be centered...but I'll take that minor drawback any day if it means the portal updates itself! -- RyanGibsonStewart (talk) 22:01, 30 November 2007 (EST)

  • We can, actually. I just have to tweak the template a bit.--Hardvice (talk) 22:07, 30 November 2007 (EST)
  • OK, done.--Hardvice (talk) 01:22, 1 December 2007 (EST)
    • That's cool that it even centers. Looks okay to move it now, unless you think we should do all the character portals at once? And unless you plan to make stub pages for the current redlinked articles in the portals...--MiamiVolts (talk) 01:43, 1 December 2007 (EST)
      • The characters are going to be a bit more difficult since they're not yet categorized into main/rec/sup/minor. I don't think we should mess with the season one stuff at all, since it's unlikely to change. I guess I'll go ahead and try moving this into the portals now for guest stars. Incidentally, we are waaaay behind on guest stars articles. The portals we have are almost exactly 50% redlinks.--Hardvice (talk) 01:54, 1 December 2007 (EST)
        • Ok, are we storing what those redlinks were somewhere so we can chew at them later?--MiamiVolts (talk) 02:02, 1 December 2007 (EST)
          • They're all still in Special:Wantedpages because they're linked from the checklists and the images.--Hardvice (talk) 02:05, 1 December 2007 (EST)
            • Right, but the information that they were only Guest stars and not recurring actors is lost. Ah well, I guess it's not too much trouble to dig that up.--MiamiVolts (talk) 02:11, 1 December 2007 (EST)
              • Right -- particularly since all the redlinked guys who are recurring/supporting actors are still in portals.--Hardvice (talk) 02:17, 1 December 2007 (EST)
          • For posterity, here are the season two guest stars that still need articles:

A few improvements

  • You no longer have to specify FIRST and LAST in the navbar cells -- just page #.
  • When adding a new page, you can add all three rows from the start. Blank rows will be suppressed. This means we only have to (manually) edit the portals when we reach a new page, not whenever we add a new row. It's actually possible to add logic to the navbar to make even that unnecessary, and the portal would be truly maintenance-free, but we'd need unlinked portals for blank pages. If people are cool with having a blank portal floating around unlinked, then I'll set the logic up. Otherwise, we just need to add a page and update the navbar every 15 articles.--Hardvice (talk) 01:22, 2 December 2007 (EST)
    • See Portal:Guest Cast 4 for an example of what I'm talking about. It doesn't show up in the portals or in the navbar, but it will automatically once a 45th guest star article is added. If people don't mind having these hanging around unused, I can add the rest, and the portals will be 100% maintenance free (until we go over 7 pages, which is what the navabr is set for right now).--Hardvice (talk) 01:31, 2 December 2007 (EST)
      • Generally, I don't mind having blank portals for this purpose. Also, how does this affect moving those portals to "Portal:Guest Cast 1/Season Two"? (I'm sure it's not hard to figure out, I'm just too lazy to do the work, so I figured I'd ask the expert.) -- RyanGibsonStewart (talk) 01:49, 2 December 2007 (EST)
        • That's easy. Since we archive the navbar template, too, it doesn't even need a season variable--the new season will use a new version of the template, the old version will be archived. The only thing that needs to change are the page links. As for the row/cell templates, they can either be archived, too or we can add |season= logic to them.--Hardvice (talk) 01:56, 2 December 2007 (EST)
        • OK, season variables work. Should be easy enough to archive.--Hardvice (talk) 02:16, 2 December 2007 (EST)
          • Cool, thanks. By the way, let me gush for a minute about how cool this auto-updating is. -- RyanGibsonStewart (talk) 02:30, 2 December 2007 (EST)

Next Question

  • How many and what kind of portals should we implement this for?
    • We can go back and do season one. Probably not worth it -- it would require adding lots of sorts and standardizing lots of image names, and chances are good we won't be adding anyone else to the portals.
      • Agree. Why fix something that's not broken? There are a few changes I plan to make during the break in adding some guest actors to Season One, but it's nothing that can't easily be fixed, and probably not worth the trouble to convert. There's virtually nothing left to update, so why make it auto-update? -- RyanGibsonStewart (talk) 02:38, 2 December 2007 (EST)
    • We can do Principal, Recurring, and Supporting cast. Advantages: portals would automatically match the categories. Disadvantages: would require updates (though not a ton) to images and sort. Would require new templates, but they're virtually identical.
    • We can (and should) do at least Minor Characters. We'll have to categorize characters as Main, Supporting, Recurring, and Minor, but we can make the navbar template do the heavy lifting. We'll require the same update with image names and sort, though most of the characters have sort by now I'd guess.
      • I'm a bit more wary of Minor Characters. It should be done, but updating those image names seems like a beast. Also, page names for characters seem to change very often, so I feel like we'll be deleting and uploading images all the time. If it's unavoidable, so be it--I'm just expressing a concern. -- RyanGibsonStewart (talk) 02:38, 2 December 2007 (EST)
        • Actually (and promise not to hate me), it just occurs to me that we can read the image name from the infobox. That's how we're getting the sort. Whoops.--Hardvice (talk) 03:06, 2 December 2007 (EST)
          • How could I hate you? .... That's great news, I hadn't thought of that. -- RyanGibsonStewart (talk) 03:48, 2 December 2007 (EST)
    • Theoretically, we could eventually make every portal auto-updating. Probably not worth the effort for most.--Hardvice (talk) 02:30, 2 December 2007 (EST)
      • I like what you did with the items. I've noticed that when people add a new article, they generally update the navbar but (understandably) haven't quite gotten the hang of updating the portal yet. Maybe a self-updating portal would be a good idea? I haven't really thought through the advantages and disadvantages of it, though. But I do like the idea of a self-updating navbar. -- RyanGibsonStewart (talk) 02:38, 2 December 2007 (EST)

Minor Characters

  • Almost done. All I have to figure out is how to pull both sortname and image -- I'm not pulling sortname for the rows, because we don't have to (I did it for actors so we could print last name first, but that's not (as) necessary for characters), but I do need to pull it for the navcells to get the letters. Lots of the minor characters (probably most) don't have a sortname, but those that don't don't need one -- so we can probably have the bot set sortname=TITLE just so we can pull it. Other than that, we're good to go.--Hardvice (talk) 03:44, 2 December 2007 (EST)
    • For what it's worth, afaik every character who needs a sortname has one...and many who don't also have one. -- RyanGibsonStewart (talk) 03:48, 2 December 2007 (EST)
      • Yeah. But for the letters on the navbar to work, they all need one, even if it's the same as the pagename.--Hardvice (talk) 03:53, 2 December 2007 (EST)
      • In other words, we should be able to have the bot set sortname= to PAGENAME for everyone who doesn't already have sort= and be done.--Hardvice (talk) 03:54, 2 December 2007 (EST)
        • I'm new to how the bot works. Can it search for anybody who doesn't have the variable at all, or does it only search for people with the variable that's on the page but left blank. In other words, Chandra's super doesn't have the variable on his page at all, but Garcia does (it's just left blank). Will the bot be able to get both of them? -- RyanGibsonStewart (talk) 04:04, 2 December 2007 (EST)
          • Worst case scenario, I can use dpl to add a category to everybody without a sortname, and we can run the bot on that category.--Hardvice (talk) 04:10, 2 December 2007 (EST)
          • Incidentally, I am able to pull both image and sort. Would it be worth setting up the actors to do that, or should we stick with a naming standard?--Hardvice (talk) 04:13, 2 December 2007 (EST)
            • That's up to you. Would it be okay to leave it alone for Season One since we've really only got a handful of actors who are going to be added? We could pull both image and sort for Season Three. Otherwise, I like having a naming standard for images, especially when I'm doing a search for an actor, I like that the portrait is returned. -- RyanGibsonStewart (talk) 04:16, 2 December 2007 (EST)
              • Yeah, I totally agree it's not worth messing with season one. I'll make the changes for actors, though, in anticipation of season three. We can stick to a naming standard, but if one doesn't fit, it will still work.--Hardvice (talk) 04:18, 2 December 2007 (EST)
  • I'm assuming that if the character is dead, you can make their picture transparent, correct? -- RyanGibsonStewart (talk) 21:10, 2 December 2007 (EST)
    • Yeah, we can pull the "Date of death" field from the character box and use that to add "deceased=true". The only last potential problem with automating the character templates (as opposed to the actor templates) for season 3 is that we should probably add a field to the infobox for "display name" so we can manually shorten character names in the portals (c.f. "Women's correctional facility guard"). After that, we can automate characters as easily as actors.--Hardvice (talk) 20:35, 3 January 2008 (EST)
    • OK, I got deceased working (everyone dead needs a date of death, even if it's just a year or "Unknown"). I also added a sortname for everybody. We don't really need a display name -- we can just use sortname. We can automate S2 minor characters now if y'all want.--Hardvice (talk) 22:56, 3 January 2008 (EST)
      • I think it'd be good to see if it's working. -- RyanGibsonStewart (talk) 23:12, 3 January 2008 (EST)
        • It appears to be. Check this talk page's main page.--Hardvice (talk) 23:14, 3 January 2008 (EST)
          • Yeah, I just saw that. Duh. :) The only one who's not appearing is McSorley, and for good reason. It's also nice that others are automatically alphabetized correctly, like Rey Mysterio. Well done! -- RyanGibsonStewart (talk) 23:17, 3 January 2008 (EST)

Multi Season Minors

  • OK, one more question: Miami brought up the idea of de-automating previous seasons. I'm not sure that's necessary; most of the moving around from type to type seems to be among the main, recurring, and supporting guys, so all we're losing is the ability to have a different picture season-to-season, which is no biggie. However, we will need to manually add previous season categories to minors who appear in multiple seasons. For example, if the Copy Kingdom manager appears in season three, his navbar will be updated, assigning him to S3. All well and good. We can just manually add the cat for season 2 to keep him in the auto portals. If we do that, we should do it for all season one characters who appeared in S2 as well (not that many, actually), which would make each season cat a complete list. Is that worth doing, or should we just "lock" previous seasons as Miami suggested?--Hardvice (talk) 23:27, 3 January 2008 (EST)
    • I lean on the side of "don't fix what ain't broke" and leaving S1 portals alone, but I don't have too strong an opinion either way and can be easily swayed by a good argument. -- RyanGibsonStewart (talk) 23:39, 3 January 2008 (EST)
      • I agree about S1. But now I'm talking about what happens when S3 starts. Do we want only the most recent season automated, or all seasons going forward? Either way comes with costs.--Hardvice (talk) 23:51, 3 January 2008 (EST)
        • Oh, I see. Well, I'd rather have all the seasons from here on out automated. I mean, by "locking" previous seasons, I'm reading that to mean that we automate the portal during the season, and then make it manual after the season is over? That doesn't make much sense to me, or else I'm missing something. -- RyanGibsonStewart (talk) 00:01, 4 January 2008 (EST)
          • The only reason we'd need to lock them (which is exactly what you said) is that, currently, a character only belongs to their most recent season. That means that once the Copy Kingdom manager (can you tell I'm pulling for him to make a comeback?) appears in Season 3 and we update his navbar, he'll automagically disappear from the S2 portal. Maybe that's a good thing. If it isn't (and I lean towards it not being a good thing -- latest season makes good sense for a navbar, less sense for categories and portals), then when we bump his bar, then we either need to de-automate S2 (and I'm with you -- ugh) or we need to manually add [[Category:Season Two Characters]] so he'll appear in both cats and both portals. And if we're going to do that for some characters (minor characters), then we should do it for all (Peter is, after all, a S1 and S2 character, and really belongs in both cats/portals, no? He's in both portals, but currently only in S2 cat). Did that make sense?--Hardvice (talk) 00:10, 4 January 2008 (EST)
            • I think so, but my brain is fading fast. Here's my opinion, do with it as you want because I have no idea if I'm addressing the issue or not. :) If a minor character appears in more than one season (like Mr. Egami), I think he should be listed in both the season one and the season two portals. If he appears only in season one (like Chandra's super), he should appear in only the season one portal obviously. As for non-minor characters, here's what I think. If a principal character appears in more than one season (like Peter), I think he should be listed in both the season one and the season two portals; he should also appear in the character navbar, of course. If he appears only in season one (like Isaac), he should appear in only the season one portal obviously; he should not appear in the character navbar. There ya go. I feel like I'm talking parallel to you, so I hope that I'm hitting an intersection point somewhere along the way. :) -- RyanGibsonStewart (talk) 00:19, 4 January 2008 (EST)
              • I've been convinced that having a different picture is worthwhile, so I side with the "locking". Another advantage of the "locking" is that a redlink will appear if for some reason one of the articles manages to disappear--not that that should ever happen, but at least if a server glitch happens that renames/deletes a portal article, or someone renames it we're more likely to notice if a redlink we're to appear. The work required to "lock" is not significant cause DPL allows you to view a pre-type version of the page as a "debug" option. In any case, this discussion probably belongs on a portal talk page or the community portal so we can gather a consensus.--MiamiVolts (talk) 00:20, 4 January 2008 (EST)
                • I just don't see much value in the different pictures. I mean, I thought it was cool that we had pictures of Candice and Michelle, but it's a fluffy, unnecessary cool--and it's not going to be all that important to other characters who don't change identities. After all, the character article only has one portrait, so that ought to be good enough. And the crufty bar patron proves that new characters may indeed pop up from time to time, or we might get pictures of formerly unseen characters, and keeping the portals automated handles all of that (ditto name changes). In fact, the biggest reason I can think to lock them is actually the deceased reflex, and even that doesn't seem essential. I can really go either way, but the ability to use different pictures seems minor. Barring that, though, I still think everyone who appeared in Season One and Season Two should be in both categories, even if the portal is locked. I'd rather have the portals match the categories than the categories match the navbar.--Hardvice (talk) 00:27, 4 January 2008 (EST)
                  • I agree re: portals → categories and not categories → navbar. -- RyanGibsonStewart (talk) 00:31, 4 January 2008 (EST)
                  • I also agree re: portals → categories and not categories → navbar.--MiamiVolts (talk) 00:57, 4 January 2008 (EST)
                • The deceased reflex is a major method of changing the pictures. Imho, automation is best when we are going to be updating a portal often. When it is going to remain mostly static, it should be deautomated cause it is not going to be checked often. A Wiki, like any computer system, is subject to flaws and corruption that can go unnoticed. Having the previous seasons in manual format forces a redlink if an article gets renamed or removed accidently.--MiamiVolts (talk) 00:57, 4 January 2008 (EST)
                  • Actually, it occurs to me that, as long as we're adding season categories, we don't have to make the cut-off for turning off the auto portal the first episode of the new season. We can leave both seasons auto-updating until the previous season seems "set", and then lock the previous season. (I'm thinking more of actors than characters here--the character articles get written pretty quickly, but the actors have a tendency to linger. We might not have articles for all the season two actors by the time season three starts, for example. And we can always re-run the old DPL statements to "refresh" the locked pages if a whole bunch of new characters or actors are added, bearing in mind that we'll have to redo any manual changes we've made (un-deceasing S3 deceaseds, swapping pictures, etc.) In fact, we could leave the DPL code, commented out, on either the portal or its talk page, so that we could refresh the portals and navbars whenever we need to.--Hardvice (talk) 01:07, 4 January 2008 (EST)
                    • Exactly. Switching is not that big a deal, but in the non-DPL format we can be more aware of changes that get made.--MiamiVolts (talk) 01:10, 4 January 2008 (EST)