This is an archive of past discussions about Wikipedia:Manual of Style. 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.
RfC - Are curly quotes acceptable in mature articles? XXX
One editor proposes to allow typographic quotes in mature, stable articles, with the burden of converting straight quotes (inserted by editors who are not willing/able to edit with curly quotes) to fall on editors who like typographic quotes. He has edited the Wikipedia:Manual of Style accordingly. Some other editors have voiced objections on the basis that curly quotes are too difficult for most editors to edit. For previous discussion see "Curly quotes again" above.
The complications to editing, along with the problems that come with stylistic heterogeneity (such as issues with searching), outweigh the meagre benefits of having typography that a subset will find slightly more pleasing. I also agree with above editors that no consensus was found for the change. Ilkali (talk) 23:03, 21 September 2008 (UTC)
Concur with all of the above. This is simply more "asking the other parent". I'm sure it'll come up again in 6 months or so, and again 6 or so after that, in the same tendentious way, from the same 1 or tiny handful of editors who see only their desire for curly quotes and refuse to acknowledge the problems associated with them. — SMcCandlish [talk] [cont] ‹(-¿-)›00:29, 23 September 2008 (UTC)
I don't like the idea of curly quotes in Wikipedia, not even in mature articles. In my opinion they contradict the wiki principle of keeping everything as simple as possible. I also cannot detect a consensus for the MOS change that prescribes curly quotes in mature articles, and it is incomprehensible to me how anyone can feel justified to edit war for them. On the other hand it's probably not wise to edit war against them, either. How about starting dispute resolution? --Hans Adler (talk) 14:42, 23 September 2008 (UTC)
The RFC bot kept removing the RFC template from this page with a message that it was deleting an old RFC, even though the template had been placed only a few minutes before it was deleted. --Gerry Ashton (talk) 18:40, 22 September 2008 (UTC)
Two proposals
I propose that long and/or contentious arguments, such as the ones starting currently at the top of this page, move to lightweight dispute resolution forums, such as WP:Third opinion. This page serves as a noticeboard and a help page, and arguments such as the ones above are distracting to those functions.
This might be a bad idea, but I'd like to throw it out. I propose that we ask the devs to force straight double-quotes in article-space to appear as curly quotes, alternating left and right. This will of course make the page look like crap if someone put one double-quote on a page for some reason I can't think of, or because it was a typo. But in either of these cases, I'd rather the page look like crap, to alert us to the typo or odd use of a double-quote. (Of course, this will work much better if someone runs an intelligent bot which is good at finding pages with this kind of typo, so that the page doesn't look like crap for too long.) This has the side-benefit of potentially resolving the above long-running argument. - Dan Dank55 (send/receive) 18:30, 22 September 2008 (UTC)
Good point! That's embarrassing. I'm not talking about fiddling with single quotes btw, that would be way too hard. Can you think of a reason to use double-quotes in this context where they wouldn't immediately follow the degree symbol? P.S. Now I know why I didn't think of it (does this let me wriggle out?) ... WP:MOSNUM specifically recommends using a template, and what the template produces looks like curly quotes to me. So...if someone is using double-quotes for arcseconds, I'd want the bot to flag that, too. Sounds like a job for Supermouse, I mean Lightmouse. - Dan Dank55 (send/receive) 18:46, 22 September 2008 (UTC)
The (relativistic) precession of Mercury is 43"/century. (Note that it is no solution to say it can be recast; you still leave the physicist who has added the sentence, and has no idea why it's become gibberish, in the lurch.) But this is, unfortunately, a good example of why this project, with no central sysops, covering many topics, with random volunteer editors, needs to be WYSIWYG. Date autoformatting is another non-WYSIWIYG, and look how much trouble it's caused. SeptentrionalisPMAnderson18:57, 22 September 2008 (UTC)
I completely agree that we need to be WYSIWIG, and you're right, my proposal crossed that line. Hm. I'm not sold on it, still, but is there any way to salvage it? Are there algorithms that would be reliable 99.99% of the time that would figure out which way the double-quotes should slant? Every example mentioned so far seems easy to interpret as either a quote or not a quote. - Dan Dank55 (send/receive) 20:10, 22 September 2008 (UTC)
I don't think it matters. You have already said that since the single quote is also the apostrophe, it would be too hard to handle single quotes. But with nested quotes, a single quote may appear next to a double quote, and it would look bad if one were slanted and the other was not. --Gerry Ashton (talk) 20:18, 22 September 2008 (UTC)
Ah, I didn't think of that. Okay, it's dead. I can't think of a way for a bot to figure out apostrophes and the other uses of the single-quote. - Dan Dank55 (send/receive) 20:26, 22 September 2008 (UTC)
False statements of consensus
There is no "consensus" around the optional use of curly quotes in established articles. It is flat-out opposed by basically the entire body of editors who opposed the initial proposal. This is the third time that such a falsehood has been used in reverting the section back in, and I'd appreciate it if editors acted in good faith and ceased making out that some compromise had been agreed to when nothing of the sort has happened.
Per the section above, Mayalld proposed the following guidelines in the MedCab case. I would like to ask whether the experts on MOS feel that these guidelines accurately reflect the current state of MOS, policies, guidelines, and thoughts on the matter. And if they do not accurately reflect the current state, should they?
Principles
Left aligned images should not be used immediately at the start of a section.
Left and right aligned images directly opposite each other tend to distract the reader and should be avoided (staggered left/right images that overlap are OK).
Image stacking that overlaps into the following section on any brower (not just the browser used by the editor) is to be avoided at all costs.
The gallery feature is available where there are many images that should be included.
White space is unwelcome, and we should avoid it if possible (but not at the expense of allowing an image stack to invade the next section).
Guidelines
In these guidelines, the likelihood of an event should be taken by reference to a 1024x768 screen resolution.
Any decorative images should be culled.
Where there is scope to do so, text should be expanded to increase the scope to add images.
Where there is scope to do so, additional paragraph breaks can be inserted to both expand the text size without introducing white space, and bring forward the first opportunity for a left-aligned image. This measure should not involve the introduction of arbitrary paragraph breaks.
Unless there is a risk that an infobox will encroach in the right column, the first image in a section should be placed at the head of the section, right aligned.
The next image (or first image if the infobox encroaches) should be placed at the start of the second paragraph in a section, left aligned.
Subsequent images should be placed alternately left and right (infobox permitting). If an infobox is likely to encroach into a section, we should only add left aligned images every other paragraph until the text will have passed the foot of the infobox.
Where this is still likely to cause image stacking into the next section, images should be prioritised, and the lower priority images placed in a gallery at the foot of the section.
Other than cases where the infobox is likely to go right through a section, sections where there is a risk of image stack may be closed with {{clear}} to ensure that even on odd broswers we don't get image stack.
Where an infobox is likely to go right through a section, and we are using only left-aligned images, we should use {{clearleft}} rather than {{clear}}.
Action proposed: Delete one of the WP:ACCESS sentences.
Brief reasons for proposal (link to any relevant discussions, if helpful):
Something has to give, I think. WP:ACCESS says "Do not place left-aligned images directly below second-level (===) headings, as this can disconnect the heading from the text it precedes, when read with larger fonts. Instead, either right-align the image, remove it, or move it to another relevant location.", and also says:
"As explained above for the lead section, each section should have a specific structure:
MOS:IMAGE says "Avoid sandwiching text between two images facing each other." WP:ACCESS seems to be suggesting that the first image should always go before any text in a section; it's definitely suggesting that for lead sections. In general, it's impossible to follow that rigid placement guideline and also never have text between a left and right image, because an image may drop down from the previous section (unless you're willing to introduce a lot of white space, but I don't think that looks encyclopedic, unless there's no other choice.) - Dan Dank55 (send/receive) 21:10, 23 September 2008 (UTC)
[I deleted a lot of stuff that got transcluded into the middle of my message here; must have been some weird template error. I've added "nowiki" tags to make sure it doesn't happen again. - Dan Dank55 (send/receive) 18:25, 27 October 2008 (UTC)]
WP:TLDR. We have several (sometimes competing) image requirements. When all requirements can't be met simultaneously, I prioritize them as follows:
WP:ACCESSmust be met, otherwise we make our readers who use screen readers miserable. This means watch the order of items in sections, no left-aligned images under third-level headings, images within sections not above them, and captions on all images.
No images looking off the text and no text squeeze between images, per WP:MOS#Images. Do these whenever possible, and they are almost always possible.
Left-right alternating is purely cosmetic, last priority, do when possible, bt don't sacrifice No. 1 or No. 2.
My reading is that it does suggest that, based on the verbiage "should have a specific structure" and a demonstration of that structure. Can you comment on "Unless there is a risk that an infobox will encroach in the right column, the first image in a section should be placed at the head of the section, right aligned."? Prince of Canada t | c21:24, 23 September 2008 (UTC)
There are only two key points to be resolved here, as I see it: 1) whether or not the first image in a section must be right-aligned; and 2) whether or not any image or infobox may span a section divider. Dank55 has already picked up on 1, which, in more detail, seems to centre, first, around how literally the WP:ACCESS example is taken, and then about how that affects and/or conflicts with other guidelines. 2 is another matter which I can't find any guideline on; the only associated words I came across on the subject are a discouragement of forcing breaks and creating white-space. I think the aversion to images crossing section headers is unique to User:PrinceOfCanada; indeed, it seems to become even more a matter of personal tastes when one takes into consideration his further breaking down of this no-crossing-"policy" to differentiate between crossing images that "cause formatting issues" and those that don't, disallowing the former but allowing the latter. Of course, what the formatting issues are is unclear and possibly only related to personal opinions; I say that because the articles this dispute has touched remained undisturbed in this matter until PrinceOfCanada came along. --G2bambino (talk) 21:33, 23 September 2008 (UTC)
Allow me to correct the various lies and misrepresentations above.
As I have repeatedly made clear, my aversion to images crossing section headers is as follows: left-aligned images crossing section headers can produce unsightly subsequent sections if the image stacks below; the headers can be 'pushed' to the right, depending on browser resolution, thus disconnecting the header from the text below.
As I have likewise made clear on multiple occasions, right-aligned images which cross section headers are only a problem if they can cause image stack in subsequent sections, which is very specifically deprecated by guidelines.
Representing either of my positions as 'unclear' is a lie, and you know it, given how many times I have stated my position, as above. Please stop doing this. Prince of Canada t | c21:44, 23 September 2008 (UTC)
I should remind you that an opinion - and one clearly expressed as such - is neither a misrepresentation, nor a lie. Regardless, those of your points that aren't already moot don't contradict mine. --G2bambino (talk) 22:27, 23 September 2008 (UTC)
Saying that the formatting issues are unclear is a lie, when I have made it abundantly clear to you precisely what those issues are. You know it, I know it, now stop it so that we may actually have a productive discussion without your derails. Prince of Canada t | c22:32, 23 September 2008 (UTC)
Do not accuse me of lying about my own perceptions. You may hold suspicions or theories, if you like, but you do not know what I see or think. I am entitled to my opinion, and I expressed it. And those are my last words on this particular issue, as the only attempts at derailment here are those to bring this discussion off into the realms of imagined attacks and baseless accusations. --G2bambino (talk) 22:50, 23 September 2008 (UTC)
I'm having a hard time understanding 1) why an unrelated MedCab is trying to rewrite guidelines (that's done here) without 2) even consulting our readers who use screen readers at WP:ACCESS. On the other hand, I'd hate to see the ACCESS talk page burdened with this kind of verbosity. I've not yet found a situation that can't be resolved by prioritizing conflicting image concerns as I stated above, and there seems to be some over literal interpretation of the image guidelines, so I don't see what the problem is, and will oppose any change until someone can state it in something less than a book chapter. Is there a POV issue going on about images in some article at MEDCAB? That's what is usually behind these kinds of wonky concerns. SandyGeorgia (Talk) 03:29, 24 September 2008 (UTC)
Graham (an expert on Wikipedia screen readers) and I exchanged some ideas on our talk pages last night. He feels strongly that the first image link for a section heading should not be just above the section heading. The problem is, people do this, a lot, when the total vertical length of images is greater than the total vertical length of section text. I've asked a template person for a fix. - Dan Dank55 (send/receive) 11:48, 24 September 2008 (UTC)
Just to clarify on the MEDCAB issue. I was the mediator there, and the "guidelines" are an attempt to reach a compromise, within the bounds of the currently very sparse guidance provided by MoS on the point, that two parties with very divergent and incompatible views of what the guidelines mean might agree upon as a fair interpretation of MoS (we were attempting, not to rewrite the guidelines, but to seek to interpret them, and reach an agreement on a way of working that would ensure we didn't end up with disputes. Sadly, agreement was not reached. As such, I brought this here, with the objective of getting more input from people with a better handle on MoS than I do, to consider whether things might be easier if the guidelines were more detailed. As SandyGeorgia says, discussions on setting new policy belong here! Mayalld (talk) 20:12, 25 September 2008 (UTC)
It seems that the main issue is the one that Dan and Sandy disagree on; namely, whether or not the first image should always go before any text in a section. What is the reality on that matter? As I see it, the WP:ACCESS code example is just an illustration of where to put an image if it does come before all text; i.e. after the header and first links, but before the text itself. --G2bambino (talk) 05:02, 27 September 2008 (UTC)
I don't disagree with anything Sandy said above. The only problem left over for me is a problem I have with the devs (as usual). Anyone looking at an image that is entirely contained in one section would assume the image belongs with that section, wouldn't they? Including images that start on the same line as the heading ... but to get that effect, you have to put the image link just before the heading, and the devs in their wisdom have put these images in the previous section, which makes it harder for everyone, blind or not, because then you have to click the section above if you want to edit that image. The makers of screen readers haven't compensated for this problem (yet), which they could easily do by reading the heading before the image. - Dan Dank55 (send/receive) 14:07, 27 September 2008 (UTC)
Oh, sorry. From Sandy's response to your statement it seemed like there was disagreement on whether or not the first image should always go before any text in a section. That same question seems to be the crux of the disagreement that led to the start of this discussion. But, to be more clear, there's no confusion about placing an image for one section in the preceeding section; everyone seems to accept that as verbotten. Where the vaguery lies is in the legitimacy of having a left-aligned image as the first image in a section (at least one paragraph in, as per MOS). Or, in other words, must the first image in a section always be right-aligned and come between the header and the text? One user seems to think the latter is true, while another user thinks the former is perfectly allowable. --G2bambino (talk) 20:51, 27 September 2008 (UTC)
Do not place left-aligned images directly below subsection-level (=== or greater) headings, as this can disconnect the heading from the text it precedes. This can often be avoided by shifting left-aligned images down a paragraph or two. What does this mean?
Text can indeed be placed between headings and images.
In level-two headings (==), images can be placed on the left.
What issue in specific? The apparent disconnect of a section's text from its heading is a problem with left alignment of images directly below the heading, but level-two headings have a line running the width of the page, providing some "connection". And since level-two sections are the building blocks of articles, and generally larger than the rest (and not necessarily subdivided), I'd expect images thus positioned not to straddle other sections as often as in smaller, lower-level (or higher-level?) sections. Waltham, The Duke of23:03, 27 September 2008 (UTC)
Fooey on all of this. Billiard ball uses left-aligned images right after headings several times, and it works out just fine. Putting them all to the right does not work, as there are more images than will fit, and there is not enough text in some of these places to move the left aligned image a paragraph or two later (what paragraph or two later?). Tempest in a tea pot, as far as I'm concerned, this MedCab case. Important: I think MOS needs to stick to a) Matters of writing and coding style that have some impact on readabilty, usability, accessibility, editability, consistency, and reusability, primarily; b) layout issues that have something to do with those concerns (use of headings, where hatnotes go, images having captions, tabular data being in actual tables, etc.); and pretty much stop there. "Style" has many meanings, but "layout aesthetics" need not, and in my book should not, be a part of the definition here. It's a subjective can of worms, there are way too many worms wriggling around here already that this person or the other can work themselves up into a froth about. — SMcCandlish [talk] [cont] ‹(-¿-)›07:42, 3 October 2008 (UTC)
P.S. There aren't many people who would mind if you always go with 's after a singular noun ending in a sibilant sound, or always go with ', or go with ' after two back-to-back sibilant sounds (Kansas') but 's after just one (NYTM recommends this at "Possessives"), or go with just ' for ancient proper names (Moses'). I have a hard time getting fussy about this when style guides are all over the place. - Dan Dank55 (send/receive) 13:13, 4 October 2008 (UTC)
Indeed. I consistently use 's no matter what, and as far I have noticed I've never been reverted on it, even when changing extant text (e.g. Jones' to Jones's). — SMcCandlish [talk] [cont] ‹(-¿-)›00:06, 6 October 2008 (UTC)
For my own aesthetic purposes, the s's just drives me up the wall. The s' looks much more svelte and concise (and following: efficient and logical) than the duplication. — pd_THOR|=/\= | 02:01, 6 October 2008 (UTC)
Update to the update: WP:Layout looks ready; there's ongoing controversy over Wikimedia projects, but the page is mature. For the other pages, I'd like to start some discussions on the talk pages and put off doing an update for a month. WP:CITE has a lot of stuff borrowed from other pages; maybe we can get either less duplication or more transclusion. WP:EL has a very long list that might be shortened. WP:Footnotes has a lot of CSS stuff and a couple of other problems. - Dan Dank55 (send/receive) 13:51, 5 October 2008 (UTC)
Stanton, we should absolutely discuss CSS stuff on some pages, but some readers will stop reading if they're looking at stuff that looks like programming code to them. I'd like to keep code out of Category:General style guidelines when possible, but there are 91 pages in Category:Wikipedia style guidelines, and I don't see any reason to keep stuff that looks like code out of all 91 pages, if you think it's helpful. Tony, that's not an actionable oppose :) What's your question? There's a cat called General style guidelines with 25 pages that's been around for 5 months now, and a variety of people, including the Duke, find it useful for dividing the style pages into pages that apply to all articles vs. pages that apply to specific wikiprojects or specific kinds of pages. There are admission standards; I'm going to start some conversations on the talk pages of EL, FOOTNOTE and CITE this month to see if we can make the pages a little tighter and therefore a little easier to maintain; I mentioned the general issues above. If we can do that, then I'll throw them in the cat and do the monthly updates for them every month. Btw, everyone, this month's WP:UPDATE for the general style guidelines is ready. - Dan Dank55 (send/receive) 02:43, 6 October 2008 (UTC)
Oh, wait, maybe you were asking about my objections. Long lists of examples of things that do work and don't work, such as we have at WP:EL, are an open invitation for everyone to come by and add their favorite examples. Even when we have one example, people will sometimes take that as an invitation to swap in their favorite example (as happened IMO recently at WP:MOSCAPS, see talk), so I will take an axe to even a single example when it doesn't seem to add much. FOOTNOTE includes an implied warning to be on the lookout for SEWilco's bot; that's silly, the relevant bot is RefBot, which has hardly run at all in 3 years. FOOTNOTE also has too much CSS for my taste. A little more than half the information at CITE is duplicated at other pages, which makes it a pain to maintain; I'd like to discuss either transcluding material or perhaps doing without some of it. - Dan Dank55 (send/receive) 04:55, 6 October 2008 (UTC)
Some people think it's absurd that our poor editors have to go to multiple locations to learn about linking. There's now a proposal here to merge the first two into WP:MOSLINK. Your input is welcome. Tony(talk) 12:29, 6 October 2008 (UTC) --HighKing (talk) 16:04, 7 October 2008 (UTC)
En dash spacing question on year ranges
When writing a range of years, do you write it with spaces between the year and the dash (1787 – 1896) or without spaces (1787–1896)? Dabomb87 (talk) 01:59, 8 October 2008 (UTC)
No—it's much harder to read that way. Use a spaced en dash only if there's one or more internal spaces within one or both items (August 23–25, 1981; August 23 – October 13, 1981, where in the first example the items are 23 and 25, and in the second example include the names of the months, with internal spaces). Tony(talk)02:13, 8 October 2008 (UTC)
Hiya Jacq9. On almost all talk pages, new comments should go at the end. If all this stuff is confusing, don't read it. Professional writers often divide up the job between people who gather information and organize it and write it down, and other people who worry about a lot of details that the writers don't care about. I see that you haven't had a chance to do much writing of your own on Wikipedia yet. Pick a topic, look at what some other people have written about it, and then write something that we don't already have here. Don't worry about complying with any rules. It's probably a good idea to create it as a subdirectory of your userspace, say "User:Jacq9/Sandbox", otherwise it might get deleted for various reasons. Then let us know, and I'll have a look, and you can decide if my copyediting makes your article better or worse. - Dan Dank55 (send/receive) 18:55, 8 October 2008 (UTC)
It is relevant, but the name of the section should be changed to "Quotation marks and apostrophes", or else the curly v. straight stuff should be separated out into a separate section. Or something like that.--Kotniski (talk) 09:33, 6 October 2008 (UTC)
Likewise, the NOAD defines the apostrophe as a punctuation mark. It just happens to be a word character, and not sentence punctuation. —MichaelZ. 2008-10-06 16:57 z
Dashes et al. and company names, film titles, etc.
It is a rather general issue. I can't say I've looked too hard, but I don't think there is any guideline specifically mentioning a different treatment of copyrighted names like Hanna-Barbera, which according to our naming conventions should have an en dash, but which nevertheless are not only known by their hyphenated (or otherwise) version but are actually legally protected in this form. I suppose we are to retain them in their original form (and thus an album title with a year range would keep its hyphen), but I'm not sure of what others think about this and whether there is any guidance on the subject. Waltham, The Duke of02:15, 23 September 2008 (UTC)
I doubt that Hanna-Barbera's trademark protects the name with a hyphen, but not with an en dash. This is a matter of typographic style, and not legal name. —MichaelZ. 2008-09-23 03:17 z
Hanna-Barbera should have a hyphen, whether a trademark or not, unless the company itself uses an en dash (which would be eccentric). BTW, Anderson, most people use and see redundant wording—doesn't mean we should. Tony(talk)04:16, 23 September 2008 (UTC)
The glyph chosen in a particular context is a matter of style, and doesn't change the substance of the name. Its choice can be a matter of a typist using the only ‘dash’ character he knows how to type on his keyboard, or of a typographer going by a house style for hyphenated names, or of a poster illustrator choosing a 2/3-em dash as having the best proportion for careful setting in a particular display typeface.
This one is a slightly unusual case, because it doesn't neatly fit perfectly into the established cases for hyphens and dashes. One might choose a hyphen for a single hyphenated last name, but this isn't that. One might choose an en dash to represent the equal relationship of two entities, much as this is standard in examples like New York–London flight (see en dash). But then one might decide to follow the Chicago Manual's still more specific rules, and use a hyphen here anyway.
Since there is no definitively correct choice here, I would stick with the simpler hyphen, at least until we formulate more specific rules. —MichaelZ. 2008-09-23 16:47 z
First of all, a correction: it's New York – London flight; the unspaced en dash hints at a new flight between York and London (rather unlikely—the nearest you can get is Manchester).
Now, to the point. As far as the specific example is concerned, I'm not sure the simplified rule applies: following the same logic, the aforementioned flight is one thing, not two. It matters that it joins in its name two distinct entities (the two cities), as does Hanna-Barbera (Hanna and Barbera). I am not saying that we should use an en dash, but that this case is not as easily pigeon-holed as most others are. Actually, now that I'm looking at the article, I see that the proper name of the company is Hanna-Barbera Productions, which looks like a pretty clear case of en dash over hyphen. Does the exclusion of Productions make a difference? (shrugs)
In any case, let's keep our perspective. This is meant to be a general discussion about things like Slay Tracks (1933–1969) (the article of which used to have a hyphen, though I now see is fully updated throughout, dash-wise). Michael supports conversion, P. M. Anderson seems to be against, and I am on the fence. Waltham, The Duke of19:10, 23 September 2008 (UTC)
[I did mean a flight from New York to London, and only after I saved the above did I find the identical example at en dash—sorry I didn't realize that's impossible. Let's say New York–Washington train. En dashes are generally used to represent “A to B” or “A and B” entities, while hyphens often represent a single compound AB. —MichaelZ. 2008-09-23 19:26 z]
Actually, I'd still go with the simplified rule at FAC (but I wouldn't pay much attention in a C-rated article), I like: Egypt–Sudan relations (because "relations" implies a connection between two different things), but Egypt-Sudan office (because "office" doesn't imply anything going on between Egypt and Sudan, it's just one thing, an office that handles affairs for Egypt and Sudan.) - Dan Dank55 (send/receive) 19:33, 23 September 2008 (UTC)
I'd go with the hyphen in this case, since it's a name for a business entity. They could have chozen SD-Quizzlpoop, or M-Narglegle, or whatever. That the "symbols" in the name are representative of real people is neither here nor there. The name sounded out-loud is "Hanna Barbera", not "Hanna to Barbera", "Hanna and Barbera", etc. "New York–Washington train" is usually "New York to Washington train" (albeit some newscasters actually don't sound out anything for such uses of en-dashes; I have heard them say things like "US China relations". It makes me want to ask, "Is US China anywhere near the US Virgin Islands?"). — SMcCandlish [talk] [cont] ‹(-¿-)›07:08, 3 October 2008 (UTC)
– Not a MoS matter, and no consensus on usage anyway.
I seriously think the MoS needs a which-versus-that section. Far too many otherwise-good contributors use ‘which’ or ‘that’ incorrectly (particularly ‘which’). Misuse can be incredibly confusing to those familiar with the difference and incredibly ambiguous to those who aren’t.
What do you suggest? You are presumably one of those people who believe that "which" should not be used in cases where "that" can be? I've seen opinions divided on this matter, so it may not be possible to reach agreement here either.--Kotniski (talk) 08:23, 3 October 2008 (UTC)
No way. The MOS is not about prescriptive grammar; please note that it no where has any sections like this – passive voice, split infinitives, sentence-ending prepositions, run-on sentences, or any other grammar issue not related to WP concerns of readability, usability, accessibility, editability, portablility. WP assumes that its editors already know who to write English prose properly. If they don't, they will not have a very good time here and will eventually go away to finish school, and come back someday we hope. — SMcCandlish [talk] [cont] ‹(-¿-)›08:22, 3 October 2008 (UTC)
That was prevalent in early Middle English, which began to be used in the 14th century. "By the early 17th century, which and that were being used pretty much interchangeably." They have quotations from Shakespeare and the King Jame Bible (1611 version), e.g. "Render therefore unto Caesar the things which are Caesar's; and unto God the things that are God's." Apparently that fell into disuse in late 17th century literary English and reappeared in the early 18th century, against some opposition. This episode weakened the use of that in non-restrictive senses, and recently it has become unusual.
Which has never been weakened in either the restrictive or the non-restrictive use; some people try to prescribe the restrictive use, presumably because they want a clear and simple rule: "Use which in this type of situation, and that in that type of situation." But many of these presriptivists don't even follow their own rule, because it's plain wrong. Even Fowler admitted it's not a general rule:
"... if writers would agree to regard that as the defining relative pronoun, & which as the non-defining, there would be much gain both in lucidity & in ease. Some there are who follow this principle now; but it would be idle to pretend that it is the practice of "our most idiomatic writers."
E.g. Strunk and White recommend "which-hunting" (i.e. replacing it by that in restrictive cases), but White himself used restrictive which: "... the premature expiration of a pig is, I soon discovered, a departure which the community marks solemnly on its calendar." ("Death of a pig")
Although the two words’ usage conflicts, the rule is of general consensus.
Even Fowler admitted it's not a general rule:
"... if writers would agree to regard that as the defining relative pronoun, & which as the non-defining, there would be much gain both in lucidity & in ease. Some there are who follow this principle now; but it would be idle to pretend that it is the practice of "our most idiomatic writers."
Fowler was remarking on the rule’s use; he does not dispute the rule itself. Indeed, it seems he is criticizing the rule’s lack of followers, which would “gain in both lucidity and in ease”—that’s a good thing.
E.g. Strunk and White recommend "which-hunting" (i.e. replacing it by that in restrictive cases), but White himself used restrictive which: "... the premature expiration of a pig is, I soon discovered, a departure which the community marks solemnly on its calendar." ("Death of a pig")
E.B. White isn’t contesting the rule itself; he’s simply not following it. The Elements of Style still clearly outlines the difference:
“That is the defining, or restrictive pronoun, which the nondefining, or nonrestrictive.”
Ultimately, following a consistent guideline will reduce ambiguity, follow an established English rule upheld by authoritative experts, and introduce zero negative side-effects. The EoS agrees:
“But it would be a convenience to all if these two pronouns were used with precision.” (page 53 on edition 3)
In general, I’m wondering if ambiguity is under-addressed in Wikipedia.
“All homes which were for sale in the Rannersdorf community in Schwechat caught fire.”
Did every home in Rannersdorf catch fire, all of which were for sale? Or did every home that was for sale in Rannersdorf catch fire? I’m starting to agree with SMcCandlish that it doesn’t belong in the the MoS, but not because it’s prescriptive grammar.
I think that, whether or not it’s appropriate for the MoS, it’s important and should (perhaps) be mentioned somewhere. I apologize if my rebuttal seemed terse.
What do we do when the demands listed by this section conflict? I am trying to alternate left and right on antbird, which looks much much better than all down the right, but I had someone move my imgaes mostly to the right because I also can't "place left-aligned images directly below subsection-level" (see the image at Antbird#feeding) If I push it down a paragraph the image displaces the section heading for mixed species feeding flocks. How important is the "just below section heading" rule? Can I ignore it if it makes the article look better? Sabine's Sunbirdtalk21:03, 8 October 2008 (UTC)
Yes, as with any rule; but I don't think the article will look better with an image just below a subsection heading (I presume you've seen what it looks like - it separates the heading from the text in a rather strange way). For me that's worse than having non-alternated images. (Doesn't matter with section headings, as the ruled line makes the layout acceptable.)--Kotniski (talk) 09:57, 9 October 2008 (UTC)
These skins seem about as stupid an idea as personalized date formatting. Since pretty well all our readers see the same skin, why create extra problems by trying to make people edit for various skins simultaneously? In any case style recommendations should be based on what works in the skin that is displayed to the public (but not neglecting accessibility issues, as pointed out below).--Kotniski (talk) 16:15, 9 October 2008 (UTC)
It's not much of an extra problem though, is it? Apply 'under === headings' to 'under all headings', and the whole thing takes care of itself, and is applicable across all skins. Prince of Canada t | c16:18, 9 October 2008 (UTC)
No, I was just seizing the opportunity to have a general moan about skinning. But are you suggesting now that left-aligned images shouldn't appear just below any heading? Because it never seemed to be a problem with the main section headings.--Kotniski (talk) 16:22, 9 October 2008 (UTC)
I've always felt that way, actually. Based on what Septentrionalis said about how different skins behave, it turns out my personal aesthetic sense might actually have a point. (And, well, seizing my own chance to have a bit of a moan I suppose :) ) Prince of Canada t | c16:24, 9 October 2008 (UTC)
Well, I had a look and I can honestly say I had never noticed it before. Just how stupid are our readers that they can't make that little jump? Would someone liable to be confused by something like that even care about antbirds anyway? Sabine's Sunbirdtalk18:01, 9 October 2008 (UTC)
Oh.... what's a screen reader again? Is there anything I can do? I mean, I took some time picking out the best images that show different behaviours and points but now they are all jumbled up on the side and in some cases not even aligned with their respective sections anymore. Not to mention that it simply looks ugly having most of them down the right. Sabine's Sunbirdtalk18:58, 9 October 2008 (UTC)
The immaculate antbird should be in the ant-follower section, I see that it gets pushed back in place when I make my browser smaller (I am blessed with a big screen). I guess most people don't have that problem, so I guess I'm just moaning.... Sabine's Sunbirdtalk19:12, 9 October 2008 (UTC)
Wikipedia:Facial hair is required for administratorship has been marked as part of the Manual of Style
VeblenBot is sending out this notice for any change to the naming conventions; I'm thinking notice at the Pump about a change to guideline status would be sufficient; shall I ask Carl to change the notification? - Dan Dank55 (send/receive) 19:26, 5 October 2008 (UTC)
I can very easily change the list of categories that are announced here. Just let me know what you want. — Carl (CBM · talk) 02:43, 6 October 2008 (UTC)
Anyone want to weigh in? Are we agreed that we don't want WT:MOS and WP:VPP to be getting a notice saying that "X (naming convention) has been marked as part of the Manual of Style"? - Dan Dank55 (send/receive) 12:55, 7 October 2008 (UTC)
I think so. I'm not entirely sure about the relation between naming conventions and the Manual of Style. However, I do think that it might be useful to have notices left at Wikipedia talk:Naming conventions, specifically tagged "as part of the naming conventions". It is a big family of pages, after all, and it needs supervision. Waltham, The Duke of17:24, 7 October 2008 (UTC)
Hm, no response yet. Should I bring my sock-puppets? :-D
I suppose the "all in favour?" part has to do with stopping the notifications here and not with starting them over at Naming conventions. We'll need a consensus there for that. Waltham, The Duke of02:47, 10 October 2008 (UTC)
Carl doesn't have time right away to rewrite the bot to notify Naming Conventions, anyway. I believe notification of Naming Conventions conversions are now back to WP:VPP. - Dan Dank55 (send/receive) 05:29, 10 October 2008 (UTC)
Someone please refresh me. Are we supposed to type –, or the actual en-dash, "–"? WP includes the dash in the drop down selector underneath the edit summary bar, and User:Cameltrader#Advisor.js converts the code to the actual dash, but AWB from what I remember does the opposite. What's right? Matthewedwards (talk • contribs • email) 00:00, 4 October 2008 (UTC)
I haven't heard of wheelwarring bots before, that's a hoot. SMcCandlish and others argue that when the text is exported from Wikipedia, the only way to know that it will be read correctly is if we write –. They also argue that it can be a little tedious to copyedit the "–", because the hyphen and en-dash look the same in the edit window for most people, so you have to check the text window. Others argue that the dash available as the first character on the edit bar is less intrusive when you're reading in the edit window. My eyes are old, so I prefer the second argument. I also think that a lot of people who export our text won't care much about en-dashes vs. hyphens, and if they do care, they'll probably find a way to get it right. - Dan Dank55 (send/receive) 01:28, 4 October 2008 (UTC)
That's not what I argued (though it is an additional valid point); I argued that in WP edit windows that "–" is for many readers, either because of their eyesight, their font, or both, indistinguishable from "-", and that the only way to be sure that the en-dash is being used is to use the character entity code for it. I convert them to entity codes whenever I see them, for this reason. I think the MOS should mention this and recommend the code while not forbidding the Unicode character (which is, of course, right there in the "Insert" tools below the edit window, so forbidding it would confuse editors). — SMcCandlish [talk] [cont] ‹(-¿-)›04:17, 4 October 2008 (UTC)
Hmm.. if it's not AWB, then it's some other program. I can't think where right now, but I have seen it happen. Damn my memory! So if we see –, that's okay, and if we see "–", that's okay too, as long as the article consistently uses one or the other? Matthewedwards (talk • contribs • email) 05:12, 4 October 2008 (UTC)
No, no, consistency for once is not actually an issue at all. They are the same character, just two different ways to tell the browser to show that character. Either is okay, the longer code is preferable from a coding and editing point of view, not a style one, because it gives us certainty that the proper character is being used. Style-wise, they are precisely identical. (Yes, I realize that was redundant; just making it "extra clear" :-) — SMcCandlish [talk] [cont] ‹(-¿-)›09:16, 4 October 2008 (UTC)
The war of the bots! Will they growl and snarl at each other? The advantage of the gobbledygook version is that it's plain to all in edit-mode; the stupids who designed the font, whatever it is, made en dashes look exactly like hyphens, although em dashes are nicely distinguished ... let's go figure. The disadvantage is that the gobbledy is a nuisance to type and ugly to look at. I use the plain dash, I'm afraid. Tony(talk)05:55, 4 October 2008 (UTC)
Nuissance to type is a valid issue, and why I don't advocate that MOS mandate it (it should mention why it is better from a coding perspective, though – it's actually significant that editors often cannot tell that the correct character is there), but ugliness isn't, since source code is always ugly from a display perspective, even when it is elegant! Heh. — SMcCandlish [talk] [cont] ‹(-¿-)›09:24, 4 October 2008 (UTC)
And it should also mention that a line with multiple –es can be hard to read in edit space, and so hard to edit. (Our source code is often no uglier than plain-text; often it is plain-text.) SeptentrionalisPMAnderson15:51, 4 October 2008 (UTC)
It's not any harder to read or edit than anything else we add in source code, like tables, templates, and images; considerably less so in many cases. PS: You don't have to do <nowiki>&ndash;</nowiki> to show that code; just &ndash; will do the trick. — SMcCandlish [talk] [cont] ‹(-¿-)›23:56, 5 October 2008 (UTC)
The edit history will show that I began with <nowiki>–</nowiki>, which does not work. I then made the minimal alteration; if your sense of elegance forbids the redundant code, feel free to alter my post. SeptentrionalisPMAnderson16:38, 6 October 2008 (UTC)
The only time Wikipedia source code is plain text for very long is when no markup of any kind has been done on it, in which case it will probably be slapped witih {{Wikify}} and is also highly likely to be a copyvio pasted in from some other site. — SMcCandlish [talk] [cont] ‹(-¿-)›23:58, 5 October 2008 (UTC)
That is true for articles as a whole; but most sentences have no wikification, per Tony's arguments. (I think he takes them further than we need to, but there is no question that a sea of blue is not what we want.) SeptentrionalisPMAnderson16:38, 6 October 2008 (UTC)
So is there a concensus here to use the actual glyphs rather than coding (– and —)? Can this be written into the MOS, or is it just a recommendation? Jappalang (talk) 01:44, 8 October 2008 (UTC)
If it is written into MOS, it really should be phrased as a recommendation; there may be places where we will want to be excruciatingly clear (but they will be rare). I don't see that we need to write it in, unless somebody is being uncivil about an imaginary rule requiring &endash;. SeptentrionalisPMAnderson19:46, 8 October 2008 (UTC)
I agree with Mr Anderson's italicisation of if. I don't see the difference in formats as a problem, and both sides have their arguments. Personally, I usually change dashes into the Unicode version. That doesn't mean I'd like a preference stated in the Manual, however. Waltham, The Duke of03:00, 10 October 2008 (UTC)
I use the GNOME Character Palette to insert Unicode entities but I’d be happy to start using the named entities — and – if it’s easier for other editors to read. It looks like MediaWiki converts the named entities to their Unicode equivalents during parse, which eliminates the problem of browser display of named entities.Dmyersturnbull (talk) 07:32, 10 October 2008 (UTC)
I've come to feel that there are too many parenthesized statements in Wikipedia. In particular, there are too many attempts to add details by cramming parenthesized clauses into the middle of a sentence. Consider, for example, this sentence from Apollo Lunar Module:
In April 1970, the lunar module Aquarius played an unexpected role in saving the lives of the three astronauts of the Apollo 13 mission (Commander James A. Lovell Jr., CSM pilot John L. Swigert Jr., and LM pilot Fred W. Haise Jr.), after an electrical short circuit caused an oxygen tank in that mission's service module to explode.
In that case I would argue that the crew listing of Apollo 13 is unnecessary and just clutters the sentence. In other situations the parens are used to cram in disagreements or modifications of the rest of the sentence:
After the accident, the LM's systems, designed to support two astronauts for 45 hours, were shown to have actually supported three astronauts for 90 hours (at a much lower output than designed, it must be admitted).
Often the parens are part of a run-on sentence:
Like the LM, it has both descent and ascent modules (the latter to house the crew), but unlike the LM, it will incorporate improved computer systems, laser ranging and radar tracking systems for landing, waste-management systems, and an airlock for the crew, eliminating the need to depressurize the entire cockpit and reducing lunar dust tracked into the cabin to a minimum (a problem highly associated with the last three Apollo missions, when crews went into the lunar highlands).
I'm not saying that there is no need for parenning. Acronyms and very short clarifications are obvious examples of appropriate parenning.
I propose that the style manual's section on parentheses urge Wikipedians to avoid cramming parenned details into sentences. The style should also discourage the use of run-on sentences. I also propose that Wikipedians begin a War on Parentheses to edit out unnecessary parenning.
Most style guides, including AP Stylebook, have guidance for when to use parentheses vs. other punctuation, so I don't think the question is so much about parentheses as about whether we like sentences this complicated. If we change the end of your middle example to "90 hours, but at a much lower than nominal output", I wouldn't be surprised to see that sentence at WP:FAC. The last sentence would be too long for most review processes, so that raises the question, is there a conflict over sentence lengths somewhere that we need to address in the style guidelines? For instance, is some reviewer demanding more or less intricate or shorter or longer or sentences than writers are comfortable with? Is there edit warring over this? - Dan Dank55 (send/receive) 23:15, 10 October 2008 (UTC)
Yeah, commas are less obtrusive than brackets, which may be more minimal than dashes, but on the other hand they may have different implications. Parenthetical statements shouldn't interfere with clear writing, but of course they are a useful writer's tool.
This is starting to get out of the realm of house style and into the topic of what is good writing. It could grow into a huge essay entitled “Write clearly”, and probably belongs in Wikibooks. —MichaelZ. 2008-10-11 00:09 z
It's hard for a Manual of Style to legislate against absurdly cumbersome sentences; we rely on editors to observe improvements of such by their colleagues. The Apollo example might be OK, but since you didn't link us to the larger context, we can't tell. Best to minimise the use of parentheses and to use them as a resource along with (1) dashes, (2) commas, and (3) splitting complex sentences with a period or a semicolon. Learning how to allocate these devices is important if you're prone to write the way we speak (i.e., in fairly continuous strings of text, where paralinguistic information such as tone, pitch, rhythm and body language make long snake-like constructions much more digestible by the listener).
The first "LM" example can do without the parentheses.
The second "LM" example probably needs to be split up and the parentheses removed. (Parentheses can be good, though, to point out contrasting elements, even if a few lines away from each other. Here, they don't seem to be contrasting.)
All three examples need their prose to be straightened out in other respects, which might help the snake problem. Tony(talk)03:50, 11 October 2008 (UTC)
I need advice on how to start a sentence
Consider that I'm quoting the quote below.
"And also there was a sort of unspoken rule about not having drinking on television as a source of comedy. So, of course, we went right for it."
Which is the correct format?
A: "...[T]here was a sort of unspoken rule about not having drinking on television as a source of comedy. So, of course, we went right for it."
B: "there was a sort of unspoken rule about not having drinking on television as a source of comedy. So, of course, we went right for it."
A is the grammatically correct version. B wouldn't be horrible, though (since the 'also' is a throwaway term, you're not really miscontextualizing the statement by omitting it). --Ludwigs219:36, 9 October 2008 (UTC)
The APA Publication Manual (5th ed.) on page 119 says "the first letter of the forst word in a quotation may be changed to an uppercase or lowercase letter." Later on the same page it says "do not use ellipsis points at the beginning or end of any quotation unless, to prevent misinterpretation, you need to emphasize that the quotation begins or ends in midsentence."
AP Stylebook agrees on both counts, and thank you for bringing this up, Gerry, this is something I have to keep repeating. Also, this (lowercasing or uppercasing the first letter in the quote because it now does or doesn't begin a sentence) is one thing we don't require brackets for to show a difference from the original quote. (The only other two things that can show up inside quotation marks without using brackets to show that you're messing with the material are ellipses and toggling between single and double quotes.) - Dan Dank55 (send/receive) 20:16, 9 October 2008 (UTC)
I'm surprised we don't. It's rather more likely to affect the meaning than the punctuation at the end of the quote, on which we are fanatically determined. (Ellipses are a sign, although an ambiguous one, that we are messing with the quote; we should probably recommend "ellipses in the original" when they are.) SeptentrionalisPMAnderson03:29, 10 October 2008 (UTC)
That's a good point; I can tell you that the answer AFAIK is that style guides are generally agreed on not needing brackets around the first letter, whereas they're split on whether you can add a period/fullstop or comma inside the quotation marks at the end. But you make a good point. - Dan Dank55 (send/receive) 01:55, 11 October 2008 (UTC)
We are an encyclopedia, not a newspaper. If Mencken saw "[t]hat" in submitted copy, he would have been right to mock the perpetrator out of journalism; but our standards are different; we quote much more rarely, to begin with. I'm not saying that we should require "[t]hat"; I still doubt we need to require logical punctuation. SeptentrionalisPMAnderson03:48, 13 October 2008 (UTC)
Hmmm ... the double mirrors make my head spin: who knows whether the original had [...] the ellipsis at all, and whether, if so, square brackets were used or added by WP? I think that's what Anderson is rightly cautioning as "ambiguous"; it's an inherent problem in the use of ellipsis symbols. I don't think there's a simple answer. On the cap vs lower case, I'm pretty sure MOS says you can use lower case in this instance. I don't understand the quoted statement—was it intended to be heavily ironic? Can you link to the context? Tony(talk)03:46, 10 October 2008 (UTC)
Under construction artifacts
User:Woody drew my attention to {{under construction}}. I see there is Category:Under-construction templates.
When I first saw them, I thought that I was not supposed to edit the page and it seems that discouraging editing is exactly the purpose. I think I may even have been told by another editor that I needed to wait until he/she had removed the template. However, people are abusing what should be a rare privilige. If the argument is that active editing is in process then they must be tapping away at their keyboards and that seems to be an argument for perhaps 15 minutes to an hour grace.
I have the following suggestions:
Ban 'under construction' templates. Wikipedia is always work in progress. I don't believe that the number of templates on articles matches a real requirement. However, I don't think many people will support this option.
Rationalise the many similar templates into one template.
Each 'under construction' template shall have a visible expiry time. This will make it much easier to see that the template is due for removal. Currently, you have to be determined to work out how long it has been there, who added it, and whether they are showing signs of activity.
The expiry time for 'under construction' templates shall not exceed one hour. The time of one hour is arbitarily chosen but is consistent with active editing of text by the editor that wants to use the template to discourage contributions by other editors.
It seems like a good point to bring up; the template could potentially come across as bossy. On the other hand, I think it varies a lot from forum to forum; there are times and places where the template could help avoid edit conflicts. Any guideline that might cover this would IMO be a behavioral or editing guideline, not a style guideline. - Dan Dank55 (send/receive) 14:27, 13 October 2008 (UTC)
"End comma" to mark the end of an inserted part of a sentence
Is there a consensus in place on the issue of "end commas"? What I mean is the following:
"XX was born on February 25, 1978 in Bratislava ...". In my opinion, 1978 (which year?) serves as a qualifier to February 25. The end of the inserted part of a sentence should be marked with a comma (unless one reaches end-of-sentence, in which case the end is implicit).
Otherwise the sentence falls into two parts: "XX was born on February 25" and "1978 in Bratislava ...", which makes the second part look as an independent clause, which it isn't.
When you read the sentence out loud to yourself, it goes like this: "XX was born on February 25 (pause) 1978 (pause) in Bratislava ...", right? The pauses are the commas.
The same thing goes for this: "Born in Akron, Ohio to parents Bill ...". This sentence also misses a comma to mark the qualifier (which Akron?).
If there isn't a consensus on this, maybe one could be created?
I think this has been talked about before. Some people think like you do; others regard the comma simply as a conventional part of the representation of the date (separating the two numbers) or town ("town, state" is the conventional format for an American town). I'm in the second camp - in particular, I don't think I would pause either before or after 1978 in your example.--Kotniski (talk) 10:24, 13 October 2008 (UTC)
Was there any conclusion to that discussion? Btw, I don't mean that the pauses are very long, they're barely perceivable - but they're there. There is also a slight change of tone, and after the second comma the tone that preceded the first comma is resumed. LarRan (talk) 10:45, 13 October 2008 (UTC)
I guess there wasn't a conclusion. I like to think the majority agreed with me, but I don't remember for sure;) While I can admit there may be slight pauses or tone changes, I don't think they're the kind of pause that would warrant a comma under normal circumstances.--Kotniski (talk) 10:54, 13 October 2008 (UTC)
You don't pause after "25th" in reading aloud, and it's not a normal grammatical comma either. It exists solely by convention to separate the two sets of numbers. Tony(talk)11:22, 13 October 2008 (UTC)
Ok, there might not always be a perceivable pause, depending on your way of speaking, but within the expression "New York, New York", do you really say the words "York, New" as glued to each other as the words "New York"? If you must inhale before finishing the sentence (while speaking), where do you inhale, between "New" and "York" or between "York," and "New"? I bet it's the latter. Conventions don't come out of the blue: if the comma isn't a grammatical one, what kind of comma is it? The only other comma I can think of for the moment is the decimal comma, and that one it isn't for sure. I'm pretty sure it's a grammatical comma.
Is it in your view outright wrong to have an "end comma", or do you see it as matter of taste, so to speak? Is there anybody else, who has input to this discussion?
In the American language, these are parentheticals; my learned colleague is attempting to explain a language which is not his own. Like other parentheticals, idiom may allow omitting the dividing comma: "In 1978, the city of New York..." may become "In 1978 the city of New York...", but careful writers will include the comma whenever its absence may be confusing; some will always include it. SeptentrionalisPMAnderson04:08, 14 October 2008 (UTC)
I believe that in the previous discussion of this subject, although no real consensus was reached, there was support for using a comma after location parentheticals (like Chicago, Illinois—for some reason I don't think New York, New York is the best example available), but not for a comma after a year in a full date. Waltham, The Duke of04:25, 14 October 2008 (UTC)
FWIW, doing a Google search on the random phrase "Chicago Illinois was" seems to show a significant majority for the punctuation "Chicago, Illinois was".--Kotniski (talk) 09:13, 14 October 2008 (UTC)
Yes, you're right, English is not my own language, but I'm doing my best. It's not easy, you should try it some time ;-)
Found something interesting in the article Comma (punctuation), that seems to support my position:
Years following dates (this is American usage—whether this is really parenthetical is moot): My father ate a bagel on December 7, 1941, and never ate one again. (See #10 below.)
States following cities: My father ate a bagel in Dallas, Texas, in 1963.
In each case, the parenthesised (as if in parentheses) text is both preceded and followed by a comma, unless that would result in doubling a punctuation mark, or if the parenthetical is at the start or end of the sentence.
The first example, though, may not be a "full proof", as the second comma could be there for another reason, like in
"My father ate a bagel last Wednesday, and never ate one again."
Yeees... I'm not quite sure what the source is for that section of the article though. It seems a bit like an essay expressing someone's personal opinions (and we've already established that opinions on this point differ). In fact I might set about tidying up that article a bit, now you've drawn attention to it.--Kotniski (talk) 12:28, 14 October 2008 (UTC)
Numbered lists
I came across an instance on Schizophrenia which is not exactly covered by the instances where it's explicitly OK to use a numbered list. It has something like:
...must meet the following 3 criteria.
Explanation of first very complicated criterion
Rule 1
Rule 2
Rule 3
Second criterion
Third criterion
I think the numbering is useful for clarity, especially since the introduction says how many items there are to consider. I propose the following additional case to be added to the Manual of Style pronouncement on numbered lists:
When numbering is needed for clarity, such as with nested lists
Some people seem to think that, but I don't know of any good reason (apart from that categories are basically a pain and we can't really be bothered doing them right). I'd also like to know the answer, as I'm thinking about renaming lots of categories in line with the recent renaming of 1800s to 1800–1809, etc., and obviously I'd prefer to use dashes rather than hyphens to be consistent with the article names.--Kotniski (talk) 08:14, 15 October 2008 (UTC)
Kotniski, it would be a significant service to the project if you'd do that. I know that His Grace the Duke of Waltham would be keen to pursue this as well. There is absolutely no reason at all that category names should not be as readable as article titles, and consistent with their punctuation and formatting. Tony(talk)08:20, 15 October 2008 (UTC)
As far as the decades go I would suggest at least creating redirects e.g. 1810–1819 → 1810s just in case the title used for the previous decade lends itself to naïve assumptions (or hell, might as well rename all the decades the same way). — CharlotteWebb14:28, 15 October 2008 (UTC)
How well do category redirects work these days? The dashes are preferable as the final outcome, but if people aren't willing to type them we might wind up with articles being undercategorized. This isn't a problem for ordinary wikilinks, because you can just put a redirect. --Trovatore (talk) 01:30, 16 October 2008 (UTC)
Alas, I don't think there's any progress on this front (that I know of). That's why revisiting those category-move discussions would be an exercise in futility: there cannot be made an argument that consensus has changed. Since that fiasco, I've been meaning to initiate a discussion in the Pump about category redirects, but I wanted to bring myself up to speed with the status quo regarding categories in general first. As with many other things I've wanted to do lately, I haven't got round to it yet. (My ill health these days doesn't help much, either.)
If I remember well, the primary arguments against using dashes in category names are soft redirects (which slow down navigation) and the hard-to-combat miscategorisation and category fragmentation that would ensue, even if sporadic.
I think it would be nice if an editor saving an article after adding a redirecting category to it would receive a message to change the category. Rather unlikely, though. Waltham, The Duke of04:06, 16 October 2008 (UTC)
I was under the impression that category redirects now work (with the help of a bot to recategorize the members). At least, I've seen the bot in action a few times.--Kotniski (talk) 10:36, 16 October 2008 (UTC)
Yes. Several people have at various times operated bots for this task. It would be easy to add a feature that nags the previous editor, but that might be more annoying than helpful. Anyone who has the page watchlisted would figure it out soon enough. A more elegant solution might be to make it impossible to create or link to two distinct pages (or categories) which differ only by the type of dashes used so if "Foo[ndash]Bar" already exists, anyone linking to "Foo[hyphen]Bar" would get a link which points to and is rendered as the correct title. This would ensure that one or the other, but not both, can exist or be linked to. There would only need to be a few exceptions for -, –, —, etc. to exist as non-equivalent redirects (to articles about each type of punctuation). The devs are considering something largely similar to this for exotic and visually indistinguishable white-space characters (from non-latin unicode ranges). There was a very old bugzilla report which gained renewed interest after some oddball vandalism which made multi-word wikilinks turn red for no obvious reason (in fact, changing the type of space used). Dashes are a little less difficult to tell apart, but only to the trained eye (and by trained I mean familiar with the font used to display them and the urlencoding e.g. %E2%80%93 used to link them). — CharlotteWebb19:12, 16 October 2008 (UTC)
It seems to me that this rule conflicts with the WP:naming conventions general rules for no benefit, as in the text of an article redirects can take care of style issues like this one. When this issue was discussed briefly on the talk page of the naming conventions there were no consensus for it. The problem is that most people searching for a term are much more likely to use a hyphen than a dash so common usage dictates placing the name under a hyphen rather than a dash. --Philip Baird Shearer (talk) 10:48, 16 October 2008 (UTC)
All elements in a list should use the same grammatical form and should be consistently either complete sentences or sentence fragments.
When the elements are complete sentences, they are formatted using sentence case and a final period.
When the elements are sentence fragments, they are typically introduced by a lead fragment ending with a colon, are formatted using consistently either sentence or lower case, and finish with a final semicolon or no punctuation, except that the last element typically finishes with a final period.
to:
All elements in a list should use the same grammatical form and should be consistently either complete sentences or sentence fragments.
List items should start with a capital letter.
List items should not have a punctuation mark such as a period, comma, or semi-colon at the end, except if a list item is one or more full sentences, in which case there is a period, question mark, or exclamation point at the end.
This drops the recommendation on introducing the list with a colon. I don't think it's necessary to specify; doesn't the proper punctuation depends on the wording of the sentence? I don't think the introductory punctuation should depend on whether or not the list items are complete sentences or sentence fragments. The preferred style is not pretending that a list of sentence fragments is part of the previous sentence. (I really dislike the non-parallelism and gratuitous punctuation that introduces, anyway.) -- Beland (talk) 15:21, 14 October 2008 (UTC)
Your entry provides no good reason to change the current wording, IMO. Please note that WP:LISTS has been in a disordered state for some time. Tony(talk)14:10, 15 October 2008 (UTC)
Well, arguing in favor of the WP:LISTS recommendation:
It's consistent with tables, infoboxes, "Reference" sections, "See also" sections, "External links" sections, "Further reading" sections, disambiguation pages, and a large number of articles which have list-only sections. These lists do not add punctuation to the end of items that do not need it internally.
It agrees with my elementary school intuition - sentences end in a period, sentence fragments don't. Which is much simpler than learning a special rule where list items are treated differently if they are introduced in a particular way.
Pretending the list is part of the previous sentence makes the sentence excessively long, and makes nested lists extremely awkward.
It's more maintainable. Since punctuation is strictly parallel, no repairs are necessary if the order is changed or the list is extended.
It's what most people do naturally. I hit "Random article" a few dozen times, and the preponderance of the list items I saw were punctuation-free. Much of the rest of the Manual of Style itself doesn't even follow the list style it recommends. It would be a lot more work to force an artificial style on every list-bearing article that it would be to simply adopt the most common natural one.
As Beland's own list demonstrates, we will usually want an introductory colon even when the list elements are full sentences. On the other hand, a long introduction, consisting of several complete sentences, may be worsened by a colon.
This is therefore a matter on which we have no need to decide; we should be silent.
There are several other anomalous cases; some lists, for example membership lists in articles on international organizations, may well have no introduction beyond the section title. SeptentrionalisPMAnderson02:45, 17 October 2008 (UTC)
Spaced initials
When a reference to a person contains two or more successive initials, is there a rule about whether a space should be placed between the initials? For example:
Unfortunately, it's up to the editor. IMO, the spaced version is execrable. And you might also consider losing the dots, as is increasingly common in English: PG Wodehouse. Tony(talk)02:18, 14 October 2008 (UTC)
I consider the spaces strongly preferable. Without the spaces it looks too much as though the names are not separate from each other, particularly without the periods (what's that, an MPAA rating for Jeeves & Wooster?). In the case of three forenames, as in Du Bois, I'm willing to soften this on practical grounds. --Trovatore (talk) 02:22, 14 October 2008 (UTC)
I'm not sure I have a preference; I do not mind the spaced version, and I also think it is suggested in the naming conventions. (I suppose not using spaces is more plausible for three–or more?!—letters.) Not using full stops, however, seems like a stretch to me. PG Wodehouse looks like the name of an electronics company (where PG would be an obscure initialism). Waltham, The Duke of04:15, 14 October 2008 (UTC)
Stops but no spaces for me. Doesn't matter what the sources do, particularly if they were written a long time ago - this is a style thing, where we don't have to imitate specific sources. --Kotniski (talk) 09:27, 14 October 2008 (UTC)
Quite right. It would be silly to use different conventions within an article to follow the house styles of different sources. —MichaelZ. 2008-10-14 19:13 z
The period marks that it's an abbreviated first name. That does not mean that the space should be lost. Check this example: J. Edgar Hoover. If he had been known as J. E. Hoover, should the space be removed? Of course not. Where's the logic and the consistency? I assume that you don't think he was called J.Edgar Hoover - without the space. LarRan (talk) 18:08, 14 October 2008 (UTC)
Bringhurst (book), an authority on typographic style, states unequivocally “add little or no space within strings of initials. ¶ Names such as W.B. Yeats and J.C.L. Prillwitz need hair spaces, thin spaces or no spaces at all after the intermediary periods. A normal word space follows the last period in the string” (p 30). Since we don't have the level of control to use thin spaces, no spaces is our only choice.
Additionaly, it would be poor style to let strings of initials break at the end of the line, and clutter the wikitext ridiculously to write “J.&C.&L.&Prillwitz.” —MichaelZ. 2008-10-14 19:13 z
Well, that's Bringhurst's style convention. It's not binding on us, either. No-spaces are, in my opinion, hideous (thin spaces, I agree, would be OK if we had them). --Trovatore (talk) 19:24, 14 October 2008 (UTC)
Oh, as regards the linebreak issue: It's true, that's a bit of an annoyance, but it's unlikely to come up very much. In most cases the initials will be used only in the title and at the start of the first sentence, so there's no linebreaking to do. Admittedly it's possible that you might be talking about P. G. Wodehouse and his brother or something, both named Wodehouse, in the same article, and need to distinguish them, but this is a corner case and shouldn't be the determining factor of what we do normally. --Trovatore (talk) 19:27, 14 October 2008 (UTC)
Of course Bringhurst's advice is not binding, but the book is considered a standard, and so we can consider the unambiguous directive as good advice.
It's also the form recommended by the Economist “Initials in people's names, or in companies named after them, take points (with a space between initials and name, but not between initials),”[1] the Guardian, sans points, “no spaces or points, whether businesses or individuals eg WH Smith...,”[2] and the Times Online “With people's names, put points between the initials (with thin space between).”[3]
I'd be glad to consider any typographic or style-guide advice which suggests word spaces between initials, but so far all we have is the personal preference of a few editors. —MichaelZ. 2008-10-14 20:13 z
Let's keep in mind that we don't need to have a standard at all. Leaving it up to the judgment of editors on individual articles is just fine. I mention my preferences only to show another side to the preferences expressed by some others. --Trovatore (talk) 20:26, 14 October 2008 (UTC)
Why would we consider the spaced form equally acceptable, when it is rejected in professional publishing? Its use, plus the inconsistency, just makes Wikipedia look a touch more bush league. —MichaelZ. 2008-10-14 20:30 z
WP:MOS#Consistency is “an overriding principle.” The whole point of the MOS is to promote consistency, internally and with generally accepted, documented practices in English-language writing and publishing. That your personal preference differs sounds like something you should be prepared to deal with in your own way. —MichaelZ. 2008-10-14 20:52 z
Yet another, secondary, consideration is search. P.G. Wodehouse (261 results) and pg wodehouse (261) are equivalent for most search engines, but P. G. Wodehouse (752) parses as three words. Which are you least likely to type into the search field when looking for “Peegee Wodehouse?” —MichaelZ. 2008-10-14 20:30 z
Spaces are just not used in abbreviations. Would you write U. S.,Washington D. C., or The Man From U. N. C. L. E.? This is supported by our article on Abbreviation: “spaces are generally not used between single letter abbreviations of words in the same phrase, so one almost never encounters "U. S.".”
Is there any objective argument supporting the use of spaces? —MichaelZ. 2008-10-14 20:44 z
The problem is that you're thinking of the initials as a single abbreviation. They just aren't. They are two abbreviations (in the case of two forenames). That's the difference with the examples you cite, where you're making a single abbreviation. Otherwise it's like you're collapsing two of the person's names together into a single lexical entity. --Trovatore (talk) 20:50, 14 October 2008 (UTC)
With respect, that is not what the problem is.
Of course Wodehouse's forenames are a single entity. U.S., D.C., and P.G. are each an abbreviated phrase (United States, District of Columbia, and Pelham Grenville), lexically and typographically. They are demonstrably treated as such by writers, editors, and typesetters. [self-moderated]. —MichaelZ. 2008-10-14 20:58 z
The cases are not parallel. "U.S." is the name of a political entity; neither United nor States is a name. But Wodehouse's first "name", in the abbreviated form, is P, his second "name" is G, and his third name is Wodehouse. They should not be collapsed into a single thing. It strikes me as borderline disrespectful towards the individual. --Trovatore (talk) 21:12, 14 October 2008 (UTC)
“Which Wodehouse?” would be answered—with all due respect—by the proper name “Pelham Grenville,” or its abbreviation “P.G.” That's the prevalent style of writing abbreviations. —MichaelZ. 2008-10-15 00:30 z
I am not convinced that it is "the" prevalent style. It appears to be a prevalent style. I have explained why I consider it to be an inferior one. --Trovatore (talk)
Oh, except sure, I agree, for a single abbreviation, that's the way to write it. But it's not a single abbreviation; it's two abbreviations. --Trovatore (talk) 00:39, 15 October 2008 (UTC)
The AP Stylebook (2007), p 331,[4] “Initials: John F. Kennedy, T.S. Eliot (No space between T. and S., to prevent them from being placed on two lines in typesetting ¶ Abbreviations using only the initials of a name do not take periods: JFK, LBJ.”
Generally I find that journalistic stylebooks take an overly space-saving approach. As another example they tend to avoid the serial comma. --Trovatore (talk) 00:46, 15 October 2008 (UTC)
FWIW I noticed that the Chicago manual, section 15.12, recommends a space between the initials. — Carl (CBM · talk) 00:52, 15 October 2008 (UTC)
No one is trying to save space; it's a matter of looking smarter and avoiding line-wrapping. I agree with everything Michael Z says, except for the line that the whole project should be consistent on the matter (its akin to engvar, requiring within-article consistency). Since people feel very strongly about the dots, I'm happy with the option to use them or not to use them. It would be ideal to have a mild recommendation against the spacing (since this is a justified online format), retaining the option to use it. Tony(talk)05:48, 15 October 2008 (UTC)
To me, there is no logic, nor any consistency, in removing the space just because one abbreviated name follows another. If you write J. Edgar Hoover, and not J.Edgar Hoover, why suddenly write J.E. Hoover? If you don't write JohnF. Kennedy, and you don't write John F.Kennedy, why write J.F. Kennedy (btw, I'm comfortable with JFK and LBJ). Ok, there could be line breaks at places we would prefer not to have them, but so what? There will always be that -- unless we place "hard" line breaks in the text. I'm with Trovatore. LarRan (talk) 07:14, 15 October 2008 (UTC)
I prefer dots and spaces, but between the two, the spaces are actually more important. I don't agree that leaving out the spaces "looks smarter"; quite the opposite, in fact, because as I say it unjustifiably collapses two names, which should remain separate, into a single lexical unit.
I'm not sure what justification has to do with it. I do agree that it's unfortunate to have a line end in T. and then have the next one start with S. Eliot, but it would be just as bad to have a line end in J. and the next one start with Edgar Hoover, and I don't see that having a line end with T.S. and the next one start with Eliot is really much better. --Trovatore (talk) 07:09, 15 October 2008 (UTC)
Oh, it is (though it's still bad). I don't buy your argument about collapsing two names either - if we collapse United States into U.S., then we can collapse John George into J.G. They are two words in each case, but form part of the same name. --Kotniski (talk) 08:08, 15 October 2008 (UTC)
Not the same. Neither United nor States is a name; it's only together that they make a name. But if someone is named John George Smith you can call him John, George, or Smith; each of them separately is his name. (Granted, most people with that name will be a little surprised to be called George, but there are those who go by their middle names by preference.) --Trovatore (talk) 08:12, 15 October 2008 (UTC)
They can be used separately, but when we use them together they form one single name (otherwise John George would equal George John). --Kotniski (talk) 08:44, 15 October 2008 (UTC)
I think your argument about the difference between names and items might escape most punters. We may as well go back to "U. S. A." and "N. A. S. A.". They're harder to read and contain redundant formatting on two counts. The first signal that it's an abbreviateion is the upper case, especially marked with two or more letters together. The second signal is the dots. The third signal (very dodgy, IMO) is the intervening space. The tendency is to reduce redundant formatting, especially strong since the demise of the typewriter and the advent of a wealth of formatting resources on computers. We've finally realised that excessive formatting carries disadvantages, one of which is that in most cases it's harder to read. Methinks you've become so used to writing and expecting the triply formatted initials that you find anything hard to accept. Tony(talk)08:29, 15 October 2008 (UTC)
John George does not equal George John, whether the bearer is called by the first, the second or both. The keyword here is "both", which means that it's two names, not a single name. Or would you call Pelham Grenville Wodehouse Grenville Pelham Wodehouse? LarRan (talk) 09:06, 15 October 2008 (UTC)
If you're talking to me, then no, obviously, that was my point. If "John George Smith" were just a list of three names by which the person might be called, then we could equally well put them in another order, "George Smith John" etc. We can't, because the phrase "John George Smith" is itself a name.--Kotniski (talk) 09:35, 15 October 2008 (UTC)
The fact that John George Smith is a name does not rule out that John, George and Smith also are names. In addition, you haven't removed the space between the names, and still it's a name, right? So why would removing the space between initials be necessary to make that -- the combination of initials and lastname -- a name? LarRan (talk) 11:11, 15 October 2008 (UTC)
I'm not saying it's necessary for that reason, but it's the normal style when initials are part of the same name. Like in U.S.A. (where America and (the) States are also names for it, and even if United happened to be as well, that wouldn't cause people to start writing U. S. A.).--Kotniski (talk) 11:24, 15 October 2008 (UTC)
Nor is it a valid argument that "FL" or "F.L." for "French Legion" should suddenly be "F. L." because my neighbour's surname is "French". Tony(talk)14:13, 15 October 2008 (UTC)
The States is not part of the abbreviation U.S.A., whether the definite article is within parenthesis or not. The only name within that abbreviation is America, while all parts of P. G. Wodehouse are names. Even if there are people with the surname French, it isn't a name when part of the expression French Legion, it's an adjective.
My observation is that T.S. or P.G. in many cases (not all) is the result of sloppy typing or writing. That's why you find so many occurrences of T.S.Eliot and P.G.Wodehouse (no space before last name) and T.S and P.G (no second period). Many are not aware of the importance of spaces, and some don't even see this error until it's pointed out to them. So I guess my view is that a missing space between initials is simply a case of sloppyness, forgetfulness or other mistake, in short: an error.
With regard to Ipoellet's input below, I would comment that the abbreviations don't first show up in writing, they show up in daily parlance. Wodehouse's friends in school probably found it easier to address him as P G than Pelham Grenville. Spaces and periods are neither distinguishable, nor are they needed, when speaking, but the need of them arises when the name is put into writing. The role of the periods there is to point out that this is an abbreviation, the role of the space is to make clear that it's two abbreviations, not one.
Wow. I'm not accustomed to raising this much discussion! My original concern in raising this question was merely whether I would violate the MOS in exercising my preference in a particular edit I was doing. The answer clearly seems to be "no", and I thank everyone for their input. But insofar as the discussion expanded beyond my original concern, I've been wondering why I hold my particular preference - unspaced (with dots). I came up with two reasons: (1) When we reduce someone's forenames to initials, we are already - for whatever reason - trimming parts out to shorten them. Having chopped off all but the first letter of two or three names, it seems just a continuation of the same logic to pare out the space in between. The last name is not truncated, so the space remains there. Taking the reasoning even further would suggest that we should eliminate the dots as well, but that final step seems less conventional in the world at large. (2) When an individual's forenames are reduced to initials, they generally cease to be independently usable to refer to that person. It would be stylistically unacceptable to refer to T. Eliot, P. Wodehouse, or W. Du Bois. Thus the reduced initials do become a single lexical unit, and the space comes out. Ipoellet (talk) 16:39, 15 October 2008 (UTC)
I'd say ditch the spaces. A few people have argued by analogy, citing the fact that we'd provide spaces if the names were spelled out entirely. Misses the mark. If the names were spelled out, we'd need the spaces to be able to quickly distinguish the individual tokens. That doesn't carry across to a context where each token is always the same length and dots serve as explicit delimiters, so why should we observe the same convention? Should we put spaces in 01/01/2008 just because we'd put them in 1st January 2008? Ilkali (talk) 17:13, 15 October 2008 (UTC)
You're way beside the point. 01/01/2008 is not a name, nor is any part of it. The first 01 is not abbreviated, and the second 01 is not an abbreviation of January.
The rules you're applying here are arbitrary. That's the point. Why should we need special rules for names? What practical purpose do those spaces serve? Ilkali (talk) 11:19, 16 October 2008 (UTC)
Look, I'm not claiming to be riding in on the white steed of Logic and explaining why things have to be the way they are. It's a different rule for personal names than it is for organizations or countries, and sure, there's an element of arbitrariness to this. I'm just saying why it isn't totally arbitrary, why it makes sense and is plausible.
Let me give one more point along those lines: When you read Wodehouse's name aloud, at least in a formal context, you don't say, as Mzajac (ITIW) said above, Peegee Wodhouse. You say, clearly, Pee Gee Wodehouse, with Gee as a stressed syllable. The spaces are a better indicator of this.
Also I don't necessarily insist on "triply formatted" -- I would be OK with P G Wodehouse, spaces but no dots, especially as it's a British topic. --Trovatore (talk) 19:16, 15 October 2008 (UTC)
"you don't say, as Mzajac (ITIW) said above, Peegee Wodhouse. You say, clearly, Pee Gee Wodehouse". So what? Every rule espoused here in favor of the spaces is completely ad hoc. We don't write 01/ 01/ 2008 just because its constituents map to phonetically distinct words. Ilkali (talk) 11:19, 16 October 2008 (UTC)
So you're perfectly comfortable with T.S.Eliot and P.G.Wodehouse? You stated above that since we have the periods, we don't need the spaces. LarRan (talk) 19:17, 16 October 2008 (UTC)
No I didn't. I said that the dots serve as explicit delimiters (which is undeniably true), and argued that this (along with another factor - go read it again) marked a clear difference between the demands on styling in abbreviated and full forms. Since the contexts and demands are different, arguments by analogy are unpersuasive. The reason I would oppose renderings like T.S.Eliot is that they are extremely nonstandard. You can't make the same claim about T.S. Eliot. Ilkali (talk) 20:50, 16 October 2008 (UTC)
Style manual survey
All the discussion got me to go to the library. I apologize for assuming that no spaces was the prevailing form based only on a quick review of online sources. Here are my findings. Most manuals also dictate where word breaks are allowed. These citations include advice for copywriters, editor, and typographers, and probably don't all assume the same level of typographic control. —MichaelZ. 2008-10-16 01:02 z
J.R.R. Tolkien – “a space between initials and name, but not between initials,” Economist[6]
J. R. R. Tolkien – “hair spaces, thin spaces or no spaces at all,” The Elements of Typographic Style, p 30
J. R. R. Tolkien – “thin space between,” Times Online[7]
J. R. R. Tolkien – “put a thin space between a person's initials . . . except where they stand alone,” Canadian Press Stylebook, 12th (2002)
J. R. R. Tolkien – “non-breaking word space.” “If initials are given instead of first names, the break should follow the initials. Chicago Manual of Style (2003)
J. R. R. Tolkien – “preferably with a space after each in OUP style;” J.R.R.T. “entirely in initials . . . no spaces;” FDR, LBJ “people more commonly known by their free-standing initials have neither points nor spaces.” Also, “Do not break place-names or (especially) personal names, if possible. If it is unavoidable break personal names between the given name(s) and surname, or initials (there must be at least two) and surname.” Oxford Style Manual (2003)
J. R. R. Tolkien – “there are spaces between each period and the following...,” The Canadian Style (1997)
All of the spacing above works as intended in Safari/Mac, Firefox/Mac, and MSIE 7. MSIE 6 displays boxes for hair spaces, and huge spaces for thin spaces. —MichaelZ. 2008-10-16 01:43 z
There is no one prevailing style.
Manuals which recommend any type of spacing between initials also assume professional typographic setting, including control over fractional spaces and word breaks (at the end of the line). None of this is practical to recommend in Wikipedia. We can type literal non-breaking spaces (option-space on a Mac), but they get automatically wiped out by edits using some web browsers.
The only way to approximate professional results in Wikipedia, i.e., to avoid line breaks like T. / S. Eliot, is to recommend no spaces between initials. this also has the advantage of being consistent with all other abbreviations, and helping to focus search results (e.g., the terms Eliot and T.S. or its equivalent TS, are more specific than three terms Eliot, T., and S.).
The MOS shouldn't recommend a particular style, but should list the advantages and disadvantages of each. —MichaelZ. 2008-10-16 01:16 z
Michael, I'd like thin spaces as the ideal, but yes, we found here some 18 months ago that IE6 (and now you say its offspring) won't deal with them. It's with a great deal of irritation that we had to abandon a template that combined thin spaces with hard-spaces for this purpose. WHY do people still use IE? Dropping it is the only way you'll force that behomoth to get real. In any case, it's display is generally shockingly poor compared with those of other browsers. Tony(talk)01:54, 16 October 2008 (UTC)
C'est la vie. Many people just don't have control over which web browser they use, or simply don't realize that website problems are the fault of their browser. It will be some years before we have full typographic control on sites for the general public. In the meantime, we have to make compromises, or simply choose from the menu of what works. In some ways, it's already light years ahead of 1970s phototypesetting, etc.
By the way, it may be possible to emulate the typographic appearance using CSS word-spacing or letter-spacing properties, but I think a style decision is more robust than creating new templates, etc.
(MSIE 7 does these fractional spaces right by the way, or at least MSIE 8 emulating 7 does.) —MichaelZ. 2008-10-16 02:07 z
A reasonably nice technical solution has occurred to me. The thing is, you're not likely to use P. G. Wodehouse except at first reference; subsequent references will just say Wodehouse. In Wodehouse's bio there's no problem, because the first reference will be early in the first sentence, so no linebreak. In other articles that mention him, on the other hand, he'll be wikilinked at first reference.
So we could avoid most of the linebreaking problems if the developers could be persuaded to do the following simple thing: Inside a wikilink, following a dot, a single space is rendered as non-breaking. Granted, it's not 100% foolproof, but it should take care of most of the problem. --Trovatore (talk) 08:48, 16 October 2008 (UTC)
Presumably only the first instance will be linked. Hardly worth worrying about. Have you ever tried to get WikiMedia developers to do anything? It's like pushing against an ocean liner. Tony(talk)09:11, 16 October 2008 (UTC)
Well, the first instance is probably the only place there's a problem; that was my point. But no, I'm not extraordinarily optimistic about getting action from the developers. I'm suggesting it might be worth a try. Not all cases of single letter--dot--single space--letter will be initials, but it's hard to imagine a case where you'd actually want that single space to be breakable inside a link, so the solution could have benefits beyond the current discussion. --Trovatore (talk) 09:17, 16 October 2008 (UTC)
Thanks for that research, Michael Z, well done.
To me, it seems that most sources recommend the presence of a (some kind of) space, which is what I have advocated. The only problem we have now is the line breaks. For editors who are bothered by this, the solution is easy: pipe the links with non-breaking spaces, and there won't be a line break between the initials.
At the relatively low resolution of the computer display, I calculate that a typographic hair space (M/24) is equivalent to no space, and a thin space (M/5) is 2 or 3 pixels (for comparison, a word space is M/3 or 4 pixels in Wikipedia's default body text size). However, on my machine in Safari and Firefox, both hair and thin spaces render as exactly 1 extra pixel, while a word space renders as 3 pixels.
Setting the initials and points tight solves the wrapping problem, which I think is more important, for every instance, linked or unlinked, and without having to use any extra pipes, character entities, templates—just by typing the name. —MichaelZ. 2008-10-16 15:25 z
Wodehouse's full name appears 7 times in the body of the article, 9 times in its bibliography and links with spaced P. G., 8 times with tight P.G., and 3 times with PG sans points (obviously some are quoted titles which shouldn't be changed). A Google search "P.G. Wodehouse" OR "P. G. Wodehouse" site:en.wikipedia.org finds 50 articles in the first seven pages of results containing versions the name (that's when I got tired of counting). There are six or seven articles containing a variation of P.G.Wodehouse with no space at all.
I leave it to someone else to count the variegated T.S. Eliots, J.R.R. Tolkiens, H.G. Wellses, etc. ad infinitum. Any one of these names may appear hundreds of times in Wikipedia.
Initials set tight is a perfectly acceptable style, it is simplest for editors, it keeps wikitext clean, it avoids the wrapping problem, it focusses search engine results, and also helps readers consistently find names using text search on the page. Why not simply stick to one consistent style which is most practical for a web site with thousands of amateur editors? —MichaelZ. 2008-10-16 14:44 z
Encouraging a single simple standard which corresponds with other abbreviations will only improve consistency. —MichaelZ. 2008-10-16 22:42 z
Because it's bloody ugly, that's why. Because it makes people want to read Peegee Wodehouse, when it ought to be Pee Gee Wodehouse. And note that it doesn't even solve the wrapping problem, because a line ending in P.G. is still quite bad.
If Wodehouse's initials+surname appear seven times in the body, well, that should probably be fixed, no? The standard is to use surname only at second reference, unless you're distinguishing him from someone else of the same name. --Trovatore (talk) 19:11, 16 October 2008 (UTC)
I'm sorry, but to me peegee and pee gee read and sound the same. That some professional style manuals specify no space or hair space (1/24 em), and that none of them mention this so-called ugliness tells me that this is the equivalent of your opinion or original research, and not a supportable argument for spaces.
It does solve the wrapping problem—the manuals which specify wrapping to this level of detail may discourage wrapping of proper names, but they absolutely prohibit breaks between initials. Supporting quotations are in the survey above.
I'm sorry, but I don't see any problem with the specific occurrences of Wodehouse's full name in the article—if you do, then please remove them and drop a note back here. That names with initials will appear only once at the beginning of a line in a single Wikipedia article is false. The scope is thousands of occurrences of hundreds of names. —MichaelZ. 2008-10-16 22:42 z
Editors are going to use every possible permutation of initials, stops, spaces and spelled out names. The question in a commercial publication would be one of how initials should be rendered throughout by mediawiki. So far, we haven't even gotten agreement on using one citation style, but good luck with that. I'd suggest that when there is an article the first usage should wikilink to that article, which in most cases will have fully spelled out names. If citing JJD Smith or J.J.D Smith or J. J. D. Smith (or whatever) it should be pipetricked as [[John Jacob Dingleheimer Smith|JJD Smith]] for JJD Smith. Of course a hybrid between tl:persondata and tl:initialism would be a better answer for any number of reasons. LeadSongDog (talk) 21:02, 16 October 2008 (UTC)
In my case, I'm supporting it with perfect logic and consistency. The ultimate argument is that if J. Edgar Hoover is correct, then J. E. Hoover would have been correct, had he been known by two initials. Also, J.E. Hoover is only halfway from the sloppily typed J.E.Hoover -- and yes it looks gastly. LarRan (talk) 21:24, 16 October 2008 (UTC)
Sorry, but I don't see any support for that argument in any literature, while I have cited professional style manuals whose advice contradicts it. It amounts to “I like it that way.” I have also found no support for the “two abbreviations vs one abbreviation” assertion.
Both spaced and unspaced initials can be considered correct, but a line break between initials is demonstrably incorrect. The only simple, consistent way to keep things within the realm of correctness is to type the initials tight. —MichaelZ. 2008-10-16 22:42 z
We aren't going to agree on this. Luckily we don't need to. The status quo, in which the MoS simply doesn't mention the issue, is not causing any problems. --Trovatore (talk) 22:45, 16 October 2008 (UTC)
Yeah, the discussion doesn't look like it's going to go anywhere else. Perhaps I'll gather the evidence cited above, and put together a proposal for this discussion or the Village Pump. If you find any other relevant sources to cite, please mention them here and I'll include it in the proposal. You'd also have the opportunity to state your own ideas in any poll, of course. —MichaelZ. 2008-10-16 23:04 z
"The ultimate argument is that if J. Edgar Hoover is correct, then J. E. Hoover would have been correct, had he been known by two initials". Only if we assume a certain rule (that abbreviated forms have to mirror non-abbreviated forms in their spacing) that clearly is not recognised by all commenters here. Where is the evidence that this rule exists? Or is it more ad hoc nonsense? Ilkali (talk) 23:48, 16 October 2008 (UTC)
To be more clear: we have the same problem with J. Edgar Hoover, i.e. a line can end with J. and the next line could start with Edgar. Yet nobody would suggest J.Edgar Hoover, to avoid unwanted line-breaks between J. and Edgar. Still, T.S. is proposed as the appropriate solution to avoid line-breaks between T. and S.. I find that amazing.
To me, this is a process of maturing. First you realize that writing T.S.Eliot is not correct. 99% (at least) realize that there should be a space before Eliot. The next step is to realize that there should be a space between the initials, similar to the space between J. and Edgar. I think more and more editors (slowly) realize that, and I'm pretty convinced that nobody goes in the other direction. Yes, some tolerate the missing space (sighing heavily to themselves), but that's not the same as believing that it's correct.
And it's not ad hoc nonsense. Since when has logic ceased to apply on language and writing? Is your position less ad hoc? At least it's less logical.
To continue to repeat that leaving out a space between the initials is incorrect, after having read the survey of manuals which demonstrates that it is an acceptable style, is to ignore evidence and defy logic, no? —MichaelZ. 2008-10-17 15:13 z
"To be more clear: we have the same problem with J. Edgar Hoover, i.e. a line can end with J. and the next line could start with Edgar. Yet nobody would suggest J.Edgar Hoover, to avoid unwanted line-breaks between J. and Edgar". Firstly, linebreaks are not the only issue here. Secondly, our job is not to lead linguistic change. We are only justified in choosing from styles that are in common use, which J.Edgar Hoover is not.
"And it's not ad hoc nonsense. Since when has logic ceased to apply on language and writing?" The more you declare that your position is logical while ignoring every counterargument I provide, the more I think you don't know what the word means. Ilkali (talk) 12:49, 17 October 2008 (UTC)
Quotations? Excessive?
Greetings, I notice the MOS is silent on excessive quotations. I recently encountered a number of articles replete with quotations (after GA review, I found them via peer review). There were various copyvios concerns which were addressed. However, the base question of - what extent of quoting is allowed? - was not answered by the MOS. I do not find large collections of quotes to be encyclopaedic. Can the manual be tightened? Anyone else have thoughts? Regards, Lazulilasher (talk) 16:49, 15 October 2008 (UTC)
This edit removed a cited quotation of a hundred-plus words with the edit summary "copyright infringement." Was the quotation excessive? Fg2 (talk) 05:39, 16 October 2008 (UTC)
Re: Headbomb: I refer to articles comprised solely or largely of quotations; where a paraphrased summary remains possible. Granted, this is perhaps not a style issue.
Re: Fg2: The policy is NFC#Text, and the question is: does the brief quotation serve to illustrate a point of view or establish context. In the case of the above, I argue that the quotation does establish context; and is thus permissable. Perhaps there is something I didn't know. Regards, Lazulilasher (talk) 15:34, 16 October 2008 (UTC)
Thanks, Lazulilasher. I appreciate the point of view of someone who has not been involved in editing the article. Having edited it from time to time, I might misjudge something like this. Fg2 (talk) 11:12, 17 October 2008 (UTC)
The manual at present doesn't appear to cover the case of a living person when describing the format of a date range. Whilst a dead person is formatted thus: "Anne Example (1900–99)", with an en-dash, a living person should presumably be: "Anne Example (1900–)". However, I've seen it done with an em-dash and a space, thus: "Anne Example (1900— )". I presume that's wrong, but it'd be nice to clarify the consensus, and mention it in the manual. – Kieran T(talk)14:20, 21 October 2008 (UTC)
Something tells me that it's much more polite to the person to say "(b. 1900)" than to use an en dash to point to their death ("watch this space"). Tony(talk)16:10, 21 October 2008 (UTC)
Can somebody give some advice about categories please. I received the following response on my talk page:
In this edit to Barbarossa-class ocean liner you improperly changed the sortkey for a category. Because this is the main article for Category:Barbarossa class ocean liners, the pipe and space ("| ") were added to allow this article to list at the top of the category page. This is a common technique for 'lead' articles of categories. Please ensure that whatever tools you are using do not destroy this type of commonly used and intentional sortkey.
I really don't care either way, but empty pipes such as '| ]]' seem to be a bit of a hack. Does this indicate that there is something wrong with category sorting or is that just the way it is? Lightmouse (talk) 14:59, 24 October 2008 (UTC)
There are plenty of things wrong with category sorting, but I don't think this is one of them - it works well, at least.--Kotniski (talk) 15:31, 24 October 2008 (UTC)
Any sort-key which starts with a space will cause the page to appear before the "A" section in the category listing. Barbarossa class ocean liner would contain:
[[Category:Barbarossa class ocean liners| List of]]
so that it appears after the main article but before the individual boats. While it would undoubtedly be possible to change the software to allow some other way to do this, maybe some kind of magic word to the effect of:
{{#MAIN_PAGE_FOR_CAT:Barbarossa class ocean liners}}
but that would be even more confusing. If you can think of a syntax that would actually make more sense than the status quo, you should request it. In the meantime let me know if you need any help not breaking existing sort-keys. — CharlotteWebb17:45, 24 October 2008 (UTC)
This cropped up because I have been fixing unwanted spaces in wikilinks. A surprisingly common class of error e.g. [[foobar ]]. The category thing surprised me but I am sure I work around it easily enough. Thanks. Lightmouse (talk) 17:50, 24 October 2008 (UTC)
You may be interested to hear that using asterisks (*) to achieve a similar effect is actually rather common, and neatly avoids the problem of cleanup scripts removing the sort space (though personally, I still prefer spaces). —Dinoguy100018:00, 24 October 2008 (UTC)
Asterisk is undesirable because it creates a visible "*" section before "A" on the category page. Something like:
[[Category:Foobar| ]]
has exactly the same effect as a space, but it is also a bit more confusing to editors. However, at least bots won't foul it up.
Maybe we should ask the devs to make categories ignore all punctuation characters when figuring out sort-keys. Then the albums …And Justice for All and "Heroes" would sort under "A" and "H" without any special help. Also a page which deliberately contains the asterisk sort-key ([[Category:Foobar|*]]) would sort as an empty string, appearing before "A", becoming equivalent to one which is spaces only. — CharlotteWebb18:29, 24 October 2008 (UTC)
Just try asking the devs to improve anything connected with categories... You're right about punctuation characters of course; and moreover small letters should be treated as equivalent to capitals, and diacritics should be ignored, and subcategories should all be listed before member pages, and categories should be allowed as member pages, and there should be more than 200 entries on a page, and member pages should be accompanied by links to their eponymous categories, and it should be possible to watchlist and redirect categories in a way that works as you would hope, and... (sorry, this is just my private category-functionality wishlist)--Kotniski (talk) 19:24, 24 October 2008 (UTC)
Sadly, my own wishlist actually lines up pretty nicely with yours... In addition, I'd say allow each wiki to customize the global sort order (including a mechanism to sort multiple characters under the same thing) via an interface page, that would allow many of the current wanted features to be taken care of. —Dinoguy100020:42, 24 October 2008 (UTC)
Thanks for the helpful suggestions. I have now solved it and proved that it now works correctly on the articles brought to my attention, namely:
No shit. I am getting an extremely bad feeling here; the principal proponent's callous disregard for any voice other than his/her own is throwing petrol on the flames. Ling.Nut(talk—WP:3IAR)05:18, 27 October 2008 (UTC)
Yes, if this ever comes to a vote I will definitely vote against it. Different academic fields use different citation styles so should we. Having a single admissible template will make life impossible for newcomers.·Maunus·ƛ·05:37, 27 October 2008 (UTC)
Look, I am sure we all appreciate the work you've put into this, something that you probably believe will make wikipedia a better place. We just disagree with that belief. You will realise that many people are sceptical towards attempts to unify and make rules, and that some (like me) even find that such unificational solutions add complexity instead of removing it.·Maunus·ƛ·06:41, 27 October 2008 (UTC)
I'm not making any rules here, I'm writing a template. If you don't like {{unicite}}, don't use it. As far as ease of use goes, there's nothing different about using {{unicite}} than using any other templates out there. If you can use {{cite book}}, then you can use {{unicite}}. Be skeptical if you want, but I've dealt with worse things than citations debates. Headbomb {ταλκ – WP Physics: PotW} 07:06, 27 October 2008 (UTC)
I think it is rather disingenuous to act as though this won't affect people who don't want to use it, when you are on the record as advocating the use of a bot to "replace {{cite X}} with {{unicite}} and everything will be tidied up." Hesperian11:21, 27 October 2008 (UTC)
I'm against it also, honestly. There is no one citation method in academia, nor should there be on Wikipedia. And I'm absolutely against a bot going through and replacing templates with unicite. I write articles in a style that is easy for me to maintain, and having that changed on me is not something I would be for. Ealdgyth - Talk13:25, 27 October 2008 (UTC)
See WP:OWN. What's easy for you or I to maintain doesn't matter much. What does matters a great deal is that the reader sees the most correct content we can manage. That's why we do all this stuff. WP:CITE, WP:V and WP:RS all serve that end. Anything that gets novice editors to provide even minimal citations for their text contributions will be far more important. I'd frankly be happy if they'd just give an ISBN/PMID/whathaveyou permalink and a page number in most cases, bots or experienced editors can do the rest. Asking a novice to get familiar with diverse style guides depending on our idiosyncratic rules is a recipe for error. Having one template the novice can start with that will do a reasonable job would be a very good thing. Having bots ravaging carefully formatted high quality articles would not.LeadSongDog (talk) 17:07, 27 October 2008 (UTC)
I actually think WP:OWN applies more strongly to those who quash discussion by moving current discussion (almost all of which is less than a week old) to archives, rather than responding to it. Some people find separate templates per type easier; some prefer a single template; some like to format citations by hand. There are already bots that add more citation info, based on an identifier. {{Citation}} seems to be able to format references of disparate types from a single template & the {{Cite XXX}} templates will soon use the same back end. Given that the original motivation of unicite was supposedly to stop template proliferation, I don't see the point--there's no way that all previous citation templates will be deleted. Why not help improve citation/core? --Karnesky (talk) 17:18, 27 October 2008 (UTC)
Yay, I'm a demon! Argue on form, not on content! Does it matter that I summarized the old discussions in bullet form? Nope, cause I'm an evil man who didn't reply in the CABAL approved place. Burn me, I'm a witch!
The reason why I archived the discussion is because most of it was unstructured and hard to follow, incredibly lengthy and most of the points raised have been addressed. There's no need to have that here. If you feel that there's something in the old discussion that has not been sufficiently addressed, then just go in the archives, and re-copy it here.
I don't know why you resort to dramatics. My criticism was civil and reasonable and was not a personal attack. I do believe that template proliferation is a "real issue." If this template has the same goals as {{citation}}, I don't see the value in it--why not improve {{citation}}? If this template has different goals, those should be large enough to overcome deficiencies (raised both here and in the archive). Perhaps I'm missing something obvious, but I'd appreciate a clear explanation for goals and why modification of existing templates would not meet those goals. --Karnesky (talk) 17:59, 27 October 2008 (UTC)
I have a hard time seeing how referring to me as "those who quash discussion" is not an attack. Anyway, as far as I'm concerned, it's water under the bridge.Headbomb {ταλκ – WP Physics: PotW} 20:27, 27 October 2008 (UTC)
Since newcomers come from different academic fields with different citation styles, and because other newcomers don't know anything about template formatting and can barely learn to cite references in a separate bibliography section I am quite convinced that having a single admissible template citation style will not do them a favour.·Maunus·ƛ·19:00, 27 October 2008 (UTC)
I don't see anyone advocating for "a single admissible template citation style". Rather for provision of a new template that will make the others redundant. If you want to learn all the wrinkles of all the others, go right ahead. If you want to just type "( I got this from page 34 of John J Smith's 1946 book)" that's cool too. Someone will fix it up.LeadSongDog (talk) 19:38, 27 October 2008 (UTC)
Headbomb has advocated a merge of very popular & already used templates, saying "all a bot would have to do is to replace {{cite X| with {{User:Headbomb/unicite| and everything will be tidied up." That this discussion is centralized on WP:MOS also speaks volumes. A proposed merger and bot work do seem to indicate a desire to deprecate other template citation styles. --Karnesky (talk) 20:03, 27 October 2008 (UTC)
(unindent)
I did and still do advocate a deprecation of all the different citation template in favor of one unique template. I design {{unicite}} so deprecation would be very quick, efficient, and doesn't require any change in the way people cite things other than to call on {{unicite}} rather than one of the zillion templates out there. It would greatly improve things as far as uniformity is concerned, it would be far easier to maintain, and newcomers won't have to learn the quirks of zillions of templates. {{citation}} has been around for more than a year now and the fact that all the other template do not produce uniform outputs means that {{citation}} failed to do what it set out to be or that non-deprecation is not a viable option. However {{unicite}} itself is independent of whether or not the other templates are deprecated or not, and I'm not looking for a debate on deprecation right now. The fact that this discussion is centralized on WT:MOS is indicative that I think that the people who with the best insight on citation style are here, and that I would rather develop {{unicite}} openly than in a low-traffic and obscure page, and of nothing else.Headbomb {ταλκ – WP Physics: PotW} 20:27, 27 October 2008 (UTC)
{{Citation}} predates {{Cite web}} and {{Cite book}} by several months. The original goal was not to make uniform citations and multiple templates based on resource type do have advantages (different types do have some peculiar output conventions & also expect very different input data).
The uniformity problem is now recognized by many & steps are being taken to address that problem. If {{Cite XXX}} are fairly uniform with one another & differ most from {{Citation}}, then the right thing to do seems to be to continue to modify {{Citation}} until it matches the output of the more popular templates. There seems to be absolutely no advantage of starting yet another template that makes absolutely no attempt at uniform output to already-existing citations.
Even supporters of a more uniform or easier citation system have stated that they do not want or believe that this effort is meant to derail current citation systems. I imagine that any request for bots to transform already existing templates or to deleted some of the most popular templates on Wikipedia will be met with even stauncher criticism than you have already seen here. There are advantages and supporters of having choice, but few for prescription.
As I previously stated, your passion and effort is outstanding. But I think it would probably be better spent trying to improve {{Citation}}, as that is more likely to gain traction & will have to be addressed whether unicite takes off or not. --Karnesky (talk) 22:40, 27 October 2008 (UTC)
First, the thing is that {{cite xxx}} are not uniform with one another. Second it's a flat out lie that this does not attempt to match the output of the more popular templates. And third, there are nothing but advantages to having one single unified template for non-specialized citations. It streamlines maintenance, it uniformity citations, it facilitates error-spotting, and it simplifies things for newbies. {{harvnb}} could now be used for things that previously did not support it. You could now place a variety of references in sentences, not just those supported by {{citation}}. Functionality is enhanced for all the templates covered, now supporting quotes, notes, archive links, identifiers, etc... There's a lot of hoo-haa about how {{unicite}} could screw up things, but very little examples to back that claim.Headbomb {ταλκ – WP Physics: PotW} 23:33, 27 October 2008 (UTC)
Members of {{Cite XXX}} are closer to one another than they are to {{citation}} or to {{unicite}}. Please let me know what current template {{unicite}} is attempting to match--I see plenty of discrepancies in the above examples. You have already commented that some of your design choices have reflected your personal aesthetics (rather than current behavior of an existing template). All of the advantages you list could be achieved by using the same {{citation/core}} for other citation templates; what advantages are unique to a "one true template" solution?
I'm not going to waste my time reiterating why choice is generally a good thing -- I suppose that I'll save that for when you propose switching from other templates to {{unicite}}. --Karnesky (talk) 00:38, 28 October 2008 (UTC)
Well for output matching, there's a lot of corrections introduced and enhanced functionality. Baring the final semicolon in the authors (that will be removed), {{cite mailing list}} is identical (except in a comma). {{cite journal}} is nearly identical, the differences being consistent identifier output (identifier:identifier), that "Retrieved on 2000-01-01" is not displayed if identifiers are provided. The only output difference is a comma instead of a colon between issue and pages and that the order of identifiers is a bit different (id is put in front of all others since it's a special parameter. It could also be put last). I'm not saying {{unicite}} perfect or even ready to implement as of now. There's still a lot to fix, such as the editor/edition thing, {{cite conference}} displaying edition next to conference title rather than booktitle, and many others quirks. Since this attempt to uniformize citations, and that citation templates are not uniform, there's bound to be differences in output and other fixes. Headbomb {ταλκ – WP Physics: PotW} 17:35, 28 October 2008 (UTC)
Responding to Ling.Nut's original comment, if the backend merge of {{Citation}} and {{cite journal}} goes ahead we will then have two templates which can work with {{Harv}} and both will allow minor punctuation tweeking. So you should get more flexability rather than less. Currently the new backend is undegoing testing at Template:Citation/testcases, Template:Cite journal/testcases input and testing there most welcome.
While there is a good point about making things easy for novice editors we also want to making things look professional in FA's and such like. Consistency of reference formats in an individual article is a desirable goal, which in turn requires consistency between the various cite XXX templates and to a lesser extent Citation. This seems to be getting there. In actual fact there is very little variation in the output of the templates. But for a difference between . and , we do have a defacto house style.
There are lots of advantages of templates over hand crafted references, they reduce problems of getting consistant formats and produce COinS data which is increasing being used by people who want to pull references out of wikipedia. Should efforts be taken to allow editors more control over output formats? Should we think about deprecating some of the input parameters to reduce reduncancy? --Salix (talk): 20:41, 27 October 2008 (UTC)
TLDR break
Skipping aside everything else, I have only one issue with the follow unified template, that of managing size of fields. However if we have solid documentation (for web, for books, et al), that shouldn't be an issue. However, I understand that people don't want to throw out their way of citations. So, my thought for everyone to respond to:
Assuming that all non-template/alternate forms of citations are still allowed (Harvard, manual, plaintext), would you support the unified citation template or not?
Other than my fundamental problems with this proposal and its potential implications of it (which I have stated above), one obvious big problem with this is one of size and complexity of the template which is needed to let it do everything - its going to be very easy for people who are not familiar with it to put stuff in the wrong field - if we do go this way, it may be better to package the results as Cite book, cite web etc. just to make it easier to use. (And the Block quotes looks terrible in a list of references, which is how it will be used).Nigel Ish (talk) 16:04, 28 October 2008 (UTC)
"And the Block quotes looks terrible in a list of references". - Nigel Ish How so? I think they look a lot better as they stick out and that makes them easier to parse as it is not bunched up with authors/titles/pages/publishers/etc. Headbomb {ταλκ – WP Physics: PotW} 17:45, 28 October 2008 (UTC)
Specialized cite templates
I'm not reading the entire discussion, so can someone answer a quick question? Would any of the proposals get rid of specialized templates like {{cite UTSR law}}? --NE206:46, 27 October 2008 (UTC)
The page Nereid has a really horrible array of hat links. Is there something that can be done about them? Is a disambiguation page with all the different uses of the different names appropriate? Mintrick (talk) 17:58, 28 October 2008 (UTC)
Yikes. Maybe create a couple 2-link disambiguation pages, and link all of them inline, in a single hatnote. Still not ideal. —MichaelZ. 2008-10-28 18:39 z
Move the hatlinks for proper names down to the section with the list of names, making them section redirects.
... Word uses so-called "smart quotes" (that look “like this”) which may be inadvertently included in your article. These quotes are generally frowned upon ...
To parrot the MOS: "The exclusive use of straight quotes and apostrophes is recommended. They are easier to type in reliably, and to edit." Seems to take a fairly clear stance. Christopher Parham(talk)11:22, 29 October 2008 (UTC)
Please use your judgment, and don't blindly tear around changing quotation marks. Both forms are acceptable, and Consistency says “Edits should not change a stable article from one guideline-defined style to another unless there is a substantial reason to do so that goes beyond mere choice of style.” Cheers. —MichaelZ. 2008-10-31 05:25 z
Yeah, and if you take “defined” to mean “that looks pretty to you” then it's even more fun. But if you take “defined” to mean “defined”, then neither the word nor the spirit of this guideline says “go around and convert all quotation marks to typewriter quotes.” —MichaelZ. 2008-10-31 15:41 z
Oh, I think it does. Well the spirit does, at least - the guideline quite clearly recommends non-use of curly quotes, so it's quite in order (and indeed commendable) to bring articles into line with that guidance.--Kotniski (talk) 16:29, 31 October 2008 (UTC)
An example of a good reason to remove all curly quotes is the need to use a spell checker. Since the Wikipedia editing software does not provide a spelling checker, the article must be copied to some editor that does. If that editor does not make it easy to edit typographical quotes, it would make sense to change them all to straight quotes. An example of such an editor is EMACS for Windows. --Gerry Ashton (talk) 16:30, 31 October 2008 (UTC)
2¢: Having been involved in this discussion for a few months, I would like to comment on the current state of things as it appears in this thread. The need for a solution exists, in order to allow for the energies of all parties to be directed to more important pursuits. I do not feel the solution "go ahead and remove curly quotes when I see them in articles" is enough. This invites edit warring and more and more somewhat arcane threads on various talk pages such as this particular section of the MoS talk. In an ideal world, there would be: 1.) a firm consensus, established in an open vote such as exists on AfD pages. 2.) a resulting action, either a.) creation of a bot to convert all quotes to typewriter (straight) quotes or b.) firm statement in MoS that either form is acceptable. It is time to move on regarding this issue, and I would like an experienced administrator to set up a vote with clear intent as soon as is feasible. Sswonk (talk) 17:01, 31 October 2008 (UTC)
Well we have quite clear and stable guidance on this page, saying that we use straight and not curly quotes. It seems quite a simple matter with no particular reason to change (particularly as you don't normally see the curls in the default font anyway). The best thing the MoS can do to suppress edit warring is to offer unambiguous guidance like this, so that if edit wars do break out, one party can point to the wording here and the other will (if acting in good faith) back down. --Kotniski (talk) 18:04, 31 October 2008 (UTC)
(Spoken deliberately with a rising pitch toward conclusion indicating agreement with some lack of sureness) Yeeesssss..., however, I don't think It Is Me Here got a good answer to the question, "who is right?" The MoS doesn't say "we use straight and not curly quotes", it says straight quotes are recommended. Until it does say "curly quotes are deprecated, don't use them at all", the question still has no answer. That is what I am asking for, if only to close the issue and move on. If it is definitely a detriment to proper search engine function to use curly quotes, they should not simply be recommended against, they should be removed, and done so in an efficient way i.e. by a bot. Sswonk (talk) 18:47, 31 October 2008 (UTC)
It is clear from the state of the guideline that there is no consensus to ban typographic quotation marks from Wikipedia, and of course banning plain typewriter quotation marks is not practical. It will probably continue to be both ways—and somewhat more one than the other. We should learn to live with it, which is exactly what I'm asking for here.
But as usual, there's some misinformation being perpetuated in the discussion:
“An example of a good reason to remove all curly quotes is the need to use a spell checker”—perhaps a spell checker can't enter curly apostrophes, but I don't see why it has to do anything with quotation marks. If you can't enter typographic punctuation on your system, then just enter the typewriter apostrophes and quotes, and another editor can change them later if it is appropriate. If the problem is that you can only paste ASCII and not Unicode text into your text editor, then I suggest that your editor is unsatisfactory, because it will also fail to process the tens of thousands of articles which include dashes, Latin letters with diacritics, and any foreign-script text.
“the article must be copied to some editor that does”—Safari/Mac has an excellent inline spell checker, which deals with both types of punctuation (maybe the Win version does too? Doesn't Firefox have a spell checker included, or available as an add-on?)
“you don't normally see the curls in the default font anyway”—perhaps you don't but many readers do, both on screen and in print. With the default settings in all Mac browsers I've tried, and I think in Safari/Win, the typewriter quotation marks are easily distinguishable and help make the difference between the look of typescript and professional typesetting. The effect is exaggerated in print versions of Wikipedia. Please don't assume that your browsers page rendering is the same as other readers', or that everyone uses Wikipedia content the same way you do.
“If it is definitely a detriment to proper search engine function to use curly quotes”—I don't believe quotation marks in pages affect searches at all. Apostrophes are no problem with Google searches, but they may affect Wikipedia searches. And of course, for on-page text searches, Canada, Canadian, Canadians, Canadian's, and Canadian’s are five different strings, so inferior search strategies will always get inferior results, no matter whether we use one kind of apostrophe or another in Wikipedia. To find any or all of these, enter “Canad” into your text search box.
I'm forced to agree with Mzajac here. The only real issue with curly quotes is that they're difficult to edit - people who edit an article containing curly quotes are likely to substitute straight quotes. The result is likely to be inconsistent usage. I'd say this: once straight quotes are used once in an article, all other usages in that article should be similarly replaced, because it's unnecessary work to keep fixing them up each time they're edited. Dcoetzee21:24, 31 October 2008 (UTC)
Searching (whether inline or via MediaWiki search) is impacted too, as is inter-article consistency. When it comes down to it, there are a couple of reasonable idealist reasons for using typographical punctuation, and several better pragmatic ones for sticking to ASCII. Discouraging without outright banning at least allows for a potential future change, but it is evidently not the case right now that the question "should I use curly or straight quotes" does not have a correct answer on WP. Chris Cunningham (not at work) - talk22:24, 31 October 2008 (UTC)
Again, some of those assumptions are just false.
What, exactly, is “unneccesary work” in an open-source project? If an editor wants to work on improving typography, or punctuation, spelling, writing quality, or whatever, why would you want to propose a new rule that she shouldn't do so?
Quotation marks in the text do not affect search at all—apostrophes may, and only in some cases, although there is no evidence that they hinder it. We don't restrict the range of character code-points in any other context, e.g., mandate only American English, use a controlled vocabulary, or restrict content in any way to “improve search” in some undefined way.
Having been arguing the case for en dashes over ASCII's hyphens in the thread above, and accepting the claims that in some browsers the straight/curly difference is seriously visible, I find myself forced by consistency to move over to the pro-curly camp. But I wonder if it would be possible for the matter to be solved at developer rather than editor level - I mean by having the software automatically render apostrophes and quotes the curly way (and requiring editors to use a special template if they wish a particular character not to be converted). Basically the algorithm would be something like left curly if preceded by a space, right otherwise - but I guess it gets more complex than that. Anyone know if that idea's ever been considered? Also do we know if curly apostrophes are matched to straight ones in the search box, in the same way that en dashes are matched to hyphens? (If they aren't, I guess they easily could be.)--Kotniski (talk) 17:49, 1 November 2008 (UTC)
Yes, the ideal situation would be for the wikitext parser to take pure typescript, and render it as nicely-formatted typesetting. There are several bugs listed at Bugzilla which would go a ways toward this goal they were implemented, but don't hold your breath.
Curly quotation marks and apostrophes should never be required, but the fact is that they are allowed. They may be used where appropriate, and perhaps for Wikipedia 1.0, (or maybe 2.0), we could someday institute a higher level of print-quality typographic standards, for extremely polished articles. —MichaelZ. 2008-11-03 15:41 z
Headings - input needed
Hi, all. I've been encouraged again to open a discussion on the headings. I'd appreciate clarification of MOS:HEAD. How do you understand the guideline that states:
The nesting hierarchy for headings is as follows: the automatically generated top-level heading of a page is H1, which gives the article title; primary headings are then ==H2==, followed by ===H3===, ====H4====, and so on.
Previous attempts for input failed or were marginally successful: see here and here. I have had a long-standing disagreement with Rotational (talk·contribs) that remain unresolved (see AN/I requests for input here and here). I'd like to finally put this to bed. The language of MOS:HEAD seems clear to me: The automated title is H1, and below that primary headings are H2, not "choose whichever one you like best". Thoughts? --Rkitko(talk)22:02, 30 October 2008 (UTC)
Sure. Rotational prefers H3 or H4 as primary headings, reverting changes to his articles to his preferred style (diff). Several of the comments on one of the AN/I discussions ended up endorsing his preferred aesthetic at List of florilegia and botanical codices, though the recent FLC failed for many reasons, one of which was "The list does not follow style guidelines (i.e. headings, en dashes in year ranges)". I believe the guideline is clear, and certainly consistency among articles also establishes H2 as the primary heading, not H3 or H4. I've found this to be more of an issue of WP:OWN and WP:POINT (see AN/I discussions), but nothing's been done about it and that part of the discussion is beyond the scope of this one. Each time I bring this up, other editors invariably say, "What's the big deal?" - You may be inclined to agree. Regardless, if the intent of the guideline wasn't clear, perhaps it should be reworded for clarity. --Rkitko(talk)23:18, 30 October 2008 (UTC)
O.k., now that I understand it, my thought is that (a) you are right (see alsowp:Layout#Headings and sections) and (b) it doesn't make that much difference as long as there is a hierarchy that starts somewhere. Granted, starting at H2 prompts the "edit" button to appear, which is a nice feature, but if Rotational insist on being irrational and the issue isn't substantive then I'd say, since you asked, that your best option is to say to yourself that Rotational is wrong and then move on to more productive battles. Butwhatdoiknow (talk) 01:08, 31 October 2008 (UTC)
Thanks for your input. FYI, the edit link does show up for any level heading. The purpose of my question here was to affirm or challenge my interpretation of the guideline, which is one of many facets of my disagreement with Rotational (this one issue may not be as substantive, his breaking of policy such as WP:OWN and recently WP:POINT is more so). Moreover, his preferred aesthetic extends to image placement (diff - MOS:IMAGES states "Start an article with a right-aligned lead image") and other choices. He's admitted to not liking Wikipedia's aesthetic and doesn't seem to care for working toward consensus or challenging the guidelines, except in the articles he creates. Well, I digress, all of those arguments are laid out in the AN/I discussions mentioned above, if you care to read more. Appreciate your time. --Rkitko(talk)01:18, 31 October 2008 (UTC)
Your interpretation is correct, headings should be nested down through all the levels, starting at h2. Yeah, it is an MOS, so that means that we can diverge from it when consensus allows. Rotational should strive to find consensus or just smile and lump it and get on with building the encyclopedia.
If it's only the headings' appearance that's at issue though, you might suggest that he adjust his user style sheet so that top level headings's will look the way he wants them to. If he needs help, he can drop a note on my talk page, and I can show him how to do this. —MichaelZ. 2008-10-31 02:35 z
I wasn't aware you could alter your style sheet that specifically. I believe it was tangentially suggested earlier by another editor about a year ago. I will suggest it again. Thanks. --Rkitko(talk)03:00, 31 October 2008 (UTC)
I agree that Rkikto is right, but ... it's not one of the biggest deals I've seen. I'd let him have his/her way—perhaps s/he finds H2 rather large for the context ... Tony(talk)03:27, 31 October 2008 (UTC)
Rotational doesn't seem interested in help altering his user style preferences. Letting him throw certain provisions of the MOS away without a reason other than "I don't like it" has allowed it to become a larger issue. He reverts other productive aspects, including stub tags diff. --Rkitko(talk)17:48, 2 November 2008 (UTC)
There are people who pursue different ways of setting out articles, and to a certain extent we not only allow that but in a sense encourage it, as the changes may be beneficial. We progress and get better through challenges to the status quo. MOS:HEAD is a guideline - that is to say as a community we feel that the approach we advise works quite well, but we are open to different ways of doing things. However, if we find that an editor is working in a way that is disturbing other editors, and their method is not seen as a net benefit, then as a community we can start to suggest that that editor listen to the wider consensus, which is where a guideline can come in useful. Having looked at the ANI reports linked above, it is not clear that Rotational's edits are disturbing to all editors - there seem to be at least as many who feel that Rotational's use of headings is as or is more aesthetically pleasing than that detailed by MOS:HEAD. I don't see that Rotational is behaving in a manner that is a significant MoS issue; nor is Rotational being so disruptive by the individualistic use of headings as to be the cause of another ANI. This may be a matter for some other conflict resolution method. You could try Wikipedia:Mediation Cabal, or I would be willing to mediate between the two of you. I have worked within various of the Wiki dispute resolution areas including the Mediation Cabal, so I have some experience of and some success with dealing with personal conflicts. There would be two points to consider is a dispute resolution. One would be that Rotational's edits are causing you some distress, and are against general consensus, so it would be interesting to hear Rotational's rationale for continuing, even though you have made it clear that you are unhappy, and that in principle the edits are against general consensus. The other is exactly why the edits are so bothersome to you, as they are fairly innocuous, and can be easily ignored. Let me know if you wish me to set up a discussion between the two of you. Regards SilkTork *YES!19:15, 3 November 2008 (UTC)
Since the citations templates do not give uniform outputs, I've taken the liberty to write one that encompasses most of them. It is very bot-friendly, as all a bot would have to do is to replace {{cite X}} with {{unicite}} and everything will be tidied up.
Templates merged
These are the templates that can be bluntly replaced with {{unicite}} with very minimal problems if any.
Supports everything the old templates supported, and generalizes the features of some templates to all templates (like ISBNs, Quotation support, etc...)
The template is built in way that the "large work" is italicized, while sections are in quotes. If you provide |journal=, |conference=, |work=, |encyclopedia=, |newsgroup=, |mailinglist=, those will be italicized, otherwise whatever you wrote in |title= will be.
Some "advanced" features, such as the presence of a doi overiding the "Retrieved on YYYY-MM-DD" message.
Now allows for notes, so you can point out something like "Reference might be WP:POV." or "This author uses the A_ji convention instead of the A_ij convention for matrices."
Quotes & Notes are separated from the "reference" for easier reading.
Warns if some important inputs are missing (like titles)
Far easier to spot inconsistencies, as output is uniformized
Many other things
What needs to be done/ Oddities
Implement COinS. I don't know how to do this, if you do, or know someone how does, please let me know.
ISSN searches are done with Google instead of a search engine specialized for that identifier. I don't know if there's a point of contention here, but if you know of a specialized search engine for ISSN, let me know and I'll use that instead of google.
Implement |accessdaymonth= and |accessmonthdate= from {{cite web}}
Implement |dots=no, so {{unicite}} can be used in sentences.
|Quotes=no is not supported. The template is built in a way that you shouldn't have to specify whether or not quotes are used. Also {{cite journal}} recently depracated/or removed support from |quote=no. |Quotes=no might end up being supported as some people used |quotes=no for reprints, producing Author (1999). "Title". Journal. 1: p.1. {{cite journal}}: |author= has generic name (help); |page= has extra text (help); Cite has empty unknown parameter: |quotes= (help); Unknown parameter |issues= ignored (help)"Reprint". Journal2. 2: 2. 2000. {{cite journal}}: Unknown parameter |issues= ignored (help); Unknown parameter |quotes= ignored (help)
As p. and pp. are not used consistently, page(s) is produced instead. If someone can confirm that bots can pick up all the different entries an place them into |page= and |pages= accordingly, I'll set |page= to produce p. and |pages= to produce pp. Fixed. There is not reason bots can't handle this sort of thing. This is now a wysiwig field.
The last semi colon in the authors shouldn't be there. Fixed.
Template documentation is incomplete/innacurate.
Outputs
Table of outputs
Added nowiki, since the templates have changed drastically since then and the old ones were causing problems. See the previous revision of this page for the correct version. — Carl (CBM · talk) 14:59, 13 December 2009 (UTC)
As pointed out somewhere else [8]: there can't be a period at the end, because some existing citations include additional information there, separated by a comma. If the old citation template doesn't end a particular citation with a period, then the new template needs to follow that behavior. — Carl (CBM · talk) 03:42, 27 October 2008 (UTC)
Yeah, I don't quite know how to tackle this one. I could place a "|dots=" switch so you could use it to refer to anything in a sentence. Bots could then pick up whether or not a citation is placed between <ref> tags. If between tags, dots are on, if not, dots are off. Headbomb {ταλκ – WP Physics: PotW} 06:32, 27 October 2008 (UTC)
The |dots=no switch now disables dots and allows for the use of in-sentence citations. Compare
How is a bot supposed to know whether to add this parameter or not? If unicite is not a drop in replacement, then no bot should be making the change. — Carl (CBM · talk) 16:20, 1 November 2008 (UTC)
My original idea was that if it's between <ref> tags, then it's not in mid-sentence, same goes for those in bullet lists. But I've seen some examples where that might not work. Maybe it's not possible to straightfowardly implement. Maybe it's possible to implement. Maybe it's possible to implement imperfectly, but with a low-enough false positive rate so the benefits outweight the problems. This'll require some thinking. Headbomb {ταλκκοντριβς – WP Physics} 18:00, 1 November 2008 (UTC)
Hopefully the current templates will be re-worked as a wrapper for this template. The typical orphan-and-delete approach would cause more problems than it would solve. — CharlotteWebb09:52, 26 October 2008 (UTC)
There are already efforts to make {{Cite XXX}} use {{Citation/core}} as a common back end. It is unclear to me why Headbomb is ignoring that effort--he has not commented on those on-going merge discussions and has not responded to the primary person responsible for the merge on this page (going so far as to archive rather recent discussions). --Karnesky (talk) 15:01, 26 October 2008 (UTC)
Entirely pointless change for changes sake - produces an extremely complicated template with a collosal number of fields which is a guarantee that people will get it wrong most times. In addition MoS is ENTIRELY the wrong place to discuss this - use of Cite templates and the particular Citation style that this imposes is entirely optional and nothing to do with the MoS. It reeks of an attempt to use MoS to try and force everyone to use the template and with it that particular means of citations.Nigel Ish (talk) 15:57, 26 October 2008 (UTC)
I really hate having the quotes appear separately in blockquotes rather than inline with the citation. What citation style is this supposed to be following? Kaldari (talk) 20:47, 27 October 2008 (UTC)
Bad. Very bad. Only readable if in a standalone citation not in references. If this is actually used, I'll edit the template to put the quote at the end in quotes. — Arthur Rubin(talk)18:43, 5 November 2008 (UTC)
It doesn't make any sense having a semicolon between the authors and the date (which is already in parentheses). This isn't just bad citation style, this is bad grammar. Kaldari (talk) 20:50, 27 October 2008 (UTC)
This concerns the sections concerning the "dash". (WP:DASH)
The section makes a presumption that automatic redirects may be made (as is typical in mainspace, and other spaces).
But that isn't the case in category-space. We're limited to soft-redirects there.
So realistically, if this section is applied, then we'd be duplicating every category which has a "dash" in it's name.
And also, having category redirects means that they are bluelinks. Which means that they have the potential to be categorised themselves, which can cause issues, which may not be noticed by the casual observer.
And further, the whole point of categories is navigation (as noted at WP:CAT). So forcing category names to make it more difficult for those who don't have an "en dash" on their keyboard, would seem to be a hindrance to navigation.
Therefore, I'd like to propose that categories be an exception to WP:DASH. So in categories, the hyphen is to be the preferred punctuation used. - jc3709:01, 29 October 2008 (UTC)
Discussion
I understand the problems, but it is worth making an effort to overcome them, rather than accepting a substandard and inconsistent writing style. In any case, I don't agree that all the "problems" you mention really are problems. People don't (I assume) type category names into the search box very often (and negotiating a soft redirect wouldn't be a major inconvenience on the rare occasions that they do). In any case, it seems you can have hard category redirects if you want (see Category:Poland topics). The only issue to be dealt with is whether we can get the redirects to work properly (i.e. to have bots active that automatically recategorize articles that have been placed in redirected categories). Since this question keeps coming up, I'm going to try to find some bot people to raise it with.--Kotniski (talk) 09:38, 29 October 2008 (UTC)
"rather than accepting a substandard and inconsistent writing style" - You're kidding, right?
This concerns names. It's not about a piece of prose. And further, the choice of type of dash has to do with typographics, not "writing style".
And I personally type category names into the search box. And incidentally, categories are linked to quite often. If one didn't use the "proper" dash, then it would show up as a redlink, to the possible consternation of the editor.
As for consistancy, we would be consistant. In category space, names use a hyphen. It's a simple guideline, not open to confusion.
And incidentally, since policies and guidelines are to reflect common practice, you may also wish to consider that quite a few CfDs have been closed with varying results. - jc3711:59, 29 October 2008 (UTC)
Typographics then. But names should be written correctly no matter whether they are "just names" or appear in prose. The redlink argument is easily solved with redirects, just as it already is with article names (which are searched for and linked to far more often than categories anyway). And while consistency within category space would be better than the confusion we have now, consistency between category space and article space (and good English usage) would be better still. The only non-imaginary problem remains the question of the bots handling the redirects, but that's one we can solve.--Kotniski (talk) 12:20, 29 October 2008 (UTC)
I'm curious. I've seen the word "correct" (and "incorrect", for that matter), several times now. I'm curious as to what that's considered to be based upon. - jc3712:40, 29 October 2008 (UTC)
Well, on the standards that we apply to article names and article content (per the MoS), which are themselves based on what is generally considered to be good English style according to leading style guides etc.--Kotniski (talk) 13:11, 29 October 2008 (UTC)
The MoS is a guideline of suggested "good practice". And guidelines are supposed to reflect "common practice" on Wikipedia. So that doesn't seem to reflect the "correct" usage you note.
So moving on to "what is generally considered to be good English style according to leading style guides etc." - I'm wondering what style guide you found it suggested that the "en dash" or the "em dash" is more "correct" than the hyphen for usage. I know that there are quite a few authors across quite a few countries, all whom offer their own opinions on what is "correct" in typography. But Ok, would you point me to which ones specifically you're referring to? - jc3713:54, 29 October 2008 (UTC)
I don't know precisely which style guides any particular advice in the MoS is based on; if you disagree with it take it up as a general point and not in specific relation to categories (though the recommendations about dashes etc. have been much discussed and it's unlikely that there will be consensus to change them). Re the specific problems with categories, see my unindented post below.--Kotniski (talk) 14:54, 29 October 2008 (UTC)
Occuli, thanks for raising this; I'm sorry to say that the examples provided are wrong. En dashes between spaced items (one or both) must themselves be spaced: "United Kingdom – United States relations". Perhaps these tutorials are of assistance to anyone who is unsure. Tony(talk)14:16, 29 October 2008 (UTC)
Re the redirect problem, Russ has described the operation of his bot RussBot at his talk page. It would appear that this bot does indeed solve the issue - after a cooling-off period of seven days, articles are transferred from the redirected category to the target one. So as far as I can see, there are no remaining reasons for not adopting a typographic style for categories consistent with that used elsewhere in the encyclopedia.--Kotniski (talk) 14:54, 29 October 2008 (UTC)
So for seven days, articles will remain in the "wrong" category. And your casual user, who may know nothing of the differences between hyphens and en-dashes, will probably be confused as hell to see a soft redirect to what appears to be the same category name. I think it's a great idea to suspend DASH for categories, the positives outweigh any negatives. --Kbdank7115:27, 29 October 2008 (UTC)
I'm sure most of our readers are less ignorant of English punctuation than you think (they are more likely to be confused as to why a category is written differently from its associated article title). And no, I don't think articles remain in the wrong category for seven days - once the redirect has been set up and not reverted, they should be moved after one day (or we could even put them into the correct category to start with - that just involves pasting in the name of the category, so can be done even by those editors too lazy or Java-sceptic to click on the dash symbol). --Kotniski (talk) 15:52, 29 October 2008 (UTC)
You really think the casual reader is even going to notice the difference? Seriously? I have a very hard time imagining anyone sitting at their computer thinking "Geez, Wikipedia is such a piece of crap. Just look at this, they used a hyphen here and a dash there!" An English professor, perhaps. I don't think they are a large percentage of WP's visitors, though. And the casual editor, are they going to a) find the MOS, and b) wade through the beast to find out they have to name things with something they can't even type? Or are they just going to use the hyphen? (BTW, any reason you didn't use a dash in your last post?) --Kbdank7116:25, 29 October 2008 (UTC)
Yes, I'm too lazy to use dashes on talk pages (I spare them for where our readers are going to see them). But yes, there are people who care about punctuation and such geeky things, which is why the manual of style exists. So all right, on the rare occasions an editor actual types (not pastes) into an article the name of a dashed category, they might write a hyphen instead and the article will remain wrongly categorized for a day. Too bad. It could just as well work the other way if we adopt the hyphens-only rule - more literate editors will assume that the dash is required, and the article will again be wrongly categorized - this time for an even longer time if no-one's bothered to set up the reverse (and perverse) redirect.--Kotniski (talk) 17:07, 29 October 2008 (UTC)
Yes, for technical reasons the category names should use the simpler hyphens.
Kotniski: The category system is a tool to find and organise items. And tools don't have to look pretty, it is much more important that they work well. Remember that the category names are not article content, instead they are meta-data. And to use any kind of special characters in meta-data usually is a bad idea.
I manually type in category names all the time, and I have no en-dash on my keyboard, only the hyphen. If you change the category names to en-dashes then I can no longer type in such category names in the Wikipedia search box.
And the category redirect system is currently not working well. Several editors and programmers have spent hundreds of hours trying to fix it, but it is still partly broken. I am one of the editors who worked together with Russ to get his category bot to at least solve some of the problems with category redirects, so I know what I am talking about. (See Template talk:Category redirect#New categorization ideas.) To rely on the broken category redirect system to solve any kind of problem is foolish.
Given that categories are more of a technical function and the difficulties in navigating categories with characters that aren't on a keyboard are used, combined with the very low profile of categories to content, I agree that DASH should be suspended ONLY for categorization purposes. MBisanztalk17:37, 29 October 2008 (UTC)
(unindent) But the problems only arise if the redirects don't work. (And why do you assume the problem only works one way? You don't think we have any punctuation-literate editors around?) So David, tell us what doesn't work with category redirects.--Kotniski (talk) 17:47, 29 October 2008 (UTC)
Kotniski: There are a whole bunch of problems with the current category redirect system. And those problems are pretty complicated to explain. So I am not going to spend two-three hours and several pages of text here to try to explain them for you. Instead you can read up on them over at Template talk:Category redirect.
That page appears to be largely obsolete (it says that the bot is discontinued, for example). If there really are any genuine problems at the moment with the bot's operation, then please can you at least summarize them?--Kotniski (talk) 07:15, 30 October 2008 (UTC)
Right now the "count" seems to be 4:2 (I'm not sure of Tony's preference.)
But "votes" aside (since consensus is not a vote), there are some clear arguements against (for technical reasons, for example), and the ones "for" seem only to be because of a preference for a certain typographical "style".
What?? Have you read any of the above? There are absolutely NO arguments against that haven't been answered (apart from a vague promise that we will find such at a template talk page), and "preference for a particular typographical style" is what this page is all about. If you don't care about style, I suggest you stay away from the MoS - there are plenty who do care, even if they haven't participated in this particular discussion.--Kotniski (talk) 07:15, 30 October 2008 (UTC)
I think we need to run a straw poll on this, either here or somewhere like WP:VPR where there is more visibility, if out of 7 well meaning, experienced users, the split is 3-4 on an issue, then clearly more voices are needed. MBisanztalk13:11, 30 October 2008 (UTC)
OK, but let's wait for David (or someone else) to reply regarding any current problems regarding the redirecting bots. As I see it the whole issue hinges on this. If the bot works, then all the objections to using dashes are pretty much answered. If it doesn't (and the problems can't easily be resolved) then we may have to fall back on hyphens.--Kotniski (talk) 13:28, 30 October 2008 (UTC)
I don't know what the problem is with the bots, and honestly, even if there wasn't one, I'd still feel DASH should be suspended for categories only. The redirect bot solution is making things much more complex for editors and readers, it relies on a bot that historically isn't always running, and it creates the overhead of an added category (yes, even if it's only a soft redirect, it's still a category) for each category that uses a hyphen or dash. "For style", while normally a valid reason, doesn't seem to overcome the problems here. Can we get this moved to WP:VPR? Bot problem or not, this should have a wider audience. --Kbdank7114:44, 3 November 2008 (UTC)
I still don't see any problems that don't apply equally well to article pages. Since we use dashes there, it seems to me that using dashes in categories as well actually reduces complexity, rather than increasing it (and saying "much more complex" is surely an exaggeration). But certainly this is an issue that needs to be discussed and resolved one way or the other, so taking it up at the Village Pump might not be a bad idea.--Kotniski (talk) 15:25, 3 November 2008 (UTC)
I'm getting totally baffled by the apparently switching of conventions of units. It seems like we've had: only wikilinking first use, then don't wikilink infoboxes; use the abbreviation, then don't add a period, then expand to the full word, then don't wikilink common units, then abbreviate the conversion. &c. &c. This all seems to increadibly fussy and utterly unimportant, yet it comes up in FACs all the time as a sticking point. Can't we choose one standard and stick with it? As a dedicated editor I'm having a difficult and frustrating time trying to figure out how I should handle units.—RJH (talk) 17:29, 2 November 2008 (UTC)
FAC will always be a process of limited utility; it will always be easier for a language crank to insist on his pet reform than to develop a genuine Sprachgefühl for English; and even that will be easier for reviewers than knowing anything about the actual subject of the article, seeing whether it is reliably sourced, or conveys its information clearly. Therefore we will always have more of this cruft than useful criticism. The sort of questions which RJH is running into do not address any of these concerns, and are part of what renders FA a standing embarrassment to Wikipedia.
The solution is not to have a single standard; it is to have no standard on these issues save clarity and utility. (This may well produce different results on different articles; articles on the history of the metric system may well link units where other articles would not.) SeptentrionalisPMAnderson18:17, 2 November 2008 (UTC)
Many things are baffling about the MoS and FAC criteria, the rules of which are constantly flung around to corral editor behavior and "blandify" articles. Not the least of which is that the MoS is constantly changing; even the rule flingers can't keep up and have been known to reference a nonexistent "rule" in FAC criteria. I think we must resign ourselves to bafflement. —Mattisse (Talk) 04:07, 3 November 2008 (UTC)
Well the current version of things has been stable since the rewrite of June 7 (it was rewritten because there were too many rules and subrules, way too much redundancy, etc). It was very extensively debated, so I expect the "big ideas" to be pretty stable, even in the mid to long term.Headbomb {ταλκκοντριβς – WP Physics} 08:36, 4 November 2008 (UTC)
Does it make any sense to have a single "units" template that can be used to display units in any appropriate form, with options for conversions, specialty standards and so forth? It seems that it would be easier to maintain a standard template than to have everybody doing edit massages to match the MoS.—RJH (talk) 20:38, 4 November 2008 (UTC)
Standardization of templates is a very controversial topic in general. See above:
Any discussion of units template must mention 'Template:Convert'. That is the most popular and flexible units template on Wikipedia. See examples of its use in: Renault 5. Regards Lightmouse (talk) 10:41, 5 November 2008 (UTC)
For whatever reason (don't ask me why), the "Objectivism" in question is always spelled with a capital "O". But since Wikipedia always recognizes the first letter of articles as capital letters, an article called Objectivism is indistinguishable from objectivism. Hence, the parent article—Objectivism (Ayn Rand)—has the disambiguator "(Ayn Rand)", the person who is most identified with Objectivist thought.
However, I argue that the subpages of a disambiguated page do not need to inherit the disambiguator, unless the lack of it leads to similar ambiguity. Except for technical reasons, the disambiguator is not part of the article's title. I used these examples to illustrate my point:
There's a problem I'm having with a rule regarding the categorization of disambiguation pages. I'm not an administrator, so I only learned of its existance a while ago. In particular, this rule, which dates back to late July 2007, conflicts with a project that I started over a year earlier: the categorization of common names and taxonomic synonyms for various families of snakes. One of many examples is Category:Viperinae by common name, which is actually rather complete. Although most of the links are redirects, many important names, such as rock viper and sand viper, are disambiguation pages. The MoS rule indicated will eventually remove many of these important disambiguation pages from such categories, rendering them incomplete, which will be a shame. I explained the mechanism on the WP:Disambiguation talk page, here, but it did not receive much attention or sympathy. Since my project predates the MoS rule by over a year, and since the MoS rule already includes exceptions for the similar categories Category:Given names and Category:Surnames, I do not think it an unreasonable request for the types of categories that I work with to also be added to the list of exceptions. --Jwinius (talk) 13:12, 4 November 2008 (UTC)
I don't think this is really the forum for this, but it's already been explained how you should solve this problem - classify these pages as set index articles instead of dab pages (or, if they also contain non-snakes, set up a separate set index article or simply a redirect and classify that how you want it).--Kotniski (talk) 16:30, 5 November 2008 (UTC)
If MOS is going to invest all this verbiage into describing which of these should be uses where, should it not take the elementary precaution of indicating to editors how to get these constructs into the wikitext? Saying where to find each on the "Sign your posts on talk pages" line would be a help to editors just trying to write content.LeadSongDog (talk) 22:11, 5 November 2008 (UTC)
Proposal to deprecate and remove images that say 'this is not an image please add one'
I see lots of pictures that say "Replace this image". For example see in Ann Robinson. There is nothing in the images section of the MOS about them. I propose the following text:
Articles should not contain images/text stating that there is no image and/or whose purpose is to invite editors to add an image. If such images are present, they should be deleted. This applies to "Replace this image male.svg" or "Replace this image female.svg"
Strong support—They look dreadful in their grey complexity; they make the article look perpetually unfinished; they push the assumption that an article can't be good unless it has an image; there are better ways of encouraging WPians to locate suitable images than defiling the very top of an article. I can see why the practice was started in good faith, but in retrospect it looks like a bad misjudgement. Such encouragement should be an important role of WikiProjects. Tony(talk)13:35, 10 October 2008 (UTC)
Support. They look bad, push useful information further down the screen, and if anything probably encourage people to upload non-free images (people who know about Wikipedia's image use policy are also intelligent enough to know that an article doesn't have an image, and what to do about it, without being told). And the idea that we should discourage adding these things but not allow the removal existing ones is thinking at its muddledest.--Kotniski (talk) 15:05, 10 October 2008 (UTC)
Support removal because new editors often imitate existing style rather than consulting the MOS, and also I think most if not all editors of a website know that an image improves a biography, so these placeholders are not useful. Darkspots (talk) 16:08, 10 October 2008 (UTC)
It doesn't occur to them them that it is people like them who provide photos and they don't know how to upload/add them.Genisock2 (talk) 16:10, 10 October 2008 (UTC)
SupportAll of Wikipedia can be improved. There's no point in plastering pages with big flags attesting to this. This is a good article, but we're going to scream in your face that it can be improved. Punch the monkey to improve Wikipedia! Such self-references make good-quality articles look like they come from an amateur website with those awful “under construction” graphics. —MichaelZ. 2008-10-10 20:01 z
Support. They look awful. No image at all would be better in every case. This is a classic case of the tail wagging the dog; these are put up largely for editors but the vast majority of users are only readers. They still have to look at these ugly placeholders. Britannica doesn't use imagery like this and neither should we. --John (talk) 01:56, 11 October 2008 (UTC)
And also because they don't like their articles to look like ass. Neither should we. These are the equivalent of "under construction" signs and they make our articles look ugly and amateurish. --John (talk) 19:34, 11 October 2008 (UTC)
Support deprecation and weakly support removal of existing imaged commands. We're always under construction and editors who find images will look whether they are needed. -- SEWilco (talk) 19:05, 12 October 2008 (UTC)
+S Someone should find out who came up with this idea, and give that editor a barnstar for their noble intentions. But now we've tried the idea and seen that the costs outweigh the benefits. Let's delete them. Ling.Nut(talk—WP:3IAR)11:24, 27 October 2008 (UTC)
Oppose as proposed. No need to make tens of thousands of unnecessary edits just to remove these, and I they might actually prompt users to upload the images as intended (off the cuff unqualified statement). –xeno (talk)12:26, 10 October 2008 (UTC)
Oppose per xeno. Users might see a lack of an image as an agreement not to have one; an explicit "hey, you there, put a proper picture here!" encourages additions. Prince of Canada t | c12:40, 10 October 2008 (UTC)
Oppose. Absolutely not - the last thing we need is to take a wishy-washy statement about "some people don't like using these" and transform it into a blanket ban. Doing this would not help the encyclopedia one whit. Shimgray | talk | 12:53, 10 October 2008 (UTC)
Placeholders have been independently invented by a number of groups (:No_Photo_Available.svg for example) which suggest a common need and a fair degree of acceptance.Genisock2 (talk) 13:01, 10 October 2008 (UTC)
Oppose - They encourage image submission, which we want, and they don't exactly trash the aesthetic either. Why delete them? I don't think the MOS debate about whether they should be used was publicized widely enough, I'd like to see that misguided change reversed. Avruch T 13:24, 10 October 2008 (UTC)
Oppose per Avrunch. I'd also note that Wikipedia:Wikipedia is a work in progress and we shouldn't pretend that it isn't. Perhaps people can come up with placeholder images that look prettier, but I'm sure that their existence has encouraged image submission (certainly, it's logical that it should have). LondonStatto (talk) 14:17, 10 October 2008 (UTC)
Oppose: I still think we should be using these templates — but that is a different discussion — I don't see any reason to go around removing them, no. - Rjd0060 (talk) 14:28, 10 October 2008 (UTC)
Oppose: As long as we encourage readers to become editors through cleanup templates on the main article (as opposed to talk), then we should be asking for help whenever we can. --MASEM15:09, 10 October 2008 (UTC)
So would you support a message displayed automatically at the top of all articles, saying something like "YOU can improve this article by adding sourced relevant information or free images". It would be less intrusive than these placeholder images, and not be limited to one specific type of "help" on one specific type of article.--Kotniski (talk) 15:31, 10 October 2008 (UTC)
No, that would not be specific enough to be useful, and would still require a large number of edits to alter the current situation. Leaving it the way it is with images in infoboxes (where a free image will go) is fine. MBisanztalk15:33, 10 October 2008 (UTC)
So why that specific request for help? Why is it so likely that readers will have free pictures of people? Or why is it so important that we request those but not other types of image or information? And getting rid of the existing placeholders doesn't necessarily require large numbers of edits (even if you consider that a problem) - it could be done at the same time as bots perform other cleanup.--Kotniski (talk) 15:39, 10 October 2008 (UTC)
Oppose per Masem and Shimgray. The images themselves could definitely be improved though (more abstract, less "western" as someone said). -- Quiddity (talk) 18:00, 10 October 2008 (UTC)
Oppose There are certainly a lot of articles where the use of such images are pointless and feel free to remove those on a case by case basis, but even though they are discouraged there are still situations where they can be useful and so a complete "bad and delete" policy is not helpful. For example if a lot of people independently keep adding unsuitable non-free images to an article whenever the previous set gets deleted it can be useful to put up a placeholder to let them know that only free licensed images are wanted. Some of the main arguments against image placeholders in the past where that not all articles need images in the first place, but in the case of an article where fans will upload any old image they find on google if they find the article without one I think adding a "free image only please" placeholder makes a lot of sense even if it is generally discouraged. --Sherool(talk)22:40, 10 October 2008 (UTC)
But the placedholders we have don't emphasize "free image only", so I still don't see why you want to retain them.--Kotniski (talk) 10:15, 11 October 2008 (UTC)
So how about we just edit the image to say "please replace me with a free image"? Or whatever the verbiage needs to be. One edit handles every instance of the image being used. Prince of Canada t |c10:24, 11 October 2008 (UTC)
Well according to the comments above, the verbiage would need to be more along the lines of "please do NOT replace me with an image unless you have a free one".--Kotniski (talk) 10:47, 11 October 2008 (UTC)
The specific verbiage isn't that important at the moment, and I leave it to wiser minds than mine to come up with the specifics anyway. Point being, if we replaced with (or edited the current) something that actively encourages people to upload a new (free, legal, etc) image, there's a net benefit to the project. Or, why not try it for a month (arbitrary time period), and see what happens to articles, how often new images are placed, how often they're copyvios, etc. Prince of Canada t | c11:02, 11 October 2008 (UTC)
Oppose - what Avruch said. We want more people to contribute, not less. I'd be interested to know from the OTRS people who handle the photosubmission queue if people mention these when they submit pictures. Mr.Z-man06:48, 11 October 2008 (UTC)
I note that none of the opposers has even attempted to answer my question - why do we scream at people to contribute these particular images as opposed to the many other types of images and information they are just as likely to be able to contribute? --Kotniski (talk) 10:15, 11 October 2008 (UTC)
I agree that there is no reason to limit this to people, but this is a major focus because it's where WP:NFCC#1 is most commonly abused. I would support (and be willing to create) similar placeholders for buildings, rivers, lakes, mountains, household appliances, etc. if there was enough demand. However at first glance most inanimate topics appear to already have a free photo, while most people do not. — CharlotteWebb10:38, 11 October 2008 (UTC)
Well yes, because there aren't so many free images about, which makes it all the less likely that anyone will be able to contribute one, and all the more likely that they will be provoked into contributing non-free ones. So it seems that bios are actually the last kind of articles that we should wish to deface in this way. --Kotniski (talk) 10:47, 11 October 2008 (UTC)
The thing about people is that people tend to have pics of them or they do not for buildings and other fixed objects people we get better results by finding existing wikipedians who live near them.Geni20:42, 11 October 2008 (UTC)
Don't follow. People don't tend to have free pics of famous people very often; and "finding existing WPans who live near them" could be done with exactly the same type of placeholders.--Kotniski (talk) 10:34, 13 October 2008 (UTC)
Your argument is illogical, "we don't ask people to contribute everything else, so we shouldn't ask for these" - why does it have to be an all or nothing thing? I'd actually support asking for more. We probably have at least (I haven't actually done the math) 10 readers for every editor. If we could get even 0.1% of those readers to contribute something we'd be much better off. Mr.Z-man17:07, 11 October 2008 (UTC)
So after every sentence in Wikipedia we should write "if you can improve or add to this sentence then please click the edit button and do so"? That's what your argument leads to. I'm not saying we shouldn't ask for help, just that it should be done in an unobtrusive way, and without irrational emphasis on certain types of help rather than others.--Kotniski (talk) 10:34, 13 October 2008 (UTC)
No, I didn't say that and my argument does not necessarily lead to that. If you can't argue rationally, please don't ask others to try and refute your points. That's like saying raising the legal blood alcohol limit for drivers will lead to a 5000% increase in drunk driving accidents because everyone will drive drunk all the time. You continue to make this an all-or-nothing thing - It doesn't have to be. Though, we do already put inline tags on particularly problematic sentences.
How can we ask for help in an "unobtrusive" way that will still have results? If we put things like this on the talk page, almost no one's going to see them, which defeats the purpose. Would you object to a "This article needs an image" cleanup tag? Mr.Z-man19:47, 15 October 2008 (UTC)
because your core claim is fundimentaly false. we ahve stub notices and cleanup templates (and placeholders for buildings and there is one around for warships).Geni20:42, 11 October 2008 (UTC)
What core claim? Stub notices are OK; they go out of the way at the end of an article. Cleanup templates, where appropriate, aren't bad, since as well as asking for help they usefully inform the reader that this article isn't really up to standard (as do stub templates in a way). Again, why buildings particularly? Why warships particularly? Why not simply have one unobtrusive (that's the main thing) object to be placed on any article that lacks an image? Like the "coordinates missing" thing that appears out of the way at the top? We don't need to do it with a placeholder that occupies exactly the same position and amount of space as our hoped-for image is going to.
because useing different images means we get a degree of auto categorization and there are a number of article where it is safe to assume that there will never be a free pic.Genisock2 (talk) 16:51, 18 October 2008 (UTC)
Oppose - I think I share at least some responsibility/credit for these images coming into existence (a suggestion I made once on a mailing list). The hope was that we could correct a significant lack we had of photos of living persons. We can disagree about whether the approach was good, about whether it was successful, about whether we need to continue to add them. But I can't see any point whatsoever in immediately removing them everywhere. –RHolton≡– 17:02, 12 October 2008 (UTC)
You should perhaps drop by Chris Cunningham's talk page and ask him directly, he's the one that said that. I could not find anything either. –xeno (talk)13:02, 10 October 2008 (UTC)
From what I recall, the use is discouraged on dead people's biographies if they were not living when photography was widely available thus an image unlikely. -- Banjeboi22:44, 10 October 2008 (UTC)
From the archives:
Stats. Of the first twenty images linked to the female placeholder, four are deceased. Gia Carangi, Kathleen Kenyon, Ruth Gordon, Sophie Germain. Three are twentieth-century figures who died in the 1970s or 1980s. One (Germain) has been dead 1831. If you're arguing in favor of the placeholders on the grounds that they help educate editors about "fair use"/"free" images, I will argue that in these four cases (20% of the sample) they are actually misleading editors about what kinds of images are usable. Now, the proponents will say that the guidelines discourage the use of the placeholder on any articles other than living person bios; however, the practice is somewhat less clear.Northwesterner1 (talk) 20:07, 18 April 2008 (UTC)
The photosubmission queue on OTRS pretty much takes care of the second issue, especially if we remove the upload link (it should point to commons anyway). And removing the placeholders isn't going to prevent a "a determined copyright violator." Mr.Z-man17:10, 11 October 2008 (UTC)
Why ask?
Kotniski demands to know why we should ask specifically for editors to contribute pictures of people.
It's obviously silly to tag every sentence in Wikipedia with "needs improvement". But when an entire article or section is missing a large amount of information, we tag it as a stub, or grade the article "Start" class. It is actually quite useful to do this - people working with WikiProjects or who just have a topical interest can survey a collection of related articles, see which ones need attention, and focus their energies more productively on filling large gaps instead of making minor tweaks to more mature articles.
When there is a specific sentence or paragraph missing in a relatively mature article, I do usually leave a note on the talk page with an {{expand}} request. I think it's important for editors to point out every deficiency that they notice and cannot correct themselves. Otherwise, it might never even occur to editors more knowledgeable than they or with more free time that something is missing. I see this happening where someone will make a generic "expand" request, and other editors will come along and say, "I don't see anything missing, I'm removing this tag unless you can be more specific." Whether that takes the form of "huge chunks of information missing, should be obvious, tagging as stub" or "here's an outline of what's missing from this article" or "needs date of birth". Specific requests for expansion are useful work that advance the project. It takes time and mental effort to find deficiencies, and doing so makes other editors more productive.
Requests for specific graphics are even more important than requests for text contributions. There's a much higher barrier to contribution, given the need to know how to find or make digital photos, and how to upload them. It's much more likely that someone will contribute photos across many articles than each article will get a photo from a different editor. A celebrity photographer, whether professional or amateur, might have a collection of photos, so it would be useful to generate a list of celebrity articles that are missing photos. But fans of particular celebrities are also likely to be reading the article, and they are more likely to have met the person at a convention or performance event. A personal friend might have a photo sitting around, including of someone who might be deceased. Even if someone has a photo of the subject of the article, it might not occur to them to upload it unless asked. And they might not know how, but having a click-through link lowers the barrier to doing so.
So I'm strongly in favor of asking for these contributions; I think the remaining question is, what is the best way to ask? One viable alternative is a template like {{reqphoto}}, which I use quite frequently, not only for biographies but for geographic places, foods, and so on. It goes on the talk page - it's not "in your face" but people can still stumble across it and it's still available to people who want to take a survey across many articles and who know where to look. The advantage of putting the request on the article itself is that it's considerably more visible. That can be bad if your primary concern is that articles have a "finished" appearance even if they are still a work in progress. But it can be good if your attitude is, "Glad you noticed; if it bothers you so much, help us fix it!" In my experience, notices on the article page tend to get dealt with a lot faster than notices on the talk page, probably because of the far superior visibility.
Is there a reason why no one stopped your crusade for imposed non-uniformity? Let's just stop being asses for a while and let's work to maximize uniformity. I listen to those who make constructive criticism, and when reasoning is explained, things gets done. I'm building a template that should cover 95%+ of citations and produce consistent output. If you don't like it, don't use it. Headbomb {ταλκκοντριβς – WP Physics} 05:50, 1 November 2008 (UTC)
Hmmm, I'm an ass? Where's the civility patrol when you need it? ;-) Look... several folks have flatly mentioned that your template is flatly unwanted. You flatly ignore them. I won't bother to speculate why. You aren't working within consensus, you're ignoring it. Ling.Nut(talk—WP:3IAR)05:55, 1 November 2008 (UTC)
We're both guilty of being asses here. And while several folks mentionned WP:IDONTLIKEIT (and arguments of the WP:IDONTLIKEIT type can duly be ignored, as they are not substantiated), several others supported the idea ([9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], and the list goes on). As far as working with people go, just about everything that was raised has been addressed (I could offer diffs, but {{unicite}} is so different than its original form (since you know, I listen to people who argue with arguments) that this it'll probably be more confusing that anything to understand what the complaints were about). There's very little left to do to have something close to a "final product". The template generalizes the features to all templates covered, and streamlines pretty much everything. What's left to tackle is thing about how to format the quotes, and how to format original publishing dates, and to implement harvard referencing and COiNS. If you have a specific problem with a specific output, then I can address it. See for example [20], [21], [22], [23], [24], and a lot more. If you're simply throwing WP:IDONTLIKEIT however, I can't do much for you.Headbomb {ταλκκοντριβς – WP Physics} 06:16, 1 November 2008 (UTC)
Please don't lump me together with you in this respect; I'm not being an ass. And apparently you can't do much for anyone, since you won't listen to anyone. No one has made IDONTLIKEIT args. They've said your template is awkward and unnecessary, plus it leads toward unwonted and unwanted standardization. You don't listen. Ling.Nut(talk—WP:3IAR)06:30, 1 November 2008 (UTC)
"If you don't like it, don't use it." Since you have already stated your position is to deprecate existing citation templates, people who prefer the other templates to yours will absolutely need to complain sometime. Similarly, because some people who see a problem with cite template proliferation disagree with this proposed solution, they may see it as contributing to the problem & will need to complain sometime.
I agree that we can wait a bit longer to complain, though; if you want to make an unused & redundant template, more power to you. --Karnesky (talk) 16:04, 1 November 2008 (UTC)
Then complain later. There's a million possible ways to do things. Bots is one of them. Replacing template code is another. I'm not interested in debating the specifics right now. If you have something constructive to say as far as format output is concerned, then go right ahead. You can continue to sing the oppose song if you want, but it's neither very productive, nor very relevant right now. Headbomb {ταλκκοντριβς – WP Physics} 18:02, 1 November 2008 (UTC)
(undent)Are you, or someone you know or associate with, gonna TfD a whole slew of templates when you're done, Sir or Madam?
Depending on how unicite is implemented, maybe, maybe not. If the solution calls for TfDing 3 of them then 3 of them will be TfD'd. If the solution involves replacing the code of the templates, then there won't be a need for TfD. I'm not a fortune teller, and it's pointless to argue about the specifics of incomplete things. Headbomb {ταλκκοντριβς – WP Physics} 03:34, 3 November 2008 (UTC)
Let me go straight to the heart of my concern.
You make a template. La de da. "Ignore it if you don't like it" you say. And more la de da. Oh. But then the people who think that deleting things is somehow contributing to the encyclopedia set upon every template in existence, aside from the One True template. TfD won't complain, 'cause the One True Template (allegedly) covers all bases. Mass deletions ensue. "Oh, it's OK" you say "Our template has so many options. Nothing is missing." The first problem is that you won't have all the options, but your bros will delete things not covered by your Swiss Army template. Oh. But then. Then the folks who say "Eeeew, those icky-poo Harvard thingies! We should standardize!" will start removing options from the One True Template. So much easier than TfD! Bye Bye harvard! Bye Bye LSA! Bye Bye... everything but footnotes. Conformity ensues.
And don't forget that Martians will also invade earth if unicite is ever used! Seriously, there's not one damned shred of evidence for any of the apocalyptic scenarios you just put forth. Now you say that "I won't have all the options". Tell me then, which options are missing? Because I've reviewed every templates in there and there are I think only two things missing right now. The first and the most important one missing is the support for the {{harvnb}} and similar templates, and the other is the support of COiNS. There might be some features from {{citation}} not yet implemented, but they will either make it in {{unicite}} or {{unicite}} simply won't deprecate {{citation}}. Headbomb {ταλκκοντριβς – WP Physics} 03:34, 3 November 2008 (UTC)
If what is being talked about here is the use of Template:Unicite, then I am adamantly opposed to using it personally. It has far too many parameters to deal with each time I want to make a simple citation. It would mean deleting the majority of fields as irrelevant upon each use. Either that, or people would leave the unused fields empty but in place, which will unnecessarily bulk up an article. Am I understanding correctly what is being discussed here? Personally, I find the current templates quite satisfactory and easy to use. {{unicite}} makes my head spin. —Mattisse (Talk) 01:19, 3 November 2008 (UTC)
HeadBomb said "let's work to maximize uniformity". Essentially, my concern is that this is a slow, stealth move to impose one and only one cite format as a no-other-option-allowed standard across Wikipedia. Ling.Nut(talk—WP:3IAR)02:07, 3 November 2008 (UTC)
Well if you can you any other citation template, you can use {{unicite}} just as easily. If you can write {{cite book |author=[[James Carville]] |title=How to Build your Life |year=1969 |publisher=Kettle Publishing |location=San Jose, CA |isbn=1-2345-8765-x}}, then you can just as easily type {{unicite |author=[[James Carville]] |title=How to Build your Life |year=1969 |publisher=Kettle Publishing |location=San Jose, CA |isbn=1-2345-8765-x}}. If you can write {{cite web |title=Sid Meier's Pirate – A Review |author=Matt Brody |url=http://www.gamerbrody.com/SMReview |year=2002}}, then you can just as easily write {{unicite|title=Sid Meier's Pirate – A Review |author=Matt Brody |url=http://www.gamerbrody.com/SMReview |year=2002}}. Documentation is very very far from being complete or in final form, so don't pay much attention to that. Headbomb {ταλκκοντριβς – WP Physics} 03:34, 3 November 2008 (UTC)
Ling, this hostility is unwarranted and unhelpful. You can add me to the list of Headbomb's supporters, but no one is trying to foist this upon other editors. The idea is simply to remove redundancies. The complaints about being too cumbersome, et al, and how the different elements would interact are being addressed. There's no point in getting up in arms. I for one would look forward to using the template in the articles I edit; no one is forcing you to do anything. So perhaps you can vent your frustration elsewhere; you're not helping, and you're most certainly hurting the discussion. Der Wohltemperierte Fuchs (talk)03:49, 3 November 2008 (UTC)
It is not even required that any template be used in any of the guidelines. I take this to mean that maximum flexibility is valued in this regard. I used to dislike the Harvard, but lately I have seen its usefulness in specific situations and in certain types of articles. I hope our goal keep our options and and encourage flexibility. —Mattisse (Talk) 03:58, 3 November 2008 (UTC)
Templates are extremely useful for linking the in-test cites to the full references on the bottom of the page. The option to simply not use templates, while real, is a disadvantage in this respect.
As for all other replies... yawn. I will have the tiny, tiny pleasure of being able to be the one saying "I told you so" within a year. Not a pleasure, though, not really. Ling.Nut(talk—WP:3IAR)06:04, 3 November 2008 (UTC)
Replace {{unicite}} with a complex template mapping most forms back into the {{citation}} engine. That way, Headbomb could still use it, but the formatting would look reasonable, and if someone wants to do something weird, it can still be done. (I noticed his ISBN link is broken, also.) Most of the specific modifications he's made mean that people using it would have to change their formats in order to map into this format. — Arthur Rubin(talk)18:54, 5 November 2008 (UTC)
There's a couple of misconceptions in there. No one would have to change "their" format to this one, that would be automatic, and all the inputs would be covered. There would be no transition period. Now as far as mapping the old template to {{citation}} goes, what you'd have to do is to make {{citation}} into something like {{unicite}}. Well I've built {{unicite}}, and now we just have to work out the kinks of it. We're nearly there, and if people could simply comment on the output above, we could move on and fix the problem of non-uniform outputs in all the various citation templates. And the ISBN link isn't broken, it's just a crap ISBN that's given, so you don't get anything. Try a valid ISBN and you'll get somewhere. Headbomb {ταλκκοντριβς – WP Physics} 01:40, 6 November 2008 (UTC)
They would have to change their format if they wanted to mix-and-match different template and manual citations. If this {{unicite}} replaced {{citation}} and all {{cite XXX}} templates (and you have already singled out some that you don't intend to replace & others have been vocal that they don't want any replaced), you'd "only" have to change the formatting of manually-entered references. Unfortunately, I see no way for a bot to do that. This is why adhering to a pre-existing format more methodically may be a good idea. {{citation/core}} already does some of what {{unicite}} does. Because there is an active parallel effort to begin to use that as a backend to the {{cite XXX}} templates, I don't know what it lacks that you'd need for {{unicite}}, but I would imagine that it could be amended & you can transform {{unicite}} into a more meta-template, that let the popular {{citation/core}} do the formatting. --Karnesky (talk) 15:00, 6 November 2008 (UTC)
(outdent) this discussion is bizarre but -- as I see it -- for different reasons. I can well imagine why some people might prefer the plethora of {cite xyz}s, and I can see the advantages of a unified template. But I don't see why they can't have the cake and eat it too. That is, the various {cite xyz}s can be wrappers/redirects to a meta template like unicite or citation/core, and still continue to be available for those who prefer individual {cite xyz}s. Whats wrong with having both? Is there any reason why {cite xyz}s have to be deprecated? I think not. The output would be the same, so who cares what editors type in wikitext?! -- Fullstop (talk) 00:01, 8 November 2008 (UTC)
It would be if it {{unicite}} didn't have intentional differences from all of the (cite xyz)s. There would be some small system overhead if due to the additional template renditions. but that seems mininal. The difference between pages=5 and pages=p. 5, which unicite seems to have lost, can probably best be dealt with by an additional translation template, and there are probably some other adjustments that may need to be made. — Arthur Rubin(talk)02:32, 8 November 2008 (UTC)
Resolved
--Ludwigs2 02:37, 10 October 2008 (UTC)
(or hell, might as well rename all the decades the same way). — CharlotteWebb 14:28, 15 October 2008 (UTC)
--NE2 07:01, 27 October 2008 (UTC)
Implement |dots=no, so {{unicite}} can be used in sentences.
