User talk:Thumperward/Archive 21

This is an archive of past discussions with User:Thumperward. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 15

←

Archive 19

→

Arilang1234

Hi,As you probably know,I am new at Wiki,and have mininum of experience,but I am willing to learn. Thanks for moving my article into talk page,I agree with you that the essay I am using to put forward my point of view is controversial,to say the least.It is not what you called main stream. However,when Nicolaus Copernicus was telling people that the Sun is the center of the solar system,no one believed in him.Majority is not always right.Arilang1234 (talk) 13:57, 3 September 2008 (UTC)

That's true, but Copernicus's theories are now widely supported by secondary sources - we cannot include new or original material on Wikipedia until such sources are available for it. Anyway, feel free to work on the section on the talk page. Chris Cunningham (not at work) - talk 14:03, 3 September 2008 (UTC)

Hi again.

I have collected more information on Boxer Rebellion,and I wish to show you some of the links.I believe they are of reliable sources.

Please do check up these web sites when you have time.Arilang1234 (talk) 00:58, 4 September 2008 (UTC)

I have put up more contributions on Boxer Rebellion,when you have time please check it and let me know of any short comings.I am more then willing to comply with all the Wiki's rules .Arilang1234 (talk) 06:26, 5 September 2008 (UTC)

Template:Infobox user

Hi. Please have a look at the allignments of userboxes in Template:Infobox user; as you can see on my user page, the boxes are miss-aligned. Before the conversion to Infobox, I managed to fix that, but that fix seems to have been rendered ineffective, Please have a look. — Edokter • Talk • 14:10, 3 September 2008 (UTC)

To add, I don't know if it even can be fixed, due to {{Babel}} having a default left margin of 1em. But I fixed my user page to remove the margin from Babel. Just so you know. — Edokter • Talk • 14:27, 3 September 2008 (UTC)

I had a quick poke about, but I can't understand why the cell contents don't want to be centered. I'll see what I can do later. Sorry about this. Chris Cunningham (not at work) - talk 14:38, 3 September 2008 (UTC)

It's something to do with the interaction between CSS and the tables. I'm not even going to pretend that I would enjoy poking through monobook.css and the DOM inspector for two hours looking to see what's overriding what, so I've just wrapped the non-babel userboxen in your infobox inside another table. Hope this isn't too hackish for you. Chris Cunningham (not at work) - talk 15:12, 3 September 2008 (UTC)

Oh well, it works :) Thanks. — Edokter • Talk • 15:14, 3 September 2008 (UTC)

(ec) It's the combination of Babel that floats right (and has a left margin), and userboxes floating left, which is a problem in itself (I have userboxes disappearing until I hoover over them). I intend to remove the flaoting DIV in {{Userbox}} pending comments. That should fix the disappearence problem. Removing the margin from Babel might prove more difficult. It worked before because the old code had a hard-coded width for the entire table. — Edokter • Talk • 15:13, 3 September 2008 (UTC)

Infobox rail line

Good job on converting {{Infobox rail line}}; I'd played around with the idea but never got it working quite right. I've noticed a problem--the map templates aren't all including properly--see SEPTA Route 100 for an example. Mackensen (talk) 22:36, 5 September 2008 (UTC)

I believe I've fixed the issue by moving the {{{map}}} transclusion on to its own line. Mackensen (talk) 22:41, 5 September 2008 (UTC)

My pleasure, and thanks for fixing it. :) Chris Cunningham (not at work) - talk 22:57, 5 September 2008 (UTC)

Hi, after converting to the infobox template, "blank: width depends on infobox content" does not work anymore. this causes certain map templates to display gaps in the route if the line is wrapped. any solutions to this? -oahiyeel ^talk 09:41, 7 September 2008 (UTC)

I'd tried simplifying the {{{box_width}}} parameter. This might have been the cause. Hopefully it's now fixed - can you provide an example page if it isn't? Chris Cunningham (not at work) - talk 10:14, 7 September 2008 (UTC)

Still doesn't work. Check out East West MRT Line for an example. In the past, expanding the map parameter causes the infobox width to adjust; thus avoiding the breaks in the route diagram. Could it be an issue with the {{infobox}} itself? -oahiyeel ^talk 03:45, 8 September 2008 (UTC)

I've created an example of the old and new templates at User:Oahiyeel/Sandbox -oahiyeel ^talk 03:55, 8 September 2008 (UTC)

Hmmm. Yes, it looks like an issue with {{infobox}} itself; there's nothing in the code which would seem to affect that. Do you know if this is a widespread issue? If it's not, it might be worthwhile just to override the width on that particular article, because increasing the width of the table itself when the box is expanded isn't particularly nice. Chris Cunningham (not at work) - talk 07:13, 8 September 2008 (UTC)

Alright, I've fixed it by putting "width: auto;" Thanks for the help anyway :) - oahiyeel ^talk 07:58, 8 September 2008 (UTC)

Hi, I'm the user that brought the problems with SEPTA Route 100 and other lines to Mackensen's attention. I see that they're fixed now, but I found another problem with Amtrak California's Capitol Corridor. Only in this case it's the image that's being scrambled. The line template is separate from the infobox in this one, and it seems to be okay for the time being. ----DanTD (talk) 19:47, 11 September 2008 (UTC)

Fixed by setting defaults for {{infobox Amtrak}}'s image sizes. This looks to have been broken by a tweak to that infobox's image settings. Chris Cunningham (not at work) - talk 10:57, 12 September 2008 (UTC)

And how were you able to do that? Because the same problem now exists for the Long Island Rail Road's Port Washington Branch as well as WMATA's Red Line and Orange Line. I should check other articles on other systems and lines. ----DanTD (talk) 21:56, 15 September 2008 (UTC)

Okay, after reading this thread, I was able to fix the images. But now, I'm back to having broken line templates for the LIRR Port Washington Branch. ----DanTD (talk) 01:50, 16 September 2008 (UTC)

This looks to have been caused by the use of the {{px}} template in each case. In my opinion that template is more trouble than it's worth. Chris Cunningham (not at work) - talk 06:48, 16 September 2008 (UTC)

Islands

I made the template noinclude, so it shows correctly on Template:Infobox Islands/doc while not affecting the main template page. When the bug is fixed, the noinclude can be removed. Superm401 - Talk 00:56, 8 September 2008 (UTC)

List of e-book readers

I've restored the deleted devices. There is no rule about removing red links, in fact red links encourage article creation, that's why we have red links. Or simply keep them black with no link at all, but with citations for verification purposes. The article is a "List of" article, its stated purpose is to list *all* of the e-ink devices. Removing them is counterproductive. Fothergill Volkensniff IV (talk) 03:19, 9 September 2008 (UTC)

A link to a product website is not a "citation". On my next pass I'm just going to merge the few notable examples in that article back into an appropriate parent, because it's obvious that it isn't working as a standalone article for now. Chris Cunningham (not at work) - talk 07:03, 9 September 2008 (UTC)

I appreciate your view, but believe the list is a valuable resource for readers. Since a merger is in effect a deletion of the article, I would like to see a wider consensus before doing so. Thank you, and look forward to working with you, Chris. Fothergill Volkensniff IV (talk) 14:26, 13 September 2008 (UTC)

We're not here to provide valuable services to users. If the devices in question are not notable enough to warrant articles, then there is little point having an article to list them. I'm happy for further input though. Chris Cunningham (not at work) - talk 14:41, 13 September 2008 (UTC)

Dear Chris, in the interest of gaining wider consensus, I hope you don't mind I started a RFC on the article talk page. Hopefully I stated your position accurately in getting the discussion started but feel free to clarify. Fothergill Volkensniff IV (talk) 14:55, 13 September 2008 (UTC)

Sure. Thanks for taking the initiative. Chris Cunningham (not at work) - talk 18:07, 13 September 2008 (UTC)

Regarding the infobox

The current infobox's format isn't in line with the other VG character infobox formats which draw a distinct line between real-world and in-universe content. The old box on one hand isn't an issue for articles of characters from that series not exclusively from video games; however Minsc readily doesn't fit that criteria. Thus the template is necessary.--Kung Fu Man (talk) 10:22, 9 September 2008 (UTC)

I'm working on making {{infobox D&D character}} less in-universe right now. This is just a temporary measure - give me a couple of hours to work on this. Chris Cunningham (not at work) - talk 10:24, 9 September 2008 (UTC)

That's not really my point actually. My point was {{infobox D&D character}} is intended more in mind for as a stand-alone infobox, which currently unless the character is a pokemon is nn to apply to a vg character, D&D or no. There's a specific standard that gets followed with these things.--Kung Fu Man (talk) 10:29, 9 September 2008 (UTC)

Whether the infobox is {{infobox D&D character}} or {{general VG character}}, it's still an infobox for a fictional character. You can either assume that I know what I'm doing and give me a couple of hours to see if I can improve the infobox to the point where it presents information from a real-world perspective, or you can hang around and undo my edits because you feel that even temporary regressions in articles during ongoing work are unacceptable. I'd much rather you stepped back, because had I not had to respond to this obstruction the work would probably already have been done. Thanks. Chris Cunningham (not at work) - talk 10:42, 9 September 2008 (UTC)

Your infobox is still an infobox for characters beyond the video game project's scope. Video game projects are a different matter, and Minsc falls in that scope. I'm sorry this is such a "hold up" for your work for a single character out of the related articles to have this, but he ends up the only one of the lot to be exclusively a video game character (as far as I know) that achieves enough notability to remain as an article. What happens to the rest is of course your concern, not mine. But I'll choose to stand my ground, thank you very much.--Kung Fu Man (talk) 19:07, 9 September 2008 (UTC)

...Wow. Is this honestly because you thought another project was "stealing" your article? The VG project is an arbitrary line, for crying out loud. I'd thought it was down to the rather mundane issue of me having speedied a template you wrote. I suppose I'll end up taking the template to TfD. No biggie, given that it at least inspired me to work on the D&D templates. Chris Cunningham (not at work) - talk 21:11, 9 September 2008 (UTC)

Great way to skew my own words and not assume good faith there pal.--Kung Fu Man (talk) 23:30, 9 September 2008 (UTC)

The jab about ownership wasn't necessary, but I don't have to assume bad faith to state that I don't think you're right here. You haven't done anything to work with me on this issue, and have apparently moved the goalposts since yesterday - yesterday the D&D box couldn't be used because it was too in-universe; today it can't be used anyway because of the rather unfounded edict that projects which fall under the VG project have to use VG infoboxen. The general VG character subboxes need to be trimmed significantly, the D&D one doesn't make sense if it's only used in one article and can easily be replaced with a different infobox, and you haven't provided any counterargument which holds water. Chris Cunningham (not at work) - talk 07:48, 10 September 2008 (UTC)

I think you're hearing only what you want to. In the issue of your infobox, the real-world and significant information is being placed at the bottom, when if it's stand-alone it should precede the character's fictional information like race and whatnot because that's where the prime emphasis should be. The second point is that the box in all accounts clearly looks more in mind for one geared to literature originating characters, which is a good move for characters of that type...but you should generally make it clear from the getgo to the reader they're reading a video game character article, not that they're mainly reading a D&D character article. The difference is just one of simplicity, and what I mean by "What happens to the rest is of course your concern, not mine" is that I felt that in this singular (atm) case the article was a different matter than the template was intended for and a General VG character template would handle it with more simplicity for our readers: there's no confusion as a result. Lastly there's nothing to say the template won't see usage in subsequent vg character articles, just nobody has presented any with any real notability. Now do you understand?--Kung Fu Man (talk) 08:42, 10 September 2008 (UTC)

Minsc is somewhere on the border between a VG character and a D&D one - he's not even a player character, just a controllable NPC. I doubt very much that many other articles will use the template in future given that Baldur's Gate came out ten years ago and right now Minsc is the only D&D VG character on the entire encyclopedia notable enough for a standalone article. I don't see that there's anything literature-specific to the D&D infobox except that it is predominantly used by literary characters - which is hardly surprising given the ratio of D&D books to D&D games. If you think the field orders in the D&D template should be reversed then so be it - but I can hardly be "hearing only what I want to" when only now are you engaging in productive conversation and explaining your position clearly. Chris Cunningham (not at work) - talk 09:01, 10 September 2008 (UTC)

To cut to the chase...the "Dungeons & Dragons character" has no place there as big a part of the header in that infobox it currently holds. The VG template doesn't use it, film characters don't use it, etc. That's better reserved for a parameter of the infobox itself at most, and really should just be mentioned in the article's body itself. The real-world content of the infobox should be presented before the in-universe content. But the thing is after you've done that, it negates the point as the box is just the same as a General VG character & In-Universe comination, just not a uniform format with the other VG characters. It's effectively a pointless endeavor that only has the potential to confuse readers in this case. The IU-template just makes this smoother and ultimately easier to manipulate as well without affecting other relate articles as needed (for instance the issue in D&D where some characters were introduced in only certain editions, which doesn't apply to a video game character. In addition there's an issue that should be brought up as to how many D&D character pass WP:N, but that's another cookie for another time).--Kung Fu Man (talk) 10:03, 10 September 2008 (UTC)

See, now we're getting somewhere. I agree that the big label at the top should be removed - I just wanted to leave the template to cool down for a couple of days before making any more sementic changes to it, in case there was any project feedback. And no, I don't agree that the current template-plus-subtemplate situation is easier to maintain at all - for a start, this arrangement is currently holding up the migration of {{infobox VG character}} to the {{infobox}} framework, which is what kicked this whole thing off in the first place. When it comes down to it, you're got one template which is used across quite a few articles, and one spinoff which is used on one (and is holding up further development of the template it's embedded in) - and that's really all there is to it. Either template is adequate, so there's no reason to have two where one will do. Chris Cunningham (not at work) - talk 10:12, 10 September 2008 (UTC)

That I can understand then...alright then, I wouldn't bother with the other appearances parameter once the real world content is moved upward. That's just an unnecessary section that can potentially get damn huge with some characters. Simply stating which particular series (or multiple series) a character appears in will suffice in such a case alongside a first appearance: further info is best reserved for the article's body. Even the year isn't necessary to note. Homeland I'm tempted to suggest to rename to "Birthplace" to be uniform with existing infobox information of that sort, but that could be a problem with some characters...though then again easily remedied by discussing such a discrepancy in the article body. In a nutshell if this is going to be a joint of the two, it should hug closely to the older standard while being able to cover everything as well. Also I had no idea there actually was such a movement in motion: I know there's been suggestions on doing things to the infoboxes, but nothing of this sort until now.--Kung Fu Man (talk) 10:27, 10 September 2008 (UTC)

Problem with Infobox Sportsperson and Infobox Athlete

Hi, Chris. The medal table in {{Infobox Sportsperson}} and {{Infobox Athlete}} isn't displaying properly – see the article I'm working on in my sandbox. Can help figure out what's wrong? Thanks. — Cheers, JackLee ^–talk– 06:05, 11 September 2008 (UTC)

Fixed. :) {{MedalSport}} just provides a row of a table, in wikitable format - you need to start the table first. Chris Cunningham (not at work) - talk 07:40, 11 September 2008 (UTC)

Oh, right... is the additional line of text you added something that can be inserted into {{Infobox Sportsperson}} and {{Infobox Athlete}}, so that users of these templates don't have to manually insert that line? — Cheers, JackLee ^–talk– 10:29, 11 September 2008 (UTC)

Sure. I'll update the templates. Chris Cunningham (not at work) - talk 10:32, 11 September 2008 (UTC)

Done. I fixed your sandbox while I was at it. :) Chris Cunningham (not at work) - talk 10:40, 11 September 2008 (UTC)

Brilliant! Thanks a bunch. — Cheers, JackLee ^–talk– 12:24, 11 September 2008 (UTC)

The killing of ‘evil’ curly quotes

May I ask as to the reasoning behind your edit summary, and why such quotes are ‘evil’ and deserve to be ‘killed’? — Lee Carré (talk) 11:24, 11 September 2008 (UTC)

"The exclusive use of straight quotes and apostrophes is recommended. They are easier to type in reliably, and to edit. Mixed use interferes with searching (a search for Korsakoff's syndrome could fail to find Korsakoff’s syndrome and vice versa).". Chris Cunningham (not at work) - talk 11:29, 11 September 2008 (UTC)

Right, fair enough then. However, as the cause of the conflict is policy/guideline rather than opinion, perhaps you know what is being done to resolve this, or could point to me a relevant discussion?

The reason I ask, is that this guideline seems nothing more than a work-around for lacking implementation.

Unicode normalisation immediately resolves the problem of searching for equivalent characters, and if correct Unicode characters are more ‘difficult’ to enter (reliability is only a factor of implementation; Unicode is very reliable), then the interface is lacking. This work-around seems to reduce the incentive to make technical improvements to the MediaWiki system, despite the cost to correct semantics and readability. — Lee Carré (talk) 12:42, 11 September 2008 (UTC)

To the best of my knowledge nothing is being done about it, because there's a general consensus that it isn't broken. It is incredibly unlikely that the "interface" will improve much in the near future, having been fairly static for the last 130 years. Notwithstanding our insane edicts regarding the use of dashes, Wikipedia's typographical rules are generally pragmatic in nature, and the small gains in readability (practically zero on contemporary computer displays) and semantic value (again, next to none with current technology) from curly quotes have been judged to not be worth forcing users to adopt punctuation which doesn't actually appear on their keyboards. You could try asking on WT:MOS, but the suggestion is shot down fairly routinely if I recall. Chris Cunningham (not at work) - talk 13:06, 11 September 2008 (UTC)

The most sensible course of action, to me, seems to suggest not becoming involved. Sadly I've had many such discussions and various oddities of MediaWiki and Wikipedia policy. Not placing the blame anywhere (I can understand the reasoning behind the current policies, despite the flaws in it), but I can't help but see this as yet another reason Wikipedia doesn't really want to be taken seriously as a real encyclopedia or as referrence material.

However, to facilitate some form of useful discussion in our own particular conversation, some counter-points to your own:

By ‘interface’ I was referring to, for example, the ‘edit box’, which contains non-keyboard characters. There are many different ways (outlined in the Unicode spec) for entering non-keyboard characters; a ‘character map’ is one of them. Still; keyboard interface has changed in the past 130 years I'm afraid; ergonomics and key-layout/key-position are two major ones (see Dvorak Simplified Keyboard for an example). People remaining ignorant of them, or refusing to adopt (which is their right to do so) is a different problem, and personally should not be used as an excuse. Ease of editing, and the quality of the outcome seem inversely proportional in my experience.

I notice you changed my previous comments from a paragraph to something involving a definition list (as far as the client-side source code is concerned). Please don't; as it affects semantics, and thus accessibility (a definition list is not a paragraph of text). This is a classic example of ease-of-editing vs. semantics & quality.

Unless there is empirical evidence, claims about benefits/gains/advantages vs. the opposites can not reliably be made. Those with higher-resolution displays may well appreciate the serif-like nature of correct typography, rather than the corruption which came from typewriters. Many users print articles/documents, and most printers (even rather old ones) are quite capable of a sufficient resolution to print serif-marks correctly. Limitations of current technology are just that, technical limitaions. The value to readability of serif-marks has been a long-proven fact. It is exactly the reason professional print publication still uses serif fonts, such as in books.

The semantic value may not be apparent to someone using a graphical browser. Using correct opening and closing quotes (as well as a separate character for apostrophes) allows things like screen readers to better convey to the user the nature of the text. As you mentioned, correct dashes is a good example, such as the use of a En Dash to indicate a range (likely pronounced as “to” — as in “5–10 years”). I imagine it would also help sophisticated crawlers/archivers (the usual suspects come to mind here) better determine quote boundaries. Imagine a quote within a quote, and an algorithm trying to find which of the following 3 quote marks is the closing one for the first level quote, if they are all indentical. I wouldn't like to try it. But with correct opening and closing quote marks, it's quite easy.

This is, yet again, something in which WP only seems to be interested in fence-sitting. A good example in this context is support for, and use of Unicode in the wider context. A classic argument is that a lot of fonts don't contain the glyphs needed. The obvious solution is to use fonts which do (either by choice, or on the Web via @font-face in CSS). This simply results in continued ignorance, and no improvement of support for Unicode, because none is demanded. My line of thought stems from the notion that WP consessus thinks that ease of editing should over-ride the quality of the outcome. Yes this makes it easy to edit, but significantly reduces the usefulness, reliability, credibility, and trust of WP as a resource. Ease of editing is pointless if the content is of low quality. Would a respected encyclopedia or dictionary allow someone off the street to come in and edit things? Of course not. Quality and conveyence of authority (and thus trustworthiness) are the over-riding factors in pretty much any factual content. Wikipedia's open policy hinders the achievement of a high-quality outcome, and results in conflicting and contradicting guidelines, many of which run counter to well-established guidelines and style manuals.

I mean, to give an actual candidate solution (many people seem oblivous to the fact that there are any), a parser/replacer combo could be run on text which is submitted as an edit, to replace ‘easy-to-type’ characters with the correct ones (where it is unambiguous). This is infact the very approach many people who use Unicode correctly employ. Typed text is entered using the typewriter characters, to then be searched & replaced with the correct ones. This seems the best way to achieve both goals; ease-of-input, and quality-of-output.

Perhaps you can now see the cause of my disillusion with the goals of WP. — Lee Carré (talk) 15:36, 11 September 2008 (UTC)

I'm not going to address all of that, except to say that we evidently approach the semantic argument from different angles. To me, using colons to indent threads imparts semantic information in that there is a codified meaning to such indenting in wikimarkup. The HTML produced is irrelevant, because it's just a presentation format. (I'd also note that the easiest way to get two different experts on the Semantic Web to knock hell out of each other is to lock them in a room together and start talking about the meaning of definition lists.) Paragraphs with styled indents mean nothing, because the relation between different users' comments is lost. To me, your markup has lost information, as well as making the wikimarkup (the true semantic medium) harder to read. And I'll thank you to allow me to format text on my own talk page as I see fit, because I'm the one who has to maintain it.

For the rest of it, I'm afraid that I'm really not prepared to act as a surrogate for the whole of Wikipedia's policy decisions. I argue to get them changed when they don't make sense to me; I put up with them when that doesn't work. Addressing your concerns to me isn't likely to get anything changed unless I happen to agree with it, and in this case I don't, particularly. Chris Cunningham (not at work) - talk 15:47, 11 September 2008 (UTC)