Wikipedia talk:Manual of Style/Archive 39

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 35

←

Archive 37

→

comma issue on the welcome template

Please visit Template talk:Welcome#Comma business (see poll) and weigh in on a comma placement issue on an important template. DES ^(talk) 19:22, 6 January 2006 (UTC)

Commas in numbers

Is there a Wikipedia policy regading the format of numbers over 10000? namely, should we write "10,000" (common usage, it seems) or "10 000" (SI standard, I believe)? Thanks, Jorge Stolfi 20:50, 6 January 2006 (UTC)

See Wikipedia:Manual of Style (dates and numbers)#Numbers (which is quite a bit disputed) −Woodstone 21:07, 6 January 2006 (UTC)

Capitalization of titles in foreign languages

There seems to be widely varied usage for the capitalization of titles written in languages that do not capitalize all words in them. For example, the poem Orlando Furioso is capitalized as it would be in English, whereas the opera Orlando furioso (Vivaldi) is capitalized as it would be in Italian. This has also come up for some organizations and so on. I cannot find an entry in the manual of style that seems relevant. Suggestions? Chick Bowen 00:29, 7 January 2006 (UTC)

This is the English Wikipedia. In English, all nouns are capitalized in titles. User:Zoe|^(talk) 02:51, 7 January 2006 (UTC)

Really? I had no idea that was a rule in English? - Marshman 03:56, 7 January 2006 (UTC)

That's what they taught me in English class. User:Zoe|^(talk) 23:05, 8 January 2006 (UTC)

Surely you aren’t suggesting we write: “The German title of Mozart’s KV525 is Eine Kleine Nachtmusik”. Or are you? (Kleine is not capitalised in German.) Arbor 10:01, 10 January 2006 (UTC)

It occurs to me that "furioso" isn't a noun, though. But the way I was taught is that almost every word in a title is capitalized, except for "the, a, an", "and", of", and certain other words that don't come to me right now. User:Zoe|^(talk) 20:26, 9 January 2006 (UTC)

If you try to capitalize the f in Académie française, the Académie française will hunt you down and guillotine you. That's what they taught me in French class. Joestynes 09:48, 10 January 2006 (UTC)

Perhaps you'll calm down when you realize these are page titles we're talking about here.

The current rule is that only the first is capitalized (and they may someday be fixed).
Where a page title is in a different language, of course they should be spelled exactly as they are in the foreign language. But the English language title will be spelled in English!
We've had a long problem recently resolved on Wikipedia:Naming conventions (places) to capitalize the English translations of place name terms in the same manner as the official native form.

Anyway, shouldn't this discussion be in Naming Conventions, not here?

--William Allen Simpson 18:47, 10 January 2006 (UTC)

No, when a page title is also the title of a work, we, by convention, capitalize it the same as the work. That's what we're discussing. User:Zoe|^(talk) 19:29, 10 January 2006 (UTC)

Improving the source text

There are several simple tricks that make the source texts of articles better readable without changing the appearance of the rendered pages:

Spaces between equal signs and the heading title
Space after list and indent signs
Empty line before and after headings
Empty line before and after images
Empty line before and after tables

Several of these examples have been made possible through software improvements during the last years and many users have quickly adopted this style. However, many examples given on the help pages and in the Manual of Style articles do not reflect this yet. What do you think about adding this or a revised list to a Manual of Style article and to change all code examples at Wikipedia accordingly.

Cacycle 23:34, 7 January 2006 (UTC)

I see what you mean, but I wouldn't go around changing it or enforce it in any nazi way. Perhaps a robot, but it doesn't look worth the while. One thing about empty lines: we should specify that we need only one, because extra lines, unlike HTML and TeX, do show. PizzaMargherita 23:49, 7 January 2006 (UTC)

I agree, the proposal is merely meant to provide good examples. Cacycle 10:03, 8 January 2006 (UTC)

One more:

Spaces before and after the "|" in wikilinks (e.g. in lists of links)

Cacycle 09:59, 8 January 2006 (UTC)

I have a little script that fixes some of these. I found myself doing it too often by hand on messy articles. Regex heading fixer

I will try to add the others.

Also, I remember a time when extra lines in the source still showed up as only one line in the rendered output. Why was this changed? — Omegatron 18:14, 8 January 2006 (UTC)

Yes please to all of these, although they should be suggestions only. These help in readability, and also help spell-check programs do their job (like the built-in Mac OS spell-check for edit fields in Safari). Heading–image shouldn't have a line space between, and I often leave out the line space for subordinate headings, and after headings of sections that only contain a list. In piped wikilinks, spaces before the pipe get dropped, but spaces after the pipe can be problematic (and now I don't remember why). Also, any spaces break auto-piped disambiguation links, like [[Eagle (disambiguation)|]]. —Michael Z. 2006-01-10 09:36 Z

I will start to apply the mentioned changes to examples in the Wikipedia namespace during the next few days. Cacycle 22:04, 16 January 2006 (UTC)

My script is here. It currently:

Removes excess newlines in a row
Adds space between == and heading
- ==Heading== → == Heading ==
Adds newline before and after headings
Adds space after list marker (* or #)

It's pretty kludgy right now (and I welcome suggestions), but it works, with a few false positives/negatives. I run it on a page I'm editing when the markup is difficult to read. You can even include it directly in your own monobook.js (needs addLink() function) and use it yourself, so it will be updated when I change it, though it will link to my page in your edit summaries.

Heading–image shouldn't have a line space between

It probably should, but the image markup is rendered in a way that makes it look bad? — Omegatron 18:13, 17 January 2006 (UTC)

I also think heading-heading and heading-image should be spaced for easier orientation. There are no technical problems with that. There is only a problem with heading-template spacing. Cacycle 09:54, 19 January 2006 (UTC)

Yeah, I just checked and they don't render any differently.

What should really happen is that the Mediawiki software should do this reformatting every time you edit/save, so you can be lazy about whitespace when entering it and the software will keep it tidy for you. Wikis should be easy to edit and all that... — Omegatron 15:10, 19 January 2006 (UTC)

Thought folks might want to know that User:Bevo is removing the spaces in headings and after headings, "standard and consistent internal and/or external formatting" edit comment. Especially just now at Wikipedia:Section. That does make it match Help:Section. The Wikipedia:Manual of Style (headings) is pretty laid back about the whole thing, merely saying "Some editors find this easier to read in the wikitext source code." Is it worth making a fuss over?

--William Allen Simpson 19:23, 19 January 2006 (UTC)

Uses of  , —, etc?

Is this the right place to document the uses of   etc? PizzaMargherita 23:54, 7 January 2006 (UTC)

See Wikipedia:Manual of Style (dashes).

--William Allen Simpson 13:19, 8 January 2006 (UTC)

Oh, ok thanks. So what about  ? For example, its uses after "e.g.", "i.e.", or "N. Surname" etc... PizzaMargherita 15:04, 8 January 2006 (UTC)

This would probably be a good place to discuss that. As a side note, "e.g." and "i.e" should not be used in Wikipedia. Don't remember where it says that, but their use is strongly discouraged. Kaldari 18:05, 8 January 2006 (UTC)

I don't think there's any prohibition; it's usually just good writing style to find a better way to express the idea, for instance by writing "for example", or by reformulating a sentence so that examples are presented more naturally. —Michael Z. 2006-01-8 18:33 Z

That's odd. It seems that Markalexander100 removed the section in June 2005 without any discussion. The section about i.e. e.g. etc was originally put in by Ortolan88 back in 2004. Ortolan88 is one of the most experienced editors on Wikipedia (going back to 2001) and something of an expert on style guides (having written much of the original article on Elements of Style among others). Seeing as how the section stood for nealy a year I don't think it was proper to delete it without discussion. Not only that, but I think it was good advice to have in the style guide regardless. Unless anyone objects, I would like to add it back under the Usage section. Kaldari 19:31, 8 January 2006 (UTC)

Please put the paragraph back, posh school snobs not-with-standing. (Actually, Mark seems like the kind of guy I'd enjoy, but there's no accounting for taste.)

--William Allen Simpson 22:36, 8 January 2006 (UTC)

Thanks, Kaldari! --William Allen Simpson 04:12, 9 January 2006 (UTC)

Oh, good. I like that, too. User:Omegatron#i.e..2C_e.g..2C_etc. — Omegatron 07:20, 9 January 2006 (UTC)

Ok, so back to the point... PizzaMargherita 07:17, 9 January 2006 (UTC)

I wish nbsp wasn't so ugly to markup. — Omegatron 07:22, 9 January 2006 (UTC)

Sorry I probably haven't been very explicit in my request :) I give for granted that the use of nbsp, ugly though it is, is the only correct option in some circumstances. Can you please help me cobble a list of such circumstances and suggest where to put it in the MoS? Thanks PizzaMargherita 08:13, 9 January 2006 (UTC)

But is it worth it? If we really put it everywhere it's necessary for proper typography, the markup will get all cluttered up and unreadable again. I don't think there's a way to add it in plain Unicode is there? It will just get converted into a space. Maybe if there was a special markup for it. — Omegatron 08:22, 9 January 2006 (UTC)

There's no current need for anything more about nbsp in the MoS, as the article Non-breaking space seems to cover the field sufficiently.

--William Allen Simpson 14:44, 9 January 2006 (UTC)

I hope I'm not the only one who is striving for "proper typography" on WP. I disagree that this goal would make the markup "unreadable again".

There is also an article about dash, but that does link to Wikipedia:Manual of Style (dashes). Why shouldn't we have a policy for nbsp as well? PizzaMargherita 15:59, 9 January 2006 (UTC)

I think that gidence on when this should be used, when it may be used and when it probably should not be used in wikipedia article text would be a good addition to the MOS. Noting the dislike that many have for its apparence would be part of that, IMO. Perhaps Wikipedia:Manual of Style (HTML entities) should be created? DES ^(talk) 16:25, 9 January 2006 (UTC)

I agree, except for 1. Like it or not that's the only right thing to do AFAIK, and 2. I don't think Wikipedia:Manual of Style (HTML entities) is a good idea, because a MoS should be driven by style, not the technology available to attain that style. PizzaMargherita 17:02, 9 January 2006 (UTC)

Note that if you are using a Macintosh computer, you can enter a literal Unicode non-breaking space by just typing "option-space". You can probably do this on Windows by typing alt-0160 or something (anyone know?). This leaves the wikitext nice and clean, but has a couple of disadvantages.

It looks like a regular space, so you can't easily tell if non-breaking spaces have been entered.
Some old web browsers don't support Unicode properly, and replace such non-breaking spaces with plain spaces on any edit of the page. This happens occasionally when someone else edits a page. MSIE 5/Mac does this, and I think MSIE 5 or 5.5/Windows might.

—Michael Z. 2006-01-9 17:57 Z

The main problem with this is that it is almost imposible for a future editor to tell that it is there -- I think the only way would be to copy the wiki=text into an editor that shows exact character codes, which is not normal editing practice for most of us. Until wikimedia editboxes display this character is some usefully different way under comon browsers, I would say this should not be used. DES ^(talk) 21:26, 9 January 2006 (UTC)

As for a possible Wikipedia:Manual of Style (HTML entities), there are really two different sorts of issues. 1) when to use each special character (non-breaking space, amersand, endash, emdash, right arrow, etc) 2) When to use the HTML entity vs a unicode character or other implemntation. Wikipedia:Manual of Style (dashes) covers both issues for dashes. Perhaps we should have Wikipedia:Manual of Style (special characters), which could cover the above (with a pointer to the existign page for dashes) plus degree signs, superscript characters (as opposwd to a <sup> tag) and other special characters. DES ^(talk) 21:26, 9 January 2006 (UTC)

The first problem with Unicode non-breaking spaces is not serious. Non-breaking spaces aren't shown by default in many word processing programs, etc, and the average user doesn't know or care. When you see an awkward word break, just add a non-breaking space to the article. If you're serious about it, you can use a special font which shows non-breaking spaces in the edit field (by setting your browser prefs or using a Wikipedia user style sheet), or paste the text into a more sophisticated text editor program.

The second, however, means that when Unicode non-breaking spaces are entered, they may disappear sooner or later. Too bad—it's not the end of the world. Current web browser software all seems to preserve Unicode characters, and eventually editors will stop using broken old browsers. —Michael Z. 2006-01-9 22:19 Z

Really? I thought Mediawiki stripped them out. Time to experiment! (And change my scripts.) If this works, I'd say Unicode versions are good. (And would love to know about a font that will let me see en dashes, em dashes, nbsps, etc. in the edit window.) — Omegatron 06:15, 11 January 2006 (UTC)

Doesn't work for me. — Omegatron 06:22, 11 January 2006 (UTC)

The idea of Wikipedia:Manual of Style (special characters) is interesting, as I myself have always wondered when it is best to use Unicode characters and when it is best to use HTML entities. I've never been consistant about it. If we did create such a page, what would it say? Would there be detailed advice for each character or would it end up just saying "Use Unicode characters instead of HTML entities"? Kaldari 22:23, 9 January 2006 (UTC)

That would need to be debated. I would favor somethign a bit more detailed, but my general advice would be "use HTML entities rather than Unicode charaters when possible". All too often, it is hard on nediting to determine what a unicode character is supposed to be. Not all browsers display unicode characters properly.

I would also include guidence on when to use the character at all -- for example when to use & as op[posed to using "and"; when to use a non-breaking space as opposed to a normal spce; whether to use special superccript characters for squared and cubed (I would say no, always use a superscript tag instead); and other similar guidence. If the page on dashes didn't already exist, its content would go on such a page, and it could be merged into such a page, except that dashes are particularly important and often misunderstood and mis-used. DES ^(talk) 22:35, 9 January 2006 (UTC)

I would also include a list of all HTML entities recognized by the Wikimedia software and generally considered acceptable on wikipedia. DES ^(talk) 22:37, 9 January 2006 (UTC)

I think that TeX's use of tilde (~) is pretty readable and a good shorthand for the non-breakable space. IMHO it is much less ugly than the   notation, especially when editing a text part that has a lot of them, e.g., a bibliography. The entity vs. Unicode thing for other entities that you're discussing is already addressed by a robot here. --BACbKA 22:02, 10 January 2006 (UTC)

The TeX usage is all very well, but MediaWiki does not currently support it AFAIK. A robot cannot determine what the policy should be, and IMO such changes should not be bening made robotically in the absence of a clear policy. Which robot do you refer to? DES ^(talk) 22:08, 10 January 2006 (UTC)

I'm curious about this too. I periodically notice robots changing HTML entities into Unicode characters. Theoretically someone could start running a bot which did the opposite. That would be fun: edit wars by bots :) Kaldari 23:51, 10 January 2006 (UTC)

I am aware that currently the tilde doesn't have any special meaning. I was trying to suggest a markup change here. As for the robots, the one I encountered the most was User:Curpsbot-unicodify. Edit warring by robots can spawn more robots auto-blocking the warring ones ;-) One of those days, the robots will just right the encyclopedia while we all sit back and rest, won't they? --BACbKA 00:02, 11 January 2006 (UTC)

Here's an interesting note: "The Mediawiki software now has a list of old browsers that cannot handle Unicode correctly, and presents these browsers with a "safe" version of the page to edit." Perhaps Unicode is the way to go then, at least for relatively common Unicode characters (such as dashes, accented vowels, degree symbols, etc.) Kaldari 06:23, 11 January 2006 (UTC)

Yes. That's why curpsbot and my scripts are doing it. Doesn't help with nbsp as far as I can tell, though.

Also everyone see this feature request for on-the-fly conversion from HTML entities to actual unicode in the edit box. — Omegatron 06:28, 11 January 2006 (UTC)

Italics and visual disabilities

Note that italicizing text can make it harder for people with visual or cognitive disabilities to read [1]

Is this really a rule? I think this is counter-productive. Someone with a serious problem reading italic text would just turn off italic rendering in their browser or render text in <em> tags with bold or something. That's not our responsibility. We should keep the extra formatting information/javascript/special characters/semantic information in the source code, and if people want to turn it off or display it differently on their end, they can. Isn't that the way the internet works?

We don't say "write everything in a very large font so that people with poor eyesight can read it". They just view everything in a very large font.

I think this sentence should be removed. That's something for Wikipedia:Accessibility to worry about, not the Manual of Style. — Omegatron 21:44, 13 January 2006 (UTC)

I fully agree. PizzaMargherita 23:00, 13 January 2006 (UTC)

I concur. --Coolcaesar 01:33, 14 January 2006 (UTC)

I agree. Neonumbers 10:31, 14 January 2006 (UTC)

Absolutely. Martin 10:40, 14 January 2006 (UTC)

Gone. PizzaMargherita 13:31, 14 January 2006 (UTC)

Proposed addition: Avoid float stacking

Float stacking occurs when several templates or images are floated onebelow each other. When a float stack crosses over an eading, it causes the [edit] link to be moved to the left of the lastobject in the stack, typically in a disconcerting position where it is hard to find. Sometimes, whhen a particularly tall template of image is combined with small section a whole slew of links are bunched together. This is particularly frequent with taller templates (such as many infobox).

See for example Islamic architecture, where the combination of the {{islam}} and a large picture causes the link for the Elements of Islamic style section to move down to upper left cornerof the image. If the imagewas in the header, it would cause both section links to jump.

The best way to avoid float stack is to move the second element of the stack below the problematic header, which does not alter its final position. One can also float the image to the left instead.

How does that sounds for an addition? Circeus 15:40, 14 January 2006 (UTC)

Objection with "does not alter its final position": it depends heavily on the user's font size. With a sufficiently large font size, they will separate (not saying it's a bad thing).

An alternate solution, which also avoids the edit link problem, is to convert the stack of right floats into rows inside a single right-floated table (which I've seen used sometimes in the stack of floats on some of the MoS style pages).

--cesarb 16:25, 14 January 2006 (UTC)

Well, this was written for the default font size, which I assume will cover a huge part of the visitors, maybe I should do some text atlarger size, though. And while I've seen the tables before, I find them to be semantically inappropriate use of tables. It is usually simpler to just move th seconde pic somewhere else (a few paragraphs below, for example, will most often give a virtually identical result). Circeus 16:39, 14 January 2006 (UTC)

Distinguishing l and I

When I type here, a capital "I" (eye) and a lower-case "l" (el) look, appropriately, quite different. But on any Wik page I've ever seen (I've seen Wik on many machines, but not where I have authority to change appearances), they look indistinguishable. At times this is confusing. Can something be done to correct this?

Nearly every sans serif font has this confusion (whereas serif fonts usually don't). But since we're not about to add serifs to everything, I don't see any practical way around this potential confusion. In practice in English writing I don't think it's much of an issue, as it's usually obvious from context which it is. If it is unclear in a particular context, you can clarify with a parenthetical remark or possibly use of <math>\ell</math> (

\ell

). Deco 22:09, 15 January 2006 (UTC)