Memory Alpha
Memory Alpha
m (followup :))
Line 260: Line 260:
   
 
:::One huge problem with having an alternate "article" with the description is that it will not be updated when the File changes. Ever. And there's no good, clean way to tie 'em together. It also adds another layer of complication that is just not needed. -- [[User:Sulfur|sulfur]] 12:36, February 11, 2010 (UTC)
 
:::One huge problem with having an alternate "article" with the description is that it will not be updated when the File changes. Ever. And there's no good, clean way to tie 'em together. It also adds another layer of complication that is just not needed. -- [[User:Sulfur|sulfur]] 12:36, February 11, 2010 (UTC)
  +
  +
:::To make that clear in fewer words: completely and utterly unmaintainable. -- [[User:Sulfur|sulfur]] 12:49, February 11, 2010 (UTC)
   
 
== Image order ==
 
== Image order ==

Revision as of 12:49, 11 February 2010

Forums ForumsTen Forward → Sidebar templates (replywatch)

Overview

The following sections discuss a possible standardization of sidebar templates across all of our articles, starting with the initial discussion. This overview has been added to summarize the consensus so far:

  • "Common" parameters, such as a pair of image and caption, should have the same name across all templates.
  • Images in sidebars should generally not have a visible caption. Instead, the choice of image(s) representing the subject of the article should render any visible caption unnecessary.
  • However, the caption parameter is still useful, as it acts as an image description (for example for the visually impaired). Corollary: the caption should properly describe the image being used.

Further details, including the possibility of exceptions to the above general rules, are still being discussed below. Please join the discussion, if you like.

Initial discussion

I know I'm going to step on toes with that, but whatever: we need to deal with what our various sidebar templates have become, and find a common direction in which we want to go from here.

When first created, sidebar templates were meant to display the common information at a glance. "Common" meaning information that is available for a great majority of articles that would later use the sidebar, not "any information that at least one article of that type might contain". This is what sidebars have become by now - one of the worst offenders (not sure if the worst) is probably {{sidebar character}}, which has parameters for weight, blood type and even captains woman (useable on exactly three articles!) on top of spouse.

Besides their content, there are many other problems that I found when checking the various templates during the last days: tons of different parameter names serving the same function (image, image1, image-top, image-logo, logo, ...), sometimes non-matching parameter names (caption3 to serve as the caption of image2), very recently a new "formatting" parameter added to one of the templates ([1], which I think should not happen, because we're actually having templates so that an editor using them doesn't have to concern himself with formatting decisions), some sidebars using a red title bar at the top while others don't, some sidebars having visible image captions while others don't, some documentation page apparently not having been updated with the last changes to the template itself, and last but not least, several different coding styles internally, all trying to achieve the same, making it very difficult to just jump from one template to another for comparison.

Now, this is just a rant for now, but maybe I can attract some other opinions already. What do you think should be contained in a sidebar, what layout do you prefer, etc. - anyway, I'm going to suggest my preferred style later. -- Cid Highwind 13:39, February 5, 2010 (UTC)

I think that the sidebars dealing with "Real world" stuff (novels, comics, bio books, ref books, and DVDs) are all pretty good and fairly consistent across the board. DarkHorizon and I spent a fair bit of time putting those together (all at the same time) and made a point of ensuring that they were all in line with each other (ie, similar variable names, formats, etc).
Of course, I think that Cid's really referring to the "in universe" template stuff, but I wanted to make a point of separating the two from each other. -- sulfur 14:10, February 5, 2010 (UTC)
I think that the information in the sidebar should not make reading the article unneccesary- which the character template example seems to do. They should only have "name, rank, serial number" type information- the bare minimum common, basic information necessary to establish an introduction. --31dot 14:19, February 5, 2010 (UTC)

(Re: sulfur) Yep - I haven't made that distinction while checking the various templates, but now that you mention it, I can only agree: I can't remember seeing any of the problems mentioned above in a "realworld sidebar". -- Cid Highwind 14:20, February 5, 2010 (UTC)

I agree with that there is a problem with the sidebar images. Sidebar images should not replace regular article images, and certainly the gallery section doesn't need to be in the sidebar. With such long sidebars, the regular images in the article are all being pushed down. On the other hand, I don't agree so much about the data parameters, although some of them may be getting a little fat. If it takes a paragraph to explain the value in the sidebar, maybe it should just link to a section in the article that explains it fully. --bp 21:14, February 5, 2010 (UTC)
Since I made the switch change referenced above, I should at least explain it. See United Federation of Planets, Romulan Star Empire, and Empire, for what that change did. I hold the exact opposite view Cid has, in that these extra parameters aren't a problem, since at what point in a article are we going to list someones weight, or blood type? Is it going to be easy to find without reading the whole article? MA is used as a resourse for authors, and not just of the fanon kind, so the sidebar should contain every detail that an author would need short of reading the article. Let's be honest, guy's never going to stop hearing from fans if he gets someone's blood type wrong.
I fully agree with standardizing the image and caption calls, but once again I fail to see how letting someone make a choice is the end of the world here. These templates are great at standardizing the look of MA while reducing the amount of code on each page, and that's all well and good, but at what point did it become about the user base is too stupid to be be trusted to make a choice? - Archduk3 21:38, February 5, 2010 (UTC)
Also, the current {{Sidebar species}} will not have that many images when it's finalized, so no need to fear sidebars with six images. :) - Archduk3 21:46, February 5, 2010 (UTC)
While the sidebars may have been created with the purpose of being used on the most 'common' articles, they have since then changed to become all inclusive, so there aren't any articles excluded. Turning back the clock on these would serve as much purpose as turning back the clock on MA altogether. Much like the subject we are covering, we should be striving to be more inclusive instead of more exclusive. - Archduk3 22:31, February 5, 2010 (UTC)

Picking just one single "extra parameter" and asking "what harm does it do" is somewhat misrepresenting the underlying issue. The problem is not one little factoid that we simply don't know where else to address - it's one, and another, and some more, and last but not least yet another one on top of it - and all of a sudden, the sidebar has become longer than the article it should accompany (instead of replace). Similarly, claiming that "the authors" need the sidebar as a source for research can't be the whole truth. If, for example, blood type was mentioned somewhere in the article (where, by the way, it would still belong even if it is contained in the article - sidebar information should never replace information in the article, but summarize the most important facts from the article), a simple text search would bring it up. Claiming that "the authors" will just read the summary (=sidebar), and not the whole thing, if that character and his blood type are central to the story they write, paints them as totally lazy - something I think couldn't be farther from the truth. -- Cid Highwind 12:15, February 7, 2010 (UTC)

I would say that the point that these extra parameters are making the sidebars too long is also somewhat misrepresenting, as I don't know of a single page that has a sidebar that's longer than the article because these. Worf has the longest sidebar I know of, and it doesn't use any of the options you mentioned, except spouse. I couldn't even tell you what pages use 'height' and 'weight', though I have to assume that at least one does, but I'm willing to bet 50 MA points that the sidebar won't be longer than the article there because of that information. - Archduk3 20:06, February 7, 2010 (UTC)
Height and weight are used on Roberta Lincoln and Harcourt Mudd at least. Neither has an overly-large sidebar.– Cleanse ( talk | contribs ) 00:30, February 8, 2010 (UTC)
Out of curiosity, what is the longest sidebar? --bp 05:19, February 8, 2010 (UTC)
Based on text or images? Out of the in-universe articles, I would say Worf takes the cake for text, though Alexander Rozhenko comes close with images. Real world would be any of the {{Sidebar series}}. - Archduk3 05:26, February 8, 2010 (UTC)
Worf's massive TOC helps with the long sidebar, but obviously that character has been thoroughly explored in Trek. ;) --bp 05:40, February 8, 2010 (UTC)

Parameter usage

Here is a thing that might be relevant: User:DYKBot/sidebar template parameter usage. --bp 10:09, February 8, 2010 (UTC)

I fixed the "broken" entries in your list bp. Just fyi. -- sulfur 11:57, February 8, 2010 (UTC)

Good Job. --bp 12:20, February 8, 2010 (UTC)

Question -- there are some "errors" at the end. What were those errors precisely? -- sulfur 15:44, February 8, 2010 (UTC)
Also, am I blind or is the "captains_woman" option mentioned above not showing on the 'character' sidebar info? - Archduk3 23:25, February 8, 2010 (UTC)

"Errors" were stray { and } that were screwing up the parsing, look at my last edit to those pages. captains_woman is omitted because it consists entirely of a template call, that is a bug. Thanks for pointing it out. It will be included next time. --bp 23:39, February 8, 2010 (UTC) ... Fixed and updated. --bp 00:08, February 9, 2010 (UTC)

Parameter reform idea

Hey kids! Here's bp with a crazy idea that i've been talking about with Cid in IRC, and he hates it so I must go forward with it...

Consider these three ways one might add data to a sidebar template:

Way 1

| mother = [[mommy]]
| father = [[pappy]]
| siblings = [[sissy]] (sister) <br /> [[brohem]] (brother)

Way 2

| mother = [[mommy]]
| father = [[pappy]]
| sibling1 = [[sissy]] 
| siblingtype1 = sister
| sibling2 = [[brohem]]
| siblingtype2 = brother

Way 3

| family = 
{{rel | mother  | [[mommy]] }}
{{rel | father  | [[pappy]] }}
{{rel | brother | [[brohem]] }}
{{rel | sister  | [[sissy]] }}

So, I propose that we look into doing it more of the third way. There is alot of way 1, which I hate because the data has HTML mixed in which looks crappy and is harder to maintain, and it can't be parsed in a meaningful way. The second way is by far the worst, and it limits us to the number of parameters that have been added to the template. Way 3 preserves all the semantic information, is easy to parse, and is infinitely extensible without changing the core template.

Here are some other examples where this would be good:

In {{sidebar episode}} we could replace arc1title, arc1prev, arc1next... etc with:

| arcs =
{{arc|<title>|<prev>|<next>}}
{{arc|<title>|<prev>|<next>}}
{{arc|<title>|<prev>|<next>}}

And consider very generic things like "status" that appear in multiple sidebars, we could have a {{status}} template for a log of status changes. For example in {{sidebar starship}} we have status, datestatus that only allows for the most recent status.

| history =
{{status| Commissioned   |2356}}
{{status| Lost           |2359}}
{{status| Recovered      |2400}}
{{status| Decommissioned |2404}}

And status could be used for other things like rank promotions for people. It works any sidebar where something may change status!

Anyway, I think there is some really good benefits to doing things like this. I think it will clean up the clutter of some of the sidebars, and actually reduce the code that goes into them both in the templates themselves and in the template calls. --bp 12:19, February 8, 2010 (UTC)

Well, if Cid hates it I all for it. :)
But seriously, I do like the idea of unrestricting parts of the templates, as long as it is conceivably easier to use afterwards. At the very least the third family suggestion is a vast improvement over the current system, and I'm sure that Worf would agree. - Archduk3 13:04, February 8, 2010 (UTC)

I think the sub-templates should be as generic as possible to get the most usage. Like status is {{status|<newstatus>|<year>}}, maybe instead of {{f}} it should be {{rel|<type>|<what>}}. That could be used for many more relationships. In a person sidebar though, it would still be "| family = <list of rel>.". I've updated my original post slightly to reflect that. --bp 13:15, February 8, 2010 (UTC)

See, and this is exactly why I think this idea is the total opposite of what we should do. Consider this:
| family = 
{{rel | dog        | [[Porthos]] }}
{{rel | neighbour  | [[Spock]]   }}
{{rel | fav. food  | [[Noodles]] }}
There is no longer any built-in way to check that whatever is added to the template makes sense at least on the semantic level or, even if it is "family", that it is a relationship we think needs to be noted on the sidebar. Any uniformity is thrown out, and it is just a small additional step to the following nonsense:
sidebar generic
| attribute1 =  | value1 =
| attribute2 =  | value2 =
| attribute3 =  | value3 =
...
Also, consider this:
| relationships =
{{rel | girlfriend | [[1st GF]]          }}
{{rel | girlfriend | [[last (known) GF]] }}
which is basically the same as the "status" suggestion from above, just applied to a different attribute. Now, I think that having a listing such as this implies some level of "completeness" that just isn't there. We simply don't know if the guy in question has had exactly those two girls, or if he's been the biggest manwhore of the Alpha quadrant and our list is terribly incomplete.
Long story short - apply this to sidebars outside of a very restricted and previously discussed scope, and you've totally lost me. -- Cid Highwind 15:19, February 8, 2010 (UTC)

Standardization of parameters

As Cid mentioned above, there is a lack of consistency in the naming of parameters across the board, with {{sidebar actor}} being the worst case, since it isn't consistent within the template. The two main issues here would be the image and caption names, as, generally, everything else is fairly consistent or only used in a single template. This discussion will include the "logo" parameter, which is only used for assignment patches in universe and title cards on the series pages.

Going over the numbers that the DYKBot pulled (thanks bp), and only looking at the first call for something, among the calls for a image (image, image1, image-top, ...), "image" and the use of a number after 1 is used the most (image, image2, image3, etc.), so I purpose that this be used as the standard. Amongst the various caption names (imagecap, caption, caption-top, etc), the full word 'caption' is used more than anything else. So to remain consistent with the 'image' option, we should use "caption" and a number (caption, caption2, caption3, etc). As for the logo parameter, changing the in universe calls to 'patch' shouldn't be to hard and since the only caption calls for logos are on the series template, keeping them as 'logocap' shouldn't be a problem. So just to be clear, in universe 'logo' call changed to "patch" and:

  • All images:
    • Image
    • Image2
    • Image3
    • etc.
  • All captions for images
    • Caption
    • Caption2
    • Caption3
    • etc.

- Archduk3 11:55, February 9, 2010 (UTC)

Just to be precise - if they are lowercase ("image1"/"caption3"), then yes. However, let's also discuss the general usefulness of captions in sidebars in the section below. Note that this is really a separate issue - even if we don't want a visible "caption", we might still want an invisible "description", useful for accessibility. We might want to go for a different parameter name in that case, though. -- Cid Highwind 13:17, February 9, 2010 (UTC)
Having thought about it - the parameter whose value will act as the image description (=alt attribute) should actually not be called a "caption", but "description" (or perhaps shortened: "descr"). Whether the title attribute of the link tag surrounding the image should actually be (mis-)used to also show the description is currently discussed below. If a separate parameter is considered necessary for this, it should be "title". -- Cid Highwind 22:44, February 10, 2010 (UTC)

I'd be for changing caption to title either way, as it's shorter. We should try for both titles and descriptions, since the title can cite a image, mainly the year, without having to leave the page. - Archduk3 23:19, February 10, 2010 (UTC)

Image captions in sidebars

Looking through the available sidebars, some sidebars present their image description visibly as a caption, while others don't and just use it as alt/title-text. We should try to find a good way to standardize that - and looking for a potential way, I found Wikipedia:Captions at Wikipedia, which contains the following advice:

  • Info box images with mission insignia – no caption needed, but if there is a description of the symbolism, it should be included on the image description page
  • Other images (especially within standard info boxes) where the purpose of the image is clearly nominative, that is, that the picture serves as the typical example of the subject of the article and offers no further information – no caption needed.

I believe this is exactly what images within our sidebars (=info boxes) are, or at least should be - "typical examples" of the topic in question, not some extraordinary situation that needs to be further explained. That said, I think we should remove visible captions from our sidebars or, where an image absolutely needs an explaining caption to make sense, move that image to somewhere else in the article. -- Cid Highwind 13:17, February 9, 2010 (UTC)

First off, I would say we are not Wikipedia, and our articles are/should be more in-depth then theirs, so our 'info boxes' should have a wider array of 'typical examples' then theirs. After all, we are dealing with science fiction, where the typical is actively avoided. That's not to dismiss the notion out of hand, it just means we should set our own standard, and realise that it's just that, an arbitrary standard that may need to be thrown out the window the next time a movie or episode is released. That said, there a few issues with scraping visible captions across the board:
  • The series sidebars, see the TNG one, should retain the visible captions simply because they deal with a lot of information, and while we may all know that's the Enterprise-D, someone who isn't familiar with the show won't.
  • While everyone else may have a superfast internet connection, some don't and shouldn't have to go to a separate page for info that could be placed on page in a caption. This is the same reasoning behind our width formatting, not everyone has the same size monitor and resolution. So I think we should retain the option for the 'invisible caption', or 'mouseover caption' even if we scrap the visible captions altogether, as there will always be a case where it would be helpful, IE: USS Yamaguchi really should say which ship it is, but that doesn't need to be visible text.
I would say each sidebar should have it's own standard, since they deal with a wide range of subjects. An actors page shouldn't really need a caption for a image, but that doesn't mean that a starship won't, or government. - Archduk3 14:49, February 9, 2010 (UTC)

Well, that's precisely missing the point by an inch again... I say "images that are not a typical example should not be in a sidebar", and you say "our sidebar images need captions, because they most often aren't typical examples"? The obvious next question then is: If some image is not a typical example of the object we're trying to describe in any given article - then why in Q's name is specifically this image in the sidebar?

And it's not as if I'm just pulling these ideas out of my ass, or somewhere else - Wikipedia, the biggest wiki on this internet, and with probably the biggest group of contributors that know what they are doing, has published a lengthy guideline with several pages of explanation why it might make sense to use or not use an image under some specific circumstances, or with or without a caption - and then you claim that these pretty generic guidelines don't apply to us because we're a Star Trek wiki? I'm not saying that each and every WP guideline needs to become a MA guideline, but really, the logic behind what you're saying escapes me. -- Cid Highwind 15:13, February 9, 2010 (UTC)

I'm saying that 'typical' has a wider range in fiction than reality, for example: "Orions are known for their distinctive green or blue' skin". Green is by far more 'typical' of what we've seen, but who's to say that the blue skinned Orions aren't just as 'typical'. I won't even go into the Klingon augment virus and how 'typical' that may have been. The Miranda class: is the rollbar 'typical', the pods? I'm saying 'typical' is going to be nearly impossible to pin down because we deal in fiction, and we can be more flexible because we aren't Wikipedia. So I don't think I'm missing the point by an inch, I think our points may just be inches apart. - Archduk3 15:33, February 9, 2010 (UTC)
Now you're speculating. Green is typical of what we've seen. 'Nuff said.
We shouldn't have captions, we should use the "caption" as the ALT tag. That was the design philosophy that DH and I used on all of the realworld sidebars we did. It should be the same for in-universe stuff. -- sulfur 15:45, February 9, 2010 (UTC)
And the series sidebars? They deal with a wider range of information they any other sidebar. - Archduk3 15:49, February 9, 2010 (UTC)

(Edit conflict, written before reading sulfur's reply) Actually, I think you're confusing the meaning of "typical" with a concept that includes "uncertainty" and "incompleteness because of being a tv show". Even if, in-universe, an Orion may be blue instead of green, that doesn't mean that the variety of "typical Orions" is different from, for example "typical humans" (which come in different colors, too, after all). Besides, you might have a point if the first caption on Orion actually said something about the image not being typical - but it doesn't. It states nothing about color, just that this is an image of an Orion female (which I personally don't need explained in this case ;)), and that this image is from a slave auction (which is completely unimportant for a "typical image" on a species sidebar, and isn't even visible in the image).

I think that "typical" is pretty easy to pin down - "typical" is any image where the informed reader wouldn't say "WTF, why did they include exactly this image instead of that other one?". Going back to the Orion example, the one that is now on top is typical - we've seen more females than males, and we've seen more scantily clad ones than those in a Starfleet uniform - which means that File:Orion slavegirl ENT.jpg is much more "typical" than, for example, File:Gaila (Orion).jpg or File:Thelev.jpg. -- Cid Highwind 16:05, February 9, 2010 (UTC)

I was trying to say that if these three images are used for Orions: File:Orion slavegirl ENT.jpg, File:OrionMale2154.jpg, and File:Orion lieutenant.jpg, the last one should point out visibly that this is a "blue skinned" Orion male, since in universe we can't make the assumption that this was the coloring error we all know it to be. I'm not really that interested in fighting this point though, beyond the series sidebars and the mouseover text, so I'll just concede the rest. - Archduk3 16:23, February 9, 2010 (UTC)

Or, the image of the single blue Orion that we've ever seen should not be in the sidebar where "typical" information is presented, but somewhere else in the article, where that image 1.) can get a short descriptive caption, and it 2.) accompanies text that has a further explanation for "blue Orions". -- Cid Highwind 16:28, February 9, 2010 (UTC)

From what I can tell, the whole idea that Orions come in more than just green is the three seen in TAS and a throwaway line in the TOS pilot, so that whole idea should be looked at, but that's not the issue here. Back to the point, the series sidebars, visible captions - yea or nay? - Archduk3 16:57, February 9, 2010 (UTC)

I personally don't consider them that important there, either... we have:

  • up to two series logos, already without caption
  • one image of the hero starship/station, stating its name
  • up to three publicity images of the crew, stating that this is an image of the crew (D'oh!), and from which season

As in other discussions, I'm not even sure we need all those up to six images to be located in the sidebar. Take the crew images, for example - of course there have been slight changes in the main cast, but does that make it necessary to add all to the sidebar? Is the hypothetical visitor (who is assumed to not even know what that "strange starship" above is supposed to be) now able to make out minor changes in both cast and individual makeup by just being told that "this is from season 2, and that other one is from season 6"?

I say it would be much more informative to have a separate section for publicity stills, showing them all in a gallery, comparing them and spelling out "important" differences (like cast changes, changes in uniform, or comparing season 1 makeup of an alien character with season 7 makeup). If we do that, having more than one cast image in the sidebar becomes unnecessary - and with that, the caption (which is pretty uninformative anyway) as well. -- Cid Highwind 10:49, February 10, 2010 (UTC)

Why don't we just use regular images with regular captions instead of putting them all in the sidebar? --bp 11:17, February 10, 2010 (UTC)
.... that wasn't a question it was a proposal. Lets just say that only one image can be in the sidebar. Or maybe only allow multiple if they can be named something different, like starships might have image of the starship 'image' and a logo, 'logo'. Not image1,image2, etc. --bp 11:19, February 10, 2010 (UTC)

Good idea, actually. Any standard sidebar would then allow for one typical image (see section below for definitions of "typical") with standard parameter names "image"/"caption". Any further images should not just be there as another random slot to fill if one likes to, but only be defined if they are considered necessary for a specific type of sidebar - and if we are able to define some specific necessity, we will surely find a better name for it as well. -- Cid Highwind 13:12, February 10, 2010 (UTC)

[edit-conflict]
Re:Cid - Currently, the series sidebar is set up to show the title card, the ship, and the cast. TNG is the max on this, as there were three cast changes and two title cards. Everything that was purposed to remove these images from the sidebar already exists, on the separate season pages, and by all means they should be expanded, but the main page isn't that place as it's set up now. We do get people who are just getting into Star Trek, the series was just revitalized, so there are plenty of people out there who don't know what that "strange starship" is, and don't know who those people are, but maybe they saw a season 2 episode, and look there's that doctor, or that annoying kid, and now know they're on the right page. We shouldn't bury them at the bottom of the page just to duplicate information that's already elsewhere.
Re:bp - Reducing the images down to just one, and a logo, is removing 500+ images from sidebars, most of which are in the sidebar for a good reason. That's not to say that they couldn't be in the article, but if we're going to have sidebars, they should stay. - Archduk3 13:22, February 10, 2010 (UTC)

Hmm. Anyone who has seen "just that season 2 episode" will have seen most cast members (no matter which one of the three we'd use) and the hero starship/station. Also, this seems like a non sequitur again - if the reason for having an image of the hero starship is that someone needs a lengthy explanation for it, then why isn't there any explanation at the moment? All the caption currently states is "The USS Enterprise-D", which isn't helpful at all for someone who doesn't know Trek.

As an aside, I have to observe that the sidebar now needs to cater to the "least common denominator" (someone who hasn't seen Trek before), where it previously needed to cater to active Trek authors, a group of people at the opposite end of possible visitors. Why can't it try to cater to some "average reader" instead, and leave satisfying both extremes to the actual article? -- Cid Highwind 13:45, February 10, 2010 (UTC)

I'm not trying to cater to any of those groups, though I agree that the entire article, including the sidebar, should aim for the 'average reader' while trying to stay accessible to both ends. What I'm trying to do is stay friendly to those readers who are more visual based, since walls of text can be daunting to even the die-hard fans. With that in mind, those images already in the sidebar should stay towards the top of the article, and to the right for ease of reading, which, currently, places them in the sidebar. I don't think we need to rehaul every page to fit the sidebar, especially those that already have one that's been working fine. The main thing this section should be trying to answer, in regards to the series sidebar, is if the captions, including the link, are worth keeping or not. If not, alt text is great, if yes, then they don't change. - Archduk3 14:40, February 10, 2010 (UTC)
Good idea bp0, I like that we should limit type images in sidebars to specifically defined types. Makes it nice and easy for editors and readers, alike. Images then can be thoughtfully positioned within the article as they should be to help enhance sections. — Morder (talk) 16:43, February 10, 2010 (UTC)

Alt text

Just so we're on the same page here, are we talking about adding the alt attribute: (File:Worf.jpg|alt=worf's head looks like a fanny|Commander Worf in 2010) and retaining the "mouseover" caption, or just the latter? - Archduk3 22:00, February 10, 2010 (UTC)

I wasn't aware that the File: syntax supported specifically defining the alt attribute by now. Since the alt attribute is the one that is supposed to describe the image, we should start using it. In this case, I don't think it is necessary to duplicate the same description for the title attribute (the way we have it now), but I'm open to further discussion there... -- Cid Highwind 22:11, February 10, 2010 (UTC)
Actually, I just checked: the title attribute that is currently used is not part of the image tag, but of the surrounding link tag. It seems to be bad style (and even wrong) to also use the description for that. -- Cid Highwind 22:19, February 10, 2010 (UTC)

I understood the first thing you said, but I'm completely lost on the second. - Archduk3 22:44, February 10, 2010 (UTC)

Ouch, I was just told the same on IRC... :) If you look at the resulting HTML output of an File: link using both alt and "standard description", like:
[[File:Image.jpg|thumb|alt=ALTTEXT|CAPTION]]
it will look like this:
<a ... title="CAPTION"><img ... alt="ALTTEXT"/></a>
Basically, what we enter as CAPTION will turn out to not actually be the title of the image, but the title of the surrounding link element - and if we'd be totally precise, the title of a link should not contain a description of an image. That would just be wrong. Realistically, though, I could live with either duplicating the image description there, or adding a image title - as long as we start using the alt attribute (for accessibility reasons). -- Cid Highwind 22:59, February 10, 2010 (UTC)

[edit conflict] - Ok, just played with it on my sandbox, I see what you're talking about. The alt attribute doesn't seem to work using sidebar image anyways, so unless there's some way around that I think it's kind of moot. - Archduk3 23:05, February 10, 2010 (UTC)

It does work. If you have a browser that can be set to not show any images on a page, it should display an empty border with the alt text inside, instead. Opera, for example, does exactly that. The purpose of the alt attribute is to act as an "alternative" to the image itself (hence the name), not to be displayed in addition to the image. {{sidebar image}} does not currently support that, but that can be added easily. I will do that tomorrow. -- Cid Highwind 23:13, February 10, 2010 (UTC)

Checking the properties on my test images doesn't show the alt text when using sidebar image. Is it just firefox then? - Archduk3 23:15, February 10, 2010 (UTC)

As I said, the template is currently not coded to deal with the alt= parameter at all. It's just ignored... this can be changed, though. :) -- Cid Highwind 23:22, February 10, 2010 (UTC)

Yeah, might have helped if I read the whole thing there, or grasped why it wasn't working in the first place. :) - Archduk3 23:29, February 10, 2010 (UTC)

I have now added a new pair of parameters to {{sidebar image}}, and updated your sandbox example accordingly. I deliberately did not add a fallback to use the current caption as description if the latter is missing. I think that what we currently have as caption would, in most cases, not suffice as a proper image description. -- Cid Highwind 23:52, February 10, 2010 (UTC)

If we're going to seriously start using this option, it might be better to have descriptions written on a subpage (File:Worf2375.jpg/description) of the file and pulled directly from there automatically. That way there's no extra call and it could default to something like "no description, sorry". - Archduk3 01:23, February 11, 2010 (UTC)

That's a good suggestion, but not something we can achieve. This would need to be done on the level of the Mediawiki software - and preferably default to some piece of text on the image description page (perhaps marked as <description>), or to the message "please visit the image description page for more information" if such does not exist. Unless this is added to the code, though, we'll have to deal with what we have - and that is an optional parameter for each image, individually.
We could code the sidebar image template to take its description from some other page - but actually, I feel that this wouldn't enhance the situation. It would just be "out of sight, out of mind", and probably not be updated when the image gets changed - and also, it would only work for the few images that we use in sidebars, but not for the huge mass of images that are included otherwise.
I'll see if I can forward this suggestion to someone closer to the Mediawiki development - and in the meantime, it sounds like a good idea to replace the default for at least our sidebar images with a message to "click here to view description", and add that call to some maintenance category for a better description at the same time. -- Cid Highwind 11:33, February 11, 2010 (UTC)
Or {{:Image:blah.png}}, and the image page has includeonly/noinclue. No no, thats a bad idea. This is all a bad idea, stop this nonsense immedjiately. --bp 11:43, February 11, 2010 (UTC)

bp is a dangerous man, so it might be best to do as he says lest he be provoked further. - Archduk3 12:12, February 11, 2010 (UTC)

One huge problem with having an alternate "article" with the description is that it will not be updated when the File changes. Ever. And there's no good, clean way to tie 'em together. It also adds another layer of complication that is just not needed. -- sulfur 12:36, February 11, 2010 (UTC)
To make that clear in fewer words: completely and utterly unmaintainable. -- sulfur 12:49, February 11, 2010 (UTC)

Image order

On sidebars with more than two images (in universe), I think it's safe to say that the most 'recent' image of the two, the one closest to the (last) 'status date' should be displayed on top; unless that would be a 'death image' (IE:A starship exploding). - Archduk3 17:07, February 9, 2010 (UTC)

The whole thing that brought this up is the fact that some people claim that TOS characters are much more "typical" in their series appearance than in their "late movies" appearance, or any appearance even later than that (like, for example, McCoy in the TNG pilot). Even outside of that specific example, I think we're restricting ourselves too much if we claim that "recent" is more important than "typical". For example, when thinking of Picard, the image I have in mind is neither shiny-season1-in-too-tight-spandex Picard, nor Nemesis-aged-action-hero Picard. Instead, it's season4/5-field-jacket Picard.
This means, the rule of thumb to use should probably be:
  • one image: the most "typical" one
  • two images: the most "typical" one on top, and one that is still "somewhat typical", but considerably different (so as not to be superfluous) at the bottom.
Where absolutely necessary, we could then go on and have another discussion what exactly "typical" means for a specific class of articles. I don't think that having this discussion is really necessary for things that don't age, as for example, most starships, or planets. Also, just as an aside, I don't think that "no death images" should become a rule. I absolutely love the image used for USS Valley Forge, and I don't think it needs to be changed because of some artificial rule. -- Cid Highwind 17:39, February 9, 2010 (UTC)

This 'typical' idea is a whole can worms, because that allows for a completely subjective rational for images, which would lead to pointless arguments, note these would not be discussions or debates, on which season has the most 'typical' image for any character/what have you. As far as characters go, an 'early' image and a 'latter' image should cover it, with the latter in the top slot. This removes the subjective user POV and places it firmly in universe and without bias. As for the Valley Forge, I love that image too, and only said if there were two images in use, the 'death image' shouldn't be in the top slot, so don't think I'm trying to get that removed. :) - Archduk3 17:58, February 9, 2010 (UTC)