Jump to content

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

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is the current revision of this page, as edited by Legobot (talk | contribs) at 19:19, 24 March 2023 (Bot: Fixing lint errors, replacing obsolete HTML tags: <tt> (2x)). The present address (URL) is a permanent link to this version.

(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)
Archive 55Archive 57Archive 58Archive 59Archive 60Archive 61Archive 65

Year in subject

I've added a section explaining the use of "Year in subject" links, such as 1417 in art. As far as I know, there is no documentation on when to use these links, so I've just tried to explain how they are used. Feel free to update as needed. — Reinyday, 22:10, 7 September 2006 (UTC)

Well, they are mentioned just above where you put them, as well as in WP:PIPE. I don't disagree with what you've said, but I'm not at all sure we need a whole section about it. I tend to feel that this page is too long already.
If we do have a section about it, I think it should mention the argument against such links, that they lead to "surprise" destinations, which is something piped links should avoid. Also that they break users' date preferences if used in a full date. Those are the most important things from a stylistic point of view.
But again, all this is already said at the two places I mentioned, and I doubt we need to say it again. What do other people think?
Stephen Turner (Talk) 06:34, 8 September 2006 (UTC)
I agree, if this section stays, it should be changed to say that uses such as [[2006 in archaeology|2006 archaeological discoveries]] are encouraged, not just optional, and other uses are discouraged. Surprise links definitely need to be avoided. -- Renesis13 06:44, 8 September 2006 (UTC)

Units in unremarkable quotes

I added metric units to Lake Wallenpaupack. Then I happened to notice that the piece of text was a quote. Since it was not particularly remarkable, I changed it from a quote to an attribution. Another editor User:Suoerh2 reverted it with the following comment on my talk page:

I don't know what you intent was with this edit, but you integrated a quote into the main prose, thus making it look like Wikipedia's own material, when in fact it was taken from another source (which would be a copyright violation). This is a very serious error hidden underneath a edit with the innocent sounding name "units", one would assume that all you did was fix up some units or something, so probably many users just skipped checking the edit. Please be more careful in the future, such a serious error is a high price to pay for the very minor (or even questionable) units edits that you make en masse. Suoerh2 09:11, 10 September 2006 (UTC)

My intent was to make the units clear. Many Wikipedia readers have no idea what a board foot means. The addition of metric units meant that it was no longer a quote. So I changed it so that it did not mislead the reader into thinking that the added text was in the original source. To be honest, that amount of unremarkable text in a quote seems odd to me. I think that article needs attention. Perhaps I should have used square brackets or something. What do others think? bobblewik 09:33, 10 September 2006 (UTC)

I think that Suoerh2 is right here. I do not agree that adding conversions in brackets constitutes making quoted text "unquoted", just as adding a (sic) to spelling mistakes wouldn't also. I think the quote should remain inside blockquote tags with any conversions in brackets--Clawed 10:43, 10 September 2006 (UTC)
I don't. Did you look at both diffs, Clawed? Essentially Bobblewik changed it from a direct quotation to paraphrased information, in order that he could then add metric conversions. I think this was a good solution. Although perhaps paraphrasing it a little more would avoid the possibility of a copyvio. Stephen Turner (Talk) 11:12, 10 September 2006 (UTC)
As far as copyright violation goes, I would think that copying one paragraph from a web site with much more than one paragraph of text is fair use, especially when the information is freely available on the web, and the copying does not appear to create any commercial disadvantage to the publisher. In a different case, where there was a copyright violiation, paraphrasing the text wouldn't make the violation worse, and might cure it if the paraphrasing was thorogh enough.
It is a widespread practice to place additional information into a quotation within square brackets, and still present the material as a quotation. --Gerry Ashton 18:28, 10 September 2006 (UTC)
Suoerh2 is quoted by bobblewik as writing "I don't know what you intent was with this edit, but you integrated a quote into the main prose, thus making it look like Wikipedia's own material, when in fact it was taken from another source (which would be a copyright violation)." In the USA, where Wikipedia is hosted, I understand that while copyright protects authors against unauthorized copying and the creation of unauthorized derivative works, authors do not have a moral right of attribution. So a short quote or paraphrase that would be legal with attribution is still legal without attribution, so it would be plagiarism rather than a copyright violation. If any further discussion is required, it should occur on a more relevant page, such as Talk:Lake Wallenpaupack --Gerry Ashton 18:53, 10 September 2006 (UTC)
So what you are basically saying is that I can take almost any informational paragraph from any website (as long as they are not charging for access to that paragraph) and cut-and-paste it directly into a relevant Wikipedia page so that it looks as though it is Wikipedia's own paragraph and not a quote and not even provide a source for it? That is absolutely at odds with several of Wikipedia's fundamental principles. If you are quoting something then make it clear that it is a quote and from where you are quoting it. If your obsession with units requires to to change the quote either 1) leave it as a quote and add your changes in square brackets 2) actually completely rewrite the material (and what Bobblewik did was not a rewrite, he changed a word here and there). Suoerh2 22:56, 10 September 2006 (UTC)
I am saying that copying an amount of text that is allowed under the fair-use exception to the copyright law is not a violation of the copyright law. If it is not properly attributed, it is against Wikipedia policy and it makes Wikipedia editors look sloppy and uneducated. It is plagarism. It is bad. Any editor who notices it should fix it. But it isn't a violation of the copyright law, at least in the USA. --Gerry Ashton 22:32, 11 September 2006 (UTC)
I would leave the quote and use the [square brackets] —not (parethesis). MJCdetroit 03:34, 11 September 2006 (UTC)
I agree now. This is an even better solution than bobblewik's. Stephen Turner (Talk) 09:12, 11 September 2006 (UTC)
Thanks guys. I should have thought of that in the first place. Suoerh2 was right to challenge what I did and we have a good outcome. However, I would like to remark that terms such as 'innocent-sounding', 'questionable', 'obsession' are inherently negative and I was a little offended. Please can we try to be polite to each other. bobblewik 21:51, 11 September 2006 (UTC)

BC vs BCE and AD vs CE

Isn't it time we standardized the encyclopedia to use either BCE or BC? A Train take the 14:52, 15 September 2006 (UTC)

If and only if you want to start a flame war. For some reason, people find it a very emotive topic. Stephen Turner (Talk) 15:02, 15 September 2006 (UTC)
Well, it’s a bit stupid after all to call a dog a cat, then to pretend it really was a cat now. The year numbering of the Gregorian calendar, i.e. its epoch, is Christian-based (although the calendar itself has older, mostly Roman roots) and no additional E will change that. Like it or not. Anyhow, what if I wanted to standardise on the minus (and optional plus) sign, because that already is a standard? Better let’s not touch the issue and pretend it’ll go away some day magically. Christoph Päper 15:11, 15 September 2006 (UTC)
... case in point. Powers T 21:22, 16 September 2006 (UTC)
I believe this is pertinent topic that should be dealt with. Wikipedia should adopt a formalized standard of era dating in hopes of better article clarity, reduction of repetition, and for the hollistic approach of information inclusion inside the wiki engine. To purpose the continued inclusion of BC and AD cheapens the integrity of Wikipedia as to be seen as a valid source of knowledge when compaired to other scholarly forms. Also, the inclusion of BC and AD lend a pretension of Western Culture (in this case non-secular) which should be disapproved of in an attempt at unbiased histories. B. Welsh3:54, 16 October 2006 {UTC)
I, too, feel a standardization would be appropriate. The sillyness of the system we use is obvious:
  • Why date things of a non-religious nature (or of a religious-but-not-Christian nature) from the birth of the founder of that particular religion?
  • If we insist on doing that, why use an incorrect year of birth when we know better?
  • Why not remove the stupidity of not having a year zero? From January 1st year 10 BC to the same date AD 10 is a period of exactly 19, not 20 years - how practical is that? The "rational" solution would be to write "1 BC" as "year 0", and hence "10 BC" as "year -9".
  • Why maintain a system where years "before" have the "code" after the year (as in "10 BC"), whilst years "after" have the code before (as in "AD 10")?
  • Why insist on accepting two different abbreviations for the same thing (BC/BCE and AD/CE), leading to confused unproductive edit wars?
Feel free to add to this list. However, the answer to many of these questions is equally obvious: Because we have no alternative that would be generally accepted. All the same, I find it hard to defend using BC/AD, while maintaining that our project aims at NPOV. The only realistic alternative is consistent use of BCE/CE.--Niels Ø 13:42, 19 October 2006 (UTC)
I really feel it's not worth having this debate again here. The arguments for and against both sets of abbreviations have been well-rehearsed, and the present uneasy truce is probably the best compromise we're going to get. Stephen Turner (Talk) 13:56, 19 October 2006 (UTC)
Where can I find an archive of these discussions? I would be very interested in seing any valid arguments for BC/AD, as I can't think of any.--Niels Ø 15:29, 19 October 2006 (UTC)
I think the main arguments in favour of AD/BC are
  1. That it is the normal usage for most people. Speaking from a UK perspective, CE/BCE is almost unknown except in certain academic circles. For people who do know it, it comes across as something you might hear in an American university, but probably nowhere else;
  2. It is such pointed political correctness that it is more POV than the usage it is trying to replace. It has strong anti-Christian connotations, whereas AD/BC is so familiar that people never think of its origin.
I make these comments not as an attempt to engage in the argument, but simply to show that there are strong arguments on both sides.
As for previous discussions, there are loads stretching back years, but here are some for starters: Wikipedia talk:Eras, Wikipedia talk:Manual of Style (dates and numbers)/archive9, Wikipedia:Neutral point of view/BCE-CE Debate. You can probably find more by searching for something like "BCE BC CE AD". It is notable that all of these were failed attempts to change the current guidance.
Hope that helps.
Stephen Turner (Talk) 16:03, 19 October 2006 (UTC)

An archived discussion of this topic is in archive #9 at the top of the page, and there are valid arguments for both sides. I wish Wikipedia would adopt uniformity on items such as this, units of measurement, English language, etc. I understand everyone comes from different backgrounds, but being a single piece of reference work, regardless of what the decision is on AD/CE, metric/imperial or American/British English, I believe a uniform policy would be better than "what the article was started in." There is no one to "make" these decisions, however, and the contributor base is obviously strongly divided over them. I would prefer BC/AD, metric units (with imperial conversions) and American English, but would still contribute even if I had to write in BCE/CE, imperial units and British English. The project as a whole should be more important than small debates over semantics or POV. --MattWright (talk) 16:09, 19 October 2006 (UTC)

Date ranges

Based on a discussion at WP:ANI, I wonder about how ranges of wikdates can be handled. If we have (say) 1 – 10 October 2006, and we change it into wikidates, should we have:

There seems to be no easy way of doing this. --Jumbo 00:48, 1 October 2006 (UTC)

The first two are clearly bad. The last would make sense if there were a comma, but then the comma would be removed because of date preferences. What is wrong with using words or "1st of"? —Centrxtalk • 03:52, 1 October 2006 (UTC)
Try setting your preferences to American Dating - the comma is inserted automatically. --Jumbo 04:26, 1 October 2006 (UTC)
The third one seems reasonable. It would then be 1 October – 10 October 2006 or October 1 – October 10, 2006, right? Using "1st of" wouldn't really work because it looks out-of-place in the standard that we've established... The first two wouldn't really work, because of preferences...
Personally, I think it's fine without the comma, but I wonder if you could force a comma by, say, using the & ; notation? Let's see... ,? Nope... I wonder if I can find the number for it... Let's try &#x2C;... →,← yay, it worked! Now let's see if it can bypass the date preferences: →1 October10 October, 2006← yay! How's that for a comma? ;-) Hehe... I still don't think it's necessary but if everyone else thinks it is, it's possible. :-) Neonumbers 12:20, 1 October 2006 (UTC)
To me the 3rd form proposed above looks like "1 October – 2006-10-10". Not acceptable. So I guess the only good way is do away with contractions and write 2006-10-012006-10-10. −Woodstone 12:53, 1 October 2006 (UTC)
What looks reasonable to readers without preferences set? bobblewik 18:48, 1 October 2006 (UTC)
What I mean is for a range in day-month format, it should be "1 October through 10 October, 2006", with the comma. But that the date preferences would not show the comma for day-month format, despite it being appropriate in this case. —Centrxtalk • 20:03, 1 October 2006 (UTC)
For International Dating, a comma is not necessary. In the example that kicked this discussion off, the year did not form part of the date. The use of "through" in this case would also seem to be an Americanism. --Jumbo 20:50, 1 October 2006 (UTC)
I don't know who you are responding to, the comma referred to here has nothing to do with International or American dating, it has to do with offsetting the year after the range. —Centrxtalk • 23:54, 2 October 2006 (UTC)
I agree with Woodstone, the only right way would be to select the choice that won't look wrong to anybody. That would be, October 1, 2006October 10, 2006. -- Renesis (talk) 21:11, 3 October 2006 (UTC)
I think Woodstone's suggestion, "2006-10-012006-10-10", is obviously a clear and unambiguous way to write a date range. I would also accept "2006-10-01 to 2006-10-10". Anything else is unacceptable. (Speaking of which, the date format displayed by ~~~~ is also unacceptable. Wikipedia dates should be uniformly displayed as ISO 8601 dates. The display of standard measures should not be subject to "user preference.") -- -- BBlackmoor (talk) 20:25, 29 October 2006 (UTC)

tractive effort: 'lb' or 'lbf'?

Discussion below copied from Wikipedia talk:WikiProject Trains A user is reverting edits to train articles. Please look at Rebecca's contributions list at least back to 23 September. I believe the original edits improve the articles and the reverts make the articles worse. I do not want to undo the reverts myself but other editors may wish to do so. bobblewik 10:15, 1 October 2006 (UTC)

I've wasted enough of my precious hours on earth reviewing the changes involved to wish, frankly, that both of you would keep your mitts off the railroading articles. But I would have to oppose the way you went through and systematically changed "tractive effort" units from "lb" to "lbf". The correct English units measure is "pounds". Period. I've looked at some of the other changes you've made (and some of the argument about them) and frankly I think Wikipedia would be a better place if you applied yourself to substantive copyediting and writing and eschewed your program of computer-amplified nitpicks. Mangoe 11:29, 1 October 2006 (UTC)
A few of them were on my watchlist and I've taken care of those that I agree with (and added {{TrainsWikiProject}} as appropriate). Some of the changes that were reverted were only whether or not solitary years were linked. Since I have no substantive opinion in that debate, I have left those specific changes alone. It looks to me like Rebecca doesn't like any of your units edits (I see a lot of edits to ship articles, for example), and this dispute is better suited to another location. Slambo (Speak) 12:12, 1 October 2006 (UTC)
Thanks for undoing the reverts. As far as the other comments ('lb' v 'lbf' and formatting 'nitpicks') are concerned, I will copy the comments to wp:mosnum. That is probably the best place. See you there. bobblewik 18:44, 1 October 2006 (UTC)

Discussion above copied from Wikipedia talk:WikiProject Trains

Can people comment on the appropriateness of unit format edits as an editor activity and the correct unit for tractive effort i.e. 'lb' or 'lbf'. bobblewik 18:44, 1 October 2006 (UTC)

Using 'pound' (or for that matter 'kg') as a unit for force is plain wrong. Clearly in some fields, it common practice to use units in this sloppy way, but in a publication for the general public, more precision is definitely an improvement. −Woodstone 20:58, 1 October 2006 (UTC)
The pound can be used either as a unit of mass or a unit of force. According to National Institute of Standards and Technology Special Publication 811 page 59, "lbf" is the correct abbreviation for the pound, when used as a unit of force. Of course, the Manual of Style (dates and numbers) calls for all those units in all those train articles to be accompanied by metric equivalents. My personal opinion is that because the pound can be used both ways, it is a menace to society and should be banished, to be replaced with kilogram or newton as appropriate. --Gerry Ashton 22:08, 1 October 2006 (UTC)

The changes (with respect to units) that bobblewik made to the train articles dealt with measuring tractive effort. The definition of tractive effort tells us that we are measuring a force. Therefore, to change lb to lbf would be correct. I'm sure when 'train enthusiasts' are discussing tractive effort they never say pounds-force. They just say pounds. However, when it is formally written —it should be done correctly. LONG LIVE the POUND! —MJCdetroit 01:46, 2 October 2006 (UTC)

Exactly. They are the units of force; enthusiasts in their own discussions may just say pounds, but even they are probably oblivious to the facts that there are a couple of common units that go by that name, and it is important to maintain the distinction.
It is especially important since most train articles use both "lb" (and "kg" or "t" when these are expressed in metric units), and also "lbf" (and "N" or "kN" when expressed in metric units). Different units—use different symbols to keep them straight.
Some tractive effort articles express it only in newtons (e.g., maximum tractive effort). In English units, of course, these are most often converted to lbf.
Unlike some of the other measurements in other fields, I've never run across any of the "tractive effort" measurements expressed here on Wikipedia in kilograms-force. So that doesn't seem to be a problem; but if they are ever the original measurements, I think they should be kept because of their value in showing the precision of the original measurement, and converted both to newtons and pounds force. Gene Nygaard 02:44, 2 October 2006 (UTC)

Yearless dates

I propose an addition to MOS:DATE#Partial_dates to address the problem of yearless dates. This tends to arise when people write articles on current events. There is an understandable tendancy to refer to just the date and month, with an unspoken implication that the current year is being discussed (repeating "2006" after every date can reduce readability). The problem here is that the article needs to be written in such a way that it is clear which year is being referred to. If this is not done, then confusion will arise in later years. The example that prompted this is mentioned and discussed at Talk:Hurricane_Katrina#Dates_lacking_years. So, does anyone agree that this addition to the guideline is needed, and can anyone think of a good way to word this? Carcharoth 12:27, 2 October 2006 (UTC)

I'd add something to the end of Partial dates to the effect of what you said above:
"Articles addressing recent events tend to omit the year, under the impression that "June 2" clearly refers to the recent past. However as time goes on, the context of timeliness will be reduced; therefore all full dates should include the year. See also Wikipedia:As of and Category:Current events."
-- nae'blis 20:30, 2 October 2006 (UTC)
Thanks! Done. Though I thought this issue important enough to have its own section. Carcharoth 23:44, 2 October 2006 (UTC)

Yearless dates should be used only after the context of the year has been established, which is the same principle as for any yearless date. Any article should start with a date that includes the year, whether it be 1806 or 2006, and then if an editor so chooses, to use yearless dates afterward. This advice should be included in the previous section. —Centrxtalk • 23:51, 2 October 2006 (UTC)

I agree. Though this establishment of year context may need to be done several times in an article. Just once at the beginning may not be enough, particularly with long articles. A matter of editorial judgment. It is the principle of considering such things that I want to see included here, as it is an easy thing to forget. Carcharoth 01:14, 3 October 2006 (UTC)
That's a good point. Maybe some wording along the lines of "Once the year is clearly established, yearless dates can be used judiciously in nearby prose." -- nae'blis 02:19, 3 October 2006 (UTC)
Added. Carcharoth 09:40, 3 October 2006 (UTC)

Non-breaking spaces

Discussion below copied from User talk:Bobblewik I've noticed you changing a lot of units in automobile articles from "XXXhp" to "XXX hp". If you're going to do this, could you follow the WP:Autos conventions and use the non-breaking space (&nbsp;) to prevent automatic line wrapping? This would also apply to non-autombile articles where you're inserting a space between the value and the unit. Thanks. --DeLarge 22:03, 29 September 2006 (UTC)

I like to ensure that the reader sees a space. In the past, I tried to go a step further and add nbsp but I ended up making too many mistakes and it is much more complicated and slow. So now I just concentrate on the main task of correcting the absence of a visible space. If you would like to convert the visible space from one type to another, I would be happy to assist you. I have helped other editors in that. I would also be happy to discuss formats in general in your project page if you want to copy this discussion there. Regards bobblewik 10:20, 30 September 2006 (UTC)
Sorry, what? You'd rather do a half-assed job because it's quicker and easier than doing it properly, but if I want to spend my time trawling around after you tidying up your goofs you'd be happy to assist? How noble of you. Do you realise what a selfish ass you just sounded like? --DeLarge 10:20, 1 October 2006 (UTC)

Discussion above copied from User talk:Bobblewik

I have copied the above comments from my talk page. The issues raised by DeLarge may be of wider interest. I do not want to address the issue of rudeness here, I have already expressed my views on his/her talk page. However, I would be interested in opinions on the substantive points.

As long as a visible space is there, the type of visible space is a very low priority for me. I regard nbsp as just another tool available to me and deploy it on rare occasions (e.g. if a table looks really really odd). I know that some people care a lot about it, just as other people care about horizontal lines a few pixels long (hyphens, dashes). My work does not prevent other editors from changing the type of space, type of line or anything else. Because of previous requests for me to work on adding non-breaking spaces, I went to some effort to create and debug a publically available tool for adding non-breaking spaces but I don't maintain, guarantee or use it myself.

I would be interested in the views of others. bobblewik 19:03, 2 October 2006 (UTC)

(response copied)

How ironic. I considered it rude of you to dismiss a constructive suggestion on the basis that doing things the right way was too difficult and slow for you. Like I said, you'd rather do a half-assed job because it's quicker and easier than doing it properly. In future, expect your edits to be rolled back summarily - your dismissive attitude deserves to be reciprocated. --DeLarge 19:12, 2 October 2006 (UTC)
B has no obligation to enter non-breaking spaces where you want him to. He replied politely to your request and offered to work together, and you responded by calling him an ass, just because he didn't follow your orders to the letter. Shame on you. Michael Z. 2006-10-02 19:57 Z
Insertion of a non-breaking space would be the best way of doing it. Could you rewrite your monobook tool to insert the &nbsp; between the value and the unit symbol? That way you could be fast and mistake free. —MJCdetroit 20:03, 2 October 2006 (UTC)
As I mentioned, I wrote a such a tool (back in June) for anyone to use. See:
User:Bobblewik/monobook.js/units nbsp.js
I know many arguments for it, but I prefer not to use it. bobblewik 20:14, 2 October 2006 (UTC)
In addition, you may wish to ask User:TomTheHand. He has modified my code for non-breaking spaces and produced a version for AWB (I think). bobblewik 20:28, 2 October 2006 (UTC)

ISO 8601 format = Gregorian Calendar

"You can give dates in any appropriate calendar, as long as you also give the date in either the Julian or Gregorian calendar, as described below. For example, an article on the early history of Islam may give dates in both the Islamic calendar and the Julian calendar.
...

ISO 8601 date formats are unambigously defined as being in the Gregorian Calendar (ISO 8601:2000, section 4.3.1), so dates like "1616-04-23 (Old Style)" ([[1616]]-[[04-23]] ([[Old Style and New Style dates|Old Style]])), which use the ISO 8601 format but not the ISO 8601 calendar, are extremly bad style.

Julian dates should not be given in ISO 8601 format (but for example as 23-Apr-1616 ([[23-Apr]]-[[1616]]).

The best idea IMO is to change the Mediawiki software to convert between date formats and calendars. In the meantime, it might be best to provide templates for non-Gregorian dates that do the right thing. -- 3247 10:28, 3 October 2006 (UTC)

If a competent author intends to follow ISO 8601, then the date is in the Gregorian calendar. However, if a reader finds a date in the format YYYY-MM-DD, the reader would be unwise to presume the author was following ISO 8601 when he wrote it. Perhaps the author has never heard of ISO 8601, and was just imitating what he had seen elsewhere. Perhaps the author often sorts dates with a computer, and uses that style because it is easy to sort. Perhaps the first editor of a Wikipedia article understood ISO 8601 but subsequent editors did not. Thus it would be wise for a Wikipedia editor to explicitly mention the calendar under circumstances where it would be logical to use a calendar other than Gregorian, and not presume the reader will know that a date in the YYYY-MM-DD format is Gregorian.
As for automatic calendar conversion by Mediawiki software, deciding that a date in YYYY-MM-DD format is Gregorian is risky, and there is no standard method that a computer could recognise to designate any other calendar, so I don't think that will ever happen. --Gerry Ashton 21:06, 3 October 2006 (UTC)