Jump to content

Wikipedia talk:Manual of Style/Dates and numbers

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Wikipedia talk:Manual of Style

This is an old revision of this page, as edited by Matt Britt (talk | contribs) at 23:45, 28 February 2007 (→Wikipedia is no place for the MiB religion to be practiced). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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

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

  1. Tony 05:06, 9 December 2006 (UTC)[reply]
  2. Outriggr § 05:27, 9 December 2006 (UTC)[reply]
  3. MattWright (talk) 05:36, 9 December 2006 (UTC)[reply]
  4. Pinkville 14:22, 9 December 2006 (UTC)[reply]
  5. Rich Farmbrough, 14:53 9 December 2006 (GMT).
  6. CRGreathouse (t | c) 16:02, 9 December 2006 (UTC)[reply]
  7. Joe Kress 16:07, 9 December 2006 (UTC)[reply]
  8. EdJohnston 16:29, 9 December 2006 (UTC)[reply]
  9. Stephen Turner (Talk) 16:58, 9 December 2006 (UTC)[reply]
  10. Kaldari 17:06, 9 December 2006 (UTC)[reply]
  11. Doom 20:57, 9 December 2006 (UTC) -- strongly agree: links should be human generated[reply]
  12. Pia 23:54, 9 December 2006 (UTC) -- as per Doom[reply]
  13. per Outriggr -- Agathoclea 01:03, 10 December 2006 (UTC)[reply]
  14. Dhaluza 01:47, 10 December 2006 (UTC) -- Have had to clean up useless date links from several articles.[reply]
  15. Most of the time date links are irrelevant and distracting. Graham87 02:03, 10 December 2006 (UTC)[reply]
  16. Punctured Bicycle 02:25, 10 December 2006 (UTC)[reply]
  17. Daniel Quinlan 02:37, 10 December 2006 (UTC)[reply]
  18. Joy [shallot] 02:41, 10 December 2006 (UTC)[reply]
  19. Mad Max 03:02, 10 December 2006 (UTC)[reply]
  20. Gzkn 04:28, 10 December 2006 (UTC)[reply]
  21. Vsmith 04:40, 10 December 2006 (UTC)[reply]
  22. clear and should be helpful. Hmains 05:21, 10 December 2006 (UTC)[reply]
  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...[reply]
  24. I'm all for reducing the number of irrelevant blue links. Just cleaned up some an hour back [1]. I support the move with the possibility that we can also have the a new functionality for the time too. =Nichalp «Talk»= 06:28, 10 December 2006 (UTC)[reply]
  25. Agreed on general principle. This would help a lot with the less useful links. Tuf-Kat 06:32, 10 December 2006 (UTC)[reply]
  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)[reply]
  27. Support the idea. --Guinnog 08:28, 10 December 2006 (UTC)[reply]
  28. Strong support, I previously campaigned for this; hopefully we'll get someone to implement it in MediaWiki this time. —Quarl (talk) 2006-12-10 08:39Z
  29. Cuñado - Talk 10:08, 10 December 2006 (UTC)[reply]
  30. Kusma (討論) 10:28, 10 December 2006 (UTC)[reply]
  31. Wackymacs 11:57, 10 December 2006 (UTC)[reply]
  32. —Josiah Rowe (talk • contribs) 12:01, 10 December 2006 (UTC)[reply]
  33. Ground Zero | t 12:47, 10 December 2006 (UTC)[reply]
  34. Donald Albury 13:53, 10 December 2006 (UTC) Keep the request simple/single issue.[reply]
  35. Fritz Saalfeld (Talk) 15:32, 10 December 2006 (UTC)[reply]
  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.[reply]
  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)[reply]
  38. Wetman 15:49, 10 December 2006 (UTC) As Michael said, Links should support and advance the primary focus of the article.[reply]
  39. — Deckiller 15:58, 10 December 2006 (UTC)[reply]
  40. Zundark 16:11, 10 December 2006 (UTC)[reply]
  41. Yes, and I tried to lead the charge on this the last time, too. --Cyde Weys 16:37, 10 December 2006 (UTC)[reply]
  42. Good idea, full support in principle, presuming some appropriate syntax can be found. — Matt Crypto 16:51, 10 December 2006 (UTC)[reply]
  43. President Lethe 17:33, 10 December 2006 (UTC) — I support this with reservations and/or extra requirements. See my comments here and immediately above this section [moved there by Tony].[reply]
  44. Kirill Lokshin 17:49, 10 December 2006 (UTC)[reply]
  45. KP Botany 18:03, 10 December 2006 (UTC) Oh, absolutely support this, as simply cannot understand why the date I accessed a web reference should be blue linked. Check out the Afghanistan article, and related, some time to see the absurdity of links that ruins articles on Wikipedia.[reply]
  46. I like the wording and context. Kudos to getting this restarted. -- nae'blis 18:20, 10 December 2006 (UTC)[reply]
  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:[reply]

    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)[reply]
  49. Long overdue. Something like ||February 10|| would be ideal. --RobthTalk 21:43, 10 December 2006 (UTC)[reply]
  50. Stratadrake 00:25, 11 December 2006 (UTC)[reply]
  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)[reply]
  52. Neier 02:22, 11 December 2006 (UTC)[reply]
  53. Hesperian 06:27, 11 December 2006 (UTC)[reply]
  54. It'd be a huge improvement. —Moondyne 08:10, 11 December 2006 (UTC)[reply]
  55. Agree, black should be the default with linked dates available for useful context. .. dave souza, talk 09:14, 11 December 2006 (UTC)[reply]
  56. Oh, yes, I'm a supporter. This might reduce mindless rollbacks as well. Thincat 10:18, 11 December 2006 (UTC)[reply]
  57. EJ 13:34, 11 December 2006 (UTC)[reply]
  58. Curtis Clark 17:26, 11 December 2006 (UTC) Support in principle.[reply]
  59. Hemmingsen 20:05, 11 December 2006 (UTC)[reply]
  60. Support as per user Centrx, date linking and format preferences have different purposes Golden Wattle talk 20:15, 11 December 2006 (UTC)[reply]
  61. Quiddity 21:46, 11 December 2006 (UTC)[reply]
  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)[reply]
  63. Seems to be a good idea. Jkelly 22:04, 11 December 2006 (UTC)[reply]
  64. Sounds like a good idea ••gracefool |☺ 03:52, 12 December 2006 (UTC)[reply]
  65. --Duk 04:43, 12 December 2006 (UTC)[reply]
  66. Like the idea a lot. Sandy (Talk) 21:10, 12 December 2006 (UTC)[reply]
  67. AnonEMouse (squeak) 21:45, 12 December 2006 (UTC)[reply]
  68. Brilliant idea. Singkong2005 · talk 06:58, 13 December 2006 (UTC)[reply]
  69. Neonumbers 08:03, 13 December 2006 (UTC) Fully agree in principle.[reply]
  70. I hope this goes through! — Reinyday, 18:14, 14 December 2006 (UTC)
  71. Chairman S. TalkContribs 13:02, 17 December 2006 (UTC) This is an intelligent solution to the problem of date linking, and I support it wholeheartedly.[reply]
  72. Absolutely. --Spangineerws (háblame) 19:49, 17 December 2006 (UTC)[reply]
  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.[reply]
  74. Good idea. --tjstrf talk 02:10, 5 January 2007 (UTC)[reply]
  75. Excellent idea - esp per points 3 and 5 --Orderinchaos78 01:47, 6 January 2007 (UTC)[reply]
  76. Strong support Jimp 01:34, 9 January 2007 (UTC)[reply]
  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)[reply]
  78. I would like that very much. Schmiteye 00:28, 22 January 2007 (UTC)[reply]
  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)[reply]
  80. If articles can't be marked up in accordance with common sense and Wikipedia 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)[reply]
  81. This would be a great improvement. —Celithemis
  82. I support this proposal. The ideal solution would be a coding format that would both render the reader’s date formatting preference AND permit “year in XYZ” linking. If full dates cannot be piped, then the “Year in XYZ” timeline pages need to be deprecated and removed since we’d be left with every date being given simply as the year once the bot’s work is done. Askari Mark (Talk) 02:46, 1 February 2007 (UTC)[reply]

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

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

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

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

Still retains problem of how would you perform a link to a full date article (some of which exist, such as August 13, 2004) *and* keep user preferences working. If they come up with a new syntax, hopefully it can handle flexible, optional linking. --MattWright (talk) 00:34, 11 December 2006 (UTC)[reply]
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)[reply]
Alternately, I suppose triple-brackets is another option, e.g., [[[December 10]]] versus [[December 10]], where both are auto-formatted, one is linked but the other is not. And the target article for a given date probably already has redirects set up to accommodate different user preferences. (Which is probably a good idea to implement anyway....)) --Stratadrake 00:50, 11 December 2006 (UTC)[reply]
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)[reply]
I think both of these options are sub-par to other proposals I've seen, such as a {{date|}} template or new syntax for preferences such as <<date>> or ||date||. They do not address linking to full dates ([[January 10, 2007|[[:January 10]] [[:2007]]]] seems unlikely to please) and also don't take the comma issue that others have raised into account. This proposal was left without a specific syntax defined so that a clear voice can be heard that change is needed. The developers are smart and can either come up with syntax they want to implement (syntax isn't even that important, as long as it gets the job done) or solicit the community for ideas. That's my opinion anyway. --MattWright (talk) 02:42, 11 December 2006 (UTC)[reply]
||date|| would clash with table syntax. Stephen Turner (Talk) 10:26, 11 December 2006 (UTC)[reply]

: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)[reply]

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

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

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

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)[reply]
  • Suggestion: the new syntax should also deal with, or be extendable later to deal with date ranges. Reason 3-5 July has to become [3 July] - [5 July] ATM. In general, ask for the implementation to be forward looking. Rich Farmbrough, 17:48 11 December 2006 (GMT).
  • Suggestion: mention the comma thing. Rich Farmbrough, 17:59 11 December 2006 (GMT).
  • Suggestion: make the syntax extendable later to convert to preferred units (lb/kg, etc). —Quarl (talk) 2006-12-13 22:02Z
I'm pretty sure preferenced unit conversion isn't going to make it into Wikipedia. I modified the code to do this, even taking significant units into account, and was basically told it was a bad idea according to the wikitech mailing list. [2] --MattWright (talk) 22:20, 13 December 2006 (UTC)[reply]
I see, that's unfortunate and unexplained. Thanks for trying! —Quarl (talk) 2006-12-13 23:51Z

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

The community has put forward many great syntax options, but it always devolves into an argument. This proposal is saying "we need a change". No one has yet disputed that we do need a change. Specific syntax will be disputed. Who better to select from the excellent syntax options that have been presented than the developers who know how it will affect future plans, Wikipedia, and the rest of the mediawiki universe? I also don't think it would be terrible to "cross that bridge when we come to it" if they do decide to kick it back to the community. --MattWright (talk) 00:54, 13 December 2006 (UTC)[reply]
I may well be wrong, as this discussion has grown far beyond my capability to follow it (condensing it a bit, anyone?), but while everybody seems to agree that "we need a change" I see a lot of different ways to intend that; many seem to focus on the color of the text, for instance. All in all, I think I'd prefer eliminating preferences altogether to any half-backed solution which considers dates only, and tries to cope with the developers' capriciousness (though the captatio benevolentiae in the final part of the proposal text might well do the job :-)). After all, I've never seen anyone complaining they didn't like how their paper encyclopedia was spelling dates out as long as there was no ambiguity. —Gennaro Prota•Talk 20:49, 17 December 2006 (UTC)[reply]
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)[reply]
I intend to pursue the matter further if our representation is ignored. Tony 01:17, 14 December 2006 (UTC)[reply]

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

I thought to templates too when reading the MoS pages about dashes, hyphens, beams and motes (;-)) but in fact such usages would be workarounds of software deficiencies (as many existing templates are, for instance {{ISSN search link}}, which I created myself for lack of a better solution). And in this case they would still need a new software feature. Unfortunately (or very fortunately) Wikipedia has pushed MediaWiki to its limits; I don't know if its authors ever had in mind something similar in extent and complexity but certainly the software can't cope with it. It would be the software responsibility, for instance, to convert between units and number notations (at least if we are serious about avoiding human errors). And we are in desperate need of an SCM system. I'd see with enthusiasm a (long-term) project to create a full-fledged content manager, perhaps around SVN, and a migration of all the Wikipedia contents to it. —Gennaro Prota•Talk 05:26, 18 December 2006 (UTC)[reply]
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)[reply]
I had another idea for a potential syntax (since it's been mentioned that, if we have one in mind, that might make the developers' job a bit easier), for an auto-formatted but non wikilinked date, what if we could simply type it in as a piped link with no target e.g. [[ |December 20]]. It's obvious the link doesn't actually go anywhere, and when that is the case the Wiki software could format the date text per user preferences. Intuitive and fully backwards compatible (we could organize date de-linking campaigns later), so it's another viable option for a syntax suggestion. --Stratadrake 13:36, 21 December 2006 (UTC)[reply]

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

One or more, may, review (not "implement it")… Wow! Didn't he add a perhaps too? —Gennaro Prota•Talk 15:35, 21 December 2006 (UTC)[reply]
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)[reply]


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

What it really should do is format all dates, and then you can use nowiki tags to escape. Then you don't need to do anything special to format the vast majority of dates and you don't need any more HTML-esque markup cluttering up our articles. It's the wiki way. — Omegatron 21:31, 23 February 2007 (UTC)[reply]

Suggested solution

A template, we'll call it {{nldate|(the date)}}. The code is as follows: 

<span class="nldate">{{#time:{{#ifexist:Special:Mypage/datefmt|{{Special:Mypage/datefmt}}|[[Y]]-[[m-d]]}}</span>

The span/class allows users to have monobook.css changing the color to black if they don't want to figure out date formats. --Random832(tc) 20:40, 31 January 2007 (UTC)[reply]

Date preferences and Jogersbot's massive undoing of edits

Few editors expressed feelings that context is more important when linking full dates than allowing date preferences to work and therefore labeling my bot activity as harmful and unwanted [3] [4]. Were there any discussions specifically about this? I was sure that full dates is a clear-cut case and current consensus is reflected at Wikipedia:Manual of Style (dates and numbers) and Wikipedia:Piped link. I didn't mean to do anything controversial so if there is nobody here to back me up I will stop running the bot. Jogers (talk) 11:27, 1 February 2007 (UTC)[reply]

I've moved the discussion from Wikipedia talk:Bots/Requests for approval:

A number of editors have expressed concerns about

which was approved recently (27 January). See concerns raised at User talk:Jogers, WP:AN/I raised by User WhyADuck, Talk:Timeline of aviation, Wikipedia_talk:AutoWikiBrowser#More_on_dates. I and other editors do not agree with the work the bot is doing. It is undoing a lot of editors' work.--Golden Wattle talk 20:51, 31 January 2007 (UTC)[reply]

A lot of these concerns comes from misunderstanding its purpose. I would never suspect that it will cause so much controversy. I only try to help here. As I mentioned on several occasions both Wikipedia:Manual of Style (dates and numbers) and Wikipedia:Piped link are perfectly clear about the issue. The reason for linking full dates is to allow reader's date preferences to work, not to provide context. Jogers (talk) 21:04, 31 January 2007 (UTC)[reply]
Obviously the people who are linking the year in dates to year in topic articles do not agree with the proposition that "the only reason for linking dates is to allow preferences to work" - there are apparently at least 4,500 articles where many editors had made this deliberate choice - not an insignificant number. As discussed elsewhere with User:Jogers, I believe the majority of date preferences will be set to show either 11 September or September 11 format depending on whether US or Commonwealth English applies. These preferences are supported if the day and month are linked regardless of whether the year is followed. The view fails to work only when the less likely preferences "16:12, 2001 January 15" or "2001-01-15T16:12:34" format are chosen.--Golden Wattle talk 21:19, 31 January 2007 (UTC)[reply]
It is not obvious for me that it's a deliberate choice in 4500 articles because so many editors don't seem to understand how date preferences work. Jogers (talk) 21:38, 31 January 2007 (UTC)[reply]
The editors made a deliberate choice to link to a year in topic article. People are respectful of spelling differences and consequently of month/day or day/month preferences,probably less interested in pandering to yyyy-mm-dd preferences as it is a barely literate way of writing; as date format it has a point in other contexts (eg sorting lists of dates) but not in a narrative context. By bothering to put in a piped link instead of the easier straight date link which takes work, I think it can be concluded that I am not the only one who has made a deliberate choice from time to time. Your bot is undoing the work of 4,500 deliberate edits.--Golden Wattle talk 22:21, 31 January 2007 (UTC)[reply]
It would be nice to have a unified style, perhaps a discussion can take place at the manual of style page. There seems to be an existing consensus there. HighInBC (Need help? Ask me) 22:23, 31 January 2007 (UTC)[reply]
There are ongoing disputes in various places, there is not an existing consensus, there is a previaling stance that has not been overturned - see for example recent discussion at Wikipedia talk:Manual of Style (dates and numbers). Given the continuing irritation about this subject, a bot that does whole scale changes forcing a viewpoint does not seem appropriate. I will also raise concerns that the user failed to respond to my comments raised 07:49, 31 January 2007 until I blocked the bot some 15 minutes later asking him to respond to discussion raised. This bot is performing a task about which there is not unanimous agreement.--Golden Wattle talk 22:31, 31 January 2007 (UTC)[reply]
What exactly concern you about my reply? Jogers (talk) 23:26, 31 January 2007 (UTC)[reply]
The delay; you persisted with your edits despite objections and merely ignored the query until I blocked you. Your bot claims to be supervised - why persist in such edits and not respond when somebody queries your actions.--Golden Wattle talk 00:14, 1 February 2007 (UTC)[reply]
The bot is supervised meaning I check almost every edit it makes but it runs in automatic mode. Jogers (talk) 00:17, 1 February 2007 (UTC)[reply]
Also, I don't see any disagreement about the guideline that full dates should be linked in a fashion that allows date preferences to work at Wikipedia talk:Manual of Style (dates and numbers). Jogers (talk) 23:39, 31 January 2007 (UTC)[reply]
In response to I don't see any disagreement about the guideline that full dates should be linked ... at that discussion alone there are the comments: "Mass edits which solely remove (or add) date links across many articles are discouraged, as with any mass minor edits"; "There is no consensus for that particular guideline"; "The reason the language is vague is because there isn't a consensus for any stronger language."; "As for the 'preferences' thing of rendering dates in alternative styles - that leaves me cold."; "These "mostly supportive" comments consist of two for and two against. We discussed this to absolute death last year, ..... 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." "doesn't seem very likely that this proposal is going to gather a broader consensus than the previous one" "My view is that the elimination of YEAR in X|YEAR links would be a mistake" This does not read like a conversation without disagreement - it is civil but there is no consensus. There are many other places where similar discussions have been held.--Golden Wattle talk 00:14, 1 February 2007 (UTC)[reply]
Surely there is a lot of disagreement in this discussion but it concerns mainly relevance of links to partial dates, shortcomings of current date preference scheme and the issue of piped links to "years in something" in general. Nobody suggests using piped links in a way that breaks date preference. Jogers (talk) 00:21, 1 February 2007 (UTC)[reply]
What are you talking about? There's a whole section at Wikipedia talk:Piped link entitled "Disagree with year-in-x no-piping suggestion" which discusses this! Usage of such YiX piping clearly implies that such a link would take precedence. What really alarms me is that Jogers is using his bot to force his perspective. As a bot operator, I would have expected him to respond with something like "Oh, there's a bunch of people concerned here, maybe I need to back off and discuss this further". Instead, he allows the bot to continue until an admin blocks it. Bots are great, but the owners need to be really sensitive to other editors when the bot's effect is negative, even if the owner doesn't agree. Akradecki 00:56, 1 February 2007 (UTC)[reply]
This is precisely what I'm talking about. The guideline used to recommend not using piped links to "years in something" at all and it caused a lot of disagreement. I don't really feel that it is only my perspective. Most concerns were raised because of lack of understanding so I continued to run the bot after they were addressed. Only you and Golden Wattle seem to strongly disagree about the matter. As HighInBC pointed out above there is existing consensus here but consensus can change so consider discussing this at Wikipedia talk:Manual of Style (dates and numbers) maybe and I suspend my bot activity until you get some feedback. Jogers (talk) 10:53, 1 February 2007 (UTC)[reply]
I took a look at the bot's contributions, in order to repair the damaged aircraft articles, and was amazed at how many articles it had changed. Doesn't that make you stop and think? When it comes to a "consensus" about any issue discussed at Wikipedia, at most you'll usually have a dozen or so editors participate. On this issue, you're changing the work of hundreds of editors. Don't you think that mass quantity alone represents a really big group out there who use such piped dates as a tool? That's far more than just a consensus...that goes into the realm of a supermajority. In other words, there's a lot of editors out there (and don't just attribute it to ignorance, please) who have built this tool into the encyclopedia, and who are you to make such a massive edit, thinking that you've got it right and hundreds of editors have it wrong? I'll post my comments to the MOS page like you suggest later this morning. Thanks for standing the bot down. Akradecki 15:06, 1 February 2007 (UTC)[reply]
The mass quantity of incorrect date formatting doesn't really make me think that it's a deliberate work of some "supermajority" who decided to break reader's date preferences in thousands of articles being perfectly aware of how it works and what are the Manual of Style recommendations on the issue. Your strong feelings about this keep surprising me. Jogers (talk) 15:56, 1 February 2007 (UTC)[reply]
Why would it surprise you that mass edits which undo a lot of work, mine included, shouldn't be taken seriously? So you think it's just an accident that hundreds of editors deliberately type the longer YiX link? You don't think they intentionally put the link there to improve the navigabilty of the subject? YiX is a tool that a lot of folks use, and I'm disappointed that you can't see that. In our case, there are certain historic events, such as first flights, that are documented this way. Each YiA article has a whole section for first flights, and so it is a natural tool to link a first flight date in an article to the YiA entry. I'm really trying hard to assume good faith in your efforts, but your continued insistance on your position being the only correct one, and the lack of any expression of concern about all the work your bot is undoing, borders on arrogance. Please pardon me if that comes across as a personal attack, it's not meant to be, but quite honestly, Jogers, I can't think of a politer word to describe the lack of respect you're showing, even in the above comment, for the work of others.Akradecki 18:02, 1 February 2007 (UTC)[reply]
Everything I did was in good faith. Fixing date preferences seemed like a good thing to do and I already did a lot of changes like this manually without any problems before. I don't have anything against linking to YiA entries in aviation articles when it's relevant to the context. The problem I see with your approach is that you don't provide any solution to the problem of these links conflicting with reader's date preference though. The reason I've been insisting on my position for so long is that I felt that whole this discussion came from misunderstanding my bot's purpose. Also, Manual of Style clearly supports my assertions. I'm sorry if I were arrogant, I didn't mean to. Regards, Jogers (talk) 19:25, 1 February 2007 (UTC)[reply]
I appreciate your work in good faith, but this discussion didn't come from a misunderstanding of your bot's purpose but rather a clear understanding of its effect, which is to undo a massive amount of work by hundreds of editors. I fully agree that there's a problem with user preferences, but why must user preferences be treated like a universal absolute? For instance, there's a general misunderstanding out there that image thumbs can be sized...they shouldn't, because that, too, interferes with user preferences. But, there are exceptions, specifically thumbs that are used for infoboxes. The higher purpose of the userbox usage outweighes the generic system function of user preferences. Same here. When a date is configured for YiX, it is for a purpose, and specific purposes like that should take precedence, at least until someone can fix the way the system works so that the user preference will work whether or not the date part is linked to the year part, or, better yet, the system is made to recognize the text "year in XXXX" as a part of the year's number text, and treat it accordingly. Yes, there's a problem, yes it needs to be addressed (preferably with a software fix), but to allow a bot to continue to undo all that work seems quite unwise. Once a fix is found, how were you planning on putting all those YiX links back? Akradecki 21:03, 1 February 2007 (UTC)[reply]
The issue about date preference is not specifically under discussion in that sense but the comment "As for the 'preferences' thing of rendering dates in alternative styles - that leaves me cold." doesn't indicate support. For those editors, including me, who use the links in the way we do, you may wish to consider that we are doing so with some thought. As per my comments above, date preferences in yyyy-mm-dd format are not useful in a narrative particularly and as an editor I am not interested in supporting text that includes that form. Date preferences for day month or month day still do work with the way I choose to link (sometimes); ie I do support the first part of Wikipedia:Manual of Style (dates and numbers)#Dates containing a month and a day.
For yearless dates, the MOS only deprecates the same because context might be lost. It does not mention date preferences as a reason for including the year.
The issue will only be solved when the debate or fix on A new parallel syntax for autoformatting dates is resolved. In the mean time mass edits changing dates is deprecated[5] - why is a bot doing it?--Golden Wattle talk 00:53, 1 February 2007 (UTC)[reply]
You've just taken a sentence out of context to make a point. The editor said: 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. A lot of people agree that the current data preferences scheme is far from perfect and hopefully it will be changed at some time in the future. It's not the same as saying that the current data preferences scheme is bad and it shouldn't be used at all. Anyway, why don't you take it to Wikipedia talk:Manual of Style (dates and numbers)? I think you could get more feedback there if you are not happy with current guidelines. Jogers (talk) 11:03, 1 February 2007 (UTC)[reply]
Since this discussion is not really about how the bot performs a function, but about the function the bot performs, perhaps it would be better suited at the relevant manual of style page. Either a consensus already exists there, or one can be discussed. HighInBC (Need help? Ask me) 19:28, 1 February 2007 (UTC)[reply]
Much better location for this. Now, my opinion is that this bot is performing a valuable function in unifying the style of Wikipedia. I see no consensus to disallow this function. I believe it is in line with the current consensus, which while some object to it, remains. HighInBC (Need help? Ask me) 21:17, 1 February 2007 (UTC)[reply]
Not to argue, but can you point me to a place where this consensus is clearly enumerated? Because I've read quite a bit of the debate both here and at Piping, and I have yet to find overwhelming consensus. What I find is a lot of debate, and a lot of disagreement. And, don't the hundreds of editors who use the YiX feature as a tool count as a collective consensus in their own right? By characterizing the response as "some object to it" ignores what consensus is, and more importantly, that consensus can change, especially when folks realize the effects of a guideline. Remember, folks, we're talking guideline here. By definition, it's not a hard-and-fast rule, but having a bot enforce it like it is seems extremely unwise.
As to the actual issue about date formats, use of YiX links and user preferences, surely there's a way to fix the system so that all interests can be accommodated. I'd like to see the discussion focus there, rather than rehashing the bot issue. The damage done by the bot is done, and has been reverted in some cases. Those that want to make a case that date formats should trump all other interests should step up and make a case for why that's so much more important than useful YiX links. And, as I said at the beginning of this paragraph, if someone can point to a talk page where real consensus was expressed, I'd really like to see it. Akradecki 02:54, 2 February 2007 (UTC)[reply]

Hi. I've only skimmed over the above discussion, so correct me if I've misinterpreted the situation or something like that.

I would consider Joger's interpretation of the guidelines to be correct. Linking dates, at this point in time (hopefully that'll change soon), is primarily to allow preferences to work. While links like 2006 in music are okay if 2006 is standalone or in something like February 2006 in music, if they are part of a full date, it should be written 21 February 2006.

However, (s)he should take care with the effects of making such changes automatically, as the target was chosen for a reason — it was merely misplaced. One suitable solution could be: 21 February 2006 (see 2006 in music), which is even preferred by some editors when not working with full dates (e.g. "released in 2006 (see 2006 in music)"). Another suitable solution could be to recast the sentence or move the link such that the topical year link can be in a different place, but still part of a sentence.

I would not encourage edits that remove the target of links to pages like 2005 in aviation completely — rather, I would encourage that the best of both worlds be sought. Neonumbers 04:46, 2 February 2007 (UTC)[reply]

This is a great solution. Easter egg links are usually bad anyway, because people assume they just point to the year page and don't follow them, especially when they're part of a full date — your solution actually shows people where the link goes. But changing them in this way may not be possible for a bot. Stephen Turner (Talk) 05:25, 2 February 2007 (UTC)[reply]
I bet that nobody will fix this in several thousands articles by hand. In fact, the editors who raised concerns about the bot activity don't seem to be interested in fixing this at all. Jogers (talk) 14:37, 2 February 2007 (UTC)[reply]
Jogers, that may simply be due to the fact that people are waiting to see the resolution before possibly wasting their time reverting what may get re-reverted again anyway. I am curious, though, as I asked in the Wikipedia talk:Manual of Style (dates and numbers)#Year linking and delinking section above, isn't there a way to modify the coding so that both the user's date preference AND the "year in x" links will both work? This would seem to be an excellent compromise outcome. Askari Mark (Talk) 19:03, 2 February 2007 (UTC)[reply]

But the editors that raised concerns about the bot activity didn't believe that what Jogersbot was doing was fixing it. I'm not siding them, I'm just saying that one needn't and shouldn't come at the sacrifice of the other. It goes for both sides.

Would it be possible to change:

On [[21 February]], [[2003 in film|2003]], John Smith directed a film.

to:

On [[21 Feburary]], [[2003]] (see [[2003 in film]]), John Smith directed a film.

by bot?

It's not the ideal solution (the ideal would be to work the link elsewhere into the sentence/paragraph), but it's better than removing the "in film" part altogether. Neonumbers 10:46, 3 February 2007 (UTC)[reply]

I agree that this is not an ideal solution but it is possible to do by the bot. Jogers (talk) 12:07, 3 February 2007 (UTC)[reply]
Tossing my opinion here. What Jogers's bot has been doing is completely in line with existing guidelines. Given the current state of date formatting that relies on user preferences and wikilinking, it is incorrect and inappropriate to link the year portion of complete date to a year in topic. I've no objection to year-only links to topic articles, although the easter egg factor and clarity of linking is something to consider. I think Neonumbers's suggestion for separating the year in topic links from the complete date is a workable compromise. older ≠ wiser 12:42, 3 February 2007 (UTC)[reply]
Jogers's work is following the MOS. I am surprised to see this much opposition. I have not run into it when I removed some of these links myself. While I don't think the Easter egg issue is that convincing, the preferences functionality is a very important issue. Rmhermen 20:18, 4 February 2007 (UTC)[reply]
I doubt that can be done safely by bot. I suspect there would be too many exceptions that would require you to read the whole sentence and surrounding sentences. Stephen Turner (Talk) 17:17, 3 February 2007 (UTC)[reply]
You are right. I've just realized that. Jogers (talk) 12:26, 4 February 2007 (UTC)[reply]
The problem I have with separate annotation of "(see Year in X)" is that in writing articles about aircraft, we typically end up identifying a number of historical events: first flight, initial and final delivery dates, service entry, retirement, notable events in its operational history, etc. Accordingly, you would have it popping up several times, making it an eyesore as far as readability goes. Still, I find Neonumbers' proposal much preferable to the current situation. It's also far preferable to repeatedly having to try writing unawkward single or multiple sentences to capture the preference-linked date on the one hand and the "year in x" year (or date) separately. Askari Mark (Talk) 22:10, 4 February 2007 (UTC)[reply]

Billion / Thousand Million

As per discussion on Talk: United Kingdom, it would be useful if we could get 'thousand million' the preferred wording for articles of a UK focus rather than 'billion', as 'billion' is ambiguous in UK contexts. To some it's 109 and to others it's 1012. 'Thousand million' is unambiguously 109, and thus preferable for UK contexts. Thoughts? Matthew 12:28, 3 February 2007 (UTC)[reply]

I don't think it's ambiguous any more. Of course billion used to be 1012, and ought logically to be 1012, and I wish it were still 1012, but it's never used that way now. (Can you prove me wrong by citing any counter-example from a major publisher in the last five years?) Stephen Turner (Talk) 17:24, 3 February 2007 (UTC)[reply]
Not sure that counter-example would stack up, as Wikipedia isn't being edited by a major publisher with (in theory) consistent editors, and just because they do it doesn't mean it isn't ambiguous. However, Fowler's Guide to Modern English Usage (3rd edition) says that 'the older sense "a million millions" is still common'. Alternatively, there's what the people at the OED write on the matter. Matthew 17:39, 3 February 2007 (UTC)[reply]

I don't think anyone has used billion to mean a million million in about 10 years - not in anything official/formal, anyway. --Tango 17:58, 3 February 2007 (UTC)[reply]

I don't dispute this. However, Wikipedia is neither official nor formal, hence the ambiguity of 'billion'. Matthew 18:18, 3 February 2007 (UTC)[reply]
Perhaps its first use in an article should be annotated as "billion (109)" just for clarity's sake. Askari Mark (Talk) 18:24, 3 February 2007 (UTC)[reply]
Wikipedia is definitely formal... --Tango 12:01, 4 February 2007 (UTC)[reply]
Yeah, Wikipedia's certainly a formally written work, and should follow formal writing standards.
I'd still say "billion" is ambiguous though. I mean, personally, I think it's always 109... isn't it a British thing? (Note "British thing" not "Commonwealth thing"...) The first-use-in-an-article suggestion's not a bad idea. Neonumbers 09:59, 5 February 2007 (UTC)[reply]
I'm British, and I haven't heard anyone use billion to mean million million in the last 10 years. --Tango 11:08, 5 February 2007 (UTC)[reply]
Hmm... interesting... perhaps it's not ambiguous then. Okay. Neonumbers 01:27, 7 February 2007 (UTC)[reply]
Yes, perhaps it's not too ambiguous but thousand million is decidedly unambiguous. I'd rather see a recomendation to prefer thousand million for 109 and scienfific notation for 1012 and over (where convienient). Jimp 00:22, 20 February 2007 (UTC)[reply]
It seems to me that billion should be edited to indicate that usage on Wikipedia is 109. MOSDATE should recommend that billion be wikilinked when ambiguity might arise. Walter Siegmund (talk) 02:39, 20 February 2007 (UTC)[reply]
I'm not sure that Wikipedia is in the business of defining usage of given word across the encyclopædia as a whole. I would argue that it should not be. Nor do I believe that there exists an precident for articles about general topics to discuss issues internal to Wikipedia. If there is a concern about ambiguity here, I don't believe that such a solution will work for it would require readers to refer to some article in order to understand a word as used on Wikipedia. Jimp 05:03, 20 February 2007 (UTC)[reply]
I agree. We don't prescribe, we describe. More explicitly, Wikipedia is not a usage guide. If something can be ambiguous, avoid the ambiguity. In this case, that means using 'thousand million'. -- Donald Albury 00:43, 21 February 2007 (UTC)[reply]
Those are good points. I would say, though, that the use of billion to indicate 109 is a good description of usage on Wikipedia.[6][7] Billion is a WP:DAB page. While I agree that the MOS should not be linked, in most cases, from article pages, ample precedence exists for links from disambiguation pages, e.g., Link and Heading. If I might quote from WP:MOS, "One way is often as good as another, but if everyone does things the same way, Wikipedia will be easier to read and use..." Walter Siegmund (talk) 18:40, 23 February 2007 (UTC)[reply]

Mark 8 vs Mark VIII

There is a discussion going on at Talk:Daedalus class battlecruiser (from Stargate) regarding how the name of a piece of fictional technology should be written. Is it "Mark VIII tactical nuclear warheads" or "Mark 8 tactical nuclear warheads"? The name is only ever spoken on the show, and we have no written reference supporting either notation. Any comments? --Tango 22:46, 4 February 2007 (UTC)[reply]

Have you tried checking the Stargate webpage? If it's mentioned there, use whichever they use. If not, "Mark VIII" is more traditional than "Mark 8" and therefore the more likely, so I'd opt for the former until such time as the show's webpage publishes something different. Askari Mark (Talk) 02:20, 5 February 2007 (UTC)[reply]
I haven't checked personally, but I doubt it will be there. It's just a throwaway line, I doubt anyone really considered what to name them, just whoever was writing that script picked a name out of thin air. If someone publishes an official "technical manual", then we're sorted, but I don't believe there is one yet. --Tango 10:54, 5 February 2007 (UTC)[reply]

$, USD$, €

Which is correct or are both wrong? There appears to be inconsistency is applying currency formatting. http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style_%28dates_and_numbers%29#Currency Is USD$ the default symbol and currency for currency. When use a numeric example USD$ is a mouthful. Can I use €?

If you bought a machine for €100,000 and it has a life span of 10 years and it can prodcue the same amount of goods each year, you would match €10,000 of the cost of the machine to each year rather than charge €100,000 in the first year and nothing in the next 9 years.
If you bought a machine for $100,000 and it has a life span of 10 years and it can prodcue the same amount of goods each year, you would match $10,000 of the cost of the machine to each year rather than charge $100,000 in the first year and nothing in the next 9 years.

NilssonDenver 08:52, 6 February 2007 (UTC)[reply]

The manual of style recommends US$, not USD$. Although it also says that in an article specifically about the United States, you can just use $ with a note at the top of the article to make it clear which dollar you're talking about.
With Euros, you can just use € because there is no ambiguity between different types of Euro, although it should be linked the first time it occurs in case the reader is not familiar with the symbol.
Did that answer the question?
Stephen Turner (Talk) 16:25, 6 February 2007 (UTC)[reply]
To wit, there are other nations besides the U.S. that use the "dollar" and the dollar sign ($). Askari Mark (Talk) 18:22, 6 February 2007 (UTC)[reply]

It's USD or US$, the D stands for Dollar, so you should never have both the D and the $-symbol. However, in the case of an arbitrary currency used for an example, I'd just pick any symbol you like. It doesn't matter if it's US$ or CAN$ or Z$ or any other dollars, so just say $. (Or €, or £, or ¥, or whatever else you like.) --Tango 20:23, 6 February 2007 (UTC)[reply]

In your "If you bought a machine ..." examples above I don't think that it really matters what dollar you're talking about. Like Tango says: just use whichever you like. Jimp 06:31, 7 February 2007 (UTC)[reply]
So he should have used ¤, I suppose. (I still think the currency symbol belongs after the value plus a space, just like pretty much every other unit does.) Christoph Päper 12:37, 8 February 2007 (UTC)[reply]

Thank you for all the contibutions. The guide seemed to imply that US$ or $ must be used unless it is country specific. Being European, I don't see the dollar as the only currency in the world and the Euro € is now a dominant and recognised currency and symbol. So first in on the article gets dibs on the symbol :-> (it also says that in the manual) NilssonDenver 21:47, 8 February 2007 (UTC)[reply]

What about date ranges?

We're guided to wikilink complete dates, for user date formatting preferences, like so: 14 November 2006. But what about 14-26 November 2006? — SMcCandlish [talk] [contrib] ツ 18:33, 12 February 2007 (UTC)[reply]

This is a big problem. There seems to be no way to do this without messing up someone's date preferences, other than [[14 November]] [[2006]] – [[26 November]] [[2006]]. Stephen Turner (Talk) 19:01, 12 February 2007 (UTC)[reply]
Date preferences don't apply for most readers (as they have no accounts) so it's only a problem for those who have accounts, and have prefs working the other way. Most readers will see date ranges according to the way they are written, and they will appear correctly. I've been treating date ranges by applying the correct format for the article.
Of course, this would be another nice thing to have if we are ever going to get rid of linked dates - date ranges formatted correctly according to prefs. --Pete
Actually, date preference linking does have some effect, even for people who are not logged in, as far as the formatting goes (commas or the lack of them, for example).
I usually ignore those who insist on using formats that will never work right anyway when the date doesn't include a year, so [[14 November]]–[[26 November]] [[2006]] (i.e., 14 November–26 November 2006) will have acceptable results for most users. Gene Nygaard 03:23, 14 February 2007 (UTC)[reply]
If you decide to ignore the effects for some people's preferences, it is better not to link the dates at all. That way it will look at least consistent (e.g. 14 November–26 November 2006). To me the above example looks like "14 November–2006-11-26", which is clearly not acceptable. −Woodstone 08:18, 14 February 2007 (UTC)[reply]

UTC± Notation

If the notation for a time range five hours ahead of UTC is UTC+5, then shouldn't the notation for five hours behind be UTC−5, not UTC-5? It seems like it should be a minus, not a hyphen, for consistency. 155.33.61.98 20:02, 14 February 2007 (UTC)[reply]

Question

Are you always supposed to link dates? This page doesn't seem to address that. – Lantoka (talk) 23:50, 17 February 2007 (UTC)[reply]

See above for discussion on this point, but the short answer is that if you wikilink full dates, then they are formatted correctly to user preference. --Pete 10:04, 18 February 2007 (UTC)[reply]
I'm not sure why you say the page doesn't address that. It seems to me to discuss it at great length. In particular, see the sections Dates containing a month and a day and Partial dates. Stephen Turner (Talk) 10:10, 18 February 2007 (UTC)[reply]
Ah, I see. Took me a minute to puzzle through that one. Those two sections make it clear that if you do link you should do it their way so that user date preferences work, but don't explicitly state that dates should be linked all the time. Thus my confusion. Thanks for the responses. – Lantoka (talk) 08:02, 19 February 2007 (UTC)[reply]

Clarification

The section on birth/death dates does not explicitly cover the situation where the date of birth is fixed, but while death is certain, the exact date is not known. For example, consider Amelia Earhart and Fred Noonan. They were last seen on 2 July 1937 en route to Howland Island in the western Pacific. There is no concrete evidence regarding their demise. They may have died in a crash, reached land somewhere and survived briefly as cast-aways, etc. However, by now they are certainly dead. Consider Fred Noonan: what is well-documented are

What should the correct format for birth/death dates be in this case? For the moment, it is listed as (4 April 1893-c.1937). There has also been a suggestion that this could be something like (4 April 1893-missing 2 July 1937, declared dead 20 June 1938). Any input?

Ronnotel 15:30, 21 February 2007 (UTC)[reply]

My view is that this is sufficiently uncommon that we don't need guidance about it in the Manual of Style; a solution appropriate to each individual article can be decided on a case-by-case basis on that article's talk page. Stephen Turner (Talk) 16:09, 21 February 2007 (UTC)[reply]

Binary prefixes

I have tolerated them until I read a (wikipedia) article about Flash RAM that used Mebibits. I am now completely against the use of the "IEC", units and converting every instance of xB to xiB (as some users such as Sarenne are doing). If voting were still open, it would go to The MoS should discourage the use of IEC prefixes anywhere. Otherwise you're just empowering the Bobblewiks of the world. - Diceman 09:22, 23 February 2007 (UTC)[reply]

Also, if official sources give the numbers in KB/MB/GB, using IEC prefixes is original research. jgpTC 09:28, 23 February 2007 (UTC)[reply]
Converting measurement units from one type to another is NOT original research. If you think it is, you need to reread that policy. Raul654 03:28, 25 February 2007 (UTC)[reply]
Trivial interpretation or paraphrasing of sources is allowed, we paraphrase sources all the time. If HP calls their new laptop a "mobile workstation", we can still call it a laptop. Similarly, when one is talking about certain things in computing, it means XiB, period. XB may be used in marketing materials, but many things may be used in marketing materials that we should paraphrase. If a news report says that the only two people present somewhere were "an older man and a younger woman", it is not OR for us to do trivial math and say that two people were there. Seraphimblade Talk to me Please review me! 09:50, 23 February 2007 (UTC)[reply]
But... that's correct. Flash RAM is in powers of two, no? — Omegatron 15:07, 23 February 2007 (UTC)[reply]
I don't see any reason why it shouldn't be revisted if the guidelines are clearly confusing, or result in confusing articles. Which they do. — Arthur Rubin | (talk) 15:56, 23 February 2007 (UTC)[reply]
No they don't. Can you provide some evidence? There have been many votes and discussions about this and the consensus is always the same. That's why we put it in the MoS. "When there are disagreements, they are resolved through polite discussion and negotiation, in an attempt to develop a consensus. If we find that a particular consensus happens often, we write it down as a guideline, to save people the time having to discuss the same principles over and over." — Omegatron 16:52, 23 February 2007 (UTC)[reply]
Have to agree with Omegatron. We've seen almost every possible argument for and against the IEC prefixes, so short of some new compelling evidence that they cause people undue duress, I still wholly support their use in appropriate situations. As far as I can tell, the main argument against the prefixes so far is that some editors don't like them and that they aren't common usage. The original research argument doesn't hold any water. This is trivial interpretation that any intelligent and competent editor can adequately perform. We are merely talking about the difference in the reader having to interpret what "MB" means in context, or the article editor having to discern where it is appropriate to use (the SI meaning of) "mega" and "mebi", respectively. I'd prefer the latter since the article editor will (usually) be more competent than the lay reader. -- mattb @ 2007-02-23T18:06Z
I've seen every possible argument for the IEC prefixes, and still see no reason why they should be used, either generally or on Wikipedia. The person reading the article typically does not know what a "mebibyte" is; Wikipedia is not for propagating and enforcing IEC standards. —Centrx→talk • 19:25, 23 February 2007 (UTC)[reply]
And I agree with Diceman, specifically when talking about articles on vintage technology. Especially when all original production material for the product in quesion, and all cited reference material in the entry don't use these "new standards". "Appropriate to use" is a very open ended term, especially the way its being written in the current MOS, which is seen by some as giving them carte blanche to go through every single article and change every single use of Mib, etc. As far as merely "the reader having to interpret", I think that statement doesn't hold water. I've seen entire passages in entries, having been cut or riddled with reference citation requests based on the fact that the reader here is seen as someone who *can't* easily discern and must be lead around. --Marty Goldberg 18:53, 23 February 2007 (UTC)[reply]
Okay, I'll put a fine point on it. "Appropriate to use" means "appropriate in any context where the IEC prefixes are more accurate than the common (incorrect) usage of SI prefixes." 4 GiB RAM is appropriate, 372.5 GiB hard drive (as opposed to 400 GB) is probably not appropriate. The argument of "stick with tradition" has no value in my opinion. To me this makes as much sense as saying that we shouldn't prefer the usage of SI standards in American English articles because imperial units are by far more common in American English. Anyway, all these arguments have been posed before. As Omegatron suggested, I'd like to see a handful of places where the usage of the IEC prefixes has caused undue confusion. I think you'll find that most of the conflict over this issue is in the form of editors who dislike the prefixes clashing with editors who like them. The MOSNUM currently suggests that the first usage of IEC binary prefixes be linked so the curious reader can quickly read about their definition and the reasons for their existence. -- mattb @ 2007-02-23T19:17Z
The common usage is not incorrect. —Centrx→talk • 19:31, 23 February 2007 (UTC)[reply]
It is just incoherent... When you use 512 MB for RAM and 500 MB for hard drive in the same article, the two "MB" don't have the same meaning so at least one of the "MB" is incorrect.Sarenne 19:43, 23 February 2007 (UTC)[reply]
Sorry, how about "non-standard use of SI" or "usage of SI prefixes not endorsed by BIPM" or "incorrect insofar as SI is concerned". However you wish to call it. -- mattb @ 2007-02-23T19:35Z
And this is where you'll find I'm still in disagreement. That's a strawman argument calling for examples of confusion as a basis for change, when Wikipedia has no such capacity to provide that in the first place. You'd have to poll all readers (as opposed to editors) of a page on their thoughts of confusion. As someone who writes in the video game and computer industry (and specifically in historical aspects), its my professional opinion that an entry that is on historical themed subject *is* made more confusing by these. Especially when references, paraphrases, and quotes within the entry all use "older" standard. It'd be a different matter if it was a more recently released product as was mentioned above - I totally agree with you on that context. Oh, but you'd find us on opposite sides on the SI standards issues as well. ;) --Marty Goldberg 19:38, 23 February 2007 (UTC)[reply]
The BIPM is not an authority on the English language. If you want to include a mention of mebibits in the International System of Units article, fine, but that does not mean that these prefixes will be understood by most readers, or are anything beyond alternative uses along the lines of American and British spelling. —Centrx→talk • 19:41, 23 February 2007 (UTC)[reply]
(edit conflict x many)
In the context of memory, it's likely to be more accurate; but the terms are still not in common use, even among technically literate people and organizations. And, "mebibyte" is unpronouncable by a large number of people (I can probably find a source for that, if you want, but anecdotal evidence suggests that 10-20% of my co-workers cannot pronounce it); even if the abbreviations is acceptable and appropriate, the term themselves may not be.
Furthermore, have any other standards organizations picked up on the terms? There's been enough time since introduction for some other standards organizations to pick up on it if they find it appropriate. If they don't, we probably shouldn't. If that's the case, it's technical jargon which should be avoided when possible; even if it may be more accurate. — Arthur Rubin | (talk) 19:43, 23 February 2007 (UTC)[reply]
I see it has been accepted by some standards organizations, but it's still unpronoucable. — Arthur Rubin | (talk) 19:49, 23 February 2007 (UTC)[reply]
It makes little difference if something is picked up by standards organizations but is not picked up by people or non-standards publication. The IEC making a decree is not going to change the fact that your co-worker or computer science PhD is going to rightly laugh in incredulity if you use the term. Though, "MiB" is a much more reasonable construction than the word "mebibyte", which appears to have been invented by someone with no concept of language or speech. I wonder if you could find even an IEC engineer who uses the word in his everyday speech. —Centrx→talk • 22:37, 23 February 2007 (UTC)[reply]


I'd also like to point out that patronizing users for applying MOS style guidelines is misdirected agression at best, harassment at worst. There's no need to pick on Sarenne when you know the proper place to take up your issue with a style guideline (here). Revert warring is also totally inappropriate behavior. The MOS currently endorses IEC binary prefixes and states that they are to be kept if added to an article. Until such a time that this guideline changes due to consensus here, you should not engage in edit warring or use reverting to make a point. [8], [9], [10], [11]-- mattb @ 2007-02-23T19:22Z
This isn't the user's talk page; you can leave your denunciations out of the Manual of Style talk page. —Centrx→talk • 19:30, 23 February 2007 (UTC)[reply]
I could, but I won't. I find it relevant enough to mention here, I am very sorry if you disagree. Since this has come up before and it seems to have come up again, in the context of semiconductor memory, the binary prefixes are nearly universally appropriate. It simply does not make sense to produce RAM arrays in multiples of non-binary powers due to the binary addressing used by microprocessors. If an oldish computer was advertised with 32 KB/kB RAM, you can bet your buttons that 32×210 bytes was the quantity meant, not 32×103 bytes. -- mattb @ 2007-02-23T19:35Z
Your justification has nothing to do with your above comment, which was about revert warring. —Centrx→talk • 19:38, 23 February 2007 (UTC)[reply]
You misunderstand, the latter comment wasn't intended as a justification, just an additional tidbit to add to the discussion. Frankly I don't feel the need to justify my revert warring comment to you. -- mattb @ 2007-02-23T19:39Z
Then you should remove it. —Centrx→talk • 19:42, 23 February 2007 (UTC)[reply]
No. I don't feel I said anything that is out of line with rules or policy. I could construct a lengthy response to the above objections, covering territory we've been over probably five times or more. Frankly, I'm tired of debating this every other month. If you feel that there's enough consensus to change the policy, I'm totally agreeable to another vote. The experienced editors here have already seen every significant argument in this debate and have their respective opinions. Another vote will be a lot quicker than rehashing all the arguments again. :) -- mattb @ 2007-02-23T19:46Z
I looked a some of the previous voting archives on the matter as well, and a lot of it seemed inconclusive. Even a majority of those that voted for the IEC use still mentioned their own personal opinions on exceptions or stipulations regarding concurrent useage of the two. --mattb @ 2007-02-23T19:46Z

I'm still not seeing any evidence that anything has changed. A few editors have a personal vendetta against it, as they always have. So what? These units are still to be used wherever appropriate. "Appropriate" means "where the actual size is important and the actual size is a power of two". Things like "hundreds of megabytes" don't need to be changed, but things like "a 512 MB Flash RAM chip" should be.

To me this makes as much sense as saying that we shouldn't prefer the usage of SI standards in American English articles because imperial units are by far more common in American English.

Exactly. Accuracy and uniformity trump jargon and tradition; this is an encyclopedia. — Omegatron 21:28, 23 February 2007 (UTC)[reply]


And I'm still not seeing any evidence to the contrary of myself and others posting their views here. This *is* an encyclopedia, not a technical reference manual. It requires research and revision based on content and subject, not blind application. If I have an article who all source materials, quotes, referenced materials, etc. uses a specific older standard, simply editing that out creates more confusion not accuracy. Simply brushing it off as a "personal vendetta" is irresponsible, and the same claim could be made for those who do blind edits to promote that useage. It would be much more accurate to allow for content that uses both but describes one as being more accurate to current standards and revisions. And I'm not talking across the board on this either, as I said, I agree with you for newer devices. But when I'm writing within the context of a historical device, the useage and conventions of the time are equally as important from a historical accuracy standpoint. You can't be accurate in one respect and inaccurate in another. --Marty Goldberg 21:35, 23 February 2007 (UTC)[reply]
The usage and conventions of the time were incoherentinconsistent. Like I said in your talk page, the same MB unit was used to mean 1000*1000 B (hard drive capacities) and 1024*1024 B (RAM, ROM, cache...). Even if you don't want to use MiB within the context of a "historical device", the articles are innacurate (or incoherent). The easiest way to make them accurate is to change the "memory" MB to MiB. Sarenne 22:22, 23 February 2007 (UTC)[reply]
That seems pretty coherent. And the articles would also be more precise if we changed words in quotations, or invented other words defined through some explicit logic, but this is the English-language Wikipedia, not the IEC-language Wikipedia or the Derrida-language Wikipedia. —Centrx→talk • 22:44, 23 February 2007 (UTC)[reply]
Once again, that has nothing to do with historical accuracy. Ancient cultures saying the sun god blotted out the sun, when its more "coherent" to say its an eclipse, doesn't make it any less of importance for useage or inclusion. You just denote the difference and way, but both still must be reported. It *was* the standard, and is historically accurate to represent it as such. Once again, when talking about the context of historical content you can't be accurate in one respects and innacurate in another. Circular reasoning again. --Marty Goldberg 22:28, 23 February 2007 (UTC)[reply]
And fact remains that the sun is blotted out. It is a vagueness, not an incoherence. —Centrx→talk • 22:39, 23 February 2007 (UTC)[reply]
Actually by "incoherent" I meant "inconsistent".
So, what *was* the standard : 1 MB = ....... B ? Sarenne 22:42, 23 February 2007 (UTC)[reply]
Actually, if everyone is using it at the time, that's pretty consistent. As stated below, 1 MB was stated as 1024KB or "About a 1000 kilobytes". --Marty Goldberg 22:56, 23 February 2007 (UTC)[reply]
"About a 1000 kilobytes" is not accurate. 1 MiB is. Sarenne 23:07, 23 February 2007 (UTC)[reply]
Again, being circular and repeating something you already stated above which has nothing to do with the current conversation. This is why I gave up with the talk page discussion. You just asked what the standard was then, and I gave it. It was accurate for the used definition at the time. Mib didn't exist, its a new standard. People agreed "its about 1000KB" or "1024KB" as the definition, that was the definition of accuracy at the time. The IEC decided recently to redefine it so that MB actually refered to as 1000 (and more closeland whipped up a new wording of "bibytes" to compensate. --Marty Goldberg 00:17, 24 February 2007 (UTC)[reply]
You didn't give *the* standard. "About a 1000 kilobytes" has never been accurate and has never been a standard. There were 2 different standards (one official, the other was just a (bad) convention) at the *same* time : 1 MB = 1000*1000 B and 1 MB = 1024*1024 B. These incompatible standards were used at the same time for different purpose. It is inconsistent to use both standards in the same article. MB cannot accurately mean 1024*1024 B and 1000*1000 B in the same article of an encyclopedia. By the way, IEC never redefined MB. Sarenne 00:40, 24 February 2007 (UTC)[reply]
Yes, I *did*. Per the IEEE-CS computer terms - "MB Megabyte, 1024 Kilobytes". Likewise, the IEC did redefine it. Per the Wiki entry for Megabyte: "In the past few years, standards and government authorities including IEC, IEEE, EU, and NIST, have addressed this ambiguity by promoting the use of megabyte to describe strictly 1000² bytes". Again, anything to run around in circles instead of keep the conversation in context. --Marty Goldberg 00:57, 24 February 2007 (UTC)[reply]
Can you provide an actual standard that defines the term megabyte thusly? Or are you just using common usage again (nobody here is trying to argue what common usage is). IEEE 1541 is IEEE's official endorsement of the IEC binary prefixes. Is there a similar prior endorsement of the <SI prefix> + "byte" construction to denote powers of two? -- mattb @ 2007-02-24T01:23Z
Huh? Nobody is stating anything contrary to 1541. The question asked was a) Was there an old standard (i.e. before that), and b) What was it. The IEEE-CS terminology I provided was directly from them, an actualy listing of their definition from the past. --Marty Goldberg 01:28, 24 February 2007 (UTC)[reply]
This is exactly what I meant to ask, can you provide a reference showing that IEEE ever officially endorsed the common usage of "megabyte"? Simply using it in that context doesn't imply endorsement, while we have IEEE 1541 to show us that the IEEE clearly endorses these new prefixes in appropriate computing contexts. IEEE-CS is just one of the many IEEE societies, not a standard or a statement of official endorsement of prefixes. You made the assertion that the binary power usage of "megabyte" et al was an "industry standard", which is something more than just common usage. I'm asking if you can show some support for this beyond saying "the IEEE has used the terms in this context before". I'm not meaning to be antagonistic, but merely to point out that there is a difference between common usage and a standard.-- mattb @ 2007-02-24T01:55Z'
I'm not going to bother looking because it doesn't really matter. Wikipedia is not an implementation of standards documents. It is the English-language Wikipedia, and the OED is quite fine for that purpose. —Centrx→talk • 18:18, 24 February 2007 (UTC)[reply]
IEEE-CS is not IEC, "promote" is not "redefine", 1024 is not 1000 and "About a 1000 kilobytes" is not a standard for a unit. You seem to have an issue with accuracy but if a contributor wants to make Wikipedia more accurate or more consistent, you shouldn't stop him just because you think that Atari articles must match exactly what used to be Atari brochures or what used to be the common usage 20 years ago. If you want a snapshot, quote. Sarenne 01:34, 24 February 2007 (UTC)[reply]
1)"IEEE-CS is not IEC", what does that have to do with anything? Once again, the question was a)Was there a standard before and b) what was it. 2) If there's a definition before and a newer definition is promoted, that's a redefinition. 3) That's correct, 1024 is not a 1000 which is why Megabyte or MB was defined as "1024KB or 'About a Thousand'". 3) You seem to have an issue with context, historical accuracy, and circular reasoning and etc. The simple fact that you call "historical accuracy" a "snapshot" betrays this, if not a bit condescending. And even more circular, if someone is interested in accurately portraying industry wide useage of an item (such as Atari consoles and computer, Amiga, etc. etc.) from 20 - 25 years ago in an entry that is about said product from 20-25 years ago, you shouldn't stop them. And once again, I'm not saying the SI standards shouldn't be used in any of these articles, I'm saying that the older standards should not be wiped out completely from the entries in favor of it. For someone who keeps pushing consistency, the idea of historical consistency with said brochures, articles, manuals, design documentation, and general references that are used in the entry, seems to escape you as well.--Marty Goldberg 01:48, 24 February 2007 (UTC)[reply]
What you call "historical accuracy" is an inaccuracy and inconsistency. Wikipedia doesn't need to be accurate with brochures, articles, manuals, design documentation if they are inconsistent or inaccurate. If you want to quote Atari brochures to "accurately portray industry wide useage", i will not stop you... but you should quote it, not paraphrase it. Sarenne 02:09, 24 February 2007 (UTC)[reply]
And here we go around in a circle again. It is inaccurate compared to the current standard, not inaccurate for the standard that was used at the time of these. And then you asked a) Was there a standard and b) What was it. And then......here we go again...... --Marty Goldberg 02:14, 24 February 2007 (UTC)[reply]
"1024KB or 'About a Thousand'" has never been accurate nor "historicaly accurate", and never will be ! It is inaccurate by itself. Sarenne 02:24, 24 February 2007 (UTC)[reply]
Once again proving you're not understanding the context of "historicaly accurate" or even the context of the word "accurate" being presented. If it was used as the industry standard then, used in said material, said subject, etc. etc. etc., in order to maintain historical accuracy you must present it as such to maintain that accuracy. If I have an exhibit in a museum about a caveman, I don't give him a ferrari, that would be historically inaccurate and defeat the purpose of the display. If I'm presenting an entry on a historical topic (i.e. vintage computers, video game systems, etc.) I don't completely wipe out all reference to what was actually used then, otherwise its "historically inaccurate". Or is that context still not understood? --Marty Goldberg 02:32, 24 February 2007 (UTC)[reply]
You want to maintain an "historical accuracy" and not about Ataris but about industrial "standards". It is not the purpose of an encyclopedia. That's exactly what I said : you want a snapshot, so *quote*. Sarenne 02:45, 24 February 2007 (UTC)[reply]
Of course historical accuracy is a purpose of the encyclopedia. You're giving a complete and accurate (in all respects, including historical) representation of the subject matter. Its exactly what I said: you don't understand the context, so *quote*. But please, keep adding more and more accusations about what I mean and what's being said, so we can go around in circles even more. --Marty Goldberg 02:54, 24 February 2007 (UTC)[reply]
We don't have to reproduce errors, inconsistencies and inaccuracies just because it would be "historicaly accurate". Wikipedia is not an encyclopedia of 1980. EOT Sarenne 02:57, 24 February 2007 (UTC)[reply]
It is however an encyclopedia of subject matter from 1980, which has an appropriate context and historical accuracy. Wikipedia is an encyclopedia, not a technical manual. Its job is to discuss and present the topic/entry as a whole, even if the topics are now considered technicaly innacurate. But please, please mean the EOT. Or are you going to post something else and I can come back and edit out the EOT because its now an error and innacurate? (Though you did say it, so it would still be historically accurate) --Marty Goldberg 03:02, 24 February 2007 (UTC)[reply]
It *was* the standard
No. It wasn't. — Omegatron 22:31, 23 February 2007 (UTC)[reply]
Yes, it was the industry standard at the time. I'd be happy to provide technical document references, plans, brochures, and other material that used it across the board. The common explinations at the time in text books, the press, etc. etc. that MB was actually 1024k or "about a million kilobytes" as was also used. --Marty Goldberg 22:38, 23 February 2007 (UTC)[reply]
Then make sure the first use of MiB is blue-linked, and discuss the old usage in that article. There, now we've got our historical accuracy, without saying in our voice that the gods really are blotting out the sun. Seraphimblade Talk to me Please review me! 22:34, 23 February 2007 (UTC)[reply]
Not quite, because it still leaves the confusion when quotes and referenced material do not. And no need for emotional sarcasm. --Marty Goldberg 22:38, 23 February 2007 (UTC)[reply]
If the use of it is in the prose, then it would be "mebibyte", not "MiB", which should be confined only to infoboxes and other places where space is tight. On that, links should be made according to context, not for every dictionary word that readers might not know. Unless the article is talking about storage standards or the IEC, "mebibyte" should not be linked. If a word is so obscure and novel that it must be linked in order for even the most literate person to understand, then it does not belong there as a used word. Wikipedia is not a vehicle for propagating marginal jargon. —Centrx→talk • 22:51, 23 February 2007 (UTC)[reply]
That's a silly line of reasoning. By that logic the Newton (SI unit of force) is too obscure and jargony to use because it is often linked in articles for the benefit of the reader. Even the most literate person in the world may well have no idea what the Newton is if they've had no significant exposure to physics (or have simply forgotten). Likewise, I wouldn't expect someone unfamiliar with computers to know what "ISA" or "KB" or indeed "KiB" mean. We link practically anything relevant in Wikipedia articles. Am I mistaken in believing that your argument tends towards "megabyte is part of the English language and mebibyte isn't"? (per your earlier comment about this being the "English language Wikipedia). I encourage you to note how many SI units, which are accepted for usage on Wikipedia, are based on non-English names. The Ampere, the Becquerel, the Coulomb, the Ohm, the Sievert, the Volt, the Pascal... All from non-English names. I realize you simply don't like the sound of the IEC binary units, but frankly I've never particularly liked the nomenclature "one millisiemens" (ending 's' is correct usage), but it's blessed SI, and I'd rather use a consistent standard than make up my own mind about "what sounds better". -- mattb @ 2007-02-24T00:47Z
One major difference: any physicist, even anyone who has taken a single physics course, knows what the Newton is and uses it as such. Computer scientists, computer programmers, computer users, do not use "mebibyte"; i.e. it is not even the term used in the field. Ampere, ohm, etc. are all used in English and were used in English more than 100 years prior to the IEC decree. They are all standard in the field. The sound of these words merely shows that they were inventions of engineers rather ignorant of language and its usage, and that they will not gain acceptance. Even if they are going to be accepted, they are not currently and it is not Wikipedia's place to use them when they are not used in the normal language. You personally are free to decide that you will use words handed down to you from on high, but Wikipedia is not prescriptive. —Centrx→talk • 18:30, 24 February 2007 (UTC)[reply]
See also e.g. French Republican Calendar. —Centrx→talk • 18:48, 24 February 2007 (UTC)[reply]
Well, several rather relevant standards bodies and professional organizations have adopted them, and a significant number (though a minority) of computer users and experts also use them. There are a handful of SI units that are NOT in common usage, even by experts (especially consider the mess surrounding units associated with ionizing radiation), yet we recommend adherence to SI because it is a recognized standard and helps keep articles consistent and unambiguous. The IEC prefixes solve an abiguity problem and (in my opinion) work for Wikipedia's purposes. I still don't understand why you are so passionate about deriding the construction of the words themselves, but I don't personally consider a slight aesthetical displeasure even slightly relevant. I do, however, encourage you to submit a proposal to a major standards organization detailing your own preferred construction of unambiguous binary prefixes which are not "ignorant of language and its usage". -- mattb @ 2007-02-24T20:47Z
Actually, there isn't a single book on Google Books that uses "mebibyte" or "mebibytes" as a word. There are four that have it listed in dictionary form. In contrast, there are hundreds of books that use "megabyte" as word, many of them published after 1998. I found one book, published 2001, that uses "gibibytes", with reference to an appendix because the term is so unfamiliar. In contrast, pick any SI unit and you will find hundreds or thousands of books that use the term as words. Even "millisiemens" has 20 times more books that even include the word than any of the binary prefixes. If there is some standard unit other than the SI unit for measuring ionizing radiation, that also should be used in favor of or alongside an unused SI unit. —Centrx→talk • 23:46, 24 February 2007 (UTC)[reply]
I see no reason to state that we shouldn't use an accurate technical term rather than an inaccurate but commonly-misused one, just because some people might not understand it. I would venture a guess that most people don't know what a joule is and would be very confused to hear a person talk about a mole of hydrogen-what do small burrowing creatures have to do with hydrogen anyway?? But if we're referring to something measured in moles, or joules, we should use that term. (And if we use moles, or joules, we should link to the appropriate page, specifically since many readers may come across those terms and want more information about them.) Similarly, if we're referring to something measured in kibibytes, or mebibytes, that is the term we should use. Do you think people only come here to read about things they already know? Seraphimblade Talk to me Please review me! 01:45, 24 February 2007 (UTC)[reply]
The joule and the mole are all commonly used in their fields, and are known by anyone who has taken even a high school science course. Wikipedia is not the place for introducing new language. Wikipedia articles do consist of things that the person already knows; that is prerequisite for the person learning new things, and articles do not suddenly "teach" a person something totally unrelated to what the article is about. If someone wants to learn about these new unit names, they can read the article about SI or IEC, etc. but if someone is reading about the iMac they should not be confronted with terminology that even the computer-savvy layman is not familiar with. —Centrx→talk • 18:47, 24 February 2007 (UTC)[reply]
Something additional I noticed, though this may be a bit off-topic... It is extremely common usage to denote binary capacities with the value and unit not separated by a space. On Wikipedia, we endorse the SI standard of placing a space between value and unit. I'm rather perplexed why nobody ever seems to bring this up. If we're so terribly concerned about common usage, wouldn't we ignore SI in this regard and write data capacities without a space between the value and unit? You don't have to venture far to find 100GB, 512MB, etc used in various forms of computer-related documents. Anyway, as Omegatron pointed out, this issue has always had its staunch supporters and fierce critics. There are definitely valid points on both sides of the fence, but my opinion remains unchanged and would be reflected in any potential vote. -- mattb @ 2007-02-24T01:27Z
It's possible we should, but there is a major difference in the two issues: the space does not change the meaning at all; it is purely formal, there is no danger of misrepresenting any source material, and the reader is unlikely to be perplexed or to even notice it. —Centrx→talk • 18:55, 24 February 2007 (UTC)[reply]

Yes, it was the industry standard at the time.

It certainly was not. Please provide evidence of this standardization. "MB" has meant 1,000×1,000, 1,000×1,024, and 1,024×1,024 bytes in different contexts and different times, and was never standardized. M- as a prefix has meant the same thing for hundreds of years, on the other hand.
Please read through the previous, endless, debates. This has already been discussed countless times, and you clearly have nothing new to bring to the discussion. Here's a start:


It most certainly was at one time. As stated, went through the archive already. I also already provided one instance of the IEEE using that as a 1024 standardization in its glossary. Likewise, as I stated it was an industry wide standard during the time period (1970's through 1980's), and most certainly for the historically entries items I was discussing about. The other inerpretations you mentioned came later, as the articles state as well. Once again, it was used across the board in documentation, promotional material, design specifications, etc. of the time. I also have several instructional text books from across that time spectrum where that definition is presented as the standard as well. Its not that there's nothing new being presented, its that its nothing you want to accept or listen to. Once again, very clearly, I'm not debating on its current use. I'm stating that previous definitions should be co-existing in entries on vintage hardware/topics so that historical accuracy is maintained. Especially within the context of cited references, reference material, or the like. As stated, I write in that area professionaly (historical analysis and exposition of vintage computer and video game topics), and I can't emphasize enough how important that is to maintain. --Marty Goldberg 03:45, 24 February 2007 (UTC)[reply]
As I tried to point out above, mention in a glossary does not constitute a standard in any way. It's acknowledgement of common usage at best. Also, I think it's even more confusing to have a policy endorsing the usage of IEC prefixes only for articles on "new" (by some arbitrary and as yet undefined distinction) topics. I don't see why we should have to use less accurate units in deference to historical usage. You don't see the article on the Great Sphinx of Giza reporting all its measures in cubits. -- mattb @ 2007-02-24T03:58Z
Once again, did not say only "new". I stated they should co-exist on "old". And yes, if I'm citing a passage, quotation, or reference of an original source that used cubits, cubits are indead mentioned. --Marty Goldberg 04:05, 24 February 2007 (UTC)[reply]
I don't believe anybody has suggested changing source texts. What does "co-existence" mean? Something like "The Nintendo included 2 KB (KiB) main memory"? That sort of thing is even worse than not using the IEC prefixes at all. I don't see any compelling reason at all to avoid usage of IEC prefixes in historical contexts; either the prefixes should or should not be used universally. The entire point of these things is for consistency and unambiguity. Picking and choosing historical contexts in which they should be used defeats the whole purpose. -- mattb @ 2007-02-24T04:11Z
Actually, yes, Sarenne had in his rants on my talk page, which is what prompted me to get involved in the topic here. He's also been going around making sweeping changes to every single appearance of MB/KB/etc. on every page, when the IEC/IEEE/Etc. is promoting those to still remain but cover 1000/etc. now. Unless he's gone and researched every single topic he's doing that in, the problem is there's the claimed confusion as to what a standard on MB meant. How does he know that he's not changing a 1000 item, that's supposed to remain as MB to an iB? And no, I wasn't suggesting the 2KB (KiB) thing, I agree that would look terrible throughout the text. But I think some kind of compromise can be worked out (which I've been more than willing to do), possibly using KiB in the text and the original specs in a more limited manner (infobox, or?) I'm sure there's something we can come up with working together. --Marty Goldberg 04:46, 24 February 2007 (UTC)[reply]
Yes, I must testify that people making mass formatting changes without reading or understanding the articles is liable to and does change the meaning. Separate from any issue of whichever form is most appropriate, this should not be done. Blind consistency produces error. —Centrx→talk • 18:59, 24 February 2007 (UTC)[reply]
As a rule of thumb, semiconductor memory contexts use multiples of binary powers and hard disks use multiples of decimal powers for reasons of addressing and marketing. Anyone familiar with computer architecture can verify this. Some other contexts aren't as cut-and-dry, but those two are pretty safe. -- mattb @ 2007-02-24T04:50Z
Why not present a short direct quote, say from a technical manual, if it's so absolutely imperative that "xB" be presented? Certainly, we must present direct quotes exactly as they were stated, as opposed to paraphrasing. Seraphimblade Talk to me Please review me! 05:08, 24 February 2007 (UTC)[reply]
That's kind of what I was thinking, possibly just in the system/machine specs box or initial presentation of system specs, having one xB/iB and using iB through the rest of the entry. It kind of prompts the reader (who is more commonly used to the xB reference) to question why the iB and click through on both of them (to learn about the new standards vs. old, which is what you want a reader here to do - learn), yet still keeps the historical accuracy and consistency with the support material present. --Marty Goldberg 17:09, 24 February 2007 (UTC)[reply]
How do you know that any {K,M,G}B reference, when used to refer to cache or memory sizes, isn't a 1024 item? Binary-coded decimal computers went away a long time ago, and it makes no sense whatsoever to cut short the memory capacity of a machine with binary addressing (I'm not sure how, for example, you'd limit a 1024*1024-byte binary machine to 1000*1000 bytes in hardware without adding a bunch of useless extra hardware or a pointless software hack). Can we please not waste any time whatsoever considering the possibility that any post-IBM 1400 series or Honeywell 200-series machine has a memory or cache size that's a multiple of 10? Guy Harris 08:18, 24 February 2007 (UTC)[reply]
Thanks for bringing up that example, it was kind of my point actually with the paragraph above. You have to be somewhat familiar with the hardware in question and what was actually being refered to before making a call on that sort of edit, especially with vintage hardware. The current set of "guidelines" and the way it was being interperpreted by some, would not have allowed for the BCD on some pre-IBM1400/Honeywell 200 series machines for example. Especially when doing almost robot like edits of every occurance of xB. --Marty Goldberg 17:09, 24 February 2007 (UTC)[reply]
Isn't there still a problem with the listed storage spaces not being in binary? If the box says "1 kilobyte", how do you know it's not really 1000 bytes or 1023 bytes without researching the issue rather than automatically changing it? Many times these terms are purposefully used in the vague sense, and where changing the unit is then simply wrong. —Centrx→talk • 23:50, 24 February 2007 (UTC)[reply]
If kilobyte/megabyte/gigabyte/terabyte is used to refer to a quantity of semiconductor memory (main memory, cache memory, flash, etc.), I know it's really 1024/1048576/1073741824/1099511627776 bytes because that's the way addressing hardware for that type of memory works. (Decimal computers were designed before semiconductor memory; machines such as the IBM 1400 series machines used core.)
For disk memory, the term is vague (for one thing, a sector typically has a power-of-2 number of bytes in it, so an "80 gigabyte" disk is unlikely to have 80000000000 bytes of data space on it). However, I don't think you'll find anybody advocating the use of the IEC terms for disk memory. Guy Harris 03:14, 25 February 2007 (UTC)[reply]
"The way it was being interpreted by some"? Could you put that in more concrete terms? I haven't seen Sarenne or others editing articles about computers from the 50s and 60s to use IEC binary prefixes. Your contentions have seemed to center around game consoles from the 80s, which as microcomputers, certainly use binary addressing. You're right that some familiarity with hardware is necessary to interpret this; are you familiar enough with all the hardware in question to mention what variety of microprocessor they used? As has been mentioned a few times before, most computers since the 1960s and very close to all microcomputers use binary number representation and binary memory addressing. -- mattb @ 2007-02-24T17:30Z
Actually, no, my contentions haven't seemed to focus around that. I said I deal in vintage computers *and* video game consoles, Sarenne kept bringing up and focusing on "Atari". And yes, I'm familiar with microprocessor varieties (or lack thereof for older computers). --Marty Goldberg 17:59, 24 February 2007 (UTC)[reply]
Okay, then where's the problem? I'm just asking for some specific examples for us to mull over. -- mattb @ 2007-02-24T18:07Z
I never said they did, you're missing the context again Matt, please reread. I simply said the way its being interpreted by some (and across the board robotic like edits) would not have allowed for for it, i.e. if they continue in the same manner, combined with the general way the guides are written, that would not allow for those older systems to retain their proper identifications. Unless there's some familiarity with the architecture, etc. Once again, when Sarene blindly states "Sources use decimal prefixes where the sizes are in fact binary. This has nothing to do with "vintage technology", yet that indeed isn't the case with vintage 50's and 60's computers, and then he's further calling for every single appearance of xB to be changed to SI and using the guidelines to justify it ("Yes, we *should* change every single 'old' reference... that's exactly why the MoS says that the use of the new standards should be accepted."), that's a pretty broad stroke and one has to assume he means it given the majority of his contributions listed have been iB edits. (And to clarify, I'm not knocking him for iB edits, so don't take it that way). I'm sure you'll come back with some response to brush this off, but this is important, or I wouldn't have brought it up. You think I like going through 2 full days of discussion? ;) --Marty Goldberg 18:38, 24 February 2007 (UTC)[reply]
I'm not calling for every single appearance of xB to be changed but, like the MoS states, I think we should accept every change xB => xiB when xB is beeing used in a binary sense, even if it is vintage technology, except if it is quoted material. If I change an xB that is actually used in a decimal sense then it's a mistake. Sarenne 18:53, 24 February 2007 (UTC)[reply]
You were previously calling for every single one to be changed, and stating it had nothing to do with vintage tech. I'm glad to see you revise your position then. It still needs to be clarified in the guideline then as far as this aspect. The other (single appearance of xB) is still being discussed above. --Marty Goldberg 19:02, 24 February 2007 (UTC)[reply]
You just misunderstood what I said. Yes, it has nothing to do with vintage technology and yes, every single 'old' xB (i.e. xB used in a binary sense) should be changed. That's exactly what the MoS says: "The use of the new binary prefix standards in the Wikipedia is not required, but is recommended for use in all articles where binary capacities are used." It's pretty clear, isn't it ? Sarenne 19:43, 24 February 2007 (UTC)[reply]
Serenne, I'm not picking up where we left off yesterday, I refuse to go around in circles like you like to. There was no missunderstanding, you said it in response to very specific statements by me that it shouldn't be across the board with vintage technology. Likewise in repsonse to my statement that (as we went through yesterday) for historical accuracy and continuity its not clear, and not accurate to do it across all references and documented material used in an article. And then I had to clarify for you what historical accuracy means, just as I previously clarified what "not required" and "should" vs. "must" means. Just as what's clear: "The following rules do not claim to be the last word on Wikipedia style." and "These are not rigid laws: they are principles that many editors have found to work well in most circumstances, but which should be applied with flexibility.". Hence the discussion a few paragraphs up about how to keep the historical accuracy for cited and referenced material while still using iB's as well. We're trying to reach a compromise here. If you have nothing concrete to add to coming up with a compromise and solution on that, then move on and please don't turn this in to another pissing contest full of sarcasm and claims about me, while repeating the same things over and over. --Marty Goldberg 20:14, 24 February 2007 (UTC)[reply]
I confirm that you misenderstood what I said, in a discussion you deleted. Your clarifications are useless, I know what you want and what you mean and I know what I said... you don't. You are going in circles by yourself.Sarenne 20:36, 24 February 2007 (UTC)[reply]
Sarenne, you can keep telling your self that if it makes you happy. And the discussion was here as well. Furthermore, it takes two to tango, even if one is just repeating the same thing over and over with sarcastic jibes while the other's trying to reason, discuss, and compromise. As I stated in the one on the talk page that I removed, you just can't keep from going on and on about the same thing, ignoring requests to stop, and adding more claims about me. Case proven. If you want to contribute, contribute. If you want to just keep posting sarcastic things to get the last word in, you'll find you're alone in this as I'm more interested in the discussions/debates I was having with the other above. EOD with you on this for me. But please, do another of your responses and prove it further. --Marty Goldberg 20:53, 24 February 2007 (UTC)[reply]
I don't know how you can find a compromise and discuss something if you don't understand what I'm saying. I'm forced to repeat myself because when you paraphrased what I supposedly said, you totaly altered what I had really meant. For example, you said that I revised my position... well I didn't... so you obviously misunderstood what I said. Sarenne 21:12, 24 February 2007 (UTC)[reply]
I agree that quoted texts should not be altered. However, I would not agree to applying this to specifications. That is, if your source says "32KB RAM", a Wikipedia article that mentions this figure should should read "32 KiB RAM". Only blocks of text that are directly quoted passages should be unaltered. -- mattb @ 2007-02-24T20:47Z
Yes, mine was more in to regards that if sources cited, referenced, etc. it should appear once in one of the previously suggested formats. Creating a citation with a link to a source is similar to a quote in functionality. You use quotes when its feasible due to size or overly important in the flow of the page, otherwise you use citations. I'm not suggesting litering the page with sometimes xB and sometimes xM (though that is what happens with the quote rule). Once again, "where it is important to do so" is pretty open ended and open to interpretation unless its further clarified. I believe my position on Hist. Ac. is important for example. --Marty Goldberg 21:01, 24 February 2007 (UTC)[reply]
Trying to get back on track, does anyone else want to propose additional or alternative phrasing to the current MOS? If it's no different from the original text proposed in this section, I'm afraid I still must wholeheartedly object. -- mattb @ 2007-02-24T20:47Z
Actually, I do have an alteration proposal: All instances of IEC units should be linked unless that unit is actually taken from a WP:RS for the article. The precise phrasing I suggest is to change from
However, because they are less familiar, binary unit prefixes such as MiB should be linked at least once per article to avoid confusion. Link as [[Mebibyte|MiB]] to avoid a disambiguation page.

to

However, because they are less familiar, binary unit prefixes such as MiB should be linked at least once per article to avoid confusion. All instances of binary unit prefixes which are translated from incorrect usage of SI prefixes should be linked. Link as [[Mebibyte|MiB]] to avoid a disambiguation page.
Also, although this should not be part of this proposal, but the individual articles should note that Wikipedia may be the most common medium in which these units are used the units are not yet generally used. — Arthur Rubin | (talk) 21:09, 24 February 2007 (UTC)[reply]
Sounds like an interesting alternative as well. So I'm clear, are you saying to change all over to IEC but keep a link to SI or keep SI and like to IEC's with an explination? --Marty Goldberg 21:18, 24 February 2007 (UTC)[reply]
Change (incorrect usages of) SI units outside of quotes to IEC, but link all of them. If Kibibyte, etc., are merged to Binary prefixes, then I think we'd have to leave a soft redirect in place, rather than a hard redirect, or the link would be unnecessarily confusing. (I haven't checked when the merge tag was added, or if those proposals should be still active.) — Arthur Rubin | (talk) 21:34, 24 February 2007 (UTC)[reply]
I really dislike linking all of any term, and I think it goes against the recommendation of some policies. However, it's a reasonable compromise that I'm willing to agree to if you think it will significantly improve things. -- mattb @ 2007-02-24T23:08Z
That just exposes how backwards the use of these terms on Wikipedia is. Wikipedia is not the place to implement standards that are unknown to general readers. If and when this terminology because common use, even in the field, then Wikipedia should use these terms. Plain dictionary words should not be linked in Wikipedia articles, and this style guide should not contradict WP:MOSLINKS and WP:CONTEXT. If the linking is necessary in order for people to understand what is referred to, then these terms should not be used, or they should be used alongside their more common equivalents. —Centrx→talk • 00:00, 25 February 2007 (UTC)[reply]
So do you have another proposal? I think it's obvious that totally revoking the MOS endorsement of the IEC binary prefixes isn't likely to happen and I don't think any amount of dialog will sway anyone involved in this discussion. However, I'd like to come to a somewhat agreeable compromise since this issue keeps coming up. Forgive me if I seem terse at this point, but we're really just rehashing all the issues that have been discussed before and I'd like to see some proposed compromises that we can work on. -- mattb @ 2007-02-25T03:58Z
Coming in here without being involved in all the history of this, I have to say that the comment "I don't think any amount of dialog will sway anyone involved" means we have a real problem here. I think you'll find that there are a lot of editors who would feel that "MiB"/etc are weird, and would disagree with the current MoS on this if asked. I certainly would have if I'd had any idea such a decision was even being contemplated seriously. Note that the people here in the discussion on both sides have come here because they're involved (or were involved in the original decision). Yes, WIkipedia isn't a democracy - but it is based on consensus, and it's also has a higher goal which is to provide a usable encylopedia to the world. The goal of wikipedia is not to enforce or promote a particular standards body and its standards, and in this case, by pushing this standard so hard it is hurting the main goal of Wikipedia - providing an encyclopedia. To exaggerate, it's the equivalent of writing it in Esperanto "because it's a universal standard that everyone should use". (Yes, that used to be an argument for Esperanto.)

I would have no problem if these IEC prefixes were used in Wikipedia once even a significant minority of the computer industry started using them. I took a poll of (non-Wikipedia-editing) coworkers, mostly seasoned engineers, a few new PhD's and Master's. Out of around 20 (other than me), only one had ever even seen KiB/MiB/etc - and that was in an Wikipedia article (and I've only seen it here, too). And they had no idea what it meant when they saw it, and thought it was silly.

Can a group of editors who devoutly believe that everyone should use these new prefixes force the issue, and keep the requirement? Probably - Wikipedia rewards those who are persistent and care about an issue, whether it's a good idea or not, so long as there's a critical mass. But in the end I think this truly hurts Wikipedia. For the readers (remember them? The ones we're building this for?) it's like reading an article on land use where all the distances were in furlongs, and all the areas were in jugerum. — jesup 16:07, 26 February 2007 (UTC)[reply]

You can write in Esperanto, actually, if you'd like. But that's rather a nonissue here, this is the English Wikipedia. It is not the "non-binary-prefix" Wikipedia, so use of binary prefixes doesn't contradict, you know, our very name. The land comparison is also poor. Most people who had a reasonable base of knowledge (especially if they're on the metric system), but no special knowledge about computers, could be asked what a megabyte is. Well, they know what mega means, and they probably have some idea that a "byte" is a unit of something, so they'd say "A million bytes, of course!" If you're asking about their hard drive, they're right. But if you're asking about their RAM card, processor cache, any of that...they're wrong! Good guess, but wrong. For that reader (remember them? The ones we're building this for?), we owe it to them to be accurate and specific. We don't repeat urban legends, for example, just because it might be disconcerting to a reader to find out that some "common knowledge" thing is a total crock. If our verifiable information is that it's a crock, that's what goes in the article. And in this case, the idea that solid-state memory operates in powers-of-ten multiples such as kilo, mega, and giga is a crock. Those prefixes have an ancient, well-known meaning, and 2^10, 2^20, and 2^30 isn't it. So, we provide our readers accurate information. That is exactly why this is advocated. Your friends who are engineers already know that when you refer to a "gigabyte of RAM", you're not really referring to a billion bytes. But most of our readers do not. Using megabyte instead of mebibyte is not like using feet instead of furlongs, but having an accurate value either way. It's like saying "one yard" when the actual distance is really "one meter". It's close, but not quite accurate. Seraphimblade Talk to me Please review me! 16:21, 26 February 2007 (UTC)[reply]
I believe the proposal to link IEC terms has merit, because it attempts to address the central problems, unfamiliarity and ambiguity. Saying that all usages of one particular term should be linked is, of course, excessive. But the use of any term where it must be interpreted should be either disambiguated or the ambiguity referenced.
It seems obvious to me that, unless one wants to preserve ambiguity, ambiguous terms need to be defined by links. If a quote uses MB, even if 'we' know which measurement was intended, 'MB' should be linked to some article that notes that the historical usage of MB included at times a strained extension of 'mega-', and that depending on context (which we can leave up to the reader to discern), 'MB' may mean the SI 1000x1000 or the computerese 1024x1024 (which would be more correctly defined in modern usage as MiB or mebiByte, and which links to those articles as an introduction). (whew) Ambiguity is the enemy here, and in every resource material. At least give the reader evidence that a closer look is necessary. The first use of any of 'MB', 'MiB', 'megabyte', or 'mebiByte' should be linked.
This satisfies the objection that one should not change source material nor quotes. But we can certainly reference that old usages were merely conveniences when differentiating standards didn't exist. It also satisfies the objections to the use of new terms which themselves seem to be strained. Whether 'mebibyte' is pronounceable won't matter as the linked definition will be in text. ;-) But we can't expect the reader to replicate the thought processes of IEC and other standards groups without help.
Does an article already exist that clearly notes the conflicts between the stopgap terms and the intended meanings? Does the article already note the usage contexts (such as cache vs. disk)? Shenme 22:30, 25 February 2007 (UTC)[reply]

I took a poll of (non-Wikipedia-editing) coworkers, mostly seasoned engineers

Did you poll the readers? That's who you claim to care about. Most readers don't know (or care) that kilobyte sometimes means 1024 bytes.

it's like reading an article on land use where all the distances were in furlongs, and all the areas were in jugerum.

Other way around. You're arguing in favor of furlongs while the rest of us are trying to use the metric system.

I believe the proposal to link IEC terms has merit

What proposal? It has always been part of the MoS to link the IEC terms.

Does an article already exist that clearly notes the conflicts between the stopgap terms and the intended meanings?

Binary prefix?

If and when this terminology because common use, even in the field, then Wikipedia should use these terms.

Then what the hell should we use in the meantime? Do you dispute that it's necessary to be accurate when referring to units? If you agree that it's necessary to be accurate, then how do we do it? Do you want to go around changing every instance of "100 MB" into "100 decimal MB"? That would be far more disruptive than just using standardized unambiguous units. So some readers aren't familiar with them. So what? They can read an article about it just as easily as they can read an article about the traditional units. Most readers aren't familiar with the ambiguous definitions of those, either. — Omegatron 16:38, 26 February 2007 (UTC)[reply]
What proposal? It has always been part of the MoS to link the IEC terms. Actually, that's not the case Omegatron. It became a part of the MoS when you put it there on 9 July 2005. And please don't claim what readers can and can't do, you can't speak for them any more than you're claiming we're not. --Marty Goldberg 18:35, 26 February 2007 (UTC)[reply]
I have to say that the comment "I don't think any amount of dialog will sway anyone involved" means we have a real problem here.
Sorry for speaking the truth. I only meant to say that the people who watch this page have seen this issue and all the arguments both ways several times now. Most of us see some validity in each others' points of view, but have our strong opinions regardless. Re-hashing the same arguments again won't change these opinions. That's all I intended to convey. -- mattb @ 2007-02-26T17:14Z
Matt, I understood what you meant as well, though it did come off a bit more authoritative as the other person mentioned. Either way, my intent in all this was and is still not to stop IEC from being used or to completely change the MoS entry (though I do appreciate the clarifications that were added during the couse of this discussion). It is to illustrate that striking IS from an article is not as cut and dry as the suggested MoS binary entry (and the MoS is only a suggestion by defintion) dictates. Just as the MoS states "should be applied with flexibility". Those statements are there to allow for differences of opinions, no matter how strong they are. --Marty Goldberg 18:35, 26 February 2007 (UTC)[reply]

I do not know why this repeated discussion this time turned so aggressive and sometimes outright silly; please calm down everybody! In most cases where it applies this really comes down to adding an i and a link to Binary prefix. This improves accuracy a bit, which is a good thing. Many readers will read over it without noticing it at all, because they are unaware of the issue and do not need to be bothered with it too much. Authors have in general more knowledge about the subject at hand than do readers, so they shall bear the duty to decide whether a source used decimal or binary values. (For an example compare the max. capacities quoted for 5¼" and 3½" diskettes, HDDs, CDs, DVDs and FMCs.) This has nothing to do with altering or augmenting quotes, which are very rare here anyway. In the English Wikipedia in particular we have to disambiguate use of units all the time, e.g. land vs. nautical miles, US vs. Imperial and wet vs. dry capacities, Avoirdupois vs. Troy weights, long vs. short vs. metric tons, pound-force vs. pound-mass, local vs. US dollars and so on; or, on a similar matter, Julian vs. Gregorian dates. Much of this could be overcome if we settled on the metric system and other international standards (like ISO 4217 for currencies), though. It is also questionable whether megabit is any more an English word than mebibit is. (Note the etymology of bit, which is similar to that of the binary prefixes.) Christoph Päper 09:30, 27 February 2007 (UTC)[reply]


Wikipedia is no place for the MiB religion to be practiced

from: http://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard#my_edits_keep_going_away ==== my edits keep going away i have editted two intel articles on "pentium d" and "core 2" user sarenne keeps undoing the edits.

i don't understand what is going on here and need some help. what's the point of Wikipedia if some folks just undo all of the work of other users. I did enter a comment on user's sarenne talk page -- but i doubt it makes a difference.

but from what i read the problem is much bigger than i.

this user is trying to engineer social change far beyond the mear correctness of terminology...which, by the way, i totally disagree with.

so someone needs to explain this binary terminology religious ferver to me and what it has to do with Wikipedia.

Or maybe you won't have to "block" me. I will just go away and use/contribute somewhere else where it is valued.

Thanks.

Rman2000 17:40, 28 February 2007 (UTC)

This is a conflict over the Manual of Style's guidelines for the binary prefixes. Rman2000, under the IP 68.115.91.4, is going against the MoS by using, for example, MB, while other users are using MiB. Veinor (talk to me) 17:44, 28 February 2007 (UTC) It has been explained to this user why his edits have been reverted and he has been directed to the correct page to take up his issue with the current policy. This is a hotly contested policy, but has withstood many challenges thus far. There have been a string of IP users recently who show up solely for the purpose of removing the correct usage of these prefixes and causing a fuss when their changes are reverted. -- mattb @ 2007-02-28T17:51Z It doesn't matter how hotly contested this issue is or what the past has held. In this case these articles are about products designed and built by Intel. The inventor/manufacturer does NOT use this terminology. So I don't think that Wikipedia consensus (and since the entire community didn't vote, the importance of this isn't clear either) is really the guiding factor in these articles. They should be true to the rightful inventor/owner terminology. It is clearly confusing to see one terminology in Wikipedia and a different one from the manufacturer: web pages, documentation, packaging etc.

This isn't just editting of a page here or there but these MiB/KiB folks are out to change the world. They are clearly monitoring Wikipedia for just sunch changes and changing them back...it's like the binary number police at work. When in this case, they are simply wrong on every front. If they want to write original articles and use obscure terminology known only to .00001% of the population, then fine. I appauld them for living in their own private world. But I live in this world and it doesn't use MiB or KiB ... anywhere else.

The forced imposition of standards is a political event and should be handled in a suitable political forum. If they want to "suggest" certain changes to authors...well why not. But they are forcing every page in Wikipedia to bare their particular nomenclature stamp when it is not the desire of the subject community. What is "correct" is not the forced change of every occurance of MB to MiB etc. They must have a BOT that checks all pages in Wikipedia for "violations" of their form of "correctness" given the speed with which my edits were removed. This is really the George Orwell "1984" nightmare incarnate.

And the slight above about IP users is just more snobbery about the topic. I didn't sign on because I didn't even think about it at the time. And I don't think others are trying to hide from the changes. Only from the overwhelming pressure of the binary zealots that are taking over Wikipedia.

Read what they said. The words on vandalism and blocking are threats pure and simple. You don't leave it the way we want it and you will be "eliminated"....almost "resistence is futile" sound about it. I don't think that I and other users respond to threats very well.

Wikipedia's value is deeply rooted in it's openness. This kind of "bully" editing runs clearly against the grain. These folks, whoever they are, don't own every technical page in Wikipedia...at least I don't think that they do (correct me if I am wrong). And I don't think it serves Wikipedia to have "policemen" of any type forcing everyone to walk on the "right" side of the street.

But I am concerned about these pages where the terminology is being corrupted in the name of "standards" and made inconsitent with the common practice of engineers, programmers, users and manufactures as represented in their own writings, web sites and packaging. Rman2000 19:47, 28 February 2007 (UTC)

In this case, the marketing people at the companies you mention are using the wrong prefix because they don't want to confuse the customers. Wikipedia shouldn't adhere to marketing talk, it should keep to standards and in this case MiB is the correct use of prefixes when referring to 1024 bytes. --Strangnet 19:52, 28 February 2007 (UTC) In any event... this is a content dispute, not something requiring admin action.--Isotope23 19:59, 28 February 2007 (UTC) Wonder what admins are for then? I am just a simple user and everytime I make a change the MiB police change it back. I don't have the power or time necessary to keep making the changes over and over again. If the admins are in support of "editting police" then it's a sad day for Wikipedia. If and until the "issue" is settled, I think that they should not be able to "purify" all technical articles to their own beliefs and wishes. This isn't a dialog that can happen on a single article or two. And it doesn't appear to me that they are winning on the merits of their argument either. They are winning by brute force. Multiply this behavior many times and it will be the death of Wikipedia. Sure you want it to start here?Rman2000 20:20, 28 February 2007 (UTC) Admins are janitors here, not police. What I said isn't in any way "support of editing police". The only things an admin can do that any other editor cannot is delete articles and block editors for vandalism. Other than that that, we are all simple editors. Deletion and blocking are not warranted here so there really is nothing that requires an administrator to intervene. There are numerous mechanisms open to you at dispute resolution--Isotope23 20:43, 28 February 2007 (UTC) First of all, it isn't just the "marketing" people using a terminology. The technical programmers and engineers who invent, design, build, test and ship all (almost all) technical products don't use MiB or KiB. The computer technical community has been using MB, KB, for what, sixty years now give or take. And they are all "wrong" and you are the only one who is right? My my, it must be special to know that only you have it right and everyone else has it wrong. But it is also the "confusion" of the "customers" that should concern Wikipedia the most as Wikipedia doesn't just exist to fulfill the whims of a hand full of MiB zealots. Rman2000 20:03, 28 February 2007 (UTC)

For the last time. If you have an issue with this policy, take it up in the appropriate place: Wikipedia talk:Manual of Style (dates and numbers). Neither the administrator notice board nor revert summaries nor user talk pages are correct places to get this policy changed. I suggest you first read up on the five or so previous times this has come up, been discussed thorougly, and still maintained significant consensus to keep. Believe it or not, there are a lot of valid reasons for using IEC prefixes. Irregardless, please do not revert articles to your liking until such a time as the current MOS guideline changes. You can drop the persecution complex. Nobody has bullied you, it's you who is demanding that your opinion is more valid than that of the users who established and have maintained this particular policy. There are other users who disagree with the policy, if you have anything to add to the lengthy discussion, by all means do so in the appropriate place. -- mattb @ 2007-02-28T20:27Z

from: http://en.wikipedia.org/wiki/User_talk:Sarenne#I_am_not_a_vandal ==== I am not a vandal On page: http://en.wikipedia.org/w/index.php?title=User_talk:68.115.91.4&redirect=no you have accused me of being a vandal with a threat of being blocked on Wikipedia. It is you who keep undoing my edits.

Ref: articles on Pentium D and Core 2

MiB etc at NOT used by the manufacturer, Intel, on the pages you keep changing. Readers are going to be confused by the terminology and I don't think that is the intent of the Wikipedia.

Intel, IBM, Microsoft, Oracle, Dell, Gateway, Micron (and all the other memory manufacturers), Sun, etc; NONE of them use this terminology in their product descriptions, web pages or packaging.

I don't know who you are or why this is such a problem for you. But I don't think you own Wikipedia nor Intel. I don't know what right you have to threaten me either.

The COMMON usage is MB not MiB, KB not KiB etc. The COMMON usage.

It appears you are trying to use Wikipedia to engineer social change. Wikipedia is a place to learn about the world as it is; not as you would like it to be. You need a political forum for social change. And that's where you should hold this "dialog" over binary prefixes; NOT in Wikipedia.

Please STOP changing every edit I make; or it will be people like you who ruin Wikipedia for everyone.

68.115.91.4 17:28, 28 February 2007 (UTC)

You are acting against community consensus on the usage of these prefixes and borderline revert warring. That constitutes vandalism if you do not stop. This issue has been hotly debated many times and the endorsement of the IEC prefixes by the style guide on Wikipedia still stands. You should take your issue up there, not on individual pages. -- mattb @ 2007-02-28T17:35Z It is NOT a requirement of the style guide for Wikipedia. Show me where it says that all articles MUST adhere to this RULE. You can't and you know it. You are using threats to get what YOU want and apparently have nothing else to do at that. It is you who should stop messing with others input and stop threatening the general user populace. Rman2000 17:43, 28 February 2007 (UTC)

From WP:MOSNUM#Avoiding confusion: "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." It's pretty cut and dry. If you have an issue with this policy, I encourage you to contribute to the lengthy discussion on the talk page I linked above. If you continue reverting articles against this consensus you may be blocked. This isn't a threat, it's just informing you of consensus and what will happen if you believe you can singlehandedly reject it. -- mattb @ 2007-02-28T17:48Z I just want what is best for the encyclopedia. If you succeed in changing the manual of style (i.e. gathering a new consensus) be sure that I will stop reverting your edits about the prefixes. If you are not a vandal, and I'm sure you are not, just stop reverting against the current consensus and contribute to the discussion before making the changes. Sarenne 20:03, 28 February 2007 (UTC) It is patently clear that this is NOT your goal. Your goal is to force a terminology change down the throats of the Wikipeida community. You change every occurence in the entire set and then hide behind the words in the MOS. If we traced every change of MB<>MiB back to it's origin, I would be clear that you wouldn't see MiB in even .01% of the articles. I don't know, nor do I care, how the MOS got its wording. What I do know is that Wikipedia stands ALONE in a sea of billions of technical articles that use MB, KB etc by trying to use KiB and MiB etc. You aren't interested in the best, you are personally intersted in seeing your terminology religion forced onto an entire community. You have found a platform for your beliefs in the wholesale changing of every MB, KB reference in a community that has no way or will to stop such censorship. If the inventors of Wikipedia let this happen, then it (WP) simply cannot be trusted to represent the "truth". 68.115.91.4 20:42, 28 February 2007 (UTC) There is a difference between "should be" and "must be" and I made the changes in good faith that Wikipedia is an open community and not "owned" by the MiB/KiB police. The references to vandalism and blocking are very much threats--there is no other way to read them. You don't like MB then take it up with the technical community at large...but you have NO right/rule to wholesale change every Wikipedia page to your own personal view of how things should be. Go write your own pages and use whatever obsure references you like. I really don't care. But you don't have a pulpit to look down on the Wikipedia community from and dictate the terminology in every technical article -- at least I don't think you do. Prove me wrong! Rman2000 19:56, 28 February 2007 (UTC)

I'm not going to argue with you here. I have linked you to the proper place to take up this discussion several times, and I will only respond further on the MOSNUM talk page. -- mattb @ 2007-02-28T20:40Z Retrieved from "http://en.wikipedia.org/wiki/User_talk:Sarenne"

So here we are now what? Is this a better forum for the topic? Rman2000 20:59, 28 February 2007 (UTC)[reply]

Well, I'm not sure we need the whole text dump, but yes this is a more appropriate forum. That being said, though, we really have been over all this again and again, and the consensus was to leave the MOS as it was, due to the fact that binary prefixes more accurately reflect the numerical values involved. Seraphimblade Talk to me Please review me! 21:07, 28 February 2007 (UTC)[reply]
Never mind that the terminology is obscure and NOT used by the technical community at large. Never mind that less information and more confusion results in the reader's mind. Never mind that you "enforce" a style that doesn't say must or can't with an iron fist. What you need is a pulpit and a congregation for this cause; it is a misuse of Wikipedia's openness and is nothing so much as censorship. Rman2000 21:27, 28 February 2007 (UTC)[reply]
Well...if you're going to use polemic, I strongly doubt that it will be more effective for change then the previous well-reasoned discussions. The MOS addresses the issue of possible confusion by stating that the first instance of XiB in any article should be linked to Binary prefixes. Most readers unfamiliar with the discrepancy will likely simply read XiB as XB and never notice the difference, for the astute ones that do, they can click the link and find out what's going on! Commonality of use similarly isn't a main consideration, "battery acid" may be a more common term for sulfuric acid, but we still call it sulfuric acid as that is the proper and precise technical term. Seraphimblade Talk to me Please review me! 21:34, 28 February 2007 (UTC)[reply]
Oh, dear. Promoting the standardized use of binary prefixes instead of the older and more wide-spread (albeit erroneous) use of regular prefixes is equal to censorship? Sounds a bit harsh. When will the correct use ever propagate out to "the masses" if not even encyclopedias and references in general can use it? --Strangnet 21:42, 28 February 2007 (UTC)[reply]
First, thank you for taking this discussion to the appropriate place. That being said, your concerns have been brought up many times before and don't change anything in my mind. If you want to read detailed responses to your reasoning, I encourage you to read the above discussion and the handful of previous discussions linked therein. Myself and others have provided our point of view on this many times, so I'm not going to simply copy/paste my responses here. Edit: Here are a couple of the previous discussions for your consideration: [12] [13] [14] [15] Please don't mistake my brevity as ignoring you, it's just that we've been over your exact arguments so many times that I'd rather let the archives speak for me. -- mattb @ 2007-02-28T23:40Z

Proposed

When the biographical subject went missing and a year of death is not established in the historical record:

Amelia Earhart
(24 July 1897 – missing 2 July 1937, declared dead January 5 1939)

Gwen Gale 02:54, 25 February 2007 (UTC)[reply]

I already replied to this above, saying:
My view is that this is sufficiently uncommon that we don't need guidance about it in the Manual of Style; a solution appropriate to each individual article can be decided on a case-by-case basis on that article's talk page.
I've reverted the change you made on the main page. I apologise for saying in my comment that you'd raised this issue before and ignored the answer, because I now realise that it was someone else. Nevertheless, you should get a consensus on the talk page before changing the Manual of Style. Stephen Turner (Talk) 10:04, 26 February 2007 (UTC)[reply]
I hadn't received any comments at all. Do you have some sort of special authority on this page? Please clarify, thanks. By the way, uncommon or not, the lack of policy on this has caused wasted time and gnashing of teeth. A policy is needed (there are a few ways of handling this that would be ok with me, but a policy is needed). Gwen Gale 10:16, 26 February 2007 (UTC)[reply]
No, I don't have any special authority on this page. However, this exact question was raised by User:Ronnotel just a few days ago, and the only person who replied (me) said it wasn't necessary. So there certainly isn't a consensus for the change at the moment.
Personally, I realise that a group of editors has been struggling with this issue, but I still think that the Manual of Style is not the place to resolve issues like this. It should only provide guidance for situations which come up in many articles. It can't hope to document every variant which could come up in rare situations.
Maybe some more people would like to comment?
Stephen Turner (Talk) 10:32, 26 February 2007 (UTC)[reply]
I think your reasoning may be arbitrary. What quantitative threshold are you referring to? Please provide verifiable numbers if possible. Also, a reference to written WP policy supporting your statement as to this kind of threshold and its relevance to this discussion would be helpful. Thanks. Gwen Gale 10:41, 26 February 2007 (UTC)[reply]

Would anyone else like to comment on this? Or are you all too busy arguing about binary prefixes? :-) Stephen Turner (Talk) 10:25, 27 February 2007 (UTC)[reply]

Sounds like instruction creep to me. The case is rare enough that its specification would just clutter this MoS page, and should be decided on case-by-case basis. Either form is OK, and it's really not something worth arguing. Duja► 10:41, 27 February 2007 (UTC)[reply]
Given I'm ok with a consensus I don't agree with, let's flip it: Is it fair to say that this project page provides no guidance on missing-and-maybe-later-declared-dead bios? If it does provide guidance, what is it? For example, can clarity be considered the goal, guidelined or not? Gwen Gale 10:53, 27 February 2007 (UTC)[reply]

Numerals vs. numbers as words

Isn't there research showing that even numbers as low as 2 read faster as numerals than as words? 216.179.3.122 17:11, 25 February 2007 (UTC)robgood[reply]

Possibly so, but it's nearly universally considered bad English style, and can also encourage unnatural sentence constructions since sentences shouldn't start with numerals. Since the style guide is mostly to standardize on something vaguely close to existing practice, I don't think we should go out on a limb and come up with our own "scientific style guide" based on cognitive science research, at least not in cases where predominant English usage is clear. --Delirium 03:17, 26 February 2007 (UTC)[reply]
And the question remains, is there even such research at all? Even if there were, it is doubtful it was even conducted usefully. For example, "read faster" does not even equate to "understand better"; "freshman university students" that constitute many psychology studies does not equate to "Wikipedia readers". —Centrx→talk • 05:56, 26 February 2007 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Dates_and_numbers&oldid=111699910"