Wikipedia talk:Manual of Style/Dates and numbers/Archive 33

Archive 30 Archive 31 Archive 32 Archive 33 Archive 34 Archive 35 Archive 40

Years

Hi, I'm a new user with a question. I read here that years on their own should not be placed in square brackets unless they are important, so for example 1974 does not need to be written 1974. However, when I removed the brackets from an article, another editor told me it should be written 1974. Does anyone know which is correct? The Manual of Style says "If the date doesn't contain a day and a month, then date preferences won't work, and square brackets won't respond to your readers' auto-formatting preferences. So unless there is a special relevance of the date link, there's no need to link it. This is an important point: simple years, decades and centuries should only be linked if there's a strong reason for doing so." Thank you. Pintele Yid 08:50, 11 November 2005 (UTC)

So, what's your question? What that is saying is that we don't need to be linking everything just because it can be linked (but there are different considerations if it is a full date with month and day, because of the additional use of the linking for the purpose of user preferences--something that many wish could be done some other way, but that's the way it is now). If a solitary year is linked, there should be some reason for either someone going to the year article to get to the article in which the year appears (some notable event associated with that year), or some special reason for someone reading the article to follow the link to see what else was happening in that year. Otherwise, it's no big deal for someone wanting to look up the year to enter the number in the Go box. Gene Nygaard 13:41, 11 November 2005 (UTC)
If that someone realizes it's possible. A person coming from paper encyclopedias would not necessarily think of that possibility - at least I wouldn't have if I hadn't seen the link coloring.

Date of birth / death plus location (re biographies)

What is the proper formatting to use for date of birth or date of death that also specify the location? The article Ben Abruzzo is what prompted me to raise the question. First off, is it appropriate to place the location with the dates? If so, what formatting should be used? Currently it is (b. June 9, 1930 at Rockford, Illinois, d. February 11, 1985 at Albuquerque, New Mexico). I think (June 9, 1930 at Rockford, Illinois – February 11, 1985 at Albuquerque, New Mexico) follows the date-only guidelines more closely. --Dan East 05:21, 17 November 2005 (UTC)

From what I've seen, the standard is to include them somewhere else in the article--Fallout boy 02:31, 23 November 2005 (UTC)
Thanks. There are a significant number of biographic articles with the location included in the parenthesized dob / dod that follows the name. Just from my sampling I would estimate it is at least 10-15%. --Dan East 03:05, 23 November 2005 (UTC)
The standard is indeed to include them elsewhere in the article, see Manual of Style (biographies) (Wikipedias in other languages include them). If there are already at the beginning, I tend to leave them where they are, but format as follows: "(June 9, 1930 in Rockford, Illinois - February 11, 1985 in Albuquerque, New Mexico)". -- User:Docu

Date of birth / death

I don't know when the ymd format got decided on (I simply saw a date changed with a note on wikifying). Yes, it has a good reason in a computer text, but with born and died separated by em dashes and no spaces, we get a very hard to read mess. In some cases (such as the one of Rosetta Sherwood Hall, mentioned above), an en dash was mistakenly used. Since it began with a place of birth [See Dan East's comments above], it was really confusing. Kdammers 10:52, 19 November 2005 (UTC)

Birthdate: Day known, but not year

What is the correct way to write a person's date of birth if the day of the year is known, but not the year? For example, Person X was born January 1, sometime in the early 19th century, but the exact year is not known (this sounds weird, but it does happen). A few articles have something like "January 1, unknown" which I think is poor grammar, and others use "January 1, 18??" or "January 1, c. 1800", the latter of which I think is correct as mentioned in the DOB section, but I could use some expertise and an update to the DOB style section. preceding unsigned comment by 130.65.240.178 (talk • contribs)

Good question. I don't think it's been considered here before. I'd say boot the day of the year and stick it in a comment, using the <!-- and --> tags, right next to the approximate year (noted by "c. 1800"). The reason I say this is that it makes no sense to put a more specific value without a less specific one (similar to, say, saying something is something and three-tenths of a metre long). I'm not sure who would agree with me.
If you take this view, though, remember to leave a comment where the exact date would be if it was known, so that if someone ever finds out, the entire date can be added straight away. Neonumbers 10:36, 19 November 2005 (UTC)

Avoid billion, trillion, etc.

Through an unfortunate accident of history the terms billion, trillion, quadrillion, &c. have become ambiguous. The MoS currently has this to say.

Billion is understood as 109 in the 
United States, Canada and most of the
English-speaking world.  However, in most 
Germanic and Romance languages,
it means 1012.  See the detailed discussion in
English-language numerals, long and short scales.

Note: the word most, not all. There are those of us who still cling to the original meaning of the word. Dictionaries still include it. As I've suggested on the Billion talk page we could quite easily avoid these words.

I suggest that the MoS be edited to recomend using thousand million when writing 109 in words and using scientific notation for 1012 and above.

Also it should read in most other Germanic: English is a Germanic language. Jimp 27Nov05

If billion is widely understood to be 109 in most of the English-speaking world, then why would we rewrite articles to use the unfamiliar and awkward (to many) thousand million? In North America, that phrasing sounds very archaic and British; it would not last long, as many would consider it to have be too dialect-specific or some kind of joke, if not just wrong. You might as well write thousand thousand thousand. — mjb 22:23, 26 November 2005 (UTC)
This argument is rehashed in perpituity, almost as soon as the last round ends. Fortunately, it very rarely matters in real articles—for scientific topics, scientific notation is used; when dealing with money, context makes it clear. Very few other things exist in such a size or quantity. "A thousand million" sounds awkward and verbose, unless you're a Brit over the age of 40 (or have simply conditioned yourself to be a pedant). Austin Hair 22:53, 26 November 2005 (UTC)

Why rewrite it? As I say: to avoid ambiguity. Thousand million sounds neither awkward nor verbose to me and I'm neither over 40 nor a Brit. However, if it's an old argument, sorry to be wasting time with it again. Then again, the fact that it keeps coming up may be an indication that it is a problem and that understood as 109 in ... most of the English-speaking world may not be all that accurate.

How, though, could thousand million be unfamiliar when it's only thousand and million both quite familiar? In North America it sounds "archaic and British". God forbid anything sounding British! Often what may sound British to American ears is actually quite common throughout Commonwealth English. On the other hand, if British English is too dialect-specific, why would North American English not be so? Jimp 27Nov05

Whenever it's brought up, the rabble-rouser never purports that he doesn't understand the 109 meaning of billion. Instead, he points to yet unencountered "others" who "might potentially be confused." Perhaps he's trying to save face; I can't say.
While most any American should be able to work out the meaning of "a thousand million," just as he could "a million billion," it sounds ridiculous to the American ear. Very few know of any other meaning for the words billion and trillion; it doesn't sound "British," it simply sounds wrong. Because the "American" (originally French, in fact) meanings have become standard elsewhere, I doubt this is confined to the United States. Austin Hair 04:02, 27 November 2005 (UTC)

Suppose that the rabble-rouser didn't understand the 109 meaning of billion. He'd either be blissfully unaware that the word could mean anything other than million million or simply not understand the word at all. Either way he'd not know that there is any ambiguity. Now if he were unaware of the ambiguity, would he come he to suggest the term be avoided?

Calling 109 a thousand million may sound wrong to your ears. Calling it a billion sounds wrong to mine. At least, though, the former is unambiguous and unversibly comprehensible. Jimp 27Nov05

This is the English Wikipedia. Our style guide already says to use the common terms when possible. If it is common in English speaking countries to use Billion to mean 109, then we should use Billion. What people do in non-English countries have little to no bearing on the English Wikipedia's style usage. Many other English borrowed words are also False friends with different meanings in other non-English countries and we shouldn't avoid them either. The article for billion seems to indicate that the current usage of billion as 109 is the most generally accepted term for this number: "now officially used by English-speaking countries". The ambiguity issue may be apt enough but the term thousand million is fairly prescriptive and you really haven't made the case that this term is common... or at least that other style guides, publications, encyclopedias, references, etc. currently use the term thousand million. --Sketchee 08:03, 27 November 2005 (UTC)
Other publications do use thousand million, but of course in this usage the thousands part is also often written in digits: 4,000 million, 3,500 million. But billions, etc., can often be avoided not only by that method and with scientific notation as mentioned above, but also in many other ways:
  • Use prefixes in measurements, such as gigahertz and megawatts and terameters. These prefixes are unambiguous.
  • Just use digits. It even takes up less space to write 3,850,000 than to write 3.85 million, and hardly any more to write 57,000,000,000 rather than 57 billion (and much less space if in addition you have to clarify what that billion means). That way the readers can call it whatever they want to in their own minds.
A related problem that should be especially discouraged is the use of "b" and "bn" and "m" and the like as abbreviations of billion, million, etc., as in "$3.5bn" or "£37m" and "75 b" and the like. This is seen far too often on Wikipedia. Gene Nygaard 09:51, 30 November 2005 (UTC)

That's a fair comment except I'm not refering to the word's use in other languages. Jimp 28Nov05

May I point out that a couple of years ago, the editors of the venerable British Journal Nature announced that henceforth Nature would use billion to mean 109. --Walter Siegmund (talk) 07:42, 17 December 2005 (UTC)

Links on years in Luxembourg (city)#History

From Talk:Luxembourg (city):

The history section being a summary, the selection of years included there is generally important. Some of the events are even mentionned in the corresponding year pages. Thus the years should be wikilinks.

This appears to be consistent with Wikipedia:Make_only_links_relevant_to_the_context references here. -- User:Docu

To avoid the problem, this page should probably just read "generally don't link twice", instead of "generally don't link". -- User:Docu
I do not think that would be an improvement. I think the key issue is relevance. I regard two irrelevant links as slightly worse than one irrelevant link. So generally don't link once is no different to me than generally don't link twice, we are still likely to disagree on that. I think year articles are so easy to access that I do not know why anyone would link them in body text. I have removed a lot of irrelevant links to solitary years, solitary months and even solitary days like Tuesday. I know that you are an experienced editor and I respect your opinion even if it varies from mine. But I thought that perhaps you weren't aware of the Manual of style guidance. I see now that you are. If you are determined that Luxembourg (city) should have the links, just put them back in according to what you think improves the article (I hope that it will not be all of them). Bobblewik 22:23, 29 November 2005 (UTC)
When would you think the years are relevant if not in such a history section? -- User:Docu
Good question. Never. Bobblewik 09:05, 30 November 2005 (UTC)
You might be interested learn more about Wikipedia:WikiProject Years. It puts the links to use. -- User:Docu

Non-standard ordinal abbreviations

EagleWSO has been changing ordinal abbreviations in articles about military units, for instance, 2nd Infantry Division (United States) has been moved to U.S. 2d Infantry Division, and similar edits have been made to the text. There is a little discussion on this at Wikipedia talk:Manual of Style (dates and numbers)/archive25#Policy on "3rd", etc. Are such edits a good idea? Susvolans 17:24, 30 November 2005 (UTC)

I think not. The US military units themselves use the longer one - like the 82nd Airborne Division, which EagleWSO has changed on Wikipedia to 82d Airborne Division. I've rarely seen the short version (2d, 3d, etc) used in English. If efficiency is our goal, then we should use the European method for ordinals "2.", "3.", "4." etc. Of course, since we're not here to be as ruthlessly efficient as possible (ask Louis Epstein about all the spaces wasted after punctuation!), I would go with readability. That is, 82nd Airborne Division, not 82d Airborne Division. --Habap 18:00, 30 November 2005 (UTC)
The "d" forms for 2 and 3 are in accordance with the U.S. Army style guide (Army Regulation 15 AR-15 if I remember correctly after all these years) and perhaps in other branches of service as well. Three are several Wikipedia articles which have had this format for a long time. There are many websites of U.S. military units using 2d and 3d and the same in higher decades; there are some whose websites use both 2nd and 2d. This is one case in which Google can be very helpful: Google "82d Airborne" site:.mil gives 17,700 hits while "2d Infantry" site:.mil gives 9,730 hits. That wouldn't happen if this were just some spelling error; it happens because it is officially endorsed. Both of these have more hits on .mil sites for the "2nd" form, but that won't be true of the ordinal numbers for all other units. Look also at the "patches" and other unit insignia of many of these units. Gene Nygaard 06:08, 1 December 2005 (UTC)
Then, we ask ourselves if a U.S. Army style guide is applicable to an encyclopedia. I am not so quick to accept that a guide for use in the Army is applicable here (as this is an encyclopedia for information), but I defer judgement to those more knowledgeable on the matter.
In any case, one guideline must be chosen and stuck to; this is one of those ones where it doesn't really matter that much so long as it's all (as in, all the U.S. Army articles) the same. In general, though, such edits are to be discouraged — in the vast majority of cases, "2nd, 3rd" should be used. Neonumbers 08:40, 1 December 2005 (UTC)
The other thing is that these are proper names. We follow use of Roman numerals for corps such as U.S. Army I Corps, and we are supposed to use U.S. Department of Defense no matter which underlying national variety of English is used.
These rules haven't existed forever; I know they were there 33 years ago, but I don't know how long before that. I don't know what the normal usage was during World War II, for example. They also aren't universally followed even within the services. I would suspect that units having a coat of arms or other insignia using the "rd" or "nd" form are more likely to continue using that. You will also often find internal consistency within any specific military document; either all 2nd and xx3d or all 2nd and xx3rd.
The 2d and 3d form is also common in U.S. legal case citation, with some spillover in other usage in legal circles.
I know that many of these Wikipedia articles have used this form for a long time, while other similar ones have used 2nd and 3rd. I don't see any great need to get overly prescriptive in our rules.
U.S. Government Printing Office Style Manual search, get pdf version or poorly formatted text
"9.32. The following and similar forms are used after a name:
Esq., Jr., Sr.
2d, 3d (or II, III) (not preceded by comma)"
...
" LIST OF ABBREVIATIONS
Standard word abbreviations
9.61. If abbreviations are required, use these forms:
...
Fed., Federal Reporter; F.3d, Federal Reporter, third series
...
2d, 3d, second, third"
Note that this general guide for the federal government prescribes the 2d and 3d forms, with not even a mention of 2nd and 3rd in Chapter 9 Abbreviations and Letter Symbols. Gene Nygaard 13:12, 1 December 2005 (UTC)
Wow. I had no idea. I never see 2d or 3d or such, so assumed it was non-standard. Go figure. I don't know what to think, but I am sure glad I didn't just go and revert those changes! --Habap 20:36, 1 December 2005 (UTC)
I was one of the people that moved 82bd Airborne. Every link to the article is to that name. Clearly it is the one that is most used -even if it isn't the army's official name. And even they don't consistently use the other. I vote for common names here. Rmhermen 16:55, 15 December 2005 (UTC)

Large numbers

Shouldnt large numbers direct to the number, not the year. I noticed a few large numbers had been tried to be made a year article which is a bit ridiculous. Special:Undelete/1000000000000 Astrokey44 14:21, 5 December 2005 (UTC)

I guess it is, a bit, isn't it? Tough call. I'd imagine there'd be some strong opposition to those who manage the year pages if we tried to decide they should be numbers. I guess it depends on whether or not there's truly something to put there. Neonumbers 06:13, 6 December 2005 (UTC)

Finalise currency

The currency discussions seemed to have died down (they are in the archives now). Can we finalise those proposals so that they are final? In its current form, and re-worded so that it is a guideline and not proposal, it should be fine. Neonumbers 04:05, 10 December 2005 (UTC)

Wouldn't it need a sample with ISO 4217 codes? -- User:Docu
I don't know; I had little part in the discussions. But it's not being discussed now, which implies it's final. I posted my views on the topic early in the original discussion and didn't look there again. Incidentally, I notice the current guideline (proposal) is remarkably simpler than the one I put forward... but never mind, that's not important just yet.
Point is, it's not being discussed, can we please remove the "proposed" template (well, it's being discussed now... you get the idea.)
A sample with ISO 4217 would do no harm, given of course that it doesn't conflict with the guideline (that is, the code is used where appropriate). Where's everyone else who discussed this? Neonumbers 09:39, 17 December 2005 (UTC)
If there are no objections on or before 26 December 2005 (UTC), I will remove all mentions of the currency section being a proposal, in effect making it official. Any changes thereafter will need to be discussed from scratch on this page to change an official guideline. Neonumbers 00:24, 23 December 2005 (UTC)
Done. The section is now an official guideline. Neonumbers 22:51, 28 December 2005 (UTC)

Year ranges: 'yyyy-yyyy' or 'yyyy-yy'?

Should we use 2 digit or 4 digit years in date ranges ('1508-16' or '1508-1516')? Bobblewik 10:56, 11 December 2005 (UTC)

Personally I prefer 'yyyy-yy', but isn't convention 'yyyy-yyyy'? So I tend to change them to the later. -User:Docu
I suspect it varies according to the style manual; Chicago, for instance, prefers yyyy-yy for dates within a century. —Kirill Lokshin 17:27, 11 December 2005 (UTC)
It looks like the Manual was revised on this point sometimes after August (without discussion). The former version pointed out that one shouldn't link 1508-1516 as "1508-16". -- User:Docu

Hyphens and En Dashes Sitting in a Tree

Re:

rv 4 changes by User:Chocolateboy and User:Rich Farmbrough to last version by Bobblewik. Even these changes need to be discussed - even consistency issues; please discuss first. [1]

They've been discussed to bits:

&c.

Hyphens are not deprecated. En dashes are tolerated, but changing from one to the other is discouraged:

... editors are encouraged to be accepting of others' dash preferences and not to modify a chosen style arbitrarily in the same way as they would refrain from arbitrarily changing "artefact" to "artifact" (or vice versa).

The two live in peace and harmony in this policy ("Ranges of dates are given with a spaced or unspaced hyphen or en dash (&ndash;)") as well as on Wikipedia:Manual of Style (dashes).

If you can't stand the status quo, use a user script.

chocolateboy 14:19, 13 December 2005 (UTC)

Just because dash characters are your long-standing pet hate doesn’t mean you can change project pages to fit your prejudices. Susvolans 14:24, 13 December 2005 (UTC)

That's not a response. There's no consensus to deprecate hyphens. This very article already flatly contradicts that as does Wikipedia:Manual of Style (dashes).

chocolateboy 14:32, 13 December 2005 (UTC)

Thank you for bringing this up on the talk page. I appreciate your concerns, however I must insist that this be discussed here before updating the project page to suit.
It is a late night, and I am tired, but I have briefly scanned pages and I will endeavour to research this issue as soon as I possibly can.
However, this manual of style is narrowly focused on recommendations for reporting dates and numbers, and it is clear here that the preferred method for reporting dates here is using an en-dash. If necessary, a reference to the appropriate page, mentioning briefly the extended situation, can be used.
I must ask that no changes to the project page be made on this matter until a convincing discussion here has been carried out. I do apologise for this; it must be lived with in the meantime. Neonumbers 10:51, 14 December 2005 (UTC)
---
I must insist that this be discussed here before updating the project page to suit.

This compromise was arrived at after long discussion. The onus is on you to explain how on earth this page ever arrived at such a state of inconsistency [2] [3] and disrepair [4].

It is a late night, and I am tired, but I have briefly scanned pages and I will endeavour to research this issue as soon as I possibly can.

Probably a good idea to at least defer the blind revert until non-tired and well-informed. Alternatively, simply read this article, the dashes article, and this comment:

In terms of linking this and the mos on dashes, as long as the two pages are consistent (last time I checked which was more than a month ago, they weren't) it should be okay [5]
---
it is clear here that the preferred method for reporting dates here is using an en-dash
Ranges of dates are given with a spaced or unspaced hyphen or en dash (&ndash;). See Wikipedia:Manual of Style (dashes). [6]
---
I must ask that no changes to the project page be made on this matter until a convincing discussion here has been carried out.

I "must" ask that you a) acquaint yourself with the policy of reading before reverting (AKA assuming good faith (and extremely long prior discussion of this topic)), and b) provide a link to the discussion where the decision to overthrow the status quo and infest the MoS with absurdity and inconsistency took place.

chocolateboy 13:45, 14 December 2005 (UTC)

I have been ignoring this issue until now I see people getting hot about it. I can't tell the difference between the variants. Please try and stay calm. Bobblewik 23:20, 14 December 2005 (UTC)
I have just taken a look at some of the links to guidance given here. Phrases suggesting that a hyphen is not MoS compliant seem very odd. Bobblewik 23:28, 14 December 2005 (UTC)
I have read the discussions you have listed above and will make an initial comment here.
Forgive me, but I counted many more editors in the discussions in favour of dashes in general, than there were for hyphens. However, that is another issue. Here, we worry only about dates and numbers.
The manual of style is for articles, not editors. If the manual recommends (say, e.g.) en dashes, then editors do not have to use them, but they must respect changes by others that convert their hyphens (where applicable) to en dashes. Furthermore, it is not in the place of the manual to encourage inconsistency, as it does when it recommends either-or. With this in mind, and remembering that dashes are grammatically correct and hyphens in their place are not, I remain firmly in favour of dashes. I regret to admit that it is not at all clear to me that hyphens are the status quo; in fact, if anything, the status quo is a mixture of correct and incorrect grammar. That, too, is another issue, and evidently it will not be resolved in the near future.
I go off on tangents like this to demonstrate what should (and should not) occur on this page. If the dashes debate is really so controversial, then the best this page can do is stay out of it. It is the purpose of this page to make recommendations for dates and numbers; dashes are of course included in this but it may be wiser to point a reader elsewhere for now.
If anything, the manual must not tell the reader to use either. It is generally considered bad style, albeit easier to manage, to use hyphens in place of en dashes. If the debate is so controversial, then the manual must either stay away from it or explain the situation. It cannot tell to use either.
Hence, even though I am convinced dashes are better, I grudgingly suggest that a link the the dashes manual be inserted, and for the purposes of this page, use en dashes throughout the page but do not explicitly recommend them. Neonumbers 00:01, 15 December 2005 (UTC)

First, I pulled your indentation back a bit as the comments were becoming hard to read. (Obviously) revert if it doesn't suit.

I'm happy to re-answer (and re-rebut) all of your points, but in the "interests of Wikilove", I'll be brief.

I don't personally have a problem if, to paraphrase Gdr, this particular article mentions both (without recommending either) while the wikitext uses en dashes to "illustrate best practice" [7], as long as that isn't construed as some sort of general license to violate the principles of typographical tolerance laid out in Wikipedia:Manual of Style (dashes).

I'd prefer this to be reinstated as well, but... one good "grudgingly" deserves another :-)

chocolateboy 01:51, 15 December 2005 (UTC)

---

I don't see what all the fuss is about—I thought this was only an issue before we had Unicode. Most editors can only easily enter hyphens, and that's fine, but en dashes are typographically correct, so I change incorrectly-used hyphens whenever I am copy-editing. I type literal dashes (hyphen: - en dash: – em dash —), so it doesn't ugly up the wikitext or inconvenience other editors.

PS: Is there an easy way to type these on Windows yet? Michael Z. 2005-12-15 00:50 Z

Wikipedia provides the en- (–) and em-dash (—) in the character insert box below the edit window. Place the edit cursor where you want either to appear, scroll down to the character box if needed, then click on the character that you want. It will appear whether or not the keyboard insert mode is on. — Joe Kress 20:54, 17 December 2005 (UTC)
To be honest, neither do I... but I guess if there's ever a place to battle out the merits of using dashes, it's not here. Best nothing more be said.
With (and not without) the consent of a few more editors, the manual change I suggested above (to remove any recommendations and any mention at all of the topic and point the user to the dashes manual, and to retain/change all occurences on this page to en dashes without explicitly recommending them) will be implemented. Neonumbers 05:49, 15 December 2005 (UTC)
I just noticed chocolateboy wanted both mentioned (is that right? correct me) — I still differ a bit here; I despise anything in a recommendation that says to use either-or; I'd prefer to just say something like, the type of dash used is controversial (or a better descriptor than that), for more info see WP:MOS (dashes). Neonumbers 05:55, 15 December 2005 (UTC)

Sigh .. it would be nice if a solution similar to the feature that ended the date formatting debate could be found (the setting on Special:Preferences).

In the meantime, the solution of "Wikipedia:Manual of Style (dashes)#Dash guidelines for Wikipedia editors" seems one to recommend: "editors are encouraged to be accepting of others' dash preferences and not to modify a chosen style arbitrarily in the same way as they would refrain from arbitrarily changing "artefact" to "artifact" (or vice versa)."

Thus, this page should offer samples of both solutions. - – -- — User:Docu