Toggle menu
Toggle preferences menu
Toggle personal menu
Not logged in
Your IP address will be publicly visible if you make any edits.

Forum:Infobox: Setting variables

The Cloisters
IndexTech notes → Infobox: Setting variables
Spoilers are strongly policed here.
If this thread's title doesn't specify it's spoilery, don't bring any up.

Note from Tybort: This overlaps a lot with the context of what to do with {{bp}}. However, I didn't find it easy to separate it and place it in Forum:Infoboxes and Template:Bp. -- Tybort (talk page) 02:17, March 12, 2012 (UTC)

Tybort's question to CzechOut[[edit source]]

Note from Tybort: I asked CzechOut five broad questions. This one is specifically about the setting parameter. -- Tybort (talk page) 02:17, March 12, 2012 (UTC)
What warrants a "main setting"? Do important preludes and epilogues count if they're a massive part of the plot? -- Tybort (talk page) 00:45, March 10, 2012 (UTC)
The definition of a "main setting" is surely subjective, but maybe if I give a few examples it'll make sense. It's the same variable that it's always been, just with a different label. By changing the label, I was hoping to encourage a reduction in clutter a bit. A lot of these pages had ridiculous detail ("London, England, UK, Earth" when "London" is just fine). To answer your question directly, I would say it's best to keep it to just a single, broad location, unless the action really is split. With Closing Time, for instance, It's really just Colchester. The bit at the university doesn't warrant the additional space that mentioning it would take up. What people have to remember with infoboxes is that the more info they contain, the longer the infobox is, and the more the pics on the page are going to get screwed up. They're not meant to house every single detail of the production. There should be just enough to jog the memory or otherwise merely identify the programme. The article is where the details should be. If the action is truly split 50/50 between two locations, maybe it's okay to put them both down. But, y'know, The Five Doctors happens on Gallifrey, period. There's no need to say, "some of it's in the Citadel, some of it's in the Death Zone, some of it's in the Tomb of Rassilon, and a wee bit of it is back on Earth". And The Doctor Dances happens in London during the Blitz". There are smallish scenes which happen elsewhere, but "London during the Blitz" is more than enough. I guess what I'm saying is that an infobox should be about economy. Find the fewest amount of words to indicate the truest sense of the episode, and you've solved the riddle.

czechout<staff />   01:59: Sat 10 Mar 2012 

Tangerineduel's question to CzechOut[[edit source]]

Are you ever not busy? :)

Just a quick question, re the retirement of my little bp template, how will we list multiple years/settings without line breaks/bullet points? I'm thinking of stuff like The Chase and The Left-Handed Hummingbird. On The Chase it's fairly obvious with all the settings sort of crammed together. Thanks. --Tangerineduel / talk 13:23, March 10, 2012 (UTC)

My immediate priority is scrubbing the bulletising HTML. Whatever our ultimate solution, it cannot be bullets, as the indentation plus the bullet takes up at least 15 px, which we just don't have to spare in an area that's only ~130 pixels wide. Not to mention the fact that it's a direct violation of T:NO HTML.
For the moment, the bot is simply replacing all that with a comma and a space. In most cases this is totally fine, because people were using bullets for as few as two items. If there's much more than three, the case needs to be considered individually, anyway. It's at that point that people are trying to cram too much into the infobox and manual editing is required. So I think the way I'm looking at it is that the bot will serve up a "best case" rendering of the information. If it looks like crap, a human has to intervene and refactor it in some way.
That leaves us with what to do about {{bp}}. I dunno. I don't really want to do a bot run to redo it, cause the regex would actually be fairly complicated. So I'll probably just change it to work to insert commas and a space. That seems the easiest solution, and it doesn't invalidate people's previous work.
As for the concept here, I know what you mean about stories that have multiple locations. But I'm hoping this design forces people to be more economical. As you've pointed out before, infoboxes don't need to be huge repositories of information. We don't need n't need huge amounts of detail. For The Chase, I'm hugely tempted to say the answer is "various", but I know that won't fly. The major locations, though, are clearly "Aridius, Mechanus and Earth". I mean, look at the bloat in this one:
Aridius, Empire State Building, New York City; 1966, Mary Celeste, Atlantic Ocean; 1872, House of Horrors, Festival of Ghana; 1996, Mechanus; 23rd century, London; 1965
There's no way you need "New York City", "Empire State Building", "Atlantic Ocean", "House of Horrors", or "London 1965" for a start. These are all truly minor details. I think the years in general are pretty unnecessary. The longest this thing should be is:
Aridius, the Mary Celeste, the Festival of Ghana, and Mechanus"
Now, you'll notice I was quick to drop the time. But this brings to mind a crucial question that I'm still struggling with. I think I'm leaning toward believing it would be better to just have two variables, one for space, one for time. I think this is what the founding editors were intending when they started this business of the {{{year}}} variable. Year is such an odd word for setting. I think maybe they had in their minds that they were going to define the year with one variable and the spatial setting with another. I think there are a number of stories that are set in basically one time where it'd be helpful just to split things on a time/space axis. Like Logopolis is all 1981, regardless of what setting you're talking about. Or The Massacre or The Highlanders or The Romans. They're all one time. So you can say for Logopolis setting=Earth, Logopolis|time=1981. It'll read cleaner. In more complicated cases, you'd maybe want to use just the setting variable and go: setting=Location1 (time1), Location2 (time2)
Hope that makes some sense of your question.
czechout<staff />   07:35: Sun 11 Mar 2012 
Can we not have bullet points but remove any indentation? Or do bullet points not work like that here?
I can see what you're trying to do with the setting field, and I agree, we don't need all that information, it's enough to say where the setting is for the characters, rather than being all specific about what land mass or nation it is (unless that's the only info).
I don't know what the original editors were up to, I think it was user:Mantrid who gave us infobox, but the fields were never explained it was more a case of look at the stories it was used on and then go and use it on others. Or at least that's how I and others went about it. I remember there being an infobox before Mantrid's creation though I can't remember what stories it was on (only remember removing it and all its code from pages.).
I definitely think we need to keep setting and year. I think this might also help editors to economise their information, if we say the setting field has to be a single location and the year field has to only correspond to that location.
Would this mean that we'd have multiple fields like setting1=/year1=, setting2=/year2= etc? I'm just thinking that if we've got all the info organised like that it would make using that data, when separated out like that a lot easier than just with commas (though I also imagine that it's not something a bot can do, so there'll be a lot of manual edits in the future). --Tangerineduel / talk 16:21, March 11, 2012 (UTC)
Okay, I've found a way forward on the list issue. Could I play with the CSS to make a special class for bullets as used in the infobox? Yes. Am I goonna do it? No. Even if you narrowed down the indentation below its standard level, you've still gotta have something there, and allow for the space of the bullet itself. It's a waste of space.
But I am mindful of the problem and will get around to something in time. The way forward is something like Template:Plainlist that wikipedia use in their infoboxes. That's why I've kept {{bp}}, but temporarily changed how its used. It'll be relatively easy to move that template on to a new and better use. And, because I'm converting the raw HTML lists in a standard way, which should make it pretty easy to take care of some sort of conversion for those in future. Manual edits of the infoboxes should be afvoided for the next week or so, because I'm intentionally editing things in a standard way so that it'll be a snap to use the bot for future changes.
Just to clarify the {{{year}}} and {{{setting}}} thing, we don't have both on any single infobox. It's that some of the story templates use {{{year}}} and some of them, {{{setting}}}, but both currently mean "setting". It'd require an easy, but time consuming bot run to change all the {{{year}}}s into {{{setting}}}s, at which time we'd want to introduce a new variable, prolly {{{time}}}, if we wanted to have one variable for location and one for time.
As for multiple setting and time variables, I'm not so keen. I think this is something that will be better solved by the introduction of something like a Template:Plainlist than by having multiple variables. I can't think of a reason we'd ever need to specifically manipulate a {{{setting3}}}, for instance. I can maybe understand a {{{major setting}}}/{{{minor setting}}} kinda deal.
Anyway, please take a look around wikipedia and other wikis, consider things you like about them, then bring those desires to my attention. I'll try to integrate them where possible. For the next week or so, my big focus is simply on getting the infoboxes installed and the HTML consistently removed. I'll definitely advise when we get to the point that the bot has done all it can. We're nowhere close to that yet, though.
czechout<staff />   20:45: Sun 11 Mar 2012 
Cookies help us deliver our services. By using our services, you agree to our use of cookies.