Wikipedia talk:Manual of Style/Dates and numbers

Archives

Archives
1, 2, 3, 4, 5, vote, 6, 7, 8, 9 (AD/CE), 10, 11, 12, 13, 14, 14a, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 49a, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59

See also:

• Wikipedia talk:Naming conventions (calendar dates)
• Wikipedia talk:Timeline standards
• Wikipedia:Measurements Debate

---

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

A new parallel syntax for autoformatting dates

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)

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. VirtualSteve 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. --Robth^Talk 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)
71. Chairman S. ^Talk_Contribs 13:02, 17 December 2006 (UTC) This is an intelligent solution to the problem of date linking, and I support it wholeheartedly.
72. Absolutely. --Spangineer^ws (háblame) 19:49, 17 December 2006 (UTC)

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)

I may well be wrong, as this discussion has grown far beyond my capability to follow it (condensing it a bit, anyone?), but while everybody seems to agree that "we need a change" I see a lot of different ways to intend that; many seem to focus on the color of the text, for instance. All in all, I think I'd prefer eliminating preferences altogether to any half-backed solution which considers dates only, and tries to cope with the developers' capriciousness (though the captatio benevolentiae in the final part of the proposal text might well do the job :-)). After all, I've never seen anyone complaining they didn't like how their paper encyclopedia was spelling dates out as long as there was no ambiguity. —Gennaro Prota^•Talk 20:49, 17 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)

---

A lot of the requests I see here could be solved by a rollout of clever templates. e.g. data ranges. I'd like to see dates encapsulated in templates like: {{dmy}} (for day, month, year), {{dm}} (for day and month), {{my}} (for month and year), {{my range}} for a month and year date range), etc.

e.g. {{dmy|18|December|2006}}

What we need is some mechanism that permits us to implement such templates while honouring users' date preferences. This might be something as simple as a #DATEPREF magic variable. Hesperian 04:53, 18 December 2006 (UTC)

I thought to templates too when reading the MoS pages about dashes, hyphens, beams and motes (;-)) but in fact such usages would be workarounds of software deficiencies (as many existing templates are, for instance {{ISSN search link}}, which I created myself for lack of a better solution). And in this case they would still need a new software feature. Unfortunately (or very fortunately) Wikipedia has pushed MediaWiki to its limits; I don't know if its authors ever had in mind something similar in extent and complexity but certainly the software can't cope with it. It would be the software responsibility, for instance, to convert between units and number notations (at least if we are serious about avoiding human errors). And we are in desperate need of an SCM system. I'd see with enthusiasm a (long-term) project to create a full-fledged content manager, perhaps around SVN, and a migration of all the Wikipedia contents to it. —Gennaro Prota^•Talk 05:26, 18 December 2006 (UTC)

The reason I would be sceptical about using templates like that is that they're (let's be fair) not that intuitive for newcomers (neither would other options, but this is even less so), and the syntax, well, it's rather intrusive for something so common and it'd be difficult to persuade people to actually use it. I mean, I know it's not that long, but imagine writing that out every time you had to write a date. I guess this is why we're leaving it to the developers. Neonumbers 06:44, 18 December 2006 (UTC)

I had another idea for a potential syntax (since it's been mentioned that, if we have one in mind, that might make the developers' job a bit easier), for an auto-formatted but non wikilinked date, what if we could simply type it in as a piped link with no target e.g. [[ |December 20]]. It's obvious the link doesn't actually go anywhere, and when that is the case the Wiki software could format the date text per user preferences. Intuitive and fully backwards compatible (we could organize date de-linking campaigns later), so it's another viable option for a syntax suggestion. --Stratadrake 13:36, 21 December 2006 (UTC)

Update on progress

After receiving no substantive reply, we now have one from developer "Simetrical"> S/he suggests that the conflation of autoformatting and linking may be an issue, and that it is solvable with effort, an effort that s/he is unwilling to provide. There's a suggestion that one or more of the other developers may be willing to review code that is written by one of us. Rob Church is kindly working on one now for this purpose, and two other signatories here have expressed a cautious interest in being involved some time next month.

I suppose that the summary message is:

(1) persistence and active code-writing will be required to generate interest among the developers; (2) it won't be a speedy process; and (2) once an acceptable code is written, and successfully reviewed by the developers, it becomes a matter of having the new syntax approved, which is not a foregone conclusion.

I'll be reminding the developers occasionally of the growing list of signatories, so please advise your fellow WPians if they may be interested in signing on.

Tony 06:30, 21 December 2006 (UTC)

One or more, may, review (not "implement it")… Wow! Didn't he add a perhaps too? —Gennaro Prota^•Talk 15:35, 21 December 2006 (UTC)

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

Rationale for "Where applicable, use uppercase rather than lowercase letters: 0x5AB3, not 0x5ab3"?

Hi,

what is the rationale for this? Is it just something like "pick up one just to be consistent" or are there any other reasons? FWIW, all other things being equal I generally prefer lowercase, as it avoids making the notation stand out with respect to the surrounding text. Also, where would the guideline be "not applicable"? Perhaps in quotations? I guess this last point needs a clarification. —Gennaro Prota^•Talk 09:36, 16 December 2006 (UTC)

Consistency. Full stop. That's pretty much all there is to it. As for why uppercase to lowercase, well, I find where numbers are in contexts where they seem to be done "properly" (i.e. formally) they tend to be uppercase, but I don't claim to be an expert in the field.

Most guidelines are not applicable in quotations. For the uppercase vs. lowercase things, I personally would consider this to not be one of them (i.e. is is applicable), because in my view it is too negligible a change — similar to, say, putting commas in the number in "Retailers sold 49258230 copies of Singstar in the first two months of sales", which you probably would do. It's a tough call though. It is generally difficult to find exceptions to guidelines, but they do occur occasionally: unless there's awesomely brilliant reason otherwise, follow the guideline. Neonumbers 09:56, 16 December 2006 (UTC)

Whoops, just read the guideline and now I see what you mean by the "applicable" part. The "where applicable" in that sentence is intended to refer to "where there are letters in the number", e.g. it wouldn't be applicable for a number like 0x3825 because there aren't any letters that can be lower/uppercase in it! Neonumbers 10:01, 16 December 2006 (UTC)

• Thanks. I was bold and tweaked the section a bit (though I still think that we non-native speakers should rarely touch the MoS :-)). Note that I also tried to make clear(er) that 0b is not a C prefix. Personally I feel that "use uppercase" is a bit of over-specification (sweat the small stuff) and that this is a usage that there's no need to standardize across different articles. Incidentally (and pedantically): in Italian we would likely use a colon after "For numbers in bases other than base ten" (we would also likely prefer starting the list entries with a lowercase letter, though that becomes difficult when there's more than one sentence in each entry — we use lowercase after ':' but uppercase after '.'). Is that different in English? (Sorry, I'm the quality paranoid! :-)) —Gennaro Prota^•Talk 19:35, 16 December 2006 (UTC)

• Oh, and I forgot this (which I was going to fix but thought to discuss first): there's no such a thing as a "non-base-ten number": a number is a number; what changes is the notation or the system of numeration. —Gennaro Prota^•Talk 19:47, 16 December 2006 (UTC)

Yes, you're pedantically right on these :), go ahead and make the changes; I think they're small enough to not need discussion first. —Quarl ^(talk) 2006-12-16 21:52Z

Given that half the purpose of the manual is to encourage consistency, and that in an encyclopedia, consistency is generally pretty important (especially on issues of neatness like this one), I still say the uppercase guideline is good.

For the colon, yes, you're right, a colon would make sense there; a comma can be used but these days we tend to use colons... and if a comma was used, it's then standard practice for the bullet points not to start with capital letters. Colon before a bulleted list normally means capitalised list items, I think (not sure). As for sentences, yes, in English, after a colon, we normally use lowercase: like this.

As for non-base-ten numbers... you know what we mean by that, right?  ;-) Technically, I suppose you're right... if you change it, try not to make it longer or more wordy than it already is. Personally, I think it communicates the message sufficiently, but I won't complain about a change if it makes it clearer but not much longer. (And I thought I was a perfectionist :-P)

I must say I'm not an expert on programming languages; basically the principle behind our splitting of the two situation is that context matters, i.e. the notation should be appropriate to context. Neonumbers 12:20, 17 December 2006 (UTC)

I avoided the colon/comma issue altogether, by removing the sentence containing it (not all sections introduce lists with a sentence, so I guessed the removal was ok); that also got rid, I think, of the upper/lowercase issue.

In general, I'd like to attach a concise rationale section to MoS pages (and articles, if possible). So far, I haven't precisely figured out how to effectively make that, though. It would probably go at the top of the talk page and be similar to what we get with the {{todo}} template. But this is completely in nuce and any idea is very welcome. When it will be more than a vague intent we could bring it to the village pump. —Gennaro Prota^•Talk 13:36, 17 December 2006 (UTC)

I've put the sentence back, this time with a colon, and with slightly different wording. Really, colon/comma, it's not that big a deal, no-one notices these things. In my humble opinion, the sentence provides a good context-setter for the section (the header doesn't count, in my book, anyway).

Don't quite understand what you mean by the rationale section, but sounds interesting. Neonumbers 02:11, 18 December 2006 (UTC)

It is an idea with a proven effectiveness in software development and other collective processes (including ISO standardization - C99, for instance, has a detailed rationale). I know no better way to describe it than Beman Dawes' words:

Rationale is defined as "The fundamental reasons for something; basis" by the American Heritage Dictionary.

Beman Dawes comments: Failure to supply contemporaneous rationale for design decisions is a major defect in many software projects. Lack of accurate rationale causes issues to be revisited endlessly, causes maintenance bugs when a maintainer changes something without realizing it was done a certain way for some purpose, and shortens the useful lifetime of software.

Rationale is fairly easy to provide at the time decisions are made, but very hard to accurately recover even a short time later.

© Copyright Beman Dawes 2003.

Distributed under the Boost Software License, Version 1.0. (See http://www.boost.org/LICENSE_1_0.txt)

—Gennaro Prota^•Talk 15:45, 18 December 2006 (UTC)

When we were discussing this not too long ago (late 2005 methinks, search the archives) I guess I got people to agree upon uppercase, because most fonts nowadays use lining decimal digits, not old style. The latter fit well with minuscels, the former do not. We cannot ensure either one, though. Christoph Päper 14:36, 18 December 2006 (UTC)

For the entire manual, or for each section in turn? Does the lead paragraph that currently sits at the top of this manual count as one? Neonumbers 22:36, 18 December 2006 (UTC)

I'll not let you indent more than me! :-)

Seriously, you can see that the quote above holds: not even the persons who wrote it can remember the details. That's not a criticism against you: it's normal, and that's why experience suggests writing rationales down. —Gennaro Prota^•Talk 23:07, 18 December 2006 (UTC)

No I get the rationale for including rationales, I mean, like, are you suggesting that we include a rationale for each section in turn in the manual (e.g. one for units, one for non-base-ten notations, one for times, etc.), or one rationale section for the entire page? Neonumbers 01:27, 19 December 2006 (UTC)

Ah! I thought you were replying to User:Crissov. Now I understand the indentation! :-) I've resized his image, to limit confusion. I haven't thought of the details (yet). In practice, however, any *choice* is to be given a reason for. Perhaps everything could be in a subpage (of the project page or of its discussion page), with a standardized link to it on the manual page proper. I think it is an important goal to try to stabilize the manual: it does need stability, the more so as the number of Wikipedia articles increases; or we would be like continually changing the rules while the game is in progress (with the difference, compared to a game, that we should retroactively adapt all the previous "moves", i.e. "fix" the style of existing articles). —Gennaro Prota^•Talk 08:42, 19 December 2006 (UTC)

I've gone (or am going) into a new section down the bottom for this topic. Neonumbers 10:15, 19 December 2006 (UTC)

Octal notation

Is it really a good idea to use the C leading-zero convention for octal? Wikipedia isn't a programming book, it's an encyclopedia, and we shouldn't presume that only programmers (or worse yet, only programmers who work in C) will read the computer-related pages. The "0x1234" notation for hexadecimal isn't transparent to non-programmers, but at least it won't be confused with 1234₁₀, something you can't say for the "01234" octal notation. There are other notations, and like '1234'O they all are pretty poor, but at least they're not easily confused. RossPatterson 01:19, 17 December 2006 (UTC)

• Good point. It would seem relevant in programming-related articles though. Since it's pretty rare to use octal nowadays maybe it should have to be explained when used. —Quarl ^(talk) 2006-12-17 01:29Z

• Despite being a C++ programmer I agree. Also, the 0b prefix is very perplexing. All things considered I think the mathematical notation should be used everywhere except where employing a specific programming language syntax (whatever the language is). Another exception could be contexts with lot of numbers (including tables and similar), such as the endianness article: writing so many "₍₁₆₎" there can be quite distracting (arguably). BTW, I was thinking to write a little template to standardize the note/explanation wording and format. —Gennaro Prota^•Talk 10:26, 17 December 2006 (UTC)

• Some languages, such as Verilog, use the 0b prefix (Verilog also uses 0o for octal). —Quarl ^(talk) 2006-12-17 21:15Z

• Ah! :-) Thanks. I guess the "correct" (conforming to the intent) guideline is thus: "In the context of computer, data-modeling languages and other specific formalisms use the notation established by that language (e.g. in C use 0x for hexadecimal; in Verilog use 0b for binary)". Prefer uppercase letters if allowed by the language syntax. In all other articles use the subscript notation. Prefer uppercase as well. —Gennaro Prota^•Talk 21:37, 17 December 2006 (UTC)

I guess I would support a manual change so that, in programming languages, the guideline is to use the notation of that language. I just wonder if there'd be situations that that wouldn't cover. Neonumbers 02:13, 18 December 2006 (UTC)

It should be fine to use the notation of the relevant programming language, per article. In that case each article should have an explanation of the notation or a link to a project-space article about notation. It would help discussion if we had a list of articles that have numbers represented in non-decimal bases. —Quarl ^(talk) 2006-12-18 02:24Z

I favour suffixed b, o, d and h in computing articles (i.e. neutral on programming language), but math-style subscripts in all other articles. Alas, the outcome of the not too distant discussion was different. Christoph Päper 14:40, 18 December 2006 (UTC)

Rationales

(Continued from above)

I agree that some stability is needed, but many would argue that standards can and do change, especially with new browser support and the like (for example, the use of proper dashes is now meant to be more common), and as well as that, Wikipedia is still (arguably) developing and new conventions continue to be developed. I would have to sympathise with those people. Stability's a bit too much to ask at this point in time.

What I'm trying to figure out is how to do so without having too much of the manual being rationale (thereby making it harder to find an actual guideline). Could it be as simple as adding, "because..." after statements, where applicable? Would we need something more solid or formal? The important thing is not to write too much. Neonumbers 11:47, 19 December 2006 (UTC)

All good points. I'm trying to figure out that too. Just a note: I didn't mean "stability" as "immutability", but we should be a little more cautious than elsewhere with the MoS. What about changing the subject here to draw other editors' attention, or bringing this to the village pump? —Gennaro Prota^•Talk 12:39, 19 December 2006 (UTC)

Yes, I think most people would agree with you in that sense. You might have noticed that undiscussed changes are quickly reverted? Though I believe that the manual should only be changed with consensus, and where there is none, the old/original/former guideline should remain standing, in order to retain some stability, I guess. But I know many disagree with this stance; they argue that guidelines need consensus to remain in place. Whoops, getting sidetracked.

Anyway, personally I think it might be wise to solidify thoughts before going to the village pump because it is a rather fundamental proposal, in my opinion, anyway. Will support your decision if you decide to do so though. Neonumbers 10:58, 20 December 2006 (UTC)

two nine-page letters or two 9-page letters?

Can we add an exception to the spell-out-all-numbers-under-10 rule for hyphenated adjectives with numbers? In other words, include something like this on the project page:

For hyphenated adjectives with numbers, like 2-year contract, 5-story building, use numerals instead of words.

Someone just reverted my change to "7-vowel system" back to "seven vowel system", and they're right according to this page, but they're wrong according to the Technical Editing course I took. --Dblomgren 16:55, 20 December 2006 (UTC)

I would always write "two-year" or "five-story" (well, I'd write "five-storey", but that's a different question). Stephen Turner (Talk) 17:16, 20 December 2006 (UTC)

Could you please also give an opinion on "3-volume", appearing in the Principia Mathematica article? —Gennaro Prota^•Talk 22:00, 20 December 2006 (UTC)

Again, I'd consider "three-volume" to be good style, although it seems Dblomgren would disagree. Anyone else? Stephen Turner (Talk) 22:40, 20 December 2006 (UTC)

Stephen's right, so "seven-vowel system" is the widely accepted way. "Two 9-page letters" is a recommended exception in several major style manuals, but there's no universal rule: it makes sense as an exception. The other exception is for units. And I wonder whether the MoS makes the SI distinction between "3 mm" radius and "3-millimetre" radius? That's a widely accepted distinction in hyphen use between abbreviated and spelt out units, where they're part of a double or triple adjectival form. Tony 06:11, 21 December 2006 (UTC)

Yeah, I'd agree with Stephen on that. Neonumbers 08:35, 21 December 2006 (UTC)

I'm a little confused now. Why is ""two 9-page letters" a recommended exception? Because it employs two consecutive numeral adjectives (two and nine)? So one would say, for instance, "three 7-vowel systems"? Thanks, Gennaro Prota^•Talk 09:29, 21 December 2006 (UTC)

"five-story", etc. is good style, and the only problem with things like "two nine-page letters" is if you do "2 9-page letters" —Centrx→talk • 08:42, 21 December 2006 (UTC)

Personally, I'd write "two nine-page letters", because in my mind, the hyphen is sufficient to resolve any confusion there. As Tony says, there's no universal rule on that — I guess it could be considered a pedanticism? (excuse the coinage) Probably the two number-words in a row, yeah, though personally I don't quite get it either. Neonumbers 10:18, 21 December 2006 (UTC)

Sure, this is fine too; there are cases where it's not, though: "three three-millimetre bullets" might better as "three 3-millimetre bullets". Up to you. Tony 12:00, 21 December 2006 (UTC)

I see... maybe (just maybe) I could buy that one... :-) interesting, these things are. Neonumbers 04:14, 22 December 2006 (UTC)

I happened to find an example in the literature of this very juxtaposition using words, not numerals; from the OED: 1711 London Gaz. No. 4906/2, I had two Nine pound Shots through my Fore~mast. —Centrx→talk • 10:25, 21 December 2006 (UTC)

It's understandable where Tony is coming from, his last example is one of the same number twice in a row, which might encourage some people to think of it as a typo, when it's not. --Stratadrake 13:52, 21 December 2006 (UTC)

Usage of m as an abbreviation

I think that the usage of m as an abbreviation should be discouraged, except when it is clear that meters are being talked about or if it is necessary due to space constraints in a table. The reason for this is that m can stand for meters or miles and it is not always clear which is being talked about. For example, an island could easily be 100 meters or 100 miles off the coast. You might say that we can use mi for miles, but that is irrelevant because visitors would not know that and even editors would not know whether the writer of the text is aware of the convention or not. -- Kjkolb 23:55, 20 December 2006 (UTC)

No, "mi" stands for miles. Since 96% of the world uses metres, I'm unwilling to dispense with a widely understood and convenient abbreviation. —The preceding unsigned comment was added by Tony1 (talk • contribs).

"m" pretty much universally stands for "metres". I don't think it's ambiguous. Neonumbers 08:39, 21 December 2006 (UTC)

You can always link it the first time it occurs if you consider it necessary: 15 m. Using m for miles is a bad idea though, in my opinion, because most of the world uses m for metres. Stephen Turner (Talk) 08:41, 21 December 2006 (UTC)

First, "m" is a common abbreviation for miles in the United States. I love the metric system and I wish that English/Imperial units could be dispensed with. Unfortunately, the vast majority of people in the United States have virtually no comprehension of the metric system (note: I have lived in the U.S. all of my life and I have an extensive and broad scientific education). The only significant exposure that most young people have to the metric system is in physical science classes, like chemistry (many biology classes below the university level do not deal with a lot of measurement or calculations, even though metric units are nominally used). If he or she does not go to college, a typical young person may have had a couple of science classes that used the metric system and that is it. This is not a good enough exposure to have an good understanding of the metric system, and what little knowledge they do have will soon be forgotten because they never use it again. Worse, older people never even used the metric system in school at all.

Second, as I tried to explain in my original post, using "mi" does not solve the problem. Visitors from the United States who know nothing of Wikipedia policy will not know of a convention to use "m" for meter and "mi" for mile, so there will be a problem when they come across an article that uses the abbreviation "m" in it. I sincerely believe that the vast majority of people from the U.S. will not only believe that "m" stands for "miles" in my example above, but that most of them will not even think of the possibility that it could be "meters" (some may not know that "m" is an abbreviation for meters and/or be unaware of what a meter is).

Third, as I stated in my original post, I am not suggesting that the abbreviation be abandoned, just that when the possibility for misunderstanding exists, it should be stated explicitly what units are being used. -- Kjkolb 16:44, 25 December 2006 (UTC)

I agree with Kjkolb. It's illogical to assume that whatever makes sense to most people in one country must make sense to people in other countries, and it's selfish and unreasonable to disregard evidence to the contrary. Furthermore, while Americans are a minority overall, we also constitute a majority of native English readers.

It's perfectly easy to type "metres" or "meters," which in no way makes the articles less understandable for anyone. In my opinion, this also is vastly preferable from a stylistic standpoint. —David Levy 18:28, 25 December 2006 (UTC)

Admittedly, I'm not American. The current guideline (or my intepretation of it) is that all units are to be spelt out in prose, except when:

• they are a conversion, e.g. "An NBA basketball court is 96 feet (29 m) long" or "A FIBA basketball court is 28 metres (92 ft) long"
• it is in a specialist article where it is obvious what unit is being used (in the case of metres, possibly science?)
• it is in a table or infobox, where space is precious (though I've never actually seen that in practice, except in specialist science/technical articles)

To some extent it means that "metres" has to be spelt out, but not necessarily always. The infobox case might be a borderline one. I must admit, I'm still unsympathetic (they need to learn about the rest of the world, just as the rest of the world learns what an inch is when they never use it, or at least, they'll look it up as necessary, and it's not like a metre and mile are similar in length so it should be fairly obvious something's different) but I want to see where the current guideline stands with respect to this issue. I think, to some extent, it addresses the concerns. So, are the exceptions okay, i.e. are the exceptions cases where it would be obvious enough? Neonumbers 00:23, 26 December 2006 (UTC)

Americans' relative lack of familiarity with meters is a secondary issue. (Many Americans have at least some understanding of the unit, often associating it with the slightly smaller yard). The primary problem is that Americans might misinterpret "m" to mean "miles" (given the fact that this abbreviation sometimes is used in the U.S.). Kjkolb cited an instance in which this application would seem to make sense.

In your conversion examples, no reasonable person would make this mistake, but I still see no harm in using language that more people would understand. (I don't know how recognizable the abbreviation "ft" is to individuals in countries that primarily use the metric system, but I certainly would support spelling out "feet" if this were to help people.)

Regarding "specialist article[s] where it is obvious what unit is being used," this would depend upon the context, but my point regarding the harmlessness of spelling out "metres"/"meters" applies.

As for tables and infoboxes, the context can be clarified in the main prose, so abbreviation here is a legitimate space-saver. —David Levy 00:55, 26 December 2006 (UTC)

Units should always be spelt out in prose, so this is only an issue for the conversions and usages in infoboxes/tables. Always spelling out conversions might be good—it would look more professional—but it would not be relevant to the above matter because any metric conversion would already have the English units spelled out before them. For infoboxes and tables, they are not spelled out because it is necessary to use less space, so there would be no other alternative to "m" except an utterly novel "me". —Centrx→talk • 02:29, 26 December 2006 (UTC)

The issue of spelling out conversions would have to be considered for all units, not just metres; and in my opinion it would be more of an issue of "is it stylistically better" (i.e. more professional), and if it is found that it is stylisically better to spell out conversions (which, in order for conversions to take up less space and therefore reduce impact on the flow of the article, I disagree with, but anyway) then that of course will work fine. For specialist articles, in the case of metres, the only instance I can think of is in science (probably the physical sciences?), and it'd probably just about always be preceded by a rather long number in scientific form, and surrounded by a sea of metric/SI units in the rest of the article which should make it obvious that it's metres not miles (right? you tell me, keeping in mind that readers of those articles are likely to have at least some background in the subject (otherwise they'll understand nothing))...

What I'm trying to say is, the current guideline effectively encourages spelling out of the word "metres". It is only in cases where the symbol is recommended (which are relatively few) that "m" is preferred. Neonumbers 09:30, 26 December 2006 (UTC)

To the original question of m being confused with miles instead of meters: I've never seen an instance where m was used to mean miles—nither wikipedia or elsewhere. Most of us Americans who are on Wikipedia for one reason or another are smart enough to know what a meter is. I think it is safe to keep m as an abbreviation for meters per some of the great reasons given above. —MJCdetroit 21:46, 26 December 2006 (UTC)

While this isn't a error that you or I would commit, I have seen such an abbreviation used informally. Furthermore, even smart people make mistakes—such as your ironic use of the phrase "us Americans" (no offense intended).

Wikipedia is an encyclopedia for the masses. If a tiny amount of effort can assist some of out readers (without causing any harm), I see no reason not to expend it. —David Levy 22:07, 26 December 2006 (UTC)

ISO 8601 dates again

I just removed examples of ISO 8601 dates from the section "Dates containing a month and a day".

When we rewrote that section in April, there was a consensus to remove those dates. And their presence there contradicts the later section "ISO date formats" (which had consensus although with a small amount of dissent), which explains that linking such dates is magical too but recommends not to use them in most contexts.

I have been back through the history, and discovered that the examples were reinserted by User:Docu on June 15 (GMT). The edit summary says "as per talk", and indeed there was a short discussion here. However, it doesn't seem to me to show a consensus for restoring them, and the previous discussion did show a consensus for removing them. I note that it was added at the same time as another edit of Docu's which also said "as per talk" but which hadn't achieved consensus and was quickly reverted.

So I've removed it again. We can discuss it here if people want. But my understanding is that there are a couple of people who think it should be allowed because it's an unambiguous standard, but a clear majority think it's bad style in normal prose.

Stephen Turner (Talk) 11:26, 21 December 2006 (UTC)

As usual, the majority is wrong. Unambiguous dates should be the standard and enforced as a rule, not merely a guideline). Lacking that, ISO 8601 format should at the very least be a documented option for people with the good sense to use it. Aside from that, the example you deleted was a useful example of a perfectly valid Wikipedia feature, and as such it serves a useful purpose in that place in the article. I have therefore reverted your deletion. -- -- BBlackmoor ^(talk) 19:31, 28 December 2006 (UTC)

As it happens, the firm views of a clear majority is what determines these guidelines. Most of us agreed that they were not standard practice in modern English prose. Anyway, I never really understood how 29 December 2006 could be ambiguous... Neonumbers 00:11, 29 December 2006 (UTC)

Bblackmoor, I'm surprised to find an experienced editor justifying an edit to the Manual of Style with the phrase "As usual, the majority is wrong", especially after you talk so much about consensus on your page. For all its faults, consensus is the way we determine our guidelines.

I still maintain that ISO 8601 dates should never be linked. There may be occasional circumstances where use of ISO 8601 dates is appropriate, but there is never a time when you want established users to see "29 December 2006" or "December 29, 2006", and new or anonymous users to see "2006-12-29".

Stephen Turner (Talk) 08:38, 29 December 2006 (UTC)

"Numbers in letters" (for two-word or less) or "Consistency" comes first?

Apparently, I could not agree with Epeefleche's opinion about the numbers in numeral/letter form (in this case it is mostly about order numbers. I think). The problem was started in Mike Mussina about this edit. There is a small discussion about this in here, although I felt the need to have more opinions from different people. There is also a change in number style under this page (I had it on watchlist, so I noticed that). Any thoughts about this issue? Replying in either here or on Mussina's talk page are fine, although keeping this discussion in the other talk page might be preferred. Regards, Vic226_(chat) 16:50, 27 December 2006 (UTC)

Date formats related to topics

We've had a couple of looks at this before. I reverted the addition of France to this list because the change, in my opinion, is significant enough to require prior discussion and, if necessary, the gaining of consensus.

My view is that no date format should be recommended for any country that is not English-speaking. Learning how to write the date is part of learning the language, so non-English speakers will learn about how we write our dates. After all, we wouldn't expect articles about China to use 2006 December 30 for its purposes, would we? The British-American difference is not unique to dates, but the division is unique to English. That's my view, anyway. Neonumbers 12:34, 30 December 2006 (UTC)

I can't follow this logic. Every country has a preferred format for dates, whether it is 1-23-1945 or 23-1-2000. The name of the month is the only part of it that is English: the format applies to the country, not the language. 14 Juilliet is Bastille Day in France, and of course we translate the French month name as July - a thoroughly noncontroversial usage. I note that several countries in the Commonwealth of Nations don't use English as their primary language. Exampleas are India (Hindi), Pakistatn (Urdu), Bangladesh (Bengali), Cameroon (French), Mozambique (Portugese), Maldives (Dhivehi), Brunei (Malay), Cyprus (Greek) etc. etc. Rather than make an illogical and inconsistent choice on language, I suggest that we continue to use date format actually used in the country as the criterion for date format in the article. This is consistent with other usages, such as metric/Imperial units. --Pete 17:20, 30 December 2006 (UTC)

I'm sure I've said this before (although I can't be bothered to search through the archives now) but I strongly believe we shouldn't have a list of example countries there at all. It just invites people to add more and more. I don't believe the list of countries adds anything to the guidance. Let's just remove them. Stephen Turner (Talk) 20:26, 30 December 2006 (UTC)

Left to my own devices, I would tend to agree that we shouldn't have a list at all. Historically, however, the problem has been that certain editors mostly in the US have taken the view that in the absence of instructions to the contrary it's OK to use month-day-year format for all countries even when normal practice in those countries' languages is day-month-year, thus rubbing everyone else up the wrong way and creating the perception that all countries should be named in the example countries, even though countries which use month-day-year format are a very small minority in the world (and ignoring East Asian languages which use year-month-day format). Personally, I would prefer the statement to be changed to read "use month-day-year format in articles relating to North America and a few countries very heavily influenced by the US, such as the Philippines and Micronesia, and day-month-year format everywhere else." -- Arwel (talk) 14:50, 31 December 2006 (UTC)

I would leave the instructions, but without the list. In other words:

If the topic itself concerns a specific country, editors may choose to use the date format used in that country. This is useful even if the dates are linked, because new users and users without a Wikipedia account do not have any date preferences set, and so they see whatever format was typed. See Wikipedia:Manual of Style#National varieties of English for more guidance.

This seems to me to be just as definite and more concise. If, as in your example, a U.S. editor were to change a British or a French article to American dates, it's just as good to cite this guideline as the existing one when changing it back.

Stephen Turner (Talk) 17:35, 31 December 2006 (UTC)

A change to the project page must be supported by a prior discussion. I reverted the change because of a lack of this discussion (what is above is still insufficient, you must give everyone some time).

To emphasise this, I am deliberately not commenting on my opinion on this change. All I want to press on in this post is that this is not a minor change, and agreement (or lack of opposition within a reasonable time) must be found here first. I will leave further comment on the change itself to other users and may comment on it in one or two days, to emphasise that I reverted not because of my opposition, but because of process. Neonumbers 03:02, 31 December 2006 (UTC)

Adding another nation to an existing list of nations is a minor change, when they are united in date format. The debate is whether there should be a list at all. --Pete 20:27, 31 December 2006 (UTC)

Looking back, it seems there was no problem with adding other nations such as Ireland and Palau. I cannot see why France should require special treatment. --Pete 08:11, 1 January 2007 (UTC)

I've reverted it again. It's clear from the discussion here that there is no consensus for this change. Neonumbers is right — you need to wait until the discussion has concluded. Stephen Turner (Talk) 08:45, 1 January 2007 (UTC)

My point is that prior consensus was not found for other additions such as this one. Adding to a list where the criteria for membership are known should require no discussion. Ireland uses day-month-year format, as does France. --Pete 09:31, 1 January 2007 (UTC)

So do you think we should add all two hundred or so countries in the world? Stephen Turner (Talk) 13:13, 1 January 2007 (UTC)

No, but if process is as important as some insist, then building on past process is the way to go. Once again, I point out that adding countries to a list has needed no prior discussion in the past. I'm happy to dispense with a list entirely, but that is exactly the sort of change that requires consensus. --Pete 17:35, 1 January 2007 (UTC)

Adding an English-speaking country seems a bit different, perhaps. But in any case you shouldn't assume that because one edit didn't get reverted that a precedent has thereby been established. Stephen Turner (Talk) 08:41, 2 January 2007 (UTC)

Again I make the point that the list contains several nations that do not have English as a primary or official language, in that they are members of the British Commonwealth. In fact, most of the citizens of the totality of countries belonging to the Commonwealth do not speak English. Speaking English is quite irrelevant to whether a nation uses one date format or another - I need only point out that the U.S. and the U.K. both speak English, yet use different formats.

And no, it's not just one addition to the list. The last half-dozen additions have been added with no objection or prior consensus. That looks like a pretty good precedent right there, which is why I simply added France to the list. --Pete 17:28, 2 January 2007 (UTC)

Would anyone like to comment on my proposal above that the list of countries be deleted entirely? Stephen Turner (Talk) 08:41, 2 January 2007 (UTC)

You've convinced me, Stephen. I support it. Neonumbers 11:11, 2 January 2007 (UTC)

I'm happy to lose it, but I make the point that we still need to know which countries use which date format. Who knows what format Wallis uses? Or Burkino Faso? --Pete 17:28, 2 January 2007 (UTC)

Time interval

I can't find out a policy concerning time intervals.. think about a sport competition.
What about 22 seconds and 7 tenths? 22.7 / 22.70
What about 4 min and 22.7 seconds? 4 m 22.7 / 4 min 22.7 / 4'22"70
What if you take into account hours?
Don't bite newcomers, Marra 23:53, 30 December 2006 (UTC)

22.7 and 22.70 are not the same thing so it is not a style matter to be decided. " and ' are discouraged as too opaque. 4 min 22.7 sec is acceptable. Rmhermen 00:54, 31 December 2006 (UTC)

These are not the same thing. 22.70 specifies that the measurement was precise to the hundredths. —Centrx→talk • 02:56, 31 December 2006 (UTC)

That's a very good question, Marra.

My take is that an interval of a time is a quantity, and is therefore governed by the "Units of measurement section" rather than the "Times" section, which aims to do with times of the day. Therefore, in prose, it should be expressed as "22.7 seconds" or "22.70 seconds" (depending on the accuracy of the measurement as Centrx said). Likewise, for minutes, "4 minutes 22.7 seconds" or "4 minutes and 22.7 seconds". If in a table or infobox, the symbols are min and s respectively (SI), though "sec" might be more appropriate — personally I much prefer "s".

It would help if you gave us a pointer to the article itself so that we can understand the context. Good job with pointing out the lack of clarity there. Neonumbers 03:14, 31 December 2006 (UTC)

I first found 3 m 46.29 s in Ian Thorpe's article, that was not consistent within the article. Looking at other swimming/athletic articles I found that there is not an uniform style, and neither a clear MOS entry.

Quite a lot diffused is to say 3:46.29, in my opinion is more compact and clear than 3 min 46.29 s .. add a couple of hours and it makes 2:03:46.29. I think this is the best format despite heavy when going from hours to hundredth (hh:mm:ss.xx - with xx I mean 1/100th). Marra 09:24, 31 December 2006 (UTC)

How would I know that 3:46 was three minutes and forty-sex seconds but not 3 hours and 46 minutes? I don't like that format at all. Remember "Wiki is not paper" and spell out as much as possible. Rmhermen 21:57, 31 December 2006 (UTC)

You'd certainly be right to say that the format should be consistent!

While it would be possible to argue that the true meaning of 3:46 (and, for that matter, 3:46.29) can be determined based on context, I would still prefer to avoid the risk. In my opinion, 3 min 46.29 s is more readable than 3:46.29—which is of course simply opinion.

It is best to spell out units as 3 minutes 46.29 seconds, but looking at that article, it looks as if it would become rather cumbersome. (Personally, I think the article focuses too much on the little things like times and details, but that's another issue and not one for us.) It might be fair to abbreviate units here, but I would still prefer against 3:46.29, except in extended tables (of more than, say, ten rows). My two cents. Neonumbers 07:49, 1 January 2007 (UTC)

Well.. I did a quick survey on FINA and IAAF websites, it turns out that the format hh:mm:ss.xx (with xx I mean 1/100th) is the one actually used.

• In long events hundredth are avoided (here) and sometimes even tenth (here)
• In sprints hours are not taken into account (here) and even minutes may be omitted (here) and (here)

This format is never ambiguous (3:46 can't exists since for a such short race hundredth are considerd, so 3:46.29) and rarely heavy to read (since you never go from hours to hundredth).

Choosing the format for wikipedia you should consider that this kind of articles are often filled with a lot of timing info so compactness is an issue. By the way I wouldn't say that these infos are details! Believe me that these are really interesting things for a fan. Marra 16:36, 1 January 2007 (UTC)

lol, okay, for a fan (as only an encyclopedia can do), if you say so... :-P and we should consider, Marra ;-)

For an article like that I could understand 1:23.45. The only concern I would have is immediate clarity for people that aren't sports fans. In context, it's not ambiguous, but as is always the case, it needs to be clear. Such clarity could be achieved by, say, clear wording of a sentence, or may not need any effort at all to be achieved.

I would imagine that this format would only work well for race times (and lots of them). Intervals of time in other contexts would be better off with 1 min 23 s — unless there's other contexts? Neonumbers 07:37, 2 January 2007 (UTC)

I completely agree with you, in sport-related articles hh:mm:ss.sss is the right format.. moreover ISO 8601 and W3C say the same thing! :)

I read some ISO directives and stuff like 3 min 46.29 s are never mentioned. Will we still allow this on wikipedia? I'd say yes for purpose of clarity.. but the answer is no more obvious in my opinion. Marra 09:25, 2 January 2007 (UTC)

I'm just trying to think of an instance in which it would actually need to be used. If there is one, then yes. The abbreviations are those recommended by the SI manual, and it follows all of the guidelines in the units section of our manual here, and of course it's clear. I think we would need it for intervals of time that are both abbreviated and not a race time, but I can't name any. Even for non-race sports like football and basketball, I don't see how such information would be encyclopedic content anyway (except in exceptional circumstances).

As always, most instances would be fully spelt out, but in the event that abbreviation of this is required, I'd say yes too. Neonumbers 11:09, 2 January 2007 (UTC)

Question RE: Linking Source Access Dates in a Citation

For a FA-candidate, one reviewer continues to object on the grounds that the dates on which a cited source was accessed as mentioned in the footnote/citation should be linked up. I refuse do to this, as the nominator and chief contributor to the FA-candidate because it's just ludicrous given that this is just a "guideline" and that it would violate Wikipedia:Only make links that are relevant to the context in that linking up such dates will not be relevant to the article's context or aid or facilitate in any way a reader's understanding of the article. So I ask the following:

• What is the consensus regarding this guideline being in force on access dates in citations?
• If there hasn't been a consensus, what is the opinion of the contributers and other people who debate this MOS provision?

I thank you in advance for your answers and assistance. —ExplorerCDT 18:04, 1 January 2007 (UTC)

The reason we use linked dates is not because they link to anything, but because they are automatically converted to the user's preferred format. For a FA, all dates should be wikidates. --Pete 18:37, 1 January 2007 (UTC)

• Please see and respond to the question below posed to Dwaipayanc. —ExplorerCDT 18:43, 1 January 2007 (UTC)

My observation Quoting Wikipedia:Manual of Style (dates and numbers), "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."

Also, "This Manual of Style, like all style guides, attempts to encourage consistency and ease of reading. The guidelines here are just that: guidelines are not inflexible rules; one way is often as good as another, but if everyone does it the same way, Wikipedia will be easier to read, write and edit." Please comment. Regards.--Dwaipayan (talk) 18:39, 1 January 2007 (UTC)

• Please explain how linking source access dates are relevant to the context of the article or how they increase the understanding of an article? Please don't just quote the MoS, because it's already accepted as a given...ambiguous and contradictory as it is. —ExplorerCDT 18:43, 1 January 2007 (UTC)

Well, access dates are not relevant to the context of the article. That is clear. This policy concerns allowing readers' date preferences (to display the reader's chosen format).--Dwaipayan (talk) 19:57, 1 January 2007 (UTC)

Linked dates make the article easier to read because the date appears in a format which is natural to the reader, not one which is unnatural. I think almost everyone agrees that linking and formatting should be able to be done separately, but the software doesn't work that way at the moment. Given that they're the same operation, the clear consensus is that the advantage of making dates appear in the reader's preferred format is greater than the disadvantage of making links that are not relevant to the context. Stephen Turner (Talk) 20:03, 1 January 2007 (UTC)

This again? Please see A new parallel syntax for autoformatting dates above, especially the subsection "Update on progress". A lot of people share your concern about overpurposing the linking of dates, but progress on a fix is slow. -- nae'blis 17:37, 2 January 2007 (UTC)