User talk:Thumperward/Archive 43

Archive 40

Archive 41

Archive 42

Archive 43

Archive 44

Archive 45

→

Archive 50

Hammer paint‎

How come you marked it as a textile-stub? Am I missing something? Pseudomonas_(talk) 16:05, 12 January 2010 (UTC)

D'oh. Lack of caffeine. {{material-stub}} would probably be a better choice. Chris Cunningham (not at work) - talk 16:21, 12 January 2010 (UTC)

Sherlock Holmes

The reception section of the article Sherlock Holmes (2009 film) is pants. Since you did such a good job on Zombieland I thought I might encourage you to tackle Sherlock Holmes if you're interested. I understand of course if you have other things you'd prefer to spend you time on, I might take a stab at it myself but I'm sure you could do a great job on it. -- Horkana (talk) 02:47, 13 January 2010 (UTC)

I'll try to take a look. Thanks for the suggestion; feel free to drop by with more any time! Chris Cunningham (not at work) - talk 08:45, 13 January 2010 (UTC)

Wiki or HTML

Reverted a rather large edit of yours adding HTML to an article, which was clearly in good faith so there are two issues that I should probably explain.

1. HTML. There might be an exceptional reason to use HTML but it is not generally recommended. I used mostly HTML when I started editing Wikipedia, other editors will usually clean it up if you find it easier to work that way but it is not recommended. The principle of keep it simple applies, but it is mentioned in the introductory guidelines: "Use HTML and CSS markup sparingly and only with good reason. Minimizing markup in entries allows easier editing."
2. Indentation. Having done a little bit of programming and far too much checking of other peoples bad programming code I have a strong personal preference for clear line breaks and indentation. Line breaks make it much clearer and easier to read the wiki source, to verify that citations look reasonably correct (e.g. unnecessary junk in the URL after .html) or to see if they might be improved by adding extra details such as authors or dates or even archiveurls. Retaining line breaks also makes the diff tool (compare revisions) much clearer and more useful, so even if do strip out line breaks it helps a lot to that in a separate edit from copy editing so other can more easily compare the text of your edits to the previous versions. And I could probably come up with more reasons why identation is a good thing but it's about clarity and keeping it simple.

-- Horkana (talk) 15:44, 13 January 2010 (UTC)

1. There is definitely an "exceptional reason" to use HTML to define an ordered list: hacking it up with manual numbering and line breaks leads to code which is no simpler and semantically useless. What I accomplished was impossible with wikimarkup, which is precisely when to use HTML.
2. The previous whitespace was simply haphazard and inconsistent and led to dozens of cases where there were unintentional line breaks after references which meant that one couldn't unambiguously identify whether the following text was intended to be in the same paragraph or in a new one. Removing excessive line breaks also has the advantage that it allows browser text edit boxes to treat the content as a paragraph properly, of massive benefit when moving things around. The whitespace was cleaned up to be completely consistent, such that changing the whitespace style again would be so trivial as to be automated if need be; regardless, there was certainly no consensus as to the previous mess.

Quite on top of those two, a huge amount of general cleanup was involved in said edit. I do not expect it reverted lightly because someone disagrees with the whitespace style. I'll be re-doing said edit tomorrow, after which I expect that if there are problems with it that editors will take said problems to talk instead of treating the undo button as a veto. Chris Cunningham (not at work) - talk 15:58, 13 January 2010 (UTC)

I can see merits to your approach but it seems like a lot of change for very little improvement. The HTML seemed like the less simple approach, we'll see what happens when casual editors come back and keep trying to insert extra rules into the list, maybe the extra complexity will help put them off, which in this case might be a good thing.

Many smaller diffs are easier to review than one huge amount of cleanup. Shorter edits with edit summaries would have made you very deliberate intent to use HTML much clearer. It might also have allowed me to revert only a small part of your edit. A big edit makes a big revert the most likely choice, I'm sorry you see that as a veto, I know how annoying deletes can be. You could revert my revert (and possibly still can) and said your changes were very much intentional, if I had made a suggestion on the talk page it could have be easily overlooked or ignored. Not all big edits are as well intentioned as yours, it does seem like some editors make deliberately big edits making it harder for anyone else to disagree with their edits and make small changes (there's a guy who keeps entirely rewriting plot summaries and describing his edit as "trim"). So give it a try, reapply the HTML if you want.

I take no board your point about consistency, in future I'll make the effort to format an article fully in my preferred style if it nearly all that way already but I'm not using any automated tools so it doesn't seem all that trivial, maybe you can recommend some to make the task less tedious. It is really on new articles that need lots of change, review and cleanup that I feel the clarity of the wiki source is particularly necessary. I think when there are spaces there it makes it so much easier to see that additional parameters should be added (and for the best few sources in the article I'll even go to the extra trouble of backing up the links). I wish more of these things like citation were checked automatically, then we could focus more on the content.

Sorry to take your time away from editing. Hopefully we can move this along again. -- Horkana (talk) 02:34, 14 January 2010 (UTC)

It is important for markup to be as semantic as possible; that means that lists should always be marked up as lists. HTML provides the facility to have ordered lists skip numbers, whereas wikicode doesn't (yet). If wikicode ever develops this feature I'll convert the list myself; I am in fact strongly in favour of using wikicode over HTML but only where that's technically possible. The code is not excessively more complicated for the added semantic value it imparts.

As for the size of the diff, sorry about that; much of the code cleanup involved iterating over the whole article as once, and some of work required that the whitespace be cleaned up in advance. It therefore probably wouldn't have been possible to undo the whitespace changes afterwards. That said, I believe that WP's current diff tool is not restricted to per-line operations; it once was, but it's slightly smarter than that now IIRC.

I'll take any followup to article talk. Chris Cunningham (not at work) - talk 09:55, 14 January 2010 (UTC)

Hi. I just reviewed the massive diff, including an examination of both edit boxes. The html use was reasonable; it is perfectly acceptable given the odd numbering of the rules. The breaking of refs onto multiple lines is a practice I favor and I am sorry to see such formatting forced onto one long line. There were a great many other bits of clean-up lost and that quite unfortunate. If I were to have come upon the article after Chris's edit I would have be inclined to reformat the refs onto multiple line while keeping the rest (this assuming I was much interested in editing the article at all). Cheers, Jack Merridew 16:37, 13 January 2010 (UTC)

As I say, if there's consensus to split refs into multiple lines then it is trivial to do so consistently from the new revision. The current version uses both systems, which helps nobody. Chris Cunningham (not at work) - talk 19:05, 13 January 2010 (UTC)

I'd say we should restore your edit and move from there. I'll do so, restoring some bit an anon has added, and then we can talk about the ref format. I'll only dip my oar in for one revert. I'll look in a sec, but it my recollection for earlier that the refs were in rather an inconsistent state. Cheers, Jack Merridew 02:15, 14 January 2010 (UTC)

Barnstar

		The Special Barnstar
		For your kindness in being so willing to help with infoboxes and other technical issues, often at the drop of a hat. It is greatly appreciated. SlimVirgin TALK contribs 19:37, 14 January 2010 (UTC)

Avatar (2009 film) article -- the Critical reception section

I am thinking that your help is needed on this matter. Right now, your thoughts could be especially helpful at Talk:Avatar (2009 film)#Moved recently added sociopolitical paragraph here for discussion. Considering the excellent work you did on Zombieland's Critical response section, I believe that you could help us out a lot with the Critical reception section of the Avatar (2009 film) article. Flyer22 (talk) 01:04, 15 January 2010 (UTC)

I've added my thoughts; what I would say is that I strongly disagree with the assertion you made on the talk page that there should a "positive" and a "negative" paragraph. While this is sometimes okay, it's far better to split the reception paragraphs by the theme or the aspect of the film being covered (for instance plot, sociopolitical impact, effects) and to contrast opposing opinions within the paragraphs themselves. I actually think the article does a very good job of this already, including in the paragraph currently being discussed. Chris Cunningham (not at work) - talk 09:08, 15 January 2010 (UTC)

To start off the Reception section of a well-received film, I feel that the positive reviews should come first, and the negative reviews second. Like, if we start off relaying the entertainment aspects of the film, as the Avatar (2009 film) article does. If we start off saying the film received generally positive reviews, for example, I do not see how it is better to immediately follow that up with mixed reviews. The positive reviews come first; this was also done with the Avatar (2009 film) article, though one could say that it is mainly because most of the reviews about that film, especially the entertainment aspects, are positive. Likewise...with a film that received mostly negative reviews, I feel that its reception section should start off relaying those negative reviews first, like the Pandorum article does, then relay whatever positive reviews it got (whether in themes or whatever). That makes the most sense to me. I basically said that I am typically for a "positive" paragraph and a "negative" paragraph...and then "whatever else" after that. I am for Reception sections being covered in themes, if they have enough themes/aspects to be covered in that way. It is just that I typically think in terms of "positive" and "negative" in regards to film reception sections. Most films are so mediocre these days, or are very, very simple. You made me think differently on the positive and negative format with the work you did on Zombieland's Reception section, but not all films are going to be that abundant in themes/aspects; some will not even have enough people pointing out the same thing.

As for the article in question, I do not feel that its Critical reception section has taken care of enough; I feel this way because of the constant complaints about the Critical reception section leaving out certain criticisms and not having a worldwide view. The American view is not a worldwide view. Yes, it is obvious that a lot of people all over the world like or love this film, but some reviews from those other aspects of the world can be noted without being redundant...or at least traded out with a few of the American views saying the same thing. It is not WP:UNDUE to include a few non-American reviews. In fact, Wikipedia articles should present a worldwide view. (I will copy this particular paragraph on the talk page of that article.)

Anyway, thank you for weighing in on this matter. Flyer22 (talk) 22:37, 15 January 2010 (UTC)

Nomination for deletion of Template:Infobox Automobile engine generation

Template:Infobox Automobile engine generation has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Thank you. 78.32.143.113 (talk) 11:27, 16 January 2010 (UTC)

{{footballbox collapsible}}

Re: [1] I've replied on the talk page. While I disagree that this violates MOS:COLLAPSE, I respect your opinion. I've provided my thoughts on why I don't think it is in violation. I'm going to add a pointer to this discussion in WT:FOOTY as well. Thanks for bringing up this concern. --SkotyWA^T|_C 23:23, 17 January 2010 (UTC)

replied. Thanks for taking it to WT:FOOTY: I should have done that, my bad. Chris Cunningham (not at work) - talk 01:05, 18 January 2010 (UTC)

You said: I'm not in the habit of proposing that templates in moderate use simply simply be wiped out without any contingency for existing transclusions. I'm sorry, but that's exactly what it looked like you were doing with your first post. Sorry for the "rhetoric", but it was a genuine response to what seemed like hostile activity. --SkotyWA^T|_C 05:26, 18 January 2010 (UTC)

I do a lot of work in both templatespace and in football articles; I can think of better ways of getting my jollies than suddenly causing a lot of articles to have red links in them where they used to have large data tables. You might want to reconsider your threshold vis a vis what a "hostile activity" is. Chris Cunningham (not at work) - talk 09:20, 18 January 2010 (UTC)

I think you're making the mistake in thinking that your reputation precedes you. It doesn't. Two editors (myself and WFCforLife) made the "mistake" in thinking you were proposing deletion without a migration plan. When making such remarks, being clear about your full intentions is critical. Your first comment simply said "I'm going to delete this because of X" with no further plan being conveyed. Obviously I had a bit of an allergic reaction to such an idea and may have troubled you with my "rhetoric". For that I apologize.

Moving on, your comment here seems to contradict itself. First you say that "removing it (box score information) negatively impacts the informational value of a given article" clearly implying the importance of the information and then three sentences later you call the same information "fancruft". So which is it? Is it valuable information that must be accessible to all users (not sure that it isn't already) or is it wasteful information added by fanboys?

Also, the last part of that same comment makes me think that all you're really going for here is the removal of redundancy between {{footballbox}} and {{footballbox collapsible}}. If so, why all this fuss about accessibility? I've been thinking for a while about getting rid of {{footballbox collapsible}} in favor of shared functionality with {{footballbox}}. When I originally created {{footballbox collapsible}} I did so because {{footballbox}} was still very primitive (for example, it had a separate template for penalty scores) and it was used practically everywhere. I didn't want to mess anything up, so I created a new template with the features I was looking for (collapsibility and self-contained penalty results were among them). Since then, {{footballbox}} has "caught up" with {{footballbox collapsible}} mostly. The documentation of the two templates should tell you all you need to know about their differences (I put a lot of effort into {{footballbox collapsible}}'s documentation as well).

Finally, I think George's comment pleading for using common sense is spot on. You started this whole thing with the premise that the MOS had to be enforced even if it meant the deletion of a widely used template. What I'm asking is did you ever consider that you may have interpreted the MOS incorrectly (I've provided quotes/links to another applicable section that contradicts your interpretation) or that MOS:COLLAPSE may be altogether inaccurate (which I've raised with you and also on WT:ACCESS). I've taken it upon myself to test out the accessibility concerns raised with real world examples and found them to be false (still setting up a VHD to test IE6 on WinXP to be sure). I beg that you please apply some common sense rather than dutifully applying the MOS as if it's holy scripture and you're the only one who can interpret it correctly. If you look at the history of WP:ACCESS and WT:ACCESS you'll see that it was added by User:Happy-melon with very little discussion (follow the links to see what I'm talking about). I'm about ready to go to that editor directly and see if (s)he had this in mind when making the initial proposal. I'll give my post on WT:ACCESS a few days first to see if it gets any traction. In the end, I think the MOS is wrong, and I think that you are misguided in how you're choosing to apply it.

Sorry if this comes off as offensive, that's not my intention. I'm trying to be open and honest with you. Hopefully I'm not making a mistake. --SkotyWA^T|_C 03:30, 19 January 2010 (UTC)

1. There's a simple rule for avoiding that confusion.
2. Sorry for the apparent contradiction; the point was that the material in the tables imparts a significant amount of information; whether that information is really useful enough to retain on a long-term basis is debateable, but that's a different matter.
3. Accessibility is something I try to pay a lot of attention to. I suppose I had similiar goals to the one you've given here when I started {{infobox football biography 2}} in that while I had a specific feature in mind (in this case accessibility) I wanted to experiment with additional improvements without unnecessary disruption to deployed instances. As I said, while unforking the template should be a pretty uncontroversial improvement, it wasn't my main reason for bringing up the discussion.
4. No, I don't believe that I have interpreted the MoS incorrectly. The spirit of the guideline is that because tables which are collapsed may be inaccessible, they should not be used to present material which one might need to understand an article. Parsing this by article component means treating it as an arbitrary rule rather than a guideline with an underlying rationale. I'm not following the MoS here simply out of some supposed duty to enforce it, but because I'd far rather err on the side of caution when it comes to accessibility; what may be a minor inconvenience to sighted users (such as having to scroll a bit further) may cause significant problems for others. If indeed that argument no longer applies then so be it, and I suppose it opens the door for future improvements to a whole bunch of templates that I follow. But I'm not prepared to use "common sense" (i.e. deriving my own answer from first principles) lightly in this case when I'm aware of the potential negative effect that doing so could have.

No hard feelings, anyway. The end result is that we're going to have some improvements in these templates and hopefully some clarification in the MoS to boot. Compared to some discussions regarding the MoS I've seen this has been like a Victorian tea party. Chris Cunningham (not at work) - talk 09:02, 19 January 2010 (UTC)

I must say I'm a little disappointed at your insinuation that I have not extended you good faith. I would argue that I've gone out of my way to extend you good faith in the face of your terse initial comment and your overall lack of clarity regarding your intentions. You said: But I'm not prepared to use "common sense" lightly in this case when I'm aware of the potential negative effect that doing so could have. Really? What negative effects are you aware of? What actual facts have you offered? What brand/version of screen reader have you tried that has trouble accessing these footlball boxes (I am aware of one which has no trouble)? What brand/version of browser have you tried that has trouble rendering these football boxes (I've tried 3 and they all work fine)? Frankly it seems like I'm the only one doing the grunt work to ensure that common sense prevails in the face of your dogged interpretation of the MOS. --SkotyWA^T|_C 17:50, 20 January 2010 (UTC)

From the response I've received, you'd think I'd started bulk-deleting these things without comment rather than doing the right thing and raising it on the template talk before actually following through with my "dogged interpretation of the MoS". I'm not really in the mood for having a fight about this. If there's a response on WT:ACCESS which clarifies whether collapsing / scrolling sections are still an accessibility problem then we can move forward from there. If there's nothing soon I'll try pinging some folk who have worked on template accessibility in the past to see if they can pitch in. Chris Cunningham (not at work) - talk 09:54, 22 January 2010 (UTC)

Just to let you both know, I've started a section at Wikipedia talk:Manual of Style#MOS:COLLAPSE, in an effort to draw attention to the discussion at WP:ACCESS. WFCforLife (talk) 02:13, 24 January 2010 (UTC)

Avatar Critical reception rewrite

Thumperward, thanks for your contribution on Avatar. Following yours and some other editors' suggestions, I have proposed a restructured Critical reception section for discussion here, hoping to try and accommodate a deeper and more balanced coverage of the film internationally. Please have a look. I hope we can resolve this impasse and work out something everybody or most will be happy with. Regards, Cinosaur (talk) 11:30, 18 January 2010 (UTC)

Replied. Thanks. Chris Cunningham (not at work) - talk 09:19, 19 January 2010 (UTC)

Thanks for your reply. Could you please also suggest improvements on that talk page? Cinosaur (talk) 09:40, 19 January 2010 (UTC)

I'd rather wait until some of the old discussion dies down first. There seem to be several discussions going on in parallel right now, and it's unproductive to try and keep track of them. I'll keep it watchlisted, though. Chris Cunningham (not at work) - talk 09:46, 19 January 2010 (UTC)

Template:Cladogram

Whatever you're doing at {{Cladogram}} has broken the template. Guettarda (talk) 16:01, 20 January 2010 (UTC)

Should be fixed. Probably best showing an example if it's still not working properly somewhere. Chris Cunningham (not at work) - talk 16:02, 20 January 2010 (UTC)

Less broken, but still messed up. See Aiphanes#Taxonomy. Please use a sandbox for this kind of thing in future - I just searched through about 40 edits, edit by edit, to see where I had screwed up, before realising it was the template that was screwed up. Guettarda (talk) 16:05, 20 January 2010 (UTC)

Fixed again. Sorry about that. Chris Cunningham (not at work) - talk 16:10, 20 January 2010 (UTC)

I know you're probably still working on this, but the template is still broken. Next time, would you mind testing your revisions first in a sandbox? Otherwise I love the look your revisions seem to be aiming for. –Visionholder (talk) 16:17, 20 January 2010 (UTC)

Sandbox doesn't magically fix these things. Things would still be caught in deployment which would need to be fixed. Comments about breakage which are accompanied by descriptions or examples can be fixed far faster than by me having to hunt through random transclusions. Chris Cunningham (not at work) - talk 16:36, 20 January 2010 (UTC)

Sorry for not including an example. Start with Primate. If you fix it there and it still looks broken on my sandbox pages (where I'm currently working), I'll let you know. –Visionholder (talk) 17:00, 20 January 2010 (UTC)

I've been hunting through transclusions and I can't see the problem. have you purged the page cache? Primate's transclusion looks fine here. Chris Cunningham (not at work) - talk 17:03, 20 January 2010 (UTC)

We're back to normal. Thanks! Honestly, though, I kind of liked the new border color (before you changed it back). But that's just my opinion. Best, –Visionholder (talk) 17:16, 20 January 2010 (UTC)

No problem, my bad. :) I've tweaked the border colour again so that the inner/outer borders match those on image thumbnails, which was the look I was going for originally. If you have any thoughts then please let me know. Chris Cunningham (not at work) - talk 17:18, 20 January 2010 (UTC)

Sorry to keep this going.  :-) I have noticed some text overlap since your changes on a large cladogram on one of my sandboxes. It's a very large cladogram, and it brings up an interesting point. Can the cladogram template offer a centering option? I think I've tried sticking large cladograms in tables before, but had no luck. –Visionholder (talk) 17:24, 20 January 2010 (UTC)

What do you mean by "text overlap"? The text on the diagram is overlapping the lines? I can't see it in your sandbox. As for centering, do you mean putting the table in the middle of a block of text? Chris Cunningham (not at work) - talk 17:28, 20 January 2010 (UTC)

On my browser (Firefox 3.5.7), one line of text from Characteristics and ecology section and the edit link overlap with the cladogram title. Maybe that's just how Firefox likes to display it. As for centering, I would like to center such large cladograms on the page much like you can an image. Therefore text would not flow around either side and the box would be centered on the page. –Visionholder (talk) 17:36, 20 January 2010 (UTC)

The edit links thing is unfortunately just an artefact of the way edit links are displayed; it can happen with lots of different layouts. There are ways to hack around it, but avoiding it here would mean going back to a non-standard way of displaying this table (and to be honest I'd rather this template had the same problems with edit links as other articles than entirely different ones). As for centering, sure thing. I'll add support shortly. Chris Cunningham (not at work) - talk 17:41, 20 January 2010 (UTC)

Done. Try align=center out now. Chris Cunningham (not at work) - talk 17:46, 20 January 2010 (UTC)

B-E-A-utiful! You rock! Thanks, man! –Visionholder (talk) 17:51, 20 January 2010 (UTC)

Talkback

Hello, Thumperward. You have new messages at Armbrust's talk page.
You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.

Armbrust (talk) 22:21, 20 January 2010 (UTC)