Wikipedia talk:Manual of Style/Archive 105

Archive 100

←

Archive 103

Archive 104

Archive 105

Archive 106

Archive 107

→

Archive 110

Identity

"A transgender, transsexual or genderqueer person's latest preference of name and pronoun should be adopted when referring to any phase of that person's life, unless this usage is overridden by that person's own expressed preference. Nevertheless, avoid confusing or seemingly logically impossible text that could result from pronoun usage (e.g., she fathered her first child). " - This goes against the factual encyclopaedic nature of Wikipedia, although popular western media currently promotes the acceptance of transgender and transsexuals as belonging to their chosen rather than natural gender, this is not a globally supported position and creates an opinion bias. —Preceding unsigned comment added by 210.8.121.116 (talk) 01:35, 28 October 2008 (UTC)

I just find it retarded that we're shoehorning political correctness into biological facts. If you're born with a penis between your legs, you're a man and you're a he. If you're born with a vagina between your legs, you're a woman and you're a she. Being post-op doesn't turn a man into a woman or vice-versa, you only have their appearance. These are facts, not opinions, and they have nothing to do with opinions. "Original genders" should be used rather, nonsensical pronoun usage being another of the reasons. I'm about as liberal as it gets, but an encyclopedia referring to men and woman (whether transsexuals, post-op, genderqueer, etc. or not) as women and men is pure and simple POV-pushing. Headbomb {ταλκ – WP Physics: PotW} 05:41, 28 October 2008 (UTC)

Actually both biological and linguistic gender is quite a lot more complex than whether or not one has a penis or not, not to mention the identity issue which is even more complex. For example some people are born with neither penis nor vagina and doctors chose which gender to make them them and if a ship can be a she then why can't a transgendered ex-male? The only sane guideline is to refer to people the way in which they prefer, particularly for example within biographies of living persons that should treat all people with respect. I fail to see the specific POV that is being pushed by calling someone who has chosen to become a woman "she" other than of course the view point of respecting peoples rights and feelings. ·Maunus·ƛ· 05:50, 28 October 2008 (UTC)

Fine, instead of penis, use the presence of a Y chromosome to determine whether or not someone is male or female. Headbomb {ταλκ – WP Physics: PotW} 06:09, 28 October 2008 (UTC)

And what do call people for whom we have no chromosomal data ()probably the great majority? Or people with downs syndrome or other chromosomal disorders?·Maunus·ƛ· 06:15, 28 October 2008 (UTC)

Your argument only works if we assume that linguistic gender maps directly to biological sex, which just isn't the case. What pronoun someone uses depends on what gender identity they associate with the subject (not what they know about their chromosomes) and since Wikipedia is supposed to be neutral and can't have an opinion of its own, it has to mirror someone else's. Who should that be, if not the person in question? Ilkali (talk) 21:15, 28 October 2008 (UTC)

Why are we endeavoring to decide these issues? We should do what we do elsewhere: use what our sources use, with greater weight on more recent sources. By and large, this will be what the subjects themselves choose; where it is not, there is something unusual happening, which should be made clear to the reader anyway. Septentrionalis PMAnderson 16:08, 28 October 2008 (UTC)

I agree that "gender depends on chromosome type alone" is just one POV. Gender#Gender_taxonomy lists 9 different potential criteria. Certainly there are people that will complain about "political correctness" POV if anything other than birth sex (if there is a clear one) is used to refer to someone, and other people who will complain about being insulting and holding anti-transgender POV if anything other than what the person chooses to be called is used. I think most professional news outlets these days simply go by whatever gender the public persona has. If a transsexual has legally changed their name and is dressing and living as a woman, they use "she" for the present persona and "he" when talking about the pre-transition persona. A casual transvestite might be a "he" when going to work during the day, but "she" when dressed up at night. Likewise for fictional characters - Peter Pan is referred to as "he", even if a woman is playing the part. I don't think this practice is necessarily an endorsement of political correctness, it's mostly a "looks like a duck, quacks like a duck" philosophy. -- Beland (talk) 17:38, 6 November 2008 (UTC)

National varieties of English

I understand the reasons for and agree with the philosophy behind the MoS approach to WP:ENGVAR, but suggest an addition. Where a topic is itself a word that is spelt differently in different varieties of English, I propose that the MoS be updated to specify that alternative spellings be given alongside the first instance of the word in the article. Many people will be guided by the spelling used in Wikipedia, and will not necessarily realise that it may be spelt incorrectly for their region—particularly for medical, technical or otherwise specialised terms. Bleeding, for example, does this well in relation to 'haemorrhage' and 'hemorrhage'. Hematochezia, however, despite the fact that 'haematochezia' redirects to it, makes no mention of the alternative spelling and may lead people in Britain and Australia astray.—Zoe Ocean 10:50, 29 October 2008 (UTC) —Preceding unsigned comment added by Zoe Buchanan (talk • contribs)

That does seem like a good idea. -- Beland (talk) 17:55, 6 November 2008 (UTC)

The guideline already says “If the subject of the page has a common abbreviation or more than one name, the abbreviation (in parenthesis) and each additional name should be in boldface on its first appearance”. Seems more than enough. —Michael Z. 2008-11-06 18:03 z

"More than one name" is not the same as "more than one spelling". Roger (talk) 18:29, 6 November 2008 (UTC)

"See also" sections in categories

The other day I ran into a "See also" section in a category, linking to a series of articles. I'd never seen that before, and, as it was ugly, a POV-magnet, and undermined the whole purpose of categories, I removed it. However, the person who added the "See also" section, User:Timeshifter reverted me, and insisted it was common practice, found in many categories. Having never seen that before in 4.5 years of editing Wikipedia, I asked him to show me examples, but he refused, repeatedly. I then investigated, and discovered that "See also" sections did exist in about 30 categories; all added in the last week by User:Timeshifter. I've removed these additions from the categories for now, and brought the issue here for further discussion. Thoughts? Jayjg ^(talk) 00:45, 6 November 2008 (UTC)

The "see also" sections I found were not linking to a series of articles, but to a series of categories. I think that in some cases it may be helpful to point users toward other categories of interest that are related but are neither a parent nor a daughter of the category that is being viewed. I sometimes see this practice in the Commons, but not much on Wikipedia. --Itub (talk) 11:09, 6 November 2008 (UTC)

The "see also" should be a semi-related cat (as noted above), or as links as part of the category introduction. But I agree that we shouldn't be using "see also" for overkill.

One thing in particular is to prevent duplicate (and incorrect) categorisation. Sometimes people will categorise something not realising that there is a more specific category. It's a hindrance to navigation (the point of categories.) The "see also" helps prevent that.

That said, in looking at some of the "see also" sections that you've removed, it looks like some of them could possibly have been apparopriately categorised into one or more parent cats. - jc37 11:32, 6 November 2008 (UTC)

See also Template:CatRel and Template:Cat see also. - jc37 15:57, 7 November 2008 (UTC)

MOS or video game?

What's the point of hiding parts of the MOS and then turning reading and editing them into a treasure hunt!? In the WP:MOS#First sentences section:

1. I click the section “edit” link, but there's nothing to edit, except some opaque and unfamiliar code
2. There are puzzling grey bars in the MOS section, with no indication of their function or content
3. But the grey bars have instructions on them, saying “Click "show" to display more content information.” What is “content information?” Why does clicking “show” in this sentence do nothing?
4. I see there is another tiny label on the grey bar which says “[show]”—when I click it I see that secret MOS guidelines were hidden—why, to save paper?

This is a terrible interface for an unneeded function. We don't allow such obstruction to readers and editors in articles, we don't recommend it in the MOS, so we shouldn't degrade the MOS by incorporating this. —Michael Z. 2008-11-06 18:30 z

I thought this was the modularize the text so that the same singly edited text would appear in the main manual of style and in Wikipedia:Lead section, but apparently not. —Centrx→talk • 18:44, 9 November 2008 (UTC)

I understand the intent, but the implementation reduces readability, and is impenetrable for editing (I haven't even given any thought to where to discuss changes to a guideline which appears in three places and has a fourth talk page). A simple link accomplishes exactly the same thing without the complications—and a bit more work could add a useful summary which could remain stable even if the details of the source guideline change. —Michael Z. 2008-11-09 20:14 z

You're thinking of Wikipedia:Accessibility TT lead section, which is used elsewhere, but not here.[yes it is. man that is an ugly implementation.] I'm not sure how successful that experiment is.

See also the thread I'm about to copy below, concerning the proliferation of hidden sections. -- Quiddity (talk) 20:55, 9 November 2008 (UTC)

It appears to me that there are two separate issues here: First, whether to use transclude text to coordinate information that appears on more than one MOS page. Second, whether to use the show/hide option within transclude text. The second issue is discussed in the new #When to use hidden/collapsible sections below.
Turning to the first issue, I am a proponent of using transclude text. It is easy enough to say "have a central location and link to it," but the reality is that folks edit the page they are on regardless of whether there is a link. The result: Balkanization. Using transclude text solves that problem. Butwhatdoiknow (talk) 22:29, 9 November 2008 (UTC)

Locking the page would also solve this “problem” in the same way—by making it impossible for the average user to edit the page. Seriously—I tried to edit the section linked above, and I could not. I'm an administrator, and editor for four years. I can't adequately express how bad a “solution” for anything this is.

If you are a serious proponent, then please, let's examine what this does. Let's say I wanted to edit the quotation in the guideline which says “"Homer Simpson is a fictional character in the television series..."”, while I'm looking at Wikipedia:MOS#First sentences. The normal procedure would be this:

1. Click the “[Edit]” link by the heading
2. Edit the text and click the “(Save page)” button

In comparison, here's what I have to do now:

1. Click the “[Edit]” link by the heading
2. See that the edit text says “{{:Wikipedia:Lead section TT first sentence content}}{{:Wikipedia:Lead section TT first sentence format}}<!-- for more about this edit see WP:Transclude text -->”. I actually cut-and-pasted three page names from this, and didn't see my edit text there either. WTF?
3. Post a question here on the talk page
4. Wait at least three days (that's how long it's been so far, and no one has yet posted the answer)
5. What now?

Hm, 5 steps instead of 2, and it's still not done. If you think I'm doing something wrong here, then please outline the steps a novice editor would reasonably take to edit this section. —Michael Z. 2008-11-10 00:01 z

You lost me at step three. It seems to me that step three would be go to the transclude text page you want to edit, step four would be click the “[Edit]” link by the TRANSCLUDE TEXT heading, and step five would be make the change. See Wikipedia talk:Transclude text#Oy!.

A little more cumbersome? Perhaps. But the transclude text approach, if one allows oneself to become accustomed to it, seems to be a reasonable middle ground between uncontrolled Balkanization (with the result that pages conflict with one another) and locking MOS pages. Is it your position that style pages disagreeing with each other isn't a problem? If so, please take a look at Wikipedia:WikiProject Manual of Style Butwhatdoiknow (talk) 00:52, 10 November 2008 (UTC)

The page I want to edit is WP:MOS, and the heading is “First sentences”. I didn't see any “TRANSCLUDE TEXT” heading. What is step 3, for someone who doesn't know the location of this secret page?

Seriously, I looked at the three pages mentioned in the wikitext by cutting and pasting them, and they didn't give me any clue. How do I edit this page? —Michael Z. 2008-11-10 06:14 z

Yikes, found it. It's buried in the midst of some truly ghastly tangle. I'm going to put the documentation in a proper documentation section (and probably break something). Wikipedia:Lead section TT first sentence content and Wikipedia:Lead section TT first sentence format.

I think I even managed to extract the offending hiding code. (Boldly, after noticing the note here).

I'll see you in the thread about hiding below :) -- Quiddity (talk) 08:43, 10 November 2008 (UTC)

Weird. I can see that you've removed the show/hide from the TT pages but they still appear on my MOS page. Twilight zone? Butwhatdoiknow (talk) 13:57, 10 November 2008 (UTC)

It needed a null edit. --NE2 14:02, 10 November 2008 (UTC)

"If the subject of the page has a common abbreviation or more than one name, the abbreviation (in parenthesis) and each additional name should be in boldface on its first appearance."

How do we define what a 'common' abbreviation is? I've seen more than enough examples of these that appear to be made up on the spot. --neon white talk 15:18, 9 November 2008 (UTC)

If the abbreviation is listed in a reputable dictionary, or in the case of an organization, used on the organization's web site, I think that would suffice. --Gerry Ashton (talk) 15:28, 9 November 2008 (UTC)

Thank you. I think the issue is with the idea of 'common'. It often seems to leads to original research with editors point to instances of usage to try and assert widespread usage, where as, if we were to follow the rules as WP:NEO, it would be a requirement to "cite reliable secondary sources such as books and papers about the term—not books and papers that use the term". --neon white talk 12:30, 10 November 2008 (UTC)

Wikipedia:Avoid neologisms does not clearly define its scope. From reading it, however, it is obvious that it cannot apply to proper names and abbreviations for proper names, because the kind of sources recommended by the neologism guideline, like dictionaries, provide very limited coverage of proper names. If we tried to apply the neologism guideline to proper names there would be many noteworthy people, places, and companies that we could not write about. --Gerry Ashton (talk) 17:32, 10 November 2008 (UTC)

I think you're misunderstandiung the point, this isn't about the notability of subject or the existance of articles on them. It's about the sourcing of alternate names and abreviations for a subject. It has to be sourced somehow or it's original research. --neon white talk 02:05, 11 November 2008 (UTC)

When to use hidden/collapsible sections

copied from the VPP archive

We really need some recommendations about when/when not to use the "hidden" code, outside of footer-navboxes.

See:

• Template talk:Hidden#Within article text
• Wikipedia talk:NavFrame#Accessibility of collapsed sections
• Wikipedia talk:Accessibility/Archive 1#Hide/show buttons?
• the discussions about the entirely-hidden-infobox experiment at Ponte Vecchio
• people using it whimsically in vertical-navboxes, such as {{Alpha Phi Alpha articles}} and {{Video RPG}}

Questions:

1. Are there any more links to relevant discussions about hidden/collapsible sections?
2. The various hiding-templates often get used to hide content that some editors simply cannot agree on whether to display or not (see the "influences" sections in some Writer-infoboxes (e.g. William Gibson), the Ponte Vecchio experiment, the vertical navboxes linked above, etc). Is this a usage we want to encourage or discourage?
3. What code should be used? Wikipedia:NavFrame says it is deprecated, but it is widely used by all of the hiding templates ({{Hidden}}, {{Show}}, {{Hidden begin}}, {{HiddenMultiLine}}, {{Hidden section top}}, {{Hidden infoboxes}}) none of which mention deprecation.
4. Any suggestions as to what we should be using for guidelines? Or where we should be discussing it? -- Quiddity (talk) 04:42, 1 October 2008 (UTC)

My general intuition is that hidden/collapsable sections should never be used except for navigation elements. The reason is to facilitate moving articles to print form - everything has to be fully expanded in print. Dcoetzee 20:47, 5 October 2008 (UTC)

I agree, while some dynamic content in articles would be nice, there's generally no reason to show/hide article text. Mr.Z-man 21:33, 5 October 2008 (UTC)

I don't know if this is within the scope of the question, but I think it's legitimate to hide the solutions of "puzzle" boxes, e.g. chess diagrams or colour vision tests. -- Philcha (talk) 21:55, 5 October 2008 (UTC)

Until we have a way to show collapsed sections on non-standard browsers (eg text-to-speech) and for printing, collapsed sections should be avoided. --MASEM 01:28, 6 October 2008 (UTC)

CSS can define separate rules for display and printing, so that's an internal technical matter. In the case I raised, it's all done via a template, so if someone defines a CSS class "hide when displayed, show when printed" it can be applied very easily.

I've never used a text-to-speech reader. Do these have options to speak hidden text? If not, that sounds like a deficiency that the suppliers should resolve.

In any case the cases I cited are chess diagrams and colour vision tests, which would be pretty unintelligible to text-to-speech readers. -- Philcha (talk) 08:44, 6 October 2008 (UTC)

I would hope (though I'm not sure) that screen readers would just act as a browser with JS disabled (where all the text should show by default), though I'm not sure. Printing is still an issue though, AKAIK. Mr.Z-man 16:28, 6 October 2008 (UTC)

Screen readers should be fine (as collapsing is done by JS), but that's why printing fails; I asked this before and it's not just changing the media type for CSS; IIRC, JS will react independent of the CSS media setting, so if tables start collapsed on a page, they will stay collapsed when the page is parsed for printing. We should be avoiding any collapsed media until this can be (if ever) resolved, despite the fact it can really help a page with lots of secondary information. --MASEM 16:32, 6 October 2008 (UTC)

Thanks for the responses. I'm still not certain what the consensus is though; A few specific questions:

For hiding things like:

• the "influences" sections in biographical-infoboxes as a standard practice (this information is not always duplicated within the article-text)
• anything, just to avoid argument (entirely hidden infobox at Ponte Vecchio)
• anything, to save random space (hidden timeline at Elizabeth Smart#Legal proceedings (now fixed))

are we recommending against these practices? How strongly?

To which guideline/policy page would we add any sentences related to this? (and discuss further there)

Besides the printing and usability problems, there are isolated text overlap problems (e.g. Ant infobox).

I'm also concerned that some readers will completely tune-out [show] links, because at a glance they look just like [edit] links, down the right edge of the page. -- Quiddity (talk) 01:54, 10 October 2008 (UTC)

I don't understand the question: we already have a guideline (and I note that none of the pages linked above considered that it's already dealt with at MoS) ... do people just forget that we have a Manual of Style when they're off discussing Wiki-wide style issues on individual template pages?

• Wikipedia:MOS#Scrolling_lists

Scrolling lists and boxes that toggle text display between hide and show are acceptable in infoboxes and navigation boxes, but should never be used in the article prose or references, because of issues with readability, accessibility, printing, and site mirroring. Additionally, such lists and boxes may not display properly in all web browsers.

Agree with Mr. Z-man, already addressed at MoS, which is where the discussion should occur anyway. SandyGeorgia (Talk) 04:49, 10 October 2008 (UTC)

Thank you! That's what I was looking for. It took 3 weeks to get that answer! And for the record, no, I haven't had time to read/reread all 200+ guideline pages recently...

On further analysis, it appears that section did not mention hidden-text, until you added it on Aug 27 2008. Please don't be condescending just because we don't all watchlist & scrutinize the same pages that you do... :)

I will transfer this thread to that talkpage in a few days. -- Quiddity (talk) 18:37, 10 October 2008 (UTC)

end of section copied

"Scrolling lists" does not bring to my mind "hidden/collapsible sections". This information should be easier to find without continually reading, as you say, all 200+ guideline pages. —Mattisse (Talk) 13:46, 10 November 2008 (UTC)

Hidden code - section break

I've copied this here to remind/reinforce the consensus that these really shouldn't be used, and to get all the relevant links in one place. The hiding code is still popping up all over the place (See two threads up for a start...).

Perhaps we could change the MoS subsection title from Wikipedia:MOS#Scrolling lists to Wikipedia:MOS#Scrolling lists and hidden sections, or similar? Other comments welcome. -- Quiddity (talk) 21:01, 9 November 2008 (UTC)

Agree that MoS subsection title should be changed. I went over there looking for "hidden sections" and could not find it. Had to come back here and find link to Wikipedia:MOS#Scrolling lists; I never would have guessed that "hidden sections", or "boxes that toggle text display between hide and show" as it is called there, would be under Scrolling lists. If that information were not here, I never would have found it. —Mattisse (Talk) 13:40, 10 November 2008 (UTC)

I would hope (though I'm not sure) that screen readers would just act as a browser with JS disabled (where all the text should show by default)

Some text-based web browsers do ignore JavaScript, but the most common screen reader (JAWS) actually uses MSIE to interpret the web page, so all Javascript applies and hidden text is hidden (JAWS also ignores style sheets aimed at screen readers, contrary to the standards).

. . . the cases I cited are chess diagrams and colour vision tests, which would be pretty unintelligible to text-to-speech readers

Unless we are experts in the subject, we shouldn't make any assumptions about how differently-abled people access web sites. For example, the majority of “blind” people have partial vision, so some may make use of a screen reader to supplement limited vision. Real example: “When exploring CSS, it was the totally-blind kids who insisted on learning how to make words in different colours.”[1]

Re colour vision tests, they're images that are meant to be fairly hard to read, so that only people with near 100% in the relevant aspect of colour vision will see the "content". If there's a colour vision test that evaluates colour vision accurately and is also solvable by users with 100% colour vision but poor visual acuity, you might like to post it at Talk:Color blindness.

Re chess positions and other puzzles, hiding the solution increases readers' enjoyment of these by not telling the answer until they've had time to try solving them.

If JAWS hides such solutions, I would expect it also to reveal them when the user "clicks" (or JAWS equivalent), the "show" link.

Chess positions are currently represented by a table (8x8) in which the cells contain images of chess pieces. They are generated by templates, so if someone finds a way to present chess positions that is suitable for the different needs of "normal"-sighted users and those who use screen-readers, changing the templates would apply the upgrade to all diagrams. In that case users of screen-readers who are also keen chess players would benefit from the opportunity to have a go at these "puzzles" before being shown the solution.

I do not think accessibility should ever be used as an excuse for eliminating facilities that are useful for "normal" users. --Philcha (talk) 11:58, 10 November 2008 (UTC)

anything, to save random space

Is Wikipedia running out of space now? Would someone carefully describe this problem, so we can evaluate this “solution” for it?

Thanks for pointing out that the MOS recommends against hiding parts of the page. And yes, and can someone please remove the hidden sections from this very MOS, under Wikipedia:MOS#First sentences? I am not able to do so, because of another creative “solution” for a nonexistent problem (see #MOS or video game?, above). Thanks. —Michael Z. 2008-11-10 00:20 z

I suspect that you are, in fact, able to make the change you want. See Wikipedia talk:Transclude text#Oy!. (I have already posted the change I suspect you want to make on the talk pages for TT pages that include show/hide boxes.) Butwhatdoiknow (talk) 00:41, 10 November 2008 (UTC)

No, I want to edit WP:MOS#First sentences. Still having no luck with that. —Michael Z. 2008-11-10 06:18 z

I believe I've fixed your specific situation. Now back to what we're going to do about hidden sections in general... -- Quiddity (talk) 09:10, 10 November 2008 (UTC)

See my comments on "puzzles" above. I cannot believe that MOS should be used to deprive the majority of users of features that may increase their enjoyment of articles. --Philcha (talk) 12:00, 10 November 2008 (UTC)

Even if those that use screen readers or other assisted methods of "viewing" WP pages make up <0.1% of our audience, we should strive to make sure to achieve 100% accessibility. That's not to say we shouldn't see how we can support it somehow. I'm wondering if there's a way to build that into the Mediawiki software and make a preference (that's off by default) that enables collapsable sections. This would immediately satisfy the screen readers, but we may still have problems with printing (unless we provided a different approach to that). --MASEM 15:03, 10 November 2008 (UTC)

The printing thing is easy - CSS allows separate styling for screen and print. All that's needed is for WP's techies to define and publish in a well-documented location suitable CSS class names with the screen rule set to "display:none" and the print rules set to "display:block", "display:inline", etc. (so we need 1 class for each value that would be usable in a print rule). "Well-documented" may be the tricky bit, as WP is poor at documentation.

I agree with the rest of MASEM's comment, provided that "normal" users are not deprived of facilites in the meantime. --Philcha (talk) 15:17, 10 November 2008 (UTC)

It can't work that way. WP already does have print media specific CSS, however, collapsible sections are implemented through Javascript, and thus what is collapsed when printing is called stays collapsed as the JS code is not magically called to expand sections (I asked about this a while ago to make sure). An option is to have a "Print this page" link that regenerates the page with all sections expanded, but we want to KISS and have printing through the browser's function call to do the same. And I would beg to differ about making sure the functions are still there for normal users - WP aims to be a free content encyclopedia anyone can use and edit, and any barrier that prevents this should be removed. Again, if we can figure out a way that works for all options, great, but right now there isn't one. --MASEM 15:24, 10 November 2008 (UTC)

Can you provide a link to your previous discussion of CSS and JS for hidden sections? What I described is correct for Web pages in general, although I know there are one or two tricky points in implementation.

Re "anyone can use and edit", I agree about "anyone can use", subject to not depriving the majority of users of features that may increase their enjoyment of articles. "anyone can edit" is more doubtful, as the tightening of policies like WP:N and WP:V has made the learning curve steeper. In addition there will always be more technically-knowledgable and less technical editors - I wouldn't claim to be a technical guru, but I've used my modest knowledge of (X)HTML and CSS to help other editors with layout issues, and have produced a few templates. Sometimes I get stuck and ask others with greater technical expertise in certain areas for help. It's just another aspect of collaboration. --Philcha (talk) 15:56, 10 November 2008 (UTC)

See here. It's not technically impossible, but is impossible without backend support in MediaWiki. Again, the point is that it is a nice beneficial feature for 99+% of WP's users, but that feature at the present time does prevent some content access to a small fraction. It does need to be fixed to achieve 100% usability, and until that is in place, use of collapsing sections should be avoided. (I believe, for example, a collapsed section at FAC will not pass due to this). --MASEM 16:16, 10 November 2008 (UTC)

Re printing, the discussion for which you provided a link seemed to close with the suggestion that @media print { div.NavContent, ..., ... table.collapsible tr {display:block !important} } would do the job.

Re "prevent some content access to a small fraction":

• I'm far from convinced that it would prevent access. As I said before, "show / hide" is a link, and AFAIK screen-readers and other assistive facilities are quite good at enabling users to find and activate links. I imagine they must also be quite good at informing users of changes in the visible content, otherwise AJAX-powered standard features such as "watch / unwatch" would raise accessibility problems.
• The actual puzzles to which the solutions are hidden are themselves meaningless to users who are effectively blind. You seem to be proposing that WP should force spoilers on those who can enjoy these puzzles, while providing no benefit to those who cannot because of the visual nature of the puzzles.

Please note that I am not arguing in favour of hidden sections in general, but that a specific exception should be made for puzzles which can only be presented visually. --Philcha (talk) 19:19, 10 November 2008 (UTC)

just found this thread — coincidentally I've been experimenting with templated collapsible sections (autosections) recently, and I'm looking for feedback there. (Sorry for my previous edit, which resulted from a restored Firefox session after a crash while doing a "section edit".) --Zigger «º» 12:37, 10 November 2008 (UTC)

Should Presidential Templates Comply to MoS Naming Convention?

Presently, Barack Obama's template is using his full name. There are some editors advocating that all presidential templates should use full names rather than the most common name as specified here. I would like some resolution to this. Modocc (talk) 05:16, 11 November 2008 (UTC)

This isn't a general MOS issue. I suggest you try discussing it at WikiProject U.S. Presidents. —Michael Z. 2008-11-12 22:09 z

"Similarly" in first sentences content section

Suggest that "Similarly" be removed (I found it impossible in a few minutes to think of an appropriate replacement, and it is not an active part of the policy issue discussed in the sentence). The first sentence differs from the second in that the first allows deviations from the main title to be used, the second demands a deviation in the case of disambiguation words or phrases. There is only the most tenuous connection between them: there is the -possibility- of the requirement of the second occurring within the bounds of the first, without regard to the mandate of the second. They have a shared subject, but the requirements of each as regards that subject differ. I hope I haven't done this potentially intuitively understood proposal to death with my dubious skill in constructing an argument of logic. Anarchangel (talk) 20:13, 11 November 2008 (UTC)

"By the same token"? Regardless of whether you select this or another phrase I think you can safely change "Similarly" to some more appropriate word or phrase without fear of much resistance. Butwhatdoiknow (talk) 21:00, 11 November 2008 (UTC)

Images as thumbnails

Additional views are needed at Wikipedia talk:Lists#Thumbnails instead of bullets regarding the use of thumbnails of people as bullets in a list in a city article. -- AnmaFinotera (talk · contribs) 03:39, 12 November 2008 (UTC)

More about transclude text

This is laughable. For those still trying to “improve” the way the wiki works: here's an objective description.

How to edit a page section, e.g., Wikipedia:MOS#First sentences

How Wikipedia works

How Wikipedia doesn't work

Click “[Edit]” Edit in the textarea, click “(Save page)” See your results

Click “[Edit]” Decipher “{{:Wikipedia:Lead section TT first sentence content}}<!-- To edit this text go to [[Wikipedia:Lead section TT first sentence content]]. For more about transclude text go to [[WP:Transclude text]] -->” and realize that you should copy the text Wikipedia:Lead section TT first sentence content Open a new browser window, type and paste to form the URL http://en.wiki.x.io/wiki/Wikipedia:Lead section TT first sentence content, press return Notice that 253 words of content are followed by 464 words of neatly-organized documentation. Scan the documentation until you get tired of it, then click “Edit this page” Edit in the textarea, click “(Save page)” Close the browser window, to see your results in the previous browser window. Pray you didn't make a typo, because editing this stupid Wikipedia crap is B.S.

The second version is not an improvement. Adopting it is not supported by consensus. You're welcome to propose the idea, but please remove this from the MOS. —Michael Z. 2008-11-10 18:11 z

(1) The transclude text idea has been in place since August and you are the first person to be so adamantly opposed to it. (2) You have not responded to the underlying issue of how best to coordinate MOS pages - do you have a better solution? Butwhatdoiknow (talk) 18:29, 10 November 2008 (UTC)

1) That is no indication that this arrangement is better than the usual one. How many users have actually made content edits to that section in this time? 2) Yeah, and I've mentioned this more than once. You put the text in the page of the main guideline where it belongs, and you link to from the other places, optionally with a short summary which should remain stable. —Michael Z. 2008-11-10 21:59 z

I've made it a little bit easier, by placing the ===headers=== within the transcluded text, so that if you click their [edit] links, you get taken to the correct page immediately. Still not perfect, but then neither is wikimarkup for talkpage threads... ;) -- Quiddity (talk) 19:02, 10 November 2008 (UTC)

Neat, thanks. Now to see whether it passes the "Mzajac test." Butwhatdoiknow (talk) 19:55, 10 November 2008 (UTC)

Sorry, but when a reader clicks the edit link for the “First sentences” section, he is still confronted with opaque gobbledygook.

Please don't patronizingly write “Mzajac test”. You are breaking the way Wiki pages are edited—this is a slap in the face for the average editor, and a terrible example to put in the MOS. It is completely unsuitable for normal editing, and you wouldn't get away with leaving this kind of terrible arrangement in a high-profile article for a single day. —Michael Z. 2008-11-10 21:59 z

I am sorry that you found my attempt at levity to be patronizing. I can assure you that I did not mean for the comment to come across in that light. 22:31, 10 November 2008 (UTC)

With regard to the issue at hand, transclude text has been in the high profile Manual of Style article for a couple of months now and you are the first person to argue so passionately against it. For the third time I ask: Do you have a better solution for the problem of conflicting style pages? Butwhatdoiknow (talk) 22:31, 10 November 2008 (UTC)

Well I don't feel like continuing the slap fight, so I'll paste my last response again: 2) Yeah, and I've mentioned this more than once. You put the text in the page of the main guideline where it belongs, and you link to from the other places, optionally with a short summary which should remain stable. This technique is used on tens of thousands of Wikipedia pages without screwing things up. —Michael Z. 2008-11-11 02:23 z

I find myself apologizing to you once again - sure enough, you did answer my question before. Sorry I missed that. I'm not sure what a "slap fight" is but I do agree that it appears that you and I have differing opinions regarding: (A) Whether it is realistic to expect that the short summaries you propose will actually remain stable. (I offer as evidence for my position the existence of conflicting style pages that have built up over time from the system you are championing. See also discussion beginning at Wikipedia talk:WikiProject Manual of Style#An example of a serious conflict.) (B) Whether the alternative transclude text solution is so cumbersome that it should be abandoned. (With regard to this disagreement I note that no one has jumped into our discussion to support your position that transclude text is simply unredeemable. Instead, a few folks have taken some of your criticisms regarding functionality to heart and have made improvements in the transclude text to at least partially resolve those criticisms.) Butwhatdoiknow (talk) 03:23, 11 November 2008 (UTC)

I appreciate the pros, but the con which makes this unacceptable is simply that a button labelled “edit” no longer lets someone edit. A one-step operation turns into “road closed: read this map, back up, and take a detour”. If a new feature breaks one of the basics, then it is not an improvement. —Michael Z. 2008-11-12 06:28 z

Where is this "basic" rule found? Assuming such a rule does exist, I believe that WP:WIARM applies (particularly in light of the improvements that have been made within the past few days to resolve almost all of the concerns you raised). No doubt you disagree. It appears that we are at an impasse. 16:38, 12 November 2008 (UTC)

If you absolutely insist on a citation for “this "basic" rule”, then you could read over Help:Editing, which this method subverts; it also undermines a few of the principles in WP:5: it is disruptive by greatly raising the threshold of accessibility for productive editing, and asserts article ownership by the precious few editors who are comfortable with transclusions. If this isn't painfully obvious, perhaps have a read over WP:Common sense, too. —Michael Z. 2008-11-12 17:40 z

I'm sorry but I just don't feel your pain. With the recent revisions it does not appear to me that an editor needs to be comfortable with transclusion to change the first sentence text. And the citations you have provided don't seem to say that making editing as simple as possible is so crucial to Wikipedia that slight complications in particular situations should be banned even when the result is to solve another problem. Butwhatdoiknow (talk) 18:32, 12 November 2008 (UTC)

“You don't feel my pain?”—that's exactly what I'm talking about. You are comfortable using this to deal with your own editing issues, with complete disregard for the needs of novice and average editors. Why don't you update Help:Editing with instructions for transclusions? —Michael Z. 2008-11-12 22:06 z

I respectfully disagree with your characterization of my position as being in "complete disregard for the needs of novice and average editors." In fact I (and some other, more talented editors) have recently made a number of changes to the first sentence section of this article to specifically meet the needs of novice and average editors. You appear to be completely disregarding those changes. Butwhatdoiknow (talk) 23:20, 12 November 2008 (UTC)

True enough, you have tried to mitigate the potential problems, but this is inadequate. As I pointed out, clicking the main section's “Edit” button still gives the editor a completely unexpected result, and forces him or her to read some instructions. And even this is not applicable if subsections are absent, and will break down if the subsections are renamed or removed. Even for its intended purpose, this “solution” is less useful than just leaving a link as I suggested. —Michael Z. 2008-11-12 23:30 z

I accept your apology. As to your other remarks, I believe we should proceed as you suggested below (i.e., set up a poll in the hope that it will move the discussion forward). Butwhatdoiknow (talk) 23:42, 12 November 2008 (UTC)

I have to admit, this transclusion business does make editing that section confusing. How do you accommodate those that have section editing turned off? Is the solution to that to make the "instructions" even more complex? If anything, IAR would prescribe reverting the transclusion, and quickly. --Kbdank71 17:11, 12 November 2008 (UTC)

"IAR would prescribe"? Sorry, but you lost me right there.LeadSongDog (talk) 18:31, 12 November 2008 (UTC)

Do those people need to be accommodated? It seems to me that turning off editing is something that is done by sophisticated editors. (I don't know how to do it and I'm not sure why anyone would do it.) I suspect those folks who know enough to turn off section editing can also figure out transclude text without too much difficulty. After all, the use of transclusion has been around for quite some time (see Wikipedia:Transclusion). Butwhatdoiknow (talk) 18:32, 12 November 2008 (UTC)

"My Preferences", "Editing". 2 seconds. 5 to save and refresh your cache. Fairly simple, even for unsophisticated editors who know nothing about transclusion. Regardless, though, it seems to me that making Wikipedia harder to use for most and (according to your instructions) impossible for others goes against this being a wiki. --Kbdank71 18:53, 12 November 2008 (UTC)

I'm still working on understanding the extent of the problem here. Would you please tell me why someone would spend the seven seconds to disable section editing? Butwhatdoiknow (talk) 19:45, 12 November 2008 (UTC)

Perhaps you're not understanding the right thing. Don't bother understanding why they would do it, because it's irrelevant. Understand that those that do choose to do it will be unable to edit that section. Understand that even if they can edit sections, this makes it more difficult. We should not be putting up roadblocks and detours to edit wikipedia. --Kbdank71 20:26, 12 November 2008 (UTC)

Well, without the explanation I am left to conclude that those who do it are purposefully making it difficult for themselves to edit for no good reason. I am not sure we need to be too concerned about accommodating what I imagine to be a very small group of folks who (a) are sophisticated enough to know how to turn off section editing, (b) voluntarily chose to turn it off for no good reason (other than, apparently, the challenge of making it more difficult for them to edit sections), and (c) aren't sophisticated enough to figure out how to edit trancluded text (such as templates). Butwhatdoiknow (talk) 22:01, 12 November 2008 (UTC)

There's a lot of speculation here about what certain editors would do and what they wouldn't, and obviously the respective sides' arguments are not convincing the others, because we're starting to repeat ourselves. Why don't we just hold a poll, here or at the village pump, to gauge whether consensus supports adding transclusions to pages in the Wikipedia: and Help: namespaces? —Michael Z. 2008-11-12 22:06 z

That may help us make some progress. The problem will be in reaching an agreement regarding the the phrasing of the proposal. (I don't think we can talk about transclude text without talking about the problem of conflicting style guides.) How do you suggest we work on that issue? Butwhatdoiknow (talk) 23:20, 12 November 2008 (UTC)

How about expanding the TT docs to include an explanation of the problem to be solved, a list of advantages and disadvantages, and alternatives. When this is stable, we can refer editors to the docs and let them judge for themselves—and the system can speak for itself. Also useful would be a list of places it is in use, so that we have a variety of examples. —Michael Z. 2008-11-12 23:39 z

Would wp:Transclude text be a good start for what you have in mind? Butwhatdoiknow (talk) 23:48, 12 November 2008 (UTC)

I just realized that the section in question here is actually two separate transcluded files. Wouldn't it be better to just use a single one? Currently, one subsection cannot be edited while viewing the other, and a section intro sentence can't be added before the first subsection (right?). And a simpler arrangement may be easier to understand. —Michael Z. 2008-11-12 23:39 z

Sounds good. Butwhatdoiknow (talk) 23:48, 12 November 2008 (UTC)

MoS needs rescoping

I have for some time now had this fantasy that the generic material in the MoS will be transwikied into one or more WikiBooks projects—e.g. a scientific writing style manual, a Web content best practice manual—thus rescoping our MoS as documentation of our Wikipedia-specific conventions. Hesperian 22:35, 12 November 2008 (UTC)

That would be a great help. Septentrionalis PMAnderson 22:41, 13 November 2008 (UTC)

Possessives of common nouns in s

Is there really any doubt about "boss's" and "dress's" (rather than "boss' " and "dress' ") as is implied by the latest edit? --Kotniski (talk) 11:28, 13 November 2008 (UTC)

A rule of thumb that I use (and that some publishers recommend) is based on the sound of the final S. If it's an S sound (boss, dress, bus) add apostrophe-s. If it's a Z sound (James, Hitchens), add just an apostrophe (though classical names like Zeus take just an apostrophe even though the final sound is S). Would it be useful to propose this here, I wonder? SNALWIBMA ( talk - contribs ) 14:15, 13 November 2008 (UTC)

What about common nouns like "series", "species" (I mean the singulars)? For me, series' and species' look inescapably plural.--Kotniski (talk) 16:34, 13 November 2008 (UTC)

Good question - but I'd definitely say "the species' origin is in ..." - meaning a singular species. So I guess it doesn't look inescapably plural to me. SNALWIBMA ( talk - contribs )

I'd regard those words as exceptional enough that they could be listed, if necessary. Certainly this is better than just saying "some don't". But more importantly, we should be basing this on cited examples of authorities which prescribe this rule, rather than anecdotal evidence. Chris Cunningham (not at work) - talk 08:40, 14 November 2008 (UTC)

Interesting — I think this perception comes from the fact that these words have invariant plurals. Which invites the question: Is there a common noun that (in the singular) ends in a voiced s, that does not have an invariant plural? Offhand I can't think of one. --Trovatore (talk) 00:28, 14 November 2008 (UTC)

Limes would qualify, if it is an English noun. Its possessive, however, should be vanishingly rare. Septentrionalis PMAnderson 06:39, 14 November 2008 (UTC)

How do you pronounce it? Since it's Latin rather than Greek, my guess would be LEE-mess with the unvoiced s. --Trovatore (talk) 08:08, 14 November 2008 (UTC)

I would pronounce it to rhyme with the equally Latin series; so would the OED. This is not the currently popular pronunciation in Latin in either case; but we are dealing with English. Septentrionalis PMAnderson 15:36, 14 November 2008 (UTC)

See wikt:limes#Latin. LeadSongDog (talk) 19:43, 14 November 2008 (UTC)

For the pronunciation? Wiktionary is unsourced; the pronunciation given would be correct in (one of the half-dozen pronunciation systems for) Latin, but disagrees with observation and the OED (/'laɪmiːz/, if I have the right semivowel) for English. Septentrionalis PMAnderson 23:20, 14 November 2008 (UTC)

No, there's no doubt whatsoever. "Boss'" is just ghastly illiteracy. I've reverted this. Chris Cunningham (not at work) - talk 16:57, 13 November 2008 (UTC)

Collapsing

A recent addition says:

Scrolling lists and boxes that toggle text display between hide and show are acceptable in infoboxes and navigation boxes, but should never be used in the article prose or references, because of issues with readability, accessibility, printing, and site mirroring. Additionally, such lists and boxes may not display properly in all web browsers.

Surely, if such features cause "issues with readability [and] accessibility", that alone is reason why they should not be allowed in in info & navboxes? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:49, 15 November 2008 (UTC)

Info and navboxes shouldn't contain unique information anyway - they're at-a-glance summaries. I agree that keeping them short is a better solution than allowing them to collapse, but doing so shouldn't ever make information physically unreachable for certain readers, unlike collapsing sections in the article body. Chris Cunningham (not at work) - talk 13:00, 15 November 2008 (UTC)

It's redundant; the chief problem with readability (and AFAICT the problem with accessibility) is that they don't display properly in certain browsers and devices. A shorter form would be welcome. Septentrionalis PMAnderson 16:28, 15 November 2008 (UTC)

Unclear statement

If changing a heading, try to locate and fix broken links; for example, searching for Wikipedia "section headings" will yield links to the current section.

Perhaps I'm just being slow, but I'm unclear what this is trying to say. Should it read "... searching Wikipedia for ..."? And why "section headings"? Is there a special "search Wikipedia for section headings" feature (if so a pointer to it would be helpful), or does it just mean that you should use the normal search facilities to locate all instances of the text of the section heading in case they might be links to it. (Unless it's an unusual combination of words, good luck. A better option would be to search for Title#Heading, yes?) Matt 20:18, 15 November 2008 (UTC). —Preceding unsigned comment added by 86.136.194.39 (talk)

Well, I think it means just to insert the string Wikipedia "section headings" into the search box ("Section headings" just being an example, happening to be the title of the section in which this statement appears). I'm not sure it's a great example though.--Kotniski (talk) 22:16, 15 November 2008 (UTC)

Aha, I see what you mean... yes, I was being slow (in my defence, I think that using a section called "section headings" as an example is, as you say, not great -- not as currently worded at any rate). Would it be better to say '...searching Wikipedia for "Manual of Style#Section headings"...' then? Provided you enter the double quotes and click "Search" this seems to work, and would seem to be more generally applicable, as well as making it easier to understand what the explanation is getting at. For example, if you want to find a link to a section heading called "History" then searching for Wikipedia "History" might not be very helpful? Matt 03:22, 16 November 2008 (UTC) —Preceding unsigned comment added by 86.134.30.114 (talk)

A section for apostrophes

As with commas (see last section above), there was no section for apostrophes. I have therefore added that as a subsection of Punctuation immediately before Quotation marks (with which it shares issues), and added or altered internal links for the existing scattered treatment of the apostrophe in MOS. I also linked to the article Apostrophe, which gives excellent guidance for usage and surveys many of the alternative schools of thought. I also moved something about Ayin and similar characters to this new section, since that is more rational than covering it under Quotation marks (where is was for want of a better home).

Someone might like to make a shortcut link to this new apostrophe section, yes? WP:APOST?

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 05:39, 16 November 2008 (UTC)

Unnecessary sentence?

Note also that the common names of some birds are correctly hyphenated, for example the Great Black-backed Gull.

Maybe so, but the names of a large number of things are correctly hyphenated, and I don't really see why this one example is singled out for mention. Should we just delete it? Matt 03:28, 16 November 2008 (UTC). —Preceding unsigned comment added by 86.134.30.114 (talk)

I agree, Anonymous. It's altogether too specific. Since this looks uncontroversial I'll revert it myself right now.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 04:19, 16 November 2008 (UTC)

Undoubtedly, this is a remnant of a dispute about that specific article. The existence of a dispute suggests that we should say something, especially since Great Black-backed Gull appears to be correct. But it may be sufficient to say that hyphenated adjectives, on which we already have a bullet point, also occur in proper names. I included the example, as harmless and clarifying, but I don't care if it goes out again. Septentrionalis PMAnderson 16:01, 16 November 2008 (UTC)

Having it as an example embedded in a more general point seems absolutely fine to me; it was just the prominence of the original standalone statement that seemed weird. But I'm not sure the new wording is exactly right:

Many compound adjectives that are hyphenated when used attributively (before the noun they qualify—a light-blue handbag), are not hyphenated when used predicatively (after the noun—the handbag was light blue); this includes usage in proper names, such as Great Black-backed Gull.

This implies that if you wanted to say "the Gull was black-backed" then you would not use a hyphen, which seems wrong to me. Matt 00:28, 17 November 2008 (UTC). —Preceding unsigned comment added by 86.134.90.235 (talk)

But no, Anonymous. We simply read the sentence that follows immediately after the one about the gull: "Where there would be a loss of clarity, the hyphen may be used in the predicative case too (hand-fed turkeys, the turkeys were hand-fed)." You might quite naturally write the gull was black-backed, or indeed that gull turned out to be a Great black-backed, not a Ring-billed. These rules are to offer choices; but you still have to make the choice, depending on what will communicate clearly in any given situation.

I have no objection to this gull thing, in its present form.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 03:09, 17 November 2008 (UTC)

I'm afraid I disagree. Regardless of what the second sentence says, the words "this includes" clearly imply that "Black-backed" is one of those "many compound adjectives" that are not hyphenated when used predicatively. Matt 12:17, 17 November 2008 (UTC).

Point taken; I don't think this has to mean only one clause, but confusion will be avoided by changing to this attributive hyphenation, since we've just defined the term. Septentrionalis PMAnderson 17:58, 17 November 2008 (UTC)

A section for commas

While I'm focusing on MOS I thought I might re-configure just a little. It was strange to have the shortcut WP:COMMA pointing users to a section headed Serial commas. I've fixed that (here and at the redirect itself), and written a single sentence under the general heading Commas:

Commas are the most frequently used marks in punctuation, but also the most difficult to use well. See the article Comma (punctuation) for general principles governing usage.

Then follows the existing section Serial commas, demoted one level.

Obviously more should be said about the comma in general, not just about the serial comma. With my referral to Comma (punctuation) I've made a non-committal start. I hope that is not controversial. Others might now fill in details here, parallel with our treatment of all the other punctuation marks. I might well join in.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 04:52, 16 November 2008 (UTC)

I don't think the Manual of Style can refer to an encyclopedia article as a source of guidance. The article is (or should be) completely descriptive, the MoS is (at least to some extent) prescriptive.--Kotniski (talk) 07:46, 16 November 2008 (UTC)

I don't see why not; to the extent that we are advising people to do what English actually does, the article is exactly what we want. (It does not in fact discuss Common misuses of the comma, although it could: that grammarians regard some actually existing commas as "wrong" and "bad writing" is a verifiable fact about them.) Septentrionalis PMAnderson 15:11, 16 November 2008 (UTC)

Expanding and renaming a section: Colons and semicolons

Following the introduction of new sections for commas and apostrophes, it seemed rational to expand the section on colons to include semicolons as well. The two often operate together in the same sentence, and are frequently confused; so it is well to deal with them together. (It is also proper that they come immediately after commas, as they do.) I have deleted some information that is too obvious, or that should be addressed more systematically elsewhere for all punctuation (concerning spaces adjacent to punctuation marks).

There remains a general question about how much detail of this sort to include: but at least our treatment of punctuation is now more uniform and complete, with reasonable cross-linking.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 07:21, 16 November 2008 (UTC)

Those would probably be clearer divided into a section for each mark. These do not overlap significantly; the use of colons as strong semi-colons, while their original function, is obsolete, and we don't even mention it. Septentrionalis PMAnderson 16:03, 16 November 2008 (UTC)

Noetica, thanks for your good work. Tony (talk) 00:58, 17 November 2008 (UTC)

Anderson: I wrote that "the two often operate together in the same sentence", and that they "are frequently confused". I made these two points to support my idea that "it is well to deal with them together". What is your argument against those two points, to the conclusion that colons and semicolons ought to be kept in separate sections?

Tony: small enough in comparison to your own efforts, especially when we add the excellent work you do to tutor people about MOS, and your other coaching activities for Wikipedia. We could wish for certain others around here to be so hard-working and positive.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 02:58, 17 November 2008 (UTC)

They are indeed frequently confused; that seems to me an argument for discussing them separately. "The two often operate together in the same sentence"? I hope not; such sentences are cumbersome, and I trust such dangerous tools will be left to the anachronisms who can construct periods, such as Edward Gibbon and myself. Septentrionalis PMAnderson 04:23, 17 November 2008 (UTC)

I see I must explain that this is a joke, and that "anachronism", although less than serious, is self-deprecation. <sigh> Septentrionalis PMAnderson 04:07, 20 November 2008 (UTC)

MOSHEAD question: "The" and "a/an" in section headings

I've been studying MoS violations in randomly selected Featured and Good Articles, and I'd like a clarification of MOS:HEAD. If I understand the MoS correctly, the definite article "The" shouldn't be used in section headings. However, here are some Good Articles where one might argue for them:

• section "The 16 current Decade Volcanoes" in Decade Volcano
• section "The future" in Tyne and Wear Metro
• section "The EON films" in James Bond

I'm inclined to keep the "The" in the first article, but eliminate the others. What do others here think of these examples, and of prohibiting "The" in section headings? Thanks, Proteins (talk) 20:43, 18 November 2008 (UTC)

Another Good Article with multiple sections beginning with definite ("the") and indefinite ("a", "an") articles is United States Senate election in New York, 2000. What do people recommend? Proteins (talk) 21:02, 18 November 2008 (UTC)

No, you can use The in section titles, although if it adds nothing, you might as well omit it. We advise against it in article names largely to avoid having two articles on one subject, one with The and one without. This isn't a problem with section heads. Septentrionalis PMAnderson 00:08, 19 November 2008 (UTC)

This is why we should simplify and explain MOS. If we had done so, we would not have had to do here. Septentrionalis PMAnderson 00:08, 19 November 2008 (UTC)

According to the present version of MOS:HEAD, all the guidelines for article titles also pertain to section headings. Therefore, "The", "A" and "An" are "normally avoided as the first word, unless part of a proper noun." I'm not agreeing with that, but rather asking for clarification. Proteins (talk) 00:15, 19 November 2008 (UTC)

Yes, you are perfectly correct. A/an/the should not normally be used at the start of section headings. Tony (talk) 05:14, 19 November 2008 (UTC)

Rationale for this? Or is this another "because we say so"? Septentrionalis PMAnderson 05:50, 19 November 2008 (UTC)

I'd rename "The 16 current Decade Volcanoes" to "Current Decade Volcanoes" because I don't like the current title, but not just because of the "the". (BTW, is Decade Volcano really a proper noun?). Some people may complain that the heading repeats the article title; I don't think it's such a big deal, but another possibility is to rename it to something generic like "Current list". --Itub (talk) 06:19, 19 November 2008 (UTC)

"Volcanoes selected" is another option; I've gone for that for now. Chris Cunningham (not at work) - talk 09:37, 19 November 2008 (UTC)

Anderson, are you proposing a change to the MoS in this respect? Was your misinformation wishful thinking, or is the text—specifically, the cross references between the subsections—not sufficiently clear? Tony (talk) 11:45, 19 November 2008 (UTC)

I think MOS has been misread; it's a work in progess, and could use clarification here. The should usually be omitted in article titles for good reasons; section headers should generally be like article titles. Both are true; but I don't believe that this accidental collision of two independent and generally valid pieces of guidance was ever intended to prohibit the in section titles, nor do I believe that there is any good reason (except brevity, which I have already discussed) to do so; none of the other reasons we omit it in article titles apply to sections. Septentrionalis PMAnderson 17:13, 19 November 2008 (UTC)

Another MOSHEAD question: Disambiguations in the section headings

Please have a look at the "toponymy" section headings in Black Swan emblems and popular culture, which are disambiguated. Are they correct per MOS:HEAD? They seem inconsistent. Perhaps they should be rather "Toponymy (aboriginal languages)" and "Toponymy (English language)"? Is disambiguation itself allowed in a section heading? Thanks, Proteins (talk) 23:13, 18 November 2008 (UTC)

Yes, of course it is; although something less distracting than parentheses would be preferable, if it can be done without undue clumsiness. Section names should preferably be unique within a page; this applies even for the names of subsections. Sometimes this requires disambiguation. Septentrionalis PMAnderson 00:04, 19 November 2008 (UTC)

Please see my message at Talk:French_fries. -- Wavelength (talk) 01:14, 19 November 2008 (UTC)

The MoS consensus I'm hearing is that disambiguations per se are fine in section headings, is that correct?

The current section headings, "Toponymy (Aboriginal languages)" and "Toponymy (English-language)", still seem inconsistent. "Aboriginal languages" is a (capitalized) noun phrase, whereas "English-language" is a compound adjective. One solution would be "Toponymy (aboriginal languages)" and "Toponymy (English language)". These are minor points, but I'm curious whether disambiguations have style guidelines. Proteins (talk) 14:15, 19 November 2008 (UTC)

But do remember, as a human editor, not as writer of programs, that parenthetical disambiguation is usually our last choice, because it's hard to read. If there is a way to disambiguate without parens which is not wrong or clumsy, we prefer it: Aboriginal-language placenames would be better here - or merging the two sections. But if there isn't, parens are better than ambiguity; so scripts, which can't decide between these two cases, should leave them alone. Septentrionalis PMAnderson 17:34, 19 November 2008 (UTC)

I think your merger solution is excellent for this article, making the parentheticals into subsections. I also prefer "Place names" to "Toponymy"; the latter term is more specific but I think it won't be understood by general readers.

Just to clarify, the MOSHEAD-checking script is only diagnostic; it makes no changes to the article. The script readily concedes that its messages are only potential MoS issues. Of course human judgment is needed; I didn't mean to suggest otherwise. Proteins (talk) 18:10, 19 November 2008 (UTC)

Just as well; sorry not to have noticed that. Perhaps careful enough wording can avoid the abuse I foresee: "The script said it was wrong; MOS breach! MOS breach! Oppose." Unfortunately, FAC discussions are, all too often, exactly that robotic in their approach to MOS. Septentrionalis PMAnderson 19:10, 19 November 2008 (UTC)

MOSHEAD-checking script

I've written a script to check for violations of MOS:HEAD. It adds a new button to your "navigation" portlet in the left-hand column; when clicked, the script analyzes the article, printing potential MoS errors in popup windows in batches of 10 and highlighting suspect section headings in red. I've been testing it on random, Featured and Good Articles and it seems to work OK, although it can't recognize proper names, of course. To try the script out, you need to import it by adding "importScript('User:Proteins/mosheadcheck.js');" to your monobook.js subpage under your user name, as you can see at my own user page. You can test it on your favorite articles or on this MoS nightmare. Feedback would be welcome! Proteins (talk) 00:07, 19 November 2008 (UTC)

Checking nesting of headings is very handy; it's tedious to check it using the edit screen. I will check out the script this weekend; thanks for your work, it looks complicated! - Dan Dank55 (send/receive) 19:31, 21 November 2008 (UTC)

Image size

The last conversation on this was inconclusive. The current wording doesn't sit comfortably with the policy statement: WP:IMGSIZE. On the whole my understanding has been that size forcing is discouraged, unless there is a compelling reason for it. A vague statement that "This image is often resized to about 300px" is misleading as it doesn't give any explanation for the statement. It could either be advice to resize to "about" 300px, or a simple observation that the image tends to get forced even though it shouldn't be. I looked back in the history to find the first instance of allowing the lead image to be forced and found this conversation in which it was concluded that though there are considerations for at times forcing the lead image (and Bishonen's comments are persuasive for at least that incidence), that it shouldn't generally be applied. When the statement was transcluded over to this guideline, the wording on allowing forcing the lead image was left out as not having consensus. It was Gman who applied that wording 4 months later without consensus, or apparently misunderstanding the reasons why people were not comfortable with including it. The wording has been played around with since, so that now it no longer even makes sense. I propose a return to some of the original wording of the proposal, and to removing the vague statement about "This image is often resized to about 300px." SilkTork *^YES! 11:29, 19 November 2008 (UTC)

Better remind us what the "original wording" was. Personally I am happy with the current wording, which doesn't seem to lead to problems in practice. Johnbod (talk) 14:53, 19 November 2008 (UTC)

This is a much-watched page; substantial changes that have been made were the subject of discussion; the current wording has been stable for months; if it didn't represent consensus someone would have said so long ago. Forget the history and simply make a new proposal to change it, with reasons. The meaning of "this image is often resized..." is fairly clear to me; editors are allowed to use their judgement, as must always be the case with image size, but in so far as their judgement is to be based on the aim of consistency with other WP articles, 300px for lead images is a good direction to go in. (That's just what it says now, I'm not saying I strongly agree with it.) --Kotniski (talk) 15:40, 19 November 2008 (UTC)

I've given WP:IMGSIZE a quick edit, to make it explicitly clear that exceptions are discussed here at the MoS.--Kotniski (talk) 15:47, 19 November 2008 (UTC)

It shouldn't resized to "about 300 px". Wording should be "may be resized to 300 px". Users can set their preferences to specific thumbnail default sizes up to to 300 px. If someone sets their default to 300 px, and the lead is a forced image size of 250 px, then it will be smaller than all the other thumbs on that page (which will render at 300 px). This defeats the purpose of setting the larger image size for the lead image. It forces someone to see an image at a smaller size than the preference default they have chosen. Ty 15:58, 19 November 2008 (UTC)

How about "often resized to 300px, as this is the upper limit on the reader's thumbnail size preference"? That explains the rationale while still allowing a little wiggle froom for common sense in cases where 300px may be undesirable (images with very tall aspect ratios, for instance). Chris Cunningham (not at work) - talk 16:17, 19 November 2008 (UTC)

That 300px is the largest default is not a reason to make it the largest size allowed. Ty's reasoning would suggest something like "at least 300px", or maybe "300-350 px". What is the size where images are just too big on some screens? Johnbod (talk) 16:38, 19 November 2008 (UTC)

On a screen 800 x 600 (some users have even lower res screens) the 300px image takes up just over half the width of the article. 550px leaves no room for text at all. On a 1024 x 768 screen, 300px takes about 40% of the width and 550px about 70%. This suggests that 300px should be the maximum for the lead image, apart from exceptional circumstances. Ty 17:12, 19 November 2008 (UTC)

Is there a good reason why the lead image should be treated differently to the other images in the article? Why should all the images not be thumb sized and let editors' preference settings and visitors' default settings take over? (obviously with the exception of images with a high aspect ratio). Rotational (talk) 18:40, 19 November 2008 (UTC)

I think lead images can be 300px or they can be thumb size depending on the article, the image and number of images. In certain cases the lead is better as a thumb; and in other cases it is better at 300-350 px...Modernist (talk) 23:19, 19 November 2008 (UTC)

Suggestion

The original wording that was discussed:

The lead introduction image bullet point was questioned and no consensus was found for keeping that statement so was not included in the edit bringing over the wording.

This is when the edit under discussion was included: April 2007.

Previous discussions on this issue: [2], this long debate, the finish of which was that there was no consensus to add in the lead image statement, this one is more about the default image size, which is probably a developer issue, [3], inconclusive, but interesting discussion - good contributions from SlimVirgin, [4], image size, but this is a developer discussion misplaced here, [5].

Interesting reading.

The wording from image size policy is:

"In articles, if you wish to have a photo beside the text, you should generally use the "thumbnail" option available in the "Image markup". This results in 180 pixels wide display (140 pixels for images with the "upright" parameter) in the standard preferences default setting. As a rule images should not be set to a fixed size (i.e. one that overrides the preferences settings of the individual users), but see the Manual of Style for exceptions.

Where size forcing is appropriate, larger images should generally be a maximum of 550 pixels wide, so that they can comfortably be displayed on 800x600 monitors."

Given that a guideline should keep within policy, a suggested wording:

IMAGES

Further information: Wikipedia:Picture tutorial, Wikipedia:Accessibility § Images, and Wikipedia:Image use policy

The following general guidelines should be followed in the absence of a compelling reason to do otherwise.

• Start an article with a right-aligned lead image or InfoBox.
• Multiple images in the same article can be staggered right-and-left (for example: Timpani). It is often preferable to place images of faces so that the face or eyes look toward the text. However, images should not be reversed simply to resolve a conflict between these guidelines; doing so misinforms the reader for the sake of our layout preferences. If an image is ever reversed or otherwise substantially altered, there should be a clear advantage to the reader in doing so (for example, cropping a work of art to focus on a detail that is the subject of commentary), and the alteration must be noted in the caption.
• See Wikipedia:Picture tutorial#Avoiding image "stackups" for how to group images and avoid "stackups".
• Avoid sandwiching text between two images facing each other.
• Use {{Commons}} to link to more images on Commons, wherever possible. If there are too many images in a given article, a link to the Commons is a good solution. Use of galleries should be in keeping with Wikipedia's image use policy.
• Do not place left-aligned images directly below subsection-level (=== or greater) headings, as this can disconnect the heading from the text it precedes. This can often be avoided by shifting left-aligned images down a paragraph or two.
• Use captions to explain the relevance of the image to the article (see #Captions).
• You should generally use the "thumbnail" option available in the "Image markup". This results in 180 pixels wide display (140 pixels for images with the "upright" parameter) in the standard preferences default setting. As a rule images should not be set to a fixed size (i.e. one that overrides the preferences settings of the individual users). Where size forcing is appropriate, larger images should generally be a maximum of 550 pixels wide, so that they can comfortably be displayed on 800x600 monitors.

Examples of images where size forcing may be appropriate include:

• Images with extreme aspect ratios
• Detailed maps, diagrams or charts
• Images in which a small region is relevant, but cropping to that region would reduce the coherence of the image
• To get the full impact of the image because at the default ratio it could not be seen clearly

I am not quite convinced why the lead image should be forced simply because it is the lead image. If it is forced because it is in an InfoBox, then so be it. If it is forced because it matches the above criteria, so be it. If there is some other reason why an image should be forced then so be it. But simply because it is the lead image doesn't make any sense that I can see, and nothing has come through from the debates I've linked above that indicate why being placed in a particular corner of an article means an image should be forced beyond default size. SilkTork *^YES! 20:53, 19 November 2008 (UTC)

I don't agree about that, but won't go into it again. There are other problems above:

1) The no facing out should be given precedence over staggering left & right - I think it is generally accepted as the more important in the inevitable conflicts - see for example Sandy Georgia somewhere recently on FAC. Reversing the order would make this clearer. It is not just faces that may have a left or right-leaning bias, but perhaps that is too complicated to get into. 2)"If there are too many images in a given article, a link to the Commons is a good solution" is redundant to the previous sentence, and often a Commons link is far from a good solution, but one should be added anyway. This should be cut. 3)"Where size forcing is appropriate, larger images should generally be a maximum of 550 pixels wide" appears to contradict what Ty says above, except for panoramas intended to take up the full width. Maybe this should be spelled out. Johnbod (talk) 08:03, 20 November 2008 (UTC)

I agree with that. Also there is no onus on staggering images. They can all be right-aligned if that works for the article. Staggering need not be done mechanically right-left-right, but can be adapted for the needs of the article. Ty 09:20, 20 November 2008 (UTC)

Agreed that human heads are not the only objects with a front and a back - animals, vehicles, sculptures and a myriad other things should be included in the guideline/policy. Rotational (talk) 11:23, 20 November 2008 (UTC)

I've merged in the text to the project page. I haven't altered the "maximum of 550 pixels wide" sentence as that comes straight from policy, and the policy should be changed before we change it here. SilkTork *^YES! 08:35, 21 November 2008 (UTC)

The fourth item in the list there sounded weird; is my merge and reword of it into the first item acceptable? --an odd name 08:58, 21 November 2008 (UTC)

About 'Quotation' section

However, attribution is unnecessary for quotations from the subject of the article or section.

Does it mean that if the content is from the part of another content, it is not necessary to be attributed ? I think this sentence can be misleading. Jtm71 (talk) 23:06, 20 November 2008 (UTC)

Attribution means mentioning who said or wrote something, and if it's clear already, then it's not necessary to mention it. - Dan Dank55 (send/receive) 19:05, 21 November 2008 (UTC)

Academic Level of Articles / Formality vs. Insightfulness in Mathematics articles.

I think Wikipedia needs to solve a problem involving the academic level of science articles. Do we need to mark articles or sections of articles with levels like these: "high school (in USA terminolgy)", "first two years of college", "last two years college / graduate / first year graduate school", and "late grad school / postdoc"?

Also, in the mathematics section there is going to be (has been for a while) a problem where if everyone on the planet can improve an article by adding "formality", eventually it will become so formal that noone but a mechanical theorem proving progam will have a clue what is being discussed. Do we need to label sections as "Formal" and "Insightful / philosophical / informal". Actually, I dont know a word to discribe the opposite of "formal" in mathematics.

I noticed a similar problem in biology articles. It seems like some biology articles have tables of chemical codes and not much information about what is under discussion. —Preceding unsigned comment added by GeorgeScienceNut (talk • contribs) 03:21, 21 November 2008 (UTC)

It would be better to bring this up at WT:WPM. There you might mention an example or two to focus the discussion. (This would be a welcome break from the current tempest in a teapot over stub template images.)

It is certainly possible for a math article to be too formal. My concern would be that sometimes when people think they're making an article less formal, they're actually making it less correct. I hope we agree that it's not possible for a math article to be too correct. Also we need to keep in mind that WP is a reference work, not a textbook — the goal should be to make it possible for the reader to find out what he/she wants to know, not to teach the subject. --Trovatore (talk) 03:29, 21 November 2008 (UTC)

I see that User:GeorgeScienceNut edited the Eikonal equation article. The first sentence of that article says "The eikonal equation is a non-linear partial differential equation". To me, that is getting into rarified air. I don't suppose that one should expect the treatment of "a non-linear partial differential equation" to be written in "high school (in USA terminology)".

Perhaps a quote from Einstein is apropos:

Make everything as simple as possible, but not simpler.

One might ask for clarification on the talk page of a math article. I have done that before, and there were helpful replies. - Ac44ck (talk) 03:46, 21 November 2008 (UTC)

If anyone can suggest an informal (which is the word wanted) translation of non-linear partial differential equation, I would be glad to consider it; frankly, I can't. Septentrionalis PMAnderson 14:02, 21 November 2008 (UTC)

It's true that informal is the opposite of formal, but I think that George was searching for the word intuitive. For example, a theorem in calculus might have an intuitive geometrical proof that many people might understand, whereas a rigorous proof might fly over their heads. I'm reminded of the 19th century complaints that even Gauss' proofs were not rigorous enough; surely we don't expect casual readers of Wikipedia to operate at a level higher than Gauss?

As a scientist, I sympathize with both requirements, to be precise and to be accessible. However, I'm not sure that multiple versions of the same article are practical, although I see that good things have been done with general relativity and introduction to general relativity. I made a suggestion at Wikimania 2008 that might pertain here. The suggestion was to label articles or even article sections with the prerequisites for understanding it. That's sort of done implicitly by the article's wikilinks, but it might be good to work out something systematic. A method for determining prerequisite knowledge would be helpful for people who want to make textbooks and courses from wiki-material. Perhaps the prerequisite labels might be hidden by default, and visible only when the reader clicks on a button. Stating prerequisites more exactly also gets around the problem that curricula can vary widely between countries, within a country and even between schools in the same city. Basic algebra, trigonometry and statistics might be 7th-grade material in some schools, or college-level material in others. Proteins (talk) 14:35, 21 November 2008 (UTC)

The problem with a label about the "level" of an article is that it would function as a warning or disclaimer that an article might not be suitable for a reader. Although this particular type of disclaimer isn't covered at Wikipedia:No_disclaimers_in_articles, the talk page discussions have been relevant, and this text is relevant, IMO: "Allowing some disclaimers would generate a significant overhead of disputes surrounding where to draw the line, drawing editors' time from more productive tasks." - Dan Dank55 (send/receive) 18:52, 21 November 2008 (UTC)

Apart from the logistical problems in trying to define the "level" of an article, I think that it can send an unhelpful message: "No user-servicable parts inside — please stay away." There is no telling what someone at any level might be able to glean (or inspired to learn) from the most complicated article. Wikipedia does not exist in isolation. Things that I have read in articles have caused me to search for, find, and learn from information elsewhere. One can't grow without stretching. Sending the message to stay away because "some animals are more equal than others" can be needlessly crippling.

Maybe a "complexity" tag would be useful. As there are tags for uncited statements, NPOV issues, etc., maybe there could be a tag which is shorthand for "This discussion seems to be more complicated than needed. Please clarify by addressing issues of jargon, unexplained connections with other concepts, etc." This would be a message to _editors_, not visitors.

I don't know a good mechanism for doing so, but increasing an awareness of statements in existing guidelines could be helpful: WP:Explain_jargon and WP:Manual_of_Style_(mathematics), where it says "Probably the hardest part of writing a mathematical article (actually, any article) is the difficulty of addressing the level of mathematical knowledge on the part of the reader." It seems to me that the issue of excessive complexity is probably something that needs to be handled on an article-by-article basis.

Rating systems for article quality exist. Maybe a rating system for article _clarity_ could counter a trend toward complexity. A "this article is muddy" tag would send the message to a visitor that the tough slogging ahead is not necessarily due to a lack on their part. - Ac44ck (talk) 19:14, 21 November 2008 (UTC)

Reference library category

In order to help facilitate easier location of potential sources of offline information to help verify the notability of article subjects and contents, I have created Category:WikiProject reference libraries and placed into it all of the reference library pages of which I am aware. Please add more project reference libraries to this category if you know of more. Additionally, feel free to create new reference library pages for any particular project as well. They can be very useful. ···日本穣^{? · Talk to Nihonjoe} 20:08, 21 November 2008 (UTC)

Do these qualify?

• Wikipedia:Book sources
• Wikipedia:WikiProject Fact and Reference Check
• Wikipedia:WikiProject Resource Exchange

-- Wavelength (talk) 21:50, 21 November 2008 (UTC)

Absolutely. ···日本穣^{? · Talk to Nihonjoe} 04:51, 22 November 2008 (UTC)

Thank you. I see that all of them are now mentioned on the category page.

-- Wavelength (talk) 06:51, 22 November 2008 (UTC)

Proposed addition to "Currencies" section

I propose that the following text be inserted in the "Currencies" section:

The names of currencies, currency subdivisions, coins and banknotes should not be capitalised except where normal capitalisation rules require this (for example, at the start of a sentence).

Matt 20:01, 15 November 2008 (UTC). —Preceding unsigned comment added by 86.136.194.39 (talk)

• Since there have been no objections I've done this. Matt 23:05, 22 November 2008 (UTC). —Preceding unsigned comment added by 86.146.47.251 (talk)

Forced v unforced image sizes (again)

I realize that this is a perennial discussion, and am well aware that the consensus here is that image sizes should generally be unforced to defer to user preferences. But, isn't it time to reconsider the emphasis on "user preferences", given the recent decision to abandon date formatting? I mean, it was said that the vast majority of Wikipedia readers, on the order of 99%, are anon IPs and therefore do not have "date preferences" set. By the same logic, they don't have image size preferences, either, leaving them to strain trying to view a postage stamp-size 180px image or click on the image to enlarge. At the risk of being considered an iconoclast, I think for the sake of consistency and applying the same rationale, we should move away from the rigid, doctrinaire "no forced images so you can set your own size preference" for a more flexible approach. The goal should be suitable viewability by the vast majority of our readers, when 180px is too small.  JGHowes  ^talk 22:37, 19 November 2008 (UTC)

We shouldn't start making more images fixed size until logged-in editors have the ability to override the fixed size through an additional option in their preferences.

And, more fundamentally, the point of using the "thumb" option is the put a thumbnail of the actual image; the reader is perfectly able to click on the image to see the full version. If the default size for thumbnails is too small, it can be increased. That's far better than having each editor pick sizes out of the air that happen to look nice to him or her but are likely to lead to problems for users with different setups. — Carl (CBM · talk) 22:45, 19 November 2008 (UTC)

With the date situation there was no consistency for the unlogged in user when editors were using the auto-date feature, and the use of it was leading to a mess. With the image situation the mess occurs when editors are size-forcing the image, so we ask them not to size force, because then we have a consistency built in with the default size of 180px.

To be consistent with the decision to abandon date formatting is exactly why we abandon size formatting/forcing. Do you see? The purpose is exactly the same.

Now, for some people there is a belief that 180 px is too small a default size. But that is a different discussion. It's a developer issue, and has nothing to do with MoS guidance or Image Policy, which would continue to say the same thing, regardless of what the default size is: Do not force the size of the image unless there is a compelling reason to do so, because by forcing the size you are producing a different result for different people depending on their browser settings, etc. On these pages we are urging a consistency to aid all users - we are not advocating a particular size, simply a uniform approach. SilkTork *^YES! 23:40, 19 November 2008 (UTC)

If 180px is too small considering the size of modern monitors (and I think it may be), then it's time to revisit that as the default size for thumbnails. That's the best solution to the problem you describe. Chris Cunningham (not at work) - talk 08:52, 20 November 2008 (UTC)

Wikipedia appears to be optimised for 800 x 600 screens, which was once probably the majority of viewers, but may not be any more. Statistics are needed on readers' screen resolutions before any viable decision can be made on a default image size. Ty 09:24, 20 November 2008 (UTC)

My screen resolution when I am not using a stationary display is 800x480. And that's not unusual. --Hans Adler (talk) 09:32, 20 November 2008 (UTC)

800×600 is the size of the laptop I am using right now. — CharlotteWebb 20:34, 21 November 2008 (UTC)

So you now advocate that we should approve of forcing images to be larger than the screen of an iPhone and similar mobile internet devices and yet smaller than a user prefers? If the wikimedia software was more able to identify the type of device and set the default in a more intelligent manner, multiple "default" sizes could be used. Unfortunately, we simply don't have that available to us. It's bad enough that the last round of argument here moved from saying that we should not specify unless for one of a very limited range of reasons to saying that it was fine to have static sizes specified as long as you could get a majority consensus on the article's talk page to agree to it. I don't believe that the current position is as good as the previous one, and would prefer to retirn to the old arrangement wherein there were a very limited set of reasons to justify occasional images having their size fixed. --AliceJMarkham (talk) 11:27, 20 November 2008 (UTC)

We currently have: "If an image displays satisfactorily at the default size, it is recommended that no explicit size be specified." Is that not strong enough for you? Especially given that (as was pointed out in a previous discussion) fixed sizes were very commonly applied in practice - even in FAs - even when the guidance was worded differently.--Kotniski (talk) 13:59, 20 November 2008 (UTC)

Any default size needs to be overridden sometimes. E.g. sometimes an image is just eye-candy, sometimes it illustrates a point and sometimes it helps to explain a point. I've even used Template:Annotated image to crop images so that they focus on the important aspects. I've also tested "fixed size" images in Firefox, Opera and Internet Explorer 7, and all will expand images along with text, so I don't think there's an accessibility issue.

We can't assume all desktop users are viewing WP though widescreen monitors, and I test article layouts at both widescreen (16:9 or 16:10) and "traditional" (4:3) aspect ratios. To get the layout right for both, you need some control over image size.

For a good diagram a default thumbnail size is too small but full-size may be ridiculous.

If an editor specifies a size, he / she has probably thought about it.

Re Chris Cunningham (not at work)'s "If 180px is too small considering the size of modern monitors (and I think it may be), ..." a new default size needs to be tested on a range of clients, screen sizes and aspect ratios. --Philcha (talk) 15:39, 20 November 2008 (UTC)

I may be missing something here, but what is the problem with clicking on the thumb to see a full size image? jimfbleak (talk) 19:06, 20 November 2008 (UTC)

Well yes, you can do that, but it's better (if practicable) to save users that extra decision and extra bother. Images should - if possible - make an article nicer to read, not more annoying.--Kotniski (talk) 19:13, 20 November 2008 (UTC)

I typically hard-code most images to be 200px or larger, since 180 is just too small. For maps and diagrams, they're pretty much useless at 180 and even for photographs 180 looks like a postage stamp. And for the record, images of 200 or 300px display just fine on my iPhone. All this talk about needing tests and statistics is pointless. No one looks at webpages at resolutions less than 600px (including iPhone users) and I don't think anyone would want to set the default to be larger than 300, which is only half that. Kaldari (talk) 19:34, 20 November 2008 (UTC)

Setting my preferences to read thumbs at 300px works just fine on my screen. Is there any reason why images can't be changed from 180px to 300px as a default for casual readers? I can't see why that should be difficult... Rotational (talk) 20:04, 20 November 2008 (UTC)

I remember when this was last discussed, there was a strong consensus to allow editors to fix or omit the pixel size as they saw fit. Despite that, we have editors turning up at articles, including featured articles, to do nothing but remove pixel size or otherwise adjust images to conform with whatever someone has decided to add to the MoS. I've therefore removed the recommendation not to fix the size, and I've emphasized that the ArbCom has asked editors not to turn up at stable articles simply to change the style. SlimVirgin ^talk|edits 20:41, 20 November 2008 (UTC)

Your changes to the stability section are fine with me, but not the changes to the image size section. I reverted those. Editors should not be setting non-standard fixed widths simply because it looks good on their particular browser and setup. The aesthetic appearance is only one factor; the usability of the page, particularly on small or narrow screens, is another equally important factor. I also support increasing the default size to 240px. — Carl (CBM · talk) 21:01, 20 November 2008 (UTC)

Agreed, plus this just comes from the policy Wikipedia:Image_use_policy#Displayed_image_size, where it has been for a long time. Johnbod (talk) 10:08, 21 November 2008 (UTC)

The conversation seems to be continued at #Forcing Lead image below. - Dan Dank55 (send/receive) 19:07, 21 November 2008 (UTC)

I think we have conflicting guidelines here:

• Wikipedia:Mos#Images: "If an image displays satisfactorily at the default size, it is recommended that no explicit size be specified." Since this does not define "satisfactorily", I think the default must be "in the opinion of editors / reviewers."
• Wikipedia:Image_use_policy#Displayed_image_size: "As a rule images should not be set to a fixed size (i.e. one that overrides this default), but see the Manual of Style for exceptions." I interpret as being much more stringent, equivalent to "Do not override default sizes unless they fall inot the exception defined at Wikipedia:Mos#Images".

IMO the less stringent Wikipedia:Mos#Images guideline is almost OK and the more stringent Wikipedia:Image_use_policy#Displayed_image_size is wrong. As I pointed out earlier, images are used for a variety of purposes. At one end of the scale, I've produced diagrams that need to be as large as they can be without making a shambles of the layout. At the other, they can be simply eye-candy, or examples of points made in the text, and they only need to be large enough to be recognizable.

The problem with Wikipedia:Mos#Images's "satisfactorily at the default size" is that the default may change, and the new default may be unsuitable for the purpose for which the image is being used in a specific article. Only the editor(s) of the article can make this decision. --Philcha (talk) 18:19, 22 November 2008 (UTC)

A new citation template

Hi all. I've created a new citation template for citing Canadian federal & provincial statutes and regulations, based on the citations used by Queen's University, listed here. Compare [6], [7], [8].

A quick demo:

{{Cite canlaw
|short title = Trade-marks Act
|abbr        = R.S.C.
|year        = 1985
|chapter     = T-13
|section     = 9
|subsection  = 1(e)
|link        = http://laws.justice.gc.ca/en/showdoc/cs/T-13/bo-ga:s_1::bo-ga:s_2?page=2
|linkloc     = Department of Justice Canada
|wikilink    = Trade-marks Act}}

Produces: {{reflist}} (reflist moved down the page, no need to do it over and over)

I would appreciate any feedback on this. I'm concerned that too many abbreviations (chapter, section, etc) may be used, and I know the code itself looks awful. Is this something that people here think would be useful?

I have posted links to this discussion at WT:CANADA and WT:Citing sources to gain input from those groups as well. You can see the template in the wild here (the lone untemplated reference was what spurred me to try and find a template, but there wasn't one). //roux   11:59, 22 November 2008 (UTC)

Some thoughts:

• You might want to notify members of WikiProject Law about this discussion.
• There are far too many abbreviations in the citation. They may be intelligible to lawyers (and I have my doubts), but they will be a mystery to many readers. I suggest you spell out some of the terms in full, e.g., "Wikipedia Act, S.C. 2004, chapter W-1, section 2(iii), as amended by S.O. 2006, chapter 16 and S.O. 2007, chapter 4, section A (Wikipedia Act at Wikipedia).". Alternatively, if you feel that abbreviations will shorten the citation sentence, at least add mouseovers for abbreviations like "c." (chapter), "s." (section) and "ss." (subsection). (Note that "ss." is potentially ambiguous – it could be interpreted as "sections" or "subsections".)
• Is it possible to give pinpoint citations as "section 2(iii)" or "s. 2(iii)" rather than as "section 2, subsection iii"?
• Shouldn't there be a comma as shown? "S.O. 2006, chapter 16, and S.O. 2007 ..."
• I suggest that the phrase "Wikipedia Act at Wikipedia" be enclosed in parentheses rather than be set out as a separate sentence. Place a full stop at the end.
• Isn't the external link in the wrong place? "Wikipedia Act at Wikipedia" suggests that I am being provided with a link to a Wikipedia article, in which case the name of the piece of legislation at the beginning of the citation should be the one externally linked.
• Alternatively, to reduce the length of the citation sentence, why not link the first occurrence of the name of the piece of legislation to a Wikipedia article (if one exists), and the chapter number of the legislation to the external link, thus: "Wikipedia Act, S.C. 2004, chapter W-1, ..." The get rid of "Wikipedia Act at Wikipedia" at the end.

— Cheers, JackLee ^–talk– 14:13, 22 November 2008 (UTC)

Hi! Thanks for the feedback. In order..

• Will notify them now, should have thought of that!
• Yeah, I was iffy about the abbrevs too.. easily fixed.
• Yes, citations can be pinpointed if preferred.
• I don't think there should be a comma. Willing to be corrected but it doesn't look necessary to me.

My personal view is that there should be a comma in such situations (for example, "Big Ben in London, England, is a world-famous landmark"); not everyone agrees ("Big Ben in London, England is a world-famous landmark" seems – ugh – to be acceptable these days). But don't worry about it. It's not a biggie. — Cheers, JackLee ^–talk– 14:40, 22 November 2008 (UTC)

• Parentheses make sense.
• The external link isn't particularly clear in my fake example. Look at this for a real version:

Trade-marks Act, R.S.C. 1985, c. T-13, s. 9(1(e)) (Trade-marks Act at Department of Justice Canada)

Oh, that looks fine (but there should be a full stop at the end – or, preferably, use parentheses to avoid having two sentences). Your example was a bit ambiguous. — Cheers, JackLee ^–talk– 14:35, 22 November 2008 (UTC)

What about just "Trade-marks Act, R.S.C. 1985, chap. T-13, section 91(e) (Trade-marks Act at Department of Justice Canada)"? That way, editors can string several citations together in the same footnote separated by semicolons, if necessary: "Trade-marks Act, R.S.C. 1985, chap. T-13, section 91(e) (Trade-marks Act at Department of Justice Canada); Wikipedia (Prohibition of Use in Assignments) Act, R.S.C. 2008, chap. W-13, section 1 (Wikipedia (Prohibition of Use in Assignments) Act at Department of Justice Canada)." — Cheers, JackLee ^–talk– 15:27, 22 November 2008 (UTC)

I don't quite follow... why would you cite multiple sources in a single note? //roux   15:32, 22 November 2008 (UTC)

Because there are multiple sources for a single assertion. (This is sometimes inherent in the assertion: "Several laws provide..." requires several laws - or a secondary source.) Some editors approach this with multiple footnotes at the same point, but I find that ugly, complex, and confusing; so does FA. Septentrionalis PMAnderson 15:43, 22 November 2008 (UTC)

[Sorry, edit conflict.] It might be relevant to refer to more than one piece of legislation in the footnote. For example, one might be listing all the statutes that create offences for which the defendant can be sentenced to life imprisonment. It would not make sense to have a whole series of footnote numbers ("[1][2][3][4]..."), each one stating "See, e.g., the Offences Against the Person Act ..." — Cheers, JackLee ^–talk– 15:48, 22 November 2008 (UTC)

(out)Hmm, well, one could easily do that, no coding necessary.

Little bit of fiddling needed to make semicolons work, but I see no reason why someone couldn't include multiple cites in one set of ref tags. Or am I missing your point? I may well be.. //roux   16:22, 22 November 2008 (UTC)

Yes, that's what I'm getting at. But you're misunderstanding me slightly. I'm not suggesting you recode the template to allow for the citation of multiple statutes within the same template. All I'm saying is that your citation sentence should be one sentence. At the moment the template breaks up each citation sentence into two sentences, the first one being "Trade-marks Act ... section 91(e)." (note the full stop at the end) and the second one being "(Trade-marks Act at Department of Justice Canada.)". If one puts a comma or semicolon after that and then adds another citation sentence, it will look odd. I suggest you eliminate some punctuation marks and make the template generate a single citation sentence, like this: "Trade-marks Act, R.S.C. 1985, chap. T-13, section 91(e) (Trade-marks Act at Department of Justice Canada)" (no full stop after the section number and at the end). — Cheers, JackLee ^–talk– 16:57, 22 November 2008 (UTC)

Ah so. Done. //roux   17:03, 22 November 2008 (UTC)

• I thought about doing that, but then it just looks like one long link at the beginning of the cite. If no wikilink is provided, the act title becomes the external link, and no external link is appended on the end.//roux   14:32, 22 November 2008 (UTC)

Good idea! Will have a look at the code when I am less busy. Hmmm, am now wondering whether to expand {{Singapore Statute}} and {{Singapore Constitution}}, which I previously worked on. — Cheers, JackLee ^–talk– 14:35, 22 November 2008 (UTC)

I've edited per your suggestions above and struck out some of my comments. //roux   14:47, 22 November 2008 (UTC)

Other comments

"Section" and "subsection" parameters. Is there any utility in having separate "section" and "subsection" parameters? Why not have a single "section" parameter that would be used thus: "section=9(1)(e)"? The separate "subsection" parameter may tend to mislead editors into typing "subsection=1(e)". This would cause the template to render "section 91(e)" rather than "9(1)(e)". — Cheers, JackLee ^–talk– 17:17, 22 November 2008 (UTC)

Well, that's why I had chapter & subsection in before. I'll re-add them.//roux   23:52, 22 November 2008 (UTC)

Er, not sure what you mean. "Chapter" has always been a separate parameter and I'm not suggesting any changes to it. But I think it may not be necessary to have two separate parameters, "section" and "subsection". Just a single "section" parameter is enough. — Cheers, JackLee ^–talk– 06:30, 23 November 2008 (UTC)

I think I've now made it as clear as it's possible to. The docu for the template is also extremely clear about what goes in which field. //roux   06:36, 23 November 2008 (UTC)

I'm in favour of the shorter form "section 9(1)(c)" rather than "section 9, sub. 1(c)", in which case it's only necessary to have one parameter "section" which an editor can give the value "9(1)(c)". But this isn't a big issue. I guess it's still possible for editors to just use the "section" parameter and omit the "subsection" one. — Cheers, JackLee ^–talk– 06:44, 23 November 2008 (UTC)

I'm aiming for standardization and idiot-proofing. If there are separate places to put the section and subsection, it avoids goofs, as well as being more transparent in the final cite to anyone--like myself until yesterday--not familiar with the conventions of legal citations. //roux   06:54, 23 November 2008 (UTC)

Spot plague

Is there any MoS guidance on use of a stop to end each item in a list?

I am thinking of the See Also section of an article as an example where I am noticing a tendency to put stops at the end of each line, even with short items that are not sentences. Is there any MoS guidance on this (I have looked, but not thoroughly)? If not, should there be? (It seems to me to be an undesirable affectation.) Globbet (talk) 01:05, 24 October 2008 (UTC)

Generally speaking, stops should be only used at the end of a sentence. I can see three distinct cases here:

the whole list is part of a sentence

Punctuate as if part of a sentence; e.g.

I need to remember to pack

• my toothbrush;
• my hat; and
• my ferret.

a list of sentences

Punctuate each entry as the sentence that it is; e.g.

• Feed the dog.
• Kick the cat.
• Kiss the wife.

a list of non-sentences

Don't bother punctuating; e.g.

List of VFL clubs starting with F:

• Fitzroy
• Footscray
• Fremantle
• fucking Collingwood

Hesperian 01:42, 24 October 2008 (UTC)

• It is usual in today's English to keep full stops to a minimum. For example, 50 years ago the BBC was written B.B.C., today it has no full stops. I also query the use of full stops when writing U.S. Should it not be US or better still USA as leaving off the reference to America is an arrogance that presumes that presumes there are not other united states in the world? Brenmar (talk) 06:14, 24 October 2008 (UTC) Brenmar

Dots are usually redundant; their use should be minimised. Some American writers still insist on "you dot es dot", regrettably. Tony (talk) 12:08, 24 October 2008 (UTC)

In some contexts it is easier to do a computer search for "U.S." rather than "US" because if the search is not case-sensitive, the latter is the same as the word "us". --Gerry Ashton (talk) 13:36, 24 October 2008 (UTC)

That is true, but one would search for "US" plus another item such as "health system". Hmmm ... that would yield nothing, probably—just joking; actually, it's very successful on google, with WP's articles (which use the dots in their titles) the top two of 52.4 million hits. Looks like cyberspace has caught up the the dotless way. Tony (talk) 13:49, 24 October 2008 (UTC)

MOS:DAB is specific that thou shalt not end entries with a period. For consistency, other list-like pages or sections should do the same (or else dab pages should conform to the general standard). SpinningSpark 16:09, 24 October 2008 (UTC)

Thank you for bringing that to our attention. MOSDAB has hardened into a most unfortunate bunch of silly rules; but its requirements should not make Wikipedia look stupid. We have enough articles that do that already. Septentrionalis PMAnderson 20:26, 24 October 2008 (UTC)

I regret seeing my learned colleague endeavor to impose Australian English on the rest of us. Please chill, Tony. Septentrionalis PMAnderson 20:08, 24 October 2008 (UTC)

I'm trying to impose nothing; I support the current option to use or not use dots for "US", but encourage all editors not to use them. On the other point (below), US editors apparently object to the dots in "U.S.A", and indeed even to the use of the triple abbreviation in most instances: see MOSNUM. Tony (talk) 03:09, 25 October 2008 (UTC)

• Maybe the answer, Tony, is to refer to USA. That way makes it clear and avoids the arrogance of the Americans in thinking they are the ones with united states. Even presidential candidates call it the "United States of America" Brenmar (talk) 22:59, 24 October 2008 (UTC) Brenmar
• And the editors you refer to correctly represent idiom: U. S. but USA; nowhere is it written that idiom must be logical. Septentrionalis PMAnderson 14:22, 25 October 2008 (UTC)

List items are already clearly marked by bullets. Adding semicolons or periods is useless decoration, as would be adding colons to boldfaced headings. Periods should only be added as separators if the list items are mixed fragments and sentences, or short paragraphs. The same thing goes for image captions, whose nature is clearly indicated by their relationship to the image and enclosing border.

Like any functional product, typography is degraded by redundant elements, and it is not common practice to use them. —Michael Z. 2008-10-25 00:33 z

So - general agreement, as I expected, but where in the MoS maze does it say, or of it doesn't, where should it say something like 'don't clutter lists up with misguidedly prissy punctuation'? Globbet (talk) 00:03, 26 October 2008 (UTC)

I guess Wikipedia:MOS#Bulleted_and_numbered_lists has advice, but it doesn't quite conform to this concept, nor does it match prevailing use in my opinion. Also the examples in WP:LIST have no punctuation at all. —Michael Z. 2008-10-26 16:13 z

I tried fixing Wikipedia:MOS#Bulleted_and_numbered_lists to remove the unnecessary punctuation and conform to WP:LIST and common practice, after asking for comments here and posting a project-wide request for comments, but my change was reverted by Tony1. -- Beland (talk) 17:16, 6 November 2008 (UTC)

I didn't see an opposing view stated here by Tony1, so I have changed the relevant section, along with some rephrasing. Our table of contents is a prime example of final punctuation being omitted for a numbered list of non-sentence elements. --Zigger «º» 04:02, 14 November 2008 (UTC)

Failure to punctuate the end of list items causes them to be run together as a single sentence in some assistive technologies (primarily screen readers, as these only parse the displayed text, not the underlying HTML). Not everyone can afford more sophisticated software such as JAWS, so placing stops at the end of all list items is an important part of making Wikipedia accessible. dramatic (talk) 03:45, 24 November 2008 (UTC)

Which screen readers have this limitation? —Michael Z. 2008-12-02 22:56 z

Footnotes in the lede?

I recently saw someone claim that the MOS says the lede section of an article should not contain footnotes. I dont care about the article in question, but please tell me this isn't so. — Carl (CBM · talk) 21:51, 15 November 2008 (UTC)

The idea is that the lede is a mere summary of the article, so all claims in the lede will be verified in the text. As such, visually distracting inline citations do not provide any benefit to the reader. If this is not covered in the MoS, I think it ought to be. the skomorokh 21:54, 15 November 2008 (UTC)

There are many purposes for footnotes other than inline citations of specific facts. In particular, they are used for parenthetical and editorial comments. And the scientific citation guideline has long recommended that one way of indicating general references for the article is via footnotes or inline citations in the first paragraph, as in Mathematical logic and Aldol reaction. So I can't see that a blanket prohibition would be justified. — Carl (CBM · talk) 22:05, 15 November 2008 (UTC)

Right, I was referring to straight inline citations, as in {{cite journal}} and the like. Expository comments are of course a different matter. the skomorokh 22:07, 15 November 2008 (UTC)

I'd agree in most cases, but I still think it's not totally uncommon to get the occasional cite-worthy statement appearing in the lede that isn't repeated anywhere else. Perhaps we could make a recommendation including exceptions; but perhaps not on this page, but on whichever one it is now that deals with citations.--Kotniski (talk) 22:12, 15 November 2008 (UTC)

Aye, for well-developed articles. Many ledes are simply unsectioned leftovers rather than summaries. Something like "inline citations are discouraged in the lead sections of articles where the lede functions as a summary"? I image WP:LEDE would be the place to address this. the skomorokh 22:14, 15 November 2008 (UTC)

There is already some text at WP:LEDE#Citations. I just wanted to be sure there is no general prohibition on footnotes in the lede in some other MOS page. — Carl (CBM · talk) 22:27, 15 November 2008 (UTC)

(ec) Examples of two well-developed articles that use notes in the lead for dispute resolution: USS Constitution, an FA, uses two notes that point out facts that were often changed or discussed on the talk page. Led Zeppelin, a former FA candidate, uses notes in the lead to an extreme, again to avoid arguments about facts that were disputed in the past. I would have to say that the USS Constitution uses the correct style, and Led Zeppelin is overkill. However, in both cases without the notes disputes are bound to occur. I am constantly amazed that editors will remove, tag or dispute facts on talk pages without reading past the lead, but it does happen. Sswonk (talk) 22:36, 15 November 2008 (UTC)

I'm not sure whether we're talking about just footnotes as opposed to citations or both; people use the word "footnotes" both ways. Someone correct me if I'm wrong, but I think that a year ago, it was a common request at WP:FAC to remove all <ref> tags from the lead section, but there have been many FAC's this year that passed with multiple <ref>'s in the lead. - Dan Dank55 (send/receive) 23:32, 16 November 2008 (UTC)

Led Zeppelin has mostly citations; USS Constitution has two parenthetical explanations, just as well out of the text. Septentrionalis PMAnderson 23:55, 16 November 2008 (UTC)

• Strongly against a blanket prohibition, or even any discouragement. For example, articles on paintings should give their size in the first paragraph, about which there is rarely anything further to be said. But this should be referenced. Similarly with variant spellings of historical people's names. Johnbod (talk) 14:58, 19 November 2008 (UTC)

Strongly against a blanket prohibition, or even any discouragement. If the lead section contains statements that need citations to justify them, then it should have the citations.

• An example of this is Prince Consort class battleship whose second paragraph has citations for what the class is called today (Prince Consort class), and what it was called at the time (Caledonia class). These facts belong in an introduction.
• In the article Jackie Fisher, 1st Baron Fisher there are citations concerning his name - how this man should be referred to is disputed. Having his correct name at the start (with citations), but using one of his many nicknames as the title seems to be something people can live with. Other examples of citations for the name being advisable, are articles on some cities in Eastern Europe, because the English language name is disputed, e.g. Dnepropetrovsk (though curiously enough, that article does not have them - the justifications (with citations) being in the talk page.--Toddy1 (talk) 15:20, 23 November 2008 (UTC)

General and specific questions about subscripts in section headings

First the general questions: is it appropriate to include a subscripted mathematical variable such as pK_a in a section heading? Pro: It can be useful, and my own feeling is that we should err on the side of allowing things. Per WP:ACCESS, Graham87 and I have checked that such variables are read correctly by screen readers. Alternatives such as the Unicode pKₐ do not render in all browsers and are not read by screen readers (at least with my JAWS and Fire Vox settings). Con: MOS:HEAD suggests that "special characters" should not be used in section headings. There's also a problem with linking to such sections, as you can see at User:Proteins/Sandbox. This can be solved using an additional {{anchor}}), but many editors might not know about that.

Now the specific questions. The article acid dissociation constant is at FAC, and the nominator Petergans would like to use pK_a in the section headings. He and I agree that this variable is equivalent to the article title, and therefore would ordinarily not be included in the section headings, per MOS:HEAD. Should an exception be made? The current section headings do not use pK_a. What do people here think of introducing pK_a into the section headings of this particular article? Proteins (talk) 16:05, 22 November 2008 (UTC)

I would be cautious. Just because some browsers handle this right is no quarantee that all do, and the cost of garbling a header could be quite large.

I would include the special character if necessary; but I'm not sure, for this article, where it would even be helpful to add it. (Possibly Values, but Values of the acid dissociation constant would probably be better there.) Which ones does he have in mind? Septentrionalis PMAnderson 16:55, 22 November 2008 (UTC)

I believe the idea would be to (1) substitute "Values" in section 7 by "pK_as", and (2) add "of pK_as" to several section headings such as "Experimental determination" and "Significance".

With the article at FAC, everyone would like a consensus on the issue. The current consensus seems to be: (A) in general, allow subscripts (with caution) if necessary but (B) discourage "pK_a" in the section headings of acid dissociation constant. Does that seem fair and sensible? I encourage everyone here to contribute their ideas and opinions! Proteins (talk) 12:51, 23 November 2008 (UTC)

Tags or templates of any kind are not reliable in section headers.

• [[Very long article#Very important section about pKₐ]]
  This will always link to the correct place whether you can see the last letter or not.
• [[Very long article#Very important section about pK<sub>a</sub>]]
  This will never be rendered as any kind of link.
• [[Very long article#Very important section about pKa]]
  This link might point to a section containing the html <sub> or it might not. There is no way for the reader to know prior to clicking. This should be avoided as typical non-obvious link behavior.
• [[Very long article#Very important section about pKa|Very long article#Very important section about pK<sub>a</sub>]]
  This will have the correct target and the correct appearance without using non-ASCII letters but this code is not something I'd like to see in the edit box, ever.

Additionally if a reader attempts to copy and paste the section title to another medium the <sub> tags (and thus part of the meaning) will be lost, but using ₐ would preserve it. — CharlotteWebb 15:27, 23 November 2008 (UTC)

You raise very good points, Charlotte, some of which I was also trying to highlight in User:Proteins/Sandbox, less articulately. What I'm hearing from your post is that you would discourage the use of subscripts in general, but if they must be included, they should be done with Unicode characters such as ₐ, not with tags such as _a. Is that a good summary?

I agree that tags won't work as internal page links. An extra {{anchor}} template (with a non-subscripted name, of course) could be used as workaround, but I imagine that most editors won't know about it. If we wish to allow casual editors the freedom to link to arbitrary sections, then it seems we should discourage editors from using subscripts in section headings.

The problem I see with Unicode subscripts is that they don't always render. For example, the symbol ₐ appears as a square box with numbers in it on my laboratory computer running Firefox 1.5, which I believe is standard for the operating system, Ubuntu. Also, there seems to be an accessibility issue: I didn't hear the final "ay" in pKₐ when I listened to it in version 9 of JAWS and in Fire Vox. Presumably, those screen readers don't know about this Unicode character, unless perhaps my default settings are bad. In the future, browsers and screen readers will undoubtedly support Unicode subscripts, but for the moment, they seems like they aren't a solution for everybody. Proteins (talk) 16:20, 23 November 2008 (UTC)

On the bright side one of these appears to be open source, so there may be some hope of correcting its deficiencies. — CharlotteWebb 16:48, 23 November 2008 (UTC)

Screen reader trials and tribulations

Well, I just tried to install Fire Vox hoping to see what settings are available but it caused Firefox (3.0.4) to crash immediately after opening, so I had to use "safe mode" to disable the plug-in. Can anybody else get this to work? — CharlotteWebb 17:08, 23 November 2008 (UTC)

My installation of Fire Vox was disabled when I upgraded to 3.0, so evidently it's not compatible.--Curtis Clark (talk) 18:11, 23 November 2008 (UTC)

I forgot to mention that I did try it in version 2.0.0.18 I had before and it failed there first. This is what encouraged me to upgrade to FF3 and try again, but the plug-in still causes a fatal error. In 2.0.0.18 it said:

firefox.exe has generated errors and will be closed by Windows. You will need to restart the program.

Now in 3.0.4 the message is longer but no more informative:

Firefox had a problem and crashed. We'll try to restore your tabs and windows when it restarts.
Unfortunately the crash reporter is unable to submit a crash report.
Details: The application did not leave a crash dump file.

Note that there were no "tabs and windows" at the time of these errors, as they happened immediately at startup in both cases (can only be avoided by using "safe mode" to disable add-ons). — CharlotteWebb 18:38, 23 November 2008 (UTC)

I'm so sorry that you've had such difficulties with Fire Vox. Fire Vox is not a mature screen reader and I mentioned it only because I personally found it easy to install and learn. I'm using Firefox 3.0.4 on a Hewlett Packard laptop running (I cringe to say this) the Vista operating system. If you can get one working, screen readers can be fun and also useful to writers, because you can hear an article read aloud. To make the reading flow better, you might want to strip out the hyperlinks with this script. We also probably all agree that it's important to make our articles accessible; isn't WP:ACCESS part of the MoS?

The de facto standard screen reader seems to be JAWS, although I've found it a little difficult to learn to use. It's commercial software but you can download a free demo version that gives you 40 minutes of use after every reboot. Graham87 maintains notes on how best to use JAWS on Wikipedia; he's the go-to expert. A GPL-free screen reader is NVDA, which is designed specifically for Windows. Proteins (talk) 11:56, 24 November 2008 (UTC)

I almost forgot to ask: what's the consensus on the general and specific questions that are posed above, the questions about subscripts in section headings? It'd be great to give Petergans a clear answer. Thanks, Proteins (talk) 12:01, 24 November 2008 (UTC)

I don't know how these programs work as I haven't gotten any of them to run, but why would one want to "strip out" the links? Wouldn't that defeat the purpose of using text-to-speech within the web browser? If I wanted to listen to plain text I'd probably just copy-and-paste it in my word processor and be done with it. Of course if I was blind I probably wouldn't be able to do that.

Anyway the point of all this was I wanted to check out these screen readers and see whether they can be user-configured with "alternate text" for letters and symbols it might not recognize:

"subscript a" for ₐ to use instead of "<sub>a</sub>" which might not be recognized if tags are stripped out.

"not equal to" for ≠ to use instead of "!=" (which the screen-reader might interpret by shouting the previous text) or worse, "=/=".

"copyright" for © (instead of (c)).

If these settings are easy enough we can offer a configuration file for screen-reader-users to install, possibly including other symbols or expressions with a Wikipedia-specific meaning. I'd really like to help with this as long as I can find some software that actually works and especially if it's free. Hopefully the result will be one less excuse for poor typography. — CharlotteWebb 17:10, 24 November 2008 (UTC)

I have very limited experience, but screen readers always seem to stop reading at every hyperlink, to allow the listener the option of following it. Given how dense hyperlinks are in wiki-text, that makes for very choppy reading. That's why I wrote the script to strip them out. You could cut and paste the article into a text editor, as you say, but the script spares you that trouble. Later, I found out about an online server that produces MP3 files of a whole article. However, a screen reader gives you control over what parts of the article you'd like to listen to. If you listen to an long FA, it can take over an hour!

BTW, what do you think about the general and specific questions on section-heading subscripts? Proteins (talk) 17:49, 24 November 2008 (UTC)

I think html tags and templates should generally be avoided within section-headings, and that the section headings should more generally conform to the same "technical" restrictions as article titles. That is, they should not include #<>[]|{}. Sections are after all independently wiki-linkable, and can in many cases be thought of as an article within an article (especially those which are the product of a merge or a candidate for splitting apart). I'm experimenting with NVDA right now (but I had to disable it because it wouldn't let me type with it running—I'll have to figure out what's up with that). — CharlotteWebb 18:23, 24 November 2008 (UTC)

Figured out why I can't type while using NVDA—the keyboard is overridden with bunch of shortcuts making it impossible to input most letters. I tried using "[x] Disable access keys" in Special:Preferences but that had no effect on the screen reader behavior (yes I cleared the cache, and yes I'll keep them disabled anyway) because this is entirely some feature of NVDA. Once I slowed the voice down enough to understand it, I figured out why it was jumping around to different parts of the screen, such as looking for the "next separator" with "S" and the "next list item" with "I". I can't find any settings to disable this, so I'd appreciate advice from anyone who uses NVDA, because it is tedious to exit the program every time I want to type something.

Anyway, I was able to test it on a previewed page with the following:

visual	foo bar pKa test 1 foo bar pKₐ test 2 foo bar pKa test 3
wikitext	#foo bar p''K''<sub>a</sub> test 1 #foo bar p''K''ₐ test 2 #foo bar p''K''a test 3
actual html	<ol> <li>foo bar p<i>K</i><sub>a</sub> test 1</li> <li>foo bar p<i>K</i>ₐ test 2</li> <li>foo bar p<i>K</i>a test 3</li> </ol>

On all three lines it only spoke "foo bar pee" and stopped, I removed the italics from all three and tried again.

After that I got: "foo bar pee kay [stop]" for #1, "foo bar pee kay test two" for #2 (but with no pause for the unrecognized U+2090), and "foo bar p'kahh test three" for #3.

Then I took a closer look at #1 and figured out it would pronounce the "a" and the "test 1" individually but only when I hover cursor over them. It seems to stop at all html tags, not just hyperlinks, and it does not give any hint that the "a" is formatted as subscript.

I'm not sure if this could be configured enough to be reliable for a visually impaired person so I will try the JAWS demo next. — CharlotteWebb 16:39, 25 November 2008 (UTC)

Your experience with NVDA echoes my own, although I am able to hear #1 more-or-less correctly in Fire Vox and JAWS. Graham87 and others will be able to tell us the best settings, if any, for reading such examples. However, the fact that a screen reader must be specially configured to read a section heading suggests to me that HTML sub/superscripts and Unicode text should be discouraged from section headings, at least until screen readers improve. I can't imagine a situation in which they'd be necessary, but it's also good to keep an open mind. Proteins (talk) 17:30, 25 November 2008 (UTC)

Well, the JAWS demo gave me the following message: You cannot install this product on this version of Windows. Please contact Freedom Scientific for a version that will run on your operating system. On a more positive note the error message was spoken aloud and much more clearly than any of the NVDA voices, so unless it was pre-recorded this does inspire some confidence (as soon as I can afford to buy a new lappy—but I'm told Vista really sucks so I might try going Linux in that event). In the meantime I don't suppose there is any JAWS demo that will run in Windows 2000, service pack 4… — CharlotteWebb 18:26, 25 November 2008 (UTC)

Undesirable behaviour of the section edit box, for the last section

If the last section, edit tag, is selected, all content below that section is also displayed in the edit box, this can be solved by creating a footer section. Byzerodivide (talk) 01:21, 24 November 2008 (UTC)

The only problem I see with that is there is no way to for a section heading to be editable without being visible both at the bottom of the article and in the table of contents, which would be an eyesore in my opinion.

The only syntax other than ==Headline text== is to use <h[number]>, but this has exactly the opposite effect:

Example!

This is visible here and in the TOC but has no edit button (because despite appearances it is actually part of the previous section). — CharlotteWebb 22:41, 24 November 2008 (UTC)

Page of frequently made challenges

It appears that the Manual of Style is receiving so many challenges on a repetitive basis (as other parts of Wikipedia are doing) that it must be difficult for some editors to keep from tiring out (burning out?) from answering the same challenges over and over again. Some challengers are probably new to Wikipedia, and some challengers evidently fail to read or to understand or to accept responses which have already been given above their own challenges. Therefore, I suggest, for the benefit of everyone concerned, that there be a page Wikipedia: Frequent challenges against the Manual of Style, with a list of frequent challenges and carefully prepared responses to them. There can be a notice at the top of the page Wikipedia:Manual of Style, saying: "If you wish to challenge the Manual of Style, please see this page first."
-- Wavelength (talk) 03:34, 24 November 2008 (UTC)

Wavelength, you've really stepped it up, and you're learning fast. I have been deliberating whether to reinstate monthly changes to style guidelines at WP:Update, and have decided that it will be a net positive (especially if you help!) There's one thing we have to be careful about: when we're sharing information about style guidelines, it's important to do it for the right reason ... to support the community of copyeditors, and people who are familiar with books, magazines and newspapers generally, and Wikipedian editors generally who are more comfortable when they're operating in a world that looks familiar to them. We need these people; they need our help. What you're saying sounds great, but the proof is in the pudding: if it attracts and supports people with high levels of clue, we're succeeding, and if it puts them off, then we need to adjust what we're doing. - Dan Dank55 (send/receive) 16:22, 24 November 2008 (UTC)

With the note that, per WP:CONSENSUS, that frequent challenges to the same point by independent editors strongly suggest that the consensus of self-appointed "regulars" may not represent a consensus of Wikipedia as a whole. Septentrionalis PMAnderson 22:10, 24 November 2008 (UTC)

...and that pre-emptive non-collegial tampering with guidelines tagged as under discussion is unacceptable. And that editors who do not even support MOS offering genuine guidelines should be advised to reconsider their involvement here. And that we desperately need to tackle the whole matter of prescription (the common stance of all style guides) versus passive description (the common stance of dictionaries and entertainments like Fowler's). If these things are not attended to fast, no other work here counts.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 00:38, 25 November 2008 (UTC)

Feel free to tell me whenever I'm wrong, I love collegial feedback. - Dan Dank55 (send/receive) 00:06, 25 November 2008 (UTC)

Do I detect a reference to the first and last sentences of the third paragraph of Collegial#Definition_of_collegiality? --Philcha (talk) 01:43, 25 November 2008 (UTC)

I didn't know that meaning, I meant "genial" and "as among colleagues". I've got something going on that would make it very unwise for me to get in any big fights at the moment; I can come back to this topic in about a week. - Dan Dank55 (send/receive) 03:15, 25 November 2008 (UTC)

PMAnderson, which is more important, the quantity of editors supporting a position, or their qualifications and expertise? If a thousand editors were to challenge the article "Pig" with the claim that pigs can fly, and ten editors were to refute their claim with solid evidence, should Wikipedia state that pigs can fly? What would Doctor Google say?

-- Wavelength (talk) 05:54, 25 November 2008 (UTC)

As you're stating it, that's more of a policy discussion, Wavelength (WP:OR, WT:OR, WP:RSN, etc.), but I take your point that you're talking about how to arrive at useful content in WP-space, which is not covered by those pages. - Dan Dank55 (send/receive) 15:07, 25 November 2008 (UTC)

@Wavelength: The quality of the editors' arguments. We cannot judge expertise; indeed, we've already had scandals where Wikipedians have claimed expertise they don't have. The numbers of editors can be a proxy for this; but this page should only make assertions which have general consensus among Wikipedians - see WP:POL. It doesn't match that standard, because there's always a language crank or two who want to lend tinsel "authority" to their pet notions. Septentrionalis PMAnderson 03:36, 26 November 2008 (UTC)

• Which is more important to Anderson? Neither. His monocampaign is to dilute the authority of the MoS, pure and simple. Tony (talk) 15:24, 25 November 2008 (UTC)
  • If my learned and gallant colleague has really never noticed the tag at the top of the page, I invite him to consider it. MOS is a guideline; it has no "authority" other than representing the consensus of Wikipedians, which it does not, as to the the actual or desirable usage in English, which it does not. Septentrionalis PMAnderson 21:55, 25 November 2008 (UTC)

So what are we talking about for starting off here? Curly quotes and lede image sizing are two which spring to mind which are constantly quarrelled by people other than the usual suspects. Chris Cunningham (not at work) - talk 15:35, 25 November 2008 (UTC)

Unless curly quotes have popped up again, we actually got consensus on avoiding them; I think I talked with everyone who weighed in. I wouldn't put lead image sizing in the category of issues that cause trouble, at least not yet; there are a variety of legitimate concerns on both sides of the table, and it will probably work itself out. Stay tuned. - Dan Dank55 (send/receive) 17:44, 25 November 2008 (UTC)

I presumed Dan meant such things as the insistence on "logical" quotation. As it is, we get objections every other month or so, by someone who was taught differently, and the same half-dozen voices insist on its manifold virtues. It would be worth seeing if stating those virtues convinced everybody; on the other hand, it would be useful to keep a running record of those it does not convince. Septentrionalis PMAnderson 21:55, 25 November 2008 (UTC)

Curly quotation marks (as to shape) are discussed at Quotation mark glyphs.

Logical quotation marks (as to position) are discussed at Quotation mark#Punctuation.

The same marks can be curly or logical or neither or both.

-- Wavelength (talk) 22:21, 25 November 2008 (UTC)

But logical quotation is the entirely different issue: when does punctuation go inside the quotation marks? MOS present adheres to the position that punctuation in inside only when it occurs in the original; there is an another form, aesthetic punctuation, which always places periods and commas inside; this treats ," as a single conventional mark. The CMOS prefers the latter, as more practical, and it is widely taught, especially in the United States; it is certainly easier to proof. Septentrionalis PMAnderson 03:29, 26 November 2008 (UTC)

• It's illogical and, in terms of WP's critical respect for keeping faithful to the original, can be very misleading. It looks gawky. Why is it "easy to proof" (if that was ever an important consideration here)? Tony (talk) 04:09, 26 November 2008 (UTC)
  • Most of this is WP:IDONTLIKEIT. "Gawky" is in the eye of the observer.
  • Checking whether "logical" punctuation has been done correctly requires checking the punctuation in the original text (which can, in some cases, be impossible to define). This is much harder than checking the mechanical requirements of aesthetic punctuation. Septentrionalis PMAnderson 04:36, 26 November 2008 (UTC)
  • CMOS warns against "logical" punctuation because it is easy to get it wrong. I see no advantage whatever to erroneous "logical" punctuation; plainly Tony does. Perhaps he could explain. Septentrionalis PMAnderson 04:49, 26 November 2008 (UTC)

The first paragraph of Quotation mark#Punctuation says:

The traditional convention in American English is for commas and periods to be included inside the quotation marks, regardless of whether they are part of the quoted sentence, whereas the British style places them inside or outside the quotation marks according to whether or not the punctuation is part of the quoted phrase. The American rule is derived from typesetting while the British rule is grammatical (see below for more explanation). Although the terms “American style” and “British style” are used, it is not as clear cut as that because at least one major British newspaper prefers typesetters' quotation (punctuation inside) and BBC News uses both styles, while scientific and technical publications, even in the U.S., almost universally use logical quotation (punctuation outside unless part of the source material), due to its precision.

-- Wavelength (talk) 21:40, 28 November 2008 (UTC)

Image position

Reywas92 recently added this statement to the guideline: "Images should be inside the section they belong to (after the header and after any links to other articles), and not just before the header." It was taken from "Wikipedia:Accessibility". I've initiated a discussion about this guideline at "Wikipedia talk:Accessibility#Image position"; do join in. — Cheers, JackLee ^–talk– 07:55, 28 November 2008 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Guideline-by-guideline citation of sources

I would like to suggest that the Manual of Style cite beside each guideline the sources that support that guideline. Sources are cited beside entries in the article "List of English words containing Q not followed by U". I see four benefits.

• Maintainers (new and old) of the Manual can assure themselves by inspection that a given guideline has the support of certain sources.
• Maintainers of the Manual can refer to the sources to defend the Manual against its challengers.
• Users of the Manual can assure themselves by inspection that a given guideline has the support of certain sources.
• Users of the Manual can refer to the sources and avoid uselessly challenging the Manual.

-- Wavelength (talk) 04:49, 23 November 2008 (UTC)

Additionally, more details about the source information for the guidelines can be provided in an accompanying page:
Wikipedia: Sources for the Manual of Style. The same treatment (same-page guideline-by-guideline citations and accompanying-page source information details) can be applied to each of the subpages of the Manual of Style.

-- Wavelength (talk) 17:06, 23 November 2008 (UTC)

I'm completely in favor of people who know stuff sharing what they know, so anyone who wants to make a page called "stuff in the style guidelines, and where it came from", will have my undying affection. I've got it on my to-do list to pick out those elements that are well-understood and well-supported by publishing professionals and citable in style guides and references, as a way of making publishing professionals more comfortable on Wikipedia. It's not such a good idea to put this stuff directly on the style guidelines pages, because the most commonly cited reason for ignoring the style guidelines is that they're too long, and that would make the problem worse. - Dan Dank55 (send/receive) 19:33, 23 November 2008 (UTC)

Thank you for your support. The article "List of English words containing Q not followed by U" uses only abbreviations after the entries, and the abbreviations are explained at the bottom of the page. My suggestion is for something similar for the Manual of Style. The extra space occupied would be very small.

If some people ignore the Manual because they find it to be too long, then why not Wikipedia because it has so many articles, or the Internet because it has so many websites? It does not have to be a case of all or nothing. If it would help some people, a notice can be put on the Manual to say that even applying only some of the guidelines is better than applying none of them. Other pages linking to the Manual can also point this out, so that editors are aware of it before they see the Manual. In any case, where guidelines are not applied, other editors can make corrections.

-- Wavelength (talk) 02:30, 24 November 2008 (UTC)

Is Wavelength suggesting WP:MOS should be subject to WP:V, WP:RS, WP:NPOV, etc. just like an article? Sounds good to me. --Philcha (talk) 22:01, 23 November 2008 (UTC)

I had not thought of this suggestion in those terms, but, now that you mention it, I guess I am.
I say "I guess" because I do not know the complete set of guidelines to which an article is subject.
(By the way, I saw on your user page a link to Web Style Guide, 2nd Edition, and I found it to be
very interesting.)

-- Wavelength (talk) 22:28, 23 November 2008 (UTC)

(minor sidepoint) That's actually rather scary regarding the 'standards' section... so old: ie, where you're actually building the site using HTML. A better read in that regard would be Introduction to the Web Standards; Opera. --Izno (talk) 02:58, 25 November 2008 (UTC)

Wavelength, your comment "I do not know the complete set of guidelines to which an article is subject" highlights a serious problem - especially coming from someone with your strong contributions record. At Wikipedia:Village_pump_(policy)#Proposal_to_include_template_.7B.7Bcent.7D.7D_on_every__discussion_page one editor estimates 300. I think the number of policies and guidelines is a serious issue. I've raised this at Wikipedia:Village_pump_(policy)#Too many guidelines and policies.? --Philcha (talk) 09:56, 25 November 2008 (UTC)

Izno, thanks for the link to Introduction to the Web Standards; Opera. However I was referring to what readers experience rather than the techniques for producing the experience. --Philcha (talk) 09:56, 25 November 2008 (UTC)

Philcha, I have not found the number of policies and guidelines to be a serious problem, nor the size of the Manual of Style, nor the size of Wikipedia, nor the size of the Internet. A storybook is read from cover to cover, but a reference work is consulted for what is of interest at the moment. Lists, categories, tables of contents, indexes, and search functions simplify the work of zeroing in on relevant information. I have not, so far, worked with images on Wikipedia, except occasionally to edit their captions, so I have not concerned myself with policies or guidelines about images. Others are establishing those policies and guidelines, and others are applying them, so that I and millions of other users can benefit from them.

-- Wavelength (talk) 15:41, 25 November 2008 (UTC)

Wavelength, I'm referring to the fact that learning all the relevant policies and guidelines is a more onerous research task than writing a well-sourced article on a scientific subject.

BTW in what sense of "interesting" did you find Web Style Guide, 2nd Edition "very interesting"? --Philcha (talk) 11:49, 28 November 2008 (UTC)

I found it to be interesting in a positive sense, and as something which I wish to investigate further. Also, it may be of positive interest to watchers of this page and maintainers of the Manual. Of course, I can not vouch for what I did not see, but what little I did see sufficed for me to list it on one of my subpages.

By the way, if policy A seems to contradict policy B, there can be a hierarchy of policies, where policy A trumps policy B, or vice versa. Additionally or alternatively, one can say that policy A applies in a given situation, unless certain features are present, and then policy B applies. If I remember correctly, such a system is used in the Psychodynamic Diagnostic Manual.

-- Wavelength (talk) 23:45, 28 November 2008 (UTC)

Hi, Wavelength. I'm not sure the exmaple of the Psychodynamic Diagnostic Manual is a compliment to WP:MOS. What does one need in order to understand MOS - psychiatric training or psychotherapy? --Philcha (talk) 00:17, 29 November 2008 (UTC)

Philcha, I meant neither a complement nor a compliment. When I said "such a system is used", I was making an analogy (a comparison). In the PDM, if I remember correctly, a diagnosis is associated with a list of symptoms. If a patient has a minimum number of those symptoms (for example, seven out of ten), then that diagnosis is a made of that patient. However, if a minimum number from another list of symptoms is found, then that finding overrides the diagnosis that would otherwise be made, and a different diagnosis is made.

In Wikipedia's policies and guidelines, it might be that, if policy A usually applies in a given situation but certain features are present, then policy B applies. I hope that this clarifies what I said. We all need to be careful with analogies. Otherwise, we could be out of the ball park, on a wild goose chase, barking up the wrong tree.

-- Wavelength (talk) 02:23, 29 November 2008 (UTC)

Woof :-)

Back to the serious stuff. We seem to agree that WP:MOS should be subject to WP:V, WP:RS, WP:NPOV, etc. just like an article. The question is how to proceed. How about a community-wide RfC, like the recent one about Notability? --)

-- Philcha (talk) 10:37, 29 November 2008 (UTC) [signature and timestamp constructed from history by Wavelength]

I am ready for a Request for Comment. Instructions are at Wikipedia:Requests for comment. If that results in a "No" decision, my suggestions could still be followed, as I described them at the beginning of this section, before this subjection was mentioned to me.

-- Wavelength (talk) 23:31, 29 November 2008 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Images

I see no compelling reason for the guideline, "Images should be inside the section they belong to (after the heading and after any links to other articles), and not above the heading." to exist. If there are placement reasons (such as other images in a section) for images to be at the tail end of another section, then it does not do any harm to do so. The goal of images is to clearly illustrate encyclopedic content and concepts in the article, and this particular guideline doesn't support that goal in a way that makes it a necessary addition to MOS. Steven Walling (talk) 22:36, 29 November 2008 (UTC)

• If an image is outside of the section it illustrates, it confuses the reader. That should be obvious. This isn't "wiki stalking", by the way, I had this page on my watchlist already. FunkMonk (talk) 22:41, 29 November 2008 (UTC)

I'm glad you joined in the discussion, no worries about "wiki stalking" (I'm all about AGF). I don't think it confuses the reader at all: Putting the markup for images outside the section they illustrate doesn't necessarily not place an image within the section it is meant to illustrate, as you can see in Domestic sheep. Some images can be placed just above a header, and still appear within the section. It's sometimes necessary to put sufficient space between images so that text isn't crowded. Steven Walling (talk) 22:46, 29 November 2008 (UTC)

See the talk page of Domestic sheep, where I've answered already. FunkMonk (talk) 22:58, 29 November 2008 (UTC)

• This is already being discussed elsewhere - see 2 sections up. Personally the suggestion that every image has a "section they belong to" just seems wrong to me. Johnbod (talk) 00:00, 30 November 2008 (UTC)
  • An image "belongs" to a section in the sense that it is relevant to it and the subject of it is discussed in it. If there's a section about the beak of a bird, an image of the beak would "belong" in that section. FunkMonk (talk) 01:20, 30 November 2008 (UTC)

Wow, thanks! but many images are relevant to several sections, or the whole article. Johnbod (talk) 14:58, 30 November 2008 (UTC)

Please join the discussion at "Wikipedia talk:Accessibility#Image position". — Cheers, JackLee ^–talk– 07:45, 30 November 2008 (UTC)

That should be clarified. I would have taken belong = "In edit space, Image:Foo is after the section header for". Septentrionalis PMAnderson 01:11, 1 December 2008 (UTC)

Individual wikiprojects are deleting infoboxes from articles

Several people from musical Wikiprojects are systematically deleting infoboxes from biographies that are covered by their projects:

• "Rmv infobox as these are not used for classical musicians per Wikipedia:WikiProject Classical music#Biographical_infoboxes)
• "Rmv infobox as these are not used for composers, per Wikipedia:WikiProject Composers#Lead section) "

Here is an example at: Milton Adolphus

It appears that they are trumping Wikipedia biographical policy with their own subset of rules. It would be like the New York Wikiproject deciding that people born in New York City don't get infoboxes, or don't get birth dates added, or any other global Wikipedia rule. It destroys the consistent look and feel of biographies from article to article. Anyone else have an opinion? --Richard Arthur Norton (1958- ) (talk) 06:33, 29 November 2008 (UTC)

Which WikiProjects? They should be given a medal. Mostly, infoboxes are a huge weeping sore on an otherwise good article. Dreadful idea that spread like leprosy. They tend to repeat information that is already in the main text, and/or to falsify it by shoving it into awkward categories. There should be a project-wide audit of them. Tony (talk) 06:51, 29 November 2008 (UTC)

Hear hear!!! I've been fighting what I thought was a lone vendetta/campaign against infoboxes since day one. I have never found that they improve articles, in fact quite the reverse. It would be interesting to go back on their history and see who decided to foist them on the world at large. It's high time that we started a movement to outlaw them!! Rotational (talk) 10:31, 29 November 2008 (UTC)

• • The lede to the article also repeats information in the article such as birth and death and what made them notable. It is 100% redundancy. Should we remove the ledes from all articles, or just the classical composers? --Richard Arthur Norton (1958- ) (talk) 21:07, 29 November 2008 (UTC)

Infoboxes are not always a good thing, and sometimes people try to cram too much information in them, when it would be better to have most of the information in tables in the article. Nevertheless, as a general rule some kind of small infobox is usually useful.--Toddy1 (talk) 06:54, 29 November 2008 (UTC)

• • Cram is such a loaded word, editors fill in the info fields. --Richard Arthur Norton (1958- ) (talk) 21:07, 29 November 2008 (UTC)

I agree with Toddy1. An infobox that extend belows the TOC generally creates problems: creates a barrier between readers and the real info; makes it hard to add images that provide useful into in the first section(s) of main content. The use of widescreen monitors makes layout problems more difficult because it reduces the height of text blocks. The layout problem is most acute in articles where there's not much to say in the lead.

The fact that "sometimes people try to cram too much information in them" (infoboxes) may reflect political compromises that are better for WikiProject members' egos than for readers. The infobox at Strom Thurmond is ridiculously long and needs severe pruning.

• Strom Thurmond looks fine, it would look odd to be 100 lines long in an article of 10 lines, but how could that happen, it is long because his career was long. I all depends on why you came to the article. Was it to read a complete biography, or was it to find his years of service as a senator, or find his wife's name? We don't have a crystal ball. Try finding a single fact by reading the entire article, it is frustrating. --Richard Arthur Norton (1958- ) (talk) 21:18, 29 November 2008 (UTC)

In a few cases the heights of infoboxes may vary widely, e.g. the one at Arthropod is right on the limit because arthropods have so many subphyla and classes. In other cases variations in the amount of text content may cause difficulties, e.g. in the last version of Milton_Adolphus that had an infobox, there would have been a problem if the main content contained any actual text.

Rather than try to lay down the law, it would be better to have discussions with Wikiprojects as required, and draw their attention to cases where the infobox runs into the main text. --Philcha (talk) 10:18, 29 November 2008 (UTC)

If people don't have time to read a multi-page article, the infobox gives a good, quick overview. I often find them quite helpful.FunkMonk (talk) 20:46, 29 November 2008 (UTC)

• The infobox also automates information retrieval. Read the article to search for the spouse, or search for "spouse=". The formatted fields also allow for all this data to be retrieved and indexed automatically so someone can query "who was Abraham Lincoln married to" and get the answer. --Richard Arthur Norton (1958- ) (talk) 21:07, 29 November 2008 (UTC)

• I am sure there are lots of aesthetic reasons why some people don't like infoboxes, but the question is: can the New York Wikiproject decide that people born in New York don't get infoboxes, or people born in New York that are living don't get birth years put in, or don't get photos until they die? Or is this a global Wikipedia concern, so the look and feel is consistent? --Richard Arthur Norton (1958- ) (talk) 21:12, 29 November 2008 (UTC)

Also please stop removing the infobox at Milton Adolphus while we are discussing this, it shows bad faith. Let everyone see for themselves if it is useful to them. --Richard Arthur Norton (1958- ) (talk) 21:14, 29 November 2008 (UTC)

Infoboxes are very useful to different groups of readers, in many articles. Angrily dismissing the use of "all infoboxes" (such as the chemistry infobox, or film infobox, or ship infobox, etc), is counterproductive to fruitful discussion.

Out of the 15 most recently featured articles, only 4 do not include infoboxes: Kannada literature in the Western Chalukya Empire, Mozart family Grand Tour, Romeo and Juliet, and Caspar David Friedrich. The first two of those don't need infoboxes. The last two are interesting examples for this discussion:

• Wikipedia:WikiProject Shakespeare does not use {{infobox Play}} in any of its play articles (archived discussion) for legitimate reason (though they do use one at the FA biography William Shakespeare).
• The article on Caspar David Friedrich had an infobox until November 16, when the FAC nominator removed it hours before the nomination itself. (with no objections at the talkpage or FAC).

So, there are examples of per-wikiproject and per-article decisions not to have infoboxes. I agree with the decision at the play articles, and disagree with the decision at the biography: it is harder to determine the man's final age and location at death, and any of the other fields at {{Infobox Artist}} would make informative details more readily available to readers looking to see if there are connections to other topics they already know about (patrons, etc).

As for Milton, we'd need to track down the history of {{Infobox Composer}} (deleted in Oct 2006 because "been superseeded by Template:Infobox musical artist", which itself currently states that it is "for non-classical musician articles"). At a glance, it (Wikipedia talk:WikiProject Composers/Infobox debates) looks like there is a lot of intractable history. See Template talk:Infobox Musical artist#Where is the infobox template for classical musician articles? for the most recent thread. Perhaps someone else can research that, and let us know what the pertinent objections are, and whether they can be usefully worked out? Until then, I agree that an {{Infobox Person}} is potentially suitable and useful for all articles about people that don't have a more specialized infobox available. -- Quiddity (talk) 23:37, 29 November 2008 (UTC)

• Biographical infoboxes are also often a menace in articles on (visual) artists, where the Visual arts project is agreed they should not be preferenced over works by the artists (whether infoboxed or not) as lead picture, but they are not yet being hunted down. Frankly the biography project is wasting its time if it tries to exert a common style on all biographies where this conflicts with more specific subject-area projects, who normally contain the people who do all the work in their areas. Johnbod (talk) 23:56, 29 November 2008 (UTC)
• (X-posted from Milton Adolphus & edited for context) The Composers wikiproject has had an extensive discussion about the merits of infoboxes on composer pages and there is overwhelming sentiment against them. I suspect RAN didn't know this and that is why we have the current dispute. I concur completely with the idea of global consensus, but infoboxes are not sanctioned Wikipedia policy. Hence, as Andy Mabbett discovered, it is entirely reasonable for an individual project to determine a best-practice within a certain area and to uphold it. Clearly no group of editors owns a topic but I refer interested editors to this ANI discussion on the topic and I suspect that if this dispute continues the results will be similar. Eusebeus (talk) 00:19, 30 November 2008 (UTC)

That just highlights the major issue with most projects, for the most part they believe they do own articles. They cannot 'overrule' editors working on individual pages so every time someone disagrees the project consensus becomes void and ultimately impossible making the whole discussions pointless. --neon white talk 23:25, 30 November 2008 (UTC)

Just to add a footnote here. The Composers and the other classical music projects do not have any guidelines about infoboxes - only about biographical infoboxes. It's important to make this distinction. Nobody is objecting to the use of these boxes for factual, quantitative information (as for example the excellent geographical ones). The problem is with subjective information relating to people.

• What information in the box in question is subjective? His date of birth? His date of date? His place of death? --Richard Arthur Norton (1958- ) (talk) 00:32, 2 December 2008 (UTC)

It may also be worth noting the long debate about popular musician biographical boxes at the Music Project which extended through September and October (now housed in six archives), see Music Project Archive 9 etc. This indicated the level of unpopularity of these boxes throughout the whole range of musical WP. --Kleinzach 01:05, 30 November 2008 (UTC)

I'm glad to be reminded that there are intelligent WikiProjects. I've found infoboxes very useful at times. None of these useful infoboxes have been the silly things that litter the top right of biographical articles. As a presumably "mature" example of the latter -- one that's the result of much to-ing and fro-ing among a number of editors (rarely if ever including myself) -- I present that on Vladimir Nabokov. This gives straightforward biographical info that's not essential to an understanding of him -- nobody's opinion of his works would change if it turned out he was born in May rather than April, etc etc -- and that's anyway easy to find in the main part of the article. He's said to pertain to two literary movements, both of which are labels that apply to some stuff that's like VN's and to other stuff that isn't at all (and that additionally may be near-complete bollocks); VN, who was scathing about lazy references to "Romanticism" etc, would be grimly amused. The list of three "Notable work(s)" includes three excellent works but among them at least one surprising choice -- why Real Life and not The Gift? The list of influences on him is pretty much a not-bad list of writers to whom he referred approvingly, but unsurprisingly it's incomplete (if Mayne Reid, why no H G Wells, and VN at least once stated that he wished he had the chance to teach Shakespeare) and anyway it isn't a list of what influenced him. The list of people he influenced is a list of people who (a) more or less credibly claim he influenced them or (b) are said by some "RS" to have been influenced by him; as some of these people seem rather obscure, it's hard for me not to suspect a wee bit of coat-racking here. This infobox could be worse -- it doesn't (yet) have little flags -- but it's better removed. I'm tired of arguing with WP's Nabokovians so I leave the silly thing; but when it comes to biographical infoboxes elsewhere, I'm active/vocal in removing the stupid things. -- Hoary (talk) 06:48, 30 November 2008 (UTC)

PS 1. The few useful infoboxes include those for software: when looking for a program that promises to do something useful for me, I often find that categorization (which I might expect to do the job) isn't sufficient, and thus I want to be able to see fast whether each of a series of articles I'm skim-first-glancing at is about something that runs under the operating system of my choice, has the payment model of my choice, etc. ¶ 2. Particularly daft infoboxes include those for universities: each an odd congeries of gross oversimplification (one year given for foundation, one location given for campus), risible pseudoprecision (student number to the nearest person, no date specified), areas in olde-worlde "acres" (even those readers interested in further education mustn't be confronted with any pressure to consider metric units), trivia (university colors), etc. -- Hoary (talk) 07:04, 30 November 2008 (UTC)

The problems are similar with artists, where the selection of "works" (because almost all artists have far more works than writers) is likely to lead to even sillier or more misleading results. These boxes are often added in WP:BIO drives by editors with no knowledge of the subject, whose judgement of "movements" "influences" etc is most likely to be wide of the mark. But I approve of very many types of infoboxes - sports people, films, species, and many types of scientific ones and so on can be very useful, and even look good. Johnbod (talk) 11:50, 30 November 2008 (UTC)

• Which style guide is most appropriate for the inclusion of intelligent guidelines on where to and where not to use infoboxes? I presume that some people believe that this central MoS is it. True? Tony (talk) 08:03, 30 November 2008 (UTC)
• Biographical infoboxes often tend to oversimplify things (or to overemphasize unimportant issues). It is perfectly acceptable that some projects decide not to use them. This is one of the issues on which there has been no consensus for several years, and the standard approach in no consensus stylistic issues is to let the primary author decide. Kusma (talk) 11:30, 30 November 2008 (UTC)

Funny ... if that is the case, how were the style guides ever started? It's just the kind of matter on which users need guidance—the current situation is most unsatisfactory. Tony (talk) 14:17, 30 November 2008 (UTC)

Often when things get out of hand. A good example of that is Wikipedia:Manual of Style (icons), before that guideline was created almost every article had a little flag icon. Garion96 (talk) 14:40, 30 November 2008 (UTC)

I was thinking of stuff like WP:ENGVAR - if it doesn't really matter either way (and different choices that are decent exist), inconsistency is much preferable to forcing a randomly chosen standard down everybody's throat. Kusma (talk) 16:46, 30 November 2008 (UTC)

I don't disagree that projects can decide on their own whether to infobox or not, however, as noted above, infoboxes can serve to automate several things including collection of metadata, automatic category population, and so forth. For that reason, we should make sure that infoboxes can be filled but have a way to be called out as hidden via CSS so that they are still doing these automated aspects but are not shown to the end reader if a project decides against showing them. I can see a potential way to make this an option in user-prefs, but lets start with the easy way. --MASEM 14:47, 30 November 2008 (UTC)

I think this is already being done by using hidden Persondata. --Kleinzach 10:10, 1 December 2008 (UTC)

• I don't share your faith in the ability of infoboxes to provide uncontaminated and useful data. To start with, they're not used in every article of a type. And even if they did provide such metadata is it important compared with the potential compromises in individual articles? —Preceding unsigned comment added by Tony1 (talk • contribs) 14:52, 30 November 2008 (UTC)

Frankly Infoboxes are unpopular at the Visual Arts project..They are ungainly, bureaucratic, and unattractive to many..At best they should simply be optional....Modernist (talk) 14:58, 30 November 2008 (UTC)

• (reply to Tony after ec) And you do have faith in the ability of articles to "provide uncontaminated and useful data"? The accuracy of either articles or infoboxen is directly proportional to the attentiveness of contributing editors. I'm interpreting "uncontaminated" here to be accuracy, although you may have something more pejorative in mind. Usefulness is a somewhat subjective consideration. What one project considers useful may be anathema to another project, which I suppose is the genesis of this thread. How best to address the situation is not helped by blanket dismissals of what many editors view as valuable. older ≠ wiser 15:02, 30 November 2008 (UTC)

• • If there was a way (which there is, it's just template programming) to make them completely hidden from readers' view if the project didn't want to show them, then there is no reason they couldn't be used in every article where it was appropriate - including using multiple completely hidden infoboxes if a topic spans several WPs. The key is that they have to be able to be hidden - still part of the wikitext, but wrapped in a CSS display="hidden" div. (this would allow users that also "must" have infoboxes to be able to make a custom CSS to show them. There's only one aspect that could be a problem and that is how NFC images would be dealt with (one could "hide" the use of a NFC image in such a case, it would meet the NFC to be used in one article but it wouldn't be shown.. I'm sure there's a way to fix that however). --MASEM 15:04, 30 November 2008 (UTC)

Recently at Caspar David Friedrich the infobox was removed and the article achieved FA status..with no objections to the lack of an infobox although I only reluctantly agreed to its removal..Clearly it isn't necessary to the quality of articles...Modernist (talk) 15:12, 30 November 2008 (UTC)

From a visual arts point of view, I prefer not to use infoboxes for two reasons. 1. For artists including them they make no sence, artists are not species and cant be sucinntly defined. 2. Its preferable that the lead has two images; a portrait an major work in the case of an artist bio, and a reproduction of the artwork and a work it was closely influenced by in the case of a painting. Also, I dont see why a project should have authority over articles under the remit it itself has defined. Ceoil (talk) 15:13, 30 November 2008 (UTC)

Why are artists different from other people? Politicians aren't species either (jokes aside). ♫ Melodia Chaconne ♫ (talk) 17:12, 30 November 2008 (UTC)

Artists are different because their notability derives from individual works, not from holding an office or appointment. Thus their careers cannot be so easily summed up. As others have said already, I don't think consistency for its own sake is worth having infoboxes that contain very little useful information. Chick Bowen 17:18, 30 November 2008 (UTC)

• So what is the objection to the one at Milton Adolphus. Is it because it uses the people infobox, and it is demeaning that he is just a person and not an artist? Is it because of his birth and death date, or naming his spouse and children? What quality of an artist transcends them beyond a person that the infobox is not capturing or is confusing to people? And why is it any different than scientists? They are creative too, and hard to define. --Richard Arthur Norton (1958- ) (talk) 21:32, 30 November 2008 (UTC)

Do pay attention - he is not an artist in the sense used in this discussion, but a musician, and the music project have decided against using infoboxes for the reasons they have explained above, which everybody else here seems to think they are perfectly entitled to do. Johnbod (talk) 23:34, 30 November 2008 (UTC)

• Question What are you going to do when someone decides to create them all again? There's nothing really you can do. They are used project wide and their removal would have to be project wide and have a project wide consensus. --neon white talk 23:28, 30 November 2008 (UTC)

• Is your argument he is not a person? The box removed is the people box, not the musician box. He is also a vaudevillian, as much as a composer. You seem opposed to the concept of boxes, not the pigeonholing of occupations. --Richard Arthur Norton (1958- ) (talk) 01:14, 1 December 2008 (UTC)

I am baffled by the argument that the Composers Wikiproject "owns" Milton Adolphus. He is covered by other projects, including Wikiproject New York City, which has not come to a decision that an innocuous infobox with basic biographical information is what was called a "disinfobox". I'd expect a far better justification than a concern that people reading the article will only read the infobox (see here). Alansohn (talk) 04:17, 1 December 2008 (UTC)

Wow, looking at that edit history, this is indeed getting ridiculous. It's about as blatant a violation of WP:OWN as it gets, really. And yeah, saying it "competes with the article" makes about as much sense as saying the lead will. ♫ Melodia Chaconne ♫ (talk) 04:52, 1 December 2008 (UTC)

I agree WP:OWN is relevant here, the attitude of some members of WP:BIO is reminiscent of the Maasai attitude to cattle - wherever they are in the world, they all belong to them. Johnbod (talk) 11:27, 1 December 2008 (UTC)

Richard Arthur Norton (1958- ), we have had this discussion for many times. The following archives document the various infobox discussions in 3 projects

• Opera Project: [9] [10] [11] [12] [13]
• Composers Project: [14] [15] [16] [17] [18] (scroll down) [19] [20] [21] [22] [23]
• Classical Music Project: [24] [25] [26]

The information in infoboxes is not sufficiently flexible, can lead to oversimplification and ambiguity, and, when placed at the head of the article, simply repeats information that should be in the first sentences in any case. Thanks - Jay (talk) 05:48, 1 December 2008 (UTC)

Yes it repeats info, but so what? That's the point. It gives a nice quick glace at certain things (and one thing often buried in the article is age of death, and if they are living, current age is not given in the article at all). I think my basic issue with all this is why is it ok for some people to have them ("oh I don't care about people under THAT wikiproject, they can make thier own decisions"), and also trying to shoehorn arguments that apply to all articles ("they repeat info", etc) into a reason they aren't used on X project's articles. As for "lead to oversimplification and ambiguity", well, WP:SOFIXIT. ♫ Melodia Chaconne ♫ (talk) 12:47, 1 December 2008 (UTC)

• Then we shouldn't have Wikipedia, people use it as a crutch when they should be reading a comprehensive 300 page biography. Even a biography is a poor substitute. People should go to an archive and read original materials and synthesize their own opinions about important people. They should hold in their hand original compositions and read letters written to and from important people. How can Thomas Edison be distilled into a 300 page biography when he left 5 million pages of documents that chronicle his extraordinary life and achievements? --Richard Arthur Norton (1958- ) (talk) 06:10, 1 December 2008 (UTC)

Disinfoboxes

A box aggressively attracts the marginally  literate eye with apparent promises to contain a  reductive summary of information that can't be  neatly contained. Like a bulleted list, or a time-  line that substitutes for genuine history, it offers  a competitive counter-article, stripped of nuance.  As a substitute for accuracy and complexity a box  trumps all discourse.                —courtesy of User:Wetman

From the perspective on an editor who just looked at the article on Milton Adolphus for the first time I would have to say that I see no beneficial use for an info box at this article. The biography is in itself so short that the infobox merely parrots back what is already on the view screen (the info in the info box can be seen at the same time as the entire biography section with the same info). If the article was larger and more detailed I could see a reasonable arguement for dissementing essential information into an info box. As it is, it seems like a rather pointless/useless tool that causes un-needed redundancy in this particular article.Nrswanson (talk) 06:29, 1 December 2008 (UTC)

• The lede is 100% redundancy too. --Richard Arthur Norton (1958- ) (talk) 06:31, 1 December 2008 (UTC)

• That is rather a false analogy. A lede's function is to give an overview of an entire article but not to categorize the information into a pre-determined organizational structure that may or may not be suitable for an individual article. The lede is also primarily responsible for clearly establishing a subject's notability (see WP:LEDE), something that an info box can not do. The lede may also contain an overall perspective or view of a topic that may not be stated anywhere else in the article, thereby containing original content which is not the case in an info box. A lede has the further benfit of being able to address complicated issues with nuance in order to maintain accuracy which is less feasible in an info box. Further, since a lede is a standard literary device for academic papers it is an established format and essential element for the prose section of the article. An info box in my view is neither essential nor necessary. It can however be useful in some but not all articles. In general I would say that most articles with info boxes right now would probably be better off without them.Nrswanson (talk) 06:47, 1 December 2008 (UTC)

• The problem is that an infobox usually can't summarise any of what makes an article interesting. For example it can't explain why Beethoven's music was revolutionary, or why Opabinia lit a fire under the Cambrian explosion debate. I hardly ever read them, and would not be surprised to find that many readers ignore them. On the other hand a lead can summarise what makes the subject of an article notable to readers
• I admit there are a few useful infoboxes, e.g. at Contract bridge and Chess. Unfortunately most are just infodumps, often meaningless to non-specialists and redundant for readers with good prior knowledge.
• I think the problem is that infoboxes have become a shibboleth, to show off that the article was written by true MOS believers and / or afficionados of the subject, not to help readers. If every item in an infobox was scrutinised rigorously by the criterion "Would the reader be worse off if the infobox did not contain this?" (i.e. remove unless there are strong reasons for "yes"), many infoboxes would vanish and the rest would be shorter and more useful. --Philcha (talk) 10:20, 1 December 2008 (UTC)

Forum shopping

Richard Arthur Norton (1958- ) has now referred this issue either under the title "Individual wikiprojects are deleting infoboxes form articles" or "WikiProject Classical music is deleting infoboxes from articles under their control" to:

• Template talk:Infobox Person
• Wikipedia talk:Notability (people)
• Wikipedia talk:Manual of Style
• Wikipedia talk:WikiProject Biography
• Template talk:Infobox Musical artist
• Template talk:Infobox Actor

(With one crossreference to: Wikipedia_talk:Manual_of_Style on Wikipedia_talk:WikiProject_Council)

But not to the related Composers Project. --Kleinzach 02:11, 1 December 2008 (UTC)

Nothing sinister, I am notifying potentially aggrieved parties, the first step in any law based system, and asking them to comment where the discussion is taking place. Posting notices in targeted forums conforms with Wikipedia policy. It would be egregious to not inform others of policy decisions affecting them being held in remote areas of Wikipedia. As I said earlier, this isn't about composers, or any other narrow category a biography belongs to, its a global Wikipedia policy for biographies. The person in question is as much a vaudevillian, a Yalie, and a New Yorker as he is a composer. --Richard Arthur Norton (1958- ) (talk) 06:02, 1 December 2008 (UTC)

There is also a "global Wikipedia policy" for composers, namely that they do not have infoboxes. You have not given any reason why WP:BIO should take precedence, and override the mormal rule that the primary editors should decide in such cases. Would you put "vaudevillian" in the infobox, btw, because he sometimes played in jazz bands? Perhaps you would, itself an excellent example of the problems drive-by BIO editors routinely cause. Johnbod (talk) 11:27, 1 December 2008 (UTC)

The mater was already raised, two days earlier, at Wikipedia talk:WikiProject Composers#Biographical infoboxes: Milton Adolphus by, er, you. Did you notify the named individuals discussed there that they were mentioned? BTW, your choice of sub-heading does not assume good faith. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 09:21, 1 December 2008 (UTC)

Richard Arthur Norton (1958- ), it would be helpful if you would post at all the other Talk pages "please contribute at Wikipedia_talk:Manual_of_Style#Individual_wikiprojects_are_deleting_infoboxes_from_articles", so that this becomes a centralised discussion. --Philcha (talk) 09:48, 1 December 2008 (UTC)

• You must not looked at any of the postings, they all direct to this page if they were posted after this page became the central repository. Notice that it took multiple postings in targeted forums before this discussion here took hold. --Richard Arthur Norton (1958- ) (talk) 20:15, 1 December 2008 (UTC)

If any of you don’t know, this is not the decision made by Classical Music project alone but the consensus made by 3 different projects participants - Wikipedia:WikiProject Composers, Wikipedia:WikiProject Classical music, Wikipedia:WikiProject Opera for composers, conductors and opera singers. And also, Richard Arthur Norton (1958- ) has posted about this issue in many discussion page and this is seriously confusing and unorganized. If we were to agree or disagree on something, please centralized the discussion page and call up all related participants. Since this matter involves a composer, in which so happen to be a Classical Music composer and; since Opera is part of Classical Music, we need to re-discuss about this matter all over again by calling the correct parties. I failed to see why Richard Arthur Norton must post this issue in various “talkpage” that has less relation with this such as “template talkpage” etc . And say that we finally agreed to put an infobox for Milton Adolphus, these 3 projects must reconsider to add infobox to all other Classical / Opera composers, conductors and singers. Is it fair for these 3 projects to revise all their existing articles just because of one composer from New York? I think we have to be a bit more practical and logic here. Besides, up until today, I still can’t see why is it so important to have an infobox. - Jay (talk) - Jay (talk)

• The discussion has absolutely nothing to do with classical music, that is why it is not posted there. We are as much discussing the narrow case of Adolphus as well as the global issue of whether any project can create a subset of rules that conflict with global Wikipedia style. The argument is: can New York Wikiproject change the standard style for people born in New York because, lets say, they believe that a still images can't capture the dynamic nature of a person born in New York City. --Richard Arthur Norton (1958- ) (talk) 20:21, 1 December 2008 (UTC)

Conversly, what makes Wikiproject New York or Wikiproject Biography so special that they can enforce their own opinion about style on "their articles". The answer is they can't. It's WP:instruction creep and a violation of WP:OWN. In my opinion, no project can enforce the inclusion of an info box. However, I have no problem with a project banning the use of info boxes within a particular series or topic of articles if info boxes present a valid problem in those areas.Nrswanson (talk) 20:31, 1 December 2008 (UTC)

Why do you feel they are allow to ban them, but not enforce them? That doesn't really make any sense. ♫ Melodia Chaconne ♫ (talk) 21:56, 1 December 2008 (UTC)

I am glad you asked. There are three issues at play here: style, communication, and content. A policy enforcing the implementation of an info box is a style/communication decision. The argument for an enforced info box is that the info box will improve the look/design of the article as well as providing a useful means of disseminating an articles information. However, this view fails to recognize that not all articles are best served in terms of style and communication by an info box. Many articles are better off without them. See Wikipedia:DIB for a more thorough explanation. Therefore I would oppose any policy that blithely imposes an info box on any article without considering the unique needs of that individual article. On the other hand, banning info boxes from certain articles for content reasons is perfectly legit. If an info box is going to present a consistent problem within a particular area of articles by creating an inaccurate presentations of content, then I think a ban is warranted. If you want a detailed example of such a case I can provide one for not including info boxes on opera singer articles, but it will be lengthy.Nrswanson (talk) 23:47, 1 December 2008 (UTC)

Five problems

Neon White's comment hits the nail on the head - this sort of problem comes up with alarming regularity on here. We need establish some sort of community agreement on:

1. whether Wikiprojects should have the capacity or ability to make style recommendations,
2. whether wider community input or notification is expected, or whether decisions can be made purely in-project,
3. whether Wikiprojects have a right to enforce these recommendations on articles over the will of other editors of that article,
4. what happens when the recommendations of Wikiprojects clash with other Wikiprojects that have templated the same article,
5. whether Wikiprojects' recommendations can justifiably run against the usual advice from WP:MOS or WP:NAME (eg WP:NC(flora) which does not necessarily prefer most common usage, instead picking titles justifiable for other reasons)

As I suggested here, I feel a lot of the problems would be avoided if the proposal generation happened in Wikiprojects, but the guideline formation and consensus building happened in a more centralised forum.

Knepflerle (talk) 11:06, 1 December 2008 (UTC)

No, I don't agree. If you read the discussions that have taken place in the past (for example here), you'll see that they have not been about editorial 'style' - but about content.

Ancillary information - such as infoboxes - can be difficult to integrate with the main content of articles. In the case of these biographical infoboxes it's proved impractical because of the wastage of everyone's time. --Kleinzach 13:10, 1 December 2008 (UTC)

They are related. Whether infoboxes are viewed as a method of presenting information (framing as a style issue) or information themselves (framing as a content issue) is playing with semantics; all that decides is if the WT:MOS is the correct place for this discussion.

The issues I mention remain; what is the relative remit of the MoS, Wikiprojects and the editorial community of a given article in these matters? How are the decision-making powers of the three to be balanced when they clash, as happens again and again? Knepflerle (talk) 14:33, 1 December 2008 (UTC)

As far as I can see Wikipedia:Manual_of_Style_(infoboxes) does not prescribe or even recommend the use of infoboxes. It defines some requirements that infoboxes should meet if used, and describes some useful techniques. Likewise I don't see that any part of Wikipedia_talk:Manual_of_Style_(infoboxes) prescribes or recommends the use of infoboxes. So I think it's for Wikiprojects to decide how and where to use them. --Philcha (talk) 15:20, 1 December 2008 (UTC)

I started this section to highlight general problems, rather than focus on infoboxes but as an example - why should a Wikiproject decide what happens on an article if it goes against the wishes of the usual editing community of that article, just because someone slapped a template on the talk page once claiming it for that project? What if the article is has been template-claimed by two projects, one which mandates templates and the other not? Does a Wikiproject's decision on an infobox supercede what is written at WP:MOS(infoboxes) as an expression of community consensus, seeing as the discussion was decentralised and most editors were not aware of its existence?

In short, can a small number of editors agreeing on infobox guidelines on a distant wikiproject page impose their will on articles templated in the name of a wikiproject, even if it goes against the will of the local editors of that page, or against the wider community norms expressed in centralised guidelines? If so, are the community happy giving Wikiprojects this power over anything they can template? Knepflerle (talk) 15:43, 1 December 2008 (UTC)

Normally the editors of the actual article should decide, but the lead sentence could also be a guide as to the most relevant project, who should have priority. To use RA Norton's example here, if the article begins "Fred Foo (1900-1977) was a New Yorker..", or "New York politician" then the New York project may be justified in asserting its policy. If it begins "Fred Foo (1900-1977) was a composer..." or "baseball player..." then those projects would seem the most central. Sadly for WP:BIO, few articles begin "Fred Foo (1900-1977) was a person..." In the case actually began with here, a musician & composer who lived most of his adult life not in New York, the music projects seem the most relevant, though I notice the row over the infobox is between editors who have not written any of the text. Johnbod (talk) 17:02, 1 December 2008 (UTC)

While Knepflerle's questions are valid, it appears that they are not MOS-specific and that Village pump (policy) would be a more appropriate place to discuss them. --Philcha (talk) 17:08, 1 December 2008 (UTC)

There is now a discussion at the |Village pump. --MASEM 18:25, 1 December 2008 (UTC)

I propose we close down and archive this discussion here. --Kleinzach 02:38, 2 December 2008 (UTC)

As there have been no objections I have archived this. --Kleinzach 23:42, 2 December 2008 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Another new section under Punctuation

In line with recent changes to include punctuation marks that had not been covered, I have altered the subsection dealing with exclamation marks and question marks to include also periods (full stops). These three are sometimes discussed together as sentence-enders, and it is perhaps most efficient for us to follow that practice. The text includes the content of a subsection I have now deleted – concerning spaces after the end of a sentence. The new subsection therefore gathers together all that is relevant to ending a sentence, or at least links to subsections that deal with exceptions:

Punctuation at the end of a sentence

• Periods (full stops), question marks and exclamation marks are the three sentence-enders: the only punctuation marks used to end sentences.
• In some contexts, no sentence-ender should be used; in such cases the sentence often does not start with a capital letter. See Quotations, Quotation marks and Sentences and brackets, above.
• Question marks and exclamation marks may sometimes be used in the middle of a sentence (Why me? she wondered; The door flew open with a BANG! that made them jump).
• Along with commas, semicolons, and colons, sentence-enders are never preceded by a space in normal prose.
• There are no guidelines on whether to use one space or two after the end of a sentence (see Double-spaced sentences), but the issue is not important, because the difference is visible only in edit boxes; i.e. it is ignored by browsers when displaying the article.
• The exclamation mark is used with restraint: it is an expression of surprise or emotion that is generally unsuited to a scholarly or encyclopedic register.
• Clusters of question marks, exclamation marks, or a combination of them (such as the interrobang) are highly informal, and inappropriate in Wikipedia articles.
• For the use of three periods in succession, see Ellipses, above.

––_⊥^{¡ɐɔıʇǝo}Noetica!^T– 06:15, 30 November 2008 (UTC)[Amended]

Sounds good, Noetica. I wonder whether that punctuation table in your copy of Halliday's Spoken and written language adds anything? Tony (talk) 08:05, 30 November 2008 (UTC)

Ah no, Tony. That isn't among my Halliday books. You may be thinking of my Longman Grammar of Spoken and Written English, which I mentioned to you once. A glorious corpus-based blockbuster of 1,200 pages. But as I'm sure you suspect, where necessary I check my work against a formidable array of sources.

I'll look out for that one of Halliday's.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 12:03, 30 November 2008 (UTC)

I gave you a copy! Tony (talk) 14:06, 30 November 2008 (UTC)

Ha! I sensed that something was amiss about this. Yes you did, and I am grateful. It is not among the many recent acquisitions I had told you about, and I had forgotten its title. Thank you! I'll look it up soon.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 22:08, 30 November 2008 (UTC)

It's all good, Noetica, and thanks. But can you think of any Wikipedia article where a question mark or exclamation point in the middle of the sentence would be desirable? (As always, I'm not competent in anything but professional American English, and not always in that; that's my context even when it isn't anyone else's.) "Why me? she wondered" and "The door flew open with a BANG! that made them jump" are professional English in a narrative style, but I'm having trouble coming up with a sentence in an expository style that should have ? or ! in the middle. If you agree, then I'd prefer we have the warning just before those examples rather than just after. We could tell the editors that they may have seen this in novels, but you don't usually see it in expository writing (or "encyclopedic" writing, although that word is so overloaded around here.)

I can hear someone objecting now that additional advice on punctuation is unwelcome. How "big" the style guidelines should be is a question that comes up again and again here at WT:MOS, and in general, I don't think it matters. The more words we have, the less comfortable people will be trying to digest it all; the fewer words we have, the more people will be forced to go to other sources, or not find out our conventions until they're getting "graded off" in some review process, which isn't good, either. I think readers can decide for themselves how much they want to read, and if they think it's too much they can say so, and if they have questions, they can ask. In general, it looks to me like that's exactly what is and has been going on at WT:MOS, and you're never going to have perfection in an adhocracy. Perfection isn't even desirable.

Many GAN reviewers have pushed back against the style guidelines, feeling that they distract from more important things. I believe we'd see less resistance if we had 20 well-trained copyeditors volunteering at GAN and FAC, and that would increase throughput, too. Ideally, we'd want copyeditors with 20 years of experience who are either retired or are bored with what they're copyediting in their day jobs. For anyone who's interested in volunteering, or in recruiting and training copyeditors, see WT:WikiProject_Featured_articles#Kicking around some ideas about copyediting. - Dan Dank55 (send/receive) 14:46, 30 November 2008 (UTC)

Worthy thoughts, Dan. Yes, I can think of contexts in which these marks ought to be used in the middle of a sentence in Wikipedia articles, or in which editors at least need to be familiar with such usage:

1. An editor may transcribe some text from an audio source (a formal recorded speech, a radio documentary, or a film, perhaps). The words could be anything at all: an account of a robbery, a spoken memoir, a story about a dream. The editor then needs to have the normal resources of English punctuation available; and these include exclamation and question marks not at the beginning of a sentence. (This is one of several situations in which rewording is not a practical option; editors cannot always avoid difficulties such as numbers starting sentences, awkward possessives, and uncertain applications of the hyphen – as in recent drawn-out discussion about premodifiers that include adverbs with -ly. Simply to advise them to do so is often unhelpful.)
2. An editor may be quoting directly from a source that uses such punctuation, and be unsure whether to break off the quotation at the relevant point and paraphrase, apply the notation "[sic]", or just leave the text intact as representing normal practice. MOS then helps.
3. Further cases like the following could turn up in quoted text (or implied in a spoken source); major style guides allow them, and though we cannot cover them all we should at least suggest such flexibility in our guidelines:
   The battalion – or was it the whole army? – was headed for defeat.
   Catullus – saucy poet that he was! – is improper for the youngest readers.
   Homer wrote (?) the Iliad before the Odyssey. [He or they wrote these, or were they composed orally?]
   The insect eats five times (!) its own weight in a day.
   Addressing the questions "how long?" and "at what cost?" proved harder. [Omitting these quote marks is possible, and perhaps capitalising the starts of the questions without capitalising after the question marks themselves. It's a fluid affair.]
4. Certain uses of the kinds just given would not be out of place in straight unquoted text, at least in articles on pop-cultural topics and the like. The style guides approve of them: why should we not?
5. Of course exclamation and question marks occur at the end of sentence fragments too, not just full grammatical sentences. (Like this? Why not!) We don't want to give a wrong impression, and have at every point to distinguish sentences-for-the-purposes-of-punctuation from fully grammatical, non-elliptical sentences. Give a guideline that both tells the truth and suggests the right path for further interpretation. (Consider the guideline we have for captions, by the way, which treats sentence fragments as non-sentences for purposes of punctuation. I don't approve of that!)

All that said, I have no problem with making our warnings more prominent by putting them earlier. Since we seem to agree about that, I'll re-order the text like this:

Punctuation at the end of a sentence

• Periods (full stops), question marks and exclamation marks are the three sentence-enders: the only punctuation marks used to end sentences.
• In some contexts, no sentence-ender should be used; in such cases the sentence often does not start with a capital letter. See Quotations, Quotation marks and Sentences and brackets, above.
• For the use of three periods in succession, see Ellipses, above.
• Clusters of question marks, exclamation marks, or a combination of them (such as the interrobang) are highly informal, and inappropriate in Wikipedia articles.
• The exclamation mark is used with restraint: it is an expression of surprise or emotion that is generally unsuited to a scholarly or encyclopedic register.
• Question marks and exclamation marks may sometimes be used in the middle of a sentence (Why me? she wondered; The door flew open with a BANG! that made them jump).
• Along with commas, semicolons, and colons, sentence-enders are never preceded by a space in normal prose.
• There are no guidelines on whether to use one space or two after the end of a sentence (see Double-spaced sentences), but the issue is not important, because the difference is visible only in edit boxes; i.e. it is ignored by browsers when displaying the article.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 22:08, 30 November 2008 (UTC)

The Homeric question changed from Did Homer write the Iliad? to How did the text now called the Iliad come into being? over the course of... The internal question mark can be rephrased away, but it is a legitimate usage in an encyclopedic tone, and we should permit it. I'd really rather not have a MOS vigilante trying to explain the evolution of oral poetry theory since Friedrich Wolf; please? Septentrionalis PMAnderson 23:35, 30 November 2008 (UTC)

I can't be confident about the motivation for some of what you say there, PMA. No one is suggesting that the sentence I made should be included in MOS. It is just to illustrate a point in this discussion; its punctuation is at issue, not its content. I agree that contentious or simply wrong content is not good in our actual examples. Your own more extended sentence is more suited – if we wanted to include another example. But do we?

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 00:14, 1 December 2008 (UTC)

I see we came up with the same idea independently; my eyes must have blurred after your Catullus example, which I would not use (it's emotional and probably POV, even although it may be consensus). Septentrionalis PMAnderson 01:07, 1 December 2008 (UTC)

It may or may not be helpful for the Manual to mention Factorial and Subfactorial in the use of the exclamation mark.

-- Wavelength (talk) 02:44, 1 December 2008 (UTC)

AP Stylebook does give You told me – Did I hear you correctly? – that you started the riot. I still think it's likely that at least 9 times out of 10 that I'm copyediting an article, and I see a question mark that's not at the end of a sentence or sentence fragment, and it isn't a scientific symbol or code and isn't quoted (either directly or by implication), it's going to seem too informal or chatty to me. I don't object to your proposal, Noetica, but your BANG! sentence is a little more positive than I'd like. - Dan Dank55 (send/receive) 03:13, 1 December 2008 (UTC)

BANG! is not suggested as encyclopaedic style, Dan. See my points 1 and 2, above (and 3, I suppose). Note the wording, and note the caution that now precedes it:

• The exclamation mark is used with restraint: it is an expression of surprise or emotion that is generally unsuited to a scholarly or encyclopedic register.
• Question marks and exclamation marks may sometimes be used in the middle of a sentence (Why me? she wondered; The door flew open with a BANG! that made them jump).

But on the strength of your comment, I'll now change it. And why not, indeed, adapt and shorten PMA's rather good suggestion too? Note the bold "?,", which is also generally allowed. So:

• Question marks and exclamation marks may sometimes be used in the middle of a sentence:

Why me? she wondered.

The Homeric question is not Did Homer write the Iliad? but How did the Iliad come into being?, as we have now come to realise.

The door flew open with a BANG! that made them jump. [Not encyclopedic, but acceptable in transcription from audio, or of course direct quotation.]

Now any editor paying attention with even dimly activated cortices will get the message, yes?

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 03:50, 1 December 2008 (UTC)

Okay, I think I like that, Noetica. I say "think" because I really never know in advance, because it all depends how clear it is to our editors, and they are all over the map. If I find that I'm removing ! and ? in the middle of sentences and people keep telling me, "Hey! (grin) You can't do that, MOS says it's fine!" then we'll have to massage as needed. (As always, there are potential issues of whether my edits are intrusive or show bad judgment, but that's a separate question from what the guideline should say.) - Dan Dank55 (send/receive) 16:46, 1 December 2008 (UTC)

Roman numerals in Bible citation

It may be helpful to mention forms of Bible citation in the MOS.

The Bible citation article says the colon-delimited form of Bible citation is the "most common format on Wikipedia". If so, the MOS might promote the use of that format for consistency.

Some references use Roman numerals for chapter numbers. The Homiletics article uses several references of the form "Matt., xxviii, 19".

Maybe it's a personal or regional preference thing like spellings (color or colour) and units (feet or meters — or metres).

Perhaps there is elegance in using Roman numerals for this purpose, but I don't encounter Roman numerals often and it slows my reading to translate them. Maybe it isn't the role of the MOS to discourage Roman numerals in this context, but the format seems like an anachronism to me in that I usually find it in older books. - Ac44ck (talk) 17:24, 17 November 2008 (UTC)

Roman numerals are fairly standard in several types of Biblical study; I doubt it would be useful or effective to prohibit them, and "most common" already promotes "Matthew 28:19". Since the exact chapter really only matters if you plan to check the reference, can't you just treat them as arbitrary tags? Septentrionalis PMAnderson 18:03, 17 November 2008 (UTC)

Note, however, that this is a virtually unaltered Catholic Encyclopedia article, from when Roman numerals were more common than they are now. Septentrionalis PMAnderson 18:20, 17 November 2008 (UTC)

The "most common" observation seems anecdotal, but probably accurate, to me. And it doesn't seem to be the result of a conscious decision to write a Wikipedia articles using the format that most people will _expect_ for Biblical references. It seems to be an unwritten, (mostly) de facto standard. I favor making it a written (not inviolable, but preferred) standard.

Finding references in Roman numerals may make it harder for me to marshal the effort to actually look up the verse listed. It may provoke a choice between 1) trusting the author's interpretation, or 2) overcoming several obstacles to evaluate the author's claim: a) go get a Bible, b) find the cited book in the Bible, c) decode the Roman numerals, d) find the referenced verse, e) evaluate the author's interpretation. Finding the verse in Roman numerals makes the list of obstacles 25 percent longer than it would be otherwise. Certainly not insurmountable, but potentially discouraging enough to break a chain of events that might have happened otherwise.

As for treating the Roman numerals as arbitrary tags, I assume that means to read over them as I might a word that I don't understand, hoping that I might glean enough of the author's meaning from the context around the unfamiliar word. That can happen, but it interrupts my reading to 1) encounter a word that I don't recognize, 2) make the decision that I will skip it and hope for the best rather than reach for a dictionary, etc.

There is a Wikipedia article on how to write a phone number:

Local conventions for writing telephone numbers

Writing a telephone number in a different format will look strange to a resident

I have seen several ways to write a phone number in the USA: (888)555-0111, 888-555-0111, 888.555.0111, 888 555 0111. Some forms are easier for me to recognize as a phone number. And these examples involve only a change in punctuation, not numeral type.

A Bible citation article exists, but it isn't likely to get much attention unless there is a link to it in the MOS. And the existing article doesn't address the issue of using Roman numerals.

There was a time when I was unfamiliar with the colon-delimited format by which chapter and verse are usually cited. A mix of Roman/Arabic numerals may compound unfamiliarity and discourage some from making the effort to learn the "code" by which chapter and verse may be found. It may not seem like a complicated code, "But knowledge is easy to him who has understanding" (Prov 14:6b).

I don't know how many Romans read the English Wikipedia, or how many of them use Roman numerals. I don't necessarily subscribe to the "newer is better" hype, but updating the verse references in the Homiletics article, which apparently is "a virtually unaltered Catholic Encyclopedia article, from when Roman numerals were more common than they are now", seems like it could be a helpful thing to do. It could also be helpful for the MOS to address the issue instead of leaving it for several editors to raise the issue on multiple talk pages where they might want to "update" the format.

• There may be more Arabs, but not many; this is a poor case for Arabic numerals. Septentrionalis PMAnderson 04:40, 18 November 2008 (UTC)

• Arabic numerals

• The arabic numerals (often capitalized) are the ten digits (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
• Today they are the most common symbolic representation of numbers in the world.

• Roman numerals#Modern_usage

The Roman number system is generally regarded as obsolete in modern usage

-Ac44ck (talk) 06:43, 18 November 2008 (UTC)

Except, of course, in those fields where it isn't obsolete, such as here and here and here. Septentrionalis PMAnderson 17:32, 18 November 2008 (UTC)

The issue here is: Might a general audience have a preferred format for Biblical citations? The statement in the Bible citation article about the "most common format on Wikipedia" suggests that they do. Who might prefer the mixture of Roman and Arabic numerals? I suppose that some scholars might. Anyone who is familiar with the mix of Roman/Arabic numerals can understand the simpler format. I don't believe that the converse is true. One who is less familiar Biblical references in general may find a reference containing Roman numerals to be too cryptic to pursue.

Several additional examples of current (if potentially cryptic – how many can evaluate "MDCCCCLXXXXIII" in movie's copyright notice before it scrolls off the screen?) use are given in the link that I gave before: Roman numerals#Modern_usage. It is perhaps instructive that the notion of using Roman numerals in Biblical citations is not included in that list. In fact, the character string "bibl" doesn't appear anywhere in the Roman numerals article; even the historical use of Roman numerals in Biblical references isn't mentioned anywhere in the article.

The one-liner quips haven't made much of a case for indifference (comparable to that which should exist in a dispute over the spelling of color/colour) toward the old style of citation.- Ac44ck (talk) 19:22, 18 November 2008 (UTC)

The MOS essentially says, "If you find the 'colour' spelling in an article, don't change it to 'color' instead because both spellings are common in modern use." I don't think the MOS should be as indifferent about the old convention of citing Bible verses using a mixture of Roman and Arabic numerals. - Ac44ck (talk) 22:04, 17 November 2008 (UTC)

This issue was discussed before:

http://en.wiki.x.io/wiki/Wikipedia:Reference_desk/Archives/Humanities/2008_January_22#Chapter-verse_notation_styles

I would say the first is more common and the second is perhaps the more traditional; they are equally correct. ... Just keep your style consistent within your writing.

In my view, this gives "conformity with precedent in a particular article" priority over "ease of comprehension by an average reader".

One might point to this statement in Wikipedia:Manual_of_Style#Consistency

Edits should not change a stable article from one guideline-defined style to another unless there is a substantial reason to do so that goes beyond mere choice of style.

and call the issue "resolved". Though there doesn't seem to be any "guideline-defined style" which discusses the use of Roman numerals in citing Bible verses, and whether "ease of comprehension by an average reader" qualifies as "a substantial reason" is in the eye of the beholder.

I have added a section on Roman numerals to the Bible citation article. -Ac44ck (talk) 19:19, 19 November 2008 (UTC)

Consistency in Bible citations can make searching Wikipedia for them more efficient.

Please note:

Some versions contain apocryphal books.

Some versions have different names for some books (see Paralipomenon and Apocalypse).

Some versions have different numbering for some chapters and verses (see Psalms#Numbering).

Quoted forms which are not consistent with the Wikipedia style can be redirected (or pipe-linked) to the forms in the Wikipedia style.

-- Wavelength (talk) 07:30, 3 December 2008 (UTC)

Abuse of article space

Please do not abuse article space for hosting arguments about Wikipedia house style. Article space is for encyclopaedia articles about Bible citations, supported by sources that discuss such things, and reflecting human knowledge on the subject, not for discussing or specifying what style of citations should be used within Wikipedia. We already have a project-space discussion of citing the Bible in Wikipedia. It's Wikipedia:Citing sources/Bible. Uncle G (talk) 14:13, 24 November 2008 (UTC)

The Wikipedia:Citing sources/Bible page seems to be a work-log about templates, which external website they should link to, and which Bible version to use. It doesn't seem to touch on the various styles of citation allowed in Wikipedia. Wouldn't that be the subject of a Wikipedia:Manual_of_Style_(Biblical_citations) page?

I may not understand the "self-reference" rule. I assumed that the quoted articles contained valid information. I see how that could be unstable if the linked article changes, or invalid if the content copied from the linked article was tainted. But as I read it, WP:SELF is about refraining from mentioning the word Wikipedia or linking to things outside of article space. It seems that self-referencing can be okay if it "makes sense in a copy of Wikipedia which contains only the article space", which is what I did.

I didn't discuss or specify "what style of citations _should_ be used within Wikipedia."

I didn't touch the first part of the page other than to build structure by adding a heading, using words from the existing lead. Other than the removal of what may be interpreted as self-referencing material, the remainder of how I left it at 19:08, 19 November 2008, essentially persists (dressed up and in better company, but conceptually similar) in the current version. User:Pmanderson tagged the Roman numerals section for WP:SYNTH, but I still don't understand that.

It seems that the "abuse of article space" was either preexisting or in the "self-referencing". Otherwise, I don't see that my changes caused article space to be "hosting arguments about Wikipedia house style." -Ac44ck (talk) 08:25, 25 November 2008 (UTC)