Misplaced Pages

talk:Manual of Style/Dates and numbers - Misplaced Pages

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
< Misplaced Pages talk:Manual of Style

This is an old revision of this page, as edited by Guy Harris (talk | contribs) at 01:05, 28 January 2007 (→Converting to SI prefixes: Verifiable, but ambiguous, and the reader has to resolve the ambiguity.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Revision as of 01:05, 28 January 2007 by Guy Harris (talk | contribs) (→Converting to SI prefixes: Verifiable, but ambiguous, and the reader has to resolve the ambiguity.)(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)

Archives

Archive
Archives

See also:

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 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 . 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 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 .
  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 Misplaced Pages.
  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 21:43, 10 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 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 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. 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 (háblame) 19:49, 17 December 2006 (UTC)
  73. Keesiewonder 02:07, 5 January 2007 (UTC) If when I wikilinked, I received a list of all other important events that happened on that month-day, that'd be neat. But if all I find out is it is day X on the Gregorian calendar ... it seems pretty useless ... other than for displaying dates in the form of my preferences.
  74. Good idea. --tjstrf talk 02:10, 5 January 2007 (UTC)
  75. Excellent idea - esp per points 3 and 5 --Orderinchaos78 01:47, 6 January 2007 (UTC)
  76. Strong support Jimp 01:34, 9 January 2007 (UTC)
  77. Oh my yes! Make links explicit (once in a while they actually are needed) rather than implicit (most of the time they are not) ++Lar: t/c 05:29, 13 January 2007 (UTC)
  78. I would like that very much. Schmiteye 00:28, 22 January 2007 (UTC)
  79. Linked dates, and cities, countries etc, that have no special relevance to the article is an unnecessary eyesore.Strongly agree.Momento 10:18, 22 January 2007 (UTC)
  80. If articles can't be marked up in accordance with common sense and Misplaced Pages guidelines, so as only to link significant terms, then this is a reasonable move. It's just a pity that it's necessary. --Phronima 11:30, 23 January 2007 (UTC)
  81. This would be a great improvement. —Celithemis

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., ]) 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: ] produces a non-linked (or black-linked) date, while ] produces a blue-linked date. I believe this is the more intuitive option, but it is not necessarily backwards compatible.
  • Method 2 - Vice versa: ] produces a blue-linked date, while ] 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., ]] versus ], 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 (] ]]] 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 Misplaced Pages 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 Misplaced Pages is made better by expanding the realm of date variability; I do think a ton of editors who could be improving Misplaced Pages'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 Misplaced Pages 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), Misplaced Pages 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 Misplaced Pages. 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., ] 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 Misplaced Pages, 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 Misplaced Pages (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 Misplaced Pages 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 Misplaced Pages, 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 - 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 2006-12-13 22:02Z
I'm pretty sure preferenced unit conversion isn't going to make it into Misplaced Pages. 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. --MattWright (talk) 22:20, 13 December 2006 (UTC)
I see, that's unfortunate and unexplained. Thanks for trying! —Quarl 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, Misplaced Pages, 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 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) Misplaced Pages 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 Misplaced Pages contents to it. —Gennaro Prota 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. ]. 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 15:35, 21 December 2006 (UTC)
Interested parties may wish to view Rob Church's blog for updates on his progress. In particular, there is a working version of Rob's parser hook solution at his personal wiki. Gzkn 08:02, 4 January 2007 (UTC)


Dear supporters,
Rob Church has posted the following update:
"Just to follow up...most of the work for the DateParser class is now done, and the FormatDates extension has been checked into Subversion. I need to find some time to write an exhaustive set of test cases for it, and run some profiling checks on it.
The extension, for those who weren't following, introduces a <date> tag."
It's very pleasing to know that progress is being made, although there's a way to go yet. Many thanks to Rob for his efforts! Tony 07:44, 6 January 2007 (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 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 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)
"Two letters, each nine pages long". "Two 9-page letters" is to grammar as a rubber patch is to a bicycle tyre. -Ashley Pomeroy 02:03, 13 January 2007 (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 Misplaced Pages 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 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 Misplaced Pages 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).
Misplaced Pages 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)
MJCdetroit, you just haven't paid any attention. There are a great many Misplaced Pages articles which have at one time had "m" used for miles, primarily for one reason: that (well, actually "m.") is what the 1911 Encyclopædia Britannica used. They should always be converted to "mi" or spelled out. Furthermore, there have been many Misplaced Pages articles using "mile" as a symbol for miles. They should also be converted to "mi" or spelled out (the spelled-out word, unlike the symbol, adds an "s" in the plural).
Just for you, I went out and found one that is still that way: see Blaye (no, you cannot jump over the Gironde Estuary there!). It isn't the only one. Gene Nygaard 18:00, 19 January 2007 (UTC)
Furthermore, I take issue with the User:Centrx claim that "Units should always be spelt out in prose". This has been discussed here before. It is quite the opposite in the recommendations of standards organizationss dealing with measurement, as in NIST Special Publication 811, Guide for the Use of the International System of Units, Section 7.6 Symbols for numbers and units versus spelled-out name of numers and units
This Guide takes the position that the key elements of a scientific or technical paper, particularly the results of measurements and the values of quantities that influence the measurements, should be presented in a way that is as independent of language as possible. This will allow the paper to be understood by as broad an audience as possible, including readers with limited knowledge of English. Thus, to promote the comprehension of quantitative information in general and its broad understandability in particular, values of quantities should be expressed in acceptable units using
  • the Arabic symbols for numbers, that is, the Arabic numerals, not the spelled-out names of the Arabic numerals; and
  • the symbols for the units, not the spelled-out names of the units.
The same reasoning about international recognition including "readers with limited knowledge of English" apply to Misplaced Pages. Gene Nygaard 18:00, 19 January 2007 (UTC)
  • Let me add that I think it's crass to insist on the spelling out of units, whether metric or imperials, after the first occurence in an article. I won't do it, whether within parentheses as "equivalent" units or not. Tony 08:52, 20 January 2007 (UTC)
I agree with you, and furthermore, it is often the ones within parentheses that would be best spelled out on first occurrence. Gene Nygaard 14:03, 20 January 2007 (UTC)
I find Gene Nygaard's comment odd: If a user doesn't know enough English to be able to read the word "metre", how on earth are they going to read the rest of the article? This is the English Misplaced Pages, after all. If the goal is to make it more readable by people with limited English skills, there are plenty of more complex bits of English we should start cutting out before we resort to cutting out the word "metre". --Delirium 09:27, 20 January 2007 (UTC)
The only thing I can read at ko:인천광역시 is "986.980 Km", even though they didn't quite get the right symbol, improperly using "Km" rather than "km". With that, I might even be able to go somewhere else and figure out what those strange characters refer to.
But in any of the other Wikipedias I might visit (the two Norwegian ones, the German one, etc.) any measurements are easier to read if they are in Arabic numerals and SI symbols. It is just one little thing you don't need to worry about, one thing you don't need to bother translating in your head. If you run across something saying "sju dekar" on one of them, you might not know what in the world they are talking about, but if it is instead "7 da" you might even figure out that this is 0.7 ha or 7,000 m². Gene Nygaard 17:27, 23 January 2007 (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 Misplaced Pages feature, and as such it serves a useful purpose in that place in the article. I have therefore reverted your deletion. -- -- BBlackmoor 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)
2006-12-29 isn't ambiguous. That's exactly what I am saying. -- BBlackmoor • 2007-01-03
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)
There is never a time I want any user to see "29 December 2006" or "December 29, 2006" -- not in a reference work. Like Roman numerals and archaic measurements like "stone" and "cubit" (and some would say "pounds" and "yards"), that's suitable for prose and poetry, but not for a reference work. It annoys me that an editor can enter a valid, unambiguous date in an article and Misplaced Pages will senselessly reformat it. I suppose the alternative is typing dates like this: ]. I may start doing that from now on to avoid this problem. -- BBlackmoor • 2007-01-03
Shouldn't have linked that date above. My sentence was "I never really understood how 29 December 2006 could be ambiguous", not 2006-12-29.
Is 29 December 2006 ambiguous? Neonumbers 08:42, 5 January 2007 (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 Misplaced Pages account do not have any date preferences set, and so they see whatever format was typed. See Misplaced Pages: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)
I'm assuming that someone writing the article is likely to know. In any case, I don't think we should maintain a list to tell people which format Burkino Faso uses. Stephen Turner (Talk) 18:21, 2 January 2007 (UTC)
Looking back at the history of date formats, it seems that a lot of editors imagine that all nations use the same date format. For example, look at Gerald Ford, an article which has had a lot of attention recently, yet still contains at least one day-month-year date, in the third paragraph of the "childhood" section. This was added in the past week. This format is incorrect according to the bulk of dates in the article, the subject matter, and these guidelines. I think that even if someone knows the date of independence of Burkina Faso, or when the explosion at Vol-au-vent occurred, we have no guarantee that they know what format to put that date in. They will probably guess. --Pete 01:01, 3 January 2007 (UTC)
Yes, you're probably right actually. But I still don't think we should have a list of 200 countries with their date formats, and therefore we shouldn't have a list at all. At least, not on this page — it would be a good idea as a proper article. Stephen Turner (Talk) 10:43, 3 January 2007 (UTC)
I agree that the list of countries should be deleted, because I also think that all Misplaced Pages articles should use international standard date format. However, I also think that a list of date formats used by various countries would be a worthwhile Misplaced Pages article. -- BBlackmoor • 2007-01-03
I think both the decision and publication of which format to use should be left to the Wikiproject for each respective country. I think editors involved with those projects have the right to determine that for theirselves, and post their guideline on their page, if and only if they wish to do so (and some countries may not). If there is no Wikiproject for a given country (or a given non-country Wikiproject), then leave it to the article's editors to decide.
Keep in mind that an editor might enter the wrong date format from mistake, ignorance or newbieness: in this event, all that needs to happen is for another editor to correct it. Editors are not expected to be familiar with the manual (it's too big); it exists for articles to adhere to, not editors. As long as one person can stop by and correct it, it's not big deal (that's what a wiki's about). Neonumbers 09:48, 4 January 2007 (UTC)

I've removed the list now, since the few people who commented seemed to approve, and no-one objected. I notice, by the way, that there is some guidance about individual countries in the article calendar date (which the paragraph links to through the redirect page date format). Stephen Turner (Talk) 11:19, 5 January 2007 (UTC)

I have no problems with removing the list, and I especially like the idea of letting WikiProject editors decide how to handle nation-specific dates. Some date formats (such as year-month-day) used in Asia might require special treatment, at least until we find a solution to the date linking/user preferences thing. --Pete 00:40, 6 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)
For instances look here and here. There are a lot of space related articles, but this seems to be the only other field. I think this format fits well here, because space articles use it few times. Marra 18:47, 2 January 2007 (UTC)
Okay. That clears that up, then. I don't think it's necessary to include this explicitly in the manual, but at least we've cleared it all up. Neonumbers 08:55, 5 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 Misplaced Pages: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)
My observation Quoting Misplaced Pages: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, Misplaced Pages 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)

Space between currency symbol and number?

So for most units (which go after the number) we have a clear guideline to use an nbsp space between number and unit. For currency symbols in front of the number, there is no such guideline - and the examples in this manual are not consistent:

...so GB pound and Renminbi both have spaces - but the others don't? Where there is a space, it's not a nbsp space? I can see why we might want a space between GBP/RMB and the number - it looks weird with the GB£ form - and why is it any different than US$ in this regard? When there is a space - should it be an nbsp? I think so - we don't want it split from the number by a newline. Help! SteveBaker 00:40, 3 January 2007 (UTC)

I agree that any space ought to be a nonbreaking space. Past that, I have no opinion. This may be one of those cases where every country on Earth uses a quaint local format. And we are a long way from an international standard currency. -- BBlackmoor • 2007-01-03
Well, then I think I'll 'be bold' and just fix it. I'm going to put:
"Cases such as GB£ which end in a symbol should not be followed by a space and the cases where there is an alphabetic character should be followed by a single, non-breaking space."
SteveBaker 05:58, 4 January 2007 (UTC)
I still think currency should be treated just like any other unit, i.e. suffixed with a space (123 GBP), but I guess even if I got support here, the common English editor would ignore that (logic) convention (because he would not look for it and assume a different one). Christoph Päper 12:04, 10 January 2007 (UTC)

Context (Number in words)

*Within a context or a list, style should be consistent. Example: There were 5 cats, 12 dogs, and 32 birds. or There were five cats, twelve dogs, and thirty-two birds.

Is there a clearer definition of "context"? Something like "He is nth place in RBI (three-digit number) and nth place in stolen bases (two-digit number)" would be confusing because it looks like there are two contexts intertwined (and often viewed as one context). —The preceding unsigned comment was added by Vic226 (talk • contribs) 18:02, 6 January 2007 (UTC).

(Damn, got caught by HagermanBot :( ) Vic226(chat) 18:03, 6 January 2007 (UTC)
I'm not sure it's possible to be definitive about what makes a "context", because it could be very subject-specific. Stephen Turner (Talk) 20:17, 6 January 2007 (UTC)
In that sentence, I would consider the two places in the same context, and each of the numbers in parentheses in their own contexts — but then again, you could apply the "list" one to that sentence, because if you remove everything in parentheses, you'd find that it's sort of a list. Neonumbers 10:07, 7 January 2007 (UTC)

SI (metric) units

Not only does the the Manual of Style recommend SI (metric) units of measure for science-related articles, but also: a Misplaced Pages goal is to present a world-wide view, see:

Globe icon This article or section deals primarily with the United States and does not represent a worldwide view of the subject.
Please improve this article or discuss the issue on the talk page.

Because only Burma, Liberia, and the United States have not adopted the metric system as their official non-voluntary system, it seems appropriate to use the Metric System first (with the US Customary Sytem in parentheses) in most Misplaced Pages articles.

The US did "officially" adopt the metric system in 1975 (see Metrication in the United States). And, in 1988, the United States Omnibus Trade and Competitiveness Act designated the metric system as "the preferred system". But it calls for a voluntary conversion: the 1988 legislation states that the Federal Government has a responsibility to assist industry in voluntarily conversion.

Please edit the project page—reversion isn't particularly helpful.--Lesikar 20:34, 6 January 2007 (UTC)

I've reverted it again. I'm not trying to be unhelpful, and I realise your changes were well-intentioned, but it's conventional not to make changes to the Manual of Style until after they've been discussed and reached consensus, because it affects all the other pages on Misplaced Pages. (I realise that this is contrary to the usual rule of be bold).
There are many factors to weigh up when deciding which units to use, in particular which units the source you got it from used, and which country the article is about. But in any case it seems rather inflammatory to point out in the style guide that only Burma, Liberia and the United States have not adopted the metric system.
Stephen Turner (Talk) 21:07, 6 January 2007 (UTC)
Thank you for the very helpful discussion. I'll wait for further discussion before making any significant changes.--Lesikar 21:42, 6 January 2007 (UTC)
...and thanks for your understanding. Being reverted is never pleasant, so I'm sorry I felt it necessary.
I notice that the guidance does already say "If for some reason the choice of units is arbitrary, choose SI units as the main unit, with other units in parentheses. For subjects dealing with the United States, it might be more appropriate to use U.S. measurements first." So I'm not even sure your latest addition "Consider applying this policy to non-science articles as well" is necessary. Do you feel the existing guideline doesn't cover it well enough?
Stephen Turner (Talk) 22:00, 6 January 2007 (UTC)
It's just that the quote—near the top of Units-of-Measure section—from Scientific Style, "use SI units as the main units in science articles" implies that using SI units as the main units applies only to science articles, and one has to read the rest of the Units-of-Measure section to get the sense that SI units should generally be used as the main units, followed by US units in parentheses.--Lesikar 23:01, 6 January 2007 (UTC)
No, the style guide takes no position on this, and the relevant guidance is already in the section with the appropriate wording that was given far more consideration than you edit warring. —Centrx→talk • 04:30, 7 January 2007 (UTC)

Month and Year only

  • April, 2006
  • April of 2006

Which one should we standardize on? --Richard Arthur Norton (1958- ) 10:45, 8 January 2007 (UTC)

Pardon? What would be the need to standardise on anything here?
Only for page names, arguably, some standardisation *might* (that is if this would be a real problem, as in: matter of dispute) be in order. In which case Misplaced Pages:Naming conventions (numbers and dates) is the relevant guideline, and not this MoS page. Note that May 1968 is an example on that NC guideline page, in this paragraph (I added some bolding):

If a time indicator is used in the title of an article on an event that doesn't recur at regular intervals (or didn't recur at all) there's no "standard format" for the representation of the time indicator, so there is for instance: Crisis of the Third Century; German Crusade, 1096 (one of the developments of the First Crusade); May 1968, etc... The format of the date depends, in these cases, from established practice in history books and the like. In general, however, abbreviations for years or months are avoided (e.g., May '68 → May 1968); for centuries numerals are given in text, capitalised (e.g., Crisis of the 3rd century → Crisis of the Third Century)

So, neither "May, 1968" nor "May of 1968" as page name for the content (but both can be redirects of course). And in all other articles you use what is most appropriate. Which may be "May of 1968" or "May, 1968" as you choose, for example for something that happened in the US, and has no relation to what is described in the May 1968 article. --Francis Schonken 11:08, 8 January 2007 (UTC)
Note also that currently April 2006 is a page name, without April, 2006 nor April of 2006 redirecting to it. Feel free to create these redirects. --Francis Schonken 11:18, 8 January 2007 (UTC)

Oops, and then I also just noticed this in Misplaced Pages:Manual of Style (dates and numbers)#Incorrect date formats:

  • Do not put a comma or the word "of" between a month and year:
    • Incorrect: "December, 1945" and "December of 1945"
    • Correct: "December 1945"

...which seems to make this discussion moot (as far as the current content of the MoS is concerned - or was there an intention to change that?) --Francis Schonken 12:22, 8 January 2007 (UTC)

...ummm, yes, April 2006 is the correct format, and has been for quite some time, and neither month nor year should be linked. Neonumbers 23:44, 8 January 2007 (UTC)

a dot m dot

I think it's a little inflexible to disallow 1pm and 7am. Why insist on dots when the language has undergone a clear shift to removing them in initialisms such as NATO, NASA, and BBC? Only U dot S dot survives, in the US alone, since other English-speakers have lost the dots in that one. Tony 11:10, 8 January 2007 (UTC)

  • NATO, NASA, and BBC are not equivalent comparisons to A.M. and P.M. and neither do NATO, NASA and BBC use them. They use 24-hour time, sometimes like 0700 or 1300, sometimes split by a colon 07:00, 13:00. Most of Europe doesn't use P.M. or A.M. And writing it as 1pm is lazy, sloppy and not acceptable per style guides, writing manuals, etc.. This isn't a metric measurement abbreviation like kilometer, or gram, (which is usually the abbreviation of one word), it's an abbreviation of a Latin phrase. When abbreviating a multi-word phrase (like post meridian or ante meridian, or anno domini, or before christ, or id est, or examplia gratia, or ad majorem dei gloriam) or something that isn't speficially an acronym like NATO or NASA or BBC, it's typical to use periods (they have a name...and that name isn't "dots"). The U.S./USA (as well as U.K./UK) example is not accurate (spots outside the U.S. still commonly use the punctuated form), nor is it a decent comparison. Because it hovers on that acronym/abbreviation boundary and does so chiefly because of the third letter, as in USA. —ExplorerCDT 19:08, 8 January 2007 (UTC)
    • No, you misunderstood what Tony said. We don't use N.A.T.O., N.A.S.A. or B.B.C. anymore - so why would we say 1p.m. and 7a.m.? We say NATO, NASA and BBC - so we should also say 1am and 7pm. (And we do - I've looked at a bazillion articles and I've yet to find one that uses the a.m. and p.m. style. If this policy says that, it's being widely ignored - and correctly so I would say). SteveBaker 19:28, 8 January 2007 (UTC)
      • No I didn't, I understood completely, and explained to Tony the rationale. You're the one with reading comprehension problems NATO is an acronym. p.m. is an abbreviation, not an acronym. I don't use p.m./a.m. I stick to the 24 hour clock that most of the world uses and which renders p.m. and a.m. obsolete. —ExplorerCDT 19:28, 8 January 2007 (UTC)
        • I agree that 24 hour clock notation is clearer - but that's not what a large fraction of the English speaking world uses - so we are stuck with am and pm (or a.m. and p.m.) and we need a policy to allow us to write times like that. (Incidentally, you said that 'period' is preferred over 'dot' - that's only true amongst US English speakers - British English speakers call that character a 'full stop'. Since 'full stop' is a bit of a mouthful, many people (especially computer users) just say 'dot' instead. Notice that people say: "W W W dot Misplaced Pages dot org" rather than "W W W period Misplaced Pages period org" or "W W W full-stop Misplaced Pages full-stop org". I would go so far as to suggest that 'dot' is used when talking about the ASCII character '.' and 'full-stop' or 'period' refers to the use of that character as a punctuation symbol. SteveBaker 19:34, 8 January 2007 (UTC)

The guideline is deliberately inflexible to encourage consistency. For all it's worth, am, a.m., AM, or A.M. could well have been chosen at random; however, I am still of the position that a.m. would be the best option. From what I have seen, none of those four options is any more common than another, and all are equally accurate and understandable. However, for one encyclopedia, one format should be chosen.

The difference between a.m. and an acronym is that acronyms are all in uppercase, thereby making it clear that it is an acronym, whereas the same does not hold for a.m.. I do not see this as comparable to acronyms: I see them as entirely independent situations. "a.m.", in my opinion, looks neater and more obvious that it is an abbreviation of something. ExplorerCDT provided a good (better) explanation (from his fourth sentence onwards).

The Chicago Manual of Style recommends either "a.m." or "AM" (in small caps). For obvious reasons, the latter wouldn't really work here.

In terms of application, I would encourage everyone to try not to think of the manual in terms of "working" or "ignored", but as guideline of good and consistent style that articles will eventually find their way to. The time guideline is the relatively new one, and times are not often encountered in articles (at least, not in my experience), so I would fully understand that most times don't follow it yet. Editors are not obliged to follow the manual of style, and for something uncommon like this I wouldn't expect most editors to even know about it. Neonumbers 23:39, 8 January 2007 (UTC)

  • Also consider that in Latin, it is "ante meridian" (or meridien, meridiem...the "ian" is horribly anglicized Latin) and "post meridian" and should be used in lowercase for chiefly grammatical reasons relating to its case and sentence placement. The subscripted "AM" is probably recommended by Chicago MoS to differentiate it from the typeface of the regular text by which it may be surrounded. —ExplorerCDT 00:08, 9 January 2007 (UTC)
"am" would be the unmarked case, i.e. it looks like a normal word. It has been a long tradition and it is a good choice to use a marked case for abbreviations. Using dots (or whatever you prefer to call them) is one option, uppercasing (or using small caps) is another, combining both is redundant and therefore for a large part is being phased out. Some people prefer to use dots for abbreviations that are (usually) expanded upon reading ("i.e." -> "that is") and all caps otherwise (and then there are those acronyms (e.g. RADAR) that become real words (radar) after a while).
The "U.S." case I could only explain with situations where the unmarked case is all uppercase as often seen in CNN-inspired TV crawls, because there is also another, common English word that would look the same ("us"). Why US-Americans cannot get used to "US" in normal text, I do not understand. It was not possible to convince them over at Talk of the parent of this page the last two times I tried.
We would not have to have this discussion at all if we had stayed with the 24-hours format. Christoph Päper 12:33, 10 January 2007 (UTC)
Yet again, if Misplaced Pages would just standardize on international standard date format (ISO 8601), this would not even be an issue. -- BBlackmoor • 2007-01-11 21:43Z
  • Explorer, I wasn't expecting to be called "lazy" and "sloppy", nor to see someone else accused of having a reading problem. They're acronyms only if they can be said as a word in their own right, such as "NATO"; they're initialisms if not, such as "PBS". AM and PM are initialisms whether we like it or not. Yes, e.g., needs the dots, still, I'm advised by professional editors, despite what plain English proponents say. I think that this issue is unresolved, and that the neatest solution is to be inclusive and allow WPs to use upper or lower case, dots or no dots, as they choose—just as for the free policy on the use of spelling dialects. Consistency within an article is, of course, the important issue. Tony 01:12, 12 January 2007 (UTC)
I still hold that we should advise one specific format for the entire encyclopedia (i.e. one for 12-hour, and another for 24-hour). Consistency across the encyclopedia is best.
I hope that people will be willing—especially on a minor issue like this—to abandon their personal preferences and agree to stick to one format, whatever the format will be. Yes, I meant the "personal" part — even if you can explain your personal preference logically (and I know we all can), if we take a step back and think about it, all the formats can work.
Some, in our respective opinions, will work better than others. For example, I am of the opinion that "a.m." works best. But this does not mean "am" doesn't work at all. I've seen all four formats (AM, A.M.) and understood them all. But it is far more beneficial for us to stick to one format—any format—in the interests of making Misplaced Pages one, coherent, professional encyclopedia.
Before anyone brings up instruction creep, this isn't intended to make people use one format, it's intended to get articles consistent. All that matters is that changes to make it that format are respected (and editors that want to know which one can come here and find out—those that don't needn't worry). To say "use any" defeats the purpose of this so-called "guidance". Neonumbers 04:27, 12 January 2007 (UTC)
You have nailed the problem of many of the so-called guidances in this Manual of Style. They are too loose. Christoph Päper 14:02, 12 January 2007 (UTC)
I don't see the benefit of rigid standardation on such a trifling detail. There are plenty of things in Misplaced Pages that are inconsistent, starting with the article prose and on through the category system, use of BE/AmE, and through just about everything else. That is pretty much what makes the encyclopedia work; rigid standardization improves nothing and harms much, and I for one don't plan to follow the people on this crusade. --Delirium 09:24, 20 January 2007 (UTC)
I fail to see how any article can be harmed by having it's a.m./p.m. style changed. Certainly a substaintial number of the articles that I edited some time ago when I brought them all into alignment, used a mixture, which was not good. The only downside is we may be giving (by a combination of all the stlyle editing) an air of a level professionalism which the content falls short of. Rich Farmbrough, 14:33 23 January 2007 (GMT).

Date ranges

What about date ranges? I ran into 14-15 May 1994. Either May 14-15, 1994 nor 14-15 May 1994 won't work for user with different preferance. Is this addressed? Thank you.--Pethr 03:09, 12 January 2007 (UTC)

It's brought up on this talk page from time to time. You certainly need the month in both dates as you've discovered, but if I recall correctly, I think the only format which works for all date preferences is to include not only the month but also the year in both dates, i.e., ] ] – ] ] or equivalent.
Do people think we should make a guideline about this? It seems to be something of a FAQ.
Stephen Turner (Talk) 09:37, 12 January 2007 (UTC)
Yep, that seems to be worth it. Would it work without the first mention of the year? It'd be fine by me. Neonumbers 11:40, 12 January 2007 (UTC)
I think it doesn't work for the few people who've chosen ISO 8601 dates. They would see 14 May – 1994-05-15. Stephen Turner (Talk) 12:23, 12 January 2007 (UTC)
And people who've chosen the year-first format "1994 May 15" have the same problem: "14 May - 1994 May 15". Stephen Turner (Talk) 12:25, 12 January 2007 (UTC)
Would it be possible to create template for such things? f.e. {{dr|94-05-16|94-05-17}}. Would it be possible to program it to include different user settings and different types of ranges? It doesn't look good to have in the text May 16, 1994–May 17 1994, does it? It even spoils the meaning since such a long range looks rather like different years not two days. Thank you.--Pethr 01:34, 13 January 2007 (UTC)
I rather foolishly hinted at this problem with the proposed alternative syntax for dates. But the above summary is correct, although I think that adding the month is a good compromise. (How many people havbe ISO set (I know I have had) ? Rich Farmbrough, 14:35 23 January 2007 (GMT).

Year linking and delinking

I am posting here as I have just finished an attempt to mediate between two users who were falling out over their strong and opposed positions on whether (some, or all) standalone years should be linked.

I thought the edited highlights of the discussion we had there might be interesting to readers of this page, and so I append them below. I'd like to think that, especially if we are eventually able to remove the necessity to link dates for them to follow users' date preferences, this could allow us to reduce the amount of overlinking currently present in many articles, clarify the current "wooly" MoS guideline, and thus avoid future friction over this.

Specifically, I propose Quadell's remedy (see table below) as a new guideline for linking years. I'd also suggest something along the lines of "If in doubt, don't link" as many, many of these year articles do not provide any useful context and, it seems to me, never can. Anyway, please read it and see what you think. The original text this was condensed from is at User:Guinnog/date linking and User talk:Guinnog/date linking.

--Guinnog 03:42, 12 January 2007 (UTC)

(copied text begins) This page is an attempt to resolve the dispute about the linking of year articles. Perhaps it could serve as a step towards a more general agreement though. Once this dispute is resolved I will paste it into Misplaced Pages talk:Manual of Style (dates and numbers).

Background

At present we have got:

"Partial dates

If the date does not contain both a month and a day, date preferences do not apply: linking or not linking the date will make no difference to the text that the reader sees. So when considering whether such a date should be linked or not, editors should take into account the usual considerations about links, including the recommendations of Misplaced Pages:Only make links that are relevant to the context. ...

... There is less agreement about links to years. Some editors believe that links to years are generally useful to establish context for the article. Others believe that links to years are rarely useful to the reader and reduce the readability of the text. Another possibility is to link to a more specific article about that year, for example ], although some people find this unintuitive because the link leads to an unexpected destination."

(Misplaced Pages:Manual of Style (dates and numbers)).

While I think I understand why this compromise version was adopted, I also think the ambiguity leads to some unfortunate friction between users who think all year links, or almost all, should be delinked, and those who regard this as a loss of utility in articles.

Declaration of my own POV

I tend to side more with the delinkers than with the linkers. I find that the majority, even a vast majority of year links are adding little or nothing. I can see the merit of the other side's opinion too, and I promise to try my best to mediate here without regard to my own POV. For interest, here is a recent copyedit I made which includes date delinking: . Guinnog 04:23, 3 November 2006 (UTC)

Framework

Never link / Can be delinked on sight Seldom link / Usually delink Usually link / Sometimes delink Always link / Never delink User Comment
Multiple repetitions of the same linked year within a page, especially in lists. Links where the article linked to would in my judgement clearly add no context to the subject of the article. Recent links, say roughly from 1900 - 2006. "Easter egg links" like ]. Rather use: (See also 1933 in aviation) 1800 - 1899 dates prior to 1800 Guinnog (before) These are just my own interpretations; I stress I always discuss link removal on the odd occasion someone challenges it. I obviously try to judge each case on its merits.
Standalone year or year-month links where, in my judgement, they add no context. I rarely see any such value, just confusion as the reader is confronted with a sea of blue years: what is of value to them? What not? N/A N/A Year links in century articles Hmains As far as I know, this is the editing I am supposed to be doing as a WP editor. However, I also do not like the loose guidelines and the trouble they cause and said so when they were being discussed; however, in the interest of 'consensus', the guidelines, as written, were accepted.
I think this is inherently a judgement call. If someone thinks it is useful, keep it. If someone doesn't, remove it. Just don't get in the habit of spending all ones time doing either one or the other. Generally, I don't mind if people cut recent links (say, last twenty years). I disagree with Guinnog about setting a cutoff about 1900 - most of the most useful links, I would argue, are those for historical articles during the 20th century, where providing a broader geopolitical context is often really quite relevant. Again, I think this is inherently a judgement call. There are many cases where links in the time periods both Guinnog and I mention where date links may be relevant, but there also many where they may not. I don't think setting specified dates is particularly helpful, though I do think there's much less likely to be an issue with removing date links in the last couple of decades. As above. Rebecca I think this really is a matter of both having respect for other points of view and using a bit of discretion. Setting hard and fast rules inevitably leaves useless date links in and leads to the removal of perfectly useful ones.
Multiple repetitions of the same linked year within a page. Any year link, except in special circumstances. "Easter egg links" like ]. Rather use: (See also 1933 in aviation) Century links (most cases) Year and/or century links that are critical to the understanding of the article Guinnog (after) I have learned a lot from this study and thought it would be interesting to summarise that in this table.
Multiple repetitions of the same linked year within a page. "Easter egg links". Years mentioned in an article, where the event is important, but not the year itself. E.g., the year an album was released in an article not about the album. Any year links important enough to the article that it would be appropriate to use them in the main (summary) section, e.g. the founding year for an empire in that empire's article, or the year a swimmer won the Olympics in an article about the swimmer. Birth and death years, or years in century articles. Quadell


Links removed by both

  • Repeated links, especially close together in article. NB that medieval is a redirect to Middle Ages, and that eg 1400s is often misused in place of 15th century. Whether linked or unlinked, this is a serious error and should be checked and corrected wherever seen. Note also that forms like "twelfth-century" and 1980's (for the decade) are considered wrong and should be corrected, and that 1990s is not a link to the decade but to the single year.
  • Recent links are seen as low-value by all three of us. I thought roughly the last 100 years, Rebecca is more conservative and says the last 20 years. Obviously both of us would use an element of discretion here when delinking.
  • Easter-egg links of the type ] are deprecated.

Links removed by Hmains but retained by Rebecca

(in order of appearance in the article)

  • 15th century; some good background about the historical era.
  • 6th century BC; much less useful
  • 1st century; another fairly poor article. Peripheral interest only.
  • 3rd; thin article but contained one interesting fact slightly relevant to article
  • 7th; peripheral interest only.
  • 240 BC; one interesting fact; but this article is tiny. Little benefit.
  • 1st century BC; thin article but contained one interesting fact slightly relevant to article
  • 12th century; a slightly better article. One or two interesting facts. Some interest.

*1st century (second instance, but well down a long article from the first)

  • second century; another thin article. One slightly relevant fact.
  • 4th century; nothing here of any relevance to the article at all.
  • 5th century; peripheral interest only.
  • 354; article hardly exists. Nothing whatsoever here.
  • 430; Small article. Couple of peripherally relevant facts.
  • 245; Small article. One peripherally relevant fact.
  • 325; article hardly exists. Nothing whatsoever here.
  • 315 Little more than a stub. No interest here.
  • 386; peripheral interest only.
  • 344 Little more than a stub. No interest here.
  • 408; peripheral interest only.
  • 394; peripheral interest only.

*408 (second instance)

  • 547; stub (unmarked). No utility at all.
  • 329; stub (unmarked). No utility at all.
  • 379 Better article. Still peripheral interest only.
  • 9th century Decent article. Good historical context.
  • 560; peripheral interest only.
  • 636 Stub-class. Nothing, or very little that was pertinent

*12th century (second instance, in image caption)

*9th century (second instance)

  • 672 Little here. We did get the birth of Bede, slightly relevant.
  • 735 Sub-stub article. Bede's death.
  • 700; peripheral interest only.
  • 784 Sub-stub article. Nothing here at all
  • thirteenth century Decent article. Some good context.
  • eighth century Less good, but some peripheral interest.
  • 1550 Some minimal peripheral interest

*13th century (second instance)

  • 11th century Decent article. Good historical context.
  • 1070 Stub. Little or nothing of relevance here.
  • 12th century Decent article. Good historical context.
  • 1013 Barely above a stub. No interest.
  • 1054 Mention of SN 1054 supernova slightly interesting and of peripheral relevance.
  • 1225 Birth of Thomas Aquinas. Very peripheral relevance.
  • 1274 Less poor article. Little of relevance though.

*13th century (third instance)

  • 1400 Little here of interest. Less poor than some of the earlier year articles. Peripheral interest only.
  • 1120 Stub article. One very interesting and relevant fact. Unfortunately Welcher of Malvern is a redlink. Could be improved though.
  • 15th century Good historical context.
  • 1828 Nothing much here. Peripheral interest for those who like random facts.
  • 19th century Very respectable article. Good historical context.
  • 16th century Reasonable article. One very relevant reference.
  • 1888 Nothing much here. Peripheral interest for those who like random facts.
  • 1898 Nothing much here. Peripheral interest for those who like random facts.
  • 1830 Nothing of relevance.
  • 1896 Some minimal historical context.
  • 1816 One interesting fact.
  • 1885 Some minimal historical context.

In chronological order, by type

Century or year Grade for article quality
(1=high, 5= low)
(=x) 		Grade for relevance to Flat Earth
(=y) 		Grade for utility
(=x*y) 		Comment
6th century BC 3 2 6 Decent article, provides some historical context to when Pythagoras lived
1st century BC 4 4 16 Little here
1st century 4 4 16 Little here
2nd century 4 4 16 Little here
3rd century 4 4 16 Little here
4th century 4 4 16 Little here
5th century 4 4 16 Very thin indeed. Nice map.
7th century 4 4 16 Minimal article, minimal interest
8th century 4 4 16
9th century 3 3 9 Better article
11th century 3 3 9
12th century 4 4 16 Back to an article which is a formless list; hard to see any relevance
13th century 4 4 16
15th century 4 4 16
16th century 3 4 12 Longer article but still a sequence of lists.
19th century 2 3 6 Very interesting article; lots of peripheral historical articles to browse to, if you were finished reading the original article.
240 BC 5 3 15 Stub article
245 5 4 20 Even less, and less of interest
315 5 3 15
325 5 4 20
329 5 4 20
344 5 5 25 Nothing here
354 5 4 20
379 5 5 25
386 5 4 20
394 5 3 15
408 5 4 20
430 5 4 20
480 5 5 25
524 5 5 25
547 5 5 25
560 4 5 20
636 5 5 25
672 5 4 20
700 4 4 16
735 5 4 20 Year identifies the death of Bede, but article is so poor it provides only two other links, plus the turgid List of state leaders in 735 as context.
784 5 5 25
1013 4 4 16
1054 4 4 16
1070 4 4 16
1120 4 4 16
1225 4 5 20
1274 3 3 9
1400 4 4 16
1550 3 3 9
1816 2 2 4
1828 3 3 9
1830 2 3 6
1885 2 3 6
1888 2 3 6
1896 2 3 6
1898 2 2 4

Analysis (preliminary)

I will have more to say on this. For now, let me explain what I have just done. I tried to put myself into the role of a reasonably intelligent but non-expert person reading the article on Flat Earth (the subject of the test piece). If we can take as read that the repeated, easter egg and very recent year links are regarded by both editors (and by me) as low-value links, it is interesting to click on each of the links that Hmains would have deleted and Rebecca would not, with a view to finding what information if any related to, or even gave meaningful context to, the events described in the article.

Some rather surprising (at least to me) things came up. The century articles seem more valuable for providing historical context than the individual year links for the earlier periods. Many of these early individual year links are so poor in my opinion as not to be worth linking to at all at present. It is also rather hard for me to see how they could ever plausibly be significantly improved. Look at 735 for example.

If you review the links in question, it is hard to avoid the conclusion that many of the year links added nothing at all in terms of direct relevance to the article. I do recognise there are some Misplaced Pages users who will value the semirandom possibility in, say, clicking on 1885 and thus navigating from Flat Earth to LaMarcus Adna Thompson, the roller-coaster pioneer. I had not been aware though that many of the early year articles are so poor as not to give any real possibility for this activity. I'll think about it some more and try to take this onward this evening. For now, anybody else want to comment? --Guinnog 13:02, 6 November 2006 (UTC)

Well, I've made a table with the links that Hmains would have deleted and Rebecca would have kept (notionally) in chronological order. For my next trick, I'm going to grade each of the articles (which I've linked from the data table; you were right, Lonewolf BC, thank you). I've chosen to grade each article separately for article quality and relevance, from which I'll make up a utility score by multiplying the two. Like everything else here it might seem arbitrary, but I think it is fair. In the wiki spirit, I'll only do them one or two at a time, and will be happy if anyone else wants to join in. We should, especially if Rebecca and Hmains (and potentially other people) will take part, end up with a very interesting dataset, showing what links are better than others, for this randomly chosen article. I'd still like anyone taking part not to edit the original article though. I'll start by grading a couple tonight, and then leave it to see if anyone else will have a go. Enjoy, and remember we are evaluating the links not on principle, but from the point of view of being valuable to a hypothetical person doing research for a project, say. --Guinnog 23:24, 6 November 2006 (UTC)

Desired outcome

I thought this might be a good place to consider what we want from this, beyond a resolution of the immediate dispute between these two respected editors. It has become obvious that the existing policy is flawed by its well-meaning ambiguity. I'd like to propose that we aim to come up with a list of examples along the model of the table I made up; something like Always link, Usually link, Seldom link and Never link. I would stress that the criteria I used myself, which largely depended on the period of the date being linked to, were only my own ones, and need not be seen as a model for whatever we will end up with. I hope that the exercise I have asked Hmains and Rebecca to do may allow us to discuss towards establishing such principles. Any comments would be most welcome. --Guinnog 13:25, 5 November 2006 (UTC)

A resolution of the immediate conflict would be good. An improvement of the guidelines to prevent recurrence and improve clarity would be even better. Support your efforts. ++Lar: t/c 22:38, 6 November 2006 (UTC)

Preliminary conclusions

1. I came at this as a modest date delinker ("I find that the majority, even a vast majority of year links are adding little or nothing") but with the idea that "dates prior to 1800" should be linked or left linked, while more modern ones were superfluous.

a) I could see some merit in what Hmains was doing; systematically removing all partial date links in articles he edited, per his understanding of what the MoS allowed. I could also see the annoyance of Rebecca at what she saw as mechanistic edits, against her understanding of what the MoS allowed.

b} It seems obvious that a lot of the problem lies with the ambiguity of the present MoS; I know that has been controversial but the compromise we have ended up with is a fudge that leaves us open to the kind of misunderstanding that happened here.

2a) Overall, I think the results favour the idea that I came into this with, that most year links are pretty worthless. However, I will now look differently on which year and century articles are and aren't worth linking. The 19th century one is rather good for instance. I know that many of the 20th century year articles (that we ruled out in this study) are fairly informative.

b) I know now that many of the year articles from early years are so poor as not to be worth linking to, ever. Furthermore I see no realistic way they can ever be improved. I saw no article for a year before 1000 that was more than stub-quality. I will certainly be much less inclined to leave links to articles like 735 in place than I was before doing this. Even many of the more recent ones are poor in terms of adding understanding. You have to get into the 19th century before the articles get quite informative and well-written. Even then, few of them added real core meaning; it was more of a serendipitous sort of "what else happened that year" ability that became more real as the articles got (modestly) better through the years. (This is the opposite of what I believed before this exercise).

c) The century articles are better than the years. Even so, some quite late ones are remarkably poor (15th century for example). This could be an opportunity to improve these articles; a much more realistic aspiration than fixing up the early year articles, in my view. Meantime, I would still only link to century articles in exceptional cases where it would provide a useful perspective. I would change my view somewhat if the century articles were improved.

3. While there might seem to be nothing wrong with Hmains' edits in removing these (very often worthless) links, I understand the annoyance of editors like Rebecca at what they see as an unauthorised bot-like bulk edit.

a) Although I have no more authority than anyone else to tell Hmains and Rebecca how to act, having thought about it a great deal, I suggest the following compromise might offer a way forward:

b) Hmains should refrain from using automated or semiautomated methods for unlinking dates (pending the clarification to the MoS I propose below). All linking or delinking done should be justifiable; for each and every link added or removed a rationale should be possible and be provided on demand, and the rationale should take into account the value of the date article linked or delinked to the main article being edited.

c) Rebecca should refrain from mass-reverting Hmains' edits; if she perceives a problem with an individual edit, she should merely ask Hmains nicely and he should provide his rationale, as noted above.

d) Neither party should revert-war or be anything but civil with each other. Any problems should be referred to me in the first instance.

4. Finally, if there is no objection, an edited version of this should be copied to the relevant MoS talk page, in case it can help progress formulation of a better policy. --Guinnog 08:02, 8 December 2006 (UTC) (copied text ends)

Suggested change to MoS

I propose where we currently have: "There is consensus among editors that bare month and day names should not be linked unless there is a specific reason that the link will help the reader to understand the article. There is less agreement about links to years. Some editors believe that links to years are generally useful to establish context for the article. Others believe that links to years are rarely useful to the reader and reduce the readability of the text."

We substitute:

"Bare month and day names should not be linked unless there is a specific reason that the link will help the reader to understand the article. Links to years on their own are often deprecated as adding little value to articles, but consideration should be given to including year links which add value to the article. If the year link adds little, a century link may be more useful. (Years in century articles, by convention, are always linked.)

In deciding whether or not to include any link, the principle of Misplaced Pages:Only make links that are relevant to the context should be followed, and the value, quality and relevance of an individual year article being linked to should be considered. The use of linking merely to emphasise important dates should be avoided.

Mass edits which solely remove (or add) date links across many articles are discouraged, as with any mass minor edits (see for example 'Avoid making insignificant minor edits ... because it wastes resources and clogs up watch lists.'(Misplaced Pages:AutoWikiBrowser)), and especially because different editors will make different judgements about the value of different links.

Easter-egg links of the type ] are deprecated. Instead use a transparent form like (see also 2006 in sports), where that article has relevant information to the article."

--Guinnog 03:59, 18 January 2007 (UTC)

Comments

There is no consensus for that particular guideline, as per the discussion-to-death of this issue in 2006. There is no consensus that "links to years on their own are normally deprecated as adding little value to articles". The present language is fine: date links should be treated accordingly to Misplaced Pages:Only make links that are relevant to the context, with people actually using some common sense, thought and discretion. Rebecca 08:48, 12 January 2007 (UTC)
Sure. I couldn't ever be against common sense, thought and discretion. I just think it would be clearer if we could use some of what we found out in our exercise about the very low value of many of these links. It was an eye-opener for me. On the other hand, I like the idea of naming places where year articles should be linked. I certainly think the vagueness of our current wording is unsatisfactory to all and a recipe for possible further conflict. --Guinnog 08:53, 12 January 2007 (UTC)
The reason the language is vague is because there isn't a consensus for any stronger language. Yes, it's a recipe for occasional conflict. When we had stronger guidance here it was the recipe for a lot more conflict though. Stephen Turner (Talk) 09:43, 12 January 2007 (UTC)

I really dislike reading articles with a sea of blue dates. It's almost never useful to click on the date number and the blue links are distracting. However, I can see a value in such links from a point of view of information content. It is very useful indeed to be able to go to a page about a particular year and find all of the pages that link to it in order to automatically find all of the things that happened in that year. So what is truly needed is not links from years but categories for each century, for each year and perhaps even each month and day within each year. Some people have already started doing this - I see Category:1959 introductions for new products released in 1959. So if we are considering changing the standard, I think we'd be better off having some kind of year template that spits out the year (unlinked) into the text of the article - yet adds a category reference for that year.

As for the 'preferences' thing of rendering dates in alternative styles - that leaves me cold. Linking dates as a way to make the MediaWiki recognise them as such is an ugly mechanism. If we must do that, there should be some other kind of markup that doesn't result in an ugly link. However, providing the month name is spelled out in letters (ie not as a number), there is really no ambiguity and readers who may prefer "10th January 2007" are unlikely to be confused by "Jan 10th 2007". On the other hand, we must strongly deprecate using month numbers because "01/10/07" is utterly ambiguous. To an American, it means "Jan 10th 2007", to a Brit, it mean "August 1st 2007" and to a Dutch reader, it would mean "2001 August 7th". If we would only require the use of month names ("Aug" or "August", not "10"), I think we could simply dump the user-preference date presentation. After wall, we don't have user-preferences for regional spelling ("tyre" vs "tire", "colour" vs "color", etc) - or word choice ("lorry" instead of "(big) truck", "ute" versus "(pickup) truck") - and that can be much more disturbing for the reader! We aren't trying to fix "rubber" (meaning "condom" to Americans and "pencil eraser" to a Brit) or "Durex" (being a brand of condom to a Brit or a brand of adhesive tape to an Assie). Compared to the potential for confusion there, the date issue is very, very minor indeed! SteveBaker 14:43, 12 January 2007 (UTC)

As for the date delinking preference guideline, ditching it would be a bad idea because a) this prompted some massive edit wars over personal preferences in its time, which I don't really want to see a repeat of, and b) there is a current bug request to remove the reliance on links for this function to work. Rebecca 23:06, 12 January 2007 (UTC)
I think it will be good if we can get a method of applying date preference that doesn't depend on linking dates, which is why I supported the proposal above. In the meantime I think our policy should explicitly refer to the utility of links to readers, and give a little less leeway for personal preference as that is where I see a lot of the trouble arising from. Alongside that I think we need to underline the general advice against making minor edits in a mechanistic (ie automated or indistinguishable therefrom) manner. If we can find a way of putting something to that effect of these two points into the MoS, I think we will help a lot of people, both editors (who'll have a clearer idea of when and how year links should be linked and delinked), and readers (many of whom express a preference for less overlinking on grounds of readability). --Guinnog 23:17, 12 January 2007 (UTC)

I think if we can reduce conflation of linking and formatting, per the proposal above, it would be good, because then we could discuss when dates actually ought to be linked. Based on the analysis, and on my own gut feeling, my view is most of the time they ought not to be linked. I think a case needs to be explicitly makeable to link them, and that by default they ought not to be. I'd support a change to the MoS that moved in that direction. How did I arrive at that conclusion? At least in part thanks to Guinnog's thorough analysis, above. ++Lar: t/c 05:33, 13 January 2007 (UTC)

I created a stub article today and for some odd reason, I linked the Month/Date and then the year...which is something I rarely have done in the past. I look at the stub now and see little improvement by linking to the dates actions mentioned in the article may have occurred. The cite templates also do this, linking to year/month/date and I can't see what the purpose of this is either. Articles that are discussed in the year articles or date articles might be benefited by themselves linking to those dates, but I can't see how any improvement is gained by having this be part of MoS.--MONGO 05:42, 13 January 2007 (UTC)

You've misunderstood the purpose of the guideline. It's not because the links are useful, it's to make readers' date preferences work. Hopefully these two functions will be separated in the near future. Stephen Turner (Talk) 10:04, 13 January 2007 (UTC)
As Jack Harkness said "Everything changes in the twenty first century." Rich Farmbrough, 18:03 13 January 2007 (GMT).

Guinnog, I see you keep refining the proposal, but I still haven't seen any sign that it's going to gain any consensus. Stephen Turner (Talk) 11:05, 15 January 2007 (UTC)

Really? That's funny, I see mostly supportive comments here, apart from your own. Once the proposal is refined sufficiently (and I think it is almost there), I'll see about a straw poll. Meanwhile, do you have any constructive suggestions to make? --Guinnog 11:41, 15 January 2007 (UTC)
These "mostly supportive" comments consist of two for and two against. We discussed this to absolute death last year, featuring somewhere in the vicinity of twenty or thirty editors in total, and the current wording emerged as a compromise acceptable to nearly everybody. Unfortunately, you seem to have appointed yourself as some sort of self-appointed arbiter of this dispute, and seem hell-bent on reigniting it. Thankfully, that's not how this place works, and you'll have to actually get consensus for your changes just like everyone else. Rebecca 11:53, 15 January 2007 (UTC)
As to "constructive" suggestions, the current version reflects that there really is no consensus on all of these issues, and reflects the ability for people to use their own discretion. Your version destroys this compromise, replacing this with "feel free to kill them all, but maybe keep about thinking the occasional one". This is your own personal opinion, and in no way can be seen to reflect any sort of consensus. Really, I've had enough of people trying to assert their own style preferences on everyone else, other people be damned, and having to fight the same battle every six months when some new intolerant jerk decides that his way *must* be imposed on everyone else. Rebecca 11:57, 15 January 2007 (UTC)
And let me get this right, Rebecca: you're not asserting your own preferences as to how to deal with this unfortunate scenario ... Tony 12:27, 15 January 2007 (UTC)
No, I'm not. I'm saying "use your discretion, within reason". This allows room for a variety of interpretations, from mine through to a bunch of people who are not fond of date links (Quadell being one example, but there are quite a few others I've seen around and have no objection to), as long as they don't systematically strip them everywhere. Guinnog is saying "delink in virtually all cases", which allows room for only his particular preference. Rebecca 12:57, 15 January 2007 (UTC)
Let's try and keep it civil please. I think I have the right to make the proposal I have made; it would be great if we could restrict comments here to constructive suggestions with a view to improving the vagueness of the policy. Clearly we all have different preferences and it is very much "how this place works" for us to discuss clarifying the guideline. --Guinnog 12:43, 15 January 2007 (UTC)
I'm sorry, but this is the arrogance I object to. You've made the basic assumption that what you've put down must be superior to what is there and that this is the basis we should work from. The current version exists because it was something that basically everyone could agree on (it is for precisely for this reason that it *is* vague, and for everyone except you and Hmains, this has not proved to be a problem); yours is purely a matter of trying to slam your opinion through regardless. Rebecca 12:57, 15 January 2007 (UTC)
Sorry Guinnog, doesn't seem very likely that this proposal is going to gather a broader consensus than the previous one. --Francis Schonken 12:36, 15 January 2007 (UTC)
Well, that's if you give Rebecca's clawing and scratching any weight. She's only one voice, let's remember, not 10. Tony 13:29, 15 January 2007 (UTC)
As are you. Three and three still does not make a consensus in your favour. Rebecca 13:33, 15 January 2007 (UTC)

Guys. This is a perennial problem, in my view, and it may need more worrying at to resolve neatly. Last year's compromise may have helped, but that doesn't mean that trying to get a proposal that is crisper and that does have consensus isn't worth pursueing. I do not in any way see Guinnog as being arrogant! Rather I see him trying to take on an rather difficult and contentious topic at considerable personal cost, for the betterment of the wiki, and if the consensus is not in favour of moving in a particular direction, so be it. Terms like "slam your opinion through regardless", and "Rebecca's clawing and scratching any weight" might not be quite as helpful as they could be, don't you think? Let's work together collegially if we can. ++Lar: t/c 13:53, 15 January 2007 (UTC)

The central problem here is that this isn't "crisper"; it takes a compromise that was neutral and replaces it with one that is very decidedly biased towards one side, which the author happens to belong to. As I just stated on Guinnog's talk page, there are a bunch of opinions here which simply can't be reconciled into a "this is exactly what you must do" sort of guideline. We can either respect that difference, as the present version does, or try to ride straight over it and replace it with the personal preferences of a small group, as Guinnog's does. Rebecca 14:04, 15 January 2007 (UTC)

My view is that the elimination of YEAR in X|YEAR links would be a mistake. If you liken Misplaced Pages to a print encyclopedia, the YEAR articles are like the yearbooks--here's everything that happened in 1982. Referring someone to the entire book is not particularly helpful--much more helpful would be pointing them to a particular chapter of the yearbook where they are most likely to find the context they are looking for. If the user wants a broader context, it will always be easy to find 1982 from 1982 in table tennis, but the reverse is often not true.

The suggestion sometimes made that YEAR in X links should be replaced with parenthetical (See YEAR in X) statements strikes me as contrary to the spirit of Misplaced Pages, where links are supposed to be unobstrusive and expendable. Nareek 19:05, 15 January 2007 (UTC)

Hmm, well that's already the guidance at WP:PIPE I think. Unless you hover over a piped link like that, you have no way of knowing that it points to a more useful link than the catchall year article. Also, using the format ] ] breaks the date formatting we currently have. I'm not against linking these often very informative articles but at the moment we have the worst of both worlds when folk are using them as easter egg links. I thought that was the least controversial bit of what I was proposing! --Guinnog 20:55, 15 January 2007 (UTC)

Guinnog said:

Easter-egg links of the type ] are deprecated.<!-- The last sentence is also at WP:PIPE, so if it's changed here it should be changed there too -->

I don't see that at WP:PIPE; instead, I find:

There is disagreement about whether it is appropriate to pipe year numbers to "year-in-x" articles (such as ]).

Am I looking in the wrong place? Nareek 07:26, 18 January 2007 (UTC)

I don't think so, although the phraseing has changed. Project Albums uses the format "1999 (see 1999 in music)", and as Guinnog remarked we should avoid "12 May ]" if we want to respect peoples ISO preferences. I am of the opionion that generally the second level generic year articles are unhelpful, where soemthing with a wider temporal spread and a closer subject spread might give context, say, "interwars British comedy" or "1980s Australian Tennis". To some extent this is also the purpose of "Navboxes". Rich Farmbrough, 13:23 21 January 2007 (GMT).

Converting to SI prefixes

I'm presently dealing with a new user whose sole contribution to the encyclopedia has been to push SI prefixes into a variety of Macintosh hardware articles. And by "dealing with", I mean, reverting all their changes.

There's a serious problem here with the stated MOS guideline: It contravenes both WP:NPOV and WP:V. In essence, SI prefixes are meant to solve an ambiguity issue between "powers of 2" and "multiples of 10". This decision was made by a task force a few years ago, and was adopted by various organisations and communities as a result. The problem is that most major manufacturers of hardware and software, as well as most publications and news sources, have not adopted this naming for whatever reason. I don't necessarily agree with it, but that's their collective perogative.

So what's an encycopedia to do? The answer seems clear enough: our core policies revolve around a neutral presentation of our sources, which means it behooves us to use MB, GB, etc. when our sources use those prefixes. Wikipedians should absolutely not take it upon themselves to state numbers differently from how our verifiable, reliables sources do. Arguments along the lines of "But Apple does it wrong!" don't wash either, since that's a matter of personal opinion. Using SI prefixes to describe consumer hardware is nothing more than a minority viewpoint at this point. Personally, I'd like to see these prefixes be adopted more widely so as to solve this ambiguity, but Misplaced Pages isn't the place to champion that agenda. We report on what others say, and that's it... policies always override MOS guidelines. -/- Warren 22:31, 21 January 2007 (UTC)

I'm afraid I disagree-we need not always report sources verbatim. Apple may call their new laptop "the best thing to happen to graphics designers since Photoshop", but that doesn't mean we've got to put that verbatim in any article which mentions it! Similarly, KiB/MiB/GiB are the correct ways to represent binary values. The prefix "kilo" means "one thousand". That is not a matter of opinion, any more than it's a "matter of opinion" to say that three is a quantity one greater than two and one less than four. That is not my opinion, that's what the word means. Similarly, if a source is using imprecise and inaccurate terminology, especially when their terminology is intended to appeal to a mass audience, we need not repeat it exactly-in our context, so long as the meaning is clear, we can certainly use better, more precise terminology. In this case, it is indisputably clear that the numbers referred to are binary values. In this case, the use of XiB prefixes are correct, and the use of XB prefixes are incorrect-we're not referring to the numbers that "kilo", "mega", and the like refer to! That is not an opinion, it is verifiably and provably true. Seraphimblade 00:54, 22 January 2007 (UTC)
You're advocating silently correcting our sources for them when they're wrong, then? Ehhhh, something seems really wrong with that. I'd rather let articles on megabyte etc. explain the issue (per WP:NPOV and Jimbo's own assessment that minority viewpoints should be in ancilliary articles -- YES, the "correct" measurement is a matter of opinion)... or specifically disclaim the conversion on pages where we use it. We don't generally use metric measurements on articles on American subjects, do we? Nobody would advocate switching from miles to kilometers in those Misplaced Pages just because NIST said so, would they? The answer is no -- we tend to choose what to present based on common usage in the article's domain space, not based on what governments and standards organisations (or advocates thereof) say we should use. -/- Warren 01:21, 22 January 2007 (UTC)
However, here, we're dealing with a layman's term which is commonly used, but is also factually and provably incorrect. Whether to say "one inch" or "2.54 centimeters" is indeed a matter of opinion-either one is correct. However, if one of our sources was incorrectly using a conversion factor of 1 inch = 3.54 centimeters, they are wrong. It's not my opinion, in that case, that they're wrong. They're wrong. I would agree when directly quoting, we certainly should not change a direct quote (though we probably should tag it with (sic) where the incorrect terminology appears). But when paraphrasing, yes, we should put an obviously-incorrect layman's term into the correct technical term. The prefix kilo means 1000. That is a fact. "Kilobyte" means 1000 bytes, just like "kilometer" means 1000 meters and "kilogram" means 1000 gram. That's just what the prefix means. If a source uses "kilometer" to refer to a distance which is actually 1024 meters, they're wrong. If a source uses "kilobyte" to refer to 1024 bytes, they're wrong. That's not a matter of opinion. They may have figured it for "close enough", in what they were doing, but we should be as precise as possible. Especially up into the MiB/GiB ranges, there is a significant variance between the base 10 and binary prefixes, and what kind of number they indicate. This is not a matter of opinion, however. Either there's 1000 bytes, or there's 1024. In the cases we're talking about here, there are 1024. KiB properly represents that. KB does not. That's not my opinion, or anyone's. Words have meanings, and so do prefixes. K means 1000. Ki means 1024.
I suppose our other option would be to simply eschew prefixes and report all values in bytes, but that would get cumbersome, to say the least. However, just because most computer manufacturers would rather settle for "close enough" and allow error doesn't mean we need to, or should. That is not a "rewording" of what the source said, any more than any paraphrase is. But this is no "minority viewpoint"-find me any computer scientist who will disagree on the actual binary values. For that matter, not even Apple or Dell would disagree-they're just using incorrect but widely-recognized terms for marketing purposes. The "minority viewpoint" criteria do not apply when the viewpoint in question is effectively universal! Seraphimblade 01:35, 22 January 2007 (UTC)
No, kibibit, etc. are ill-conceived needless committee-driven nonsense. The English language is quite able to to accommodate words with slightly different meanings dependent on context. —Centrx→talk • 01:45, 22 January 2007 (UTC)
Not quite necessarily-the reason I advocate use of precision numbers was, first, when I started getting angry calls from people whose systems I'd upgraded. I promised them a 200 GB drive, you see, but it says it's only 185! It generally took a good deal of explaining to get them to comprehend they hadn't gotten shortchanged, and even then some of them seemed rather unconvinced. (Anymore, I explain this beforehand, and people don't seem to have much trouble understanding the basics-the "gigabyte" term is ambiguous, and the file system requires some space to set up its tables and such.) At least I never got sued over the discrepancy, though-but it sure looks like a lot of people have! There is not a thing wrong with being precise or taking proactive steps to prevent confusion, and relying on "context" to handle such things inevitably leads to misinformation and misunderstanding sooner or later. Perhaps, in most cases, context would handle it fine. But when a better, more correct, more precise alternative is available, why not use it? Seraphimblade 02:10, 22 January 2007 (UTC)
Actually, it is incorrect to say that one kilobyte can only mean 1000 bytes, at least in American English. See, for example, Merriam-Webster's definition of "kilobyte" and Free On-Line Dictionary of Computing's definition of "kilobyte". Even dictionaries which include the smaller variant list that as a second, less common definition; see, for example, Dictionary.reference.com's definitions of "kilobyte". --ΨΦorg 04:55, 22 January 2007 (UTC)
Interesting. Given that, staying with xB might make sense, provided we take care to link to something that clearly explains the discrepancy. (Still, I fail to see what harm it would do to use more precise terminology when it's known which one applies.) Seraphimblade 06:59, 22 January 2007 (UTC)
I totally agree with Seraphimblade. This is not a matter of opinion. Even if dictionaries say that kilobyte could mean 1024 bytes, it is ambiguous and an encyclopedia should be precise and consistent. There are prefixes specially designed for this purpose. They are internationally adopted as standards and they are unambiguous : what is written is what is meant, why not use it ? Sarenne 11:38, 22 January 2007 (UTC)

We can decide to use whatever convention we like, but we should be consistent. If it's clear that a source is using MB to mean 2^20 bytes, there is no problem with us reporting it as MiB, if that's the convention we decide on. The only problem is when it's not clear what the source means, in which case I guess the best we can do is use whatever they use. --Tango 11:50, 22 January 2007 (UTC)

I would agree, if there could be any doubt as to which one the source actually means, we should stay with what they use. In most cases, though, it's pretty clear whether it's a reference to base-10 or base-2. Seraphimblade 11:53, 22 January 2007 (UTC)
I agree, but the question is: Do we stay consistent with our sources and with common usage in the article domain? Or do we stay cosnistent across the encyclopedia? When this question has been asked of other measurement and naming standards, we have almost always decided on "sources and common usage". We use British spelling and linguistics in British articles; we use kilometers in Canadian articles; we use the time zone relevant to an event's location; we have also had a strong tendency towards binary prefixes in popular computing articles, because that's what's used in general conversation, print and online media, and by the manufacturers themselves. That's a pretty large group of real people to turn our backs on and say, "no, you're wrong, these technical committees know better". The article on megabyte does explain the ambiguity early on.
Hmm... a footnote or some other kind of explanatory widget in articles where this is an issue may be a good answer here. We do this to resolve ambiguity in other areas (pronunciation, for example.) Heck, I'm willing to do that work myself in the 1,500+ computing articles I have on my watchlist where these measurements would be relevant. -/- Warren 13:53, 22 January 2007 (UTC)
A footnote or something like that might work. Maybe some kind of template could be devised? I'm not going for any single solution, I just think we should make the issue clear to our readers-a lot of people have no idea there even is any kind of discrepancy. Seraphimblade 14:00, 22 January 2007 (UTC)
I think we should go by what would be the world wide norm, even apple uses MB and GB not MiB or GiB,No where in my computer does it reference MiB or GiB I have visted every major computer site and they all use the MB and GB term.Not one of them uses the GiB or MiB term that I saw.  Planetary Chaos  Talk to me  17:52, 22 January 2007 (UTC)

How ever I do see that if you have a 512 memory it would correctly be 512 MiB but if you have a 1 GB it would not be a GiB.  Planetary Chaos  Talk to me  17:56, 22 January 2007 (UTC)

You are still confusing prefixes... If you have a "1 GB" memory, you have 2 times a "512 MB" memory. A "512 MB" memory is actually a 512 MiB memory, so you have 2*512 MiB = 1024 MiB = 1 GiB. Sarenne 18:07, 22 January 2007 (UTC)
  • one mebibyte (MiB) is 1048576 bytes

one Megabyte (MB) is 1000000 bytes Source http://www.physics.nist.gov I don't think they are wrong.  Planetary Chaos  Talk to me  18:30, 22 January 2007 (UTC)

Hard drive seller "gigabytes" are neither binary gigabytes nor decimal gigabytes. They are usually either 1,000,000 binary kilobytes (i.e. 1,024,000,000 bytes) or 1,000 binary megabytes (i.e. 1,048,576,000 bytes). It's weird how they confuse and conflate the two meanings into a single prefix. --ΨΦorg 18:32, 22 January 2007 (UTC)
No, Hard Drive sellers are using "decimal" gigabytes (1,000,000,000 bytes) and "decimal" megabytes Example. They are using the prefixes like they should be used. Sarenne 18:47, 22 January 2007 (UTC)
Why do you quote this source ? I'm telling you that a 1 GB RAM has an actual capacity of 1 GiB, nothing more.Sarenne 18:47, 22 January 2007 (UTC)

All i'm saying is that MiB and GiG are not part of the measuring system in place now.and untill this changes, what's in place now should be reflected in the Misplaced Pages articles.

"It is important to recognize that the new prefixes for binary multiples are not part of the International System of Units (SI), the modern metric system." "Faced with this reality, the Institute of Electrical and Electronics Engineers ( IEEE ) Standards Board decided that IEEE standards will use the conventional, internationally adopted, definitions of the SI prefixes. Mega will mean 1 000 000, except that the base-two definition may be used (if such usage is explicitly pointed out on a case-by-case basis) until such time that prefixes for binary multiples are adopted by an appropriate standards body. "  Planetary Chaos  Talk to me  19:19, 22 January 2007 (UTC)

If you want to use SI prefixes with their real values (why not...), you have to change the numbers. When Apple, MS, Intel or AMD says 512 MB, it means 512 MiB so if you want to keep the real MB unit (=1 000 000 bytes) you have to change 512 MB to 536.870912 MB. Isn't it easier to say 512 MiB than 536.870912 MB ? Sarenne 19:45, 22 January 2007 (UTC)

No, I think it's easier to stick with the accepted (world wide)values instead of the confusing "new" prefixes that are not yet recognized by the world community.  Planetary Chaos  Talk to me  20:02, 22 January 2007 (UTC)

So why do you quote the IEEE that says the opposite ? What is the accepted value of 1 MB according to you ? Sarenne 20:13, 22 January 2007 (UTC)

as quoted above Mega will mean 1 000 000.You might want to read the IEEE currant standards.  Planetary Chaos  Talk to me  21:01, 22 January 2007 (UTC)

The "generally accepted values" are very dependant on context, and even then they aren't always universal. For example, should the size of my hard drive be reported as "200GB" as the manufacturer reports it, or "189GB" as Windows reports it? (Interestingly, 189GiB=203GB, I guess the 200GB it was sold as was approximate...) --Tango 21:03, 22 January 2007 (UTC)

IMO (and that's also what the current MoS recommends), the size of your hard drive should be reported as "200 GB" because 1) It uses the standard SI prefix G=10 2) It is consistent with the use of binary prefixes for binary capacities 3) Manufacturers chose this unit so there is no conversion to do.
Planetary Chaos, if 1 000 000 bytes is the value of 1 MB and you don't want to use binary prefixes, you are aware that it implies that we change all the capacity values when dealing with memory capacities (512 MB becomes 536.870912 MB, 1 GB becomes 1,073741824 GB...)? Is it really what you want to do ? Sarenne 21:27, 22 January 2007 (UTC)
I don't understand your point (2), using 200GB isn't using binary prefixes at all... And point (3) doesn't say why the manufacturer's choice should trump Microsoft's choice. Anyway, it was a rhetorical question - I was just pointing out that is isn't as simple as saying "Use the generally accepted values". --Tango 23:26, 22 January 2007 (UTC)
Using "200 GB" isn't using binary prefixes but is coherent with the use of binary prefixes. You can use "200 GB" for hard drive and GiB for RAM in the same article. If you use "189 GB" for the HD and "1 GiB" for the RAM, it is not consistent since in that case GiB and GB mean the same thing. Sarenne 23:49, 22 January 2007 (UTC)

Tango,Is your hard drive shared? Meaning your hard drive is typically C do you have a restore D or E partitioned?  Planetary Chaos  Talk to me  21:44, 22 January 2007 (UTC)

The hard drive in question is an external drive (well, a normal drive in an external caddy, to be precise), and is unpartitioned (or has a single partition, to be precise). --Tango 23:26, 22 January 2007 (UTC)

Sarenne,it is not what I want,but it is however the international standard.  Planetary Chaos  Talk to me  22:01, 22 January 2007 (UTC)

Binary prefixes (Ki, Mi, Gi...) are international standards too. Sarenne 22:17, 22 January 2007 (UTC)

Show your source.  Planetary Chaos  Talk to me  22:24, 22 January 2007 (UTC)

Binary prefix, IEEE 1541, IEC 60027, BIPM CCU, BIPM prefixes, ANSI. Sarenne 22:38, 22 January 2007 (UTC)

Let me say this M as in Mega has allways been a million long before the introduction of the PC.I to have a 200 GB HD 195 GB on C and 5 GB on RECOVERY D .Now correct me if my math is not correct but 195 + 5 = 200?  Planetary Chaos  Talk to me  00:04, 23 January 2007 (UTC)

Goody, this biscuit again... Since I haven't seen any arguments that haven't been used before, I'll just say that I don't see any compelling reason to change the current style guidelines on this matter. Conforming strictly to the SI definitions of the prefixes in question and using the binary prefixes proposed by IEC (and endorsed by BIPM, IEEE, et al) where appropriate prevents the ugly ambiguity. It only only seems to annoy people who already understand the issue at hand and dislike the prefixes for superficial reasons or are totally, utterly confused themselves. For further arguments made by myself and others at various times in the past, see this talk page archive. (specifically, here, here, here, and here (note the list at the end)) P.S. - Planetary Chaos' comments seem nearly comical considering the argument he (seems) to be attempting to make... Come on, folks, at the very least read the related Misplaced Pages articles on this matter before trying to express your opinion. P.S.2 - Shame on the folks that patronized Sarenne by labeling his obviously good-faith edits as vandalism and engaging in revert warring. -- mattb @ 2007-01-23T00:17Z
Yes, and K as in Kilo has been used to mean 1024, not 1000, in computer contexts, long before the introduction of the PC, too. See, for example, the IBM 1130 System Summary, which says on page 1 (PDF page 5) that "Core storage capacity is designated by a letter following the 1131 model number; A = 4k, B = 8k, C = 16k, and D = 32k.", and on page 2 (PDF page 6), speaks of machines with 4096, 8192, 16384, or 32768 words of memory, and, for machine that actually have megabytes of memory, see the IBM System/370 System Summary, which, on page 6-15 (PDF page 78), speaks of machines with "real-storage capacities of 1,024K (1,048,576 bytes) to 8,092K (8,388,608 bytes)". Guy Harris 07:21, 23 January 2007 (UTC)
Interestingly, for 2^10 bytes, the abbreviation "KB" is most common, which is arguably not using an SI prefix at all (SI defines a lower-case 'k' to mean 10^3). -- mattb @ 2007-01-23T14:11Z

Who here has bought a computer that uses the terms GiG or MiB? Any one? Any one at all? I just bought this computer two weeks ago..a 2007 PC and nowhere does it say GiG or MiB. On another note MiB might be confused with (Men In Black).  Planetary Chaos  Talk to me  00:33, 23 January 2007 (UTC)

Have you bothered to read half the links that have been provided, or are you more concerned with defending your original viewpoint than trying to understand why many people here are disagreeing? Let me say this explicitly: you yourself have confused terms and arithmetic several times here, so it's more than slightly ironic for you to counsel others to do their homework. -- mattb @ 2007-01-23T00:46Z
(in reply to Planetary Chaos) I'm not really considering writing any article on any of my computers, but even if I were telling you the capacities of the system, I would be sure to use the correct prefixes. For example, this laptop has 512 MiB of memory and an 80 GB HD. If I told you it had 512 MB of memory, I would be wrong. Not far wrong, granted, but wrong. "Mega" is a prefix that far predates computing, and it means one million of whatever follows it. Granted, the XiB terms are newer-that's to be expected, we only now have need of them, as only now are numbers such as 2^10, 2^20, and so on, important on a wide scale. However, they are clearly defined, verifiable, international standards, approved by multiple standards bodies, which have a clear, verifiable, and unambiguous meaning. Further, we can make trivial and obviously-correct changes to source wording, as commonly accepted when paraphrasing. For example, some companies may refer to their laptops as "laptop" computers, others to "portable" computers. If we decided that, for stylistic reasons, we should use only the term "laptop", that would be a perfectly acceptable paraphrase. Similarly, let's say an American source refers to an "organization" in an article which already uses British spelling. In that case, it would be perfectly acceptable to change that to "organisation"-we have not changed the meaning of what was said in our paraphrase. In the same vein here, when Dell refers to MB in terms of things that are always measured in MiB, we can safely presume that they mean MiB, and paraphrase for stylistic reasons and to avoid confusion. Dell may wish to speak in "layman's terms" when writing promotional material, and for that purpose, saying "1 GB of RAM" is certainly "close enough". However, in terms of writing an encyclopedia, we should work to be more precise, and to use exact numbers and terminology. Seraphimblade 02:54, 23 January 2007 (UTC)
Words take on different meanings in different contexts. In computing, the long-established meaning of the prefix "kilo" is 1024. Recently, there has been an attempt to re-define the prefix to accord with the non-computing meaning of 1000, and to invent a new prefix, "kibi", to replace what was conventionally denoted "kilo". This attempt is so far only partially successful, so it makes no sense to speak of "correct" or "incorrect", any more than it makes sense to speak of either or both "organisation" and "organization" as "incorrect spelling". The argument is between using something unconventional within computing, or something unconventional outside of computing, when writing about computers, and both approaches have their pros and cons. --Delirium 10:33, 23 January 2007 (UTC)
Quite so. The labels "correct" and "incorrect" are overblown here. My point (and others') every time this comes up is that strictly adhering to SI definitions and using IEC binary prefixes clears up any possible ambiguity assuming the writer is competent. I feel that the advantages of removing this ugly ambiguity outweigh any minor confusion that can be alieviated by reading the article that should be linked with the first usage of binary byte prefixes. I think it's far more advantageous for a reader to notice an unfamiliar abbreviation like MiB, click it, and learn about this notation issue than to see (excuse my own opinion here) misused SI prefixes and go on blissfully unaware that there is a difference between 10^6 and 2^20. If it came to a vote again, my position is clear (though I don't think it should have to since this has been discussed many times now). -- mattb @ 2007-01-23T13:27Z
  • One MegaMinute! I think we're writing a professional encyclopedia here and we don't need to use incorrect definitions if we know how to use the correct versions. I don't expect you would open a copy of Encyclopedia Britanica and find that different articles on the same subject would be using different definitions for the same units. Switching Imperial and Metric units is a poor decision as well. I think the entire encyclopedia should be written in International standard units. I am pushing for a wikimedia software feature to allow a user to set a units preference in this feature request. Alan.ca 13:47, 23 January 2007 (UTC)
Again, the label "correct" is overblown. While I tend to agree with you that we should only use SI prefixes with their strict SI definitions as set by the BIPM, there's the equally valid point that these SI prefixes have become nearly ubiquitous in common usage with computers (even professionals and engineers who know the issue often use them). It doesn't get us anywhere to insist upon which is the more correct usage, but we should consider which is the most accurate and uniform, and ambiguity plays a role in that. -- mattb @ 2007-01-23T14:09Z
Seraphimblade, Take alook at my second reply on this discussion.It kind of says what you said.
Mat, what is uniform? If you are speaking of MiB being more uniform then MB. I think you are wrong,How ever, MiB for something like 512 would be more accurate then MB.But on the other hand...MB would be more accurate for 500 then that of MiB.  Planetary Chaos  Talk to me  17:12, 24 January 2007 (UTC)
I'm really not sure what your question is... Can you express yourself with more lucidity? I fail to see much significant about the numbers you gave. The issue at stake is that using the prefix 'M', for example, in both the SI (10^6) and binary (2^30) contexts throughout Misplaced Pages is inconsistant. That's all I meant by "uniformity". I don't believe that it's good style to assume that the reader will perceive the correct context every time, or indeed even realize that there IS a context issue. Just as Misplaced Pages uses SI units in scientific articles for uniformity and accuracy, usage of the IEC binary prefixes where appropriate brings the same type of standard to computer and digital communications articles. (speaking of digital communications, just think about all the confusion there is between a kilobit, a kilobyte, a kibibyte, and a kibibit... Broadband companies make their living off this) -- mattb @ 2007-01-24T18:23Z
MiB for multiples of 1024*1024 (1048576) would be more accurate that MB. MB for multiples of 1000*1000 (1000000) would be more accurate than MiB. 500*1024*1024 (524288000) is 500 MiB, not 500 MB, just as 512*1000*1000 (512000000) is 512 MB. It's the units, not the multiple, that matters. Perhaps 500 is more commonly a multiple of 1000000 than of 1048576, and 512 is more commonly a multiple of 1048576 than of 1000000, but it's still the units that matter. Guy Harris 07:40, 25 January 2007 (UTC)
In the real world of talking about personal computer tech specs, nobody, nil, no one, not one single person refers to xiB units. Misplaced Pages articles, as they are written for non-experts, shouldn't be any different. I haven't been able to find even one other encyclopedia, magazine, or manufacturer website that refers to "gibibytes" of hard disk space or "mebibytes" of RAM. As xB units are the accepted norm, at least for now, changing to xiB units would only result in reader confusion. Sjenkins7000 04:27, 26 January 2007 (UTC)
You should take a look at a PC under Linux.Sarenne 13:29, 26 January 2007 (UTC)
If we used PC manufacturer marketing drivel as a benchmark, I can't even imagine how poor our standards of quality would be. -- mattb @ 2007-01-26T04:45Z

Should we have a vote on this? I think that everything was said. Current manual of style specifies very well where binary prefixes are to be used and still some editors are opposing it saying there isn't consensus. The only valid point why not to use them is IMO that it's WP:OR but there is no disscusion about accuracy. So we should decide whether we are about to use correct values or ones that are used in marketing materials of the computer industry (and may be utilize more info from computer marketing then since it's WP:OR not to call Apple' computers the best ones when Apple does so;). I don't think new consensus can be achieved by discussion, it has been discussed in the past (and not once) and nothing new has been said here. So we should probably vote to get over with this.--Pethr 11:29, 26 January 2007 (UTC)

PC manufacturer's specifications are not "marketing drivel." They are legal documents carefully reviewed for accuracy. They don't make "we're the best" claims. If you have more authoritative published sources for information about particular PC models covered in Misplaced Pages articles, please cite them. MOS is a guideline, WP:OR is official policy. It's not subject to a vote.--agr 12:41, 26 January 2007 (UTC)
Legal documents ? Reviewed for accuracy by who ? Sarenne 13:29, 26 January 2007 (UTC)
You're joking, right? When they publish that the computer has 2 MB of cache and 512 MB of RAM they are accurate? I thought we've been through this. It is not accurate and wikipedia is not accurate either when using MB instead of binary prefixes despite it's in WP:MS already.--Pethr 13:39, 26 January 2007 (UTC)
Err... I can't even count how many misleading statements, exaggerations, and outright lies I've seen in marketing documents, especially those relating to consumer products. Computers are not immune to this by any means. If you want an example of some of the most nauseatingly self-serving marketing in existence, browse Apple's site for a few minutes. Most of it isn't exactly untrue, but anyone can see the spin that they put on things. That's the job of marketing, to spin things in the way that is most likely to make a sale to their target audience. Consumer product marketing is NOT, by and large, concerned with publishing the most accurate specifications. -- mattb @ 2007-01-26T13:52Z
We can take it to a vote if you guys want, but that won't stop people from bringing this up. It's been voted on at least once before (twice, I think), and I still see the same debate with the same arguments every few months. -- mattb @ 2007-01-26T13:43Z
OK, so there is consensus and guideline; still it can't be enforced in articles because there is edit war every time somebody tries to push it. So it's going to stay the same despite the guidelines. It seems pretty strange to me.--Pethr 02:16, 27 January 2007 (UTC)
To briefly interject... Matt, you're talking about marketing materials, while others (such as Arnold and Pethr) are talking about technical specifications. These are two distinct sets of documents. Marketing materials are generally prepared by the marketing department and are used for advertising. Technical specifications are factual documents which are not typically used in any sort of marketing capacity. --ΨΦorg 21:38, 26 January 2007 (UTC)

In most consumer product manufacturing companies, published technical specifications go through an extensive engineering sign off and then are submitted for review by the legal department. They are contractual documents. Misrepresentations violate consumer protection laws and can result in civil suit. Apple, in particular, is a litigation magnet, so you can count on their review process being particularly thorough. If you can find one, just one, error in an Apple product specification, there are any number of class action law firms that would be glad to hear from you. Here is an example: http://www.apple.com/macbook/specs.html And the fact that you see the same debate with the same arguments every few months may be a clue that there is no consensus here.--agr 15:21, 26 January 2007 (UTC)

In these specs, Apple is incoherent. They use GB=1,000,000 B for hard drives and GB = 1024*1024*1024 bytes for RAM. Thus, there are at least 2 errors. Sarenne 15:37, 26 January 2007 (UTC)
This usage is standard practice in the industry and Apple clearly states that for hard drive capacity "1GB = 1 billion bytes; actual formatted capacity less." This is precisely the point. You want to substitute your view of how the specs should be written for what is the widely accepted standard in published sources. That is OR and POV. --agr 16:32, 26 January 2007 (UTC)
It is not "clear" at all. This usage is incoherent, Misplaced Pages should be coherent and accurate. We don't want to force Apple to be coherent, that's their choice. Sarenne 16:39, 26 January 2007 (UTC)
It is not just marketing.It was what was used BEFORE personal computers.One thing is clear, the articles written in Misplaced Pages are about the computer of topic. ie.Mac/Pc. The citations and reference links contained herein about the product at hand DO NOT reference the new SI prefix. Therefore, the article should reflect those citations and references.  Planetary Chaos  Talk to me  18:27, 26 January 2007 (UTC)
I still challenge anyone to state how this is OR. WP:NOR certainly must allow some degree of latitude-if every article we had here was as sure as some people seem to want to use the "source's exact wording", every article we have would be a glaring copyvio! Trivial paraphrasing is allowed, provided it does not change the meaning of what was said. Finally, as it seems there is not any consensus to change the MOS at this time, I would hope that no one continues to use reverting good-faith changes supported by MOS in an attempt to make a point. Seraphimblade 02:47, 27 January 2007 (UTC)
It's OR because technical judgement or interpretation is required for each conversion. This is not a case of "trivial paraphrasing," or even ordinary unit conversion, where the conversion factor is always clear cut. One must determine in each case whether KB, MB or GB were meant as binary or decimal in the source. If published sources do not provide that information, we should not interpolate it. Verifiability is an absolute requirement on Misplaced Pages, not subject to consensus.--agr 00:05, 28 January 2007 (UTC)
That does, of course, leaves it up to the readers to make the technical judgement. It also means that the article is "verifiable" in the sense that the article uses the same two letters as the primary source, not in the sense that the article and the primary source both unambiguously specify a particular amount of memory and the two amounts of memory are the same. Guy Harris 01:05, 28 January 2007 (UTC)

Ok so let's change the wording.That means for every article that contains MB,GB and so on should be changed. Computers,games,phones,memory sticks, any and all devices.I don't know about you but i'm sure this would create chaos on Misplaced Pages.  Planetary Chaos  Talk to me  17:26, 27 January 2007 (UTC)

It hasn't in the year or so it has been a guideline. -- mattb @ 2007-01-27T22:40Z

Only a few pages were changed to meet those guidlines and then changed back I have already counted more then 40 pages that would need to be changed.  Planetary Chaos  Talk to me  23:07, 27 January 2007 (UTC)

Imperial and Metric Auto Conversion like date format

I am noticing a lot of duplication of imperial and metric units. I notice that dates are automatically converted based on user preferences and I am curious if there is a similar capability for distance, area and volume. If one doesn't exist, how do we move to create such an option? Alan.ca 12:19, 23 January 2007 (UTC)

I think that would be a bad idea. With dates, you're just reordering the parts of the date. Converting units would be a far more substantial change, and in my opinion requires human judgement. For example, to how many significant figures would you convert it? Which units do you choose anyway? — e.g., m or km; m or litres; inches, feet, yards or miles? And can the engine parse the vast number of different units and different ways of writing them anyway? Quoting the source unit and providing a conversion in parentheses seems like the best solution to me. Stephen Turner (Talk) 14:08, 23 January 2007 (UTC)
I believe someone already wrote the patch, as noted either above, or in the bugzilla request for date syntax. Rich Farmbrough, 14:49 23 January 2007 (GMT).
Like Stephen, I'm wary of automatising this function. WPians just need to be skilled at judging the variables, for our readers' sake. Tony 15:07, 23 January 2007 (UTC)
I'm not wary. It's just a bad idea, plain and simple. Gene Nygaard 17:30, 23 January 2007 (UTC)
  • Ok sure, you can go through all the City pages and do the calculations manually for {{Infobox City}}. Or maybe I should just automate this template, like the hurricane template and then everyone else who finds that it's possible will do the same so we can continue duplicating our work here and wasting time. The key point here is that entering any figure twice is duplication which is prone to inconsistencies and typographical error. Further, articles become cluttered with 3 different units stated for the same figure. That's not to mention the conversion errors people make. Alternatively, we can state everything in MKS causing regional or interest groups readers who seek to view the encyclopedia in a different measurement standard will find themselves doing the calculations. Alan.ca
Date formats are simple in comparison, yet have caused an enormous amount of difficulty over the years to arrive at the current unsatisfactory situation. Automating units of measurement is an immeasurably more difficult task, just to get to the stage where registered users see what they want to see. And what happens to the majority of our users, who are unregistered and have no preferences to set? What units would they see? In this diverse world, we should cater for users from all cultures and backgrounds as best we can, and while it isn't too hard to work out that 5 June 2007 is the same day as June 5, 2007, we should avoid forcing readers to hunt for a calculator if they want to understand just how long, heavy, hot or bothered something is. --Pete 23:51, 25 January 2007 (UTC)
They would see the metric units or whatever units were most common in the world for that type of measurement. Alan.ca 01:27, 26 January 2007 (UTC)
Well, of course. But a sizable percentage would see unfamiliar units. It would be like us trying to work out dimensions given in cubits and leagues. We don't want to make life difficult for many of our readers as we pursue, with puritan zeal, a shining set of standards. The current system, where we quote Imperial and metric, and put the most relevant unit first, seems to work better than any alternative that has been suggested. --Pete 02:32, 26 January 2007 (UTC)
Who will determine the most relevant unit? Continuing in this fashion only promotes duplication and disputes over which unit is more relevant. Alan.ca 03:57, 27 January 2007 (UTC)
We'll work out disputes through consensus. In most cases, it is obvious which units are most relevant. --Pete 16:42, 27 January 2007 (UTC)
It's usually the one in the source. Stephen Turner (Talk) 17:12, 27 January 2007 (UTC)

Individual Years

I've put up the disputed tag because I think each year in this century, and for that matter, all centuries, are inherently notable. This morning someone else disagreed with this, and I wanted to come here to the talk page of this century where I began to remove redirects to the century as a whole for indvidual years yesterday. Hopefully we can gain a consensus in one way or another rather than have an edit war off the talk page. Just H 14:19, 23 January 2007 (UTC)

  • I don't think any individual year, beyond the 21st century, can be notable enough to have a page of its own. The most distant year to have a page of its own is 2065 and I think that's far enough for now. What information beyond anniversaries and fictional and astronomical events (all of which are on the century's page anyway) can be put on these suggested pages?Philip Stevens 15:14, 23 January 2007 (UTC)
The fact that there are anniversaries and astronomical events should be enough, but besides that there are also Non-Crystal Ball predictions from the present or past(just to clarify, even though the events may be crystal ball, the predictions themselves are not Crystal Ball and may be notable, ala Nostradamus or some other notable figure.)

There's also...

    • Dates mentioned in notable fiction.
    • Showing different calendar years for differing calendar systems
    • Pecularities of a year (such as 2002 being a palindrome and so on.)

and probably many others that I can't think of here, but others definately could if we just give them a chance. Just H 18:40, 23 January 2007 (UTC)

  • Yes but all of these can be found on the respective century pages and I see no reason to repeat this information. Also, there is very little of this information per year and creating a page for every individual year would lead to many hundreds of little articles with only "such a thing happen in Star Trek in this year" on them. Would it not be better to have all this information on one or two century pages where it can be easily accessed? Philip Stevens 19:30, 23 January 2007 (UTC)
  • Then let's start pages for George Bush's right foot, Goerge Bush's left foot, Goerge Bush's right thumb,.... Tony 23:30, 23 January 2007 (UTC)
    • That analogy is a bit 'over the top'. I'd like to see a statement on this page that states no pages should be created for individual years beyond the 21st century (not for the next 30 or 40 years at least) and any that are created should be instantly redirected to their respective century. Philip Stevens 06:16, 24 January 2007 (UTC)

Binary prefixes

I would like to question the guideline that states "If a contributor changes an article's usage from kilo- etc. to kibi- etc. where the units are in fact binary, that change should be accepted." There is currently something of an edit war going on about such a change on the pages dealing with several Macintosh personal computers, e.g. MacBook, Mac Mini. There are several good reasons not to use binary prefixes for articles dealing with consumer products:

  • These prefixes have not received general acceptance. Almost no one uses them. Their use on Misplaced Pages only serves to confuse readers.
  • While the binary prefixes have official recognition, their limited acceptance arguably makes them neologisms. We should not take the lead in popularizing new terms. See WP:NEO.
  • Use of the binary prefixes makes it harder to verify the accuracy of specifications contained in these articles as one cannot directly compare what the article says with the manufacturer's specifications. Typically there is a mix of binary and decimal prefixes in those specs and sorting this out comes close to original research. See the complex guidelines included in this MOS page.

I suggest that the sentence I quoted above be deleted and that the use of binary prefixes be left to the consensus of the editors working on particular articles or projects.--agr 10:45, 25 January 2007 (UTC)

See the "Converting to SI prefixes" section of this talk page for further discussion of that issue.
Note also that one of the reasons offered by people converting to binary prefixes is that the decimal prefixes are, in fact, inaccurate, so that when the vendor says that a processor has 4 MB of cache or a machine has 2 GB of memory, that vendor statement is inaccurate as the machine actually has 4 MiB of cache or the machine actually has 2 GiB of memory. Some others appear to have thought, at least at some point, that a processor claimed to have 4 MB of cache has, in fact, 4*1000*1000 bytes of cache, or that a machine claimed to have 2 GB of memory has, in fact, 2*1000*1000*1000 bytes of memory; hopefully, nobody here would argue that, as it's wrong. Given that, verifying, in any meaningful sense, the accuracy of specifications in an article requires that you somehow determine whether the vendor, when using K/M/G/T, meant 1000/1000*1000/1000*1000*1000/1000*1000*1000*1000 or meant 1024/1024*1024/1024*1024*1024/1024*1024*1024*1024, which could well mean that verifying a specification requires original research. Guy Harris 11:16, 25 January 2007 (UTC)
Memory and processor cache operate with the binary specifications. It does not require "original research" to state that a machine with 2 RAM cards at 512 each has a total of 1024 MiB of memory, any more than it requires "original research" to state that the machine has two cards because 1+1=2. On the other hand, hard drive capacities typically are measured in "true" decimal specifications-an HD specified at 200 GB really does have (200*1000*1000*1000) bytes of available storage. Also, we shouldn't shy away from using a specific term over a general one just because it's a "big word" that some people may not initially understand. The XiB prefixes are international standards with unambiguous meanings, they are not a neologism. I would venture a guess that many of our users may not know exactly what sulfuric acid is, but that doesn't mean we should use the more general term "battery acid"-instead, we should use the specific term, and link to its page, so that our readers may learn what the specific term means if it's not clear to them. (Some people refer to the electrolyte in alkaline batteries as being "battery acid"!) In the same vein, it is our job to be specific when referring to technical specifications. The XiB prefixes are unambiguous terms with clearly defined meanings, and we do a disservice to our readers by not being as accurate as we possibly can. Seraphimblade 11:31, 25 January 2007 (UTC)

Misplaced Pages is a tertiary source and verifiability is one of its bedrock principles. Making manufacturers' specifications "more accurate" goes beyond our charter. Converting to binary prefixes requires some technical judgement. If that judgement cannot be independently verified by a published source, it's a problem. We are talking about dozens of articles here. And I don't agree that it is a service to our readers to use terminology that is not widely adopted--and which may never be. We don't call water "dihydrogen oxide," even though that term may more closely conform to internationally accepted chemical nomenclature. Note I am not suggesting the XiB prefixes be banned, merely that their use be subject to editorial consensus. --agr

In practice, vendors use K/M/G/T as binary prefixes; nobody should dispute that. A Core 2 Duo that Intel says has "4 MB" of level 2 cache, for example, does not have 4 000 000 bytes of L2 cache, it has 4 194 304 bytes of L2 cache. Trust me on this one - it'd just be too much of a pain to get rid of those extra 194304 bytes, given that addressing in modern processors work with binary addresses, not BCD addresses. Thus, clearly, K/M/G/T are ambiguous, as, when you're not counting bits or groups of bits, they're decimal prefixes, not binary prefixes. The same technical judgement that would be required to convert those prefixes to binary prefixes in a Misplaced Pages article would also be required to interpret a Misplaced Pages article not using binary prefixes. Guy Harris 19:23, 25 January 2007 (UTC)
Misplaced Pages does not derive its value from blindly copying data from manufacturers. Making the data unambiguous and comparable is added value of wikipedia. Note for example that although disks are usually measured in decimal prefixes (e.g. 100 GB), Windows reports with the same visible prefix, but digital values (e.g. 93.1 GB, actually 93.1 GiB). Clearing up that kind of differences is useful. Therefore we should perhaps adopt a similar approach as to other units of measure and indicate both the source value and a conversion or re-interpretation to internationally standardised units. So me might have:
  • the disk size is 100 GB (93.1 GiB)
  • the memory size is 2 GB (2 GiB)
This approach allows both verification against sources and verification of interpretation. −Woodstone 14:01, 25 January 2007 (UTC)
This isn't a matter of verifiability at all, it's simply which prefix is more accurate. It's not making vendors' specifications "more accurate", it's correctly interpreting the context and removing the ambiguity, something that many readers could not do own their own. I support the current wording exactly because whenever I've seen this issue play out on a per-article basis it often gets overrun by people who are totally ignorant of the issue and just stubbornly cling to their own uninformed and confused ideas. A strong guideline is necessary to prevent pages and pages of debate from developing on every article where this comes up; we've discussed it enough times here as it is. -- mattb @ 2007-01-25T14:20Z
Referring to editors who disagree with your position as "totally ignorant of the issue and just stubbornly cling to their own uninformed and confused ideas." is unacceptable. See WP:Civility. We are trying to write articles appropriate to our audience. The personal computer industry has thus far not accepted the IEC binary prefix recommendation. A reader who looks at an article converted to use them will be confused when comparing it to other sources, not aided. We allow articles about cars to cite top speeds in mi/hr and km/hr, not m/s and we don't expect fuel economy in meters/mole, even though the later terms are what SI specifies. Nor should we be "interpreting" manufacturer's specifications. From WP:OR "the only way to demonstrate that you are not doing original research is to cite reliable sources that provide information directly related to the topic of the article, and to adhere to what those sources say." I have less problem with Woodstone suggestion of giving XiB units parenthetically, as it is adding info, not interpreting, though, again, I think this can be left to project editors who know their audience and subject area.--agr 16:10, 25 January 2007 (UTC)
I'm sorry, but I don't see identifying a problem for what it is as uncivil. I'm not going to water down my words for the sake of some silly ideal of political correctness, but I'm certainly not mentioning names or trying to pick a fight or demeaning anybody. Nor did I imply that everyone who doesn't agree with me is ignorant; if you bother to read, I have at several points acknowledged the validity of opposing points of view on this matter. However, the fact is that many (not all) people are either ignorant or confused about this issue. If you look at all the previous discussions you can clearly see this element popping up in the form of bad arithmetic or just a total lack of understanding of what these prefixes are and intend to do. If you think it's uncivil for me to say so explicitly, I'm sorry to say that I can't please you with candy-coated words or a runaround suitable for a career in diplomacy. Anyway, my position is clear, I feel the current verbiage should stay. -- mattb @ 2007-01-25T18:51Z

I fully support the current wording. These prefixes don't cause confusion; they cause accuracy. Just make sure they link to the appropriate articles as specified in the MoS. — Omegatron 15:46, 25 January 2007 (UTC)

what i think? since the pc and mac manufactures and the computers them selves do not use the new si. the article for that computer should not either.i support the new prefixes but only if the computer and the manufacture start using them my mac does not so the article for it should not reflect that change.when a computer or manufacture starts using the new si prefix then yes i think it should go in to the article the way i see it mb may be old not not fully correct but it is what the computer and manufactures say wikipedia should not try and change this as it is not wikipedias or its editors place to do so. — Preceding unsigned comment added by ] (] • ])

The argument on popular understanding is a straman: nobody really cares about the added i. Christoph Päper 15:25, 26 January 2007 (UTC)

I tend to agree. It's an arguable point which is difficult, if not impossible to back up with any hard facts. -- mattb @ 2007-01-26T23:09Z