MediaWiki talk:Community Portal/Archive42

[[{{#sub:MediaWiki_talk:Community_Portal/Archive42|0|-0}}|«]]	Community Portal / Archive42   e	[[{{#sub:MediaWiki_talk:Community_Portal/Archive42|0|-0}}|»]]
from~August 1, 2009 to~September 31, 2009 notes:

Marvel UK issue pages

I feel that we need to make a change with how we handle Marvel UK comic issues. The UK comics split most of its stories up over multiple issues, and even reprinted some of the split up in a different way. This has led the story articles to become bloated with non-story info (covers, letter pages, other comics from the same issue, contests, ads) for multiple issues on a single story page. Also, navigating the UK comic is a pain in the ass, as many issues having two stories (one issue has three!), as well as the reprints.

Here's what I suggest we do:

• Make "hub" pages for the individual issues. These pages will cover issue-specific things. Those UK cover scans clogging up every Marvel Transformer story? They go here. As does information from that issue's letter pages, ads, TransFormations, and anything else that isn't a part of the actual stories. Also, there will be a list of what each issue contains, mostly the TOC from the issue itself. Non-Transformers backup strips (Machine Man, Action Force) should need nothing more beyond the name of the series and the title of the story unless more info is given in the cover, letters page, TransFormations, Coming Attractions or the like. The TOC will also have links to our story articles.

• Leave the story articles mostly unchanged The UK comic usually treated the stories like serials (think the early Flash Gotdon films or the original Doctor Who series), so splitting them up makes no sense. Aside from moving the issue-specific stuff to the hub pages, the only changes needed will be removing the story navigation box from the UK-original stories, removal of the UK navigation from the stories written for the US comic, and adding any needed "Reprinted in" links, and putting "Originally printed in" links on the stories written for the UK comic.

Marvel US 33 & 34 (Man of Iron!) and Action Force 24-27 (Ancient Relics!) would be handled in the same way. --FortMax 17:40, 1 August 2009 (EDT)

So you're suggesting that any issue which contained multiple discontinuous stories get a page for the issue, and a page for both stories? -Derik 22:37, 1 August 2009 (EDT)

Not exactly. Marvel UK is a special case because these multiple discontinuous stories are broken up over multiple issues. We would still have one page for Time Wars. I'll put together a sample tommorow. --FortMax 00:51, 2 August 2009 (EDT)

I have a very rough example at User:FortMax/Sandbox. The main reason I feel this needs to be done is because not only does the UK comic non only have multiple stories in each issue, these stories get spread out over multiple issues. For example, Time Wars was printed over seven issues. --FortMax 12:04, 2 August 2009 (EDT)

That makes sense... a 'landing page.' I'm tentatively in favor of it... but I'd like to see what others say. -Derik 15:40, 2 August 2009 (EDT)

I think this is a really good idea, because it enables us to show the very different format of the UK comic. Formats, in fact - something I didn't realise till I completed my collection is how very different the first 30 or so issues are from the rest. More like a robot enthusiast's magazine than a comic, and much more 'British' in feel. Unfortunately I've only got my scanned copies of issues 1-5 to work from at the moment, but I can mock something up to show you what I mean. --Tribimat 06:25, 4 August 2009 (EDT)

I've never been overly happy that a big, "blockbuster-that-changes-everything" story like Target: 2006 or The Legacy of Unicron only gets one issue, whereas, say, the issues leading up to US #75 get a page each. There's examples of serial storytelling and individual-issue focuses (eg, Prime surrendering, or the introduction of the Wreckers) in each. LiamK 09:25, 12 August 2009 (EDT)

I've done a fair bit across the UK comics lately and I'd be hugely in favour of breaking T:2006 (especially) into its component issues - just because they weren't individually named they get lumped together in one article which I think does a great disservice to the story. I'd compare it to a six-issue series like Devastation which gets six pages labelled issue 1, issue 2 and so forth, so I don't think articles called Target: 2006 issue 1, Target: 2006 issue 2 etc. would necessarily be beyond the pale. I don't know how far I'd want to take it though - splitting up stories like City of Fear or Legion of the Lost seems a bit pointless, more so The Fall and Rise of the Decepticon Empire which wasn't meant to be split in the first place. --Emvee 15:07, 2 September 2009 (EDT)

I'm in favour. I also think that a standard link to the appropriate letters page on transfans.net (similar to the way we do tfu.info for toys) wouldn't go amiss. --Emvee 15:07, 2 September 2009 (EDT)

I'm also in favour. This is the approach I took on Joepedia for the weekly Action Force comics where there are similar problems - see [1] for how it works on the individual issues. Timrollpickering 07:59, 26 September 2009 (EDT)

If you are taking the navigation off the stories, won't that make it more difficult to click through the UK continuity, from one story to the next one, continuity-wise? Then again, I'm not super familiar with the UK comics, maybe it is so complicated that that feature is basically broken as it is. But if the current story-based nav works I'd like to keep that as well as a issue-to-issue nav. - Starfield 10:39, 26 September 2009 (EDT)

Can the nav-template images be variables?

For example: The Henkei! Henkei! nav-template uses the logo from the toy packaging, since that applies to the majority of the pages the template is on. However, the Comic Bun Bun Henkei! material uses a completely different logo design, and it would be nice to be able to substitute it for just that page. This is one of several times I've wanted to be able to do that, and maybe there's a simple way to designate the image as a replaceable variable, but my markup-fu is weak. Any help is appreciated. - Jackpot 20:35, 6 September 2009 (EDT)

The answer seems to be "no"... for some reason, even with a default set in the parameter, the imagemap code refuses to parse the parameter's info.

You could always just post the entire code of the navigation template manually on that one page with the logo code swapped... --Jeysie 21:22, 6 September 2009 (EDT)

NM, I figured it out. You should be able to do this now:

{{nav-henkei|logo=(filename)|size=(number)(unit)}}

It's set up so that if the parameters aren't given, it'll just display the default, so you don't need to change the pages that do use the typical logo. --Jeysie 21:36, 6 September 2009 (EDT)

Awesooooooooome, thank you. - Jackpot 22:32, 6 September 2009 (EDT)

No problem. :) Let me know if you need any of the other navs altered, although you should be able to just copy and paste the code and change the defaults... (actually, with my idea for a code revamp, I wonder if it might be possible to just have one nav template with all variables...) --Jeysie 23:22, 6 September 2009 (EDT)

Hmm, I didn't know you were playing around with franchise-nav revisions. I actually have a grand proposal cooking up in my head for a full breadcrumb-trail nav revamp that would be applicable to basically any non-character/item/place article. The idea being that if you're at, say, an article about a comic issue, there would be a nav in the corner with links to the series, franchise, and continuity family going up in a column. And if you're at a series-article, you would be one step up in that chain, and the nav would have links to all the other series in that franchise (presented in the current style), as well as the vertically-arranged "title" links to the franchise and continuity family. Then if you're at a franchise, you get links to the other franchises in that continuity family, plus the continuity family itself. And, finally, the continuity-family articles themselves would have a nav with links to the other families. It would be a change in functionality to the effect that the cluster of little links would always be lateral, and digging down into more specific topics would require links within the articles themselves. Currently that's the case with most articles, the exception being franchises. But I think it would be incredibly awesome to have that kind of breadcrumb-trail so a reader always knows where he or she is in the multiverse at large. Plus it would help clarify how the hierarchy of families and franchises and series and so on actually works in specific cases, since that's often been a source of confusion and argument.

But I figure I should cobble together a working sample of some sort before I formally present the idea, and I think I might need some more markup-fu before that's even possible. Or I could make a facsimile in Flash or something... Anyway, at the very least, I think having the ability to swap out the logo image is actually a step towards making this idea happen. So thanks again!

- Jackpot 00:27, 7 September 2009 (EDT)

Well, my current idea was mainly just trying to simplify the existing coding a little, as well as adding some prev/next links to the continuity family section. I think the big problem with breadcrumb links is that people would have to put them in by hand, which would make filling in comic stories even more work than it already is. The "continuity family" section of the comicnav template already tends to be pretty inconsistent sometimes depending on how the person creating the page chooses to link it. (In other words, it's a nice idea, but it'd be too contingent on people filling it in correctly.) --Jeysie 00:41, 7 September 2009 (EDT)

The episode nav template uses standard strings to identify continuities (like "g1toon") and then uses look-up tables to find the proper series page link for this, the proper "human-readable" for that link and even look up how many episodes there are in the series, and create automatic prev/next links as long as you give it an episode number.

The reason we use strings instead of pagenames is 1) they're shorter, simpler, cleaner, more standardized... 2) it means that if the page moves (or we change our mind on the naming convention) we only have to change it in one place in the lookup tables, and the link changes on hundreds of pages.

What I'm saying is... you DON'T need to force users to fill in series/franchise/family. ...just fill in the SERIES. Let the template fill in the rest! (And let you manually override the lookup if you explicitly provide variables, for maximum flexability.)

But that's not a system you can throw together by trial and error; it needs proper architecture planning or it'll be a godawful mess.

I guess what I'm saying is... if we really want to rationalize and standardize the major templates on the wiki... we need a serious meta-talk about what that means, in the broadest possible scope. -Derik 01:01, 7 September 2009 (EDT)

Well, the problem is... I agree it'd be pretty easy to auto-breadcrumb the TV series. But when you start getting into things like the comics and text stories, you start running into many different miniseries and individual issues, all of which fit into different continuities. I think the continuity family is already enough info for those, provided we make sure they all point to the right ones. --Jeysie 01:48, 7 September 2009 (EDT)

That's not exactly a 'problem' as it's conventionally thought of. You could set up auto-fill-ins for the 6 most commons comics-- which would cover 70-80% of everything, but let manual values be set for the rest (or not set) to the level of detail you desire. No solution has to be 100% you know. -Derik 03:05, 7 September 2009 (EDT)

No, but for stuff like the Marvel Comics it would take just as long to copy and paste in manual info as it would to paste in the new code, after all. So it's the new pages where people would have one more thing to add in that you'd really need to worry about, if it's part of that other 20%. Whereas I agree that new TV series episodes would get to have the benefit of auto-ness.

I guess it just seems like a lot of work for little benefit, seeing as how the continuity part of the nav pretty much covers all the context necessary. Not that I don't think it's possible the ep/comicnav could use some overhaul (though what exactly I don't know; they both seem pretty complete to me), just that I don't think breadcrumbs would be an effective expenditure of time. --Jeysie 03:43, 7 September 2009 (EDT)

I'm pretty much in agreement with that last sentiment, which is one of the reasons why I'm not technically proposing my idea yet. It needs a more concrete starting point (like a mock-up design) from which all the discussion and probably argument can branch. I have my own notions about how it could be set up in a way that wouldn't involve as much work or personal discretion as Jeysie suggests, but... well, now's not the time. Maybe later. - Jackpot 01:12, 7 September 2009 (EDT)

So what needs revision? The episode templates-- fine. And the comic issues. And the franchise navigation. And a standard breadcrumbing system... but what else? -Derik 01:17, 7 September 2009 (EDT)

I've noticed on the Marvel wiki that the "writer"/"artist" text in their issue infoboxes links to Category: Writers. I'd liek us ot consider adding this. (Also, there's something about the size or spacing of their infoboxes I just like... I think we might want to take a look at 'em when we get around to recoding.)

Derik points out that in such a scenario, the breakcrumb need not be built into (for example) the episode infobox template. The more elegant solutions is something like:

 {{episode
  |breadcrumb= {{breadcrumb
                |continuity_family=[[Unicron Trilogy]]
                |franchise=[[Armada (franchise)|]]
                |series=[[Armada (cartoon)|cartoon]]
               }}
 }}

...where you'd be pass the whole breadcrumb template as a parameter to another template. That way if the breadcrumb also has to show up in other templates... there's a standard code, standard styling, etc. Cleaner simpler code, easier to maintain, more universal, easier to work with, less percussive maintenence, etc.

That's not a solution to everything though, because we've got two prev/next/series navs for comics, and some of the Marvel issues could use four or more. Stacking 4 of those things is retarded, and pointless. We need a more rational means of addressing republished stuff. I went to look up when a certain Marvel UK issue was published the other day and we didn't have the information. ...because it was published in the US first, and our template only has one "pub date" field. -Derik 00:52, 7 September 2009 (EDT)

Sankyuu! Henkei needs a bit more love. :D --Lonegamer78 22:59, 6 September 2009 (EDT)

CSS rationalization

While discussing rewriting our HTML... we should also probably discuss CSS rationalization.

Right now our code has absolutely no regard for what the page looks like printed. (Those messageboxes at the top of pages probably don't need to be there when printed.) Do we want our links to have addresses when printed? For example, I believe CSS could make this link print like this link ("Optimue Prime (G1)") or like this link ( http://tfwiki.net/wiki/Optimus_Prime_(G1) ) or like this link ( tfwiki.net/wiki/Optimus_Prime_(G1) ), any of which would be 'friendlier' for printed-out versions.

Of course, if this was applied to excessively PotHole'd articles, the text it might become almost unreadable. Perhaps smaller or faded text would make tooting my own horn User:Derik less obtrusive when printed. Regardless what's decided for article text, I strongly believe that storylinks should have the disambig visible when printing. King of the Hill (Armada episode)

Printing, I grant you, is a fairly minor concern. But what about syndication? A few people are beginning to dynamically syndicate our content. Botch went to some trouble to remove our messageboxes and various other elements-- he just wanted the guts of the article. If we'd attached standard classes to templates (ones that have no CSS associated with them as far as TFWiki is concerned) he could have just syndicated the page as-is and hidden those elements with a few lines of CSS! (If nothing else, the storylinks need a class marking them... that seems like something that many would like to hide.)

Live page syndication is clumsy. (And I need to yell at Botch, because IIRC he's doing his in a terrible way, from our server's perspective.) But if we encourage it, it's another tool in our promotional quiver! (There was a PHP script I was working on the other month that actually has some fairly good TFWiki-specific syndication. If that was polished and made easy to use, it could have some legs.)

Soto-voice snark aside-- we really need classed like .noPrint and .printOnly. And when we redo our episode/issue infoboxes... the tables should be tested to they print nicely, and we should publish the CSS people can use to turn various 'bits off. (Or a 'general guide to site CSS', if only for our OWN use.)

How about this...? We've been moving a LOT of our code out of HTML and into CSS. One of the effects of this is that simply syndicating the "rendered" page... a lot of the HTML layouts are gobbeltygook. Should we have a consideration for syndicators who don't include our CSS file? Maybe templates we know are unlikely to be wanted can be flagged with a .noSyndicate class, making it easy to hide them? Or we should have a Syndicate.css file that includes the bare-minimum CSS code for templates to lay out right? Should some templates ({{quote}}, for instance) be rewritten so that they will render in a readable (if not ideal) fashion even if no css is included? Is there a "scale" these questions all fall on... a sort of "how important is this element to the content of the page?" spectum, where at the low end we don't care and tell people to hide it, at the middle we provide identifying tags so they can be hidden, or a truncated CSS file so they render nice, and at the high end we write the HTML so the element will always be readable even without CSS to make it pretty? (That last one means code that's less contextual. Where do our priorities lie?)

These are philosophical issues. None are especially high priority, but the "cost" of addressing them is relatively tiny, so if we're doing some thorough redesigning... it'd be a good idea.

Some elements we have (like main pages) sometimes get quite "big" (laid out in a fashion that accepts a minimum of 500+ pixels wide.) Is it worth adding a .bigElement class or a .mobile class so that those elements can have code written in a mobile device CSS file that reduces their size? Is this even a concern for new mobile devices, which scale easily? How to Kindles handle them? Do e-readers support javascript? What about tablets and wireless internet devices?

More and more, content on the internet is going to be viewed by something other than what we normally think of as a "web browser," and because web-developers spend all their time in web browsers they often neglect these outlets. We do not have to bend over backward to accommodate these technologies... if problems do arise, they will probably be the 90/10 sort; 90% of the solution/benefit can be accomplished with just 10% of the effort.
Example: When a certain news site rolled out their home page redesign several years ago, it mis-rendered on some versions of Safari-- pushing the story content below the left navigation bar. In short... the page appeared blank. This problem remained unfixed for almost a year-- it was caused by the nav rendering just one pixel too wide, pushing a floated layout down. This remained unfixed for almost a year. I'm sure that this bug only affected maybe 1% of site visitors. But after a year of blank pages... that 1% also probably stopped visiting. 1% over the course of a year is a lot of lost pageviews, it's like having your site be down for 3 days.

Anyway... that's my rant. There's no solutions there... just ideas/concerns/meta.

If other people are interested in discussing this sort of thing... may I suggest we create a dumping ground at "Transformers Wiki talk:Community Portal/Quantum Cycle Upgrade" where we can gather thoughts/issues about long-term infrastructure upgrades? -Derik 20:35, 8 September 2009 (EDT)

Picking up on just one thing for now:

Those messageboxes at the top of pages probably don't need to be there when printed

Thing about that is that they DO contain information you might want when printed that isn't contained elsewhere on a page (the writer of a story, for instance).

I could certainly see a certain degree of stripping down the messageboxen for printing as a good idea (take a look at http://tfwiki.net/w2/index.php?title=End_of_the_Road!_(US)&printable=yes - it's not even just the {{comicstory}} [which has become a bad name for that template as its' uses have multiplied...] box - the {{featuredcharacters}} box further down could do with being stripped for print. And I'm not sure the {{disambig2}} needs to be visible at all.), but I'm not sure about hiding them by default. - SanityOrMadness 22:15, 8 September 2009 (EDT)

I agree about stripping those kinds of things down... but when I said "messageboxes" I meant things like "picsneeded"; those have an enormous footprint, and they print. Their entire purpose is to alert editors of page deficiencies.... but people reading print-outs aren't editing those the pages, it's pointless. -Derik 22:32, 8 September 2009 (EDT)

Ah. I wasn't thinking of those, just {{comicstory}} and {{episode}}. Yeah, removing {{picsneeded}} and its ilk would make sense. - SanityOrMadness 10:20, 9 September 2009 (EDT)

Jeysie's infobox

Prisoner of War!

Is he strong? Listen, Bud, he made Megatron go thud.

Marvel Comics
Cover date	January 1985
Street date	October 2, 1984
Marvel Comics continuity

«	The Transformers (US) #3	»
«	The Transformers (US) #5–6	»

Writer	Jim Salicrup
Penciler	Frank Springer
Inker	Kim DeMulder, Mike Esposito
Colorist	Nelson Yomtov
Letterers	Janice Chiang & Others
Editor	Bob Budiansky

I remember doing this rough tweak idea based on Derik's comment that he liked the Marvel wiki's infobox.

Not very much of a tweak, admittedly, as I actually like our current setup for the most part. --Jeysie 21:46, 17 September 2009 (EDT)

Okay, some things:

1. {{comicstory}} is used for a LOT more than, well, comic stories, to the point that the template name is bad. But unless you want to go and find/change all of those uses (and they're pretty diverse, I don't think you could bot them), it's pretty much impossible to change the broad layout of the template.
2. Moving the back/forward navigation from the top (where it's easily accessible) to a point where it would be below the fold on netbooks, e-readers and less up to date PCs? Are you seriously suggesting that?!

Seriously, I don't "get" the ideas behind the layout here at all. - SanityOrMadness 22:00, 17 September 2009 (EDT)

They all use pretty much the same setup, actually, if you look at them. I can't think of any usage on text stories and books that is seriously different offhand... they have different credit/info types, yes, but they go visually in the same places. I would probably put things like page count and ISBN in the "publisher" box.

And like I said, I was emulating the Marvel wiki infobox, which actually has the navigation at the bottom. But essentially... I wanted to get the title up top, and make a "publisher" section, and a "credits" section... and the navigation made a good visual divider between the last two sections. I agree it's kind of weird, though... I could see moving it back up to the top under the title and just having a thick border in its place between the bottom two sections.

Like I said, it's pretty minor stuff... I think our infobox is just about perfect as-is, really. --Jeysie 22:10, 17 September 2009 (EDT)

It's not just stories. The Hasbro Q&A pages use it. The Collectors' Club Magazine pages use it, along with other non-story content from magazines, etc. What's the "title" in those instances?

Moreover, why move the title to the top at all? The title is already written in big letters at the top of the page on a single-story page, or at the top of the section on multi-story pages. Below the cover is a good place for it.

And the cover date & street date are hanging in no-man's land here, with no association with any relevant information - it looks like Marvel Comics had a street date of Oct 2, 1984.- SanityOrMadness 22:37, 17 September 2009 (EDT)

We'd leave the title off. You know, just like we do for miniseries already? Sheesh, I love it when people complain about something "new" without realizing the wiki already does it.</sarcasm>

That said, if we move the navigation back to the top, we could move the title back under the picture again. I guess it just seems to me like it's the "first" bit of info about a book, and you could use your comment as an argument towards leaving out the title bit entirely anyway.

I like my publisher idea, though... it separates the meta-info about the book from the credits. And the publisher's name makes the most logical sense to use in a section heading. Like you said, the title's at the top, so I have a hard time thinking anyone's going to think the street date has to do with the publisher's name instead of the issue the article's about. I like to assume basic intelligence on the part of the reader. --Jeysie 06:53, 18 September 2009 (EDT)

Our existing comicstory template is already deficient in presenting multi-part stories: I went to look up when Target: 2006 was published... and discovered it had no date. And why should it? The article spans several issues, with no single correct date to give!

(I happen to think presenting the UK stories in 1 article like this is stupid... but I lost that fight a long time ago, so the template might as well address it well.) -23:44, 17 September 2009 (EDT)

Er. What's wrong with just listing all the dates in the date section, or a range of dates? We already do that for Man of Iron, IIRC. I don't see what the big deal is there. It's a date field... no reason it can't have more than one date in it.

The only accommodation I might make is adding extra "story 2" credits to make credits for multiple stories a bit tidier, but that's less a major change and more just a tweak. --Jeysie 06:53, 18 September 2009 (EDT)

Counter-proposal

« The Transformers (US) #3 » « The Transformers (UK) #5-6 »
Is he strong? Listen, bud, he made Megatron go thud.
Prisoner of War!
Writer	Jim Salicrup
Penciler	Frank Springer
Inker	Kim DeMulder, Mike Esposito
Colorist	Nelson Yomtov
Letterers	Janice Chiang & Others
Editor	Bob Budiansky
Continuity	Marvel Comics continuity
US publication
Publisher	Marvel Comics
Release date	October 2, 1984
Cover date	January 1985
Cover price	75c (US); UK: 50p; Can: $1.00
UK publication
Publisher	Marvel UK
Cover dates	17th Nov. - 30th Nov. 1984 1st Dec. - 14th Dec. 1984
Cover price	25p (each)

Keeps the basic layout of the current {{comicstory}} (including keeping the issue numbers rather than the title at the top, which I consider key), but separates the meta-info from the story info (which is headed by the title, as it should be. I would prefer to use separate infoboxen for separate stories on the same page, but you could have separate subsections for separate stories, each headed by the title, if it was thought desirable). - SanityOrMadness 08:55, 18 September 2009 (EDT)

I definitely agree with San here that the navigation info needs to be at the top. It's just counter-intuitive otherwise.--Rosicrucian^Talk 12:15, 18 September 2009 (EDT)

I like the idea of separate credit sections in the same infobox for separate stories in a single issue, with the titles of each story as the header; I was going to suggest that myself. We could always do a "if/then" clause so the extra section only shows up if one of the pertinent parameters is used. (I think stacking entire infoboxes might get a bit too cluttered, plus it's nice to see a whole issue's overview right at the top, but I'm willing to see a mockup if someone thinks that might work better.)

I find myself wondering if continuity should be in the navigation somehow, as then we could potentially tag it as a separate prev/next series if need be. I know that I was reading the Axiom Nexus text stories, for instance, and there seems to be a lack of a good way to show how some stories relate to each other in terms of reading order when the actual publication order in the franchise it's released under has stuff in between. (The Shattered Glass stories at least had the ready excuse of being stuck under that franchise for the navigation...) --Jeysie 18:01, 18 September 2009 (EDT)

I like the idea of separate credit sections in the same infobox for separate stories in a single issue, with the titles of each story as the header; I was going to suggest that myself.

Betcha weren't :p [Seriously, with the title up top out of the way, you couldn't do anything of the sort]

Anyhoo, the main reason I'm a bit reluctant to put multiple stories together in such a fashion is that it would seem to divorce the latter stories from the infobox with their credits. If they end up so close together that the infoboxen actually stack and push the info away from the story in question, put them together in one infobox by all means. - SanityOrMadness 20:39, 18 September 2009 (EDT)

Betcha I was. Because hey, you could put the title of the issue at the top (or not, if the issue doesn't actually have a title), and the title of the individual stories in the credit sections. It's funny how that works. :D

And, like I said, if someone can do a mockup of dual infoboxes that doesn't look silly, I could buy it. As it is, I just think it'd be weird basically having two separate pages on one page. I like the idea of the infobox itself being devoted to the comic issue as a whole. --Jeysie 21:01, 18 September 2009 (EDT)

I am uncomfortable with the "dual navigation" system simply because... some of these stories have now been published 3 or 4 times. No previous/next for them? They don't get credits or publication dates? What if I want to know when IDW published an issue of "Prey," how many parts of that story they published (IDW doubled up content from 2 UK issues) or anything else important?

We're just tossing aside republishing info because our template doesn't support it. Same problem with the dates being left off multi-part stories... if it's nto clear how to add the information, the information becomes lost. -Derik 19:40, 18 September 2009 (EDT)

Isn't the point of the '"dual-navigation" system' to record contemporaneous republication? [Marvel US in Marvel UK/Marvel G2 in Fleetway G2/IDW Beast Wars & AHM in Titan TF (...actually we don't currently do that last set, although we should)/etc]. That is, we wouldn't record an IDW "Best of the UK" as such even if it was the first such reprinting, because it was twenty years later?

If you try to fit four sets of data in one poor infobox, it would become unmanageably and unreadably large. - SanityOrMadness 20:39, 18 September 2009 (EDT)

I don't disagree.

Speaking of... right now our navigation at the top of such boxes is (in theory) publication order... but with a weird mix-in of reading order too.

Should it become one or the other? And which is of primary importance? -Derik 02:32, 21 September 2009 (EDT)

...Didn't I more or less say that a few comments above? I think maybe we should have both... the main navigation(s) being publication order, then a third "continuity" section with a link to the issue's continuity and the prev/next reflecting proper reading order. --Jeysie 06:12, 21 September 2009 (EDT)

The thing about THAT idea is that the issue doesn't necessarily reflect the continuity if you want one infobox per page - take the AHM "coda" issues, or the Animated Arrival issues as examples, since they have multiple stories on one page. There's no one continuity place for those issues, since they're anthologies which take place out of order. You'd have to do the continuity nav at the story level, rather than the issue level. - SanityOrMadness 13:52, 21 September 2009 (EDT)

I've started work on fleshing out changes at "Template:Comicstory beta" (relevant: "Template:Comicstory beta/Example"), but there's one major bit that I'm not sure how to deal with - Editors. Sometimes, editors work on the story level (to the point you could have separate editorial teams working on the different stories in the same issue, although I'm not aware of any TF examples off the top of my head), but sometimes they work at the issue level, overseeing a load of non-story content in addition to any stories in the issue (the latter's more common in the UK - US comics tend to have a letters page at most for non-story content). And so I'm having trouble placing where the various editorial credits should go - I've bunged them under a separate "Editorial" header temporarily, but I'm not happy with that - I want them under the story, or under the Publication info... - SanityOrMadness 14:00, 21 September 2009 (EDT)

Images for deletion

Interrobang has marked a pile of unused images for deletion. Some of them, I suspect, are unused because of the Bookworm crash, like the pictures of Lipoles. I've made a start on some of them, but if anyone wants to pitch in and fix up some of the images we should keep, be my guest! --abates 07:59, 12 September 2009 (EDT)

True, part of them are, um, "victims"(sort of) of the Bookworm crash, such as Image:Convoy BT.jpg and several others. I think those pictures should be hold and got checked/salvage for a while before being deleted. I've check the Category:To be deleted, but I can only recognize a few. People can check their watch list or Category:To be deleted to help ID those pictures they(users) know where they(pictures) belong to. --TX55^TALK 08:26, 12 September 2009 (EDT)

I've noticed that several of them aren't "unused" per se--they're not used as images anywhere, but they're still wikilinked to. For example, Image:Fat guard.JPG says "There are no pages that link to this file", but if you check "What links here", you'll see that Capture the Cube does in fact link to it. So before anyone deletes any images, I suggest checking if anything is wikilinking to them first. --Apoc 08:42, 12 September 2009 (EDT)

Yeah, I noticed a while back that the section under the image that lists pages which link to it only includes pages where the image is actually embedded. Plus some images are used in the site skin or CSS files, like the logos Derik set up to appear after links to certain sites. --abates 18:30, 12 September 2009 (EDT)

Are we intending to resurrect the community-nav template? The images used on it were among those tagged for deletion... --abates 21:11, 14 September 2009 (EDT)

I'll take that as a no. And down to 150 pictures now. Again, if anyone wants to take a look through Category:To be deleted in case anything they recognise where the images are supposed to go, please do! --abates 08:16, 16 September 2009 (EDT)

Down to 76 images. Most of those left were uploaded during the crash period, so any information about where they were intended to go is lost. Some of them, like Mugheads.jpg, are from lost talk pages. Some, like Tflive_logo_stacked.jpg, might be still useful for something. The two covers for The Ark II probably should be on the appropriate page. Some, like Mort-icons.png and Tf gf 002 back.jpg, I don't have the foggiest what they were intended for... --abates 23:23, 19 September 2009 (EDT)

This Day in Transformers History

We should try to turn the This Day in Transformers History into an exportable module, like our Go-Boxes. It'll help our SEO by encouraging links back to us as well as give us another source of dynamically-generated deep links to help users discover our content. We have info for all 366 days, we should exploit it. --Jimsorenson 15:46, 16 September 2009 (EDT)

Speaking of history, today is the 25th anniversary of the premiere of the G1 cartoon right? Want to mention that anywhere? --SuzyP 18:35, 17 September 2009 (EDT)

Guess what.....

I've just decided to check our statistics for no apparent reason, and we have 9,588 "legitimate content pages", whatever that means. So then I randomly decided to check out the Wikia page (which, by the way, has had the same Featured Article for God-knows-how-long), and guess what?

7,209 pages. We're beating them out by 2,349 pages, which is quite a lot. Who thinks we can hit 10,000 soon? ---Blackout- 15:15, 18 September 2009 (EDT)

No problem. ...though it's about quality, not quantity. ;) -- Silvery 15:24, 18 September 2009 (EDT)

I can tell you the quality of their articles as well.

Nonexistent. ---Blackout- 15:29, 18 September 2009 (EDT)

Oh, you're too harsh. Anyways, I know this wiki's the best 'cause I checked all TF wikis before I've decided to join... -- Silvery 15:45, 18 September 2009 (EDT)

I can personally testify, we delete articles that aren't up to snuff and don't look like they're going to be.--Rosicrucian^Talk 15:36, 18 September 2009 (EDT)

Now I'm interest in knowing how many articles the original wiki had back before the big split. - Cattleprod 15:57, 18 September 2009 (EDT)

Somewhere around 6890 or so. I should note that our current total is artificially inflated by about 75 due to the "ghost" pages causing the macron issue, so our total's nearer 9513 or so. --abates 20:36, 18 September 2009 (EDT)

@Silvery: I'm not being that harsh. Here's some examples. And I know, this will give them slightly more traffic.

Their ROTF Soundwave page.

Their All Hail Megatron page. Count the red links. ---Blackout- 02:53, 19 September 2009 (EDT)

You're too harsh in a "hit 'em when they're down" sense. It's called "irony". :P -- Silvery 04:11, 19 September 2009 (EDT)

I get a bit of personal pride whenever I compare our Shattered Glass section to theirs. --Jeysie 06:11, 19 September 2009 (EDT)

I weep whenever i read the Animated articles...Sentinel Prime's page is the best example.--Sunjumper 15:00, 22 September 2009 (EDT)

I just removed an {ongoing} tag from their Animated Perceptor's page. What the hell? ---Blackout- 15:08, 22 September 2009 (EDT)

Also, for some reason, someone back there REALLY liked deleting my stuff. They liked it so much in fact, that my contributions page has been wiped clean. ---Blackout- 07:23, 23 September 2009 (EDT)

Also, Monaco now screws up page layouts when you move mainpics to where they're meant to be! (That's what it does on another wiki I happen to be an admin on, anyway.) Woo-freakin'-hoo. ---Blackout- 07:37, 23 September 2009 (EDT)

Wikia, seriously?

Look at the image, and be confused as to why anyone would want to see the ads? ---Blackout- 13:36, 25 September 2009 (EDT)

That option was actually put in due to user feedback. It's so they can view pages with the ads still in place and modify the layout to not look like ass.--Rosicrucian^Talk 14:17, 25 September 2009 (EDT)

I just checked their Shattered Glass (comic) page, and hell, they've not even added Soundwave, Rumble, Long Haul...I also feel a bit of pride since I uploaded the images and started writing most of those :) --Emvee 20:00, 25 September 2009 (EDT)

Reading Order

When the wiki began in 2006, reading order was a clear and obvious thing. It was straight publication order-- and even if broken up into minis like Dreamwave did, they followwed a logical "volume" order.

...IDW is nowwhere near that clean. Characters literally leave one aeries, appear in another, bunches of stories are interwoven. I think we should consider creating an IDW "reading order" page, simply because reading order is not the same as publication order, is not the same as chronological order. -Derik 04:41, 19 September 2009 (EDT)

User:Jackpot/Sandbox/IDW-G1 recommended reading order :3 --Jeysie 06:10, 19 September 2009 (EDT)

OK.....weird.

Did someone *looks at Derik* break the block log, or is it meant to only show blocks up to March this year? ---Blackout- 13:14, 22 September 2009 (EDT)

Also, how didn't I get an edit conflict when Jimsorenson and I were trying to delete the same duplicate section at the same time?

Derik, please don't break the wiki. ---Blackout- 13:16, 22 September 2009 (EDT)

Think back to what happened in March.--Rosicrucian^Talk 13:23, 22 September 2009 (EDT)

Oh yeah.

STUPID BOOKWORM! *scream is heard across the world* ---Blackout- 13:27, 22 September 2009 (EDT)

Yeah, not everything is Derik's fault. On the other hand, many awesome improvements to the site are.--Rosicrucian^Talk 13:56, 22 September 2009 (EDT)

I may have been reading a bit too much Community Portal Archives recently. ---Blackout- 14:23, 22 September 2009 (EDT)

Derik breaking things is generally content, template, or presentational related-- despite all the joking, I have only ever broken the core of the site itself once. (And even then, it was for less than 10 minutes, Siph was nice enough to delete the page that was giving the site's database epileptic fits.)

I'm actually rather proud of that one-- insofar that it was supposed to be completely impossible, but I somehow managed to do it! (This was back on Bookworm, I suspect their server bog-down issues contributed to making my impossible feat happen.)

When I break stuff it tends to be more localized or cosmetic. -Derik 14:46, 22 September 2009 (EDT)

Speaking of local/cosmetic issues, the automatic archive listing on this page does not appear to want to display archive 39.--Rosicrucian^Talk 14:48, 22 September 2009 (EDT)

The one that doesn't exist yet?

Also, This is incredibly funny. ---Blackout- 15:04, 22 September 2009 (EDT)

Oh, it most definitely exists. Click on archive 38, then use the archive navigation at the top to go to the next archive. 39 is already populated.--Rosicrucian^Talk 15:09, 22 September 2009 (EDT)

Vote to move that page to "Things that don't exist". ---Blackout- 15:19, 22 September 2009 (EDT)

That might be because the nav you're referring to isn't automatic. Just the ones in the individual archives. - —The preceding unsigned comment was added by Derik (talk • contribs) - who thought there actually were five lights in that TNG ep :p. 16:03, 22 September 2009 (EDT)

Something I just came up with.....

Because I absolutely loathe our current {{caption bastard}} tag, I came up with this.

---Blackout- 12:03, 24 September 2009 (EDT)

Tough. --M Sipher 12:51, 24 September 2009 (EDT)

You're pretty obsessed with caption edits.Dead Metal 12:57, 24 September 2009 (EDT)

I was very bored that day. ---Blackout- 01:50, 25 September 2009 (EDT)

Just a minor layout change. :D --TX55^TALK 09:35, 25 September 2009 (EDT)

Well it definitely looks better now. ---Blackout- 12:39, 25 September 2009 (EDT)

Keep an Eagle Eye (ROTF)

I notice that the first DVD-rips of ROTF have begun to drop-- 3 weeks before the movie is out on DVD. Be wary of a flurry of new screencaps appearing. -Derik 19:20, 26 September 2009 (EDT)

TF Wiki link forum signatures = spam = loss of google ranking?

Somebody on a Macross forum reported that posting links to their website via forum signatures counted as spam, which took a major hit in their site's google ranking, and it was the same for Digg linking. Since I'm not that net savvy, I'm waiting for the guy to provide more info about this, but we should probably discuss it here anyway: To our more tech and net-experienced members - does linking to our wiki via our forum signatures (as suggested and encouraged by our staff during the move last year) actually count as spam in Google's eyes and hurt our search ranking? --FFN 16:04, 27 September 2009 (EDT)

No. The worst that Google would do would be to ignore the links for the purposes of ranking. If Google did demote sites based on forum signatures, people would start putting links to their competitor's sites in their signatures. --abates 16:23, 27 September 2009 (EDT)