Wikipedia talk:Manual of Style/Archive 54

Archive 50

←

Archive 52

Archive 53

Archive 54

Archive 55

Archive 56

→

Archive 60

Foreign language links: order

I'm trying to find a reference to a style policy on the language-links list, but I can't find the right place. It should be here on the MOS page, but there is no mention of it.

I want to know in what order the list of links to an article in other languages should be kept. Should it be in alphabetical order according to the two-letter ISO code (for example, DE (German) would come before HR (Croatian)), or should it be alphabetical according to the English name of the other languages (Croatian would come before German). Does anyone know what the guideline is? Thanks. EuroSong ^talk 23:53, 11 August 2006 (UTC)

Putting them in alphabetical order according to their English names doesn’t make much sense since they are presented at the side of the page in their own languages. For example, de yields Deutsch (not German) and hr yields Hrvatski (not Croatian). Sorting by ISO code gets you pretty close to being sorted by native term. For example, if you have articles in Spanish, Esperanto, and Estonian, you might order them as eo, es, et. That would give you Esperanto, Español, Eesti, which is actually backward from the desired order. I don’t see that as a big problem, though. They at least all start with E, so anyone seeking a particular language wouldn’t have to work very hard to find it. Perhaps it would be best if the software would sort the list when it generates the page. --Rob Kennedy 20:52, 12 August 2006 (UTC)

Though not official, the order used 99% of the time is alphabetical, based on local language, see m:Interwiki sorting order. Which makes sense, as then the order visible to the reader is sorted nicely (using other orders give a semi random look to the order of the links). Martin 09:24, 29 August 2006 (UTC)

anything other than iso code will be much harder to maintain. DGG 08:25, 18 September 2006 (UTC)

British Muslim

I saw an interesting commentary in the Independent (which they do not seem to have included in the online version - but I will try and pick up a copy of the paper later and transcript the relevent section) this morning which discussed the recent "terrorist" plot in the UK. One of the points that was dicussed was the use of "British-born Muslim" as a form of soft racism rather than "British Muslim" or "Muslim Briton" (the author contented it was soft racism because the papers do not use that form of address about any other ethnic or religious group).

What would be considered the correct syle in a wikipedia article? --Charlesknight 13:46, 12 August 2006 (UTC)

"British Muslim" and "Muslim Briton" are not actually equivalent to "British-born Muslim", since I suspect that not all British Muslims were born in Britain. I see nothing wrong with "British-born Muslim" as a concise way to say "a Muslim who was born in Britain", although the longer form is fine as well.

And it's not true that this form of address is not used to describe other ethnic or religious minorities: here's an old BBC story which uses the phrase "British born Hindu". The phrase is much more commonly used in the press these days in reference to certain Muslims, for the simple reason that certain British-born Muslims have made the news. In my opinion, ascribing this usage to "soft racism" rather than to a need to describe the background of a few suspected criminals is specious and should not deter us from using accurate language. --Kevin (complaints?) 21:13, 12 August 2006 (UTC)

Almost always use 's even if the noun ends with s

I have corrected the grossly incorrect statement about possessives. You almost always add an apostrophe and an s to all nouns, even if they end with an s, unless it is a plural noun that ends with s. Here is backup for this correction:

• archive 44 of this talk page
• Apostrophe#Possessive_forms_of_nouns_ending_in_s

In practice, regularly leaving off the s after the apostrophe is as nonstandard and weird as not pronouncing the h in human or humble. In striving to be a publication with mainstream appeal and understandability, Wikipedia must use standard forms.

Nova SS 19:26, 12 August 2006 (UTC)

Time for a split?

About half the recommendations seem to concern "style" (grammar, expression, naming, etc), and half concern "layout" or "format" (when to link, headings, how to use images, captions etc). Could we consider splitting this into a genuine "Manual of Style" (nothing but questions of "how to say it"), and a "Manual of Layout" or "Manual of Formatting", which concerns presentation? My concern is primarily that there is very little guidance on layout, and the size of this beast is a discouragement against adding any. Stevage 16:55, 14 August 2006 (UTC)

Yes, layout and formatting should be elsewhere. Maurreen 06:54, 18 August 2006 (UTC)

Overriding standard styles generally

The Paris article formerly had a custom TOC. I replaced it with the usual TOC, on the grounds of consistency, but someone else asked me about whether there was a guideline on the issue, and I couldn't find anything that clearly includes this. The closest is Formatting issues, which states:

Formatting issues such as font size, blank space and color are issues for the Wikipedia site-wide style sheet and should not be dealt with in articles except in special cases.

Should this be expanded to something like:

In general, features of pages that are specified by the software or style sheets, or for which there are standard HTML tags, should not be overridden on a case-by-case basis except where there's special reason. Likewise, if a template is available, use that if possible rather than writing your own formatting. If you think the default style looks ugly, you can feel free to propose site-wide changes, or (in many cases) edit your style sheets to automatically make the style appear as you prefer, but don't manually override any specific instance of a standard site style: it makes Wikipedia look inconsistent and unprofessional.

? That's kind of the point of a manual of style, after all . . . —Simetrical (talk • contribs) 17:56, 14 August 2006 (UTC)

Kind of what I'm getting at above. We really need to have some serious discussions about formatting and layout on a site-wide level. We have 1.3 million articles after all ;) I would rather have much stronger language: individual articles should *never* directly modify text styles. However, there is a middle ground: individual WikiProjects may wish to use certain formatting on all their pages. We're nowhere near the level of setting a standard look and feel for the whole Wikipedia, whatever illusion this manual of style presents. Stevage 21:49, 14 August 2006 (UTC)

I totally agree that modifying text styles should be strictly verboten - there's also Wiki's many available skins to consider, and manually-added styles would override these. The only exception I could see would be for templates used in specific pages.

For layout elements that become a real hindrance, such as that TOC, I do agree that it is pushing 'it' (though we're still not sure exactly what "it" is) a bit to make changes, but I don't see a real 'problem' if this a) does not break with 'Wiki style' in any way and b) is not a hindrance to navigation from other pages. I don't think the TOC in question was either of these. Unless I've missed something, there doesn't seem to be any real discussion going on about possible changes. Also, as I've already said to Simetrical before, I think it would be the very modifications that Wikipedians try to make that would be the best indicator of improvements that could be made.

Anyhow, it would be in everyone's interest to create both a clear-cut 'graphic style guide' and a place to talk about it, and place a link to it under every editing window, in much the same way as the Help:Editing already there. This would both be helpful to a Wikipedian having problems with layout, and dissuade the same (by providing another option) from actually making layout changes without exposing their problem/suggestion first. thepromenader 08:11, 15 August 2006 (UTC)

The idea of a MoS to begin with is in large part to give the site a consistent look and feel. Again, that makes us look more professional. Having different TOC styles on different pages is slightly disorienting, and just looks sloppy.

The place to propose a change to the TOC style is, well, here. You should drop a note to Wikipedia:Village pump (proposals) too. But the idea is, it should remain consistent across the site. (Note that making the TOC smaller or dropping subsections for long pages only is still consistent, in that it treats different cases differently only insofar as they differ: it doesn't have one page look one way, and an analogous page look different.)

As for adding a link to the MoS, we need to be wary of overcrowding. The MoS isn't nearly as important as the rest of the links we have there; most editors won't need to know anything about it. They just shouldn't object to people cleaning up their edits after the fact. —Simetrical (talk • contribs) 19:01, 15 August 2006 (UTC)

Mind you I'm not objecting to your reinstating the standard TOC - some of my comments were outlining my motivation for changing it in the first place. Since this falls in to sort of 'grey zone' I can neither defend my actions nor condemn yours - but I will say that this grey area must be accounted for.

Any wikipedian finding a layout shortcoming - ugliness, floats, overlapping, etc - should have a clear idea of where he can see that it gets the attention it deserves - would that be here in this page filled with talks about accents and interlineage? It wouldn't seem so at first glance - and the 'guide to layout seems more of the same - but if it is, it took my custom TOC to learn this. I'm sure you see what I mean. thepromenader 22:08, 15 August 2006 (UTC)

Italicized quotations, and quotes in blockquotes

There is normally no need to put quotations in italics unless the material would otherwise call for italics (emphasis, use of non-English words, etc.).

Should this be strengthened to

Quotations should not be put in italics unless the material would otherwise call for italics (emphasis, use of non-English words, etc.).

? Or perhaps be weakened or otherwise be made more explicit? I've always disliked italicized quotations, but never changed them because I got the impression they were viewed as acceptable (certainly some reputable publications do italicize them). At the very least, there should be no need to manually italicize <blockquote>s, because it would be easy for anyone to change that in their stylesheet; inline quotes that's not an option for. —Simetrical (talk • contribs) 18:21, 14 August 2006 (UTC)

It'd be great if we could just say, "Block quotations should be done using the {{...}} template." I'm heartily sick of not knowing the correct way of doing quotations. Sometimes I use >blockquote<, sometimes I use {quotation}, sometimes I roll my own with indenting and italics. Some guidance would be great! Stevage 23:12, 14 August 2006 (UTC)

Short answer: there is no correct way. Colon-indenting looks right in visual browsers, but it actually makes the text a definition definition <dd>, part of a definition list <dl>, which would normally follow a definition term <dt>. This makes no semantic sense.

An html <blockquote> element would be the right way, but until Bug 6200: Linebreaks are ignored in <blockquote> gets fixed, paragraphs and other block elements don't work right inside a blockquote, so unless it's just a single paragraph, you have to type something like this:

 <blockquote>
 The first paragraph.
 <p>
 The second paragraph.
 </blockquote>

It would also be nice if there were a standard wikitext way to enter blockquotes: Bug 4827: blockquote support in wikitext. —Michael Z. 2006-08-15 00:06 Z

Ugh, I forgot about bug 6200. Paragraphs work fine, they just have to all be prefixed with <p>. I'll put figuring out 6200 on my to-do list. —Simetrical (talk • contribs) 00:30, 15 August 2006 (UTC)

Maybe the two methods ought to be labelled "Bad" and "Worse". Cheers. —Michael Z. 2006-08-15 00:48 Z

Quotations should never be in italics, even if the original material is italicized. Editors on Wikipedia have a bad habit of italicizing all quotations as a matter of course, and it's irritating to the eye, makes articles harder to read, and is distracting. Quoted material that is rendered in italics is normally underlined. Exploding Boy 04:38, 15 August 2006 (UTC)

I don't think I've ever seen that. What style guides recommend it? —Simetrical (talk • contribs) 19:05, 15 August 2006 (UTC)

float and line-height

I removed the text

In particular, do not use the CSS float or line-height properties because they break rendering on some browsers when large fonts are used.

with the summary "This page's HTML source contains 61 floats inline alone, and main.css alone has 17 line-height declarations. I mean, huh?" User:Mzajac restored it with summary "restore advice against complex markup *in article body*".

If the reason for not using those properties is "they break rendering on some browsers when large fonts are used", why does it matter whether they're in the article body or in the stylesheet? If the reason is because they're complex (as the positioning would seem to suggest), why single out those two? —Simetrical (talk • contribs) 18:25, 14 August 2006 (UTC)

Please keep in mind that the Manual of Style is intended to provide guidance for editors editing articles in the English Wikipedia, not to delineate what the MediaWiki software developers and designers are allowed to do.

Line-height is extremely buggy in some rather old browsers. There isn't much reason for an editor to use it in an article, and inconsistent line-height in an article is bad from a visual design point of view.

Float, and other positioning declarations can totally break the display in certain buggy web browsers, especially when they interact with other positioned elements. The skin style sheets are stable and have been well tested and debugged by designers who are CSS experts. New additions to the project style sheets are at least vetted by a community of editors experienced with CSS. But if editors start dropping new inline floats and other layout code into individual articles, then they may destroy the display of an article. This might effect only some obscure web browsers, possibly making an article completely unreadable for a small number of readers, with little or no opportunity for debugging and fixing, or requiring a large amount of layout work in an article's text field which which is unsuited for debugging CSS.

Other CSS can be problematic too, but these are two good examples which may be tempting to use.

Individual articles don't need special layout anyway, beyond what is achievable with the use of existing functions such as aligned images and templates. The edit field is for editing article content, not experimenting with new layout techniques. Complex layout in wikitext is to be avoided. —Michael Z. 2006-08-14 19:18 Z

Which browsers are we talking about here, may I ask? —Simetrical (talk • contribs) 00:32, 15 August 2006 (UTC)

From memory, an old version of MSIE/Mac would interpret integer line-heights as pixels, instead of relative size, so "line-height:2" would make lines of text overlap at 2-px intervals instead of being double-spaced.

MSIE/Windows 5 and 6 have various quirks with floats and other positioning that drive me mental when debugging web site designs.

Various versions of different browsers have their own quirks, every single one, and complex layout has to be widely tested and properly debugged, not just created ad hoc. For a hint of the problem, see Comparison of layout engines (CSS), or Google "browser CSS bugs". —Michael Z. 2006-08-15 00:46 Z

"Principles" addition

This is a substantial, contested addition to a guideline. Insofar as its substance is uncontroversial, it is long-winded and repetitive; please explain why it is necessary. Beyond that, it is in some parts a large alteration in the current standard, and should not be added without further discussion. If you could explain here the purpose of why you think this should be added, the proposal can be improved, rather than just adding it and reverting without discussion. —Centrx→talk • 21:33, 15 August 2006 (UTC)

I agree. By the way, I considered making an RFC, but the process and the page have become too complicated for my taste. Maurreen 07:12, 16 August 2006 (UTC)

Alphabetical Order (part II)

Note: Part I is archived Jimp 08:06, 26 October 2006 (UTC)

It seems to me that we ought to have specific guidelines on alphabetizing for lists. There's a lot of complicated stuff, for instance:

1. How to deal with "Mc" and "St" at the beginning. Traditionally, "Mc" is alphabetized as though it is "Mac," and "St" as though it is "Saint," but not always. I'd prefer to do it this way, even if it's a bit counter-intuitive, but at any rate we should have a specific policy.
2. Separate Words vs. continuing words. Which comes first "Fun rat" or "Fungus"? Under some criteria, one would alphabetize "Fun rat" as though it is simply "Fun" when comparing it to "Fungus" (and thus have it come first), while in others you ignore the space (in which case Fungus comes first).
3. Last name/first name issues. We ought to be clear that individuals like Marie de France or Wolfram von Eschenbach should be alphabetized by first name.
4. "De" - I think the French language has specific rules about when "De" is to be considered the beginning of the name, and when it is not. In English, I believe it always is. The "De" issue will also relate to point 2 - what comes first, Henry Dearborn or Thomas De Quincey?

This would apply not only to list articles, but also, I think, to categories, in instances where the automatic alphabetization doesn't follow whatever we choose to prefer). john k 14:32, 17 August 2006 (UTC)

I don't know what rules are used for automatic alphabetization. But if anyone does, maybe it would be good to make that the default, for the sake of simplicity. Maurreen 15:42, 17 August 2006 (UTC)

Well, "Mc" doesn't count as "Mac," obviously, nor "St" as "Saint." I'm not sure how it works for issue 2. john k 16:19, 17 August 2006 (UTC)

I like the idea of alphabetization guidelines. I'm ambivalent about the specifics.

1. Are we able to override automatic alphabetization in categories?

   Through piping, of course we are. john k 18:37, 17 August 2006 (UTC)

2. I lean toward putting "Fungus" before "Fun rat."
3. I don't get your point about Marie de France or Wolfram von Eschenbach.

   I mean, we should make clear what names are to be alphabetized by the first name. Marie de France should be under "M", not "F", and same deal with Wolfram. john k 18:37, 17 August 2006 (UTC)

4. I would lean toward consistent treatment for "Da", "De", "ibn, "Van, "Von", and so forth. Maybe that was what you meant, but I figured it'd be good to make it explicit. Maurreen 16:32, 17 August 2006 (UTC)

   Not necessarily. Anglophones with such names are often treated differently from natives, and should be. We should follow local custom of wherever the person is from. john k 18:37, 17 August 2006 (UTC)

The rule used for automatic alphabetization is unworkable and will be changed sooner or later so that it isn't insane. Basically, article names are sorted by Unicode code point. This means that in the English projects, the order is slightly illogical: they're sorted character-by-character, with ' !"#$%&'()*+,-./' coming before digits 0-9 in that order, which come before ':;<=>?@' in that order, which come before uppercase letters A-Z, which come before '[\]^_`' in that order, which come before lowercase letters a-z, and then there are some miscellaneous punctuation marks, then come non-ASCII letters (stuff you can't easily get on an English keyboard). This is weird for us, and of course it's hell for the Latin-based projects, which sort in all sorts of insane orders (accented chars always come after unaccented), as well as for Wiktionary (many of whose articles start with lowercase letters). See Mediazilla:164. —Simetrical (talk • contribs) 18:52, 17 August 2006 (UTC)

• I agree that specified rules for alphabetization would be useful. I would aim for a simple approach that does not need knowledge of any 'hidden' rules, such as the handling of Mc, but simply take each character position in order from the beginning:

1. Capital letters precede lower-case (so Zebra precedes aardvark)
2. Space precedes any other letter (so 'Fun rat' precedes 'Fungus')
3. Mac precedes Mc, and Saint precedes St.
4. 'Henry Dearborn' precedes 'Thomas De Quincey', but 'De Quincey, Thomas' precedes 'Dearborn, Henry'
5. We would have to agree where numbers, punctuation marks, and other symbols would fit in, as well as lesser used characters such as æ, å, and ß. Agreement on whether accents, diaresis marks, cedillas and so on are taken into account would also be needed. WLD 18:12, 17 August 2006 (UTC)

Capital letters precede lower-case? Why? Are you also suggesting alphabetization by first name? Again, why? Also "Saint" and "St." is hard to justify - The same place, for instance, could be called "Saint John" or "St. John". Why should they be alphabetized differently? In terms of accents, they should be received as "ae," "a", and "ss," I think. Numbers generally come first. Personally, I tend to prefer the so-called "hidden rules" which are usually rules for good reasons. We expect people to know other "hidden rules" of English grammar and usage, why shouldn't we use normal capitalization rules? Obviously, such rules shouldn't be used to beat newbies over the head with, but why not stick to the standard ways of doing things in English? john k 18:37, 17 August 2006 (UTC)

I would sort however seems the most natural to a typical English speaker. I agree that things like Mc = Mac can be confusing and unintuitive, but John Kenney makes a good point about alternate spellings. Capital and lowercase should always be considered equivalent, since that's how people think of them (but in otherwise identical words, the capital can go first) I would sort in the order

1. Punctuation marks and dingbats ☺✡♘♋ of all kinds. (These can be sorted in Unicode code point order if there's a conflict, and if anyone cares.)
2. Numbers, sorted in value order. 100 goes after 5, and 2.0 is sorted the same as 2 (reverting to per-character sorting in case of a collision).
3. Latin letters, with capital, lowercase, accented, and unaccented being considered equivalent.
   • In the case of a collision, accented goes after unaccented; if there's still a collision, lowercase goes after capital.
   • Ligatures should be sorted as their constituent letters, since that's how English speakers perceive them. Speakers of languages that use æ would probably expect it to be sorted some particular way, but when I (along with any other monolingual Anglophone) look at it I see "ae" squished together.
   • Exceptions could be made for äöü sorting as ae, oe, ue if it's judged that enough people are familiar with the rule.
   • Letters that are neither simple ligatures nor simply accented would be sorted on a case-by-case basis, primarily on the basis of how native speakers sort them (if applicable).
4. Non-Latin alphabetic, syllabic, or logographic symbols. They should be internally sorted based on how natives most commonly sort them; their relative order should probably follow Unicode order if it matters (Greek then Cyrillic then Armenian then Hebrew, etc.).

It's slightly complicated for the weird cases, which arguably it's not necessary to legislate in the first place, but the important points are easy to remember. Usually sorting only has to account for letters, numbers, and spaces (occasionally hyphens). Spaces would count as punctuation and so go before letters in this scheme. (And no, I haven't addressed names; those are tricky.) —Simetrical (talk • contribs) 18:52, 17 August 2006 (UTC)

This sounds mostly good. It leaves the "Mc/Mac" and "St/Saint" issues. I think that St/Saint pretty much has to be viewed as equivalent. Alphabetizing "St" as "St" creates tons of problems, since it's totally arbitrary whether a place uses "St" or "Saint" in its name (and the same thing in people's names, I think, as well). I'm less sure of "Mc". I have something of a preference for alphabetizing as "Mac." But I could be persuaded otherwise. john k 00:34, 18 August 2006 (UTC)

The explanation of the conventional sort order which treats "Mc" and "Mac" as equivalent, is that the sorting was done on the basis of the way the word sounds, not the way the word is spelled, This is also the basis of the traditional library sort order in card catalogs: but there the sorting is done on the basis of the way the word sounds in the language of the item. "2 Hommes" was alphabetized under D for deux, while "2 Men" would be under "T". (This is also the basis of traditional transliteration--it is intended to produce a word that sounds like the original, not just converts the letters). Even before on-line catalogs this was simpified, but even the simplified version is over 100 pages long. (Library of Congress filing rules / prepared by John C. Rather and Susan C. Biebel. 1980) The motivation for simplifying the rules, and using the written form, was so the catalog records could be sorted by a computer. . Part of my job for some years was teaching these absurdly complicated rules to new library assistants. I was however left with the lesson that such rules are always somewhat arbitrary: it is better to accept the ascii order, or whatever order one finds being used, than to modify it.

But be aware that other langagues use different sort orders, particularly for the accented letters, which sometimes go at the end of the sequence, and sometimes next to the unaccented letter; this is still necessary to be taken into account when using a printed bilingual dictionary.DGG 00:45, 23 September 2006 (UTC)

== Tag Essay-entry ==

I am looking in vain for an explanation on how to improve an article that has the following tag:

Any help? Thanks CuriousOliver 18:00, 17 August 2006 (UTC)

Could you link to the article? It probably needs to put in "encyclopedic tone", and to be organized as in Wikipedia:Guide to layout. —Centrx→talk • 15:07, 18 August 2006 (UTC)