User talk:Captainmike/archive 2016

How is Star Trek Online a part of the Star Trek Expanded Universe?
Hello Captain Mike,

How does Star Trek Online fit into the Expanded Universe timeline? I have been playing the latest module for it: Agents of Yesterday which feature a couple of missions that take place on Original Series worlds and settings. If we add those would they require to have their own headline?

I am asking as Star Trek Online's 24/25th century are differently depicted than in Pocket Books (the Borg still being around for example). The distinction between the two timelines were more clear, but the AoY missions are just set after the Original Series television series.

One mission for example involves Murasaki 312, how would I add that?--The Dutch Ghost (talk) 22:02, July 10, 2016 (UTC)


 * The STO game nominally takes place in the future of the 'standard' Star Trek timeline, but is only a 'possible future' (which is why the STO novel differs from other timelines)... in particular, there seems to be changes of premise that occur between the latest Pocket novels and the earliest STO sources -- but since the 'standard' timeline hasnt gotten there yet, we generally don't want to waste time speculating on why those changes occurred, or how.


 * The new module I'm unfamiliar with, but if it involves traveling back in time from the 25th century, then it can be described as those from a 'possible future' traveling back into the 'standard timeline' and possibly (but not necessarily) causing an 'altered timeline'. I really can't say because i'm not aware of the premise.


 * But simplicity is key, so i'd say they're probably in the 'regular' 23rd century and you're just going to lists this as a regular reference to Murasaki 312 just like any other source. Not 100% sure if that's what you're asking, but I hope this helps. -- Captain MKB 22:09, July 10, 2016 (UTC)

Yes, that was basically my question: how to treat the new content of this module. Should it be put in the main timeline or I should I put a clear indication that this content is part of the Star Trek Online timeline. The new module starts out in the 23th century (the player can create a new character in this era) and is set some time after the end of third season of the Original Series. There is some time travel in it but from that period back into Season 2. The time traveling Na'kuhl also make an appearances (hope that does not spoil it for you) during the story campaign of Agents of Yesterday.--The Dutch Ghost (talk) 07:30, July 11, 2016 (UTC)


 * I don't think there's a clear point of divergence that would allow us to call it an alternate reality. Sounds like the content of the story could lead to that outcome, but you should be putting everything in as regular references. -- Captain MKB 11:54, July 11, 2016 (UTC)

Okay, I will put in all the Agents of Yesterday under the general timeline articles of the mentioned subjects. So far there does not seem to be a breach with the established storylines, the missions involving time travel back into the Original Series seasons are more like 'hidden perspectives', elements that were not told during the episodes such as there being Na'kuhl on the Enterprise during "Journey to Babel" who also provided the Orions with the technology for their fast attack ship, or giving the Klingons cloaking technology (well it seems to be implied during that mission in STO).--The Dutch Ghost (talk) 12:39, July 11, 2016 (UTC)

Spoilers
Did not think i put that many spoilers into it. I just tried to keep it like it was on Memory Alpha. Plus, i forgot about spoiler template. Thanks for warning, will try to remember that for next movie or show.CC-1990 (talk) 23:21, July 22, 2016 (UTC)

Question about stubs
I've noticed that you've frequently added stub templates to very short articles. I am not entirely certain that this is correct, as it is my understanding that, sometimes, the articles are short not because they are stubs, but because that's all the details given about the subject in the source materials. Doug86 (talk) 03:35, July 31, 2016 (UTC)


 * I've been adding the stub template to articles that need completion. I assure you there is additional context to be added for all these articles. -- Captain MKB 09:46, July 31, 2016 (UTC)

USS Excelsior
This user, 184.1.16.134, vandalized the USS Excelsior (NCC-2000) page by replacing words with some nonsense words. Not only did I revert his edit, but I even gave that user a warning about what would happen if he did it again. Please block this user as soon as possible. AdamDeanHall (talk) 19:45, August 1, 2016 (UTC)

Charlie Pike deletion discussion
Can you explain to me what I did wrong and tell me what I should've done instead of just saying it was an "inappropriate discussion"? I thought I was following the policy as you explained it to me in Forum:Characters with contradictory names. NetSpiker (talk) 00:48, August 3, 2016 (UTC)


 * Suggesting a merge or discussing altering the format of the article can take place on any article's talk page.


 * A deletion discussion presupposes that there is actual reason to DELETE the article -- and there is no such problem with Charlie Pike. it is a responsibly written article from a valid source. A deletion discussion could be very threatening to the author of an article, who as far as I can see contributed in good faith. There's no reason either Charlie Pike or Josh Pike should be deleted. -- Captain MKB 00:55, August 3, 2016 (UTC)

I didn't mean to offend anyone. Since Memory Beta (unlike Memory Alpha) doesn't have a "Pages to be merged" section, I mistakenly assumed that the "Pages for deletion" section would be the right place for a merge request. I will restart the discussion on the Charlie Pike talk page. NetSpiker (talk) 03:22, August 3, 2016 (UTC)


 * OK, but for the record, i am of the opinion that the articles should not be merged. they are two different characters. i'm sorry it doesnt appeal to you that there are discontinuities. -- Captain MKB 12:56, August 4, 2016 (UTC)

I have no problem with different stories contradicting each other. I just suggested that they should be merged because you once told me "I definitely would not suggest or support there being two articles for one character. these should redirect to a common page". How is the Charlie Pike/Josh Pike situation different from the Ra-ghoratreii/Eteon tar-Chereos situation? NetSpiker (talk) 13:23, August 4, 2016 (UTC)

EDIT: I just read what you posted on the Charlie Pike talk page. So there's no policy that alternate names are not supposed to have separate pages. You judge each example on a case by case basis and decide whether or not it's different enough to be considered a separate character. I guess that's okay. NetSpiker (talk) 13:32, August 4, 2016 (UTC)


 * Its different because both Ra-ghoratreii and Eteon tar-Chereos are the same person holding the same position, but with a different name. There would be no difference between two separate articles about them because they both have identical life-timelines and actions. Even in cases like this where novelists have written different endgames (perhaps there are even two separate obituaries), they are still the same person just with a branched endpoint.


 * Charlie Pike and Josh Pike, despite both purportedly being Pike's father, have both led sharply different lives and hold different places in the Trek universe -- Josh Pike is Starfleet's elite, a retired admiral if i am not mistaken -- while Charlie Pike is an NCO who has had a soap opera of history with remarriages and his son being adopted away from him and then reuniting


 * It would be a disservice to templatize Charlies history into Josh's article and it would be a disservice to change Josh's history to reflect what was written about Charlie. They're two different people. -- Captain MKB 13:39, August 4, 2016 (UTC)

Portable infoboxes
Heya :) sulfur and I have been working to make the infoboxes on MA portable, and he thought it would be cool if I swung by here to offer my services, as well.

Changing over to portable infoboxes will help more people on more devices see your content. It'll also put you in a better position for the future, as the infobox morphs from something which simply shows data into something that leverages data.

I've therefore whipped up an example for you at User:CzechOut/Starship. As you should be able to readily see, Starship/Draft works just like Starship. All the same variables are employed. And the re-coloring of titles happens just as it does now: depending on the value of.

Since you're an artist, I thought you might enjoy looking at a very slight variation to your current design. As you can tell, I've taken the padding along the outside edges of the infobox away to give a sleeker look. If you'd like that restored, it's super easy, but I just thought we might look at this as an opportunity to freshen things up slightly.

Please do take a look and let me know if you'd like me to change any of this. Since all your infoboxes use this basic design, once we get this first box settled, it'll be easy to pump out the rest of them.

And just to emphasise: you don't have to do any work on any of this. I'll build 'em all based on your approval of this first design. — CzechOut 22:59, August 7, 2016 (UTC)
 * Oh there's also a comparison of the Character infoboxes to look at. — CzechOut 23:55, August 7, 2016 (UTC)
 * Heh, actually ... once I started working with Characterbox a bit more, I just went ahead and added all your original padding back in. The alt pictures at the bottom collided with the image of rank insignia, so the original negative space was pretty useful.  You may have to do a browser cache clear, but you should find that the old and new boxes are pretty much twins now. — CzechOut 00:36, August 8, 2016 (UTC)


 * Hi, I took a look and the look seems pretty legit. my main concern would be the way the code is written -- as Wikis go, we are advised to stay away from HTML and keep the data entry simple -- i have a hard time convincing users not to put HTML overrides and workaround coding in tables and infoboxes, so hopefully anytime that happens wont break the efforts. i'd like to be assured that the code does not violate any of that rule of simplicity, furthermore.


 * i'm not in a great place to comment further, because in coding the padding and color changes ten years ago i did a lot of awkward workarounds myself. but i'd just hope it is something we can apply without any outages or violations of any rules. -- Captain MKB 23:18, August 8, 2016 (UTC)


 * Well, the portable infobox code was designed specifically with simplicity in mind.


 * Data entry is absolutely the same as with the current, wikitext infoboxes. Not a single variable has been harmed in the making of your portable infoboxes. Whatever you did before to call your infoboxes on a page is exactly what you'll do with the portable versions.


 * Meanwhile, most communities have found that it is much easier to build a portable infobox from scratch than it is to attempt one of the old-school wikitext models. This is because a lot of the parser functionality is built into the code.


 * For instance, if you wanted to make sure that a variable in, say, starship didn't appear if there was no value for the variable, you'd have to write an #if: statement, like this:


 * By contrast, portable infobox code simply assumes that you don't want the line to show up if there's no value for it:


 * That's it! There's no counting of the number of curly braces to make sure they show up.  There's no need to worry about using 1. It's simply naming the variable and offering the label.


 * And by tucking away the styling into CSS pages like MediaWiki:Infoboxes.css and MediaWiki:Themes.css, we're further protecting your infoboxes from accidental damage. You have to be an admin (or staff or one of our official helper groups, like Vanguard) to affect the template styling.


 * As for introducing HTML, don't worry. Though it looks similar, this isn't HTML but XML. It's hard for users to "break" without immediately seeing that they've done something wrong. Warnings immediately pop up when you try to publish something the parser rejects as bad code.  And when something is broken, you get a very clear sign on pages that call the template that the infobox is refusing to parse.  So in the case of someone other than you passing rejected elements to the template, you would simply return to the template and undo their edits to the last known good version.


 * This is better than the wikitext infoboxes, because users could introduce errors without any sort of alarm. They could remove a single curly brace, and the box would still function -- except in one harder-to-spot area. They could change the background color of a single line in the box, and you might not notice for weeks. If the infobox were particularly obscure, those errors might stick around even for years.


 * Such damage is much less likely with the portable infobox code. Understand, though, that I'm not saying PI code is completely foolproof.


 * Users could introduce undesired changes that weren't coding errors. For instance, they could remove an entire  line, the infobox would still parse correctly, and you'd be none the wiser unless you happened to spot the absence. And they could vandalise the spelling on labels and titles. But they could do that with wikitext infoboxes.  And portable infoboxes can't be genuinely broken without an error message and publishing alarm being tripped.


 * If you wanted additional assurances, you could always just protect the templates. Since the number of active admin is relatively small, it would be relatively unlikely that someone other than you would break them.


 * Does that allay your concerns? If you have further concerns, please feel free to ask them below. Or, if you have no further issues, lemme know if it's okay for me to actually push the "approve" button -- yes, there's an actual button! -- on these new designs, or if you'd like to do it yourself. Thanks! — CzechOut 17:56, August 9, 2016 (UTC)


 * I think we're in a good place to use these. make it so, engage, etc -- Captain MKB 13:18, August 11, 2016 (UTC)
 * Engage I did, and now your infoboxes are all converted to portable. Please lemme know if you run into any problems! — CzechOut 03:58, August 12, 2016 (UTC)

Hyphenation in portable infoboxes
Okay, I killed the hyphenation in the data labels and data values. I think you might have been seeing it here with greater frequency than is typical because your infoboxes are a bit on the narrow side. — CzechOut 16:56, August 12, 2016 (UTC)


 * A lot has changed in display standards since 2005 when we launched - widening them might be the next step. Having the code simplified makes that easier! Thanks again -- Captain MKB 01:18, August 13, 2016 (UTC)

Image handling
I'll take a look. Sorry for the inconvenience. I hadn't expected that prose-only people would be represented by symbols. I just thought they wouldn't have a picture. — CzechOut 02:55, August 13, 2016 (UTC)
 * Is this practice widespread, or is it just something that happens with Characterbox? To find a solution, it's going to be important to know which templates, specifically, are affected. — CzechOut 03:01, August 13, 2016 (UTC)
 * Okay, I think I've fixed it for you. Please take a look at Agbadudu and let me know if that's what you were hoping for. Thanks! — CzechOut 03:21, August 13, 2016 (UTC)
 * That's a lot better. I've been trying to think of a better arrangement of those forever, but they are very widespread. i've thought of making icons a separate line in the table from the image, but it would kind of mean going through every template someday to change the parameter. we might want to do that someday, but for right now this is what i am used to. - Captain MKB 04:31, August 13, 2016 (UTC)


 * It doesnt look great on mobile either, so it' something we'll probably have to fix eventually -- Captain MKB 14:53, August 13, 2016 (UTC)


 * Well, I wouldn't call it horrible. It still gives recognizable icons-at-a-glance on a single line, like on desktop. But if you want anything different, you are going to have to consider a major overhaul.


 * As I see it, there are two options, both requiring a bot (which I can provide). You can:
 * * put each image into a variable of its own, and then let the infobox code handle each image naturally or through sidebar image portable
 * * actually remove the images -- or change the image variable name -- so that you have no image


 * In any case, for the short term, it would be helpful to know the names of the templates where this dual-icon approach can happen. For instance, he reason planetInfobox is exhibiting the undesired behavior is because I didn't know to apply the characterbox fix there. — CzechOut 16:32, August 13, 2016 (UTC)

Adapted box

 * hey i just noticed that adapted didnt really get a new treatment -- its a hybrid for episodes that are also comics and novels - the episode style you picked up is deprecated, by the way -- we were trying to transition that to be ore like the other infoboxes (as the "adapted" one reflects) -- Captain MKB 14:53, August 13, 2016 (UTC)
 * Yeah, adapted wasn't classified as an infobox -- instead it showed up as "unknown" template type -- so it wasn't on the Special:Insights/nonportableinfobox list of infoboxes to do. It's done now, though. And it appears to function better than the previous version, in that it actually displays images and a ton of variables (particularly in the "publication information" section) that had been specified, but weren't displaying.


 * This incident makes me believe I'm going to have to crawl through all the templates at Special:Templates to find any mis-categorised infoboxes. If you know of any that do not currently appear at this list of converted infoboxes, please let me know. — CzechOut 16:32, August 13, 2016 (UTC)

Other styling matters
Are you saying that you'd like all infoboxes to be styled in exactly the same way, and that characterinfobox and starship and adapted are exhibiting that style? (FWIW, I think that would be a great and highly sensible move.)

If that's true, can I get a ruling on where you want your section headers? Some infoboxes have them left-justified. Others have them centered. You can see the confusion by going to The Counter-Clock Incident, where the code obeys the conditions set for Characterbox. However, Characterbox has the added advantage of colored headers, so the headers stand out more there than in other infoboxes.

I think I'd recommend all of your headers to be centered. What do you think? — CzechOut 16:32, August 13, 2016 (UTC)


 * Seems legit. Yeah, i hadnt realized there were such different styles at play. Characters, planets, ships and facilities benefit from coloration in headers, while episodes and other media do not need that attribute -- but the goal is definitely to have the font, alignment and cells styled the same for all of the above.