Wikipedia talk:Manual of Style (dates and numbers)

From Wikipedia, the free encyclopedia

Contents

[edit] Archives

Archive
Archives

See also:

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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"? —Centrx→talk • 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 ,... →,← yay, it worked! Now let's see if it can bypass the date preferences: →1 October – 10 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-01 – 2006-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. —Centrx→talk • 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. —Centrx→talk • 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, 2006 – October 10, 2006. -- Renesis (talk) 21:11, 3 October 2006 (UTC)
I think Woodstone's suggestion, "2006-10-01 – 2006-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)

[edit] 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)

[edit] 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. —Centrx→talk • 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)

[edit] 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 ( ) 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   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)

[edit] 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)

[edit] Abbreviating decades

Is there a guideline on whether it's acceptable to abbreviate decades, and if so, how? I'm thinking of a context in which saying "the 1970s and 1980s" appears slightly stilted, and "the 1970s and '80s" would be more natural; however, I don't see any recognition that it's ever OK to say " '80s", or whether there's a preference about the use of the apostrophe. (" '80s" is abbreviated from "1980s" and so is usually written with the apostrophe, but I think some style guides prefer to avoid the apostrophe altogether. Note that this is different from the incorrect usage "1980's", which is correct only if you're saying "belonging to 1980" or "1980 is".)

Has this been discussed before? (I didn't really want to search through 57 archives.) —Josiah Rowe (talk • contribs) 04:09, 4 October 2006 (UTC)

I believe that the guideline is not to abbreviate decades at all, that is, "the 1970s and 1980s" is correct. Let me double-check that...
The guideline is in the "Incorrect date formats" section. It says that an apostrophe is expected, and it's acceptable (but not advised) when not ambiguous, but I don't really like that... anyway, that's what it says.
Remember that you are writing formally, so what you would say naturally isn't always the same, especially when it comes to dates. My strong advice is to go with 1980s, but if you really want to abbreviate it, then make sure an apostrophe's there. Neonumbers 09:57, 4 October 2006 (UTC)

[edit] %

In keeping with Ref. [6: ISO 31-0], this Guide takes the position that it is acceptable to use the internationally recognized symbol % (percent) for the number 0.01 with the SI and thus to express the values of quantities of dimension one (see Sec. 7.14) with its aid. When it is used, a space is left between the symbol % and the number by which it is multiplied [6: ISO 31-0]. Further, in keeping with Sec. 7.6, the symbol % should be used, not the name "percent." Example: xB = 0.0025 = 0.25 % but not: xB = 0.0025 = .25% or xB = 0.25 percent —The preceding unsigned comment was added by 82.155.158.96 (talk • contribs) 14:35, 8 October 2006 UTC.

This style guide, as well as the Chicago Manual of Style, 14th ed., paragraph 8.18, indicate there is no space between a number and a percent sign. The Institute of Electrical and Electronics Engineers, an organization that has adopted SI and which has published standards on about SI (IEEE/ASTM SI 10-1997) does not place a space between a number and a percent sign in its magazine Spectrum (see, for example, page 51 of the September 2006 issue). Since the ISO has no law-making authority and just creates standards for those who choose to adopt them, I suggest this guide should continue to recommend no space between a number and a percent sign. --Gerry Ashton 19:30, 8 October 2006 (UTC)
What about degree signs? 50 °/50° or 50 °C/50°C — Omegatron 16:55, 19 October 2006 (UTC)
NIST's Guide for the Use of the International System of Units (SI) on page 16 says there is no space before ° when used to mean degree of angle, but there is a space before °C. Also, when an angle is expressed in degrees, minutes, and seconds, there are no spaces at all; the example given is 30°22'8". I looked in the Chicago Manual of Style and didn't find such clear-cut advise. --Gerry Ashton 19:02, 19 October 2006 (UTC)

Let's just relax and use some common sense. Expressions like ten percent and 10% are traditional in English prose and typography, so it is appropriate to use either. SI style like 10 % is used in many scientific publications, so it may be appropriate in such articles (but include a non-breaking space, or these expressions may line-wrap in an ugly, amateurish way). Pretty much the same goes for ten degrees Celsius, 10° C, 10 °C. Remember that it's a style guide, not scripture. —Michael Z. 2006-10-19 17:31 Z

[edit] Firearm Calibres

We've been having a discussion over at Wikipedia:WikiProject Military history regarding the naming conventions for firearm calibres. The general consensus is that the current standard is wrong and needs to be changed to reflect common usage and convention. For example, the article entitled "7.62 x 54 mm R" is at odds with how the calibre is usually written- convention is "7.62x54R", without the spaces or the "mm". The discussion can be found here. We'd appreciate your input. --Commander Zulu 04:51, 19 October 2006 (UTC)

No-one has any thoughts on the subject? --Commander Zulu 08:30, 31 October 2006 (UTC)

Given the lack of objection, I'm going to add something on the article page here shortly to reflect the standard for firearm calibres, unless someone has any major problems. --Commander Zulu 10:07, 7 November 2006 (UTC)

I'd be reluctant for you to include anything on this page. This page will quickly become bloated if every field has its own guidance. It's better if each WikiProject has its own style guide on its own page. Stephen Turner (Talk) 11:01, 7 November 2006 (UTC)
My concern is that this forms an actual manual of style, whereas the WP:Milhist page only covers Military History. Besides, I'd argue that firearm calibres are likely to pop up often enough to make a mention of the preferred style here worthwhile.--Commander Zulu 11:50, 7 November 2006 (UTC)
Well, maybe other people have different views, but I feel it's an extremely specialised topic, and if we included guidance on notating every topic of similar status, the page would soon be twice as long as it currently is. This page should concentrate on dates and numbers that crop up in all subject areas. Stephen Turner (Talk) 12:25, 7 November 2006 (UTC)
Even if those were true names, there are certain things that you may freely alter for typographic reasons, like casing, space or character shape (e.g. ’ instead of ' in O’Connor or, here, × instead of x).
If there is a (preferably international) standard explicitely using any kind of “[0-9]+([.,][0-9]+)? ?(mm)? ?[×x] ?[0-9]+ ?(mm)? ?[A-z]*” (RegEx notation) you should use that, but if all the notations are just customary you should follow the rules of the WP:MoS for units, because then it looks like a designation including units that has no prescribed format. Even if there is a standard or at least a NATO protocol (or whatever they call it) it is probably vague on the issue, because the creators did not care or think about such details and then you should still follow the Manual of Style in effect.
JFTR, WP is not a military history publication but a general purpose encyclopedia. Christoph Päper 16:48, 7 November 2006 (UTC)

[edit] Very large numbers

In the article, we have

Very large numbers may be divided up by commas every three places (e.g.: 2,900,000), starting from the decimal separator in both directions. (This is different from the SI/ISO 31-0 notation style, where punctuation marks are not used, but as an option, a thin space may be inserted every three places.)

Why is it we do not follow the international standard with the spaces? It is universally understood and completely unambiguous. In <math>, thin space is represented as /,. In plain text, I don't know how to represent it - perhaps that answers my question: We don't follow the standard because we can't?--Niels Ø 13:24, 19 October 2006 (UTC)

I would love to see SI units used, and only SI units used (with very few exceptions) and ISO 31 formatting rules followed with respect to those SI units. In my view, it would not be unreasonable to enforce internationally-agreed standards in an international project such as the Wikipedia. I would assume that the reason we use US customary units and US customary formatting in the Wikipedia is that many Wikipedians are from the US, are used to their own way of doing things, and are reluctant to change. Blaise 15:17, 22 October 2006 (UTC)
Either find a way to type the thin space as easily as a comma, or forget it. Any method that requires doubling the amount of typing and remembering obscure codes will never happen. --Gerry Ashton 18:15, 22 October 2006 (UTC)
Some more thoughts on standardising the style and format of Wikipedia articles: I think one might have a decision to recommend one standard format, and yet accept that many editors write articles in other formats, leaving it to nitpickers, bots, and the like, to convert their input to the standard format. This applies to many of the issues discussed here: Spatiation at percent symbols, degree symbols and units; 3-digit grouping; use of BC/BCE and AD/CE; use of SI/customary units; etc. It could even be applied to the issue of British vs US English, but that might be too problematic. No-one should frown at editors adding material to an article in a format inconsistent with the chosen standards or with the rest of the article, but of course it is legitimate (and desirable) to edit such additions for consistency.
One could imagine the toolbar above the edit box extended to include buttons for thin space and non-breakable space.
One could imagine an automated way of making measurements in SI units clickable, linking them to their conversion into customary units.
One could imagine style choises in each article being indicated in a comment at the top of the article, with an indication why (typically: because it was the choice made by the editor creating the article). Presently that could include chosen variant of English, choice between BC/BCE etc, and other choices, but I advocate limiting the number of such choices to be made by the editors to an absolute minimum.--Niels Ø 15:33, 24 October 2006 (UTC)
Much as I dislike American units, there is value in quoting the source unit first, with a conversion to metric afterwards, because conversions are easy to get wrong (over-precision, calculation error etc.). Our section on Units of measurement recognises this. Stephen Turner (Talk) 15:49, 24 October 2006 (UTC)

[edit] Date links

What are my options if I want to make a date as few characters as possible. I guess I would like it to look like 5/13/2002 or if it has to be a dash 5-13-2002. The manual of style has [[1958-02-17]]: 1958-02-17 but this is what I get for 09-30-2004. Thanks - Peregrinefisher 01:20, 27 October 2006 (UTC)

Thanks for asking! Please don't use any of your suggestions, because they don't work for users outside North America — we don't write dates in that order.
If you really need very short dates (e.g., in a thin column in a table), 1958-02-17 (unlinked) is acceptable. But full dates, linked, are preferable where possible: [[February 17]], [[1958]] which will display according to the user's preferred date format if they've set one up.
Stephen Turner (Talk) 09:38, 27 October 2006 (UTC)

[edit] Ordinals?

Should they be spelled out? i.e. second instead of 2nd? --plange 22:43, 28 October 2006 (UTC)

Good question (I'm surprised it's not already covered).
I would follow the same rule as ordinary numbers. So in prose, always (read: normally) spell out first, second, third ... tenth. Ordinals above ten can be spelt out only if it can be done so in one or two words: thirty-second, forty-ninth, two-hundredth. Otherwise, use the number: 249th, not two-hundred-and-forty-ninth. In tables and infoboxes, always (read: normally) use the numeral 1st, 2nd, 3rd, and so on.
Hope that helps. Neonumbers 23:33, 28 October 2006 (UTC)
Sure does, and that makes sense! Thanks! --plange 00:25, 29 October 2006 (UTC)
What about for centuries? My watchlist just registered an editor changing an entire article from "5th Century BC" to "Fifth Century BC"--do others have thoughts about this? I'm certainly more familiar with the former usage, but have never given it much thought. Chick Bowen 04:26, 2 November 2006 (UTC)
That should be uncapitalized: "fifth century BC". —Michael Z. 2006-11-26 18:52 Z
And what should the deal be with superscripting the th's and rd's? Should they be or not? 03:44, 26 November 2006 (UTC) —The preceding unsigned comment was added by 71.102.186.234 (talk • contribs) .
Heavens, no. That example of naïve typographic "sophistication" looks terrible, attracts far too much attention to the ordinal on the page, and makes it look like a superscripted footnote reference. —Michael Z. 2006-11-26 18:50 Z

[edit] Exemptions for airport articles

Some editors are claiming that dates should not be wikified for airline schedule information in airport articles (see, for example, here). Before I pursue this further, I would like to see some other opinions. -- Donald Albury 12:17, 31 October 2006 (UTC)

  • This is certainly wrong. Full dates should always be linked (with very limited technical exceptions). Stephen Turner (Talk) 13:10, 31 October 2006 (UTC)

[edit] recent edit concerning the linking of dates

I strongly disagree with "almost always". I'm so pissed off with the linking thing that I'm now not linking dates, even at the expense of foregoing the auto-formatting.

The problem should be shifted to the techs and above who've made auto-formatting and linking the same process. Bad idea.

I suggest that you soften the "almost always". I'll just refuse to comply if it stays. Tony 13:40, 31 October 2006 (UTC)

Of course the technical decision is wrong: I absolutely agree with that, and I long for the day when we can do away with all those date links. However, that's not the question. The question is, given the current state of the code, should full dates "almost always" be linked, and I think almost everyone is in agreement that they should be. If the misfeature ever gets fixed, I'm sure the style guidance would quickly change, but we're not writing guidance for that hypothetical world. Stephen Turner (Talk) 13:59, 31 October 2006 (UTC)
Is it remotely possible, then, that a push might be mounted to fix it? Tony 14:58, 31 October 2006 (UTC)
I would happily support such a push, but I don't know what an effective procedure would be. Anyone? Stephen Turner (Talk) 15:07, 31 October 2006 (UTC)
Agree with Stephen. FYI, the right place for discussing the feature change, where it in fact already has been "shifted to the techs" would be MediaZilla:4582 I suppose (unless there are still duplicate bug reports floating around). BTW, Steve Bennett's idea ([[19 January]] [[2000]] -> Behaves as current; [[:19 January]] [[:2000]] -> no links shown, only reformatting) is my personal favourite. --Francis Schonken 15:10, 31 October 2006 (UTC)
Nice; I could gather more support; has anyone experience in bringing issues to that forum? I don't. Tony 13:26, 1 November 2006 (UTC)
Would anyone support a proposal for a new linking system in mediawiki (the wikipedia software) for dates, measurements and currency so they are formated automatically according to preferences? --Clawed 04:15, 2 November 2006 (UTC)
I think date preferences are more manageable than currency preferences. In the case of currency, do you propose to convert between the currencies of various countries? Where do you get the conversion factors? Do you present the present day conversion or the conversion as of the date some event in the article occured?
In the case of measurements, are you thinking of converting from metric to American units? The preference can vary according to the subject matter; an American might want to measure distance in miles while driving, but measure the focal length of photographic lenses in millimeters. --Gerry Ashton 04:47, 2 November 2006 (UTC)
Measurements also have the problem of how many significant figures to include, and which is the source unit and which is the converted unit. So I think dates should be tackled first; they are much more likely to reach agreement. If the syntax also allowed future expansion to other areas, that might be an advantage, but only a minor one. Stephen Turner (Talk) 08:19, 2 November 2006 (UTC)

These seem to be good points, and auto-conversions of weights, measures and currencies as an optional preference may be worth looking into. But first, let's lobby to overcome this regrettable technical connection of linking and the auto-formatting for dates. I've looked at the MediaZilla link provided above, and wonder why nothing came of that push earlier this year. Tony 10:08, 2 November 2006 (UTC)

[edit] Making date links be only about cross-referencing

I see three aspects to the question of how to write dates at Wikipedia: personal/national custom, logical writing style (specifically, punctuation), and cross-referencing.

Encoding a date so that it is a link results in three things:

1. The date appears in different ways to different readers; which form of the date appears is the result of user preference (or default).

2. The date is punctuated logically or illogically (and thus, according to my prescriptivism, properly or improperly); this depends on the combination of the original writing and the displayed writing.

3. The date appears in a different color, with underlining, and acts as a cross-reference to another article.

My personal opinion about Point 1 is that user date preferences should be removed from Wikipedia's programming, and that the Manual of Style should require exactly one style for dates that aren't part of direct, verbatim quotations. My personal preference is that that style be "Monday 6 November 2006" (with perfectly acceptable shorter forms being, as the context warrants, "Monday", "Monday 6", "Monday 6 November", "6 November 2006", "6 November", and "November 2006"). I have little sympathy for the reader or editor who likes to pretend that "6 November" is clear while "November 6" is incomprehensible gibberish (or vice versa) or likes to get angry about which form is in front of him. (My reason for advocating the date–month–year sequence is that it shrinks the matter of commas.) Wikipedia has other style standards that contradict one personal/national custom or another: an example is which punctuation to place inside and outside quotation marks—and Wikipedia has a single policy (not a double one for, say, Britons and Americans), and a single way of displaying the punctuation (no stuff about encoding the punctuation as a link so that it appears differently for different readers). I also think that, when a date is encoded, it should have to be written in the same way as a non-encoded date (except, of course, the insertion of the double square brackets), and it should have to be displayed in exactly the same way as a non-encoded date (except, of course, the color and underlining).

If Wikipedia were to become as I recommend in my discussion of Point 1, then Points 2 and 3 would be simplified drastically.

Point 2 would become a matter of simply an improperly written date, which could be corrected easily. There would be no matter of a properly written date having its displayed punctuation imperfected by an inadequately written program that changes the date's display form. The present program illogicalizes the punctuation for a good many dates at Wikipedia:

On [[22 August]] [[2006]], Sam wrote to Alex. [Properly punctuated and encoded.]
and
On [[August 22]], [[2006]], Sam wrote to Alex. [Properly punctuated and encoded.]
both result in
On August 22, 2006, Sam wrote to Alex. [Properly punctuated display.]
or
On 22 August 2006, Sam Wrote to Alex. [Properly punctuated display.]
depending on viewer preference.
And that's fine. BUT
Sam's [[22 August]] [[2006]] email to Alex is long. [Properly punctuated and encoded.]
and
Sam's [[August 22]], [[2006]], email to Alex is long. [Properly punctuated and encoded.]
result in four different things, depending on viewer preference, which are
Sam's 22 August 2006 email to Alex is long. [Properly punctuated display.]
Sam's August 22, 2006 email to Alex is long. [Improperly punctuated display.]
Sam's 22 August 2006, email to Alex is long. [Improperly punctuated display.]
Sam's August 22, 2006, email to Alex is long. [Properly punctuated display.]
There, the first and fourth results have proper punctuation, but the second and third have faulty punctuation (a missing closing parenthetic comma in the second, and an extraneous comma in the third).

If there were only one way of writing a proper date link, and only one way of displaying a date link, this problem would be gone.

Point 3 would become only a matter of relevant cross-referencing, instead of also a matter of (im)proper punctuation and personal/national custom, if my suggestion were implemented.

My personal preference about when a date should act as a cross-reference (which I see as the worthy point of encoding a date as a link (I think this matter of personal/national custom is unworthy)) is that, if a date appears on the screen, I be able to click on that date to see what else happened on that date in history. The flow of my reading is not significantly distracted by the different appearance (color, underlining) that cross-references have. If the same date appears five times in a window without any scrolling, not all five occurrences should be cross-references. Also, any cross-reference that seems to lead to an article about a year or date in general (rather than, say, an article about pop music in that year) better lead to what it seems to lead to.

I understand that people will still argue about how relevant a cross-reference is in a certain spot. But the argument about links should be only about cross-referencing—not about this waste of time, effort, emotion, and computer resources, not to mention this imperfector of punctuation, that is the present way of encoding and displaying dates for personal/national preference. My main concern is the combination of (1) not having an imperfect date-rendering program botch the punctuation, (2) not having people fight over personal/national style when all we have to do is say "There is only one preferred style (in terms of punctuation and ordering) of writing dates at Wikipedia (except in verbatim quotes from other sources), and all editors have the right to make dates conform to that style, and no editor should cause a date to stop conforming to that style", and (3) having the link-encoding argument be reduced to the sole question of cross-referencing.

In no other aspect of Wikipedia (at least to my knowledge) do we use linking for anything other than making a cross-reference—something that allows the reader to jump easily to another article to read more about that topic. The distinction between "November 6" and "6 November" isn't so important that it deserves a special bit of programming (and one that works imperfectly at that) and editors wasting their time on which form is appropriate for one article or another.

President Lethe 15:58, 7 November 2006 (UTC)

I don't think you'll find many people who agree with you on #1. Even if there were such a rule, it would be impossible to get editors to obey it, so it's better to have a means of switching between the different formats.
#2 has been noted before, but the benefits of #1 seem to outweigh the disadvantages of #2.
As for #3 ... well, as we've been discussing in the previous section, the problem is that one syntax does both #1 and #3, rather than there being a separate syntax for the two things. But we can't seem to persuade the developers that this is a problem.
Stephen Turner (Talk) 17:12, 7 November 2006 (UTC)
Thanks for your response, Stephen Turner. I'm on a long break from Wikipedia these days, so won't be getting into much of an involved discussion on the topic right now; it's just that a friend recently asked me about something related, and I thought I may as well voice get around to voicing an opinion I've had for months.
But I will say something more about Point 1. First of all, I don't grasp why some readers may have, or claim to have, a harder time adjusting their brains to one date format or another than they have with colour/color, organize/organise, &c. Also, it seems that Wikipedia's single standard about punctuation with quotation marks is a good comparison for how this date matter could develop. True, we have some contributors who are unaware of, or choose to disregard, Wikipedia's single rule about whether to put within quotation marks a piece of punctuation that wasn't part of the original quotation; but, because we have a single, logical rule, any editor can go changing any text that deviates from the rule, and any editor can then point any dissenters to the Manual of Style, where the matter is settled. The good thing about making rules is that even the grumblers soon start obeying the rules—and then most persons, even the former grumblers, start seeing the benefits of the rules—and then people are like "This rule makes so much sense. How/why did we ever spend so much time doing things in those silly, other ways?" (I do understand that this can go the other way, in a closed, oppressed society, where few persons ever think to stop obeying an unjust or illogical rule.)
I'm pleased, by the way, to hear that Point 2 has been noted before; I didn't know anyone else had ever pointed it out. It may seem a small/non issue to many, but I find it important. ... Actually, I have one more thing to say about Point 2 and weighing advantages and disadvantages. If we restrict ourselves to reputable reference works on modern English punctuation, we find that—although such sources do mention both forms ("7 November 2006" and "November 7, 2006") as acceptable, depending on context—they don't say it's acceptable to go injecting extraneous commas ("Alex's 7 November 2006, email") or omitting half a mark of parenthesis ("Alex's November 7, 2006__email").
Anyway, that's all, at least for the moment.
President Lethe 19:08, 7 November 2006 (UTC)

[edit] Preferred linked format?

When I first read a help page on wikitext, [[1958-02-17]] was the only format mentioned. Now it says a) several others work and b) that this one is not preferred anymore. So what linked format is preferred? Shinobu 15:11, 19 November 2006 (UTC)

It is preferable to use either [[February 17]], [[1958]] or [[17 February]] [[1958]] depending whether American English or Commonwealth English makes more sense for that particular article. The reason is that whichever format you type is what non-signed-in readers, or those who haven't set up their date preferences, will see. Stephen Turner (Talk) 15:17, 19 November 2006 (UTC)

[edit] Direct quotations

Added a clarification to Direct quotations Section. Text as follows:

"If the quote includes an obscure use of units (e.g., five million board feet of lumber) annotate it with a footnote which provides metric units rather than revising the actual quote; see the guidelines of Wikipedia:Footnotes for an explanation of footnote generation using the <references/> tags or other accepted Wikipedia footnote methods."

Think it should be noncontroversial, but if it is too brave, let's discuss. Williamborg (Bill) 15:39, 19 November 2006 (UTC)

I don't think it's controversial, but it's in the wrong place. It was in the section about dates, so I moved it. Stephen Turner (Talk) 19:48, 19 November 2006 (UTC)

Excellent call. Thanks - Williamborg (Bill) 00:19, 20 November 2006 (UTC)

[edit] Recurring decimals

Is there a recommended style for recurring decimals?

  • 2.702
  • 2.7027
  • 2.7027027...

The overline is shown with CSS, which is suboptimal on old browsers, but better for displaying nicely. MathML would be the best solution, but hasnt been implemented yet. — Omegatron 21:42, 19 November 2006 (UTC)

I strongly prefer the first. You could also try using a Tex formula. When MathML will be implemented, Tex formulae should be rendered using MathML anyway. Shinobu 08:15, 20 November 2006 (UTC)
The second one does not make any sense and the third is ambiguous. I have seen:
  • 2.(702)
  • 2.¯702
  • 2.7̄0̄2̄
  • 2.7̅0̅2̅
Although i prefer the last one for semantic Reasons, i understand that it does not look good in most Browsers, or at least worse than the text-decoration one. Therefore the CSS-Solution might be the best in Practice, but i would like to suggest to use u instead of span:
  • 2.702
This Way even Users of Browsers without CSS-Support see the Periodicity indicated (underline and overline are mutually exclusive in CSS2). An Alternative is using Fractions, e.g. using Template:Frac:
  • 2+78⁄111
— Christoph Päper 15:10, 20 November 2006 (UTC)
Or, better yet, 226⁄37. Haven't you learned to add up the digits to see if the total is divisible by three? Pretty easy to see that 1+1+1 is divisible by 3, and not much harder to figure out that 7 + 8 = 15 is divisible by 3. Gene Nygaard 04:11, 21 November 2006 (UTC)
Somehow i did not do that final Step, i have no Idea why. Christoph Päper 17:34, 21 November 2006 (UTC)

[edit] I get a stray comma after dates

I get a leftover comma when my preferences transform the comma'd style to the non comma'd. I'm referring to the following advice:


If a date includes both a month and a day, then the date should almost always be linked to allow readers’ date preferences to work, displaying the reader’s chosen format. The day and the month should be linked together, and the year should be linked separately if present. For example:


This is all very well, but in practice you often have a necessary comma after the year, which produces things like: The party on 17 February 1958, was memorable. So it appears faultily punctuated.

It doesn't bother me much when I'm reading articles, but it does when I'm editing them. I would use the uncomma'd method myself (because I find it less fussy), but sometimes it's necessary to conform to the style already in the article. Am I doing something wrong, or is this problem unavoidable?

qp10qp 03:35, 30 November 2006 (UTC)

You're right, it's unavoidable. It's been mentioned on this page a few times, but there doesn't seem to be a solution given the current software. Stephen Turner (Talk) 12:07, 30 November 2006 (UTC)
Well, one non-technical solution, then, might be for the manual of style to recommend the form: 7 February 1958. (Forgive me if this has been done to death already.) qp10qp 15:59, 30 November 2006 (UTC)
It has. Sorry! See #Making date links be only about cross-referencing four sections up this page for one. Stephen Turner (Talk) 17:19, 30 November 2006 (UTC)
Aha. Cheers. Well, at least I was briefer. qp10qp 23:41, 30 November 2006 (UTC)

[edit] [[August 13, 2004]]

I see there are now articles for many specific dates such as August 13, 2004. I ran across such a link in an article. I'm thinking that linking to the full date is generally discouraged but cannot find this specifically addressed in the current guidelines or recent talk archives. Should I change such links to the standard linking format? --GregU 08:41, 5 December 2006 (UTC)

Definitely change them, because they don't respond to users' date preferences.
The guidance on the page says "The day and the month should be linked together, and the year should be linked separately if present". Does it need to be any more explicit than that?
Stephen Turner (Talk) 09:41, 5 December 2006 (UTC)
Perhaps not, but I had my doubts thinking general guidelines are to link to the more specific topic (eg, Convair 580 vs needing to mention it is an airplane), and why do they have such articles if you never link to them, and maybe guidelines hadn't caught up to new developments. I will fix the link I found. --GregU 10:14, 5 December 2006 (UTC)
I'm afraid that I now encourage people to disobey the MoS on the matter of linking any dates, given the shambolic state of this function on WP. IMV, better to sacrifice the auto-formatting function while it's still displayed as a link. Simple as that. Tony 13:16, 5 December 2006 (UTC)
Encouraging people to disobey the MoS is just wrong. Either try to get the MoS changed, or do what the MoS says (or bug the programmers of MediaWiki to add an unlinked date format thingy). Shinobu 04:58, 7 December 2006 (UTC)
It's a form of protest. Do something about it, like supporting a push to have the techs disentangle the autoformatting and linking processes. This was attempted earlier in the year, but fizzled out for want of energy. Meanwhile, I'm not putting up with a seriously unsatisfactory system. Tony 06:50, 7 December 2006 (UTC)
The more I think about it, it does seem like in this case, the current rule is putting form ahead of function, which is not a good thing. Again I'm not sure if specific date pages like August 13, 2004 are frowned upon or not; I could find no discussion of them. But if they are accepted, the most logical thing to do functionally is to link to that specific date. The date page should then link to the more general August 13 and 2004 pages. Until the larger issue of separating formatting from linking is tackled, maybe it would be wise to make a simpler code change and also autoformat dates like this. --GregU 10:29, 7 December 2006 (UTC)
We don't have the ability here to make code changes, only to agree style guidelines based on the existing code. Stephen Turner (Talk) 10:32, 7 December 2006 (UTC)
Which is why, IMV, the MoS should not insist on the use of blued-out dates. Why support (no, make obligatory) a bad technical feature? I'm not budging until autoformatting is rendered BLACK, just like the rest of the text. If you take a look at the last attempt to have the techs change this ridiculous system, I think one of them said something to the effect of "oh, we did it that way because people want to link to date pages". Hello? Tony 11:23, 7 December 2006 (UTC)
(de-indent) - so start/reactivate a proposal to change the system. If the developers believe there's consensus for the current way of doing things, you can try to show that consensus exists that it should be changed. I assume you're referring to Wikipedia:Date debate as the discussion earlier this year? -- nae'blis 22:17, 7 December 2006 (UTC)
This is one thing I'll never understand. I'd have sworn that no developer on this earth would claim that linking and formatting have anything to do each other, yet last time we brought the issue up everything degraded into a bicycle-shed discussion. I also proposed a suitable new syntax on bugzilla, where there seemed to be some consensus and lot of noise. I then stopped participating as after posting there my spam amount increased by at least a factor of eight (no mail address obfuscation). Apparently nothing came really out of it anyway. —Gennaro Prota•Talk 22:45, 7 December 2006 (UTC)
Any support for reaching consensus on a single date format (outside of exact quotes). Since Wikipedia is a single body of work, it would be nice if there was consistency across it. Good arguments have been made for 7 December 2006 as a format, as it requires no additional commas. That looks weird to my U.S. eyes, but I would tolerate it for consistency purposes. Even if preferences are ultimately kept, I think a single date format should be chosen as the preferred entry method, as it will provide users who are not logged in a consistent experience. I definitely think linking should not be the method in which dates are formatted for user preferences. --MattWright (talk) 22:56, 7 December 2006 (UTC)

There's been something to get date prefs without linking? Hmm... I missed that. Would anyone mind doing me a favour and leave a note on my talk page next time it comes up? Doesn't matter who, but especially if I'm inactive (which is most of the time), I'd like to know. If a discussion's active now, point me to it. Thanks.  :-) Neonumbers 00:36, 8 December 2006 (UTC)

Are there people who defend the existing syntax and believe that all dates should be linked, and linked only to [[Month Day]], [[Year]]? Or is it common ground that people think linking and preferences should be separated? Is linking only being supported because it is the only way to display preferences in dates? --MattWright (talk) 02:32, 8 December 2006 (UTC)
See my post above… I don't know what the consensus might be *now*, but last time the issue was raised (and I was there) not everyone was agreeing about the separation. I can't recall exactly why… And, yes, AFAIK linking is only supported because it is the only way to apply the preferences. :-( —Gennaro Prota•Talk 05:17, 8 December 2006 (UTC)
I suspect that Gennaro is correct: separate the functions, and the untidy peppering of blue that we must put up with to autoformat will go away; as well, the tension and nastiness that goes on between the faction that wants to blue every chronological item (including "20th century", 1890s and 2005, where autoformatting is irrelevant), and those who don't, will probably dissolve. It's clear to me that linking trivial chronological items is based on confusion of the autoformatting and linking functions. Both of these outcomes would be good for the project. Tony 10:27, 8 December 2006 (UTC)

I don't think many people defend the current situation, but I get the impression that the developers don't consider it a priority. Also the bugzilla discussion didn't really reach a consensus about what the correct format for date preferences without linking should be. Stephen Turner (Talk) 11:49, 8 December 2006 (UTC)

Thanks for the link to the bugzilla discussion. I searched it myself yesterday but I couldn't find it at first and, being a little late in the night, I gave up. I might well be misled by a few bad examples, but my experience with the MediaWiki guys and their responsiveness is quite far from encouraging. —Gennaro Prota•Talk 13:24, 8 December 2006 (UTC)


Reading through both Wikipedia_talk:Date_debate and the previous bugzilla push, it seems to me that a new push will have more chance of succeeding if:

(1) it comes from as many people as possible, all at once, as though a petition; and

(2) keeps the matter as simple as possible.

I suggest that we ask that:

  • the current date-linking syntax be retained (so there are no complaints from pro-linkers)
  • a new syntax be created in exact parallel to the linking syntax, simply by substituting <<date>> for [[date]], rendering the date autoformatted but not linked, and thus coloured black.

The initial comment, then, would list people who sign up here, ask for the new parallel syntax to be created, and set out the arguments for it as briefly as possible.

Does that sound like a good strategy? Tony 14:39, 8 December 2006 (UTC)

That doesn't sound bad; another option that we used the other night in a RL consensus meeting was to agree in principle that we wanted to do the thing, then try to decide what the mechanism would be. That may be impossible to sort out on Wikipedia, but I think if we archive Wikipedia_talk:Date_debate and refactor the main page, and try to get things started again as mentioned above, we could get somewhere. I can help. -- nae'blis 15:31, 8 December 2006 (UTC)
I would certainly support such a push, but I think I'm less optimistic than you about the chances of success. Stephen Turner (Talk) 15:47, 8 December 2006 (UTC)
Ditto. See for instance my comment #25 in the bugzilla discussion. Why there tends to be such detrimental nitpicking is really beyond me. —Gennaro Prota•Talk 16:08, 8 December 2006 (UTC)
I think if we come up with a proposal to vote on this time, we should make no mention of the actual format we want the developers to use. Some people were arguing for or against specific formats, such as <<date>>. I think our concern is not what the format is (we can leave that to the developers to best decide), but that there exists a format we can use to enact preferences and avoid linking. --MattWright (talk) 18:20, 8 December 2006 (UTC)
I don't mind that strategy, but I'd like to specify that the format be "chosen by developers, preferably as simple and short as possible, such as <<date>>". Is that a good idea? Tony 04:40, 9 December 2006 (UTC)
Why specify that? I think the bug report lists other great ideas, like {{date|}}, which could be a wrapper to <date></date>, etc. which may have advantages. I just think that we want this changed so that linking and date prefs aren't using the same syntax and that anything you add to that request is just more stuff that can be debated and used against the idea of separation of these two functions. The simpler you keep it, it seems the less likely to raise objections. Make it a clear win that people want linking and preferences untangled, and *then* the actual syntax can be argued over. That's my opinion anyway. --MattWright (talk) 05:36, 9 December 2006 (UTC)
Can we hash out the request here or on a sub-page somewhere before it is submitted to polish it and agree on something? I was going to write something up and start a list like this as well, but didn't get the time yet. --MattWright (talk) 05:36, 9 December 2006 (UTC)
I agree with Matt. Let's see what we're signing up to first. Stephen Turner (Talk) 08:07, 9 December 2006 (UTC)
Seems pretty clear. I for one am agreeing "in principle" that wiki needs functionality that allows date formatting preferences to work without turning every mention of a date into a pointless link. –Outriggr § 08:58, 9 December 2006 (UTC)
I agree with Outriggr. Worst case scenario we could apply some HTML formatting to override the link's default color -- for example, "click here". Maybe we can rig up a template to do just that? --Stratadrake 01:46, 10 December 2006 (UTC)
Thank you all for your support. May I repeat MattWright's suggestion above that we keep our request as simple as possible (single-issue, let the developers decide on the details, I guess). Previous attempts appear to have come unstuck through continued debate over details. Tony 07:12, 10 December 2006 (UTC)
I'm with Outriggr and Tony1. I agree in principle that auto-formatted non-linking dates is a Very Good Idea, and that the worst thing we can do in support of that idea is to over-specify it. The first sentence of the request should be the entire request, with the remainder justifying it. RossPatterson 19:04, 10 December 2006 (UTC)
Strong support, this has been previously discussed at Wikipedia:Date debate. —Quarl (talk) 2006-12-10 08:38Z
  • Comment my opinion about all this issue is: we already have a mechanism (preferences) which allows the user to choose a preferred date format or to specify that he/she has no preference at all. That should already mean that —regardless of any linking or whatsoever— a logged in user should either see all dates as they are written (no preferences) or as he/she prefers. Currently it is not so, and this is the first problem, or at least an oddity. Secondly, date formatting is just one aspect of localization. Why Mediawiki offers an option to format dates but not to choose, for instance, the decimal separator is beyond me. Finally, I believe that *auto*formatting (when the user is logged in) should be the default, in absence of any syntax. What we need is a syntax to *inhibit* localization, which would be used, for instance, in quotations and the like. Do we agree on this? —Gennaro Prota•Talk 13:40, 10 December 2006 (UTC)
    • No, I don't think I agree. I think that your suggestion would put more burden on the Wikipedia servers, because it would have to scan all text, not just marked-up text. I'd also be worried about false matches. And for other localization: I agree with you in principle, but I really recommend keeping that out of the discussion, because the discussion has stalled in the past when those issues are raised. Stephen Turner (Talk) 14:16, 10 December 2006 (UTC)
Like Stephen, I agree in principle; but it's just too radical in the current context. Getting the developers to act will require simplicity and unanimity. Any complications and they're likey to take the easy way out and just say "nah". Tony 14:24, 10 December 2006 (UTC)
  • (moved by Tony to keep debate and list separate). I continue to prefer that the MoS recommend exactly one format for dates (just as there's exactly one set of rules for how to place other punctuation around quotation marks, and one set of rules about capitalizing article and section titles). But, if this new syntax will allow all dates to have exactly the right commas (as discussed in the section to which I link earlier in this paragraph), and if it will do away with some of the fighting over when a date should be cross-referenced (for the sake of referencing, not formatting), then I support it. Even if those two criteria were met, supporting this proposal would still not be my first choice. My first choice, as I've said multiple times, is to have only one order in which to write the parts of dates (preferably "Sunday 10 December 2006", with punctuation as required only by its placement in the rest of the sentence, and with "A.D." (before the year) or "B.C."/"B.C.E."/"C.E." (after the year) added as required) and for encoding to do nothing but turn the date into a cross-reference. As may be obvious, my first concern is doing away with syntax that results in faulty punctuation, and the two concerns that share second place for me are making the current style of encoding be only about cross-referencing (thus reducing some battles over that) and standardizing the order in which we write the components of dates (so that editors stop warring over "December 10" vs. "10 December").
Personally, I would prefer this as well, but I think it may be much more controversial than just eliminating the links, which seems to be something almost everyone agrees on. Theoretically, if a new syntax is designed, it should take into effect these other concerns. I don't know that "input conformity" is necessary (requiring editors to input in a certain order), but certainly I would like to see "output conformity", where a date either displays under a user's preferences or displays in a single style throughout Wikipedia for anonymous users, regardless of input method. I would expect if the entire date was wrapped in a single syntax, comma concerns could be worked out automatically. --MattWright (talk) 22:21, 10 December 2006 (UTC)


[edit] A new parallel syntax for autoformatting dates

[edit] Text of initial request

Please create an additional syntax for autoformatting dates that does not make hyperlinks to date pages. The current syntax conflates the two independent functions of autoformatting and linking. The current syntax is simple; it would be an advantage if the additional syntax were also simple.
The new syntax is conceived not as a replacement but as an alternative, retaining (1) the option to link to a chronological article where useful, and (2) the validity of the huge number of date-links already marked up in the project.
There are significant advantages to allowing autoformatted dates to be black rather than blue, where there is consensus to do so in an article. Specifically, reducing the density of blued-out links will:
(1) improve the readability of the text;
(2) improve the aesthetic appearance of the text;
(3) remove low-value chronological links that may lead readers to pages that are irrelevant to an article;
(4) increase the prominence of high-value links;
(5) reduce the spill-over effect, in which editors feel they should link centuries, decades, and bare years, months and days of the week; and
(6) reduce conflict.
This request is signed by 70 Wikipedians. Some supporters have suggested specific mark-ups, such as <<date>>, but on balance it is considered best that the developers use their expertise to choose the most appropriate mark-up.

Tony 10:25, 13 December 2006 (UTC)

[edit] List of supporters

Please add your name here if you agree in principle for your name to be listed in the initial request. The more names the better. At any stage before the request, you can of course remove your name. --Tony 05:06, 9 December 2006 (UTC)

  1. Tony 05:06, 9 December 2006 (UTC)
  2. Outriggr § 05:27, 9 December 2006 (UTC)
  3. MattWright (talk) 05:36, 9 December 2006 (UTC)
  4. Pinkville 14:22, 9 December 2006 (UTC)
  5. Rich Farmbrough, 14:53 9 December 2006 (GMT).
  6. CRGreathouse (t | c) 16:02, 9 December 2006 (UTC)
  7. Joe Kress 16:07, 9 December 2006 (UTC)
  8. EdJohnston 16:29, 9 December 2006 (UTC)
  9. Stephen Turner (Talk) 16:58, 9 December 2006 (UTC)
  10. Kaldari 17:06, 9 December 2006 (UTC)
  11. Doom 20:57, 9 December 2006 (UTC) -- strongly agree: links should be human generated
  12. Pia 23:54, 9 December 2006 (UTC) -- as per Doom
  13. per Outriggr -- Agathoclea 01:03, 10 December 2006 (UTC)
  14. Dhaluza 01:47, 10 December 2006 (UTC) -- Have had to clean up useless date links from several articles.
  15. Most of the time date links are irrelevant and distracting. Graham87 02:03, 10 December 2006 (UTC)
  16. Punctured Bicycle 02:25, 10 December 2006 (UTC)
  17. Daniel Quinlan 02:37, 10 December 2006 (UTC)
  18. Joy [shallot] 02:41, 10 December 2006 (UTC)
  19. Mad Max 03:02, 10 December 2006 (UTC)
  20. Gzkn 04:28, 10 December 2006 (UTC)
  21. Vsmith 04:40, 10 December 2006 (UTC)
  22. clear and should be helpful. Hmains 05:21, 10 December 2006 (UTC)
  23. image:VirtualSteve.pngVirtualSteve 05:28, 10 December 2006 (UTC) I support (indeed like others in this list - I have always supported this view and versions that have worked towards a similar end) - and now I await the same-same naysayer brigade...
  24. I'm all for reducing the number of irrelevant blue links. Just cleaned up some an hour back [1]. I support the move with the possibility that we can also have the a new functionality for the time too. =Nichalp «Talk»= 06:28, 10 December 2006 (UTC)
  25. Agreed on general principle. This would help a lot with the less useful links. Tuf-Kat 06:32, 10 December 2006 (UTC)
  26. Warmly agreed in principle. (But couldn't the request be phrased in a way that's less pompous but just as clear? Or perhaps all such requests hereabouts are phrased in this style; I really don't know.) -- Hoary 08:07, 10 December 2006 (UTC) .... PS in response to Tony's invitation on my talk page, I hurriedly revised this request there. I find President Lethe's proposal below (and as elaborated here) very persuasive. -- Hoary 22:12, 10 December 2006 (UTC) ... PPS struck though obsolete material 00:51, 12 December 2006 (UTC)
  27. Support the idea. --Guinnog 08:28, 10 December 2006 (UTC)
  28. Strong support, I previously campaigned for this; hopefully we'll get someone to implement it in MediaWiki this time. —Quarl (talk) 2006-12-10 08:39Z
  29. Cuñado - Talk 10:08, 10 December 2006 (UTC)
  30. Kusma (討論) 10:28, 10 December 2006 (UTC)
  31. Wackymacs 11:57, 10 December 2006 (UTC)
  32. —Josiah Rowe (talk • contribs) 12:01, 10 December 2006 (UTC)
  33. Ground Zero | t 12:47, 10 December 2006 (UTC)
  34. Donald Albury 13:53, 10 December 2006 (UTC) Keep the request simple/single issue.
  35. Fritz Saalfeld (Talk) 15:32, 10 December 2006 (UTC)
  36. --Paul 15:35, 10 December 2006 (UTC) I support this request. The current method in addition to the faults mentioned above is non-intuitive and consufing.
  37. I strongly support this proposal. Links should support and advance the primary focus of the article. Michael David 15:47, 10 December 2006 (UTC)
  38. Wetman 15:49, 10 December 2006 (UTC) As Michael said, Links should support and advance the primary focus of the article.
  39. — Deckiller 15:58, 10 December 2006 (UTC)
  40. Zundark 16:11, 10 December 2006 (UTC)
  41. Yes, and I tried to lead the charge on this the last time, too. --Cyde Weys 16:37, 10 December 2006 (UTC)
  42. Good idea, full support in principle, presuming some appropriate syntax can be found. — Matt Crypto 16:51, 10 December 2006 (UTC)
  43. President Lethe 17:33, 10 December 2006 (UTC) — I support this with reservations and/or extra requirements. See my comments here and immediately above this section [moved there by Tony].
  44. Kirill Lokshin 17:49, 10 December 2006 (UTC)
  45. KP Botany 18:03, 10 December 2006 (UTC) Oh, absolutely support this, as simply cannot understand why the date I accessed a web reference should be blue linked. Check out the Afghanistan article, and related, some time to see the absurdity of links that ruins articles on Wikipedia.
  46. I like the wording and context. Kudos to getting this restarted. -- nae'blis 18:20, 10 December 2006 (UTC)
  47. I support the idea, specifically the request as expressed in the proposal. I reserve my opinion about other issues and suggestions raised in the comments to the proposal. RossPatterson 19:04, 10 December 2006 (UTC) As I noted in reply to the initial proposal:

    I'm with Outriggr and Tony1. I agree in principle that auto-formatted non-linking dates is a Very Good Idea, and that the worst thing we can do in support of that idea is to over-specify it. The first sentence of the request should be the entire request, with the remainder justifying it. RossPatterson 19:04, 10 December 2006 (UTC)

  48. Support. The fact that dates must be linked in order to autoformat is terrible. Dates should be linked only when it is useful to link them, i.e. when the date's article is likely to be of interest to the reader. Dates should never be linked under other circumstances, and the software should provide a way to implement this without losing the autoformat capability.--Srleffler 20:00, 10 December 2006 (UTC)
  49. Long overdue. Something like ||February 10|| would be ideal. --RobthTalk 21:43, 10 December 2006 (UTC)
    • ||February 10|| would clash with table syntax. (This is why I think we should let the developers decide on the syntax: they're in the best position to think about these things). Stephen Turner (Talk) 10:29, 11 December 2006 (UTC)
  50. Stratadrake 00:25, 11 December 2006 (UTC)
  51. Date linking and format preferences have different purposes. Don't overload them; it devalues highly relevant date links and overvalues totally irrelevant date links (e.g. 2006), and has collateral effects. —Centrx→talk • 01:27, 11 December 2006 (UTC)
  52. Neier 02:22, 11 December 2006 (UTC)
  53. Hesperian 06:27, 11 December 2006 (UTC)
  54. It'd be a huge improvement. —Moondyne 08:10, 11 December 2006 (UTC)
  55. Agree, black should be the default with linked dates available for useful context. .. dave souza, talk 09:14, 11 December 2006 (UTC)
  56. Oh, yes, I'm a supporter. This might reduce mindless rollbacks as well. Thincat 10:18, 11 December 2006 (UTC)
  57. EJ 13:34, 11 December 2006 (UTC)
  58. Curtis Clark 17:26, 11 December 2006 (UTC) Support in principle.
  59. Hemmingsen 20:05, 11 December 2006 (UTC)
  60. Support as per user Centrx, date linking and format preferences have different purposes Golden Wattle talk 20:15, 11 December 2006 (UTC)
  61. Quiddity 21:46, 11 December 2006 (UTC)
  62. ArmadilloFromHell Oh, I can only hope, the current proliferation of year links makes them all but useless ArmadilloFromHellGateBridge 21:53, 11 December 2006 (UTC)
  63. Seems to be a good idea. Jkelly 22:04, 11 December 2006 (UTC)
  64. Sounds like a good idea ··gracefool |☺ 03:52, 12 December 2006 (UTC)
  65. --Duk 04:43, 12 December 2006 (UTC)
  66. Like the idea a lot. Sandy (Talk) 21:10, 12 December 2006 (UTC)
  67. AnonEMouse (squeak) 21:45, 12 December 2006 (UTC)
  68. Brilliant idea. Singkong2005 · talk 06:58, 13 December 2006 (UTC)
  69. Neonumbers 08:03, 13 December 2006 (UTC) Fully agree in principle.
  70. I hope this goes through! — Reinyday, 18:14, 14 December 2006 (UTC)

[edit] Amendments

Please debate the autoformatting/linking issue here, and keep the text and list of supporters relatively simple and neat. Please note that this is framed as a "minimalist" request, under the assumption that that is most likely to succeed. Tony 07:22, 11 December 2006 (UTC)

I have one: Let the developers expand colon-prefixed wikilinking (e.g., [[:2006]]) to distinguish whether or not to wikilink (or blue-link) an auto-formatted date. Since we already use the colon syntax to produce text wikilinks to categories and images, expanding it to dates would be simple and easy for everyone to learn.

  • Method 1: [[December 10]] produces a non-linked (or black-linked) date, while [[:December 10]] produces a blue-linked date. I believe this is the more intuitive option, but it is not necessarily backwards compatible.
  • Method 2 - Vice versa: [[December 10]] produces a blue-linked date, while [[:December 10]] produces a non-linked (or black-linked) date. This is backwards compatible, only low-importance links need to be changed. But it is arguably less intuitive to adjust to.

If added into the proposal text, then this would let the developers know that we have specific ideas on exactly how to address the issue (rather than merely saying what the issue is and leaving all the rest to the developers), however no solution is perfect, and not everyone may agree on exactly what the solution should be. --00:48, 11 December 2006 (UTC)

Still retains problem of how would you perform a link to a full date article (some of which exist, such as August 13, 2004) *and* keep user preferences working. If they come up with a new syntax, hopefully it can handle flexible, optional linking. --MattWright (talk) 00:34, 11 December 2006 (UTC)
I don't know for certain, but I suspect that user date preferences should apply only to the text of a wikilinked date (same effect as a piped link) and not the actual target article. --Stratadrake 00:48, 11 December 2006 (UTC)
Alternately, I suppose triple-brackets is another option, e.g., [[[December 10]]] versus [[December 10]], where both are auto-formatted, one is linked but the other is not. And the target article for a given date probably already has redirects set up to accommodate different user preferences. (Which is probably a good idea to implement anyway....)) --Stratadrake 00:50, 11 December 2006 (UTC)
Upon further retrospect (and review of the current proposal version), I'm going to summarize all that -- developers implement a solution by which:
  • All existing date-formatted links are rendered in black text instead of blue, and for high-value dates of interest we use the colon prefix or triple-brackets to make them appear blue-linked.
  • OR vice versa, existing links are unaffected and we apply the colon prefix or triple-brackets to turn low-value / non-relevant date links as black (normal) text.
--Stratadrake 01:02, 11 December 2006 (UTC)
I think both of these options are sub-par to other proposals I've seen, such as a {{date|}} template or new syntax for preferences such as <<date>> or ||date||. They do not address linking to full dates ([[January 10, 2007|[[:January 10]] [[:2007]]]] seems unlikely to please) and also don't take the comma issue that others have raised into account. This proposal was left without a specific syntax defined so that a clear voice can be heard that change is needed. The developers are smart and can either come up with syntax they want to implement (syntax isn't even that important, as long as it gets the job done) or solicit the community for ideas. That's my opinion anyway. --MattWright (talk) 02:42, 11 December 2006 (UTC)
||date|| would clash with table syntax. Stephen Turner (Talk) 10:26, 11 December 2006 (UTC)

 :Would the simplier solution be for WP software to parse any text that has the valid name of a month and a valid day (in either order) and just display the date based on preference, not requiring any text encoding at all to handle this? Thus 'January 20' or '20 January' could be in the text and would simply be displayed correctly because the WP software would be smart enough to know what to do. I could code this to happen with my own software programs; I am sure WP software could do this also. Hmains 02:00, 11 December 2006 (UTC)

There are cases where this is incorrect (inside of quoted text, article names, etc.) --MattWright (talk) 02:28, 11 December 2006 (UTC)
(Sorry if this comment isn't in the best place.) Of course, if we stopped worrying about the readers who somehow don't know that "December 10" means "10 December" (or vice versa), then we wouldn't have to bother with any of this stuff about HTMLing the blue out of links, or using triple brackets or colons or bracey templates or angle brackets, &c. Rather than develop new encoding, why not just stop trying to accomodate a very silly aspect of pickiness? Think about it: how long would this discussion last if it were about magically encoding "color" to be "colour" and vice versa? And is Wikipedia really made superior by having this "One way of writing a date results in multiple ways of displaying it" function? It's true that, at some other websites, you can choose how you want your dates displayed; but this applies only to automatic dates, not to, say, the body of a message posted by someone at a forum. I really don't think Wikipedia is made better by expanding the realm of date variability; I do think a ton of editors who could be improving Wikipedia's content in more-important ways are being distracted by this niggling little matter. If people can learn to add a third colon or HTML, or to put the comma outside of the upcoming quotation marks, and if they can tell that "standardize" is just about the same as "standardise", then they probably can get used to reading and writing dates in just one way for one website. — President Lethe 03:34, 11 December 2006 (UTC)
Well, the real issue is merely that the only way to auto-format dates in Wikipedia articles is to wikilink them. This results in visual clutter, links with no relevance to the article or context in question, etc. And btw, I experimented with trying to make a template to do something like this, but the simple and obvious approach to templating it didn't work (it black-colored the link perfectly, but didn't autoformat the date), Wikipedia software does not (yet) support the string ParserFunctions defined by Meta, and I don't think templates have any means to access user preferences to figure out what date format to use. --Stratadrake 04:45, 11 December 2006 (UTC)
I've been thinking more about this, inspired partly by a message left at my Talk page; and I think that the following is both the simplest of the options that I favor and the simplest to implement:
Let's think about what we do for all the rest of Wikipedia. It boils down to exactly three points:
• (1) in some aspects of written style, we have one rule for everyone to follow (for example, you don't use an unspaced hyphen when an em dash is in order);
• (2) for certain style issues, writers and editors use a variety of standards (for example, whether to write "color" or "colour", and whether SI units are the main ones or the ones in parentheses), and readers have to read articles as they're written (there's no fancy little tool that converts neighbour to neighbor and vice versa);
• (3) the main kind of special encoding used is just for making cross-references, and the only way in which a cross-reference can be made to be displayed as anything other than the name that it points to is with piping (e.g., [[one|two]] shows up as "two" but points to the "one" article).
We could apply this same logic, which has worked fairly satisfactorily for the entire rest of Wikipedia, to the date issue. If we do this, allowing dates to continue to be written with their components in multiple orders (e.g., "10 December" and "December 10"), and removing from the present form of date encoding this magical display variability, then we get these results:
• Picky writers are allowed to put dates in whichever format (from a short list of acceptable standards) they prefer. (This is already what happens.)
• Picky readers sometimes have to tolerate dates in formats that they don't prefer (just as they have to accept color or colour). (This already happens every time a date isn't encoded as a link or isn't written according to the MoS's guidelines, and happens in comma screwups with some coded links.)
• Dates are encoded only for the purpose of cross-referencing. (This is the rule that we already use for everything else at Wikipedia (make it a link only if your point is to link to another page). And the question of when a cross-reference is or isn't relevant will continue to be a point for individual little disputes.)
• Nobody spends any time designing new syntax and putting it into the programming, and nobody spends time learning it and trying to stick it into thousands and thousands of dates.
As far as I can tell, there is no simpler way of handling this (unless, of course, we just leave everything as it is, and continue with these battles and discussions). Even my own other proposals are more complicated than this way. This way is so simple: everything remains the same, except for two points—namely, (1) that whoever programs Wikipedia to work as it works just removes the bits that make encoded dates show up differently for different users, and (2) that battles about linking end up being only about relevant cross-referencing and not how the date appears to various readers.
President Lethe 06:12, 11 December 2006 (UTC)
  • Comment. Preslethe, while I agree with many of your points, the formatting/spelling issues are a complicated compromise on Wikipedia, and proposals for radical change are unlikely to succeed. That is why I've made the request as simple as possible, while hoping that it treads on no one's toes in an area that has tended to be emotive.

I can assure you that if the launching of the request is followed by debate, uncertainty, and a cascade of technical suggestions, it will fail again. To succeed, a simple, unitary argument needs to be put in one fell swoop, period, no further discussion or disarray, just let them assess it and, we hope, act. That's the reason for signing the request with 50+ names: all speaking at once.

We need to avoid (1) possible problems with back-compatibility, (2) offending those who—for whatever reason—want to retain blue chronological items, and (3) complication. The developers do NOT want to enter contentious debates; it's just easier for them to say "no" than to become wound up in unpleasant politics. Getting them to add this parallel syntax will be a major step, and will bring a number of significant improvements that we'll all enjoy. PLEASE, let it go in its simple form, and allow the technical experts to apply their skills. Tony 07:35, 11 December 2006 (UTC)

Hear, hear. Every previous move to change this has petered out in a discussion of the pros and cons of different syntaxes. So let's just ask that we can somehow format without linking, and let the developers decide how to do it. Stephen Turner (Talk) 10:26, 11 December 2006 (UTC)
  • Suggestion: the new syntax should also deal with, or be extendable later to deal with date ranges. Reason 3-5 July has to become [3 July] - [5 July] ATM. In general, ask for the implementation to be forward looking. Rich Farmbrough, 17:48 11 December 2006 (GMT).
  • Suggestion: mention the comma thing. Rich Farmbrough, 17:59 11 December 2006 (GMT).
  • Suggestion: make the syntax extendable later to convert to preferred units (lb/kg, etc). —Quarl (talk) 2006-12-13 22:02Z
I'm pretty sure preferenced unit conversion isn't going to make it into Wikipedia. I modified the code to do this, even taking significant units into account, and was basically told it was a bad idea according to the wikitech mailing list. [2] --MattWright (talk) 22:20, 13 December 2006 (UTC)
I see, that's unfortunate and unexplained. Thanks for trying! —Quarl (talk) 2006-12-13 23:51Z

Unfortunately I've found the developers to be fairly picky about not imposing their will on the community (which is not so unfortunate when you think about it), so my fear is that if we send them a "IB PFI" message, they'll kick it right back as rejected until we give them a syntax as well. That being said, I think we can succeed by a) giving them a list of concerns such as date-range extensibility and retaining wikilinks where appropriate, or b) using an up-down poll for the principle and approval voting (or whatever) for the syntax options discussed so far. -- nae'blis 21:32, 12 December 2006 (UTC)

The community has put forward many great syntax options, but it always devolves into an argument. This proposal is saying "we need a change". No one has yet disputed that we do need a change. Specific syntax will be disputed. Who better to select from the excellent syntax options that have been presented than the developers who know how it will affect future plans, Wikipedia, and the rest of the mediawiki universe? I also don't think it would be terrible to "cross that bridge when we come to it" if they do decide to kick it back to the community. --MattWright (talk) 00:54, 13 December 2006 (UTC)
Fair enough, I am perfectly happy to be found too pessimistic by the consensus of the group. :) -- nae'blis 19:51, 13 December 2006 (UTC)
I intend to pursue the matter further if our representation is ignored. Tony 01:17, 14 December 2006 (UTC)

[edit] Yen vs. Yen

Is there any preferred disambiguating prefix for ¥ to differentiate Japanese yen from Chinese Renminbi? "¥" is not mentioned under the good style examples but it is the sole prefix form used at the Renminbi article. —  AjaxSmack  22:04, 11 December 2006 (UTC)

If there is, I'm not aware of it. My suspicion would be JP¥ and CN¥ respectively, though I wouldn't have a clue.
For the Renminbi article, there would probably be no need to differentiate one from the other as the article is clearly about the Chinese currency. It might help if you could post the article you're working on (or one or more of them). Neonumbers 08:28, 13 December 2006 (UTC)

You could use the ISO 4217 code, i.e. "CNY" and "JPY"; for CNY you can also say RMB. It's common to write e.g. "USD" instead of $ since there are many countries that call their currency the "dollar". Another method is to link to the currency like this: ¥, though that one has the disadvantage that the reader has to mouse-over to see what it is, and it won't show in print. —Quarl (talk) 2006-12-15 04:32Z

Retrieved from "http://en.wikipedia.org../../../m/a/n/Wikipedia_talk%7EManual_of_Style_%28dates_and_numbers%29_9d65.html"