Wikipedia talk:Manual of Style

See also
Wikipedia talk:Writing better articles
Wikipedia talk:Article titles
Wikipedia talk:Quotations
Wikipedia talk:Manual of Style (dates and numbers)
Wikipedia talk:Manual of Style/quotation and punctuation

Use of the article before the name of a ship

A sizable number of Wikipedia articles omit the "the" before the name of a ship, and in many cases usage is inconsistent, RMS Titanic is an example. Entries about navy ships tend to forego the use of the article frequently (military jargon?). The Little, Brown Handbook (ninth edition, 2004, page 343, ISBN 0-321-10350-5) indicates that the article is used before ships ("the Lusitania"), Melville left us a description of "the Pequod", and "Sink Bismarck" just does not sound right. Shouldn't we use the article before ships in Wikipedia? Ekem (talk) 03:10, 30 June 2009 (UTC)

Doesn't it depend on whether the article is part of the registered name of the ship or vessel? — Cheers, JackLee ^–talk– 10:05, 30 June 2009 (UTC)

I'm confused myself, but at least I think it's rare to keep an article after Her Majesty's Ship (H.M.S.), His Majesty's Canadian Ship (HMCS), Royal Mail Ship (R.M.S.), United States Ship (U.S.S.), etc. Thus, Raise the Titanic! but H.M.S. Pinafore. The Player's cigarette box is famous for the incorrect inscription on the Royal Navy sailor's cap, which reads "Hero" and not "HMS Hero" or "The Hero". On the other hand, inscriptions on a ship's stern usually read "Hero/Bristol" and not "The Hero/Bristol". If you're not near a dock, look at just about any Tintin story. —— Shakescene (talk) 21:53, 30 June 2009 (UTC)

:-D I seem to recall a ship called the Kanchenjunga... — Cheers, JackLee ^–talk– 09:02, 1 July 2009 (UTC)

As to the names of American Navy ships, I can tell you that there doesn't appear to be consistancy as to the inclusion of 'the' when referring to a ship. Navy ships are often referred to just by name, without stating 'USS', but I've heard some sailors (and ex-sailors) say "the Midway" while others just say "Midway". Personally, I prefer to not use 'the', I think it personifies a ship more. After all, you wouldn't refer to your girlfriend as "the Jennifer" . . . or would you? OLEF641 (talk) 09:52, 8 July 2009 (UTC)

I agree. I'm quite sure there isn't any consistent usage. I think if one is stating the official name of the ship, then one should try and find out whether the definite article is part of the official name. However, in other references to the ship, I think it is acceptable to either leave out the The or retain it, depending on what suits the sentence best. Here's a twist, though – what if the definite article is in another language, e.g., what if the ship is named La Traviata? Should it be referred to "the La Traviata" or "the Traviata"? Hopefully this problem won't happen often. — Cheers, JackLee ^–talk– 19:47, 8 July 2009 (UTC)

Hello, again. Found this in the Wikipedia article "Ship prefix":

"Note that while calling a US ship "the USS Flattop" may make grammatical sense, the preliminary article "the" is discouraged by nearly all style guides, and the U.S. Navy. The U.S. Navy uses ship names without article, except for USS The Sullivans, named for the five Sullivan brothers, all lost at sea during World War II. Its British equivalent ("the HMS Flattop") is also discouraged, since "the Her Majesty's Ship" would be grammatically incorrect."

I agree that there are times that use of an article makes for less awkward phrasing, c.f. "Raise the Titanic!" above.

As for doubled articles, here in Los Angeles, we have a famous landmark usually referred to as "The La Brea Tar Pits". For those of you who don't read Spanish, this is literally "The The Tar Tar Pits" -- say it rhythmically with a kick at the end and you get a great conga lyric, but I digress ;-) OLEF641 (talk) 00:47, 11 July 2009 (UTC)

I am trying to summarize what may have been said: 1. There is no article before the name of a ship (xxx) when it is grammatically incorrect (example: "HMS xxx", never "the HMS xxx"), 2. It seems to be customary to omit the article before the name of ship of the US Navy at least in official use (I agree with OLEF642 that sailors use the article, i.e. "I served on the Lexington"), thus "USS xxx" may be preferable over "the USS xxx". 3. Otherwise it appears that the article is generally used, thus "the Santa Maria", "the Pequod", "the Titanic", etc. The article is, of course, always included when part of the name. Is this correct? Ekem (talk) 03:12, 20 July 2009 (UTC)

I generally omit the definite article when referring to a ship by name, with the exception of when there is a qualifier before it (ex: "The Japanese signed the official surrender document on the battleshipMissouri..." but "Prince of Wales sank after having been torpedoed several times..."). The way I see it is the ships are given names; you wouldn't say "the Jeff went to the grocery store" (and if you do, you sound like a pretentious idiot, but I digress). That's just my 2 cents. Parsecboy (talk) 23:02, 24 July 2009 (UTC)

The comment by Parsecboy sums up my view as well. I previously added a request for comments here to the WT:SHIPS page. Sswonk (talk) 23:17, 24 July 2009 (UTC)

Parsec took the works right out of my mouth. —Ed (Talk • Say no to drama) 03:15, 25 July 2009 (UTC)

Yep; The Parsecboy is correct ;) Ian Toll's Six Frigates is an excellent book but he uses 'the' before every ship name which needless to say drives The Brad insane. --Brad (talk) 12:32, 25 July 2009 (UTC)

According to the [U.S. Navy Style Guide] under "ship names," "Do not use 'the' in front of a ship's name: 'USS San Jose,' not 'the USS San Jose.' " Darkfrog24 (talk) 13:44, 25 July 2009 (UTC)

Another source, The Guardian (UK) Style Guide, uses the phrase "mariners shun the definite article" when talking about ships. An observation I personally might add is that the confusion may stem from the concept of ships as structures, as with "the Empire State Building" or "the Brooklyn Bridge". This use of the definite article is different because the structure name is in the form adjective-noun, building or bridge being the noun. Ships, to me, are not unlike thoroughbreds in that the name is a proper name like "Secretariat" or "Man o' War" (!) although the ship name has often had "the" added by writers in the past because of the confusion with buildings. Therefor, I would say that the above summation by Ekem is wrong on the third point, it should be "the article is generally not used" with the PDF I'm linking above providing a further explanation (under the "Military tendency" heading). Sswonk (talk) 14:56, 25 July 2009 (UTC)

I think a global rule on the use of the definite article would be a mistake. For instance, I would never say "I got seasick a once while riding James." when I meant "I got seasick once while riding the James." FWIW, in day-to-day operations, the only time I don't use "the" before my ship's name is on the radio, for example i.e. "Suez Pilots, this is Fredericksburg," but "The Fredericksburg was a deathtrap." and "I'm so glad we scrapped the Fredericksburg." Examples on both sides go back at least as far as the Argo. Cheers. Haus^Talk 04:12, 28 July 2009 (UTC)

There are strong examples for the use of the article and it will be hard to ignore Melville, Conrad, O'Brian or the New York Times (i.e. [1]). This is a nice observation of the dual use, though, and I concur (personal observation) the article is omitted on the ship radio, yet when talking about a boating experience the article tends to be used. Checking on cruise ships, companies refer to their ships without article (at least the two lines I looked at), but people would say "we went on the xxx" when talking about their cruise ship. So, is there a distinction between a "mariner/operational use" and a "literary/general use" - I am struggling with these terms but throw them out here to help us move forward - ? Ekem (talk) 13:33, 29 July 2009 (UTC)

Certainly it seems that when the ship is personified or being portrayed as an active agent (as in, for example, when it is the ship herself that is figuratively making a radio call), omission of the article is much more common than in other situations. Powers ^T 14:50, 29 July 2009 (UTC)

All very good points. One of my motivations to make the suggestion above, "the article is generally not used", was that "the" isn't used in a lot of the articles (this can be dangerous i.e. Article (grammar) vs. Article (publishing)) in WP:SHIPS that are FAs, see USS Constitution and SS Kroonland. Another good example might be Vasa (ship) where "the" is used sparingly (once) when talking about the ship but multiple times when talking about books, a museum, in the map and so on. So if a standard isn't spelled out properly I would fear having to chase down edits to these and other articles where the well meaning editor decides all of the mentions of the ship need to have a definite article. Sswonk (talk) 15:09, 29 July 2009 (UTC)

Are you saying here, it does not matter what may be the correct answer as we moved already into the "no article" version?Ekem (talk) 01:46, 31 July 2009 (UTC)

No, that wasn't me saying it doesn't matter. I wrote about FAs under the scope of the WP:SHIPS project and also the very good and careful eyes of many of its members. What I meant to convey there was that these articles have passed our highest form of vetting and stand as good examples. There are also the examples of the two published style guides cited and the comments I and other editors provided above. The problem is popular usage, which sometimes represents a different standard than what is correct. This happens with subjunctive (also see) mood verbs: "I wish I were going to the park" is correct for formal writing but "I wish I was going to the park" though incorrect is often found in popular usage. Judging by Google hits, "was" is more common by a wide margin: searching the exact string "I wish I were" produces 3.6+ million hits while "I wish I was" produces 16.1+ million hits. The same might be true here. So I would absolutely not say "the article is generally used"; in spite of the usage in novels (not formal writing, possibly in character etc.) and the New York Times (anecdotal examples), the other examples show a strong preference for the proper name style among mariners and people here who write about ships. Presenting both versions with explanation in this style guide might be possible, but ultimately pointless, as I don't think we are going to be able to say either form is truly correct or even "generally used". Sswonk (talk) 05:03, 2 August 2009 (UTC)

I respect people who are writing here immensely, but -just on their own- they are not reference points for style. I would think that reference points are literature, popular use, style books, and major newspapers (this includes the New York Times - the Times also writes about "the USS Ronald Reagan" - and the Times' use of the article has been consistent over time and (print)space, not "anecdotal"). It appears to me that the omission of the article is seen primarily in writings by mariners and in some recent mariner literature. Ekem (talk) 01:54, 3 August 2009 (UTC)

To clarify, I used the word "anecdotal" to describe the use of random example articles to show usage in the Times as opposed to use of an entry in the Times official style book, if such an entry has existed at any point in time. Of course I did the same thing with the example FAs, it is just a distinction of the source of the information that I was making. Sswonk (talk) 13:13, 3 August 2009 (UTC)

Diacritics - Use if unsourced?

I know the diacritic thing has been done to death, but let me pose this question:

Should diacritics be allowed if the word/name with diacritics in question is never used in English media?

This is an ongoing issue with the hockey article I edit. There are a couple of die-hards who use the 'ignore all rules' protocol to constantly revert all changes so that all Czech, Swedish, Slovak, Latvian, etc. names have diacritics regardless of popular usage or even any usage at all. --Львівске (talk) 21:09, 18 July 2009 (UTC)

The MoS is clear on this issue—see Wikipedia:Naming conventions (use English), specifically:

• "Use the most commonly used English version of the name of the subject as the title of the article, as you would find it in verifiable reliable sources"
• "Names not originally in a Latin alphabet, as with Greek, Chinese or Russian, must be transliterated into characters generally intelligible to literate speakers of English."

Seems cut-and-dried to me, but I'm also aware that people enjoy introducing nationalism into this debate as seems to be the case from reading the Talk page of Talk:Sandis Ozoliņš. --Laser brain (talk) 21:17, 18 July 2009 (UTC)

Yeah, it seemed pretty cut and dry to me and I made my case on WT:Hockey but the user, DJSasso, just watches every player and reverts any diacritic changes regardless of the rules, citing WP:IAR, WP:BOLD, etc.

Sandis Ozolinsh is a good example...though a user recently reverted it back to the Latvian language. How how about a guy like Jaromir Jagr? His name, "Jagr" has been spelled as such his entire, well documented, career. Why should Wikipedia be the only source in the world using diacritics on his name? How about Peter Statsny? Why should his surname be spelled differently than his sons, because he was born in Slovakia and they the US?

In keeping with Latvians, even the Dinamo Riga (their top team) website (english version) keeps diacritics out,link, yet the wiki page and roster insists on using them.

I'm not against diacritics. They have their place (see: Häagen-Dazs, Brüno) when they have common use. But is there no recourse or solution to this? Or just endless edit wars of those who follow the rules vs. nationalists?--Львівске (talk) 21:47, 18 July 2009 (UTC)

I don't really know what to tell you about the hockey project. My understanding was that they had developed a consensus to use diacritics, but you are making it sound like it is one editor. Which is accurate? I don't happen to agree with them, but I'm not really motivated to do battle about it. It does seem a bit odd when you explain it they way you've presented it. --Laser brain (talk) 02:43, 19 July 2009 (UTC)

I am just reverting to the consensus the hockey project has come to. If you have an issue with the situation by all means get the consensus to change. More than just me told you that the hockey project has come to a consensus on how the naming works so don't go saying I watch every page and just readd them, I also remove them on the pages that the hockey project has deemed they should be removed on. And I must admit I find it funny you would imply I am a nationalist since I do not come from nor am I descended from any country that uses them. I am about as English you can get. Also there have been basically zero edit wars on this subject in about a year and a half until you started arguing the issue. -Djsasso (talk) 03:02, 19 July 2009 (UTC)

I didn't imply you were a nationalist, that was about the Latvian editors. You certainly seem to defend their cause, though. As far as consensus goes, that doesn't seem to be the case as I've seen it. As GoodDay described the situation to me, it was more of a "hostile takeover" to the point where one can't keep up with the edits to keep them without, as these editors have taken ownership of the language on the articles in question. Regardless, I don't see how the consensus of a handful of people on the hockey WP overrules WP:BIO and WP:MOS basic style and form. Common use trumps the selective use of editors pushing an agenda.--Львівске (talk) 03:23, 19 July 2009 (UTC)

Hockey isn't actually the only sport that uses them. The problem is that all across this wiki are some projects that use them and some projects that don't use them. I personally believe using them still complies with "Use English". I don't think adding them stops the word from being English. I do however find removing them to be a misspelling and an insult to the individual. I don't believe that wikipedia should perpetuate the mistakes that other mediums make. GoodDay is probably the least reliable person to listen too, even editors that agree with his opinion that no diacritics should used say he gets a bit to insane on the issue. Basically the story you got was from the most extremist of the "removal" side of the debate. There was a relatively large number of people who agree on the current situation to stop the edit was, because the addition of them and removal of them mostly come from IP editors and people like GoodDay were waring with them up to 30 or 40 edits and the only way to get it to stop was to come to this compromise. The only time I actually add or remove them is when someone who knows the consensus blatantly ignores it. I have always been of the opinion that people should use the ENGVAR version of dealing with them, "use what was originally there", so if you come to a page and they are there leave them...if you come to a page that they aren't there then don't add them. -Djsasso (talk) 03:46, 19 July 2009 (UTC)

Anit-diacritics extremist, me? Yep. Un-reliable? that's for each to decide. The WP:HOCKEY compromise? a joke (concerning the Quebec articles & NHL player's birthplaces). GoodDay (talk) 18:15, 19 July 2009 (UTC)

To get back to the question. The consensus of the hockey project is to use diacritics on players own articles. Players names are present both in North American English media AND in international media. You would expect to find the name in diacritics on an European web site. The consensus of the hockey project on North American league articles is to NOT use diacritics by and large, because those articles are North American in scope and you see players' names in print and media commonly. The hockey project allows place-names with diacritics on league articles. I believe this is explained that the names don't have an English common usage and the various leagues just ignore them, so we have no reliable source for a translation. So, by and large, we are following the rules and we are putting forth a valid compromise. You can tell because no-one is perfectly placated. :-) Alaney2k (talk) 21:07, 20 July 2009 (UTC)

Excuse me, but what European (English-written) sources use diacritics? The IIHF doesn't, EuroHockey.net doesn't...Shouldn't we be following the NHL, IIHF, KHL, and other league/team/official sources on this? This isn't the Esperanto Wiki... --Львівске (talk) 22:26, 20 July 2009 (UTC)

 Nor is it Simple Wiki. —Krm500 ^{(Communicate!)} 22:45, 20 July 2009 (UTC)

This isn't going to get solved here, because it's clear that wider input is needed. Львівске, if you would like to see if there is a shift in consensus on this issue, I suggest opening an RFC at the hockey project. --Andy Walsh (talk) 22:40, 20 July 2009 (UTC)

The editors who put those diacritics in can answer the question. The main point, I think, is that in Europe it would not be uncommon to use diacritics, as we all know. Alaney2k (talk) 22:47, 20 July 2009 (UTC)

That's simply not true.--Львівске (talk) 22:55, 20 July 2009 (UTC)

We'll agree to disagree then. Ask the Swedish editors in wp:hockey. They're able to find links in English quite quickly when the debate rages... Alaney2k (talk) 23:17, 20 July 2009 (UTC)

He is correct, we quite regularly find references using diacritics in english when this debate comes up. -Djsasso (talk) 15:03, 21 July 2009 (UTC)

If it were up to me, all diacritics would be eliminated from Hockey related articles. Which of course, doesn't surprise anyone. GoodDay (talk) 22:57, 20 July 2009 (UTC)

You can't just impose your will, as I've learned. As I figure it, if it completely satisfies no-one, then it's just about the right compromise. Everyone has their opinion of what is the right way on things like this. I think this pops up in every wt:hockey archive. Anyway, the eds who put them in have found references. Maybe we could impose a policy of prove it. But I think the dio eds would prove it. Do we have to count up the references? Do we have to count up the paper media references? Alaney2k (talk) 23:17, 20 July 2009 (UTC)

The best I can hope for (these days), is that the dios remain off the NHL template roster's player names. GoodDay (talk) 23:21, 20 July 2009 (UTC)

Wait, let's get back to the original question. Is it really settled convention for the hockey project that diacritics be used no matter what? If there are no English-language sources that use the diacritics, how can we justifiably use them? Powers ^T 15:49, 21 July 2009 (UTC)

To answer the question, no, there is no settled convention. Right now it's just a "compromise" to allow player bios to have them (re: too hard to keep reverting the changes) but bar them from team pages. This discussion is ongoing at the WP, but it seems regardless a good proposal to follow logic and wiki rules, it's fought with people pushing their own opinion-based POV and the WP:IAR and WP:BOLD proposals.--Львівське (talk) 16:22, 30 July 2009 (UTC)

Punctuation: Quotation marks: “regular” vs. "straight"

I would like to re-open for deliberation the long-standing issue of regular (or “typographical”, or “curly”) quotes, versus the upright (or "typewriter", or "straight") quotes.

The issue has a long history. Apparently it originated in an “omnibus bill” of Archive 3, where it didn’t get much of attention because people were more bothered with British vs. American location of punctuation, and attracted by Hawaii. The real discussion started only in archives 18 and 19, where no consensus has been reached and therefore the recommendation of which quotes ought to be preferred had to have been removed (although it wasn’t). In later years the discussion has been revisited many times: see archives 94, 100, 103, 104, 108). So why am I beating the dead horse then and pester the community about this question once again? Well, it just so happens that as time goes by, the arguments in favor of regular quotes become stronger, while the arguments in favor of typewriter quotes fade, so by the intermediate value theorem there’s bound to be such moment in time when we’ll change the policy regarding this issue. So the purpose of this discussion is to find out whether such momement is already at hand.

In order to save the time and effort of many people who are interested in this discussion, I’ll try to give my overview of the past discussions (the overview will probably be slightly biased, but then bias is sometimes even welcome).

Basically, there are two major camps of thought here:

• Pro-choice: people who believe that it is editor’s right to make a choice between the curly and straight quotes, and the official MoS ought not to declare the former as deprecated; and
• Pro-life: people who believe that those in the first camp have to get a life and stop revisiting this issue over and over and over again...

I’ll try to list the major arguments and counter-arguments for both sides, it will (hopefully) help to avoid the unnecessary repititions in the follow-up.

Pro-choice

N	Argument	Rebuttal
C1	Curly quotes look aesthetically more pleasing.	Depends on the platform, and in any case beauty is in the eye of the beholder. On Netscape 4.7 browser for example curlies look quite ugly.
C2	Curly quotes are the only typographically correct symbols to denote quotation; any printed book will serve as a proof of this fact, the Unicode standard strongly recommends them too.	Computer screens are different from printed material.
C3	Curly quotes look aesthetically more pleasing.	That’s C1 repeated again.
C4	Curly quotes allow for easier understanding of the material. After all Wikipedia must be for the benefit of the reader, not the editor.	This benefit is actually quite miniscule.
C5	Articles formatted with curly quotes look more respectable and professional.
C6	If browser compatibility is the concern, then it is possible to add a user preference to convert all curly quotes into regular ones on the fly when sending the page to a user with such an option turned on. It cannot work in the opposite direction though.
C7	There is no single reason to forbid the editors to use curly quotes if they’d like to.	Lots of reasons, see the Pro-life section.
C8	Curly quotes, or indeed any quotes which have different opening and closing glyph, are capable to delimit the quotation unambiguously from computer's standpoint. It means for example that a text reader for blind people will be able to understand “hello” and render it as a quotation, but not the "hello".

Pro-life

N	Argument	Rebuttal
L1	Curly quotes are not on the standard keyboard so they are difficult to type.	Wikipedia is for the benefit of reader, not the editor. Every single rule in MoS makes editors’ life more difficult while readers’ comprehension better. The curly quotes should not be exception. Besides, there are easy keystrokes on Mac, Linux, and some Windows platforms to produce such characters; if your computer is missing their support then you might want to reconfigure it.
L2	Legacy browsers may not recognize such quotes and render them as square boxes or worse.	Curly quotes pose no more challenge to the browser than already widespread symbols of m-dash, n-dash, extended Latin, Greek, etc. See also C6
L3	Curly quotes cause problems with search function.	This one is entirely made-up. All search engines strip down punctuation from their search strings anyways. Besides there’s no real reason one would want to search for a string with quotation marks in it... And no, let’s not discuss apostrophes here.
L4	Curly quotes present problems with in-browser search function.	People hardly ever search for quotation marks anyways. No I mean: really, do they? Also modern browsers are (or should be) capable of performing search which does not discriminate between curly and regular quotes.
L5	Straight quotes are a “long established consensus”, there is no real reason to change it.	Actually it was never a consensus, the issue was disputed over the years. As for the reasons, see C1-C8.
L6	I hate those curly things, I'm not going to tolerate them!!!	(Yes this was indeed brought up as an argument on several occasions). Luckily, Wikipedia is a community. Nobody expects a colorblind person to contribute pictures; nobody expects a non-native English speaker to produce a perfect prose; nobody expects a person unable to appreciate the beauty of professionally typeset text to produce such a text. Chill.
L7	Curlies might have been common in the old times, but nowadays straight quotes are perfectly acceptable.	They might be acceptable in a text which is designed for only a handful of readers: an e-mail, or a blog; however when the potential audience is large the text must meet a higher standard of quality, which includes the use of “correct” quotes. And even when something is widespread (0MG!!! (00!_ !_()L) does not necessarily mean we should use it.
L8	Curly quotes are difficult to type.	That's repetition of L1. Oh and incidentally, this is exactly what the «"» is good for: —"— to indicate repetition of the previous line.

Discussion

So let the discussion begin. I will add from myself the following: it appears that all the arguments in favor of curly quotes work best with better computers, better monitors, etc; at the same time most of arguments against the curlies emphasize problems with ancient computer systems. This is a crucial point: the monitors slowly upgrade their quality and are able to pack more and more pixels per square inch, while old computers slowly go out of use. It means the monitors will eventually reach the point when the quality of on-screen display will match that of the printed copy. At that point it will be already obvious that curly quotes are vastly superior; however due to continuity of the process the actual “switch” point when it becomes beneficial to use curlies will happen much earlier, maybe it happened already.

Oh and while we're at it, we might also touch the issue of implementing the hanging punctuation, i don't think it has ever been discussed here. ... stpasha » talk » 05:02, 21 July 2009 (UTC)

I think the bigger question is should we italicize quotes, i.e. "Hello" vs. "Hello". To me, the former is more aesthetically pleasing :). — ^{\`</sup>CRAZY`(lN)`SANE<sup>`/} (talk • contribs) 05:09, 21 July 2009 (UTC)

This is indeed a bigger question, not quite within the current topic. However it appears to me that we'd run into the problems once the quote spans several sentences or even paragraphs. Too many of italic text will defeat the entire purpose of italicizing. Maybe use color, like “Hello”? ... stpasha » talk » 05:24, 21 July 2009 (UTC)

Point taken, I would perhaps be in favor of using italicized quotes sparingly, in a quote of perhaps no more than one sentence. Also, songs, which are always placed in quotation marks, could be italicized. I'm not sure what I think about your color idea though, I think it would be too unprofessional-looking and messy. — ^{\`</sup>CRAZY`(lN)`SANE<sup>`/} (talk • contribs) 05:27, 21 July 2009 (UTC)

No on italic quotes. Italics are more difficult to read, and jarring to the eye. There's a reason that italicing quotes isn't standard practice. And songs are always in quote marks because they are short-form works or portions of long-form works, like poems, short stories, magazine articles and episodes of television series. Italics would imply that a single song is long-form like an album. oknazevad (talk) 07:55, 22 July 2009 (UTC)

No, please don't use color. It is harmful for visually impaired users, either those using text-to-speech browsers or those who, for example, simply have colorblindness or work in poor light environments. Try to keep the article as plain as possible, that always has seemed to be the WP way.

Of course use of color can be good (e.g. in images) but color should never be used as the sole basis of distinguishing information.

For similar reasons I prefer straight quotes as I know they work better over a broader range of browsers, even if my particular browser does quite a nice job of quotes. Ideally I think there would be recommendation to use a template for inline quotations; then all discussion could be hoist out of MoS into the template talk page, though (like with MOSNUM and {{convert}}) the two would tend to walk in lockstep.

Having not really bothered with this discussion page before, I now find myself less, not more confident in MoS. If it is always being changed, any article I write or revise will almost inevitably not conform to MoS, within a matter of days. That does not help MoS. The rule to me would simply be that of consistency: use straight quotes or curly quotes as you prefer, but use them consistently throughout the article.

BTW "minuscule" is so spelt (not "miniscule").

best wishes SimonTrew (talk) 07:21, 22 July 2009 (UTC)

I agree with Simon here, color is a poor choice to distinguish one type of text from another. I disagree with the spelling of miniscule vs minuscule, though. Both are acceptable spellings. See here: [2]oknazevad (talk) 07:47, 22 July 2009 (UTC)

Right now, raising the question of curly quotes is futile. Instead, people might usefully focus on the fact that the page is blocked for editing. A disgrace. With goodwill and focus, that problem could be solved. Until it is solved, why bring up a matter that is guaranteed to waste vast resources in time and attention, when in the unlikely event that consensus is achieved the page cannot even be edited to incorporate the changes? Not without calling on an admin, that is. Shame!

In any case, the arguments to and fro above, as stpasha presents them, are incomplete. Take two examples:

1. Searching within any current browser for curly quotes (or apostrophes, of which there is no mention) will find only the curly variant; searching for straight ones will find only the straight variant. This makes editing a real pain. The same would apply in many separate editing applications that some of us use. Having curly quotes that most users can't type in thwarts their searches within a browser, also. So much for looking after the needs of those who consult Wikipedia.

2. It is easy to find printed books that use not curly quotes (or "directed quotes", as they have been called) but quotes that lean to the right – the same for left and right.

Get the facts right, stpasha, rather than complicating things with cute repetitions in what purports to be a rational tabulation of the arguments. Or better, put your energy into addressing the bigger picture: the problems that perennially beset this page, and have now left it locked for weeks because of two or three editors' intransigence.

I'm inclined to stay away until that's sorted out, myself. I've had my share of futile discussion over MOS, in which glaring faults and inconsistencies have lingered for months without people so much as noticing, let alone maintaining quality with good housekeeping. If I do rejoin discussion here, I'll want to see some intelligent treatment of several other overarching issues, before we are at all ready for details such as stpasha raises yet again.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 06:02, 21 July 2009 (UTC)

Just because the page is blocked for editing doesn't mean that we can't or shouldn't discuss other things. Edits have been discussed and made during this time. Darkfrog24 (talk) 13:15, 21 July 2009 (UTC)

To take the part of Noetica's post that is strictly relevant to the curly/straight issue—that "the arguments are incomplete", with "two examples:

1. Searching within any current browser for curly quotes (or apostrophes, of which there is no mention) will find only the curly variant; searching for straight ones will find only the straight variant. This makes editing a real pain. The same would apply in many separate editing applications that some of us use. Having curly quotes that most users can't type in thwarts their searches within a browser, also. So much for looking after the needs of those who consult Wikipedia.

2. It is easy to find printed books that use not curly quotes (or "directed quotes", as they have been called) but quotes that lean to the right – the same for left and right."

I agree entirely. Tony (talk) 10:36, 21 July 2009 (UTC)

I believe that we should take aesthetics out of this discussion. Straight quotes look prettier to some people and curly quotes to others. Aesthetics has no logical weight on its own. If there were an overwhelming wave of people who felt one way or the other, then we would be right to take aesthetics into account despite this, but I don't think that's the case here.

Stpasha raises an excellent point that one day many of the compatibility arguments in favor of straight quotes will become obsolete. It is not my opinion that that day has come. Not everyone who reads the English Wikipedia lives in a country where newer computers are common. Wikipedia must serve those readers as well. Darkfrog24 (talk) 13:15, 21 July 2009 (UTC)

I agree, I missed that argument (I did read all the archives linked at the beginning of the post, although haven't found strength to re-read them second time when summarizing). If nobody minds I'll update the list to include it. And certainly the counter-argument against the in-browser search function are two-fold: first, it is nearly impossible to imagine a real-life situation where one would want to search for quotation marks (though apostrophes problems are pretty common). But then you'd have exactly the same problem if you'd try to search for "Gauss–Markov theorem" for example (note the n-dash). An intelligent in-browser search engine must take into account unicode equivalent classes when performing the search (so that ’=‘=′=', and “=”=″="=«=»=etc...), and also attempt to guess common word modifications using the dictionary (such as Canada=Canadian=etc; this problem gets much more complicated in other languages). The problem with quotes is of minor importance compared for example to the problem with dashes or apostrophes...

As for "straight quotes look pretier to some while curlies to others" -- that is certainly true. However it is quite an established fact in typography industry that in printed text curlies do look better (the fact that the majority of modern books use them serves as an indirect proof). The major difference between printed text and monitors is that the latter has less DPI. Which means that as techonology progresses, eventually DPI of the monitors will be sufficiently high that curlies will look unequivocally better. Of course that moment won't bang on our front door and say "I AM COME", at which point we'll hastily run up to our computers and fix all the 10+ million wikipedia articles in a jiff. Instead we have to recognize the fact that the moment is indeed coming and start working towards meeting it, before it's too late :)

And Darkfrog, I'm afraid we can't "leave aesthetics out of this" -- that's the basepoint of all arguments in favor of curlies. Aesthetics is indeed important, in fact the purpose of entire MoS is aesthetics (that is, a text which violates every single point of MoS will probably be still understandable only rather unpleasant to read). And the reason why we value aesthetics so much is because it is paramount to conveying the information to the reader. How many times has it been in the history of science that publications remained unnoticed because they were too vague or obscure? How many theorems and methods do not bear the name of their inventor simply because somebody else had to popularize them? ... stpasha » talk » 15:58, 21 July 2009 (UTC)

One thought that comes to my mind on this, is that we should account for the possibility that reader's expectations may have changed. While Stpashal is correct that printed material typically uses curly quotes, he's also correct that, until recently, computer monitors have largely not used them. With the increase in importance and prevalance of digital text, there are likely a great many readers who consider straight quotes to be the norm.

Also, as for the "proven better" arguememt, I don't believe such a claim can be made. The prevalance of curly quotes in one form, print, does not make them inherently superior. The arguememt could be made that the universal nature of straight quotes, that is to say they're the same symbol, regarless of on which side of the quote they appear, makes them a more useful and practical choice, and a simpler, easier to understand system that requires fewer resources. Indeed, that may very well be the reason they were selected in the early days of computing.

Technological advances have rendered these arguememt less compeling, but that goes back to the first point, that while no longer neccessary, the norm of straight quotes in modern digital text has become established in the meantime. oknazevad (talk) 19:13, 21 July 2009 (UTC)

I must correct you on one point, StPasha. The MoS is not about what is aesthetically pleasing but about what is correct. There are plenty of people who'd think that capitalizing words like "North," "Summer," and "West" would look better, but it is not proper to do so, so the MoS advises against it. When I say that we should take aesthetics out of the discussion of curly vs. straight quotes, I mean that we should look at what is right, not what is beautiful.

I agree wholeheartedly that the prevalence of curly quotes in print should not be taken as proof of their superiority over straight quotes in all media. There are any number of reasons why formal printed media prefer curly quotes. I do seem to recall hearing something about curly quotes being easier to track on a page, but even if I remember correctly, reading off a monitor is a different experience. With a monitor, the light source is/is behind the text and with a printed page it's behind the reader. (I do specifically recall hearing that fonts with bars are easier to read in print and fonts without them, such as Arial, are easier to read on screens.) Has any research been done to see whether there is some evidence of curly or straight quotes being literally easier on the eyes on a glowing screen? Darkfrog24 (talk) 21:10, 21 July 2009 (UTC)

Historic remark: in the days of pre-computer era typewriters were designed so that to have the least amount of keys possible. Each extra key would have meant additional complicated mechanics, and would increase the possibility of clashes (that is when 2 of the keys were pressed in a quick succession one of the strikers may not have been able to return to its position yet and they jam). It also means that typewriter's keyboard was designed in such a way to make keys that are frequently pressed in succession (such as s+h, t+h, etc) to be pretty far away. When computers came they adopted typewriters keyboards in order to economize on the cost of re-training the typists. There is a sufficient evidence for example that Dvorak keyboard layout would have been better to use, but it's already too hard to switch now. Anyways, that's why we're stuck with keyboards that have straight quotes on them. And yes, they do require fewer resources (which was an important point in the epoch of ASCII, but certainly not now).

Regarding the monitor vs. printed media. It is indeed true that many web-designers advocate for the use of sans-serif fonts for screen media. The reason is again the DPI: when output DPI is high, serifs serve as a kind of guideline, allowing the person to follow the line of text more easily. When the DPI is low however, serif marks become more of an obstruction, making it more difficult to recognize the glyph's shape. I would hazard a guess that again, as technology progresses, we'll see more and more serif fonts on the web until one day they become prevalent.

As for the “proof”, I'd really like to see one myself. I mean alright, there is a LaTEX guide (LATEX is used for creating both PDFs and printed documents, maybe with more emphasis on the latter) which says that "straight" quotes must not be used without giving any references as to why is it so (well, Donald Knuth is an authority). Manuals for web-design also stress the importance of using curlies (for example here, or here). ... stpasha » talk » 00:28, 22 July 2009 (UTC)

[Outdent] As I predicted. Yet another tedious iteration of discussion we are not ready for. And as always when this topic comes up, failure to adduce evidence of how users really interact with Wikipedia, and failure to deal with issues that have long been on the table.

Browsers have a search facility for a reason. You may assert that users don't need to search for quote marks displayed by their browsers. But assertion is one thing; evidence another.

Confront this long-established fact too, for a change: Wikipedia's own search facility treats curly quotes and straight quotes differently. Go on: actually investigate, instead of theorising on empty. Enter “Hole saw” and see what you get; then enter "Hole saw" and see what you get.

Contrived a sophistical argument that you imagine will dismiss that hard reality yet? OK, now try searching on Cayley's theorem, followed by Cayley’s theorem. Then think. Think hard.

The ground assumptions behind these blinkered tinkerings cry out for attention. Meanwhile, to Darkfrog: May we have a progress report? I mean, on your continuing efforts to overcome the current block on MOS, brought on by your actions several weeks ago?

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 22:26, 21 July 2009 (UTC)

It's good to encourage people to get their facts straight. If you look at the page history, Noetica, you will see that the MoS was blocked because of an edit war in which I did not participate. Darkfrog24 (talk) 00:56, 22 July 2009 (UTC)

Yes Darkfrog, it is indeed good for us all to get facts straight. I would encourage people to look at edits on and around 30 May 2009 in WP:MOS, to see who, by several non-consensual edits and reversions, introduced instability in the quotations guideline. I said, with all caution, "brought on by your actions". Whatever technical excuse you may pretend to find, I'm sure others would still like an answer to my question, trimmed to its essentials: "May we have a progress report? I mean, on your continuing efforts to overcome the current block on MOS [...]?" You cannot deny that you were centrally involved, except by transparent evasive manoeuvres.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 03:11, 22 July 2009 (UTC)

Very well then. No you may not. It is not my or any other editor's responsibility to report to you or to anyone else on Wikipedia. Nor is it necessary; the entire discussion is available on this page and in the archives if you want a look at it or join in. Judging by the fact that you have directed your request at me and not at any of the other people who have participated in said discussion, not even the ones who, unlike myself, were actually involved in the conflict that directly precipitated the current blocking, I must interpret your request as a personal attack on myself. Please stop now. Darkfrog24 (talk) 04:25, 22 July 2009 (UTC)

Thank you for clarifying your attitude, Darkfrog. Let me clarify mine in return. I am not interested in attacking you, nor have I done so. I asked you to explain something; and you have refused to do so. I accept that as your choice. If you don't want to account for your actions and inactions, fine. You are under no compulsion. You are not responsible, to me or anyone else. Very well.

Nevertheless, I identify your well-documented actions on and after 30 May 2009 as a major factor leading to the present impasse at MOS; and I am surprised that you show no interest in doing anything about it. You are entitled not to do anything about it; and I am entitled to be surprised at that attitude. If you say that others are responsible for the impasse, I hope you will join me in asking what they are doing about it, since the impasse is a far more pressing and immediate problem than this re-stirring of an old pot. I note that you too, below, are re-hashing yet again the same tired arguments that we have been through before. Let me say quite clearly: you are entitled to do so, even if I think it is a complete waste of everyone's time. Good luck!

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 05:20, 22 July 2009 (UTC)

I didn't have to ask them. The matter was discussed on this page weeks ago. It's in the archives. Darkfrog24 (talk) 12:53, 22 July 2009 (UTC)

Please explain, Darkfrog. I said: "I hope you will join me in asking what they are doing about it." Presumably prompted by that, you said: "I didn't have to ask them. The matter was discussed on this page weeks ago. It's in the archives."

¿Qué? I am interested in what people (you, and the others involved) are doing now, to fix the problem with MOS. It is locked for editing. How's the program for fixing that coming along? It is mystifying: to refer to the archives for a current problem, yet to rehearse again and again these tired old discussions of a subordinate issue, repeating afresh all the follies of the past that are themselves recorded in the archives! Since you are determined not to do anything about the present and continuing results of your disruption of seven weeks ago, I'll not persist. I'll just wait for those responsible to fix the problem they have brought on.

Dwell on what lesser matter you will. But don't dismiss my reasonable and weighty question with inconsistencies and irrelevancies, as if I had done something damaging to our work at MOS, or wasted time here.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 00:33, 23 July 2009 (UTC)

Whoah! That's a really cool example. Now you probably have noticed that there is a page on Wikipedia called «“hole saw”» (which redirects to Drill Bit), so that when you enter «“Hole saw”» in the browser it somehow converts capital H into small h and makes the match. There is also a different article in Wikipedia called «Hole saw», so that when you enter «"Hole saw"» into the search string the quotation marks get stripped and the match is performed. Now if you think about it a little, you would probably come to the conclusion that curly quotation marks are actually the ones compatible with search function, while straight quotes are not. Simply because you can search for curly quotes, whereas straight quotes get removed from the search string.

Now regarding the «Cayley's theorem». (I wonder why you keep bringing in apostrophes here? maybe you secretly like them (: ). It is true that Wikipedia's own search engine cannot treat ’ properly. Well, Google search does that pretty well though... If you really want to deprecate the straight apostrophes and promote "curly" ones, then there are 2 options: (1) fix the Wikimedia search engine (hard but not impossible), (2) create redirect pages such as Cayley’s theorem => Cayley's theorem (quite easy with a bot actually). ... stpasha » talk » 00:28, 22 July 2009 (UTC)

That is an interesting historical note, StPasha. But we shouldn't assume that just because the original purpose of a rule has phased out that it no longer serves any purpose at all. Back in the typewriter days, straight quotes served the purpose of keeping keyboards small, but they've developed other purposes since then. The question is whether or not their benefits, such as avoiding problems with temperamental search engines etc., outweigh their disadvantages right now. Darkfrog24 (talk) 00:56, 22 July 2009 (UTC)

I just tried the following exercise: “Increase the font size in your browser to the largest possible”. Curlies look much better. In fact i even tried to switch to the Times New Roman font — and it looks better at large scale too! (best part about serif fonts at large magnifications is how they handle italics; in fact Arial font italics is barely noticeable in large font size, for some reason). Well, then of course i also reduced the font size in my browser below the Normal setting. And certainly enough, at small scale serif fonts look horribly, and curly quotes are indistinguishable from straight ones. Well, so I guess it all actually depends on what default font size your browser is using, as well as monitor’s resolution.

I also think there could be a compromiss, only it's harder to implement than merely editing the MoS. We could change the Wikipedia engine so that there is a new user preference: whether or not to convert curly quotes to straight ones. By default this option can even be set to “convert”, so that a regular person would see the text with straight quotes only. However articles would internally be stored with curly quotes, so that for those people who use large font sizes (visually challenged people, or simply those who like to sit far away from the monitor), or who'd want to make a print copy of an article, it could be send in the unmodified form. ... stpasha » talk » 01:53, 22 July 2009 (UTC)

Does anyone actually have the curly quotes on their keyboard? Who really has the constitution to use them or figure out how to type them? I bet if you query 100 random editors, fewer that 1 of them would respond that they like to make a habit of "producing" curly quotes. We can never recommend them, because that would be introducing an unacceptable level of complexity for editors. We can't remove the recommendation altogether, because editors will see them and either: 1) Recognize them and come here to see if they're allowed (unlikely), or 2) Not know what the hell they are or how to reproduce them if they want to improve or expand the article (likely). Bad idea, sorry. --Andy Walsh (talk) 03:49, 22 July 2009 (UTC)

Utility is certainly an issue. But we don't have m dashes on our keyboards either, and the MoS advocates their use where appropriate. The matter is handled by a list of special characters below the editing window. Darkfrog24 (talk) 04:32, 22 July 2009 (UTC)

• What kind of keyboard has no em dash? Tony (talk) 06:44, 22 July 2009 (UTC)

aha - now i understand an enigmatic remark you made in my direction a few months ago! my (major brand uk-style) keyboard has no dashes - just a hyphen. it's clearly not unusual for keyboards to lack dashes, and not everyone knows the code for them. Sssoul (talk) 13:54, 22 July 2009 (UTC)

But it depends on the operating system too: while no keyboard using the major operating systems has either en or em dash morphologically speaking, they are usually available with simple combinations.

• Mac: opt–hyphen, op-shift-hyphen.
• Windows full keyboard: cntrl-(minus sign), cntrl-shift-(minus sign). [Minus sign is very top-right, alphanumeric pad.]
• Windows lapdog: you're stuck.

Um nope - when I type ctrl+numpad- in the edit window, it zooms the page to 20%. ctrl+shift+numpad- does nothing. (Vista, full keyboard, Opera). Also, if you choose to turn off the silly editing buttons the characters below become static (needing cut'n'paste) rather than insertion links. dramatic (talk) 17:53, 2 August 2009 (UTC)

Otherwise, as Darkfrog says, use the easy-to-locate edit tools below the edit-window; or make an Auto-Hot-Key shortcut, which is stunningly easy and effective. Or get a Mac. Tony (talk) 14:07, 22 July 2009 (UTC)

• • Ah have a whole type case full a d!ngbats that I throw at de screen whenever!

✁ ✂ ✃ ✄ ☎ ✆ ✇ ✈ ✉ ☛ ☞ ✌ ✍ ✎ ✏

✐ ✑ ✒ ✓ ✔ ✕ ✖ ✗ ✘ ✙ ✚ ✛ ✜ ✝ ✞ ✟ ✠ ✡ ✢ ✣ ✤ ✥ ✦ ✧ ★ ✩ ✪

Heck, ah am my own dingbat!Ah just hurls myself into de computer monitor when I feels like it! --Goodmorningworld (talk) 07:32, 22 July 2009 (UTC) (duH)

My (theoretically UK layout) keyboard has no em dash, nor en dash; but that is no great problem, since I can write — or –. Laptop keyboards typically cut down on the keys, in particular the numeric keypad, which makes it very fiddly to type Unicode numbers with Alt+number. (In Windows.) Similarly it does not have directed quotes on the keyboard. Similarly, US keyboards tend not to have a £ sign. My keyboard does not mark a € sign (AltGr + 4) although it works anyway. It should be remembered that, yes, these can generally all be had in some way (e.g. in Windows at worst using charmap to grab the characters) but can be very fiddly if there are lots of characters that are not on your keyboard: with quotes it is especially fiddly since the openers and closers are different so one needs to jump through hoops to copy both (e.g. to Notepad) then only select one of the two to copy into the article.

By the way I imagine somewhere there is a debate on what # is called, the US tends to call it a pound sign, which confuses UK readers for whom a pound sign is £ (# is a hash).

But in any case, it is better to do this with markup, I think.. You simply mark it up (with a template or HTML tag) as "this is a quote" and the way that the server (WP) or client (browser) decides to display that, is rightly out of your hands. That way a user can choose to display it how they prefer. Although there are templates for quotes, I am not sure that there are for inline quotes? I shall be pleased to be pointed to them if I am wrong.

Similar issues arise with translated articles, or translated phrases, whether to use italic or not, or put the English in italics and the original language in straight, or vice versa, and so on. The {{lang}} template is silent on the matter and articles vary; all one can say, I think, is use the template and then (one hopes) if a prevailing style is adopted the template will be changed to fit. This happens for example with WP:MOSNUM and {{convert}}, which is far more complicated than doing quotes, yet is usually pretty much in line with MoS, and if not then one or the other gets fixed, and if it is too big a fix, MoS is ignored as being unreasonable or unwieldy, but with arguments reached by consensus (they are all sensible people in the MOSNUM and convert talk pages).

Best wishes SimonTrew (talk) 07:49, 22 July 2009 (UTC)

Indeed, that's a wonderful idea: we could use either <q>lorem</q> html markup or we could use a template: {{q|ipsum}}. Apparently that template even existed once but was deleted :( And for some reason Wikimedia foundation is unwilling to support Q html tag. ... stpasha » talk » 08:15, 22 July 2009 (UTC)

# a.k.a. "the marijuana sign" <g><g><g>--Goodmorningworld (talk) 09:34, 22 July 2009 (UTC)

My keyboard doesn't have an em dash, just a hyphen and an underscore. I have to type out the code or go to Word if I want an em dash. I believe that straight are best for now, but there is some precedent for advocating non-keyboard-ready characters when it is correct to do so. "They're not on the keyboard" is not, by itself, a deal-breaking argument against curly quotes. Darkfrog24 (talk) 12:37, 22 July 2009 (UTC)

Darkfrog wrote "The matter is handled by a list of special characters below the editing window". This list is entirely useless for similar-looking characters, because the names of the characters are not given. Even for characters that reasonably distinct, it would still be useful to be provided the Unicode character name. A person just beginning to care about typography will have trouble telling the difference between - and –. Few editors can tell the difference between “, ”, and ″ as they appear in Internet Explorer 7 below the edit window. --Jc3s5h (talk) 14:14, 22 July 2009 (UTC)

Hm, good point Jc3. Do you think we need to make the list more accessible to neophytes? Darkfrog24 (talk) 16:15, 22 July 2009 (UTC)

Yes, the list should be made more accessible to everyone (perhaps giving the Unicode name of the symbol during mouse-over). Furthermore, this should be finished before entertaining the idea of curly quotes. --Jc3s5h (talk) 20:22, 22 July 2009 (UTC)

I consider these to be two separate issues, but on a practical level, since the time for curly quotes is so far off, it would be better to deal with the unicode strip first. Darkfrog24 (talk) 20:49, 22 July 2009 (UTC)

<rant>Why on Earth did Unicode decree that U+0022 is “neutral (vertical), used as opening or closing quotation mark; preferred characters in English for paired quotation marks are U+201C LEFT DOUBLE QUOTATION MARK & U+201D RIGHT DOUBLE QUOTATION MARK”? Had it not, fonts could use right-leaning quotes (as many of them used to do in the past decades), or even a “-like glyph at the beginning of words and a ”-like glyph at their end (as many fonts do for Arabic letters with different contextual forms), there wouldn't be separate “ and ” characters, and we wouldn't even be discussing this. Everyone could choose a font using their favourite glyphs.</rant>

Personally I'm pro-choice about this. Curly quotes are not harder to type or search for than, for example, the minus sign, but then we don't suggest to use the hyphen-minus instead because it's easier to search. BTW, some other Wikipedias preferentially use the quotes which are used in print («like this» in Italian, « like this » in French, „like this“ in German), and the sky hasn't fallen on them. Also, I can't imagine a situation in which one would search for quotation marks themselves (rather than using them to delimit a string). OTOH, I agree that what looks best in print isn't always what looks best on screens. (The master example is $\Rightarrow \,\!$; if the horizontal lines were perfectly parallel, an optical illusion would make them appear to converge rightwards, so TeX, which was originally designed with print in mind, draws them slightly converging leftwards to compensate; but this looks awful on screen.) But this is in the eye of the beholder; for one, I like the look of “” more than that of "" on my screen.

So I think the best solution would just be “use whichever you want, but be consistent in each article”, which is what we do for most style choices. (But if there's consensus against this, I can continue using straight quotes in articles just fine. I have more important things to worry about.)

As for the character palette below the edit box, it looks just fine to me, but if it doesn't for some users, as Jc3s5h points out, we should use a larger type for it. --A. di M. – 2009 Great Wikipedia Dramaout 13:12, 23 July 2009 (UTC)

[Outdent] And I’m back. So, the issue has been discussed over the past few weeks and there appears to be no real argument in favor of recommending the straight quotes. Well, at least there is no argument which would survive a simple exercise of replacing the words “curly quotes” with “n-dash” and “straight quotes” with “hyphen”. Examples:

Curly quotes are difficult to type	N-dashes are difficult to type
Curly quotes are not in the standard ASCII encoding and thus old computers may have difficulties with rendering them.	N-dashes are not in the standard ASCII encoding and thus old computers may have difficulties with rendering them.
People will have difficulties with searching for curly quotes and apostrophes, example: Cramer’s rule	People will have difficulties with searching for n-dashes and m-dashes, example: Cramér–Rao bound
It became standard on the web to use straight quotes instead of curlies.	It became standard on the web to use hyphens in place of n-dashes.
Curly quotes have no real utility: people are perfectly capable of interpreting "…" as opening/closing quotation pair. (Re: they do have utility, “ denotes opening quote, and ” denotes closing quote. And people are capable of recognizing teh for the, it doesn’t mean we shouldn’t watch our grammar).	N-dashes have no real utility: people are perfectly capable of interpreting Cramér-Rao as a disjunctive dash. (Re: n-dashes do have utility: – denotes a disjunctive dash, while - denotes a hyphen. And people are capable of recognizing teh for the, this doesn’t mean we shouldn’t watch our grammar).
etc…

All this is an attempt to prove that curly quotes merit exactly the same treatment as currently n-dashes do (and I bow before those brave people who shouldered the difficult task of persuading the community that correct dashes have to be respected).

Now the good news. I found this nice program http://ilyabirman.ru/english/typography-layout/ which installs new keyboard layout that makes entering all common typography glyphs a breeze. This program is available for Windows and Mac platforms; as for the Linux you can use the standard xmodmap utility to modify the key bindings on system level. Cheers :-) ... stpasha » talk » 15:51, 31 July 2009 (UTC)

In theory, I'm strongly in favor of using curly quotes whenever possible; they are simply correct and straight quotes are simply incorrect. We should find a way to do it. However, changing the MOS to recommend that editors type curly quotes into the edit box is not acceptable in my opinion. There are far too many technical issues, as thoroughly outlined above. The comparison to en dashes is correct in theory but completely wrong in practice. The fact is, en dashes are very very rarely used. The majority of articles do not contain them; the vast majority contain less than, let's say, three. Quotation marks and apostrophes, on the other hand, can be found in almost every paragraph. So the slight technical inconvenience of using en dashes is overruled by correctness, because the use cases where actual problems are caused are so unlikely. Conversely, the slight technical inconvenience of using curly quotes completely overrules correctness, because the use cases where actual problems are caused are legion. This is "the free encyclopedia that anyone can edit", accessibility and usefulness overrule all other concerns. Forcing users to use difficult technology is being disrespectful to their needs. Furthermore, it's completely unrealistic to expect this to gain any traction; we're at three million articles, for crying out loud. Converting every article (manually or botwise) would be far too drastic and messy.

However, as I said, I am a curly quotes advocate. What I propose is a MediaWiki extension (I'm assuming a dozen PHP libraries exist for this purpose) that can be controlled (and is, by default, disabled) in the user preferences. Turn it on when rendering a print version. That's a decent compromise that helps promote curly quotes without being incredibly unfriendly to our users.

There are steps to be made toward typographic zen, but we're just not there in 2009. We'll be there in 2020. Maybe 2015. But not now. —Werson (talk) 03:30, 2 August 2009 (UTC)

While I don't agree with the idea that straight quotes are incorrect or that the time for curly quotes has come, I find your idea that there would be no point to making a change of this kind equally flawed. So what if it would not be practical to go in and change every last article? Why not change the rule and say "Write new articles with [new way]. If you're editing an existing article for any reason, feel free to also change the [old way] to [new way]"? Then the change happens slowly over time. Darkfrog24 (talk) 04:53, 2 August 2009 (UTC)

Well, some changes to MoS are certainly desirable. For instance the {{cite ref}} template currently uses typographic quotes to enclose the article’s title. It would be easy for them to change to curly quotes (or at least to add an option quotes = curly|straight|none) but they don’t do that because MoS “discourages” curlies. ... stpasha » talk » 06:20, 2 August 2009 (UTC)

Arbitrary subsection break

Although I support the use of curly quotes in theory, they cannot be declared the norm without a technical solution. On the operating system used by the large majority of Wikipedians (most of whom have no understanding of the issue), the default rich-text editors insert characters #147 and #148 (IIRC) as curly quotes - this is Microsoft providing legacy support so that documents written in pre-unicode days still work in their software. Unfortunately, the code range 128 - 159 is declared void in Unicode (because if there is a 7-bit conversion these map to control code range 1-31). Internet Explorer faithfully renders any characters in this range according to the default code page, but Unicode-compliant browsers (i.e. most others) do not, displaying boxes or error marks. So, the Wikipedia software would need to immediately reencode such input as valid unicode. dramatic (talk) 18:04, 2 August 2009 (UTC)

Punctuation within a name

This is something I wanted to check about regarding a character article, MissingNo. The period at the end of its name is clearly a part of the character's actual name, as supported by printed material and the game it appears in. However one user noted it was being read as a full-stop, and should be omitted within the body of the article. So my questions are:

• Should it be omitted within the article body and written as just "MissingNo"
• And if so, should it be left as "MissingNo." for the first mention in the article's lead and/or image captions?

Thanks for any advice on this matter.--Kung Fu Man (talk) 01:17, 23 July 2009 (UTC)

If it's part of the character's name, it should be used at all occassions. Omitting it would constitute changing the character's name, which would be incorrect on accuracy and intelectual honesty. oknazevad (talk) 02:33, 23 July 2009 (UTC)

If it's not something ridiculous, then keep it. MoS: NAME doesn't mention a thing about punctuation, but keeping the period in "No." seems to be in keeping with the spirit. I'd reword to avoid full-stop ambiguity where necessary. Darkfrog24 (talk) 03:03, 23 July 2009 (UTC)

Without the period/full stop, the only way to read it is as "Missing No" (negative), when "Missing Number" must be at least one of the intended meanings. So there's more than just a stylistic reason to keep the stop (as opposed to commercial brands that insist on using ALL CAPITALS or all lower-case). And in the case of authors like e.e. cummings and anomalies like eBay and the iPod, we should (but apparently don't) keep their style instead of substituting Wikipedia's. —— Shakescene (talk) 08:27, 23 July 2009 (UTC)

You might want to read E. E. Cummings#Name and capitalization. --NE2 09:31, 23 July 2009 (UTC)

Yes, it means "missing number", so it needs a period at the end. --A. di M. – 2009 Great Wikipedia Dramaout 12:07, 23 July 2009 (UTC)

But No is a special case (Numero, French I think into English but perhaps other latinate languages also). By UK English WP rules you don't put a stop after No because it ends in O (it would, I guess be N'o to show the missing letters but no stop at the end) but in practice No is written thus, and stops seem rather optional. The difficulty arises, I think that it is not an English abbreviation, it is an abbreviation of a French word. A. di. M. is perhaps best to qualify this, considering the stops in the username (and his general intelligence and sensibility).

Best wishes SimonTrew (talk) 00:15, 26 July 2009 (UTC)

Yeah, in UK English there's no period when the abbreviation ends with the same letter as the full word (e.g. "Mr" for "Mister"), but in US English there is, and WP:ENGVAR says, "The exceptions are: ... proper names (the original spelling is used, for example United States Department of Defense and Australian Defence Force); ..." (Now you might argue about whether names of Pokémon species are proper names, but c'mon.) --A. di M. 10:16, 26 July 2009 (UTC)

(BTW the French word has an accent somewhere, "numero" comes from the Latin ablative: see Numero sign. --A. di M. 10:18, 26 July 2009 (UTC))

I suppose they're proper nouns. "Gandalf" and "USS Enterprise" are both proper nouns even though they're both fictional. Aside from that, judging solely by the video game screencap shown in the article, the source material seems to place a period after "No." Darkfrog24 (talk) 13:27, 26 July 2009 (UTC)

MissingNo. is an abbreviation, and it's standard (American) English to use a period (see R.E.M., E.T. the Extra-Terrestrial). So there's nothing wrong with it. If the period was just decoration (like Clerks. it would be preferable to ignore it. —Werson (talk) 14:44, 2 August 2009 (UTC)

Formal Name of an Office

The "titles of people" section states that "the formal name of an office is treated as a proper noun." This rule seems too vague. My preference would be for it to be eliminated altogether, but if it is retained, there should at least be some guidance as to what qualifies as an "office." Many pompous people consider their job title (e.g., "attorney") to be an "office" worthy of capitalization. —Preceding unsigned comment added by 163.231.6.87 (talk) 20:20, 23 July 2009 (UTC)

I am not going to quote right now, since it is early days and not worth getting 101 slightly different sources, but at least ib British English a cap is used as a singular position and without cap for the collective. e.g. the Government is the people ruling you badly, a government is any of many governments ruling you badly. And mutatis mutandis. In British English we would write Road-Sweeper or Rat-Catcher with caps or minuscule depending on context.

The classic example here is the City of London (from an American, and I have lost the book but can find it, about 1930 but not Thurber's style). You can be in the city without being in the City, but you cannot be in the City without being in the city.

Best wishes SimonTrew (talk) 00:04, 26 July 2009 (UTC)

Regarding the word "duology"

(Linking to this from numerous places)

There's some debate at Talk:List of film duologies regarding whether the nascent term "duology" should be used on Wikipedia. It refers to a two-part work of fiction; it's not listed in any established dictionary, but is widely used on the web. The issue seems to be one of brevity versus clarity. Here are a few of the places the term is in use:

• Duology is a redirect to Sequel
• wikt:duology
• List of film duologies
• The Hand of Thrawn duology, Category:The Hand of Thrawn duology
• Cygnus X-1 duology
• Template:The Waxwork Duology
• Template:The Terror Toons Duology

There was some prior discussion over this last August at Wikipedia_talk:Naming_conventions_(films)#Problems_with_film_series_titling_guideline. The consensus at that time appeared to be that film series should use "(film series)", and by analogy I presume that "(series)" or "(book series)" is appropriate for literature. That leaves open the question of the use of the term in the bodies of articles, and the use of it in the names of list articles like List of film duologies (should it be List of two-part film series?). What's the final verdict on "duology"? Dcoetzee 05:33, 28 July 2009 (UTC)

Well I hope the term "duology" is correct, as I've been using it professionally to refer to a pair of literary works on a common theme by the same author! I dislike the use of the term "series" to refer to only two works – in publishing, a "series" is four works or more. Etymologically, it should be "dilogy", but "dilogy" means a word or phrase which has two meanings: "dilogy" is not a dilogy, although it would be kind cute if it were… Physchim62 (talk) 08:31, 28 July 2009 (UTC)

Yes, the word duology is ugly; but so are most new words. And yes, it is not well-formed from Greek; but then, neither is television (first part Greek, second part Latin). And yes, dilogy is already taken (as well as "an ambiguity", as Physchim points out, it can mean "2. Repetition of a word or phrase, in the same context. In recent Dicts" (OED). Looks like it fills a niche that diptych does not fit into neatly. We can't recommend against it without also recommending something better in its place.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 09:28, 28 July 2009 (UTC)

Agree with Noetica ... except that I have no objection to Greek/Latin combos! Tony (talk) 11:25, 28 July 2009 (UTC)

Normally, I am fine with "duology" and "trilogy", but my problem is with the {{Film series}} template that goes beyond these: tetralogies, pentalogies, hexalogies, heptalogies, octologies, ennealogies, decalogies, and polylogies! I mean, come on. "Trilogy" is the most well-known of the bunch, and "duology" is known to a lesser extent, but the rest of them seem like an overly complicated way to be consistent with trilogy and duology. I think we should pursue a different naming convention -- something like "List of film series with two entries". —Erik (talk • contrib) 12:00, 28 July 2009 (UTC)

Perfect illustration of how the template mentality can go awry. Tony (talk) 14:29, 28 July 2009 (UTC)

Agreed. It seems that even the film world stops using number-specific terminology once they hit four films. As for "duology," I'm of a divided mind on the word itself, but "List of film series with two entries" seems quite unobjectionable. However, it also sounds as though not all film series that happen to have two entries are true duologies, just as not all film series that have three entries are true trilogies. Therefore, our real criterion should be what exactly it is that we're trying to describe. Darkfrog24 (talk) 17:04, 28 July 2009 (UTC)

When I skimmed the lists of film series with x entries, they seemed well-updated. If a film series gets one more film, the list of films is moved to the successive "list of film series" article. My real concern is for the article titles. "Duology" and "trilogy" can be somewhat misleading because it sounds like an intended setup, where it's not always the case. For example, American Psycho had a DTV sequel that really had very little to do with the first film (and actually completely missed the purpose of it). Using "List of film series with x entries" makes the issue more ambiguous since unlike the tetralogy/pentalogy/hexalogy names, it does not sound like a preconceived setup. —Erik (talk • contrib) 17:39, 28 July 2009 (UTC)

Leaving aside the quality of the articles, Wikipedia has a policy where neologisms should be avoided. As "duology" cannot be established in any dictionary, this alone should be enough for it not to be used, but as additionally there is already controversy as to whether "dilogy" should be used in its place, then there is no question something else should be used. Serious consideration should also be given as to whether pentalogy / hexalogy / etc should be used as these words do not appear in dictionaries. As a couple of other posters point out however, with the articles in question (as well-updated and meticluously put together as they might be) it isn't an issue, as they are not lists of true "trilogies", etc as they include works that do not follow a overall cohesive narrative arc, etc, so to my mind these should all be moved. One could argue that some of the entries on these lists do not even form true series, but that's probably an argument best left for another day.

I'm unsure what to suggest as an alternative for the word "duology", and they do get more clumsy as the numbers get higher. If in publishing three is a "trilogy" and four or more is a "series" (noting that four is not a "tetralogy"), this would therefore seem to be the appropriate convention to follow for films with more than three in a series. As, in the case of the film lists, this would be a simple movement even for the "trilogy" list as as we have established above, a lot of these do not form coherent trilogies. "List of film series with x entries" would seem to be the appropriate form as others mention above, even for two. Others can argue as to what counts as part of the series and what doesn't - I believe Star Wars is in under "ennealogies", which for me is two trilogies, or a series of 6 films.

I think that we just don't have a word for a series of two works (although i don't have a problem with "a series of two" myself). I don't think that it is up to us to invent one, and neither should we use "duology" until "they" put it in the dictionary. Robsinden (talk) 12:21, 5 August 2009 (UTC)

To satisfy my own curiosity, it would appear "Star Wars" has moved from "ennealogies" to "decalogies" and now back to "hexalogies". I wonder about the necessity of these lists! Robsinden (talk) 12:32, 5 August 2009 (UTC)

Guidance for bulleted lists

I recently removed bullets from many paragraphs in Write-in candidate (diff), because in those sections every paragraph was preceded by a bullet, which seemed pointless to me. However, it was soon reverted (diff), with the claim that the sections do not read easily using plain paragraphs.

Eons ago, the Manual of Style said, "If every paragraph in a section is bulleted, it is likely that none should be bulleted" (see, for example, [3]). Over time, the wording of this sentence was changed a bit, and apparently at some point a comment was added which I do not understand ("this is a critique of a hypothetical article - not guidance"). Eventually the sentence was removed in an edit that, ironically, turned the entire "bullets and numbered lists" section into a bulleted list (diff). No edit summary was used when this sentence was deleted, and the only discussion I can find in the talk page archives does not seem to explain why this sentence was removed (see Wikipedia talk:Manual of Style/Archive 93#Bullets and numbered lists).

I am looking for some guidance for situations like this. I do not understand why the addition of bullets before every paragraph in a section of an article can make it easier to read, and so I feel that they are unnecessary and should be removed. The paragraphs read just as well without the bullets as they do with the bullets. This is an encyclopedia, after all, not a PowerPoint presentation. Is it not true that "if every paragraph in a section is bulleted, it is likely that none should be bulleted"? What do the bullets contribute in a situation like this? —Bkell (talk) 18:01, 28 July 2009 (UTC)

As the editor who reverted, all I can say is that in the case of Write-in candidate, each paragraph is independent, and the paragraphs do not "flow" as a story. The paragraphs are intended to be read independently (because some candidates are more interesting than others). Therefore, I think it is easier to read the article with bullets. Dems on the move (talk)

I agree with Dems. These sections are collections of lists in paragraph form. Bullet points are not without application here. Whether we absolutely need to have the bullet points is another question, but they are not nearly as out of place as they would be in most articles. The real question is whether the sections should be written in list-paragraph form in the first place. I think it's easy to read, organizing the paragraphs by candidate, especially because there are so few of them. Darkfrog24 (talk) 19:08, 28 July 2009 (UTC)

Yes, I'd seen that disconnected, particulate nature of each para and thought that this is one of the unusual instances where bullets are probably OK. They are, at least, a signal to the reader not to expect the normal flow that is encountered in a WP section. Some editors would have framed it explicitly as a list, which would also be OK. If it were a FA nomination, the reviewers would complain if the bulleted sections were not balanced by the presence of more flowing information. Tony (talk) 07:55, 29 July 2009 (UTC)

Help with parens

Over at Expedition to the Barrier Peaks I'm doing an FAC, and it hasn't come up, but I'm wondering if I'm using parens correctly. Here's what it says:

He gave it 9/10 overall, but complained that some of the maps were printed on both sides of the same sheet, making them useless as a Dungeon Master's shield.[1] (A visual barrier that allows dice rolls and other activities to be conducted without the players knowing the outcome.)

Can I put a whole sentence inside parens? Should it go inside the first sentence? If it should, where should I put the ref, because it only supports the first sentence. Thanks. - Peregrine Fisher (talk) (contribs) 21:21, 29 July 2009 (UTC)

The sentence inside the parentheses is a fragment, so either it needs to go with the first sentence:

He gave it 9/10 overall, but complained that some of the maps were printed on both sides of the same sheet, making them useless as a Dungeon Master's shield[1] (a visual barrier that allows dice rolls and other activities to be conducted without the players knowing the outcome).

or it needs to be rewritten as a full sentence:

He gave it 9/10 overall, but complained that some of the maps were printed on both sides of the same sheet, making them useless as a Dungeon Master's shield.[1] (A Dungeon Master's shield is visual barrier that allows dice rolls and other activities to be conducted without the players knowing the outcome.)

The first option is probably better, since you don't have to repeat "Dungeon Master's shield". In both cases the reference should appear directly after "as a Dungeon Master's shield". Strad (talk) 23:27, 29 July 2009 (UTC)

Cool. Thanks. - Peregrine Fisher (talk) (contribs) 00:12, 30 July 2009 (UTC)

No dashes in category names? Hello?

Someone has launched in and made a major change. I don't think there was consensus for this, was there? I think it should be reverted until there is proper consensus. There's some reference to archives in the edit summary. Tony (talk) 12:22, 30 July 2009 (UTC)

I don't remember any discussion for this change. The change description mentions that this change was requested on July 14 and is in the archives. Archived dash sections from around that time include [4], [5], and [6]. None of them explicitly mention changing "file names of images" to "category names." Darkfrog24 (talk) 12:35, 30 July 2009 (UTC)

Wikipedia talk:Manual of Style/Archive 109#Hyphens in category names. DrKiernan (talk) 13:16, 30 July 2009 (UTC)

I undid the change. If consensus to make any change develops while the MOS page is still protected, please use the {{editprotected}} template to bring in an uninvolved admin to edit the MOS page. — Carl (CBM · talk) 13:23, 30 July 2009 (UTC)

So 1. a consensus did exist 2. but Vegaswikian should have requested administrative intervention rather than inputting the new phrasing personally. Okay. Darkfrog24 (talk) 15:03, 30 July 2009 (UTC)

Normally, if a discussion sits idle for so long that it is archived, I would take that as evidence that there was not a consensus for a change. But things are more difficult on fully-protected pages, because many editors will be unable to make changes they propose. One role of the editprotected template (beyond bringing in someone to make the change) is that the template itself serves as a proxy for the edit that cannot be directly made to the protected page. If there is consensus for the change, editors will not contest the editprotected tag. If there is not consensus, editors will contest it. This makes it much easier for an uninvolved admin to see whether there is consensus for the change. — Carl (CBM · talk) 15:09, 30 July 2009 (UTC)

I believe the discussion should be revisited before any action is taken. And can someone determine whether the use of punctuation in category names is dealt with in another style guide or policy? I seem to remember a doubling up. Tony (talk) 15:48, 30 July 2009 (UTC)

Category names in general avoid any characters that can not be directly entered from a common English language keyboard since redirects don't work on categories. There is, to my knowledge, nothing actually written in WP:CAT on this. However a significant majority of past discussions have supported this restriction. Vegaswikian (talk) 17:46, 30 July 2009 (UTC)

OK, So where do we go from here? Do I simply have to make another request to have the change made? Do I tag the change that had consensus in this discussion with the template? I read the template and the document that goes along with it is less then clear on this. Vegaswikian (talk) 17:29, 30 July 2009 (UTC)

I'm not going to participate further in this discussion as an admin or a participant, but my suggestion is to make a new post with the precise change you propose. Link to the previous discussion as well. Add the {{editprotected}} template with you comment. Then wait for either an admin to make the change or someone else to dispute the change and remove the editprotected tempate. I will see if I can clarify the documentation for the editprotected template to make it easier for people in the future. — Carl (CBM · talk) 20:58, 30 July 2009 (UTC)

ampersand in corporate names

The style book says:

"The ampersand (&) is a symbol representing the word and. In running prose, and should mainly be used instead as it is more formal. If it appears in the titles of businesses, works, or in a quotation, the use of an ampersand is justified."

OK, "justified." But is the ampersand preferable to "and" in the names of corporate entities? Is it conventional and thus to be used in the title of an article on such an entity? I'm starting a stub on the 19th-century architectural firm "Lanyon, Lynn & Lanyon," to which I'll need to link. Cynwolfe (talk) 16:44, 30 July 2009 (UTC)

Shouldn't it use the form that the company itself uses/used? --Auntof6 (talk) 18:01, 30 July 2009 (UTC)

Agreed. The only time you alter a company name is to remove ridiculous formatting conventions. If the company uses an ampersand, use the ampersand. If it uses and, use and. Strad (talk) 19:13, 30 July 2009 (UTC)

On the other hand, if the company, or that business as a whole, seems to use 'and' and '&' interchangeably, it may make sense to create a naming convention ("house style") for that field. For example, Trains magazine always uses the ampersand, even when the railroad company always uses 'and'; our longstanding naming convention is the opposite. --NE2 19:23, 30 July 2009 (UTC)

The common-sense principles above (that is, do as the corporation itself does) seem right to me for modern entities; however, the point about using the two interchangeably and the proposal to have a "house style" gets at my question better. My particular corporation is historical, long dead and gone; when we title the article "William Shakespeare," we're relying on our own conventions of orthography, since his name was spelled variously in his life. Printers in the 19th century and earlier used the ampersand willy-nilly for "and," so in many if not most historical instances, corporate in-house style, if it existed, would be difficult if not impossible to determine. (I also corrected an earlier typo in '19th-century' above.) Cynwolfe (talk) 21:16, 30 July 2009 (UTC)

Would WP: COMMONNAMES apply here? Darkfrog24 (talk) 23:15, 30 July 2009 (UTC)

Hm. Helpful in principle. But in part that's what I'm asking: my impression is that an ampersand is common and even conventional in corporate names, but I don't know what I'm basing that on. Cynwolfe (talk) 01:27, 31 July 2009 (UTC)

I would add that we should exempt logos and headers from the estimation of what is common and go with body text only. Many companies punctuate differently when going for visual effect. Darkfrog24 (talk) 02:28, 31 July 2009 (UTC)

¶ Although none of these should be the deciding factor, some technical considerations may be relevant:

1. Ampersands are usually harder to find and type on standard keyboards (it's shift-7 on my US Windows Vista one from Compaq), so used in the titles of articles they may make searches a little harder.
2. On the other side, ampersands remove some ambiguity from unfamiliar foreign conjunctions such as those in Moët et Chandon, Saône-et-Loire, Thurn und Taxis or Romeo y Julieta.
3. There may be some problem because in HTML, ampersands are used to introduce extra non-alphabetic characters such as comma, colon and ampersand itself.

As for corporate style, everyone in the Northern California refers to the local utility, Pacific Gas and Electric orally as "Pee-Gee-and-Ee", abbreviated in writing as "PG&E", "P.G.& E.", or occasionally "P.G. and E." But when covering a municipalization initiative in Berkeley in the early 1970's I found that the company's own press releases referred to it as "PGandE". However, I see that the present logo includes the ampersand prominently. —— Shakescene (talk) 04:19, 31 July 2009 (UTC)

Point 3 sounds sobering. Point 2 perplexes me: are you saying it would be OK and maybe even helpful to substitute an ampersand in, say, Saône-et-Loire? Et, y, and especially und would seem to qualify rather as familiar foreign conjunctions. But I think what's emerging is that there really is no strong pull toward conventional usage one way or the other when it comes to the ampersand for a corporate name. There is, however, an argument for avoiding an ampersand when possible even in these names. Yes or no? Cynwolfe (talk) 04:52, 31 July 2009 (UTC)

I'm not yet taking a definite stand one way or the other on any of these issues, just throwing out some points to consider. But your point is well taken: I must have been thinking more of the reverse situation, where the foreign entity most often uses an ampersand (or, to confuse things further, a plus-sign, +) and a reader might not know enough (especially with less-familiar languages like Finnish, Basque, Hebrew or Arabic) to substitute the correct conjunction. I wish that I could remember some good examples, but they escape my mind right now. This is less of a problem in Spanish, Portuguese and Italian where an ampersand would normally replace a single-letter conjunction (y, e or i) and would thus save little space. —— Shakescene (talk) 07:10, 31 July 2009 (UTC)

Change wording on when to use hyphens

Currently the policy includes this statement 'Dashes should never be used in the filenames of images (use hyphens instead).' I'm requesting that this be changed to 'Dashes should never be used in category names; use hyphens instead.' This request is based on the consensus in this archived discussion.

The proposal does two things. It removes a restriction from our MoS that is apparently in conflict the naming convention on commons for files. It adds an exception for issues that still exists from the software in how it supports category redirects. This proposal does not address an issue raised in the discussion on using spaces before or after a hyphen. Vegaswikian (talk) 21:35, 30 July 2009 (UTC)

Hyphens are not normally spaced—certainly in titles. Run past us again why dashes should never be used in either image filenames or in category names? I've never heard anything so illogical. Tony (talk) 13:42, 31 July 2009 (UTC)

There's a very good reason not to use dashes where they have to be parsed correctly by the software or produce the wrong output - they are extremely difficult to distinguish from hyphens in isolation, which makes names with dashes in the names considerably harder to link to in articles. For articles this is less problematic because we can create redirects from the hyphenated names, but this isn't available for filespace or catspace. It's an issue of simple utility over MoS purism. Both should be discouraged as a simple courtesy to that majority of the population which doesn't know or care about characters which aren't available on regular keyboards. Chris Cunningham (not at work) - talk 15:10, 31 July 2009 (UTC)

Tony, you've seriously never heard anything as ridiculous as a disagreement over punctuation? How long have you been on Wikipedia again? =) For the record, I agree with Vegas and Chris. Powers ^T 15:20, 31 July 2009 (UTC)

The proposal seems reasonable, an understandable concession to technological limitations. However, shouldn't the phrasing mention both file names of images and category names? Also, acknowledging that this change was properly discussed before it was implemented. Darkfrog24 (talk) 15:35, 31 July 2009 (UTC)

Chris says: "they have to be parsed correctly by the software or produce the wrong output - they are extremely difficult to distinguish from hyphens in isolation, which makes names with dashes in the names considerably harder to link to in articles". I don't understand a bit of it. If software can "parse" dashes in article titles, what is the problem with parsing them in category titles? In what respect are they "extremely difficult to distinguish from hyphens"? I've seen a developer debunk these arguments before, I'm sure. Tony (talk) 16:00, 31 July 2009 (UTC)

Most people cannot reliably distinguish between - and – in isolation (i.e. without having the other to compare to it). If I type Scottish Premier League 2008-09 then I am transparently taken to Scottish Premier League 2008–09 via a redirect page; as explained here, the same is not possible for redirects to the file or category namespaces. Chris Cunningham (not at work) - talk 16:46, 31 July 2009 (UTC)

My initial proposal was to add categories to images as the exception. A point was made that since there is no restriction on commons for files that we should not be more restrictive. If the change is made and images are left in as an exception, I don't think that most editors would be upset. Vegaswikian (talk) 22:36, 31 July 2009 (UTC)

The proposal is not consensual. It is made at a time when the page is locked. I believe that several skilled and experienced editors are not participating in discussions here, and that they will not return until the people responsible for the current absurd impasse have repaired their damage.

Nor has discussion in the archives yielded wide consensus for any such change. (The page was already disrupted, and avoided, when that discussion took place.) Therefore, even without weighing the supposed merits of the particular case, I oppose the proposal.

I call on Darkfrog, and any others he or she nominates as bringing about the present dire problem, to get on with fixing it. I see no reason for us to accept them as participants in this or any other discussion until they have done so.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 22:53, 31 July 2009 (UTC)

The fact that the page is locked over some other dispute is simply no reason not to make changes in other areas that have consensus. To shut down sensible work on the encyclopedia and its policies because of some bickering is simply unacceptable! Please contribute to productive work and changes! Vegaswikian (talk) 23:22, 31 July 2009 (UTC)

Darkfrog, the page remains locked because when, a few weeks ago, I tried to arrange for it to be unlocked, you stuck a knife into that move it received negative comment from you and others. Tony (talk) 02:54, 1 August 2009 (UTC)

Saying, "I don't have strong feelings about it either way" is sticking a knife in it? What are you talking about? Darkfrog24 (talk) 03:08, 1 August 2009 (UTC)

Agreed. The fact that the page is locked has nothing to do with this. The proposal should be discussed on its merits. With regard to whether the previous discussion was valid because other editors may or may not have been discouraged from participating by the page's protected status, isn't there a policy that says, " 'There's no consensus because I wasn't here' isn't a good argument against consensus"? Or was that only a line in "signs that you might be slipping into feelings of article ownership"? EDIT: Ah yes this is where I saw it.

Noetica, the page was locked over an edit war in which I did not participate. I had no more or less to do with it than anyone else who was not a direct participant. Kindly stop addressing these requests to me. Darkfrog24 (talk) 00:34, 1 August 2009 (UTC)

Vegaswikian writes: "The fact that the page is locked over some other dispute is simply no reason not to make changes in other areas that have consensus." I agree. But as I have pointed out, we do not have consensus for the proposed change. We cannot get consensus while experienced MOS-editing regulars are staying away from discussion because of the present stalement.

Darkfrog, I have suggested that you nominate those you think are responsible for the current mess, and that we hold them to account. You continue in your failure to do this, and to acknowledge your own well-documented role in destabilising the page (see your edits around 30 May 2009: two months ago, now). It is ridiculous to suggest that I claim any ownership here, and your attempt to appeal to a policy page to suggest any impropriety on my part is ill-focused and futile. I say only that the work of all editors is seriously impeded by the disruption in which you participated. Fix it, please. That hard work is overwhelmingly urgent. Discussion of other issues in the meantime is a waste of everyone's time.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 03:09, 1 August 2009 (UTC)

I do not mean to imply that you were claiming ownership for yourself, Noetica, but it seemed as if you were claiming it on other people's behalf. I meant only to show that last month's discussion about whether to change the phrasing is not invalidated by the absence of any specific Wikipedia editor.

The page was not protected because of a discussion; it was protected because of an edit war. You seem to feel that no improvements can be made to the MoS while it is protected, but the discussions on this page are evidence to the contrary.

Finger-pointing is improper. Please stop and please stop asking me to join in. Darkfrog24 (talk) 03:29, 1 August 2009 (UTC)

[Outdent] Darkfrog, no clear, wide, or resilient consensus was reached in the discussion you refer to. I do not make any claim about any specific editor's absence, then or now. I do say (yet again) that during the current disruption editors are staying away, just because it is so unpleasant to be here and because they can see no way to do useful work in this climate.

It remains mysterious why you do not acknowledge your part in disrupting our work, in the face of plain evidence. It is also mysterious why you are not pushing for a resolution to the impasse, even if you were not involved.

I am asking that you, and everyone, accept that we have larger work to do before we can proceed with details. I have been patient and restrained. So have others, whom we do not so far see joining in my call for action. Who, after all, would want to engage with the implacable obstructionism we have seen over the last two months?

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 04:13, 1 August 2009 (UTC)

I do not claim that last month's discussion was perfect, only that the absence of one or more specific people from that discussion is not sufficient to invalidate it (and that therefore Vegaswikian was not out of line in believing that consensus was sufficient). We should certainly discuss the matter further now that other editors want to weigh in.

I certainly did participate in a long and often heated discussion about Wikipedia's punctuation policies and the way they are treated in the MoS, but this discussion is not why the page is locked. I have not pushed for the page to become unlocked because I do not have strong feelings about the matter. I do not see the page's locked status as a serious problem, though I can respect the feelings and conclusions of those who do. If other users have not "joined in your call," then perhaps it is not because they are afraid of me but rather because they, too, do not see it as a serious problem. Darkfrog24 (talk) 04:27, 1 August 2009 (UTC)

No one's afraid of you, Darkfrog. People are, however, dismayed at your unwillingness to respect MOS and the work of its editors.

It is not a question of "the absence of one or more specific people". Two points (already made, above): There was no sound consensus anyway; and editors generally were staying away, and are still staying away, because of the dismal overwhelming problem with this page. Yes, as you now admit you "certainly did participate in a long and often heated discussion about Wikipedia's punctuation policies and the way they are treated in the MoS"; and your own earlier irresponsible editing was a major factor in fanning that conflagration. Take responsibility. Work towards a solution, please. As you say, you "do not have strong feelings about the matter". Interesting. You care about all manner of details, but you don't care that the day-to-day work of dedicated editors has been disrupted for weeks, with no end in site.

I urge editors not to tolerate this sort of contemptuous abuse of process.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 05:31, 1 August 2009 (UTC)

Wading into these turbulent waters, I believe the proposal is reasonable, for although it may not be fully grammatically correct to not use dashes in file and category names, it is a reasonable variation to accomodate Wiki's technical limtations. And file names should still be included, for although the limitations may not exist at commons, it is virtually impossible for every file to be on commons due to the fair use nature of corporate logos, which can't be hosted on common, iinm.

As for whether this is a valid consensus, the lack of participation by some editors cannot be held against it, as participation in the project is not mandatory. If some have choosen not to participate, then consensus must be based on those that do choose to participate. There's no permanent membership or quorom to fulfill here. If one is absent from the discussion, then that is that. oknazevad (talk) 05:13, 1 August 2009 (UTC)

Oknazedad, it is not a simple choice not to participate in particular discussions. People are understandably repelled by the obstructionism of the last few weeks. This is not a climate in which reasoned collegial discussion can proceed. Those who brought about the present difficulties do not budge. Why would any editor want to confront such stonewalling? They stay away, and their absence means that we cannot go about "business as usual". This is indeed a crisis.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 05:25, 1 August 2009 (UTC)

No. The only obstructionism here is from you. Numerous editors have been attempting to have reasoned, collegial discussions about a variety of topics. Yet you keep badgering one contributor in all discussions on this page, even when they are completely unrelated to the original dispute. Frankly, I find your behaviour here obnoxious and more detrimental to collegial discussion than any past incidents. Please stop. oknazevad (talk) 21:54, 1 August 2009 (UTC)

Good to see you expressing your view robustly, Oknazevad. Unfortunately, history shows that you are wrong. I mean the histories of WP:MOS, of this talkpage, and of Darkfrog's and my contributions. The evidence shows that work on MOS has been irresponsibly interrupted (it still is!), that Darkfrog was centrally involved, and that I was not. The evidence also plainly shows that the perpetrators are doing nothing to undo this damage. If editors whose work is disrupted cannot robustly hold those enemies of collegiality to account without being branded "obnoxious" and uncollegial, we are in even worse shape than I say above. No wonder several editors specialising in MOS stay silent and stay away; and no wonder these disruptive elements have their way – again and again. I again call on editors to suspend any development work on MOS guidelines until the present crisis is resolved.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 09:15, 2 August 2009 (UTC)

Some of us are actually trying to get work done here. There are plenty of people who are glad and willing to do just that. Past contributions don't guarantee future rights to determine future outcomes, so just because some past contributors have stopped contributing does NOT mean that work must stop ! Your so-called "crisis" only exists in your mind. oknazevad (talk) 14:32, 2 August 2009 (UTC)

Once more, Oknazevad, it is good to see your bold opinions aired. But once more, strident assertions are not enough. We'd need evidence and reasoned argument. When a page that is important for the whole project is disabled for weeks on end, with no prospect of relief, and the editors who caused that do nothing towards a solution, we have a crisis. When a straggling few dwell on mere details here, distracting attention from the central problem, we have a crisis. When those who remind them of this sorry state of affairs are themselves accused, we have a crisis. No wonder editors stay away.

I don't say that work must stop. We might reasonably answer queries, offer interpretations, and the like. But don't imagine that there can be serious development of the page, while the crisis quite manifestly continues. Of course I can't stop people ignoring the plain facts; but I can draw attention to them so that people don't grow entirely oblivious.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 16:29, 2 August 2009 (UTC)

Noetica, why don't you start a new section? You certainly seem to feel that this issue is important enough to merit one. That way, it would be more likely to get the attention that you feel it deserves and the rest of the issues under discussion can proceed with fewer interruptions. Darkfrog24 (talk) 17:18, 2 August 2009 (UTC)

Comment I have not been actively watching this discussion, so I may say things that have been said before. Here are my views: dashes for file names are unnecessary and would make things difficult; in the edit screen, there is no difference between the appearance of a hyphen and an en dash, and the difference between the hyphen / en dash and the em dash (in the edit screen) is barely noticeable. For category names, I agree it would be nice for en dashes, but only if there was a way to make a "category redirect" (not sure if these exist or technically feasible). Dabomb87 (talk) 17:36, 1 August 2009 (UTC)

Vegaswikian, perhaps it would be best to leave the edit request tag off until after we confirm that we've reached a consensus. To that effect...

Support. This change of phrasing seems to be a reasonable concession to technological limitations. Darkfrog24 (talk) 23:08, 1 August 2009 (UTC)

That would be fine if we can keep the discussion on track. Consensus was already reached in the archived discussion. Right now the only issues are over the inclusion of two additional words and the dispute over some individuals who apparently think that they can take the ball and go home shutting down changes here. If consensus is difficult to see, it is only because of the side issues that don't have to do with the actual proposed content changes. I agree that I'm not normally here for discussions, but this is not what I expected. Vegaswikian (talk) 00:26, 2 August 2009 (UTC)

With regard to the two words, I for one am satisfied with the reasons you gave for why they are not included in the new phrasing. With regard to the previous consensus—which I believe does count as consensus—while it is not invalidated by any given editor's absence, I believe that it is right and proper for an editor to create a new discussion if he or she has serious concerns. I don't agree with Tony's conclusion, but he's gone about it in the right way. Darkfrog24 (talk) 00:34, 2 August 2009 (UTC)

Oppose removing dashes from category titles. I agree that typographic style is not important for file names since they don't appear in the article, they're mostly only seen by editors, they're nongrammatical, and are expected to be saved to hard drives, etc., where technical limitations are more significant. But category titles actually appear in mainspace, and readers interact with them. They should be stylistically correct. Categories are edited infrequently, and generally by experienced users who use that drop-down box script, whatever it's called. Dashes don't cause enough problems to forbid them. —Werson (talk) 03:52, 2 August 2009 (UTC)

Actually most of the category names have hyphens and this has worked without issues. It is only lately that some requests for changing of the hyphen have become more common. Vegaswikian (talk) 19:31, 2 August 2009 (UTC)

Obviously the hyphen won't cause "issues", but if it's incorrect it should be changed. —Werson (talk) 23:44, 2 August 2009 (UTC)

Splitting off punctuation disputes?

Currently more than half the talk page is dedicated to a single, ongoing (and seemingly endless) debate over American/British/logical punctuation. Then further down the page we have another immortal behemoth of a discussion over quotation mark glyphs. Can we please put these in a subpage (WT:MOS/Punctuation, maybe) so that the rest of the discussions have some room to breathe? Strad (talk) 22:21, 30 July 2009 (UTC)

Oppose. Punctuation is part of the MoS, so the MoS talk page is the place to discuss punctuation for Wikipedia articles. Also section 8, Punctuation, ties with section 16, Grammar, for largest subsection of the MoS, so it's not all that surprising that punctuation discussions take up a big portion of the talk page. Darkfrog24 (talk) 23:22, 30 July 2009 (UTC)

Oppose. Neutral I don't necessarily have the same views as the others that have posted here, who are all intelligent and sensible. It needs to be kept in MOSTALK as per Darkfrog. SimonTrew (talk) 23:38, 30 July 2009 (UTC)

Now I think about it, I tend to more look at MOSNUM (and {{convert}}, which are siamese twins) so if you have MOSNUM I can't see why you can't have MOSPUNC. If it is large then split it off. SimonTrew (talk) 23:44, 30 July 2009 (UTC)

I agree with you there, Trew: If the punctuation portion of the MoS were its own separate page, then it would make sense for punctuation discussions to take place on a separate talk page. However, whether or not punctuation should be split off from the main MoS is another question. My take is that a separate punctuation page is not necessary at this time. Darkfrog24 (talk) 00:05, 31 July 2009 (UTC)

Agree, but MOSNUM is still part of MOS — just it has its own chat page so it doesn't clutter MOS talk. It is still part of the MOS (which of course comes under WP:COMMON anyway) but it means that discussions can happen off the main page and not waste others' time.

Best wishes SimonTrew (talk) 11:08, 31 July 2009 (UTC)

For full disclosure, I dislike Wikipedia's punctuation style. But I follow it because that is the style. Consistency is most important. I am more than happy to argue whether to use this quote or that dash or whatever but consistency is what we want, I think. This is not the place to argue the details, just wanted to disclose that. SimonTrew (talk) 11:21, 31 July 2009 (UTC)

Yes, MOSNUM is part of the MoS project, but this [7] and this [8] are two separate pages, so it makes more sense that numbers would have a separate talk page than that punctuation would. Darkfrog24 (talk) 11:55, 31 July 2009 (UTC)

Slight lean towards support: Even though Wikipedia talk:MOSNUM stands alone (like Wikipedia talk:MOSICON, etc.) because it's attached to the stand-alone MOS page for dates and numbers (WP:MOSNUM), that Talk Page itself had to be split in order to allow other questions room to breathe during The Great Date Auto-Formatting War of 2008. I don't think the punctuation debates have reached that level (they're certainly far more civil), but should they grow so long that they crowd out everything else, there is a precedent. On the other hand, punctuation (unlike spelling) is harder to split cleanly from other questions of grammar and style.

What I do think we might come to agree on is that when the time comes to archive all or part of the punctuation debates, they should have a separate, clearly-marked archive of their own (rather than being buried with unrelated questions in number 110 or 111 — if I'm keeping correct count), which would make retrieval far easier for everyone. —— Shakescene (talk) 21:44, 31 July 2009 (UTC)

Oppose, based on the substance of the proposal. But even before we look at that substance, we are not ready to have this discussion.

The solution to the present disruption is for Darkfrog, and any others she or he nominates as involved, to repair the damage they have brought about. The solution is not to have the main MOS page split as a further consequence of their mischief.

Those perpetrators have no place in a discussion of this sort, until they have done that work. Why should we others, and the Wikipedia community as a whole, suffer because of their irresponsible behaviour, and their obdurate refusal to focus on what is obviously their most urgent task?

We others, who want to get on with plain housekeeping and incremental improvement of MOS, are justified if we urge them away from discussions like this. Let them go back and fix things first. Then we can accept them as participants in new discussions.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 23:13, 31 July 2009 (UTC)

Oppose. Tony (talk) 05:06, 1 August 2009 (UTC)

Oppose—Past experience has shown that moving discussions off to subpages is not very helpful. The subpage gets ignored by all but a few editors who are really into the issue and who come back with a "consensus" which really counts for nothing. Unless the page itself is split, let's not split the discussion. JIMp _talk·cont 08:33, 1 August 2009 (UTC)

Oppose Reduces visibility of discussions when we actually need more opinions. Dabomb87 (talk) 17:31, 1 August 2009 (UTC)

Oppose nothing warrants splitting punctuations to it's specific subpage. Numbers and Dates are huge sections, with a million different cases to cover. Punctuation is not nearly as big as them, nor so clearly distinguishable from the rest of the MoS. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 14:55, 3 August 2009 (UTC)

Another dash question

What should be used for Lehigh-Buffalo Terminal Railway? The name comes from it being the Lehigh Valley Railroad's terminal railway in Buffalo. --NE2 15:58, 1 August 2009 (UTC)

Same thing for Wabash-Hannibal Bridge Company (the Wabash Railroad's bridge at Hannibal). --NE2 16:01, 1 August 2009 (UTC)

"Lehigh – Buffalo Terminal Railway", if the route is from Lehigh (Valley) to Buffalo, since an en dash is used for direction, motion, route. But I'm wrong to space the en dash if "Buffalo Terminal" or "Buffalo Terminal Railway" are not the second unit; that is, if it's the Terminal Railway for the Lehigh–Buffalo route. If one or both of the units linked by the en dash has an internal space, the en dash itself is spaced on both sides.

"Wabash–Hannibal Bridge Company": this is a company specifically to build a bridge between Wabash and Hannibal? If so, unspaced, since both units are single words. — Preceding unsigned comment added by Tony1 (talk • contribs)

I explained how the names were formed. The first means "terminal railway in Buffalo for the Lehigh Valley Railroad" and the second "bridge company at Hannibal for the Wabash Railroad" (which owned the Wabash Bridge). --NE2 17:02, 1 August 2009 (UTC)

OK, so my suggestion was correct: "Buffalo Terminal", not "Buffalo", is the second element; therefore, a spaced en dash is required, since there's a space in at least one of the elements. This is a good example of why we need to use spaced and unspaced en dashes functionally. Same for the Wabash example. Tony (talk) 03:41, 3 August 2009 (UTC)

Poll on Ireland article names

Tiny tiny images

An example of a thumbnail image that is too large if the size isn't fixed

Why is it that most FACs I review now have microscopic images that are utterly useless unless you double-click on them? Is there scurrilous guidance here that is making nominators ruin this already-weak part of WP (criticised in an external report written up in the most recent Signpost, I think). It seems weird. Have our readers got Internet connections that are so snail-paced we have to go backwards to the 20th century? And, BTW, who wants to see tiny-wrap skyscraper-tall captions with one-to-three words in most lines? They look ridiculous. See here, for example. Tony (talk) 12:17, 3 August 2009 (UTC)

A map of the Norse-Gaelic zone, with region names as they are described in the sources of the period; Gallgaidelaib is the word Galloway (see text), Airir Gaidel is modern Argyll, Cenn Tire is Kintyre, Innse Gall is the Hebrides, Na Renna is Wigtownshire, and Mann is the Isle of Man

As an aside, I agree with Tony that the example was ridiculously small, and have fixed it in the Donnchadh, Earl of Carrick article. On the left is original the example again, so that you can see what it was like before it was fixed. Eubulides (talk) 23:13, 3 August 2009 (UTC)

Good heavens, is it possible for you to write a criticism without sounding apoplectic? Anyway, the article you linked looks fine to me. Maybe you can adjust your thumbnail size in preferences? Powers ^T 12:38, 3 August 2009 (UTC)

Tony, there seems to be something in the MoS that makes editors think only thumbnails are allowed, except for the lead image. Certain editors go around removing image sizes, citing the MoS. With a couple of articles I've written, I've suggested on the talk page that we could try to get them to FA standard, and one of the first responses has been, "You'd need to get rid of the fixed image sizes." The problem with using thumbnails is that the sizing is inconsistent. Most of the time they took tiny, and sometimes enormous; see right for an example of the latter. SlimVirgin ^{talk|contribs} 12:48, 3 August 2009 (UTC)

Re "something in the MoS that makes editors think only thumbnails are allowed, except for the lead image" - it's the "one size fits all" approach of some MOS zealots, and their forgetting that MOS is a guideline, i.e. WP:IAR applies. The idea that "only thumbnails are allowed" has clear weaknesses, e.g.:

• It's no use to readers, most of whom are unregistered so can't set prefs.
• It depends on the pic. E.g. a simple pic such as most flags can be shown pretty small, but many maps and diagrams need to be larger.
• It also depends on the use. For example File:Atrax robustus.jpg can be shown if it's just a pic of the Sydney funnel-web spider or of spiders in general, but needs to be enlarged if it's used to illustrate the modification of the chelicerae into venom-injecting fangs, which is spiders' signature feature.

Such points should be left to the judgement of editors and reviewers. --Philcha (talk) 13:06, 3 August 2009 (UTC)

We've had this discussion several times on this page that I recall, and every time there is no consensus to force people to use thumbnails, yet somehow it has crept into the MoS: "Generally, use the thumbnail option ("thumb"), which is available in the image markup. ... As a rule, images should not be set to another size (that is, one that overrides the default)." SlimVirgin ^{talk|contribs} 14:02, 3 August 2009 (UTC)

Something I've suggested on the WT:FAC page that I think could be considered: We ask for thumbnails for images when they are to be flush alongside text. As we are still (?) designing towards a 800px resolution monitor, these should never be beyond 300px to avoid blocking off too much text. Yes, we should avoid setting a size and let "thumb" do its job, but that shouldn't be a hard-set rule. But there are points where images need to realistically be larger than 300 px horizontally to do their job on the printed version of the page. In this case, I propose that if the image needs to be displayed (and for print) at a size larger than 300px (and all NFCC considerations are met for that, if non-free), that we allow for "inline" images that do not run flush on text (see, for example, the Los Angeles panoramic view). This would need to use some special formatting to make sure there's text clear breaks on both sides if the image is >300 but less than 800 px, but technically not an issue. --MASEM (t) 14:10, 3 August 2009 (UTC)

Hi Masem, two questions: first, why do we ask for thumbnails? There has never been any consensus for that, so far as I know. And secondly, what do you mean by "flush on text"? I don't really understand the point you're making. SlimVirgin ^{talk|contribs} 14:20, 3 August 2009 (UTC)

I would support a change to the MoS allowing editors to use the image size best suited to the article. Darkfrog24 (talk) 15:05, 3 August 2009 (UTC)

I personally don't know the initial reasons why we ask for thumbs, but I would say that now they serve two purposes: they help to normalize the sizes of images in articles when the various images are all ranges of sizes (from what could be freakin' huge 2000x2000 free images to, say, reduced non-frees of standard TV/computer size dimensions (eg 320x240); and using thumbs from 180 to 300 px help to keep the page layout across WP pretty consistent without having to worry about browser/OS/font size issues (eg, we are trying to avoid pixel-perfect placement).

"Flush" means, as the example at the top of this section, the text runs as close as possible (with some margins) next to the image. This is compared to, say, if I were to put an image on a line by itself with no text running flush along either side of it. --MASEM (t) 15:21, 3 August 2009 (UTC)

BTW, the image I cited at the top of this section has a caption that is ... wait for it ... 14 lines deep, most of them three or four words across. Here is the current text that appears relevant to this issue:

• Most pictures should be between 100 and 400 pixels wide. Generally, use the thumbnail option ("thumb"), which is available in the image markup. This results in a default width of 180 pixels (140 pixels if the "upright" option is used as well), although logged-in users can set a different default in their user preferences. As a rule, images should not be set to another size (that is, one that overrides the default). Where it is appropriate to select a particular size, images should generally be no more than 300 pixels wide, so that they can be comfortably displayed on 800x600 monitors. Where appropriate, the {{Wide image}} template can be used to fit an image into the width of the browser window (similarly, {{tall image}} may be used for abnormally tall images). Examples where size-forcing may be appropriate include:

• Images with aspect ratios that are extreme or that otherwise distort or obscure the image
• Detailed maps, diagrams, or charts
• Images containing a lot of detail, if the detail is important to the article
• Images in which a small region is relevant, but cropping to that region would reduce the coherence of the image
• Lead images, which should usually be no larger than 300 pixels

This is what I suggest, although I'm an amateur at image control, so please weigh in with your suggestions and we can create another draft below if necessary. In particular, I've no idea about the 300 versus 400 pixel issue:

Images are normally up to 400 pixels wide, although an upper limit of 300 pixels is typical so they can be comfortably displayed on 800 x 600 monitors. Editorial judgement should generally be used to set an image to a size that is neither so large that it "crowds" the text which wraps along its side, nor so small that its details are uncomfortable for readers to discern and the caption text is wrapped in an over-narrow column. Other reasons for forcing size may include that an image:

• has aspect ratios that are extreme or otherwise distort or obscure the image;
• is of a detailed map, diagram, or chart;
• contains a small region is relevant, but cropping to that region would reduce the coherence of the image;
• is in the lead, in which cast it should usually not be larger than 300 pixels.

Alternatively, the thumbnail option ("thumb") is available in the image markup, which results in a default width of 180 pixels (140 pixels if the "upright" option is used as well), although logged-in users can set a different default in their user preferences.

Where appropriate, the {{Wide image}} template can be used to fit an image into the width of the browser window (similarly, {{tall image}} may be used for abnormally tall images).

Tony (talk) 16:34, 3 August 2009 (UTC)

Nice. The line about editorial judgment is exactly what we need. However, I think it would be best to distinguish more clearly between description and instruction. This stuff is confusing for beginners and I don't think we want to confuse information on what images are with instructions on what we want the users to do. For example, "Most images are 300 pixels wide" is confusing because I've seen images of all shapes and sizes.

On Wikipedia, most images should be no wider than 300 pixels, with a maximum for most articles of 400 pixels wide. This is so images can be displayed comfortably on 800 x 600 monitors. However, editorial judgment should be used to set each image to a size that is neither so large that it crowds the text that wraps along its side nor so small that its details are difficult for readers to discern and its caption text wrapped in an overly narrow column. Some other situations in which forcing image size may be desirable include the following:

• Images with aspect ratios that are extreme or that otherwise distort or obscure the image.
• Detailed maps, diagrams, and charts.
• Images in which a small region is relevant but cropping to that region would reduce image coherence.
• Lead images, which should usually not be larger than 300 pixels.

Alternatively, the thumbnail option ("thumb") is available in the image markup, which results in a default width of 180 pixels (140 pixels if the "upright" option is used as well), although logged-in users can set a different default in their user preferences.

Where appropriate, the {{Wide image}} template can be used to fit an image into the width of the browser window (similarly, {{tall image}} may be used for abnormally tall images).

Darkfrog24 (talk) 16:59, 3 August 2009 (UTC)

I think any solution that puts the "thumb" option as the secondary option under "allow the editors to decide" is going to be a problem. Knowing those that love to use images, if you give them up to 300px, they will use 300px, even if its not necessary for an image. You've also just nuked the reason a user may choose a different image thumb preference.

An optional approach may be to consider changing the default thumb size from 180 to around 220-250px (a setting in the WP wiki config, I believe), with the noted allowances for going beyond this if necessary. This would fix most of the "walls of caption text" that seem to be at issue, and retain the user preferences aspect. If anything, we then need to emphasize that it is appropriate to break out of the "thumb" size when it makes sense, being a lot more lenient and IAR-ish about that fact. The only limiting factor is why we chose 180px in the first place - if it's for NFCC issues or the like, we may have to stick to that. (That subtly comes into play here, it should be noted). If the 180px was due to file size and typical transmission issues, that's likely no longer a valid reason of concern with the proliferation of high-speed today. --MASEM (t) 17:13, 3 August 2009 (UTC)

• How about starting: "On Wikipedia, most images are narrower than 300 pixels, with a maximum for most articles of 400 pixels wide."? Tony (talk) 17:40, 3 August 2009 (UTC)
  • I think we've got two aspects going on here. We want to try to funnel images to <300px (what that is, well, that's an issue). The next question is that when an image has to go over 300px for good reason, how do we deal with it? And that's where the 400px is - it's not really a maximum image size, but a size where we now span over half the page at 800px, and thus needs special treatment beyond that. If it is larger than 400px then it should be placed without flush text per the {{wide image}} template; if it's less than 400px, then it should be placed aligned in text. --MASEM (t) 17:47, 3 August 2009 (UTC)

Three things about Tony's proposal:

• He's right about editorial judgement being the final arbiter. Whether it's deciding what info the pic needs to convey or how to solve layout problems (which are harder on widescreen monitors), the editor can often produce a better solution than a set of rules can.
• I agree with Masem that the "thumb" option should be presented as the preferred option in most circumstances, simply because thumbs adapt more easily to change - for example perhaps we'll all have portrait monitors in 5 years.
• We need to avoid the word "should" because it's ambiguous - some treat it as "is preferable", others as "must", and we already have enough arguments over interpretation of "should" and "should not".

So here's my attempt for y'all to shoot at:

Wikipedia's recommendations on image size are a guideline rather than a policy, and therefore may be overridden if common sense shows than an alternative approach is better for readers. In most cases the default "thumb" option of the image markup is the best option for many reasons, for example:

• Logged in users can override this in their preferences.
• It produces images of the same width and thus avoids a ragged appearance.
• It can be adjusted globally if circumstances change, for example if new types of monitor become common.

However there are several types of situation where editors may find it necessary to specify sizes, including:

• Providing larger sizes for detailed diagrams, maps, charts, etc.
• Reducing the size to avoid cramping the text between or to one side of one or more images.
• Reducing the need for gaps between sections or paragraphs in order to keep images alongside the text they illustrate.
• Presenting lead images. If the article has an infobox, the lead image should fill all its width apart from a small margin on each side, and this will often require a fixed size. In other cases lead images are expected to be less than 300 pixels unless it can be shown that a larger size provides clear benefits to readers.

--Philcha (talk) 17:53, 3 August 2009 (UTC)

I'm not in favor of saying the thumb is better, or the default, because it encourages editors to go around removing image sizes, which is the problem with the current wording. I prefer Tony's version, where we stress editorial judgment. SlimVirgin ^{talk|contribs} 18:02, 3 August 2009 (UTC)

This makes two separate issues: the legitimate complaint against the MOS's prescription of using "thumb" which presently defaults to 180px, mostly due to 180px being too small, and the behavioral problem of those that forget that the MOS, while policy, needs to be treated in an IARish manner, and that going around removing "thumb" without consideration of editorial decisions is not good editing practice. The latter is something outside the bounds of MOS beyond using the best language possible to convey this, but continued "abuse" of the MOS in this manner should be dealt with in appropriate dispute resolution.

So if you take the behavior out of it, we're still at the case where, at least to me, we want to still encourage and funnel users to use "thumb", with strong consideration of upping the default thumb size to 220-250px, but emphasizing that they may consider other sizes if they deem it necessary. --MASEM (t) 18:21, 3 August 2009 (UTC)

You can't take the behavior out of it, and it's not reasonable to ask us to engage in dispute resolution every time someone tries to enforce the MoS. The wording needs to be changed, so as not to encourage people to impose thumbnails on articles. There's anyway no good reason to use thumbnails. I have no problem setting parameters—no smaller than X, no larger than Y—but otherwise editors have to be allowed to use their judgment. SlimVirgin ^{talk|contribs} 18:26, 3 August 2009 (UTC)

If people are interpreting, as it is presently worded "Generally, use the thumbnail option ("thumb")...", as that we require thumb sizes, then those people are overstepping their editing bounds. This is a human-decision-based clause, it cannot be done purely mechanically. --MASEM (t) 18:32, 3 August 2009 (UTC)

• How about changing the default thumb size as suggested by MASEM, and changing the guideline to keep the basic encouragement to use the thumbnail option, but adding encouragement to use proportional image scaling where appropriate. Suggested wording:

• In general, pictures should be between 100 and 400 pixels wide. Basic practice is to use the thumbnail option ("thumb"), which is available in the image markup. This results in a default width of 180 pixels (140 pixels if the "upright" option is used as well), although logged-in users can set a different default in their user preferences.
• Where images have a lot of detail or small lettering, larger images can be used for clarity. Adding the parameter |upright=2.2 gives a scaled image equivalent of a 400 pixel wide image, making the number larger or smaller changes the image size accordingly. Where appropriate, the {{Wide image}} template can be used to fit an image into the width of the browser window. It is also possible to fix the image size using the parameter |px=300, in which case images should be no more than 300 pixels wide, so that they can be comfortably displayed on 800x600 monitors. Where tall images appear unduly large, {{tall image}} may be used to force a smaller size. Examples where size-forcing may be appropriate include:

• Images with aspect ratios that are extreme or that otherwise distort or obscure the image
• Detailed maps, diagrams, or charts where text appears too small
• Images containing a lot of detail, if the detail is important to the article
• Images in which a small region is relevant, but cropping to that region would reduce the coherence of the image
• Lead images, which should usually be no larger than 300 pixels

That way we get away from the problems which seem to be associated with |px=400 or other fixed sizes. The ideal or maximum ratio for |upright= should be given, alternatively clear advice could be given on using {{tall image}} which seems to duplicate the |upright= parameter. . dave souza, talk 18:09, 3 August 2009 (UTC)

Dave, what is wrong with letting editors set image sizes (in words a completely non-technical person will understand, if possible)? SlimVirgin ^{talk|contribs} 18:28, 3 August 2009 (UTC)

I wrote the above before seeing your comment, but left it as "Basic practice is to use the thumbnail option" simply says what the basic way of doing it is, without saying you must do it. Don't mind if you've got better wording, perhaps "The simplest approach is...." My aim is to set out clearly the best ways to change image sizes, and state what the limitations are, if any. The proportionate method using |upright= sounds as though it may fix the problem of |size=400px, but technical advice is needed. Part of the problem is that the same thumbnail view or enlarged view looks much larger in Camino than it does in Safari, don't know about other browsers. The aim is a simple way for editors to play about with image sizes and reach workable and reasonable layouts. . dave souza, talk 19:20, 3 August 2009 (UTC)

Yes, exactly. Everything depends on the image, the shape of it, what it shows, what it's being used for, where in the article it's going, whether it'll be near other images, templates etc. We can't have one-size-fits-all. Look at the image I posted at the top of this section, for example. That's a thumbnail, but clearly too large. I think we need to remove anything that suggests thumbnails are required or preferred. SlimVirgin ^{talk|contribs} 19:30, 3 August 2009 (UTC)

This section got pretty long, so I created a new section #Image size rewording below for further comments. Eubulides (talk) 23:13, 3 August 2009 (UTC)

Image-size rewording

As it happens, over the past couple of weeks I've rewritten WP:Picture tutorial, particularly its image-size section. I read through the above discussion and a lot of it makes sense, but there are some problems:

• The current and proposed text sometimes suggests 300px, sometimes 400px. It should be consistent. The 300px limit comes from old desktop and laptop displays that are 800px wide. These displays are obsolete and are no longer of practical importance to Wikipedia. Currently, the narrowest displays in widespread use on desktops and laptops are 1024 pixels wide. Of course there are mobile devices with displays narrower than even 800px, but they use different techniques to show Wikipedia images, which won't be affected much by changing suggested max width from 300px to 400px.
• Dave souza's draft has some good suggestions, particularly about proportional image scaling, but it also has some problems, e.g., it doesn't address non-thumbnails and it uses some syntax like "px=300" that doesn't work.
• It's OK to say that thumbnails are in common use (as they are); this doesn't mean they are required or preferred.

The following draft attempts to address the above issues. A sandbox diff shows the difference between this text and what's currently installed.

(This draft is now obsolete; please see the #MistyRose proposal below. Eubulides (talk) 08:06, 4 August 2009 (UTC))

• Most pictures should be between 100 and 400 pixels wide. Common practice is to use the thumbnail option ("thumb"), which is available in the image markup and normally floats the image to the right. This results in a default width of 180 pixels, although logged-in users can set a different default in their user preferences.
• A picture may benefit from a size other than the default. Adding the parameter "|upright=2.2" (or "|frameless|upright=2.2" for non-thumb images) scales an image to about 400 pixels wide by default; making the number larger or smaller changes the image size accordingly. A floating image should generally be no more than 500 pixels tall and 400 pixels wide, so that it can be comfortably displayed next to text on the smallest displays in common use; a nonfloating image can be somewhat wider if it stands alone. The {{Wide image}} and {{Tall image}} templates can display images that would otherwise be impossibly wide or tall. Examples where adjusting the size may be appropriate include:

• Images with aspect ratios that are extreme or that otherwise distort or obscure the image
• Images containing important detail. For example, a map, diagram, or chart may contain important text that would be unreadable at the default size.
• Images where detail is relatively unimportant. For example, a national flag may be easily recognizable even at a small size.
• Images in which a small region is relevant, but cropping to that region would reduce the coherence of the image
• Lead images, which should usually be no wider than "upright=1.67" ("300px")}}

Eubulides (talk) 23:13, 3 August 2009 (UTC)

I see no problem with the above (and yes, agree the 300px is probably out of date.) 400px is probably the best limit to stick with as to consider the issues with NFCC (as if you take most NFC, being from screenshots, a 400px width image will get you an image file that is just around 0.1 megapixels, which has been suggested as the "ideal" low resolution image, though by far not a hard limit).

I still say we talk about increasing the default "thumb" size to 250px based on the same logic above. --MASEM (t) 23:18, 3 August 2009 (UTC)

The default thumb size could well be increased too. The above proposal is designed to make sense no matter what the default is, though of course its specific numbers would need to be changed to match whatever the default is. Eubulides (talk) 03:06, 4 August 2009 (UTC)

If this is aimed at newcomers as well as the technically proficient, it might be a good idea to avoid the word "parameter", which startled me as a non-techie, even though its meaning later becomes apparent. There are several other phrases that mean nothing to newcomers, such as "floating", and others which suggest complexity such as the templates. The style just looks too technical and daunting, I'm sorry to say.

I think, however, that it might be a good guideline if converted into the language of an ordinary reader who just wants to post a picture (which is quite complicated enough already by the multiple-stage process of uploading not to Wikipedia but to the Wikimedia Commons, certifying the rights, and then transcluding it — if that's the correct term).

As for image size, my Compaq FS7600 monitor (on Windows Vista Home Basic) is I think 800 x 600 pixels, but I deliberately used a 400-pixel-wide image of a New York Times cartoon so that the important words within the image would be legible on small screens like mine. (Originally it had been 550 pixels wide, but that caused problems for other users. See Talk:New York City mayoral election, 1917#Formatting and the article itself. See also, for comparison, Talk:New York City mayoral election, 2009.) Although I'd agree that it's bad style to have too much of it, I see nothing wrong in occasionally squeezing wrap-around text so long as the text is suitable for such squeezing (in the 1917 mayoral example, it was a set of bullet points) and you're conscious of what you're doing. —— Shakescene (talk) 06:00, 4 August 2009 (UTC)

• Thanks for the comments. I attempted to reword the draft to make it less technically daunting, and the result is in the #MistyRose proposal below. Unfortunately some of the stuff can't easily be omitted (e.g., "upright=2.2"), but the words you mentioned ("parameter" and "floating") can be removed, and wikilinks can be added for parameter names like "upright".
• The Compaq FS7600's recommended resolution is 1024×768, as per its user's guide (PDF). Like most CRTs, one can run it in 800×600 mode and it will display larger text that way; this sort of thing used to be more common but I think it's relatively rare nowadays. But perhaps this point is moot if 400px looks OK on your screen.

Eubulides (talk) 08:06, 4 August 2009 (UTC)

You're right; once I remembered the easy way to look up my resolution, it was indeed 1024 x 768 pixels. The FS7600 is smaller than my previous 19" screen, so the higher resolution gets swallowed up by the tiny display (sometimes commas are hard to distinguish from periods/full stops; and umlauts, tildes and circumflexes from each other.) While I don't have the time or patience to do it right now (being exhausted by trying to reconstruct who was Chairman and who President of the Reconstruction Finance Corporation, and when), perhaps someone would like to see what in fact does happen to New York City mayoral election, 1917 when seen in an 800 x 600 resolution. —— Shakescene (talk) 08:21, 5 August 2009 (UTC)

Reasons for defaulting

All of the above proposals are articulate on why it is good to set image sizes, and make no mention of why it is good to use the default. Some people have tiny screens or terrible bandwidth. These people can improve their browsing experience by setting their preference for very small thumbs. But only if we honour those preferences. When you decide that an image looks better at 350px than your default 300px setting, you're also telling people with a 120px preference that they are going to take this image at 350px whether they like it or not.

There are so many different screen sizes, font sizes, browser layout engines, aesthetic preferences, etcetera, that you are fooling yourself if you think you can construct a layout that looks nice to everyone. In reality, all you are doing is making the layout look nice to you, on your screen. I wish I had a dollar for every edit where someone shrunk an image (for me) with edit summary "bigger image".

My preference is for honouring thumbing. But, failing that, at least don't give us a policy statement that provides a persuasive rationale for only one side of the debate.

Hesperian 23:33, 3 August 2009 (UTC)

Bingo. There is a reason why thumbnails were preferred, and it's so that users can see smaller images if they want to see smaller images. Or larger ones if the have the space; my default is set to 250px, for example. Powers ^T 02:02, 4 August 2009 (UTC)

The #Beige proposal (above) addresses both of the previous comments, because it suggests using the "upright=Factor" option instead of absolute pixel sizes. The upright option causes the image to scale according to your preferences. For example, if an article's editor wants a larger image and uses "upright=1.5" to get it, you the reader will see a 375px image if your preference is 250px, and no reader will get an image smaller than they would have otherwise got. Eubulides (talk) 03:06, 4 August 2009 (UTC)

Just to be clear, 99% of the people who read Wikipedia are not logged in, and have no option to change their viewing preferences. Since the default thumb setup (which is what unlogged readers see) is clearly unsatisfactory to the majority of viewers here, it can be extrapolated that it is likely a problem for unlogged readers too. I can assure you that when I was using a public computer to view some stuff (and was not logged in), the images were so small they were nearly pointless. Thanks to those who are working to let us have pictures that are big enough to see. Risker (talk) 04:12, 4 August 2009 (UTC)

Risker puts it very well. In this respect, it's like our discovery last year that date-autoformatting didn't work for 99.99% of readers, and prevented us from noticing the glitches that lie behind the display, which had always been there for our readers to see. As a general rule, I strongly advocate that the editors who are responsible for crafting the appearance and formatting of our articles should see what the consumers see—they are the only readers who really count. I'd go so far as to say that WPians should disable their thumbnail-size preference, so they can make proper judgements as to detail and text wrapping for each image in an article.

Dave Souza's version(s). (1) It seems to have lost some of the good bits of mine, in particular the need for editors to balance the amount and size of detail in a pic with the need to avoid the uncomfortably narrow wrapping of text. I think we need to emphasise editorial judgement; we need to encourage editors to treat image size (and placement) seriously as an integral part of a high-quality product. (2) In the green box, Dave's bullets refer to both up- and down-sizing. In the beige they refer to down-sizing (?). It needs to be explicit so normal editors can easily understand it. (3) Except for flags/icons etc, I find 180px to be almost never worth bothering with. Dave's text still seems to encourage or condone the wide use of 180px. If you want a good example of how numerous superb historical pics we are able to use are basically ruined from an in-article reading perspective, have a look at the current FAC "Operation Charnwood". The vividness and life of the large infobox image are completely lost further down. You'll first need to disable your thumbnail size prefs, if you haven't already. This is nano-pic land; whereas this is after I've gone through to force a bigger size on the pics, all still thumbnails. The "Handley Page Halifax" pic under "Preliminary attacks" no longer looks like a close-up of a mineralogical sample: now it's an airplane above the chaos of war. I'd have it even larger—the accompanying text seems to demand it—but I'm being cautious.

Norse–Gaelic example still dysfunctional. I still have a problem with the map I exemplified at the opening of this debate. It is now displayed just below Slim's plastic bottle example of why we need to move on from the one-size-fits-all. Eubulides enlarged the map to 1.8 thingies, but I found that still too small to work out up from down, not even considering the nanoprint. I've raised it in the article to 2.0, but still, the print is undecipherable; you are forced to divert to the original image to learn what any word actually is, and this despite the fact that the caption refers one by one to words on the map. It is dysfunctional in these ways. So ....

Font size. Until now, we have included no advice about the size of lettering on maps and diagrams. It's a pet issue for me, since my clients often have to be encouraged to use larger font-sizes on their diagrams and pictures to avoid irritating the assessors. I don't know why people aren't fussy about this when there's plenty of space in which larger font-size can lie, such as on that map. (PS In fact, I find it very hard to decipher the wording in the original, large version. The dark-green colour doesn't help one bit, but even the yellow-background font needs significant boosting. I note also that some editors have complained about the inclusion of image titles in the image itself, as here; I have sympathy for this complaint.)

Brevity in captions. Whenever I look at a caption, I seem to be able to find ways of removing words with no loss of meaning. We have never encouraged editors to be vigilant about language bloat in their captions—particuarly the usual redundancies. I don't advocate stubby, truncated language in captions, but I do think it's even more important to avoid the vertical rise effect where it's easy to do so.

Therefore, I wonder whether there is support for include brief, "soft" advice to editors on font size within images and the need to avoid redundant wording in captions. This could be included at the same time as we get the advice on image size right. Again, the emphasis should be on encouraging editors to skill up and use their creative judgement for our readers' sakes, by outlining the editorial issues at stake. Tony (talk) 04:30, 4 August 2009 (UTC)

We do need to set up some guidelines for fonts in maps and charts, and in fact the encouragment to generate free versions of these in SVG when possible to avoid the destruction of readibility when images are shown at low size. But that's a much larger issue and doesn't seem as pressing to make sure we guide those actively seeking to limit images to "thumb" size to avoid doing that.

That said, there is still an issue of why 180px was picked in the first place that my Google-fu is not easily figuring out from talk page archives. It may be associated with NFCC policy, in which case, then, there's likely good reason to stick with it as the default thumb size. But if it's "just because" then damn the torpedos and lets get the default thumb up to 250px and emphasis IAR in allowing larger images. --MASEM (t) 04:55, 4 August 2009 (UTC)

The NFCC concerns are not related to default thumbnail widths; please see #NFCC and default width below. Eubulides (talk) 18:17, 6 August 2009 (UTC)

Just in case it's getting lost in the details, the original problem that we're trying to correct is that some users (mis)interpret the current phrasing of this section of the MoS to mean that thumbnails are required rather than recommended. It is my understanding that people have been going in and changing other-sized images to thumbnails solely because they believe it is required by the MoS. The conversation has transitioned toward discussing default image sizes, but we must be careful to remember to correct this problem as well.

It is also my understanding that a phrase that precedes a colon must be an independent clause, even if it is introducing a list. Ergo, our final text should read "includes the following" rather than stopping at "includes."

As for adding soft advice, I don't think it's a good idea, not even if we can all agree on whether short or long captions are best. We've already seen people can misinterpret "recommended" to mean "required." I feel that overly verbose captions are the sort of thing that we should allow users to fix as they go. Darkfrog24 (talk) 05:02, 4 August 2009 (UTC)

People here do seem to agree that editors shouldn't be going around changing image sizes to thumbnails over objections. I've therefore removed the parts of the MoS advice that were causing that, particularly the sentence, "As a rule, images should not be set to another size ..." [9] SlimVirgin ^{talk|contribs} 05:51, 4 August 2009 (UTC)

Nice, but we could use a "the following" after "are not limited to." Darkfrog24 (talk) 05:58, 4 August 2009 (UTC)

Re SlimVirgin's "People here do seem to agree that editors shouldn't be going around changing image sizes to thumbnails over objections" (05:51, 4 August 2009), I'd add a clause: "except where the objection is only that use of thumbs is standard practice" or equivalent - in other words the objectors must also consider the effect on the (unregistered) reader of the size of the specific image in the specific place in the specific article. --Philcha (talk) 06:33, 4 August 2009 (UTC)

Several good points were made in the previous comments. The specific wording proposals that I gleaned from them, relative to the #Beige proposal above, are

• SlimVirgin's wording change, already installed.
• Shakescene's suggestion to use less jargon.
• Darkfrog24's suggestion to put "the following" before ":".

I incorporated these suggestions into the #MistyRose proposal below. Eubulides (talk) 08:06, 4 August 2009 (UTC)

Re "this is after I've gone through to force a bigger size on the pics, all still thumbnails" above: A problem with changes like those, which inserted exact widths like "200px" into Operation Charnwood, is that this makes the images smaller for readers who've expressed their preference for larger thumbnails by changing their default widths to 300px. It's better to use "upright=1.1" instead, as this does not shrink the image for anybody. I changed the article to use "upright=Factor" rather than "Widthpx"; this won't affect the appearance for IP users or for users who have not changed their default image widths, and will behave better for users who have changed their defaults. Eubulides (talk) 08:30, 4 August 2009 (UTC)

I made my edit earlier not realizing the page was protected. I've requested unprotection. If it isn't granted, I'll revert my edit. SlimVirgin ^{talk|contribs} 09:50, 4 August 2009 (UTC)

Thanks for making that change, SV. I don't think anyone here disagrees with it, so I hope it's not reverted. I'm off to tell WT:FAC the good news. Tony (talk) 11:03, 4 August 2009 (UTC)

MistyRose proposal

This is an updated version of the #Beige proposal for improving the guideline for image sizes; it takes into account the comments noted above.

• On Wikipedia, most pictures should be displayed so they are between 100 and 400 pixels wide. The thumbnail option ("thumb") results in a default width of 180 pixels, although logged-in users can set a different default in their user preferences.
• A picture may benefit from a size other than the default. The "upright=2.2" option (or "|frameless|upright=2.2" for plain pictures) resizes an image to about 400 pixels wide by default; making the number larger or smaller changes the image size accordingly. An image should generally be no more than 500 pixels tall and 400 pixels wide, so it can be comfortably displayed next to the text on the smallest displays in common use; an image can be somewhat wider if it uses the "center" or "none" options to stand alone. The {{Wide image}} and {{Tall image}} templates can display images that would otherwise be unreasonably wide or tall. Examples where adjusting the size may be appropriate include, but are not limited to, the following:

• Images with aspect ratios that are extreme or that otherwise distort or obscure the image.
• Images in which detail is relatively unimportant (for example, a national flag may be easily recognizable even at a small size).
• Images containing important detail (for example, a map, diagram, or chart may contain important text that would be unreadable at the default size).
• Images in which a small region is relevant, but cropping to that region would reduce the coherence of the image.
• Lead images, which should usually be no wider than "upright=1.7" ("300px")

The difference between the currently-installed version and this version is available. Further comments are welcome. Eubulides (talk) 08:06, 4 August 2009 (UTC) updated 20:09, 4 August 2009 (UTC) updated again 05:59, 5 August 2009 (UTC)

Is there any benefit to recommending editors write "upright=x," as opposed to "xpx"? —Preceding unsigned comment added by SlimVirgin (talk • contribs) 08:45, 4 August 2009 (UTC)

Yes, as explained above; an explicit size like "250px" undesirably makes a thumbnail smaller for a reader whose width preference is 300 pixels. In contrast, "upright=1.4" makes the thumbnail larger for all readers. Eubulides (talk) 09:21, 4 August 2009 (UTC)

Very few readers have set their width preferences. We need to cater to the average reader, and if an editor wants an image to be 250px, there's no reason not to allow him or her to do that, surely. SlimVirgin ^{talk|contribs} 09:24, 4 August 2009 (UTC)

Yes, there's no reason not to allow 250px settings; in some cases they make perfect sense, for example when sizing one image to fit against another small-resolution image. The proposed wording does not disallow or state a preference against settings like that. Eubulides (talk) 20:09, 4 August 2009 (UTC)

We should not be encouraging editors to try to produce pixel-perfect layouts. There's too many target platforms that WP serves that the work of a user Editor-Using-IE8-on-1200x1068-Monitor-with-10pt-Ariel to make the layout perfect by assigning pixel sizes to image to get it to look right on their monitor will undoubtedly screw up on any other platform.

Hmm. Anyone know if there's a way to have images show up as a percentage of the box width that it is in? --MASEM (t) 15:33, 4 August 2009 (UTC)

That would be a very nice thing to have. As far as I know it is not possible with the current MediaWiki software. If there's some way to do it, I will document it in WP:PIC. Eubulides (talk) 20:09, 4 August 2009 (UTC)

Agree. Please let's not get to prescriptive here. --Joopercoopers (talk) 15:08, 4 August 2009 (UTC)

• "Most pictures should be between 100 and 400 pixels wide" -- I hope this doesn't mean image uploaders will only upload images between 100 and 400 pixels wide now, citing the MOS "policy". Perhaps, "Most pictures, when included in articles, should be resized to between 100 and 400 pixels wide"? Matthewedwards :  Chat  17:13, 4 August 2009 (UTC)
• Agreed. Let the actual stored image size be a concern of NFC, let the display size be the concern here. --MASEM (t) 17:18, 4 August 2009 (UTC)
• Thirded. That's a very good way to phrase it. Darkfrog24 (talk) 17:19, 4 August 2009 (UTC)

• Thanks for this suggestion. I adjusted the proposal to say "Most pictures in articles should be displayed with widths between 100 and 400 pixels.", which I think captures the suggestion more succinctly. Eubulides (talk) 20:09, 4 August 2009 (UTC)

It's a bit ungainly. Try this: "On Wikipedia, most pictures should be displayed so that they are between 100 and 400 pixels wide. [Explanation about monitor size.]" Darkfrog24 (talk) 00:34, 5 August 2009 (UTC)

Thanks, that's better, and I reworded it that way. Eubulides (talk) 05:59, 5 August 2009 (UTC)

Eubulides and the others who have contributed, Misty Rose looks very well-worded—nice work indeed. I took the liberty of tweaking in a few places (no substantive change in meaning). A few queries:

• "so it can be comfortably displayed next to the text on the smallest displays in common us"—will that get us into trouble if Blackberry/mobile displays are construed as this? Perhaps not, but those more familiar with such issues might consider the option of simply finishing the statement on "text".
• Can we remove "somewhat", since it doesn't seem to add anything?
• "The {{Wide image}} and {{Tall image}} templates can display images that would otherwise be unreasonably wide or tall." Can we remove "can" (or don't those templates always have good effect)? And just from my dumb perspective (which is a good target to address), the alternative to using those templates would be what? Would it not be clearer to write: "... templates moderate the dimensions of images that would otherwise be unreasonaly wide or tall."?
• As I mentioned above, the bullets mix the reasons to up-size and the reasons to down-size; it would be a little easier if the reasons to down-size were all listed together (say, first), and then the reasons to up-size. I've swapped the location of one bullet point to this end, but I'm wondering whether the last one (lead, no more than 300px) is meant to be up- or down- or either? If either of up-size only, it could stay at the end. If down-size only, it could go up the list with its siblings.

There's just one issue rootling around in my mind: several editors have expressed a clear dissatisfaction with the thumbnail default of 180px, which is how the vast majority of images that have been thumbnailed because of the MoS wording will appear to our readers. Is there any reason we shouldn't lobby for this to be increased to, say, 200px? If there were consensus, this could be done as a second phase, after misty rose is implemented. Tony (talk) 07:55, 5 August 2009 (UTC)

Indeed we should; this is often raised at WP:IMAGE & elsewhere, but is not pursued. Johnbod (talk) 15:50, 6 August 2009 (UTC)

• One minor wording issue I have is that none of the drafts above make it clear that even with forced sizes you still need to include the "thumb" parameter or you lose the caption & formatting. I certainly support editorial choice in the matter, allowing as far as possible for different screen sizes etc. Johnbod (talk) 15:50, 6 August 2009 (UTC)

NFCC default width

Heck, I'd lobby for 250px instead of 200px. The only issue which I cannot google-fu well enough to determine is if there is any NFCC concerns for non-free images by going above 180px as the default. Those that complain about that being too big on their layout are likely registered users and can change it. --MASEM (t) 15:54, 6 August 2009 (UTC)

• Blackberries and mobile displays are not an issue. They ignore our width advice entirely.
• The NFCC argument seems to be based on a misunderstanding of how default widths apply. If an image's native width is (say) 200px due to NFCC concerns, then any default width above 200px is ignored; the image is never displayed above its native resolution merely due to default widths. So if we change the default width to (say) 250px, there cannot possibly be any NFCC concerns with the resulting article that are not already present in the native image (which is readily available). Now, there may indeed be concerns about blowing up a 200px image to (say) 600px, using an explicit width; but a default-width image should always be OK.
• Tony, removing the "somewhat" and the "can" is fine. However, the Wide and Tall image templates do not "moderate dimensions"; they display the images in a little window that's scrollbarred. I'm not sure it's worth putting details about that here. If you can redo the wording to make it more logical, please do so.

Eubulides (talk) 18:17, 6 August 2009 (UTC)

Section headers renamed in picture tutorial

{{editprotected}} Please install this minor change to adjust to new section header names in Wikipedia:Picture tutorial. Thanks. Eubulides (talk) 23:13, 3 August 2009 (UTC)

Done. --- RockMFR 23:37, 3 August 2009 (UTC)

Altviewer rather than checkALTtext

In practice at WP:FAC and WP:FAR editors are using the Altviewer tool to check for alt text instead of the User:Proteins/checkALTtext.js script suggested on this page. To reflect common practice I propose changing "A script for checking whether an article's images have alt text is given here. " to "The Altviewer tool displays an article's alt text.". Eubulides (talk) 23:13, 3 August 2009 (UTC)

When alt text can be omitted

Where the current page says that images need not have alt text, it could be misread into saying that it's perfectly OK for an ordinary thumbnail or image to lack alt text. The actual guideline given in WP:ALT (derived from W3C accessibility guidelines) is somewhat stricter, in that editorial decision on whether an image has alt text should depend on whether the image is purely decorative. To reflect this, I propose changing "The guideline on this subject notes that images need not have alt text; editors should ..." to "The guideline on this subject notes that an image need not have alt text if it is purely decorative, that is, if it conveys no additional information and nothing happens when you click on it. Editors should ...". Eubulides (talk) 23:13, 3 August 2009 (UTC)

I disagree with any attempt to force editors to add alt text. One reason I object is that FAs are expected to follow the MoS; therefore if the MoS can be interpreted as recommending alt text, that will be one more burden on FA writers, and the burden is heavy enough as it is. SlimVirgin ^{talk|contribs} 06:54, 4 August 2009 (UTC)

The proposed change does not change any requirements; it merely fixes a misleading summary of the WP:ALT guideline. There is widespread consensus that Wikipedia should make its content accessible to people with a disability such as blindness and low vision. This consensus includes a recommendation for alt text not only in guidelines such as WP:ALT and WP:ACCESSIBILITY, but also in policy such as WP:IUP. The specific reason given for objecting is based on a misunderstanding, as WP:FACR#3 independently requires featured articles to have alt text and the proposed change would neither affect this nor add to FA writers' burden. Eubulides (talk) 08:06, 4 August 2009 (UTC)

I really strongly object to that, Eublides. People shouldn't be adding to the FA style criteria without much stronger consensus, because writers are already groaning under the weight of them. I have five or six articles that have been almost ready for FA for some time (a couple of years in some cases), and I can't face getting them there because of the heavy focus on style. We definitely should not be making that worse. SlimVirgin ^{talk|contribs} 08:42, 4 August 2009 (UTC)

In practice alt text has not proved to be much of a burden, and the process is working well at WP:FAC and WP:FAR. The initial reaction of some editors was also to object, but typically once people found out how little work it was, and how much benefit accrues to visually impaired readers, the objections were withdrawn. Could give a specific example of why alt text would be a significant burden to one of the articles you're working on? Eubulides (talk) 09:11, 4 August 2009 (UTC)

I've replied over at FAC, as it has already been added there. SlimVirgin ^{talk|contribs} 09:22, 4 August 2009 (UTC)

Can you offer evidence that this is actually helping visually impaired readers? SlimVirgin ^{talk|contribs} 09:25, 4 August 2009 (UTC)

Yes I can. I will do so at WT:FAC to avoid duplicating the discussion here. Regardless of the results of that discussion, we still have to fix the problem here somehow, as the current text gives an inaccurate (or at best, misleading) summary of WP:ALT. Can you suggest alternate wording that would solve this problem while still addressing your concerns? Eubulides (talk) 20:09, 4 August 2009 (UTC)

I'll take a look at the current wording. You said you would post some evidence at FAC, but I didn't see it. Would you mind posting it here? I'd be very interested to know who this is actually helping, and what kinds of descriptions are best for them. SlimVirgin ^{talk|contribs} 09:17, 5 August 2009 (UTC)

I followed up at WT:FAC #Alt text helps the visually impaired. Eubulides (talk) 18:17, 6 August 2009 (UTC)

Humungously long alt text

• On a slightly different note, I've seen alt texts in FACs that are humungously long: surely that wasn't the original intention. Tony (talk) 11:05, 4 August 2009 (UTC)
  • Maybe what we need is someone that is really good writing captions and alt text to establish a Dispatch or something before expecting everyone to follow a standard? (I don't question the need to include alt text, just that there is confusion between what that and the caption should do). --MASEM (t) 15:29, 4 August 2009 (UTC)
    • Humungously long alt text is not the intention, and runs afoul of WP:FACR's requirement that alt text be "brief". The difference between alt text and caption is currently described in WP:ALT #Difference from captions. It is a good suggestion to write a Dispatch; in the meantime WP:ALT is intended to cover the points that an alt text writer needs to know. Suggestions for improving WP:ALT are welcome. 20:09, 4 August 2009 (UTC)

Query: here's the alt text for the garish green/yellow map cited at the top of this section.

alt=Map showing much of north-western Britain, with the sea in blue, Norse–Gaelic land in yellow; other regions marked in green, from south to north, are: "Earldom of Northumbria" where the upper region of the Tyne lies, "Strathclyde" on the Clyde, "Kingdom of Alba" on the rivers Tay and Earn; in yellow territory from south to north: "Mann" where the isle of Man lies, "Na Renna" on Wigtownshire, "Gallgaidelaib" on north Ayrshire, "Cenn Tire" on Kintrye, "Airir Gaidel" on Lorne, and "Innse Gall" on Islay and adjacent islands

Here's the visible caption: "A map of the Norse–Gaelic zone, with region names as described in the sources of the period; Gallgaidelaib is the word Galloway, Airir Gaidel is modern Argyll, Cenn Tire is Kintyre, Innse Gall is the Hebrides, Na Renna is Wigtownshire, and Mann is the Isle of Man."

Is that out of balance? Tony (talk) 08:58, 5 August 2009 (UTC)

Er, where's the pic and the article to which all this refers? --Philcha (talk) 09:19, 5 August 2009 (UTC)

Sorry, it's the map towards the top of Donnchadh, Earl of Carrick. The map looks larger today, and doesn't sit well in relation to the surrounding text. I suppose if you squint you can read the text now, but the in-pic title is larger than life (and is missing "in"). Not the most successful map I've ever seen on WP. Tony (talk) 10:12, 5 August 2009 (UTC)

Agree about the map quality. The alt text and caption were both suboptimal, as they repeated each other and the caption unnecessarily repeated text that's clearly visible in the map. I changed it to so that the alt text is '"North-West Britain the mid-11th century". Hiberno–Norse regions and kingdoms outside Ireland are on the west coast of Britain and range from the area opposite the the isle of Mann, north through Na Renna, Gallgaidelaib, Cenn Tire, and Airir Gaidel, with the Innse Gall islands off the northwest coast.' and the caption is 'In this map, region names are as described in the sources of the period; Gallgaidelaib is the word Galloway, Airir Gaidel is modern Argyll, Cenn Tire is Kintyre, Innse Gall is the Hebrides, Na Renna is Wigtownshire, and Mann is the Isle of Man.' No doubt it could be tightened further. Eubulides (talk) 18:17, 6 August 2009 (UTC)

Linking in quotes

My attention's just been drawn to this:

Unless there is a good reason to do so, Wikipedia avoids linking from within quotes, which may clutter the quotation, violate the principle of leaving quotations unchanged, and mislead or confuse the reader."

I disagree that wikilinks clutter, violate a principle, mislead or confuse. Indeed, they do the opposite: they enlighten and help the reader, who will obviously be aware that the person quoted wasn't speaking in wikimarkup. If it is correct that wikilinks clutter, mislead and confuse, we should all give up, because that's how this encyclopedia works. --Dweller (talk) 13:40, 4 August 2009 (UTC)

Wikilinks are part of the genius of wikis. However, WP in particular holds the sanctity of directly quoted material in high regard. This has been argued before here a number of times. Problems arise because linking an item within someone else's text assumes that they endorsed the linked article. Linked articles can also change over time, with unfortunate, unintended consequences for the interpretation of the quotation. Tony (talk) 13:53, 4 August 2009 (UTC)

No wonder it's been brought up before - your reply makes far more sense than the rot that's currently in the MOS as justification. It should be changed. Your arguments hold water, although I'm still not 100% convinced. Would reasonable people really assume the author endorsing argument? And the changes over time argument applies to every single wikilink in the whole cyclopedia - but we don't stop ourselves from doing it.

Here's a practical example: ([10]) The new version loses useful wikilinks for terms like dorsal fin and River Nene which won't be repeated outside of the quotes. I think the reader loses out substantially. --Dweller (talk) 14:05, 4 August 2009 (UTC)

Wow, that is an eccentric article! The information about this unusual situation kind of leaks out as you hunt for it. I think a kinder lead would be good. Lots of things need fixing, apart from the link-in-quotation issue.

The more important links could easily be either (1) put in the "See also" section—ideal for this purpose, although the reader won't know the links are there until the end of the article; or (2) mentioned in the vicinity outside the quotes. Or not linked at all, like "anglers", which is a dictionary-type word. Let me know if you like it now. Tony (talk) 14:42, 4 August 2009 (UTC)

Thanks, I'll take a peek. I listed the terms that I thought needed to be in the text, but would be unlikely to be repeated, so didn't mention angling or common carp. I'll take a look at your version. I enjoyed writing it - I don't often write outside of football and cricket, so it made a nice change. --Dweller (talk) 15:05, 4 August 2009 (UTC)

I think the wriggle-room in the current MOS ("Unless there is a good reason to do so") means that dorsal fin and River Nene can and should be wikilinked in the quotes. But not the other words. But you guys really need to reword the justification. --Dweller (talk) 15:11, 4 August 2009 (UTC)

I've sussed this by adding material, without quotes and including wikilinks to the Lead, but I only had the luxury of doing this because the Lead was short and the article was low on other Lead-worthy material. I haven't a clue how I'd do it for a single reference to a technical term in a quote in a massive article like Roman Catholic Church for example, other than by using the exclusion built into the MOS currently, that there's a good reason. --Dweller (talk) 15:28, 4 August 2009 (UTC)

Recent changes to the "Possessives" section

the major changes regarding possible correct forms of possessives of nouns ending in a single s don't seem like an improvement to me: what's now presented as a third option is not clarified well, and i have serious doubts about the assertion that it is "the most commonly used" (which i have now removed). can we please revert to the previous version of this section and discuss any proposed changes? thanks Sssoul (talk) 05:39, 6 August 2009 (UTC)

It may not be obvious to you why changes were urgent in that section, Sssoul. But all can be explained, and will be as required. I had sought to made minimal and obvious changes, but there is a great of confusion about possessives in English, and our guideline was not free of them. Nor are most WP editors, nor are most MOS editors, nor are most published style guides. It's all quite tricky.

Of course if all the changes I made to that section are controversial, or likely not to reflect consensus, then they should all be reverted until all have been discussed. I acquiesce quite happily in your reversion of the recommendation that I added; I am confident enough that it will be found acceptable after analysis and discussion.

The section as it stood was incomplete and aberrant. It is simply not true that there are two main bodies of practice, each taking an extreme view. In fact, while that was said, other points were made that were inconsistent with that dichotomous view. I am surprised, Sssoul, that you think the third option that I added is not explicated well; and I am surprised that you have serious doubts that it is "the most commonly used". I can assure you, from a long study of style guides major and minor, and of practice from many publishers, that most adopt some version of that compromise position.

Anyway, let's do some analysis. (As a preliminary, it might best if editors wanting to participate read the English-language sections of the article Apostrophe, which surveys the field in great detail.)

Here is the section as it stood, before I amended it:

And the section after my editing (before Sssoul's removal of the recommendation that I added, and with left parenthesis now placed properly):

Here's a good place to start in considering these two versions. Suppose an editor comes to MOS wondering how to manage the four possessives in this sentence:

Sentence A. These are Doris'[s] copies of Morris'[s] books on Socrates'[s] and Descartes'[s] philosophies.

(Rewording would just be an evasion, and is to be thought unavailable.)

Question 1: What forms should MOS recommend for the whole of Sentence A?

Question 2: Why?

Question 3: How well and how clearly does the unmodified guideline settle things for the editor? (Explain in detail.)

Question 4: How well and how clearly does the guideline with modifications settle things for the editor? (Explain in detail.)

I suggest that editors offer their answers, below. For myself, I cannot give good answers regarding the earlier version; but I can for the modified version.

Please post after this contribution.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 06:17, 6 August 2009 (UTC)

... why is rewording "just an evasion and to be thought unavailable"?? i don't see any value in using implausible examples. (for the record, i don't consider "Illinois's legislature" a felicitous example either, since one would normally talk about the Illinois [state] legislature .)

i find the explanation of Option 3 far less clear than the previous concise (and true) note that some people (and some styleguides) consider it dependent on pronunciation. but a] since other people (and styleguides) do not view it as dependent on pronunciation, what are the grounds for recommending that as the "most commonly used" option? and b] how does one determine whose pronunciation "counts"? (by the way, in the old version as well, examples of pronunciation should use IPA - simply spelling them doesn't clarify anything.)

it's also thoroughly unclear how your proposed Option 3 relates to the principle of consistency within an article - until further notice, it seems like you're recommending that consistency be abandoned in favour of someone's ideas of pronunciation. which is not a helpful guideline. Sssoul (talk) 08:25, 6 August 2009 (UTC)

Sssoul, I am sorry that you do not grasp the value of the "implausible example" I propose as a starting point. Of course I could have proposed something more "lifelike", but it would have been much longer and far less efficient. Concerning implausible examples generally, note that they are purified "laboratory specimens" that help us to approach problems rationally and scientifically. Apart from that, all sorts of oddities really do turn up, and often you can't simply reword. Sometimes you need to represent a speech in written form, and you must choose the punctuation without changing the wording.

I designed the example with great care, to elucidate the differences in the two versions of the guideline: along with the questions that I then put forward. It is unfortunate that you did not engage with this exercise. Have you read the sections of Apostrophe that are relevant to our guideline?

For the rest, it is irrelevant that you deem Illinois's legislature infelicitous as an example. First, it is present in both versions anyway; second, it or something similar to it could easily turn up (Arkansas specifically legislated for the form Arkansas's, because the question did come up all the time); third, it represents a whole class of English words ending in silent s that turn up in our articles – distinct from cases like Descartes'[s]. You prefer the way pronunciation is dealt with in the unmodified version? Well, if you worked through the task that I recommend above, you might see why it is seriously inadequate. Both versions call for consistency; but with the unmodified version, consistency is undefined, since the recommendations are scattered illogically, with contradictions and avoidance of the very cases that those consulting MOS will want guidance with. Far from being infelicitous, they are the very cases that test the robustness of our guidelines. We need to know what to say about Illinois'[s], Doris'[s], Morris'[s], Socrates'[s]; and we need to have guidelines that show what our recommendations are. We cannot (and should not) prescribe every detail: no style guide attempts that for all cases that might turn up; but we do need to be comprehensive and decisive in laying out principles. Finally, IPA pronunciations are a red herring in this context. We simply appeal to what editors take to be the best pronunciation for the possessive of James. If they say James's, they can confidently write that; if they say James', then they can write that. If their understanding of the pronunciation happens to be questioned, the matter can be resolved by discussion. That sort of simplicity and clarity is the best we can hope for!

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 11:06, 6 August 2009 (UTC)

(outdent) if simplicity and clarity are the priorities, the previous version was simpler and clearer: there are two correct/accepted forms - and also differing views about whether or not pronunciation has anything to do with it - which means that in Wikipedia articles, there's no reason to change from one correct form to the other, except to maintain consistency within an article. changing that to a recommendation that the choice of form should be based on one's preferred pronunciation is a very major change, which calls for discussion and consensus, so i hope other editors will state their views. Sssoul (talk) 11:57, 6 August 2009 (UTC)

I think I like Noetica's amended text. However, may I make a plea that bold face not be scattered about? If anything, I'd make the pre-colon opening of each of the three bullets bold, but nothing else. Tony (talk) 12:12, 6 August 2009 (UTC)

Sure, Tony. I tried to salvage as much as I could of the earlier version, so I retained that highlighting. Of course formatting can be improved – and other details too.

With respect Sssoul, all that has been demonstrated is that you have not understood either version of the guideline: neither the way it was, nor my modified version. This may suggest a need for further clarification. That I concede!

If the previous version was "simpler and clearer" as you assert, it remains illogical, indeterminate, and therefore an inadequate guideline. In particular, it recommends consistency but fails to show what would count as consistent! Is an article consistent if it has both Socrates's and James'? That version does not give an answer; the version I put forward does.

You ignore my evidence and my arguments, and my suggestion that you read the highly relevant material at Apostrophe, and my specific analytical points above, and the challenge that I construct above (to demonstrate the differences in the two versions). I have laboured long to address all that you say, and I can help you no more. Indeed, let's see what others have to say. (I cannot do any more here right now, since I have work to do in the real world.)

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 12:23, 6 August 2009 (UTC)

peace, okay, Noetica? the fact that i'm trying to keep my replies brief doesn't mean i'm ignoring your points. my main point is simply these changes need to be discussed - by more than just the two of us - and whatever is decided on needs to be phrased clearly. thanks for conceding that! Sssoul (talk) 13:08, 6 August 2009 (UTC)

I consider the original version clearer. We should attempt to explain the choice between 's and the single apostrophe within the confines of their respective bullets, rather than presenting the information as a third "practice". Do not construe this preference as an endorsement, though – the original does need work, and does not read well. It's the basic structure that is superior. Be aware that this is merely a cursory opinion given whilst skimming through the MoS and its talk page. —Anonymous Dissident^Talk 12:39, 6 August 2009 (UTC)

Very briefly: AD, that's part of the problem. On a superficial reading the earlier version appears to be OK. But analysis shows that it fails to give determinate guidance, exactly where guidance is needed. And it contradicts itself. If people would read the points I make above, and take the test that I propose, they would see how.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 12:49, 6 August 2009 (UTC)

I see that the old version fails in effectively instructing the reader in when to use the apostrophe-s and when to use the apostrophe; this concession is (intendedly) implicit in my first comment. My point is that your layout creates a problem in removing a problem – that is, it introduces a bullet structure that is not intuitive (option to use 's, option to use single apostrophe, explanation of the choice) for the sake of clarifying the disparity. Tests aside, I think we should work on giving the explanations within a two-bullet layout, because it simply makes better sense; two options: two bullets. To give due credence to your point of view, though, I will be sure to return in a few hours to analyse your comments more thoroughly and to take the test of which you speak. —Anonymous Dissident^Talk 13:16, 6 August 2009 (UTC)

There seem to be two issues with Noetica's changes. 1. Noetica altered the wording. 2. Noetica added a third option for possessives where only two had been before. The second is more important. Is this third option used in the English language? Sure. The question is whether or not it should be used here. The purpose of the MoS is not to describe what people do elsewhere; it is to tell Wikipedia editors what to do here. I consider this to be the sort of change that is substantive enough to merit discussion, if not ahead of time, then now.

I would also add that, with regard to intra-article consistency, it is my understanding, it is the principle that must be consistent, not the appearance of the punctuated material. Otherwise, the American system would be the only acceptable way to deal with quotation marks on Wikipedia (though it does make things look neater and more professional, heh heh). Therefore idea that the third offered option is not consistent should not, alone, be used to discredit it. Darkfrog24 (talk) 12:46, 6 August 2009 (UTC)

Again very briefly, Darkfrog: yes, I did transparently alter what is demonstrably a poor guideline. Practice with possessives, here and everywhere, is complex and subject to exceptions. I happily accept reversion (for now) of the recommendation that I put in, but a close reading of the versions and the discussion above will show that what it replaces is very poor. Especially, I stress yet again, there is no point calling for consistency if we don't say what consistency would amount to!

Please read those parts of Apostrophe; please take the challenge I propose above. I suggest a definite procedure. It might be useful if some editors would give that carefully designed procedure a try.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 12:57, 6 August 2009 (UTC)

... by "that carefully designed procedure", do you mean the sentence about Doris, Morris, et al? my principles for possessives of nouns ending in s cope with that one just fine - but that doesn't mean it would be appropriate for me - or the MoS - to impose my principles on Wikipedia articles in which another correct/acceptable standard is used consistently. (as for what "consistency" means: yes, there is a school of thought that would support "James's portrait of Euripedes' wife", but within one article we should not have both "James's portrait" and "James' portrait".) Sssoul (talk) 13:30, 6 August 2009 (UTC)

Probable misspelling: "Pluralis" instead of "plurals"

Hello,

In Sec 4 - "Acronyms and abbreviations", Plural and possessive forms, "... other nouns, become _plurals_ by adding ...", the word "plurals" has been misspelt as "pluralis". Please verify and correct if this observation is accurate.

Arunsreelalan (talk) 07:20, 6 August 2009 (UTC)

Thanks A. All fixed now.–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 07:31, 6 August 2009 (UTC)

Full Stops in Post Nominals

All,

Could we use full stops after post nominals such as knighthoods etc. (eg. Horatio Nelson K.B. instead of Horatio Nelso KB). This would help indicate that there is more than one word in the post nominal (eg. O.B.E. (three words) instead of OBE (one word)). However, with titles from universities the common version could still be used (dPhil and not d.Phil. etc.).

Please discuss and share your opinions.

With compliments.

DAFMM (talk), 6th August 2009.

What would be the advantage of so indicating? Barnabypage (talk) 18:05, 6 August 2009 (UTC)

It's pretty standard these days to omit the full stops; see, for example, the British monarchy official offical website. I don't think the MOS should legislate full stops here, when even the Queen omits them nowadays. Eubulides (talk) 18:17, 6 August 2009 (UTC)