user talk:captainmike/archive 2007
user talk:captainmike/archive 2008
user talk:captainmike/archive 2009
user talk:captainmike/archive 2010
user talk:captainmike/archive 2011
user talk:captainmike/archive 2012
user talk:captainmike/archive 2013
user talk:captainmike/archive 2014
user talk:captainmike/archive 2015
user talk:captainmike/archive 2016
user talk:captainmike/archive 2017
user talk:captainmike/archive 2018
user talk:captainmike/archive 2019
user talk:captainmike/archive 2020
user talk:captainmike/archive 2021

How is Star Trek Online a part of the Star Trek Expanded Universe?[edit source]

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[edit source]

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[edit source]

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[edit source]

This user,, 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[edit source]

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[edit source]

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 {{{type}}}.

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:
{{#if: {{{class|}}} |
! align="left" {{1}} Class:
{{1}} align="right" {{1}} {{{class}}}
By contrast, portable infobox code simply assumes that you don't want the {{{class}}} line to show up if there's no value for it:
<data source="class"><label>Class:</label></data>
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[edit source]

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[edit source]

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[edit source]

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)
Adapted is the newest one, its designed to work as a couple of infoboxes its a merge of novelization, comic adaptation, film, and can replace film parameters with episode parameters -- it could be merged with episode in the future, but right now it is used for episode-with-comic-adaptation (omitting the novelization parameters), novel-with-comic-adaptation (omitting the episode and film parameters), and films-with-comic-and-novel-adaptations (as well as ones with novels but not comics)

Other styling matters[edit source]

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.
Headers now all centered. — CzechOut 00:01, August 14, 2016 (UTC)

Other Wikia sites[edit source]

Oh, hmmm. Interesting. I'd never thought of the template naming as indicating whether the wiki was on the Wikia network or not.

I was going off the actual language of the templates, which was saying that the site was a "wikia". That's language to which none of the sites I've encountered so far would actually agree. DC and Marvel are resolutely Databases; Tardis is definitely a wiki or "the data core".

I think I've only moved three or four, none of which have a "better" version off-Wikia, and I've kept redirects for all, so that longer-term editors won't be confused. I think I've already passed by {{stowiki}} and {{stowikia}} in my template reclassifications -- without renaming them. As a sometimes STO player, I got the distinction you were going for in those titles. — CzechOut 03:29, August 14, 2016 (UTC)

Reclassification results[edit source]

After reclassifying several hundred templates from "unknown" to something meaningful, it looks like a majority of your infoboxes weren't classified as "infoboxes". I'm not quite sure why. Of all the wikis I've worked on, the initial bot classification here seems to have been the most profoundly incorrect.

This, of course, means I'm not as close to being finished converting your infoboxes as I thought a couple of days ago. But now that we've said they're all going to have the same format, it should be something I can finish this weekend. — CzechOut 03:52, August 14, 2016 (UTC)

Image fix[edit source]

I've discovered today that the image fix that I came up with yesterday has a serious downside. It allows users to specify a certain imagewidth. But, I hear you say, "That's what it was supposed to do, so that we could get those really small icons to work."

Yes. But the problem is that it will totally break the infoboxes if the widths are specified too high (>220px)

image width too wide (300px)

image width too narrow (150px)

As you can see, this is problematical on two levels. First, it makes {{{image}}} and {{{altimage}}} have different widths. As there's no need to apply the fix to altimage, it's handled entirely by PI code, and therefore is scaled appropriately to the width of the infobox. Second, it means that, even when images technically "fit" the infobox, they won't have the same surrounding whitespace. Everything I've seen about your infoboxes tells me that's not what your design ethos is. I think you intend uniformity.

Essentially, this fix is allowing those infoboxes that don't have real images of the subject control how infobox images work. And that's not a great idea. Infoboxes that actually have images of their subjects should be the standard case, and those that don't should be very much of an exception.

I therefore propose this solution:

  1. Remove the current "fix", thereby allowing infoboxes with images of their subjects to be considered the norm in the code.
  2. Use my bot to go through the pages and find the instances where two images are in the value of {{{image}}}. Change the name of these variables to {{{icon1}}}. Since {{{icon1}}} does not exist in any infobox template, this will have the immediate effect of simply removing the "double icons" from all infoboxes.
  3. If you're fine with not having images of things that don't actually have images, we can stop right there.
  4. If you want to retain the icons, then we would do another bot run that separates the first icon from the second. We'd make the second icon the value for {{{icon2}}}.
  5. Then, we'd do one of two things:
    1. Apply a variation of the original fix, using {{{icon1}}} and {{{icon2}}}
    2. Apply {{sidebar image portable}}, but in a way that would get bigger icons that would look better on phones. See First Battle of Berengaria for an example of how this would work.

I should say the bot work is very easy, and I intend to run it manually, so that I have to approve every change. The chance of screwing anything up is practically zero. (And don't forget sulfur taught me most of what I know about bots, so this is very much an "all-in-the-family" kinda job.)

What do you think? Does the proposal -- and the need for it -- make sense to you? — CzechOut 19:39, August 14, 2016 (UTC)

We've had trouble for years getting people to adhere to image sizes -- i'd actually welcome automating the 220px requirement so we didnt have to teach people to use it.
I'd be in support of restoring the full size image code with the proviso that icons go somewhere else - if there's no actual image, it can be blanked. this will be a benefit to mobile use judging how the last fix rendered.
The reasoning behind the small icons is so they don't balloon the height of the info table, so it might be a bit of a stretch to have a table with both an icon row and the top and alt images - but that's the only detractions from the plan - and it wont even be hideous, just a little taller. -- Captain MKB 20:36, August 14, 2016 (UTC)

Are fanfiction allowed[edit source]

Just wondering are fan fiction series allowed? (Dragonboy546 (talk) 05:10, August 16, 2016 (UTC)Dragonboy 546)

No. Use the Star Trek Expanded wiki for those. -- sulfur (talk) 16:34, August 16, 2016 (UTC)
I didn't mean like fan series but novel format and I've been blocked till next year (Dragonboy546 (talk) 20:43, August 20, 2016 (UTC)Dragonboy546)

Infoboxes[edit source]

Hey! Sorry for the delay. I hadn't realised you had posted here, on your own page. I'll be working on those issues this weekend. -- CzechOut 22:31, August 26, 2016 (UTC)
Sorry again for having to push work here back a bit. I was sick last weekend and at the top of the week, and then had to play catch up as I careened towards the weekend.
So far today, the bot is going through every instance of the various infoboxes, like characterbox, which contain two images in {{{Image}}}. Once the bot finds this situation, it changes {{{Image}}} to {{{Icon1}}}, thereby removing it from the main infobox image space, and allowing us to regularise that space for "normal" pictures. In other words, that area of the infobox is now exclusively for a single picture of the topic of the page. And it'll automatically have the width of 220px.
Here's an example of a typical diff from this action:
What we do after this is, as I discussed a couple of weeks ago, a matter that needs some decision-making on your part. But let me get through taking this first step and we can talk about what comes next later. -- CzechOut 19:45, September 3, 2016 (UTC)

My pictures[edit source]


Why are the pictures what I upload deleted? The preceding unsigned comment was added by Jedi Raven (talk • contribs) .

You have to add a citation to the episodes, movies, comics, or novels the images are from. -- Captain MKB 19:12, September 10, 2016 (UTC)

Infobox update[edit source]

Heya :) Happy 50th anniversary day! All your infoboxes are now portable, and I think I've got a good handle on the commonness of the icons-as-image problem. The number of pages that used icons in the {{{image}}} variables was ~1300, allowing for the fact that the bot picked up some false positives. The only templates that used icons were:

Major instances[edit source]

More than 1000 instances can be found at:

Minor occurrences[edit source]

The rest -- probably only about 200 combined -- can be found at:

Very minor occurrences[edit source]

Fewer than three instances are at:

I separate it out on its own because currently it uses a different set of variables -- {{{image}}} and {{{image2}}} -- than any of the templates above it. It may require adjustment of its variables down the line. -- CzechOut 00:25, September 9, 2016 (UTC)

Infobox reversions[edit source]

Heya :) I notice you've reverted {{Characterbox}} and {{PlanetInfobox}}. It's gonna be hard to fix the icon issue if these are left as non-portable infoboxes. Could we please convert back to portable infoboxes and make changes based upon the newer design? -- CzechOut 19:55, September 12, 2016 (UTC)

Monobook image issues[edit source]

I think why Sulfur was encouraging you to send in a Special:Contact was because it would help establish a record of all the communities unhappy with this issue. That's really important with Monobook problems, in particular, because -- as you should know by now -- we offer only limited Monobook support. Having feedback from a wider variety of users means that there might be a reason to prioritise it.

I can tell you that we're currently discussing this issue. I personally have gone to bat for a solution. But it would be wrong of me to tell you that I know what the results of that discussion will be. Or when a final decision will be made.

Instead, I'd ask you to look at this as a "needs of the many" situation.

Your editing community overwhelmingly uses Oasis and Mercury. And your readership all-but-exclusively uses them.

Now, like you, I'm a Wikia user from way back. I probably miss Monaco more than Monobook. I'd really like to believe that the Monobook/Oasis user ratio was a lot closer than it actually is. It took me a long time to accept this simple truth: only an extreme minority of current Wikia users even knows what Monobook is. Fewer still care so much about Monobook that they're flatly unwilling to edit in Oasis.

So most of your editors don't even know the problem exists. But they do know that, in general, portable infoboxes look better on their phones than non-portable ones. And the PI code has easily unified the design of all your infoboxes on the desktop for the first time in years.

That's why I hope you'll see that, while they may not be perfect, they do improve the situation for almost everyone who uses this wiki. And they're worth keeping around despite this Monobook image situation. -- CzechOut 01:33, September 13, 2016 (UTC)

Infobox conversion speed[edit source]

Mike, I'm sorry if you've felt that your needs weren't addressed swiftly. I think we have simply missed each other or misunderstood each others' priorities.

While you've been talking about this icon matter, there have been several other things I've had to look at -- just at this wiki. One thing that's been happening behind the scenes is that some of our analytic software has not been properly reading this wiki, or Memory Alpha. Some of my timing has been affected by that now-resolved issue.

There were also a number of newly-discovered infoboxes that had to be converted.

I've spent a non-trivial amount of time trying to address the Monobook issue with other staff members who have the technical ability to help. In fact, I literally just fired off another email while I was writing this message to you. This does take some time and effort because of our limited Monobook support.

I've also discovered that some of the template classification was producing less-than-desirable results on mobile, and have had to go back and redo some of it.

Bot work has taken up some unexpected time, too. Because I'm not a regular editor here, I've had to spend time understanding all the patterns you guys have used here to call infoboxes. Just to give one example, the fact that you guys don't use a standard pattern like

{{template name
| variable1 = parameter1
| variable2 = parameter2

but also use things like

{{template name|variable1=parameter1| variable2 = parameter2}}


{{template name|
variable1=parameter1 |

means that a bot has to be programmed more agilely.

And trying to figure out the icon issue hasn't been easy, either. I'll be writing about that later today to you, but I just want you to know that I have been thinking hard about a solution for you. As I said on the 3rd, when the first round of bot work went through, the notion was to simply park the icons in a single variable, and then decide what to do from there. Most of what you saw overnight was an experiment, not anything close to a final recommendation for you.

One thing that's important to understand is that every older wiki has its own peculiar challenges. There's generally always one thing at older wikis that is outside the norm of what's done with infoboxes, portable or otherwise. The icon thing, and the specific way you're using it, is something I've never come across before. But I'll talk more about that later.

For the moment, again, I apologise profusely for not keeping you in the loop about all I was doing here. But I would say that it is in no way unusual for conversion processes for larger wikis to take more than a month. -- CzechOut 18:46, September 13, 2016 (UTC)

Infobox icons[edit source]

Hey hey :)

I know you've been frustrated having to wait for an answer on the icon issue. But it's actually quite a complicated thing that's required me to look at other wikis, research the base portable infobox code and to pull in engineers to confirm that I was seeing what I thought I was seeing. Because it's a rather lengthy explanation, I've made it on a separate page. -- CzechOut 02:23, September 15, 2016 (UTC)

Novels allowed[edit source]

Are Novels allowed that aren't published? (Dragonboy546 (talk) 04:57, September 28, 2016 (UTC)Dragonboy546)

No. They have to be published to be a novel. -- Captain MKB 14:18, September 29, 2016 (UTC)

Could you check an article?[edit source]

Captainmike, could you have a look at my article and check if I have written it well. Somehow I have my doubts. --The Dutch Ghost (talk) 04:03, October 1, 2016 (UTC)

Template:Star[edit source]

My apologies. I honestly thought all that original coding was bugged. Take for example FGC-38919. The box creates a needless redlink at FGC catalog system name. The original coding, in every case, omitted the hyphen. That's a problem because the star pages are not consistently named. There's FGC-505183 but FGC 82659 and there are sometimes redirects on the hyphen, like NGC-8149/NGC 8149 -- and sometimes not, as with Wolf 359/Wolf-359.

So sometimes you were going to get redlinks in the infobox, and sometimes not -- and, to a reader, there's no apparent rationale for it.

It might be worth exploring the notion of making sure all catalog system names are available for linking -- and therefore searching -- both with and without hyphens. Obviously you'd give preference to the way it appears most often -- I'd hazard a guess that books take Emissary's lead and stick with the unhyphenated Wolf 359 -- but a hyphenated redirect would help casual fans who don't know off the top of their heads what's present in the pre-titles Emissary crawl. Plus, there's enough confusion in how pages are titled now to suggest that users will be looking for stars both with and without hyphens.

Still, as you've requested, I've restored the formatting of the old template onto the new one. So you'll again have the workings of the Bayer/Flamsteed star system name and all those catalog system names just as they were on the original. -- CzechOut 02:35, October 2, 2016 (UTC)

In cases where redlinks occur it identifies a need for a useful redirect. -- Captain MKB 02:37, October 2, 2016 (UTC)

tlhIngan Hol reference -> ST reference[edit source]

Hi there! I noticed you changed a few of my citations from tlhIngan Hol reference: Klingon for the Galactic Traveler to ST reference: Klingon for the Galactic Traveler. Should I do the same with references to The Klingon Dictionary, Conversational Klingon, Power Klingon, Talk Now! Learn Klingon, How to Speak Klingon and other sources for tlhIngan Hol? While KGT does delve quite a bit into culture, I feel that these works are very much focused on the language. --LoghaD (talk) 15:38, October 9, 2016 (UTC)

While you feel that the works are focused, I'm not sure we have a clear case of these being presented as a 'series' as such. That field in the template is reserved for abbreviations of the series name assigned to the works by the publisher, not based on how you feel. - Captain MKB 15:47, October 9, 2016 (UTC)
jIyaj. Will update. Seems I misread the description. Sorry! --LoghaD (talk) 16:08, October 9, 2016 (UTC)
We might have cause to assign some sort of grouping to the 'subseries' notation about these works, but time will tell - Captain MKB 16:52, October 9, 2016 (UTC)

Where does the name Terence Leyton come from?[edit source]

On the James Leyton page you changed the name "Robert Leyton" to "Terence Leyton" in the Known aliases section. Where does the name Terence Leyton come from? As far as I know, the only first names Leyton has been given in licensed books are James, Robert and Thomas. --NetSpiker (talk) 03:56, October 17, 2016 (UTC)

I'm ot sure, that was quite some time ago. I might have mistyped Thomas, but I'm really not sure - Captain MKB 19:22, October 17, 2016 (UTC)

Squished template formatting[edit source]

One of the visual editors does this fairly often.

It would likely be more productive to converse with CC-1990 to attempt to resolve the issue rather than just throwing all capitals in an edit summary.

So, perhaps talk to CC-1990 and ask if they're using the visual editor, and if so, suggest that they use the standard one. It might ALSO be worthwhile to submit a bug to Wikia pointing out that the formatting using the visual editor squishes all templates, including those classified as "infobox", when it should likely leave the latter formatted in an easy-to-read manner. -- sulfur (talk) 21:41, October 22, 2016 (UTC)

I wasn't aware of that aspect of the visual editor.
However, this user routinely ignores communications about formatting, so what we are looking at is an escalation. I had thought that you had pointed out the garbage formatting, but a review of said user's talk page reveals several other issues that have not been responded to -- for example, categorizations, which you issued reminders about in March of this year, even after having been ignored from leaving the same message in 2014 --- and we still have these new articles being created without categories. My notation about adding simple required formatting to images has been ignored several more times.
Simply put, attempts to converse with this user about similar topics have been made, as you suggest --- and failed.
As to talking to Wikia, i could use some clarification about the process -- my last attempt to bring a technical issue to Wikia's attention has not been answered, so I'm just feeling ignored at this point. -- Captain MKB 16:36, October 23, 2016 (UTC)

Next trick -- if you post on someone's page and they don't respond, a short block (allowing talk page editing) with a block reason of "please read and respond on your talk page" often works quite well.

In terms of Wikia contact, did you use the Special:Contact/bug mechanism, or just leave a talk page message? If you go through Special Contact, they are required to respond. Admittedly, sometimes those responses are "thanks for the info, we're adding it to another ticket to determine if we need to make a change", but it's a start. -- sulfur (talk) 16:46, October 23, 2016 (UTC)

Yeah, that was going to be my next step. I end up giving like three warnings about issues like that and then do a short block.
I haven't tried the contact report yet because i was a little disappointed by the result of my monobook inquiries -- i'm concerned that i was told raw code issue are also low priority, as monobook fixes are. this is disappointing, because i work with old computers and pretty much have to be in the world of raw code and monobook -- i just can't support the modern interface skins with all their scripts. Wikia is unusable to me when they make changes that don't work with the raw code and the old skin. -- Captain MKB 17:24, October 23, 2016 (UTC)

Crossovers with Other Properties[edit source]

Hey, so I notice you deleted the list at "Category: Crossovers with other properties", saying to "find an appropriate venue for this information".

What kind of venue would be acceptable? A non-category article of the same title, perhaps?

Thanks, Xaq 01:11, November 4, 2016 (UTC)

That sounds acceptable, yes. On the category's sort page, Sulfur proposed such an action and I seconded it, several years ago. -- Captain MKB 01:31, November 4, 2016 (UTC)

Monobook infobox image clickthrough fixed[edit source]

Just wanted to let you know that we've fixed the issue involving clicking on an inbfobox image in Monobook. Doing so will again take you to the File: page, just as it historically did. -- CzechOut 20:01, November 11, 2016 (UTC)

Logo images & USS Franklin template[edit source]

I found the source for the USS Franklin assignment patch. You can find it on memory alpha or in the image file that i've edited. Sorry for the mess up.

Plus, could you stop removing the Kirk and his crew from the USS Franklin personnel template. I just thought for the most part they should be included like they were on the franklin personnel page on memory alpha. You can confirm these by looking at that page or watching Star trek Beyond. Thank you for your time.CC-1990 (talk) 02:08, January 29, 2017 (UTC)

I disagree, the ship's crew of the Enterprise did use the Franklin as their lifeboat, but they were never assigned to it; it wasn't 'their' ship -- Captain MKB 02:19, January 29, 2017 (UTC)
Maybe so, but tell that to guys at memory alpha. They list them as being part of the crew because they had no other ship to use and they made it their own. Plus, it became their as part the salvage rights. Since Krall abandoned the ship, it did fall to what remained of Kirk's crew. Oh, and i took care of the image. Thank but don't take out the citation when i put it in. I thought that was enough. I hope what i did was enough.CC-1990 (talk) 02:32, January 29, 2017 (UTC)
I'm afraid its not enough -- using an image from an unaware artist on DeviantArt is NOT a valid source. The artist hasnt given us permission so that attribution is NOT sufficient -- and since the image is NOT from any STAR TREK PUBLICATION, then its not right for this website. What about that do you not understand? -- Captain MKB 02:34, January 29, 2017 (UTC)

All right. Sorry about the image. I thought since the image was on Memory Alpha, I thought it would be okay. Apparently, i was wrong this time. Sorry for the trouble, and I hope this image will be here at some point since Spock and Scotty wore it on their uniforms.CC-1990 (talk) 03:11, January 29, 2017 (UTC)

As always, we welcome submissions from artists for supplemental images through the page linked above, based on the criteria the artist themselves gives permission to use and accepts a consensus of users that say whether or not the image can be verified accurate. Hopefully, a Star Trek book will eventually feature the image--that way, we can put it on the page of the book (or game) it comes from as our source for making a fair use derivation. -- Captain MKB 03:19, January 29, 2017 (UTC)

Death categories[edit source]

FYI, I was creating them in the same format as the others I found. As simple no-content pages with a category above them.

Perhaps some time should be spent filling out the other such categories and creating an appropriate and consistent category tree before you start getting passive aggressive like you did this afternoon. -- sulfur (talk) 00:38, February 4, 2017 (UTC)

I said "please". I was asking you to take note that you were using an insufficient amount of data.
The others you found were wrong. how should i let you know that to suit your communication preferences, buddy?
I've been filling out these year categories to the best of my ability with descriptions and expanding the category tree a decade at a time. If you'd looked at the last ones that I edited, you would have been able to see that you were making an error.
To be honest, you're the one who seems to have an attitude around here, Sulfur. I'm not being 'passive aggressive' by asking you to use more info -- i'm communicating.
The last time I tried to be involved in a talk page on MA, you attacked the relevance of my comments because of the age of the discussion - but my comments were valid. You were the one de-railing the discussion
I started a communication about a sidebar error i noticed in passing and you made a big deal out of the fact that i didnt correct it, because I didnt understand what was wrong - guess how, in a passive aggressive edit summary.
Maybe you should have spent some time updating that sidebar template instead of making that passive aggressive edit summary.
Overall, there's a lot of work to be done writing docs for templates, updating the category tree, etc. Stop sniping at me over it. Grow up. -- Captain MKB 00:49, February 4, 2017 (UTC)
Community content is available under CC-BY-SA unless otherwise noted.