Jump to content

Wikipedia talk:Manual of Style/Archive 35

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 30←Archive 33Archive 34Archive 35Archive 36Archive 37→Archive 40


Religions, deities, philosophies, doctrines and their adherents

I think that the rules of respect of each religion should be obeyed whenever possible. In particular, the Christian rule of capitalizing words referring to God. I don't think that this conflicts with any Wikipedia principle such as the NPOV, and while I am a Christian myself, I wouldn't mind to obey similar rules of other religions. Therefore, I propose this to be changed regarding the "Religions, deities, philosophies, doctrines and their adherents" policy. Jorge 03:06, 21 November 2005 (UTC)

So how do you propose, at the same time, to accommodate the rule in Judaism that would be violated by writing out the name of the deity in the way you just wrote it? (A practicing Jew in such a context would use a locution like "G-d"." -- Jmabel | Talk 17:48, 21 November 2005 (UTC)

I strongly disagree with Jorge. We should write in a style that as many readers as possible will understand, follow and (if possible) like. This is not necessarily the style that experts or those familiar with a particular subject will use - we should put our readers first. We show respect to our subjects by reporting factual information in (as far as possible) an unbiased way, not by changing our language to accommodate them, jguk 18:05, 21 November 2005 (UTC)

But even if a majority of wikipedia readers DID prefer capitalizing pronouns that refer to the christian god, would that really be the deciding point? For me, such a capitalization is tantamount to proclaiming the christian god is the One True God, which is POV, regardless of what percentage of the readership wants it. Alecmconroy 20:54, 21 November 2005 (UTC)
Do you think that the various news organisations, being neutral at least in name, should avoid capitalising "God" so as to avoid any seeming bias in favour of Christianity? It is my contention that rules and guidelines generally followed by the news media are no less applicable to Wikipedia.--chris.lawson 05:33, 22 November 2005 (UTC)
I think User:Alecmconroy was talking about not capitalizing personal pronouns that refer to the Christian god (i.e. He vs he), rather than not capitalizing the word "god" when it's being used as a proper noun to refer to a particular god (which would go against the English convention of always capitalizing proper nouns.) In the case of pronouns referring to one particular god or another, I agree that capitalization smacks of POV (unless the pronoun begins the sentence, obviously.) Eloil 06:14, 22 November 2005 (UTC)
Didn't think of this when I made my earlier comment, but what I said only applies to the article text, not quotes. I think changing "He" to "he" in a quote would also add inappropriate POV. Eloil 06:44, 22 November 2005 (UTC)
Ah yes. In that case (pronouns only), I agree fully. I might make the further argument that referring to the gender of God/Allah/Jehovah/etc. is also inherently POV. (I'm not a Bible scholar by any stretch, but who are we to say that a deity has a gender?)--chris.lawson 23:04, 22 November 2005 (UTC)
I'd tend to agree with that as well in the cases you mentioned (God/Allah/Jehovah), but it opens up some questions as far as extending the idea to other deities. For example, Jesus is considered by many to be a deity, but as a historical figure his gender is not seriously disputed (to my limited knowledge, anyway.) The idea of removing gendered pronouns from the articles on Thor or Zeus seems to me a bit like overkill as well, although I don't know if I could say exactly why this is. Eloil 04:32, 23 November 2005 (UTC)
The relevant source literature always refers to Yahweh, and Allah as masculine; and except for a few very recent and deliberate projects, the same is also true of "God." The relevant source literature also always refers to Thor and Zeus as masculine. The urge to make the sex (or "gender" if you prefer) of the God of the monotheistic revealed religions ambiguous is a product of very recent and temporary Western enthusiasms. God, Allah, Yahweh, and the like should remain masculine; to alter the sex of this or these deities is historically inaccurate revisionism. Smerdis of Tlön 05:42, 23 November 2005 (UTC)
Wow-- such really good points. I completely agree, Eloil, about the capitalization of "He" is appropriate if quoting another writer who used that case. It's interesting to imagine what to do if quoting not a writer but a SPEAKER-- though I can't expect that one to come up. Whether to capitalize the word "god" is trickier for me, because it can be both a proper name (and therefore capitalizable) or just a noun (and therefore lowercase). I'd be inclined to not capitalize in the sentence "Is there a god?" but would capitalize in the ever-so-slightly different sentence "Does God exist?". The gender issue is interesting. English really needs a good neuter third person that's not "it" (and a good second person plural that's not "ya'll").Alecmconroy 09:00, 23 November 2005 (UTC)

Looks like another problem that the template proposal for automatically rendering the various flavours of English (see above) could solve. PizzaMargherita 18:52, 21 November 2005 (UTC)

Is 'a' the best abbreviation for year as in 'Mt/a'?

Is 'a' the best abbreviation for year as in 'Mt/a'?

I would welcome ISO, NIST, BIPM or other respectable references on this. The article 'Acetic acid' quoted 'Mt/a'. I changed it to 'Mt/year' but it was changed back. Bobblewik 23:06, 23 November 2005 (UTC)

  • The use of 'a' for annum is a very common unit in the field of chemical industry, which is what the value of 2 Mt/a is about. For smaller amounts, such as production plant capacity also often kt/a or (worse) ktpa are very common abbreviations. You'll see the Mt/a use also in several other articles which include data about the chemical commodity industry, such as hydrochloric acid and 4,4'-MDI. External ref Quantities and Units, Part 1: Space and Time, ISO 31-1:1992 suggests 'a' too, I find now after looking around a bit. Wim van Dorst 23:31, 23 November 2005 (UTC).
Would this be worth noting at ISO 31-1 or year? It would perhaps give Bobblewik something useful to link to (i.e. Mt/a). It would probably be very difficult to find out what unit "a" indicated[1] if you didn't already have a very good idea from context. —HorsePunchKid→龜 2005-10-24 00:07:37Z

In English "Y" is much more commonly used, as in Y2K, YTD, YYYY - and I am sure others could provide many other examples. Years are not SI units anyway and they do not have a definite length, so all usage of it has to be a rough approximation. Every time I see it - and I am quite scientifically, "Latinly", and "Spanishly" literate, it takes me about 15 seconds to figure out what that freaking a is doing there - if I get it at all. I think use of seconds & hours should be encouraged & use of the indeterminate year be avoided. If year has to be used, I see no reason why it cannot be spelled out - not being an SI unit & being of indeterminate length, there will never be an official symbol for it anyway --JimWae 06:37, 29 November 2005 (UTC)

  • Year is not a SI unit and does not have an exact value
A year is exactly 365.24 etc earth days. Exactly. Stevage 16:23, 8 December 2005 (UTC)
  • "a" is ambiguous, it is also used for other non-SI units (e.g. are)
  • Other abbreviation beside "a" are used for year (e.g. "y")
  • Most readers are not familiar with any abbreviation for year

For easy reading I think we should always use "year" without mentioning "a" or "y" at all (i.e. "Mt/year"). Cacycle 21:52, 29 November 2005 (UTC)

Hello! I agree that a, while common, is also ambiguous to many. While year would do if there's doubt, this would appear odd in combination with SI or other abbreviations (e.g., Mt/year); how about yr or yr. (which appear in both Oxford and Webster's dictionaries) – e.g., Mt/yr? E Pluribus Anthony 03:07, 30 November 2005 (UTC)
The question was brought up as regards annual production of industrial chemicals. In the industrial news publications I'm familiar with, Mt/a is the usual abbreviation, or it is spelled out "million metric tons annually." As long as there is an explanatory note with the first use of the abbreviation (as there is in this case), Mt/a seems to fall into the category of units used for "historical or pragmatic reasons..." they are the standard unit in which the quantity is cited. Shimmin 03:46, 30 November 2005 (UTC)
When there is sufficient context (as in the initial example), a is acceptable; I think the topic, though, has mushroomed into one which concerns usage where insufficient context or explanation is provided, in which case a might be ambiguous ... ISO standards notwithstanding. In any case, a wikilink (Mt/a or Mt/a) would do in a pinch. We should ask ourselves, "what will visitors easily understand?" (as not all of them will be industrial engineers and chemists) and proceed on that basis. E Pluribus Anthony 03:57, 30 November 2005 (UTC)
This is interesting. I've always seen year abbreviated with a y in scientific context. I would associate a with are or a possibly ampere or ångström. I would never have thought about annum, unless the context suggested that the quantity in question was time. Actually, in that case, I might have suspected the attosecond. Don't take me as an expert or anything; I'm just a college sophomore. --TantalumTelluride 04:19, 2 December 2005 (UTC)
I'd go for Mt/year. -- Jmabel | Talk 06:11, 2 December 2005 (UTC)
In my earlier science classes, I always saw a used for year. I proposed the alternate yr since it would be in sync with abbreviations used elsewhere. It seems odd to abbreviate only one term but not another. That's it for me! :) E Pluribus Anthony 06:20, 2 December 2005 (UTC)
Scientific units can have different names in different languages, or even dialects of the same language, but the abbreviations are internationalized. Hence SI doesn't care that Americans call it a 'meter' and the British call it a 'metre', but does insist that everyone abbreviate it m. Now, the traditional units of time day, month, and year are not SI units, but they are used in the scientific literature, and a similar internationalizing principle applies, and the (highly western-centric) internationalizing principle is the Latin language, wherein the units in question are diem, mensem, and annum. We English speakers don't notice the abbreviations d and m as not-English, but a(nnnum) sticks out to us. Other languages suffer even greater mismatch between the international abbreviations and the local names, and use the abbreviations anyway. For example, the German wikipedia, in the entry de:Tag has the expression "1 d = 24 h = 1440 min = 86400 s". In local terms, that would mean "1 Tag = 24 Stunden = 1440 Minuten = 86400 Sekunden" Shimmin 00:30, 7 December 2005 (UTC)
Thanks for your note; agreed. I think we need to focus on what abbreviation will suffice for this non-SI unit, year, in this English Wikipedia. In any event, I would advocate for a logical abbreviation for year (e.g., yr in English; a(nnum) et al. in non-English wikipedias) based on common usage, precedent, and consensus. E Pluribus Anthony 19:47, 8 December 2005 (UTC)

Italics, and species references

In taxonomy it is standard to italicize the Genus and species for all organizms, not limited to bacteria. I have not payed particular attention, or noticed this is not being done in Wikipedia, but the MoS states it is specific to bacteria. Comments? SailorfromNH 01:25, 24 November 2005 (UTC)

Columns in articles

What are your thoughts on the use of columns to position sections side-by-side? Zondor (talk · contribs) has been implementing this format on a series of articles, but without discussion - which, for such a fundamental change to article formatting, I feel is necessary. For an example of what I am referring to, scroll to the end of this article or this article. I think guidelines are necessary - whether they discourage or encourage this format.--cj | talk 14:38, 24 November 2005 (UTC)

I don't really perceive this change in layout as earth-shaking. Long lists of short lines do look better in columns, and I've seen that approach taken in "List of..." articles before. It runs into troubles if the lists are liable to dramatic changes in length, and the column breaks need to be re-placed. Shimmin 14:49, 24 November 2005 (UTC)

Yes, but placing actual "headered" sections into colums is a new idea, as far as I'm aware.--cj | talk 04:42, 25 November 2005 (UTC)

I'm a bit concerned about this. I agree that columns look better under ideal circumstances, but there are a couple of potential problems. As Shimmin notes, it makes the articles a bit harder to edit and maintain—a newbie might have trouble with the column code, even with the templates. The breaks have to be repositioned if the sections are substantially changed.

The other–potentially more serious–problem is for editors and readers working at lower resolution or in non-maximized windows. The columns (particularly under {{col-3}} or {{col-4}}) could end up quite narrow; it's the sort of thing that could make references rather difficult to read or use. TenOfAllTrades(talk) 06:05, 25 November 2005 (UTC)

I really think this isn't a good idea. Columns to list items (like links) within sections can save some space, but what was on the John Howard page - sections side by side - disturbs the entire layout.
Remember that Wikipedia is still an encyclopedia, and it should be printable - by that I mean it would look okay in print... it's hard to explain I guess... But anyway, I really think this should be discouraged. That said, I don't intend to propose that it be discouraged, unless someone else is with me.
In the meantime, it is perfectly fair to revert any such changes because there is an unwritten convention columns are not used like that. So, if a guideline is to be made, it should reflect that (this convention is beyond doubt — other proposals are debatable; with this, I've never before seen columns used like that.) Neonumbers 11:22, 25 November 2005 (UTC)
I didn't want to propose anything until I had an idea of what the community's feeling was on this. There's been no discussion until now.--cj | talk 11:39, 25 November 2005 (UTC)

No, I don't think this is a good idea. Presentation and content should be as separate as possible, and while this may look good on high resolution screens it looks horrible at lower resolutions (like on Pocket PC or Palm devices). Sortan 16:27, 25 November 2005 (UTC)

I don't like it, apart from the mentioned problems, I just think it doesn't look as good. Martin 16:33, 25 November 2005 (UTC)

I can see the utility in some places, but I think this should be something left up to user preferences. I think I could hack out some simple CSS styles to do it in specific circumstances if people want the option, but I'd really rather not have the layout forced on me by the use of tables. —HorsePunchKid→龜 2005-11-25 21:21:56Z

I like it and think that it should be left to editors judgement and community consensus per article. I've applied it for example in List of object-oriented programming terms and List of Petri net tools where it fits nicely. The columns in Iraq War (permalink) also look good. Before this, I sometimes had the feeling that the verticle density of text in articles is sometimes quite low. I even have the feeling that increasing it where applicable is quite encyclopaedic. And technology will support this even better and better in the future as certainly the quality of display hardware will increase in the future. So we would be on the right track. On the other hand, I would put non-list content, especially whole sections in traditional style articles only with caution in sections. But I would not revert it if I see that and think it fits. Just Let the community decide per article. After all, it is a nice idea. – Adrian | Talk 09:02, 26 November 2005 (UTC)

My opinion is that we should allow it within a section (as per Iraq War) but not so that two different sections are next to each other. Section headers, and especially the edit links, don't look right when split. violet/riga (t) 10:11, 26 November 2005 (UTC)
Please note that the W3C accessibility guidelines state:
  • Tables should be used to mark up truly tabular information ("data tables"). Content developers should avoid using them to lay out pages ("layout tables"). Tables for any use also present special problems to users of screen readers
  • Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version).
  • If a table is used for layout, do not use any structural markup for the purpose of visual formatting.
Bobblewik 14:39, 26 November 2005 (UTC)

I think it is generally a bad idea, particularly when there are list items in the columns that're forced onto 2 or 3 lines (such as on Old Man's Child). As mentioned before, it often depends on the resolution of the monitors or device & the default text size in the browser. When I design web pages w/ tables and columns, I always evaluate it with several different base font sizes larger and smaller than my own. I these equate it to "over-engineering": Going too far to optimize (the use of space) for your-own browser environment often has unintended consequences. Unless you can be sure that features like columns are benign for every viewer, I think it's safer to keep it simple. Meegs 19:18, 27 November 2005 (UTC)

I think I agree with Violetriga's suggestion that columns be used only within sections. There is nothing really new about that, and it makes sense it many circumstances, as with dot points. The "col tags" created by Zondor make doing such easier. Perhaps we should recommend against placing secions in columns in Wikipedia:Guide to layout.--cj | talk 06:09, 30 November 2005 (UTC)
I concur with Violetriga and cj. E Pluribus Anthony 19:53, 8 December 2005 (UTC)
I dislike the columns, and if they are done, they need to be done in css; not tables. — Omegatron 22:51, 8 December 2005 (UTC)

Suggested style for using abbreviated units of measurement

I would suggest that, for example, "50 metres" should be expressed as "50m" rather than "50 m". If using an abbreviated unit, it almost always looks better to close up the number and unit (note that bar - the unit of pressure - is not an abbreviation, and thus should not be closed up). —Preceding unsigned comment added by 194.201.25.22 (talk • contribs) 28 Nov 2005

There has to be a space, see http://physics.nist.gov/cuu/Units/checklist.html Cacycle 22:04, 29 November 2005 (UTC)

Both "50m" and "50 m" are wrong. The correct form is "50 m". PizzaMargherita 22:16, 29 November 2005 (UTC)

But then the markup gets uglly. :-) — Omegatron 22:52, 8 December 2005 (UTC)

The space is important as 50m often means 50 million whereas 50 m means 50 metres.

Precision in using numbers

First, a word about significant figures (sf) and decimal places (dp): the precision of a number is denoted by the number of significant figures it contains, not necessarily the number of decimal places. For example, a length measurement of 30.8mm (to 1 decimal place) can also be rendered as 3.08cm (2dp), 0.0308m (4dp) or even 0.0000308km (7dp). In every case, the number contains three significant figures, and the precision of the measurement has not changed.

Generally, use the fewest possible digits and the fewest possible decimal places: 85.3m is preferable to 85,300mm or 0.0853km. You may want to break this rule to keep all the figures in the same units.

Figures rarely need to be given to more than 3 significant figures – you are unlikely to need such precision, and measurements are seldom accurate enough to justify it. Common exceptions include money (where $24,495 is a perfectly acceptable figure) and numbers beginning with the figure 1: it would be absurd to turn a measurement such as 1,002mm into 1.00m if you were comparing it with 998mm.

With all due respect, this doesn't make any sense to me. If I have a precise measurement, why should I round it? It would be short-sighted to impose such a restrictive and wide-ranging rule. Besides, what's so special about digit "1"? Is it not equally absurd to turn a measurement such as 2.004 m into 2.00 m if I'm comparing it with 1.996 m? PizzaMargherita 22:27, 29 November 2005 (UTC)

Round up rather than down – ie 2.904m becomes 2.90m, while 2.905m becomes 2.91m (and in this case, beware of turning 2.904m into 2.9m – see the next point).

Drop trailing zeros in most cases, ie use 18.3m rather than 18.30m, and 23m rather than 23.0m – unless: • you are differentiating between similar numbers, eg use “the trailer is 4.0m high, 200mm lower than the old 4.2m standard”. Or: • you have a group or table of figures with similar formats, eg gear ratios: 3.67, 3.84, 4.00 and 4.25:1.

Retain leading zeros, ie use 0.67m rather than .67m (but consider also using 670mm).

Thousands are clearer if separated by commas, ie 7,500kg rather than 7500kg. —Preceding unsigned comment added by 194.201.25.22 (talk • contribs) 28 Nov 2005

Hello! I was hoping a salient discussion of significant digits (SDs) and decimal places would occur somewhere. I fully support and concur with attempts to derive Wp standards around these concepts; however, everything must be assessed in context. If one figure is precise (e.g., 2.004 m) while another is not (e.g., 1.9 m), then a table should generally list each of these values (with a possible proviso about precision and accuracy). However, the recitation of a plethora of characters may be unwieldy for in-text references. ...
Also note that spaces are commonly used (particularly by scientists) when separating thousands in lieu of commas ... but I'm easy. :) E Pluribus Anthony 01:39, 30 November 2005 (UTC) ...

Why has the directive against links in the title (in the opening sentence) been removed? That's been established style for a long time, and I haven't seen some great upwell of protest against it. Occasionally one needs to make an exception, but that's true of most of our rules. I'd like to see that restored. -- Jmabel | Talk 06:22, 29 November 2005 (UTC)

I'll sencond that. PizzaMargherita 22:28, 29 November 2005 (UTC)
I concur. --Coolcaesar 23:00, 29 November 2005 (UTC)
I agree. Cacycle 23:52, 29 November 2005 (UTC)
Me too. -Willmcw 00:07, 30 November 2005 (UTC)
I might have been the culprit of this; if so, I apologise. I think if this directive is to be restored, it should not be unequivocal and modified to account for exceptions: I've noticed numerous article leads that are so wikified ... and effectively. And these despite the inclusion of this directive in this guide. E Pluribus Anthony 01:48, 30 November 2005 (UTC)
Thank you! I would only recommend replacing 'verbose titles' (in the current version) with 'certain complex titles or verbose leads', or similar; if there are no objections ... thanks again! E Pluribus Anthony 15:48, 30 November 2005 (UTC)

I do not see the need for that equivocation. It is a rare circumstance where the words in the title that are to be linked are not used again early in the article. There is nothing in the Manual to say that these words have to be linked in the first sentence or even in the first paragraph. I think that as long as the words re-appear and are linked in the first two paragraphs, the reader has ample opportunity to follow the links to the title words. I see no reason to change a long-standing directive just because there are many articles that do not follow it. It is common to see non-proper nouns capitalized in sub-headings, too, should we abandon the attempt to have uniformity in sub-headings, or should we apply the directive? I do not think that this debate is over, and wonder if others agree with me. If not, I'll stand down. Ground Zero | t 23:50, 30 November 2005 (UTC)

Noted. An absolute directive means nothing if it is not adhered to, and the wikifying of words/terms in titles is not at all rare. And the current directive remains clear while still allowing for uniformity and exceptions (i.e., used for articles that require it, particularly for terms/leads that are complex). Ditto (or should be) for caps in sub-headings. The introduction of the guide article is summative:
  • [rules and guidelines] are meant for the average case, and must be applied with a certain degree of elasticity. . . . Writers are not required to follow all or any of these rules: the joy of wiki editing is that perfection is not required.
That's it for me. E Pluribus Anthony 00:30, 1 December 2005 (UTC)

I'd be perfectly glad to see the original rule restored without qualification; my rewording was intended to meet Anthony halfway. Whichever works for other people, but something needs to be there. -- Jmabel | Talk 19:47, 6 December 2005 (UTC)

Thanks; I think the current qualification is fine while still being clear (and as above). In any event, my apologies for initiating a 'powderkeg'. :) E Pluribus Anthony 20:00, 6 December 2005 (UTC)
No need to apologize for stimulating discussion. Discussion of the style manual can only lead to improvements in it. Ground Zero | t 21:07, 6 December 2005 (UTC)
TY. :) E Pluribus Anthony 14:05, 7 December 2005 (UTC)

No explicit exceptions please. I believe it's six against one. 'Certain complex titles or verbose leads' is IMHO unclear and the other qualifications do not call for an exception. Links in the titles are downright ugly and do not add value. You have not convinced me that we need these specific exceptions, and why the generic "apply elasticity" rule does not suffice. A section well written would bring up any newly introduced concepts, and the editor should link there. PizzaMargherita 21:14, 6 December 2005 (UTC)

I reiterate my opposition to the proposed change. The need for an explicit exception isn't apparent, and would lead to confusion. Style guidelines should be clear and easy to maintain. -Willmcw 00:16, 7 December 2005 (UTC)
Noted. Perhaps the current version can be pruned or clarified to the original edit by Jmabel and not be so explicit? An opposing viewpoint can be that the original stipulation didn't make sense and that need for exceptions is apparent. Judiciously used, any wikilink adds value. Moreover, I'd prefer something that may or not be (to you) aesthetic to a larger, more problematic issue of having a tautology or redundancy through unnecessary repetition. I realise mine is not a majority position, but I reiterate the inappropriateness of including an unequivocal statement in such a document that (despite its existence) flies in the face of what some Wikipedians practice (i.e., not me alone) and does not allow for potential rare exception. And perhaps other qualifications require exceptions too?
If that is the consensus, fine. However, I contend the edition actually brings the manual in-line with practice and upfront assertions in the manual regarding elasticity and [im]"perfection." In summary: unequivocal, unenforceable guidelines (that are not Wp policy) despite reality will undoubtedly not lead to conformity in Wp style. As such, this may lead to the Manual of Style being treated with some (or additional) skepticism. Thanks! E Pluribus Anthony 13:57, 7 December 2005 (UTC)
Hey, I have an idea. A lot of people steal money, so let's realign the law to reality and make it legal, yes? PizzaMargherita 20:25, 7 December 2005 (UTC)
Excuse me? There's no need for your sarcasm. This unofficial guideline doesn't address morality or legality, and your comment flies in the face of any assumption of good faith. Moreover, your comment implies that the proponent of this opposing viewpoint advocates for incivility. If you cannot comment or argue rationally, don't. E Pluribus Anthony 01:46, 8 December 2005 (UTC)

Is there a specific example of an article where links in headings are a good idea? Sortan 01:48, 8 December 2005 (UTC)

One article, a featured one, I can think of is Military history of Canada. E Pluribus Anthony 01:51, 8 December 2005 (UTC)

Signpost articles

I have listed Category:Signpost articles (see Wikipedia:Manual of Style (signpost articles)) on Categories for deletion. Thanks/wangi 17:08, 30 November 2005 (UTC)

I have also removed Signpost articles from the main MoS page (the {{Style}} template). I cannot find any discussion on the creation of this type of article in the discussion archives. Thanks/wangi 09:32, 1 December 2005 (UTC)
And added it to miscellany for deletion: Wikipedia:Miscellany for deletion/Wikipedia:Manual of Style (signpost articles). Thanks/wangi 09:45, 1 December 2005 (UTC)

Double spaces

It says it doesn't matter whether you use single or double spaces in the markup, which is fine.  But using   to "enforce" double spaces in the rendered output (like  this) is definitely bad, right? — Omegatron 02:01, 1 December 2005 (UTC)

I agree, generally it shouldn't be done. PizzaMargherita 17:54, 1 December 2005 (UTC)
Would you look at that, WP eats up the space automagically! PizzaMargherita 17:55, 1 December 2005 (UTC)

Capital letters

I may have been looking in all the wrong places, but there doesn't seem to any section of the style manual about the uses of capital letters for some of the more esoteric examples. For example, eBay. It states in the trademark section that REALTOR should be considered Realtor, and so, according to this logic should eBay be changed to EBay? And if so, when? at the beginning of a sentence? or always? Also what of personal preference, like people like (I think) k. d. lang? Should all references to this person be reworked to normal usage (i.e. K. D. Lang) or not? Or only at the beginning of a sentence?

Linked to this, but not really, is the use of logograms, like the symbol that Prince used to go by, or the plus signs in C++. Since the +'s are just a symbol standing in for the word plus, to what extent should articles humor uncommon usages? 68.227.80.79 23:02, 2 December 2005 (UTC)

I believe an appropriate guiding principle (though you may well not find it written anywhere, and other editors may disagree) is to defer to the most common usage when in doubt. The reason articles can't start with lowercase letters (e.g. EBay) is purely technical, and it is still perfectly fine to write the link in lowercase (e.g. eBay and bell hooks). As to the various symbols, I think your best bet is to do something like [[C plus plus|C++]], again with the goal of conforming to most common usage, even though you have to do some trickery with the link. —HorsePunchKid→龜 2005-12-03 05:46:40Z
I guess my question here is more theoretical than practical. Very few people will die if from time to time a sentence does not begin with a capital letter or if certain symbols make their way into a context that generally precludes them. I guess my question is what exactly does on mean when one "defer[s] to the most common usage"? The most common usage for personal names is for them to begin with a capital letter, even if certain individuals prefer to not do so. It seems then (for me at least) that going along with such nonstandard usage shows a certain lack of seriousness as well as a bit of "suck-uppery," because (again for me) the article writers have not shown a certain distance from blatant personal idiosyncrasies. For other cases, such as eBay, there seems to be a difficult situation, because eBay is a trademark, and therefore according to this very style manual should be capitalized in all instances. 68.227.80.79 10:40, 3 December 2005 (UTC)
It is true that both these examples are very strange; I don't think you'd expect them to pop up in a manual of style, to be honest. If there is really such a war on beginning a sentence with eBay, find a way to reword the sentence so that a normal word starts it; in other cases eBay should be spelt like so (I believe that is its most common usage). With names, if most people capitalise the name in question then do so too, regardless of the preferences of the individual him/herself. Remember that the manual is not intended to be concrete; exceptions will arise from time to time. Neonumbers 05:24, 4 December 2005 (UTC)
Makes sense to me. E Pluribus Anthony 06:20, 4 December 2005 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Archive_35&oldid=1144672928"