Wikipedia talk:Manual of Style/Archive 71

Archive 65

←

Archive 69

Archive 70

Archive 71

Archive 72

Archive 73

→

Archive 75

Gender-neutral pronouns etc

I'm surprised not to see any mention of a policy on usage of gender-loaded terms, particularly generic 'he' and words like 'chairman'. Have I missed it somewhere? FSharpMajor 10:06, 30 March 2007 (UTC)

Is there much usage of generic he in wikipedia? I see mostly they or somesuch when examples are given. Also, I am sure that chairman would only be used in relation to actual men. The term does have rather a significant history though, and is not actually sexist in meaning though political correctness has assumed it so. WookMuff 11:24, 30 March 2007 (UTC)

I've noticed it on occasion, and without a specific policy it's not surprising to find it cropping up. You're right that 'chairman' and similar titles would be most likely to appear in reference to particular people, in which case the rule about using people's own self-designation would apply. (we can argue about whether a word is 'actually sexist': my opinion is that gender-loading tends to promote stereotypes in the reader's head - imagine if we used 'spaceman' routinely instead of 'astronaut', it would make you more likely to picture a man in your head even when a non-specific astronaut was being discussed). Still, again I can easily think of situations where an article might refer to a generic, say, "chessman", and that it would be helpful to have a policy of gender neutrality that we could point to in order to justify changing it to "chess piece".FSharpMajor 12:15, 30 March 2007 (UTC)

Technically, "chessman" is not equivalent to "chess piece". To a chess player a "piece" excludes a pawn, while a "man" does not. And in many cases "Chairman" is still the correct official title of a specific position. When this is true we should accurately report the fact. I don't think such a general policy is a good idea, except insofar as it is already implied by WP:NPOV. DES ^(talk) 06:21, 1 April 2007 (UTC)

There needs to be an official ruling against using he for people in general, since most, if not all, readers will assume the person referred to is male. Slightly less people, but still probably the majority, will also assume that chairman refers to a male. So these words must not be used unless you are absolutely certain the person referred to is a male. If it is an unknown person, don't use he or words ending with "man". In many cases "man" endings need to be replaced with "person" to avoid creating the false impression that it is a man and not a woman. In other cases different gender-neutral words sound better. Instead of he, I recommend the singular they, as it is the official requirement in Australia, although "he or she" is also acceptable. Even in cases where "Chairman" is the "official" title, it is not "correct" unless it is a man, and should still be replaced with the more correct term for the job, such as "chair" or "chairperson", and the official title should only be used in quotation marks.

As for situations where the person is known, it is better to use the gender-neutral term unless their gender is particularly relevant for some reason. Although in this situation it is more a guideline than a rule. Whereas for unknown people, gender inclusive language must be used as a rule. Carl Kenner 13:01, 15 April 2007 (UTC)

I have no idea why "most people would assume" that "he" refers only to male persons. Certainly that is not English usage as I learned it. Ditto for terms like "chairman". As for even when "Chairman" is the "official" title, it is not "correct" -- if you do that, you're not describing, you're editorializing. That seems wrong for an encyclopedia. To me, "neutral point of view" maens to defer to who/what is described, and suppress your own value judgments about their choice of words.

Meanwhile, I find the notion that "they" is singular to be quite bizarre. "he or she" is messy but at least grammatical. Personally I prefer to use "he" for the neutral term, as has been the practice for centuries.

Finally, when a person's gender is know, I find it particularly inappropriate to use anything other than the preposition that applies. "In an interview with John Doe, they said that..." or "in an interview with John Doe, he or she said that..." -- surely you jest? Paul Koning 17:09, 1 May 2007 (UTC)

Varieties of English

What is Irish English? [1] SlimVirgin ^(talk) 06:08, 1 April 2007 (UTC)

English as spoken in Burkina Faso Ireland. Strad 20:19, 1 April 2007 (UTC)

It's very silly to expect various articles to be written in different varieties of English. It's particularly bizarre to expect an article about England to use British English spelling while one about Oregon would use American English spelling. Would an article on Cornwall be written in Cornish English? A standard is needed and American is the obvious choice (and I write as someone in England). American must be the most widely understood and known variety of English.

It may seem silly to you, but this debate has been gone into many times, and your side of the argument appears to have lost. See Why not settle on a standard written English? a long way up this page. Also, British English and Cornish English are not remotely commensurable. British English is a standard form taught and used in many countries of the world. Cornish English is a very local dialect unknown, I would suggest, to anyone outside Cornwall. Woblosch 13:31, 1 May 2007 (UTC)

Templates to identify language variety of an article

I'd like to propose a few templates be created to identify the variety of English settled on for articles. It would be a talk page template to help when there are discussions when people start flipping words back and forth. A good example is the flipping back and forth between "organisations" and "organisztions" on 2007 Iranian seizure of Royal Navy personnel. Any of the templates should point to the national varieties section of this article to provide further guidance. Suggestions for initial template names are "{{Spelling British}}" and "{{Spelling American}}". Any comments? --StuffOfInterest 16:23, 4 April 2007 (UTC)

This might be a good idea, but I think it should focus on specific spelling issues rather than countries. While I don't think that you should mix words like colour and honor, I don't mind it if you have color and organise. Also, in Canadian English, for example, you might find honour, or, less commonly, honor. "British English" doesn't tell you whether to write -ise or -ize, although a consistent choice needs to be made. So I think the template should focus on series such as -ise/-ize, -our/-or, -re/-er and so forth, and the template should be flexible for isolated cases like tyre/tire, etc., where you can enter the words in question. Also, having a place for the dates the choices were made would help clarify whether a choice was long-standing. And I think people should only use the templates for spellings that actually occur in the article, so they can't use the template "preventively". Joeldl 20:47, 4 April 2007 (UTC)

As long as it's not one of those boxes that sits at the very top of the article. The last thing we need is more of those. Putting it on the talk page or somewhere else might be good. Strad 03:04, 5 April 2007 (UTC)

Anyone who's malicious enough, or ignorant enough, to revert-war on spelling issues will hardly bother to take notice of a template on the talk page. Whereas "normal people" will just find such templates cluttering (and personally I'd find an in-your-face declaration that "This article uses British English, or else!" a little off-putting). Avoid instruction creep. Oppose. :-) --Quuxplusone 07:11, 18 May 2007 (UTC)

Horizontal lists

Many articles include horizontal lists, often wrapping over several lines, and separated by pipes (|), bullets (•), hyphens (-) or other such characters. These characters may be spoken, intrusively, by assistive software ("bullet cat bullet dog bullet..."), and the content is not marked up, in the HTML source code, as a list, which reduces functionality on some devices and reduces semantic meaning.

There is now CSS available for horizontal lists, like this one:

• cat
• dog
• horse
• cow
• sheep

using the templates {{flatlist}} and {{endflatlist}}. See, for example, areas of Birmingham. The separators are now CSS borders, and are ignored by text readers, etc.

Such lists can be used anywhere in an article, including infoboxes and templated footers.

This needs to be reflected in the relevant section of the MoS, but I'm not sure how. Can someone assist, please?

Andy Mabbett 10:41, 5 April 2007 (UTC)

• Does this code handle separators other than the pipe symbol, e.g. {{·}}...?  Thanks, David Kernow (talk) 18:36, 8 April 2007 (UTC)

No. It’s not a pipe symbol. It’s not a character at all (which is why it’s appropriate for avoiding screen readers). It's a vertical border drawn on a box around the text. --Rob Kennedy 19:11, 8 April 2007 (UTC)

Okay; I think I understand!  Thanks for reply, David (talk) 13:33, 11 April 2007 (UTC)

Image section

Re...

• Do not place left-aligned images directly below second-level (===) headings, as this disconnects the heading from the text it precedes. Instead, place the image directly above the heading. For example, use:

[[Image:Image relating to section 1a.jpg|frame|left|]]
=== Section 1a ===
First paragraph of section 1a.

not:

=== Section 1a ===
[[Image:Image relating to section 1a.jpg|frame|left|]]
First paragraph of section 1a.

...perhaps the simpler/"safer" advice is simply to recommend that left-aligned images aren't placed immediately below section headings...?  Thanks for any feedback, David Kernow (talk) 18:45, 8 April 2007 (UTC)

I reworded it accordingly; see #Left-aligned images above. Eubulides 21:32, 2 May 2007 (UTC)

shortcuts vs. offline users

Please mention something about shortcuts vs. offline users.Jidanni 11:31, 9 April 2007 (UTC)

Since this is a question of refering to shortcuts that almost always point to teh Wikipedia: namespace, there should be no reason to cite or link any of them in any article (because doing so would be a self reference). Therefore this isn't a Manual of Style issue, since the MOS is about how to format articles. DES ^(talk) 12:45, 9 April 2007 (UTC)

Can a style be both optional and required?

I have been contributing to Wikipedia for 2 years and I now have a question about how style guidelines should be worded. Can a style be both optional and required? There is a debate going on in Manual of Style (dates and numbers) on binary prefixes that is caused in part to the wording of the guideline. I do not want to cover any of the issues in that debate on this talk page. I came here so I can get an opinion that is not biased by that debate.

There are two valid styles, the Style A and Style B, and the guideline is worded like this.

The use of the new Style B in the Wikipedia is not required, but is recommended for use in all articles. If a contributor changes an article's usage from Style A that change should be accepted.

In practice the style is optional until some user changes it then it is required. When all of the significant contributors object, a first time contributor says the change must say because of the manual of style. If this is the case, shouldn't the guideline say that style B is always required?

Did the visiting contributor (who has never made any other change) violate the other manual of style rules in Wp:mos#Disputes_over_style_issues . This is my first time I have had a problem with Manual of Styles. Can a style be optional until one person says it is required? -- SWTPC6800 23:54, 9 April 2007 (UTC)

Idiosyncratic capitalization of proper names

Can we come to some consensus about idiosyncratic proper name capitalization? There is a discussion ongoing at Wikipedia talk:Proper names. Ideally the end result would be to update the guideline with some more specific text about what to do when someone's name isn't capitalized normally. Any input would be appreciated. - cohesion 00:50, 10 April 2007 (UTC)

Infoboxes and MOS

Following an initial query on the Village Pump, it was suggested I raise the question here. Shouldn't there be some guidelines in the MOS about the use and content of Infoboxes? I'm thinking about some guidelines about what constitutes good practice in coding infoboxes, what CSS classes and id's to use, size of images (and/or infoboxes) and, what led me to raise this in the first place, best practice in defining locations. I have already picked up at least 3 different ways of defining latitude and longitude in "Place" IB's. I'm pretty sure there are more. Some seem to be regional preferences, but many are not trapped in the dump scans associated with Google Earth mashup. We should have, at least, a preferred methodology for these things. There are always good reasons for exceptions.. Shouldn't we have an Infoboxes section in MOS? Frelke 18:01, 10 April 2007 (UTC)

Maybe a generic section would be appropriate here, but typically, infoboxes are governed by WikiProject-specific guidelines. You might want to visit some of the various wikiprojects and see how they do it (for instance, the Aircraft project has a section and some project-specific templates for infoboxes in articles that fall under their purview. Akradecki 18:18, 10 April 2007 (UTC)

The MOS already includes Wikipedia:Dynamic infobox templates. Other guidance can be found at Wikipedia:Infobox templates and Help:Infobox; perhaps adding a link or two to those two pages (somewhere) would be useful? -- John Broughton (♫♫) 02:10, 11 April 2007 (UTC)

I am inclined to add Infoboxes to the Submanual list. Its WhatLinksHere seems to show that its not listed anywhere meaningful - which is, I guess, why I couldn't find it. {{style}} is another possibility. I think I'll propose over there that it should be included. I may even be bold. Frelke 07:37, 11 April 2007 (UTC)

Pic placement

Per this section am I understanding correctly that left aligned pics should be place above the header under second level headings (===) but not first level headings (==)? Quadzilla99 17:39, 13 April 2007 (UTC)

I played around a bit with an article with images, and tentatively concluded that the MoS page really should say that it's wrong to place a left-aligned image immediately below any heading. Even placing it above a heading, as suggested, is still disconcerting (to me); I think left-aligned images should only appear in the middle of sections. -- John Broughton (♫♫) 02:00, 14 April 2007 (UTC)

Sometimes it's necessary for short sections with little text that require two images. Unless you want a huge blank gap in the text you have left align one. I'd like to get some input as I think the MoS should be changed to say all left aligned pics (except in the first section of course) should appear directly above the headers. I'm very sensitive to this as I have a relatively high resolution computer screen and right aligning all pics often leaves huge ugly blank gaps in text. The thumb size options in prefernces leaves a lot to be desired as well. Quadzilla99 04:48, 14 April 2007 (UTC)

Just to clarify (apologies if I'm stating the obvious) the images section actually says:

Do not place left-aligned images directly below second-level (===) headings, as this disconnects the heading from the text it precedes.

which is true: placing the image tags above the === second level header === will force the header to appear alongside the image, which looks fine, instead of the image splitting up the text and header, which doesn't. This doesn't apply to main section headers, as they have the benefit of a horizontal line separator, which seems to "reconnect" the two. Whereas I tend to think it can look quite good alongside (a la subsection) it very much depends on the circumstances. Look at this article for example; the first main section has the image tags placed after the section header tags and (to me) looks about right. If you edit it so that the image tags are above, it looks like the pic (partly) refers to the text above, which in this case it clearly doesn't. mikaul^talk 08:23, 14 April 2007 (UTC)

Incidentally, I agree wholeheartedly with the concerns expressed here about thumbnail size and suggest you add them to this discussion above. We really ought to start making provision for the rapidly-increasing number of readers, as well as editors, who have higher-resolution monitors. mikaul^talk 08:24, 14 April 2007 (UTC)

What I dislike about having images above section headings is that images appear to be in sections they’re not really in. Click the “edit” link for a section an image appears to be in, and you don’t get the image. Click the “edit” link for the section above, and you find an unrelated image tacked onto the end of that section. --Rob Kennedy 15:42, 14 April 2007 (UTC)

Point well taken. It does seem like the software should be changed (so it essentially treats an image immediately following a third-level header as if it were above the header, in the text, if you will) rather than hoping that thousands of editors become familiar with this oddity. Someone want to submit a bug report? -- John Broughton (♫♫) 19:42, 14 April 2007 (UTC)

I reworded the guidelines for left-aligned images a bit, so it may affect this topic. For details please see #Left-aligned images above. Eubulides 21:35, 2 May 2007 (UTC)

I disagree with this as if you have a high res screen it is sometimes necessary to left align pics at the beginning of sections. Otherwise as I said above it creates large ugly blank gaps in the text. Also the wording "or place elsewhere" leaves something to be desired as it's seems to indicate that the pic should be put somewhere else even if it doesn't even relate to the text if necessary. Quadzilla99 21:56, 2 May 2007 (UTC)

I reworded the guideline to address your second point; thanks. As for the first point, sorry, but I don't follow it. As an editor one can't assume that the user has a high-resolution screen, so one shouldn't place images under that assumption. I agree that the current guideline sometimes produces ugly output, but putting the image above the section header breaks accessibility for reasons described at the end of Wikipedia:Accessibility#Article structure. I guess the "right" fix is to improve the Wikipedia software to format sections better, but in the meantime accessibility is more important than beauty. Beauty is fleeting, but structure is forever. Eubulides 22:50, 2 May 2007 (UTC)

I'll bring this up at the Pump later to see if we can get a little more talk on it and maybe see if we can spur someone to work on these technical factors. Really if you've ever seen some of these pages with gaps throughout the text it looks very amateurish. Quadzilla99 22:58, 2 May 2007 (UTC)

Bible quotes??

Surely somewhere on WP there's a guideline or policy for citing quotes from the (Hebrew/Christian) Bible. I went looking while editing this page, but came up empty. I assume chapter, verse & translation info is a minimal requirement, so for now I went ahead and added them in the style of the Blue Letter Bible (an excellent reference source BTW), where the King James (or "Authorized") version of the first two verses of the tenth chapter of the Book of Revelation would be cited as "Rev 10:1-2 (KJV)". I think that's fairly standard, but I'm not sure if it's too shorthand for WP (though the wikilink to the KJV article probably helps...) —Turangalila ^talk 04:49, 16 April 2007 (UTC)

You might want to ask at Wikipedia:WikiProject Bible; there I see reference to the templates {{bibleverse}} and {{niv}}. --Rob Kennedy 08:22, 16 April 2007 (UTC)

Image sizing

I would like to strengthen the wording "Specifying the size of a thumb image is not recommended" - perhaps to "Specifying the size of a thumb image is generally a bad practice, and to be avoided", with some additional explanation why this is so. Thoughts? Andy Mabbett 15:28, 16 April 2007 (UTC)

• Could I point you to a discussion futher up the page? I'd be interested to hear why you would like to reinforce that guideline, as there are some who would like to see it relaxed. mikaul^talk 19:02, 16 April 2007 (UTC)

plural of acronyms and abbreviations

It would be useful to have an example of an acronym or abbreviation whose plural is marked by -es.

question-marks

These are deemed acceptable, presumably outside quotations. Might there be an example given of when an encyclopedia might legitimately ask a question? I can't think of such an instance. Encyclopedias are there to inform and wouldn't indulge in such devices as rhetorical questions.

flexibility

We are told the rules "should be applied with flexibility" and it would be useful to see an example. The manual asserts its authority by saying "Wikipedia articles should heed these guidelines" and "editors should strive to have their articles follow these guidelines" so when can breaking these rules be justified? — Preceding unsigned comment added by 217.206.112.162 (talk) April 20, 2007

MoS shortcuts.

Recently, User:Picaroon9288 has gone around the various MoS subpages and removed all the shortcuts using MoS, such as MOS:ITALICS or MoS:DAB. Is this reasonable? Is there any consensus on the MoS shortcuts, and whether they should be linked or not?

Personally, I'm in favor of keeping them. I'm not entirely certain why Picaroon wants to delete them, as he didn't actually say why in his edit summaries or when I contacted him on his talk page. I'd assume that it has something to do with reducing cross-namespace redirects. If that is the argument being used, that seems rather odd, since we already have the WP: pseudo-namespace, and it's not like the MoS abbreviation is only used on two pages, but a bunch.

"Redirects are cheap." I don't see what harm these redirects are doing, and they're useful - I usually mark my edit summaries for disambiguation pages with a reference to MoS:DAB, or occasionally MoS:T. SnowFire 16:41, 21 April 2007 (UTC)

I'd say keep. Quadzilla99 16:48, 21 April 2007 (UTC)

Incidentally see here, basically as long as it's harmless there's no need to delete a redirect. Quadzilla99 16:52, 21 April 2007 (UTC)

They're not harmless; as long as non-standard shortcuts, especially ones where there is a perfectly reasonable alternative, are used, there's the chance someone else is going to pick the idea up and create another ten pseudonamespaces. What about when someone creates AN:, for administrators' noticeboard related stuff? And PO:, for policy related stuff? And BOX:, for userbox related stuff? And PJ:, for WikiProject related stuff? Picaroon 17:03, 21 April 2007 (UTC)

But... that's the entire point of redirects. To offer an alternative themselves. Heck, we don't even need the WP: shortcuts; we could just type in Wikipedia:Manual of Style (somethingamajig) every time. As for other shortcuts, a person wanting to create those should raise that question on the appropriate community noticeboard, first. But if it turned out that other editors were in favor of creating a pseudo-domain (which would presumably imply it was seen as relevant and significant enough), well, that'd be the consensus. For what it's worth, looking at the history of the various MoS: redirects, they were made by a wide variety of people- it was not one person running off on their own. SnowFire 17:20, 21 April 2007 (UTC)

WP: is widely used and agreed upon. In fact, it's easier to type than MoS/MOS. Why can't it be used? Picaroon 17:28, 21 April 2007 (UTC)

The pages are in Wikipedia space, and the Wikipedia space already has a widely agreed upon shortcut style, which is WP:. There is absolutely no reason to create shortcuts for a specific type of Wikipedia page when there is already a perfectly acceptable general one. I realize it is convenient, but remember that these pages are in the article space, the place where we write articles for our readers. We should keep the amount of crossnamespace redirects at a minimum, and this alternate system is hindering that goal. Picaroon 17:03, 21 April 2007 (UTC)

This is a very abstract long-term benefit compared to a very concrete minor benefit editors enjoy right now. A quick check of Allpages shows that no actual articles start with MoS:, so I doubt readers will be confused. I'm no developer of MediaWiki, but I imagine that it'd be easy to make other character strings like WP or MoS followed by a colon "act" as if they were in another namespace (Wikipedia), at least as a longterm type thing. Would that satisfy your concerns? (We can always put in a feature request.) SnowFire 17:20, 21 April 2007 (UTC)

While I suppose making WP: an official, redirect only namespace is a good plan, you still haven't touched on the necessity of the MOS/MoS classes of redirects. Why are they needed at all? Picaroon 17:28, 21 April 2007 (UTC)

They aren't "needed." They are, however, convenient. Most redirects (or even articles!) aren't "needed;" they're just nice to have, and since redirects are cheap, the general policy is just to let them be. (Also, to continue the thread you mentioned above on "easier to type"... not that this particularly matters, but there is a minor amount of keystroke saving comparing MoS:DAB to WP:MOSDAB. Not that I expect everyone to agree with this or to use the MoS shortcuts, naturally, but some people like them.)

Anyway. The good news is that we don't even need to submit a feature request; it seems that psuedonamespaces -> real namespaces is already in the pipeline. See http://meta.wikimedia.org/wiki/Help:Namespace_manager. SnowFire 17:56, 21 April 2007 (UTC)

"... absolutely no reason to create shortcuts" — We're not creating new shortcuts, they've been around for years. There are quite a few of my over 18,000 edits that have one of these in the edit description, and I don't relish the idea of going back and fixing them all. This strikes me as quite disruptive, with very little or no benefit to balance it. Keep. It ain't broke, so I say don't fix it. Chris the speller 22:25, 21 April 2007 (UTC)

"... going back and fixing them all." Fix what? Did I say they were being deleted? No, because deleting redirects with links wastes time. All I did was remove them from the {{shortcut}} boxes so more people would use the WP: space ones instead. I fail to see what's the big deal with merely encouraging newer Wikipedians just beginning to use shortcuts to use the standard shortcut prefix. Picaroon 16:43, 22 April 2007 (UTC)