Misplaced Pages

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

Article snapshot taken from[REDACTED] with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
< Misplaced Pages talk:Manual of Style Browse history interactively← Previous editNext edit →Content deleted Content addedVisualWikitext
Revision as of 03:30, 6 July 2008 editTony1 (talk | contribs)Autopatrolled, Extended confirmed users, Pending changes reviewers, Template editors276,760 edits Date links are required to populate 'What links here' for year pages← Previous edit Revision as of 04:22, 6 July 2008 edit undoGreg L (talk | contribs)Extended confirmed users, Pending changes reviewers31,897 edits discussion: What a loadNext edit →
Line 755: Line 755:
:* User preference settings for a which-view template wouldn’t be good because it would only work for registered editors. The vast majority of readers (non-registered I.P. users) would just see GB. So why bother? To me, this is military-grade sillyness. You don’t see computer magazines bothering to explain what “2&nbsp;GB of RAM” means, nor does ''Encyclopedia Britannica'' bother; it’s clear enough. The whole push to “disambiguate” these common expressions is just residue left over from arguments advanced by the pro-IEC prefix crowd trying to make their point about the “ambiguity” of the SI prefixes. We’re trying to fix a “problem” that exists only in our minds. A simple, one-time-only link to ] is sufficient. And I agree with you: it’s time to move on to other things. The only way I know of to enforce that is to ''ignore'' the pro-IEC prefix crowd next time they come here to complain about the last consensus vote. <span style="white-space:nowrap;">''']''' (])</span> 02:47, 6 July 2008 (UTC) :* User preference settings for a which-view template wouldn’t be good because it would only work for registered editors. The vast majority of readers (non-registered I.P. users) would just see GB. So why bother? To me, this is military-grade sillyness. You don’t see computer magazines bothering to explain what “2&nbsp;GB of RAM” means, nor does ''Encyclopedia Britannica'' bother; it’s clear enough. The whole push to “disambiguate” these common expressions is just residue left over from arguments advanced by the pro-IEC prefix crowd trying to make their point about the “ambiguity” of the SI prefixes. We’re trying to fix a “problem” that exists only in our minds. A simple, one-time-only link to ] is sufficient. And I agree with you: it’s time to move on to other things. The only way I know of to enforce that is to ''ignore'' the pro-IEC prefix crowd next time they come here to complain about the last consensus vote. <span style="white-space:nowrap;">''']''' (])</span> 02:47, 6 July 2008 (UTC)
::*GregL, it is not permissible to "ignore" anyone, and your suggestion to do so is not ]. MOS is pretty clear that disambiguation is required. I would also disagree that MB is "clear enough", as if you asked the average reader of such an article how much memory is in a "megabyte", they would interpret "mega" according to its standard meaning of one million. Given that computer measurements vary from this centuries-old standard, I think ''some'' form of disambiguation is demanded. How it is done is not all that important to me (I would personally prefer IEC prefixes and did not support their deprecation), but so long as we disambiguate it in some way or another, I'm alright with it. However, ''failing'' to disambiguate is a wholly unacceptable option. I think it also telling that the implementation of this decision is bringing others along who also disagree with it, this should be a clear warning sign that perhaps it does not have a community-wide consensus after all. The solution to that is not to ignore, it is to ''discuss further''. ] <small><sup>]</sup></small> 03:04, 6 July 2008 (UTC) ::*GregL, it is not permissible to "ignore" anyone, and your suggestion to do so is not ]. MOS is pretty clear that disambiguation is required. I would also disagree that MB is "clear enough", as if you asked the average reader of such an article how much memory is in a "megabyte", they would interpret "mega" according to its standard meaning of one million. Given that computer measurements vary from this centuries-old standard, I think ''some'' form of disambiguation is demanded. How it is done is not all that important to me (I would personally prefer IEC prefixes and did not support their deprecation), but so long as we disambiguate it in some way or another, I'm alright with it. However, ''failing'' to disambiguate is a wholly unacceptable option. I think it also telling that the implementation of this decision is bringing others along who also disagree with it, this should be a clear warning sign that perhaps it does not have a community-wide consensus after all. The solution to that is not to ignore, it is to ''discuss further''. ] <small><sup>]</sup></small> 03:04, 6 July 2008 (UTC)

:::* What the blue blazes are you talking about? Who do you think you are, the thought police? Anyone can ignore anyone they want—anytime; get that much straight in your head. You are '''''totally''''' wasting your time if you presume to tell me that I—or anyone else—''have'' to respond to someone here. “Ignoring someone isn’t civil”: what load of half-cooked tripe. As for the rest of your arguments that Misplaced Pages needs to disambiguate “2 megabytes of RAM” when no one else on this damned planet bothers to, well… I’m ignoring you. Watch:<p><small>''(*sound of crickets chirping*)''</small><p><span style="white-space:nowrap;">''']''' (])</span> 04:22, 6 July 2008 (UTC)


== Date links are required to populate 'What links here' for year pages == == Date links are required to populate 'What links here' for year pages ==

Revision as of 04:22, 6 July 2008

Template:LOCErequest

Archiving icon
Archives
General Binary prefixes Years and dates See also


This page has archives. Sections older than 10 days may be automatically archived by Lowercase sigmabot III.
editArchive
Years and dates archives

Lightbot and Lightmouse - issue with years

It would appear that there needs to be an alteration to the MOS here. Lightmouse's bot has been dewikifying years per this MOS, and I disagree that this should be happening. It is something of a contradiction that complete dates can be wikilinked as two seperate links (date and year), but on it's own the year shouldn't be wikilinked? That reads inconsistent to me. Moreover, the importance of the year articles on WP shouldn't be understated like this. I find the years very useful and I'm sure other users do as well. I suggest that the years be allowed to be wikilinked seperately, and this aspect of the MOS be changed to reflect it. !! Justa Punk !! 12:00, 17 June 2008 (UTC)

Oh dear. This debate is old news; it was fought and resolved mostly in 2005 and 2006. Year-only links are generally deprecated as nuisance links, and I don't want to go through all of the reasons here. They're in archives. Please see the statement in MOS main page on overlinking. Now, you may like to browse year article (although last time I looked, most were pitifully inadequate); but generally we don't want to dilute valuable links and degrade the readability of the text with blue-splash everywhere. Nothing, repeat nothing, is stopping any reader from tapping four keys into the search box to investigate a year article ... fine, but not linked, please. TONY (talk) 13:34, 17 June 2008 (UTC)

Agreed. Just my opinion; but I remember the first time I saw a linked year on Misplaced Pages (I had very little experience as a reader at that time). It was in an article on something or other and said “…in 1983, the researchers discovered…”. I thought, “oh, great! I can click on the link and read a blow-by-blow of what the researchers accomplished back then.” Obviously, that’s not what the links do. Instead you get random stuff like “the director of the Griffith Observatory wore a brown suit and mutton chop sideburns in 1983 and now we’ll see that on the cable educational channel forever.” (OK, I’m exaggerating). The wikilinks for years and dates are overrated and, in my opinion, you end up with over-linked articles. I never click on them. If a reader really wants an arbitrarily chosen chronology of notable events that occurred in a particular year, they can always type it into the search field. That’s my 2¢ on the matter; I am quite curious how others feel about this issue but am pleased to see Tony and I seem to be 100% aligned on this one. Greg L (talk)

Greg, perhaps you'll be pleased even further to hear that I'm with you too. Lone years should only be linked if they have particular relevance to the topic in question—which accounts of a very very low percentage of those lone years that one will find linked on this encyclopædia. That this guideline recommends the linking of dates (i.e. day, month and optionally year) inspite of relevance to the topic at hand is due to a flaw with Wikimedia. The flaw being that linking is required for the autoformatting function to work. This problem, inspite of the repeated calls of dozens of users, does not seem likely to ever be fixed. JIMp talk·cont 23:45, 17 June 2008 (UTC)

That is good news Jimp. Indeed, that first instance of a linked date that I clicked on as a newbie may well have been a specific date. Whether it was a link to a whole year or a particular date, it accomplished the same thing: nothing other than to over-link the page. Cheers. ;-) Greg L (talk) 02:28, 18 June 2008 (UTC)

It's time the autoformatting be fixed ... no, it's well overdue. Indeed the presence of date links for the purpose of autoformatting may be much of the cause of this notion that lone years (months, days of the week, ...) should be linked also (regardless of relevance to the article). I have some sympathy for Tony's position that it's better to leave dates unlinked and thus unautoformatted. Is it time to initiate another plea to the developers ... just to remind them that the problem is still here and causing a whole lot of strife? JIMp talk·cont 04:11, 18 June 2008 (UTC)

I share the views of Tony, Greg, and Jimp on this. We can plead for the developers to change the mechanism. We can update the guidance. These two activities can occur in parallel. Lightmouse (talk) 19:54, 18 June 2008 (UTC)

I see little point in going back to Brion Vibber at Bugzilla—he's not on-side with this one, even when faced with an 85-strong petition of WPians. No doubt we could get many hundreds on a petition now, but I wonder whether this shouldn't go to a different body first, so that they might make the representation. Is ArbCom an appropriate body to which to make a representation? Or Jimbo? I have no idea. But beyond that, frankly, I have no problem at all in accepting both major date formats without this failed mechanism, as long as they're consistent within each article. TONY (talk) 14:10, 19 June 2008 (UTC)

Just focussing on the issue of guidance... There are various elements of guidance but one is:

  • Links to date elements that do not contain both a day number and a month are not required

The neutral phrase not required could be changed to the more active should not generally be linked (to match a style used on wp:context). Would that be nearer to what people think? Lightmouse (talk) 17:02, 20 June 2008 (UTC)

  • Yes, “should not generally be linked.” Unless the date being linked has a special relevancy to the topic, such as Sept 11 within a topic on Terrorism, I don’t think dates should be linked. Linking dates to a random list of historical events is over-linking and discourages readers from exploration. If I really want to know on what date Charlie Sheen was born, I’ll type his name into the search field. Articles are optimally linked when they best anticipate what a the median reader being introduced to the subject would be interested in further exploring. Greg L (talk) 18:45, 20 June 2008 (UTC)
Seems to me some of these positions are getting rather pointy. Breaking the semantic web in order to motivate the developers for a bugfix is certainly not justified, no matter how annoyed we are with the bug. LeadSongDog (talk) 19:34, 20 June 2008 (UTC)
  • I’m not taking a position on bug fixes or templates or any of that because I don’t understand the issue nor do I use date templates just to format a date. (Should I?) When I write a date in an article, I write something like

The all-platinum kilogram prototype was presented to the Archives of the Republic in June and on 10 December 1799, the prototype was formally ratified…

…the Euro-style of date formating. My position is that I don’t advocate the linking of dates like this:

The all-platinum kilogram prototype to the Archives of the Republic in June and on 10 December 1799, the prototype was formally ratified…

…because on first sight, many novice readers would assume that by clicking on the link, they can get additional details of that particular historical event. All it takes is a couple of “gotchas” like that for most readers to learn never to click on these date links. I certainly don’t click on these links and it sounds like a lot of other editors here don’t either. It’s not a matter of “right or wrong”. This is my 2¢ on a grey area that pertains to how one could make Misplaced Pages better. It’s a judgement call.
It sounds like not linking dates creates problems of another sort. I think it’s too bad if that’s the case. Perhaps someone would take the time to explain why simply writing out a date in Euro-style like I did—and not linking it—is inadequate or creates problems in some way. Are there tools available for date formating that further improves the readers experience? Greg L (talk) 20:08, 20 June 2008 (UTC)
  • P.S. Here is a MacDailyNews article I just happened upon that spoke to this issue of linking dates. This is how a passage reads within that article:

MacDailyNews Take: Back on January 10, 2005, we took a bit of flack from some readers for our Take, in which we have always believed and therefore reprint here:

This is how I think readers believe linked dates will function on Misplaced Pages. But not here. Just a link to a list of minutia (and some trivialities), IMO. Greg L (talk) 20:29, 20 June 2008 (UTC)
I couldn't agree more with Greg L. TONY (talk) 13:25, 21 June 2008 (UTC)

Other relevant pages are wp:moslink and wp:overlink. Lightmouse (talk) 14:10, 21 June 2008 (UTC)

WP:CONTEXT ( a style guideline linked from WP:MOSNUM) says

Stand alone years do not need to be linked but some users prefer it,

I am a user that prefers it in some places, (like year of birth and year of foundation.) They are a good jumping off point for a reader to put a biography in a wider historical context. It is not the wiki way for a bot to delete these links at three a minute: I don't have a long watchlist but Lightbot is showing up frequently on it, often does excellent work on units, but it doesn't say in its edit summary whether or not it interfered with dates.

I would have to presume that the editors who maintain the year and date articles also like to have some relevant backlinks!

--Hroðulf (or Hrothulf) (Talk) 20:23, 21 June 2008 (UTC)

  • You raised a good point Hroðulf. It seems like limited year linking as you like to occasionally do (for particularly notable events like year of birth and year of foundation for historical context) could be worthwhile and informative. I can pretty much guarantee you that novice readers of Misplaced Pages at first anticipate date links to be ones that take the user to additional details of that particular event, as demonstrated in this example:

Tthe United States of America had been pulling away from England for many years and, on July 4, 1776, finally declared its independence.

My point is, if one is going to link dates (I tend to think there are better ways), they should function, IMO, as I showed above because this is how such links are most often done on the Web. Basically, I see linked dates like this…

…For instance, the United States of America declared its independence from England on July 4, 1776

…as a violation of WP: Principle of least astonishment. I don’t think I can come up with any suitable alternatives that fix this problem. For instance, this solution seems cumbersome:

For instance, the United States of America declared its independence from England on July 4, 1776 (click here for other notable events on July 4, 1776).

My hunch is that other editors will find that alternative as cumbersome too. But maybe not. The above technique clearly addresses the issue of least astonishment; the reader knows exactly what they will be taken to when the click. But I prefer this way:

For instance, the United States of America declared its independence from England on July 4, 1776.

In my mind, this best adheres to the principle of least astonishment and avoids over-linking and an intrusive invitation to click on a random list of events that happened during a particular date and year. Note too that linking a year (1776) might make sense “sometimes.” But the concept of linking the date (July 4) seems utterly meaningless to me. There clearly is no historical context of what happened last year on July 4th v.s. what happened on that date over 200 years ago. Arguing that linking a date provides historical context (not something Hroðulf is proposing) seems a non sequitur to me. It really amounts to nothing more than trivia. Ergo: over-linking.
The benefit of adhering to the principle of least astonishment and of anticipating what the median reader who is researching that subject will be interested in further exploring, is that we encourage exploration and learning. We do so by not teaching readers that they will often waste their time if they click on a link. Nor do we bombard them and numb them with too many blue text links. People who surf the net develop excellent “brain filters.” Someone who is researching Thermodynamic temperature doesn’t need to be bombarded with links that are as common as “the air that I breath.”
The excessive linking of dates we’ve seen over the previous year is not good, IMO. I’ve had I.P. editors come in and link every damned date and year in articles I’ve been working on. The underlying motivation for doing so seemed to be nothing more than “the tool exists, ergo I link.” Given the collaborative writing environment of Misplaced Pages, the tendency will always be for other editors to go ape-shit with date linking.
Perhaps I’m wrong though. Maybe a MOSNUM policy can be written that spells that what Hroðulf does—limited context linking for particularly notable events (like year of birth and year of foundation)—is OK. I certainly wouldn’t link the date (that would be pure trivia); only the year. I personally don’t see the advantages of this limited use as being worth the fuss that will no doubt arise from abuse of the tool. Greg L (talk) 22:06, 21 June 2008 (UTC)

Featured articles do not generally have links to date fragments. I am not sure what conclusion we can draw from that, but I think it is interesting. Please take a look. Lightmouse (talk) 11:55, 22 June 2008 (UTC)

As is often the case the discussion here seems largely to consist of a few people congratulating each other on how much they agree with each other about how right their opinion is.
Personally, I don't have a strong opinion one way or the other about dates. I do find the obsessive linking of all dates a little odd, but I also find the idea of rooting out all occurrences of linked dates in some sort of Stalinist purge equally strange.
On the whole I don't find that anything is deeply harmed (or 'diluted' or 'degraded') by these links. If fact I find them easy to ignore. I also don't find anything astonishing about a link taking you to a page about the linked text. Isn't that what every other link does?
What I actually object to strongly though, is Lightbot removing all links even though the policy says they are allowed if appropriate in context. How on earth is a bot to judge context?
Moilleadóir 14:09, 22 June 2008 (UTC)
I don't know how the bot works, but I wouldn't mind much if the bot only looks for articles with a large number of lone years, a majority of which are wikilinked. I'm pretty sure we can say that such an article is overlinked, and if an editor has to manually reinstate the contextual occurences (knowing that the bot will thenceforth leave the article alone), that's a small price to pay, as it would be much less work than manually delinking all the years. Needless to say, the best solution to date overlinking would also include changing autoformatting so as to not depend on wikilinking. -- Jao (talk) 05:33, 23 June 2008 (UTC)

I have to say that I strongly disagree with what Lightbot is doing. If, say, the article says a writer moved to a new city-state in 1473, then I do want to be able to see (if I choose to) what was the situation of the world in 1473. Who ruled where? What wars were ongoing? What was happening in the 1470s generally, and what did the map of Europe look like? This is the kind of material I can find on the 1473 page, or one link away.

Certainly, an article shouldn't be overlinked. But this is a matter for editorial discretion on an article-by-article basis.

It is manifestly not appropriate for an automated 'bot to simply bulldoze all year links regardless.

My view is that WP's year pages are useful; and therefore they can be useful to link to. If somebody put the whole lot up for AfD, that proposal would be shot down in flames. So we shouldn't be removing the links to them wholesale either. Jheald (talk) 10:14, 23 June 2008 (UTC)

  1. Could Lighbot please stop blindly unlinking years and dates until this debate is resolved and a new consensus is implemented in WP:MOSNUM?
  2. I don't think editors of the Main Page Selected anniversaries series will be pleased to hear that 'in this year' and 'on this day in history' are trivia inappropriate for an encyclopedia

--Hroðulf (or Hrothulf) (Talk) 10:40, 23 June 2008 (UTC)

  • Hrothulf: You still aren’t “getting” the point, or you are mischaracterizing our position. When you state “2. I don't think editors of the Main Page Selected anniversaries series will be pleased to hear that 'in this year' and 'on this day in history' are trivia inappropriate for an encyclopedia”, no one here takes such a position. Making the information available on Misplaced Pages is fine. Our position, as clearly stated above, is that our problem is the way the info is linked-to within articles is link behavior that is contrary to the way visitors to Misplaced Pages expect such links to behave. If you still don’t understand what we’re talking about, please take the time to read my 22:06, 21 June 2008 post, above. The sooner you address the real point of what we have a problem with, the sooner we can make progress here towards a consensus. Greg L (talk) 19:54, 23 June 2008 (UTC)
  • I think I don’t disagree with limited years being allowed. A bot with Terminator-like determination and lack of selectivity may indeed be unwarranted. I certainly think the issue of how to handle years should be further discussed before a bot is let loose on them. Personally, I think the principle of least astonishment would have year links be done per my third example box in the green section, above.

    I would suggest however, that the bot be turbocharged to hunt down dates. Here, at this example of an episode of Family Guy, is a perfect example of what should be deprecated, IMO, from Misplaced Pages. Note the very last seven characters of the Notes section. If you click on it, you don’t go to an account of Tim Russert’s passing; you are taken to a list showing, among other things, that “ 1525 - Martin Luther marries Katharina von Bora, against the celibacy rule decreed by the Roman Catholic Church for priests and nuns.” (*gag*) By the way, I already fixed this entry. Greg L (talk) 19:40, 23 June 2008 (UTC)

The most important thing if we're not to confuse newbies is consistency. So across Misplaced Pages a link that reads June 13 should consistently go to June 13. That's the way you minimise astonishment, across all the clicks on all the articles on the site as a whole. If we are going to link to an event, we should choose link text that identifies that event, eg "Tim Russert, who had passed away on June 13", and absolutely not "Tim Russert, who had passed away on June 13".
I am deeply dubious of your assertion that a newbie would expect the latter to link to Tim Russert#Death. But even if they did, overall, confusion is minimised if such links never link to articles like Tim Russert#Death. Then, at worst, a newbie might make such a mistake once, or twice. But after that, if we are consistent, he/she will realise, and then will never be confused again. Jheald (talk) 20:35, 23 June 2008 (UTC)

There is one way of measuring the acceptable rate of linking of date fragments. Just look at the rate in Featured Articles or Good Articles. It is very low. The overall quality of Misplaced Pages articles would rise (almost by definition) if non-GA/FA status articles had a similar low rate. Lightmouse (talk) 22:29, 23 June 2008 (UTC)

  • Jheald, (I fully agree with Lightmouse, by the way): That you’re dubious about the way date links on the Web are done doesn’t surprise me. Many Misplaced Pages editors get really used to the Misplaced Pages-Way™ of doing things and forget how the rest of the Web works. Here is a common way dates are linked:

MacDailyNews Take: Back on January 10, 2005, we took a bit of flack from some readers for our Take, in which we have always believed and therefore reprint here:

Where else but on Misplaced Pages does a linked date ever take a reader to a list of trivia? Yes, I agree with you that if Misplaced Pages were consistent, then that would fix some of this confusion. But initial confusion isn’t the entire issue. I agree with many of the others here: If a reader wants to find out what happened on a specific date, like June 13th (a date which includes such interesting tidbits like how some priest married a nun back in the 1500s), they can type it into the search field. The same goes for links for entire years. If a reader really is interested in what might have occurred on 1799 when they are reading about how a kilogram prototype was promoted to “kilogramhood”, they can enter “1799” into the search field. This isn’t about whether maintaining lists of trivia that occurred in various years or on various dates is a good idea for Misplaced Pages, it’s whether the typical reader is interested in clicking on them often enough to make it worthwhile adding yet another link to the link clutter. It comes as no surprise to anyone else here that there are editors who help edit and maintain this historical trivia data (thank you by the way) and you like to see links to it used in articles. I never, ever click on these links and many of the other editors weighing in here feel the exact same way. I’m done arguing over yet another issue for which there is no clear right or wrong—just shades of gray and judgement calls regarding what makes for the best user experience. Goodbye. Greg L (talk) 22:55, 23 June 2008 (UTC)
Actually, as context I think it is quite useful to know that 1799 was at the height of the Napoleonic wars, ten years into the French revolution, the year Napoleon made himself sole ruler, and also the year George Washington died.
For what it's worth, I'm not an editor of the "year" pages. But I very much appreciate that they are there, and the pages that they are gateways to. *You* may not click on such links, but there are others who do. Oh, and I do hope you are being intentionally ironic, dismissing Luther as just "some priest". Getting married may not be the absolutely most important theological schism between him and Rome; but it's a fairly sharp example of his rejection of Rome and all its traditions and authority just the same -- with reverberations that still ring down to the present day. Jheald (talk) 23:53, 23 June 2008 (UTC)
The removal of links to years (1989, 2004, etc.), centuries (15th century, 16th century, etc.), and "s" years (1800s, 1980s, etc.) that Lightbot is currently undertaking should be discouraged, in my opinion. 1) There are way more pressing needs for bots than this removal of content on wikipedia, 2) the links to dates provide a valuable function to those viewing the articles, and 3) the method that has been undertaken for this measure seems highly suspect. The actions of this bot are a net negative for wikipedia. Cardsplayer4life (talk) 22:56, 23 June 2008 (UTC)

Greg L, that you persist in your idiosyncratic interpretation of the principle of least astonishment somehow doesn't surprise me. Please at least acknowledge that a counter-argument exists, i.e. that a link taking a user to a page about the link text is both logical and unastonishing. This is how most links here work. In fact, links on the web work in a variety of interesting and wacky ways and following web practice could very well violate the principle.

Several people have taken the trouble to visit this page and say that they don't think that the current actions of Lightbot are appropriate. So far, it doesn't seem like anyone is listening. To continue overapplying an extreme interpretation of the policy in this situation shows at the very least a disinterest in working collaboratively, which is neither appealing nor encouraging.

Moilleadóir 07:17, 24 June 2008 (UTC)

What is the purpose of articles like 'Audi' having a link to 21st century? Lightmouse (talk) 00:16, 28 June 2008 (UTC)
Beats me. Your point? ☸ Moilleadóir 03:38, 28 June 2008 (UTC)
His point is that such utterly gratuitous and irritating bright-blue splashes should be delinked; please do, Lightmouse. TONY (talk) 04:13, 28 June 2008 (UTC)
Careful, some ungenerous soul might detect a hint of personal preference in that statement!
Seriously, my original point was about a bot's inability to judge context, not about the validity of every possible permutation of date-linking.
Just because I think Greg's argument about the 'astonishing' nature of date links is feeble, doesn't mean I'm a rabid date-linker. I just don't think it's such a huge threat to WP that it's worth a small number of users here upsetting a potentially large number of users 'out there'. And certainly not if the motivation is a personal aversion to the colour blue. :)     ☸ Moilleadóir 09:09, 28 June 2008 (UTC)

AFAIK there never was a broad consensus that delinking of solitary years could be performed by a bot (not even by semi-bot or script-assisted editing), irrespective of whether the application was fully automated or manually controlled. I took part in the 2006 discussions on this topic: back in those days one was left the choice: stop that kind of editing, or leave. Some left (e.g. Special:Contributions/Bobblewik).

Well, I thought maybe times have changed and consensus swept in support of such delinking activities. Apparently not, seeing the reactions to Lightbot's edits.

Re. Greg L's argument: disagree, several websites, specifically general data repositories like Misplaced Pages (e.g. IMDb) use date links linking to general data about what happened on the date, not the MacDailyNews way (which would be a "surprise link" in Misplaced Pages context). Principle of least surprise all depends on where you're coming from in this case, so I don't see how this would play any role in the discussion we're having here.

I agree with Moilleadóir above. Probably MOSNUM should make clear again (as it used to at the end of the 2006 debates) that the Misplaced Pages community is not receptive to these kind of automated delinking actions: this would avoid frustration for those engaging in this type of delinking on bot scale, only to run against community frustration shortly thereafter. Lightbot's task description (currently Misplaced Pages:Bots/Requests for approval/Lightbot) should reflect this.

Anyway, it could be argued that Lightmouse has his bot perform task not covered by the current approval (Misplaced Pages:Bots/Requests for approval/Lightbot), e.g. for these kind of edits Lightmouse writes on the approval page "... I have done thousands of these and I know what to check for." - well apparently not, seen the expressed disagreements. So, disengage from this part of the tasks or stop the bot.

Further, I checked Lightbot's testrun of 100 edits. I couldn't find a single solitary year delinked by the bot during its testrun. That may be accidental, I only want to say: that part of the tasks was never part of the approval process. So I'd recommend Lightmouse to submit an "additional task" request for approval specifically for the delinking of solitary years.

Also, centuries (15th century, 16th century, etc.), and "s" years (1800s, 1980s, etc.) are not "date fragments" by any conventional use of the English language, so the delinking of them is currently not covered by the 4th (nor by any other) task of Lightbot's approval. --Francis Schonken (talk) 11:33, 28 June 2008 (UTC)

I find it difficult to address a potential user complaint. It is easier to deal with real complaints and a real articles. Complaints about real articles do exist but we have not had a large proportion. Featured Article status is the best that Misplaced Pages can offer. It should be the measure by which all articles should be judged. So the judgment of people here can be bypassed if anyone wants. Simply put the affected article forward for Featured Article status and see if the FA reviewers say it needs links to date fragments. Lightmouse (talk) 11:57, 28 June 2008 (UTC)

Re. "I find it difficult to address a potential user complaint" – I kind of sensed that, but that is a capacity vital in someone setting up a bot. In other words, "... I know what to check for" was just bluffing. I insist that the approval of Lightbot be withdrawn until these issues are agreed upon. As for the BAG, I'd advise them not to grant approval to bots runned by those finding it difficult to address potential user complaints. --Francis Schonken (talk) 12:30, 28 June 2008 (UTC)

Francis Schonken, just let me into the secret of why you feel, on some deep emotional level, attached to year, decade and century links. I suspect that you are a very conservative person who is loath to accept any major change on this fluid fast-adapting, wonderful online product. I haven't yet heard that cogent argument from either you or Rebecca, who appears to have a dog-at-a-bone attitude to this issue yet more trenchant than your own. Now, I hope you don't take this as a personal attack, because it's not meant in that spirit: I am genuinely trying to understand what appears to be hardline inflexibility, and your postings thus far don't explain this to me, or, I suspect, others here.
I first came up against this phenomenon when you refused to allow what I saw as copy-editing improvements at ... where was it ... naming conventions (unsure now), where you may have had ownership issues. You were certainly not cooperative in discussion, I felt. But again, my purpose is not to attack, but to prompt a higher level of debate here, and to gain insights into each others' quite contrary stances.
You know where I'm coming from, I think. As a reading psychologist (that was my dissertation topic), I see bright-blue splashes all over the place, which (1) makes WP's pages slightly harder to read, (2) makes the pages messy in appearance, beyond a certain point, and (3) dilutes the high-value links, making it less likely that readers will follow them.
The situation would be a whole lot better if the default colour for links was much less obstructive—a pastel blue rather than bright blue, without underlining—with the option to change this in user preferences. But because WikiMedia itself is a conservative organisation, of not sufficiently dynamic or well-funded, technical issues seem not to be dealt with. Someone needs to donate $200K to them to upgrade their programming, frankly. So for the time being—possibly in the long term—we're stuck with an inflexible linking (and autoformatting) system, and this is why I strongly support a move away from what I see as trivial linking:
  • years, decades, centuries that very rarely lead anywhere but to a nuisance page, with the possible exception of historically early chronological items, provided the destination page is in a reasonable shape (often not), and some piped links (although there lies a problem in itself);
  • the names of anglophone countries such as the US, the UK, Australia and NZ, and of other countries that are likely to be very well known to almost all readers, such as France, India, China, and Germany (again, with obvious exceptions, such as in the article "Economy of Germany");
  • dictionary-type words.
There are compelling reasons to take a much more disciplined and considered approach to linking; to resist the temptation to link because you can (which I've fallen prey to in starting up articles, I admit). I'm referring to both the changing of our current habits and to retrospective changes. So Lightmouse should be applauded for his active, dynamic approach to lessening the problem and making WP a better place. I presume that he checks over the results carefully. TONY (talk) 12:57, 28 June 2008 (UTC)
Do we need links telling us when some random actress or actor was born?
  • Ditto everything Tony said. I would only add that if the article is on a historical subject (Napoleonic weaponry and warfare for instance), then links to years, decades, and ranges of years make sense and can certainly be left alone if they are linked judiciously. I don’t know what Lightmouse’s bot does with links like these. I couldn’t be more pleased with what his bot is doing to years (and especially dates) in regular articles on current topics. If I want to go to October 16 to discover fascinating trivia, like how Angela Lansbury “was born on this date in 1925”, I’ll type “October 16” into the search field (which I’ll never do). Greg L (talk) 23:31, 28 June 2008 (UTC)

Nah, can't speak for Rebecca (and have no hunch of her psychology), but the psychological analysis presented above misses the mark on every imaginable level. Sorry, couldn't say whether its obvious inadequacies are anywhere linked to career crash frustrations. Nor do I see any merit in discussing levels of conservatism with someone who has the old wig listed first as an inspiration. Passons. No offense intended, but that trail does not lead anywhere near the explanation you're looking for.

Misplaced Pages is a consensus-based project built primarily by humans who take pride in their work. That means that automated actions interfering with that work need to be based on a quite broad consensus. I only see that broad base missing for serialised delinking of solitary years. Still. I had seen it going on over the last few weeks, and didn't speak: as said I thought maybe the climate had changed. The reaction by other Wikipedians made me aware that things were still pretty much the same as when we discussed this a few years ago. --Francis Schonken (talk) 18:17, 28 June 2008 (UTC)

You could easily be accused of inflexibility too Tony, but this is hardly the point. Playing the man is generally considered bad form on Misplaced Pages, even if you claim afterwards that your derision of someone's position isn't "meant in that spirit".
Unless Francis has you under some kind of conservative mind control, no one is forcing you to click on those links. It is also possible to change their colour if they bother you that much. ☸ Moilleadóir 10:23, 29 June 2008 (UTC)
  • Moilleadóir, if the links were in this form:

The assembly voted to adopt the new measure on 16 October 1799 (other notable events of 1799)

…then I wouldn’t have a problem with it (if they were few and far between and limited to historical articles). I know there is a difference of opinion about the “principle of least astonishment”, and differences as to our view of the basic facts regarding what is “normal” behavior on the Web, and even whether it is reasonable to expect that all readers “learn and remember” Misplaced Pages’s behavior with links to dates. We’ll have to agree to disagree on these facts. But my main problem is with articles that have many dates in which I.P. users go ape shit linking every single one of them until a whole sentences are blue. But dates are not currently linked as I’ve proposed above, and further, all the current links do is take the reader to a damned list of random trivia.
Trivia ↑ (what does this have to do with an assembly vote held on 16 October 1799?) No one gives a dump.
Those of us here simply think that “trivia is too trivial” to bother cluttering up an article with links to it. You argue that “no one is forcing you to click on those links”, but, IMO, you are missing an important point. Users of the Web develop “brain filters” to focus on novelty and the information they are seeking. The brain learns to ignore extraneous information like advertisements and sidebars and in-line links to vendors, such as when they come across the term hard drive. If you bombard users with too many links, they stop seeing them. The sooner editors understand this important psychological behavior of the human mind and how one presents a properly crafted page of information that doesn’t over-stimulate the brain and invites exploration, the better off Misplaced Pages will be.

I honestly believe that many I.P. users who’ve gone wild linking the crap out of every damned date, have just been smitten with the power and excitement of HTML markup and Wikilinking and just need to go buy themselves a Commodore 64 so they can do some programming in BASIC and get it out of their system. Better that, than turning Misplaced Pages pages into one big turd of blue. Hooray for the bot! Greg L (talk) 17:56, 29 June 2008 (UTC)

No offence taken; I don't offend easily, which is a good stance in highly charged debates on a Wiki. Francis has had a good sniff around my talk page, so he will have reaslised that I have changed the colour of my links; as always, I'm more concerned about what our readers out there see. People have queried both the number and visual appearance of links on WP, unprompted, when the conversation turns to my active role on WP. They think it's odd to say the least, The old wig is among other likes and dislikes that are on the radical side;liking the music of the 18th century isn't a mark of conservatism, and nor is liking contemporary rock bands a mark of a willingness to change things.
So I still don't understand whether you people object just to the method of reducing trivial links, or are attached to the said links per se. TONY (talk) 10:44, 29 June 2008 (UTC)
Greg, love your analogy with Angela Lansbury, and I think "one huge turd of blue" needs to be carved into stone! TONY (talk) 03:39, 30 June 2008 (UTC)
Tony, not sure about the others, but I know I object far more to the method of removing links rather than the removal themselves. As I've stated below, at #Autoformatting purposes, I don't think the wikilinking of dates is a good idea, autoformatting notwithstanding. However, I can accept that the wikilinking of dates MAY sometimes be helpful, but it would take a human eye to discern those cases. So I object to a bot removing the wikilinked dates, but I do not object to human editors removing them. (However, if consensus decides that NO dates should be wikilinked at all, then obviously a bot could do that just fine. I don't think consensus will go quite that far, however.)--Aervanath lives in the Orphanage 14:29, 1 July 2008 (UTC)

L/T S/T M/T

{{Convert}} has been criticised for its use of the siemens per tesla symbol for the short ton. However, the Short ton, Long ton and Tonne articles do mention "S/T", "L/T" and "M/T". These, however, were added in January. The use of a solidus for abbreviations of units where no division is involved is somewhat odd. The forms "ST" and "LT" are much clearer. As for "MT", I wonder whether we should allow this at all. It's only in North American (US only?) English that the tonne is called a "metric ton" and the NIST uses "t". I propose that these abbreviations be added to the list of abbreviation to be avoided. JIMp talk·cont 03:29, 19 June 2008 (UTC)

  • The siemens/tesla (S/T) is entirely correct and is in conformance with the SI and should not be modified or degraded in some way to avoid conflicts with “short ton” / “long ton (tonne)” issues. Besides, ST (for short ton) and LT (for long ton) aren’t the correct unit symbols; the proper symbol for tonne is lowercase t (see the BIPM’s SI brochure, Table 6 (Section 4.1). Note further that besides the uppercase S being the symbol for the siemens, the lowercase s is the unit symbol for the second. So I believe it is best to not have any form of the letter S be used as an abbreviation for “short”—both s and S are in use already. And, indeed, there is mathematical division in “S/T” if one really means one siemens per tesla (just as one joule per second is J/s, which is one watt). It will be a holy war (that I don’t want to touch with a ten-foot pole) to effect change on such a well used unit of measure, but a reading of the BIPM brochure shows the following possible solutions:
    • metric ton = tonne = t = 1000 kg
    • short ton = 2000 lb (no use of the symbol t, no abbreviations, and no use of “ton”, all of which would be ambiguous)

Note also that Mt (for megaton), while rather unfamiliar to lay people, is entirely in conformance with the SI and is commonly used as a measure of greenhouse gas emissions and other environmental contexts. My suggestion would be to never try to ban the use of an SI-compliant unit of measure or unit symbol; non-SI-compliant abbreviations should yield first. Also, much confusion would be spared if editors weren’t so quick to use unit symbols. The best practice, in my opinion, is to spell out the unit of measure on the first and maybe second instances and—if the measure isn’t used too frequently, on all occasions in an article. Only if it the unit of measure is used many many times in an article, should the unit symbol be used—and even then—only after it has been introduced in the fully spelled out form. This is the way Encyclopedia Britannica does it because it follows the basic fundamentals of technical writing.
Greg L (talk) 03:53, 19 June 2008 (UTC)

Agreed: Yes, the non-SI complant should go first ... what do we do about metric horsepower vs petasiemens? I'd be happy to be rid of all six ton abbreviations; "S/T", "ST", "L/T", "LT", "M/T" and "MT"; on WP. Let the long and short tons be spelt out in full each time (even in infoboxes) and allow only the symbol "t" for the tonne. I don't know how familiar those abbreviations are, the spelt out forms are clear. It is best, in my view also, to spell units out though there are a few other exceptions besides those which are frequently used. Abbreviations/symbols should be prefered in infoboxes and in parenthetical conversions also if the unit name is long (e.g. "miles per imperial gallon"), the abbreviation/symbol should be prefered. Of course, there is another issue I'm raising here: that of the use of the solidus in unit abbreviations/symbols. I'm suggesting that this be restricted to the indication of division (per). JIMp talk·cont 04:18, 19 June 2008 (UTC)

  • As to your last point (the solidus), that is exceedingly common and quite proper. The velocity “one meter per second” is “m/s”. You’ll find this use everywhere. Density in symbolic form is mV and in actual units is g/ml (or g/cc). The only alternative is to use reciprocal units like m·s or just ms but that notation is generally only used in highly technical or scientific articles (and too frequently, IMO, here on Misplaced Pages). Greg L (talk) 04:33, 19 June 2008 (UTC)
  • P.S. As to the rest of you questions, I would suggest the following guidelines for editors:
  1. Consider the target audience and ensure not to write over their heads.
  2. Stay compliant with the SI unless a discipline consistently uses non-SI units.
  3. Spell out units of measure as much as possible. Resort to unit symbols only if they appear exceedingly often in the article, and even then, introduce them well with several instances of spelled out units.
The only possible discipline I can think of that might use petasiemens would be the bleeding edge of superconductor research. So if Misplaced Pages has an advanced article directed to such a high-level audience, and if that discipline really is using this fully-SI-compliant unit of measure, I don’t see a problem. Greg L (talk) 04:45, 19 June 2008 (UTC)
Something that I had not seen until recently is the use of the solidus in labeling the axes of graphs. For example if the horizontal axis of a graph is time (measured in seconds), and in the text the variable t is being used for time, the axis might be labeled t/s. I avoid this because while a few people may be trained in this usage, many other people will be searching through the text, trying to figure out where the variable s is defined. --Gerry Ashton (talk) 04:51, 19 June 2008 (UTC)
  • I think too many contributing editors read a technical paper or article somewhere and don’t have the confidence to revise the axis legends for greater clarity for a general-interest audience. While down at WSU talking with the Ph.D. on the medical device we’re working on, I noticed he had a number of books on technical writing. Ph.D.s do a lot of that. One of his books was titled “Why not just write it clearly?” (or something to that effect). Greg L (talk) 14:27, 19 June 2008 (UTC)
  • We cannot do away with the solidus, no, I'm saying we do away with it in unit abbreviations that don't involve unit division. Long tons are long tons not longs per ton, so "L/T" should be out. Kilometres per hour, on the other hand, can go km/h.
  • I always used to label my graphs like that but I haven't added any graphs to WP.
  • No, the petasiemens vs metric horsepower ambiguity of "PS" is hardly worth troubling about.

JIMp talk·cont 05:50, 19 June 2008 (UTC)

  • Oh, I get your point. Sorry. Indeed, we should certainly loose “L/T” for “long tons”. Yes, there is no division. “L/T” breaks so many rules and conventions. According to the BIPM, SI brochure, Table 6 (Section 4.1):

In English speaking countries this unit is usually called "metric ton".

And as I mentioned above, Section 4.1 also makes it clear that the internationally accepted unit symbol for metric ton is lowercase t; homegrown abbreviations are improper. I note that Misplaced Pages articles often use “tonne”. Either “tonne” or “metric ton” works for me. “Long ton” should be looked upon with disfavor IMO, and the bastard “L/T” symbol should certainly be deprecated in favor of “t”. I personally prefer “metric ton” over “tonne”, per the BIPM’s acknowledgment that it is the common term in English. Why? Everyone in Europe and the rest of the world recognizes what it is. And (bonus points) Americans also know what a “metric ton” means. But many Americans don’t know what “tonne” means and often assume it is a British spelling of “ton”. So “metric ton (t)” is understood by the widest audience, has the least confusion, and is absolutely unambiguous (which is why the BIPM acknowledges it).
As for short ton, all I can figure out is what I wrote above: • short ton = 2000 lb (no use of the symbol t because it means metric ton, no abbreviations like “S/T”, and no use of just “ton”, all of which would be ambiguous). Would you agree? Greg L (talk) 14:17, 19 June 2008 (UTC)
Agree that PS should always be petaseimens. If an article really needs Pferdestärke, it can be spelled out and wikilinked.LeadSongDog (talk) 20:40, 19 June 2008 (UTC)
Yeah, sorry, I guess calling the likes of "m/s" division wasn't that clear. One problem is that the unit Pferdestärke is actually very common in automotive articles where it's always abbreviated to "PS" ... we'd have an uphill battle convincing the editors of those articles to spell it out ... in German. Another problem is that the tonne is never called a metric ton in certain dialects of English (mine for example). JIMp talk·cont 00:36, 20 June 2008 (UTC)
I've just gone through all the Whatlinkshere/PS entries to find any Pferdestärke references and pipetrick dab them. No doubt there are still many non-wikilinked uses of PS though.LeadSongDog (talk) 04:35, 20 June 2008 (UTC)
  • Is there any reason PS can’t also be used as a symbol for Pferdestärke? Just because PS is the symbol for petasiemens doesn’t mean that an automobile-related article can't also use it does it? I can’t imagine that such widely different disciplines as automobiles and superconductors could trample on each others toes (confusion-wise). Greg L (talk) 04:56, 20 June 2008 (UTC)
That would seem to make sense, so long as template:convert (and the like) stick to the petaseimens meaning.LeadSongDog (talk) 05:46, 20 June 2008 (UTC)
I'm ok with having {{convert}} always spell out short tons and long tons. The term 'metric ton' or (sometimes 'metric tonne') is an American and Canadian term. However, as GregL points out, many of us in North America will assume, as I did many years ago when I first encounter it, that 'tonne' is just the British way of spelling 'ton'; similar to gram vs. gramme. Even the folks from Jimp's neighborhood would recognize what is meant by 'metric ton' and that's why I think it's a better choice. —MJCdetroit 03:04, 25 June 2008 (UTC)
  • Thanks MJCdetroit. To all: Note that according to the BIPM: SI Brochure: Section 4.1, Non-SI units accepted for use with the SI, and units based on fundamental constants: Table 6: “In English speaking countries this unit is usually called ‘metric ton’.” I sincerely hope that referencing the BIPM would settle the issue here. There will simply be no way to convince all editors that the terminology they’ve grown up with and are accustomed to is (or is not) the “normal” way or is “correct” or is the “best” term when referring to “tonne” or “metric ton”. I do note that my current version of Safari (3.1.1), just flagged “tonne” as a misspelling (if that means jack). As MCJdetroit alluded to above, simply calling it “metric ton” while awkward to some, will result in the least confusion since by far the greatest number of readers understand what it means. And, as I stated, if we can all lighten up on how sure we are that what our ears are used to hearing has got to be the “correct and only” way, and bow to the reality that the BIPM is saying the unit is “usually” called “metric ton” in English, then that will avoid a lot of needless bickering here. In acknowledgement of this reality, I recommend “short ton” (no symbol) and “metric ton” (symbol: t). Greg L (talk) 20:29, 25 June 2008 (UTC)

I agree with MJCdetroit and Greg L. NIST's Special Publication 811 on page 63 says the symbol for metric ton is "t", and gives no symbol for short ton or long ton. While NIST is not authoritative for the whole world when it comes to SI, they are authoritative for the short and long ton, since the USA is nearly the only country still using them. --Gerry Ashton (talk) 21:28, 25 June 2008 (UTC)

I disagree, in the UK we are familiar with the ton (which you in the USA choose to call the Long Ton) and its near metric equivalent the tonne. For example, in the context of transportation and transportation of dangerous goods 30 ton / 30 tonne are almost equivalents (within 2%); and most UK readers would not be familiar with the term Long ton. The BIPM appears to be referring to US-readers when it refers to "English speakers". So just for the benefit of the US, were are to expect the ton (Short ton) and the metric ton. My recommendation is the "ton" (long ton, no symbol), the “short ton” (no symbol) and “metric ton or tonne” (symbol: t).Pyrotec (talk) 21:51, 25 June 2008 (UTC)
Let me support Pyrotec on this. "Metric ton" might have been used in the 1970s, but it's simply no longer current in the UK. Consider the following google searches:
site:www.timesonline.co.uk - ton 827 - tonne 697 - metric ton 0
site:www.guardian.co.uk - ton 1,590 - tonne 2,410 - metric ton 1
site:news.bbc.co.uk - ton 102,000 - tonne 28,800 - metric ton 157
site:www.economist.co.uk - ton 52 - tonne 103 - metric ton 0
site:www.dailymail.co.uk - ton 2,840 - tonne 347 - metric ton 1
site:www.telegraph.co.uk - ton 4,300 - tonne 1,360 - metric ton 25
And of course nobody in the UK would have any idea what a "long ton" would be referring to.
(Note the "ton" figures also include a lot of instances of the word being used as slang for the number 100; and in expressions such as "a ton of people", meaning lots and lots of them; and other usages. So only a minority of these hits may be using ton as a unit of weight).
So I'd support Pyrotech, and recommend the "ton" (long ton, no symbol), the "short ton" (no symbol) and "metric ton" or "tonne" (symbol: t). Jheald (talk) 23:24, 25 June 2008 (UTC)
  • I’d argue that the key test shouldn’t be which term people use in different countries (which is obviously going to vary from country to country), but which term is “understood” by the widest audience. Are editors from England really trying to say that readers there don’t understand what “metric ton” means? The trouble is that Americans are entirely unfamiliar with what “tonne” means. I’m automatically skeptical of proposal that would have Wikipeda flouting what the BIPM says. Greg L (talk) 23:37, 25 June 2008 (UTC)
I think a fair number of people would find it very unfamiliar. The quasi-SI unit is the tonne, and it is not just in the UK that that is what is used:
site:www.smh.com.au - ton 2,190 - tonne 2,950 - metric ton 2
site:www.nzherald.co.nz - ton 650 - tonne 799 - metric ton 2
site:indiatimes.com - ton 2,910 - tonne 6,310 - metric ton 72
site:www.mg.co.za - ton 314 - tonne 282 - metric ton 6
site:site:www.theglobeandmail.com (Canada) - ton 1,720 -- tonne 1,430 - metric ton 40
site:en.wikipedia.org - ton 20,500 - tonne 3,050 - metric ton 431
It would be a big mistake to mandate that every instance of "tonne" must be changed to "metric ton". Jheald (talk) 00:40, 26 June 2008 (UTC)
  • Of course the official name for unit is “tonne”; that much isn’t in dispute. We’re also getting sideways on multiple issues here…

    One issue is whether the symbol for “tonne” or “metric ton” should be called L/T and various other variations on that theme (which is, after all, what is embodied in the very title of this section). Clearly, I would say ‘no’ to the use of any such unit symbols or abbreviations. According to the BIPM, the official symbol for the unit is lowercase t. We should abide by what the BIPM says and not stray from that policy unless there is a compelling reason to do so. In rare circumstances, official MOS policy flouts the BIPM. For instance, according to the BIPM’s SI brochure: Subsection 5.3.3, Formatting the value of a quantity, a space is always used to separate the unit symbol from the numeric value and this rule applies to the use of the percent symbol. Fortunately, in this case, MOS wisely ignores that BIPM rule and instructs editors to write “75%”, not “75 %”. Why is this wise? Because we are following commonly accepted and recognized conventions—the way the real world works—and don’t want to confuse our readers. I’m not seeing a compelling reason to ignore the BIPM here with regard to the unit symbol for “tonne/metric ton”; according to the BIPM, all the language-variations of Misplaced Pages should standardize on lowercase t for the unit symbol; no “L/T” or “LT” or “L-T”.

    The next thing to decide is how what unit name to call it by. The BIPM says “In English speaking countries this unit is usually called ‘metric ton’.” I can guarantee you that for America, that is true; spell checkers don’t even recognize “tonne” here (there’s a red squiggly line under it right now). But that isn’t the only reason I am advocating the use of “metric ton.” I am arguing that the term, albeit not the primary name in all English-speaking countries, is recognized (understood) by the greatest number of English-speaking readers. Your argument is that the BIPM’s assertion is wrong and/or outdated. But clearly, America—with a population of 300 million—has no idea what the unit “tonne” means; most assume it must be a “British specialised spelling for short ton”. The term “metric ton” is instantly recognized by Americans. And even though many British, New Zealand, Australian, and Canadian readers might chafe over how the term “metric ton” may not be standard in their area, I am confident that vast majority instantly understand what “metric ton” means when they encounter it (please point it out if I am wrong on this assumption). Once again, it’s not what unit name is a first choice preference, it’s what unit name is most widely understood.

    Finally, with regard to your statement, that it would be unwise to “mandate that every instance of ‘tonne’ must be changed to ‘metric ton’ ”, I am taking no such position. I don’t pretend to understand all the intricacies and implications of such a move. I would say that, certainly for new articles and edits where convenient, the wisest thing to do is use the least confusing “metric ton” (symbol t). Further, I am saying that to avoid confusion and ambiguity, the 2000-pound “ton” should be called “short ton” and should not use any symbols or abbreviations like “S/T” (and certainly not t, which is reserved). I advance that this all results in the least ambiguity and confusion, and further has the virtue of being entirely consistent with the BIPM’s resolutions and statements on the subject. Greg L (talk) 02:40, 26 June 2008 (UTC)

  • I absolutely agree with Greg_L that the symbol for the metric ton a.k.a. tonne is t. Not only does the BIPM say so, it says so in the official interpretation of SI for the USA (on page iii). I also agree with using the most widely understood term, even if it is a bit awkward for some. And I promise to never use the word "ton" by itself unless it is in a direct quote, and then I'll use a footnote to indicate which ton. --Gerry Ashton (talk) 02:55, 26 June 2008 (UTC)

We certainly should strive to use widely understood terms, yes. However, certain terms are just out of place in certain varieties of English. The term "metric ton" is clear and unambiguous but completely foreign in certain dialects—regardless of the assesment of the BIPM. According to WP:ENGVAR if the article has a strong tie to a given dialect, we are to use it, and if not any dialect is permitted. An article written in Australian English—it may be about uranium mining in the Northern Territory—should use "tonne" not "metric ton". The word is unambiguous, any confusion caused by certain readers' mistaking it for some quirky spelling of "ton" can be dispelled with a link or footnote (or conversion). I would therefore propose the following recommendation:

  • 1000 kg → "tonne" or "metric ton" & abbreviated to "t"
  • 2240 lb → "long ton" not abbreviated
  • 2000 lb → "short ton" not abbreviated

As for permitting the long ton to be written simply as "ton", this is ambiguous, inherently ambiguous, not just a result of some readers' unfamiliarity with spelling. An editor who comes across the word "tonne" in an article and who knows what a tonne is can quickly and easily clear the issue up for our American friends by providing a link/footnote/conversion. An editor who comes across the word "ton" in an article and who knows what a ton is, on the other hand, knows that clearing the issue up might take a good deal of digging around in sources and/or making assumptions and knows that there may even be no clearing the issue up at all because of the term's ambiguity. JIMp talk·cont 03:34, 26 June 2008 (UTC)

  • “According to WP:ENVAR if the article has a strong tie to a given dialect, we are to use it, and if not any dialect is permitted.” That makes sense to me, Jimp. We’re trying to write for maximum clarity and not all readerships are going to be the same for all articles. If it’s going to be an article on, for instance as you say, uranium mining in the Northern Territory of Australia, then editors should use terms and dialect appropriate for the readership that will most likely be coming to that article. I realise it should be “tonne” then. Greg L (talk) 06:36, 26 June 2008 (UTC)
The Economist (which has well over half its circulation in the United States) seems to think that "tonne" is sufficiently widely understood that no qualifier "metric" is understood (Economist styleguide).
I think you miss my point. In all contexts apart from specifically US-national ones, the Economist recommends to use tonne. Thus, so many tonnes of global CO2 emissions. The Economist does not recommend to use metric tons; and it does not appear to be worried that its majority US audience might not understand. Jheald (talk) 10:25, 30 June 2008 (UTC)
As for "long ton", the problem is this really won't be understood outside the United States. The simplest recommendation would be to prefer metric units. Of course, in some cases the quantity isn't sufficiently precise that it makes much difference; or the usage is historic -- eg "several tons of rubble"; "4-ton truck". If the measured quantity is exact (or at least given more accurately than +/- 20%), and there is a overwhelming reason that a non-metric ton be used, then we should perhaps insist on a metric conversion, because that would clarify exactly which ton was in question.
How serious do we think the problem is? How many examples do we think there are of cases where the word "ton" is being used, and could cause serious ambiguity that is not already readily resolvable from the context? How does WP currently use the word "ton" ? Jheald (talk) 09:05, 26 June 2008 (UTC)

1. As an aside: Version 7 of the SI brochure said:

Version 8 of the SI brochure says:

I think the change from some to usually is surprising, particularly since one of the main editors is British.
2. A web search attributes the following text to ANSI/IEEE Std 268-1992 and to the U.S. Geological Survey:

  • The term "metric ton" should be restricted to commercial usage

3. I am sympathetic to the idea that understandability/accessibility for all is more important than familiarity for the narrower interests of those within a particular domain or region. I think this is why Misplaced Pages prefers micrometres/nanometres over microns/angstroms.
4. Mass units are ambiguous in US-related articles but not elsewhere and the metric system is regarded as an anomaly that needs to be highlighted. This is why a special prefix word is widely used there but not elsewhere.
5. I do not know which way to go on this one. Lightmouse (talk) 01:27, 27 June 2008 (UTC)

Metric ton should be clear enough to everyone but I wouldn't go so far as prohibiting the word tonne, if it's not recognised by half the English-speaking world, this is a serious problem, but there are solutions which need not require the use of a term which has no place in the given dialect an article is written in. JIMp talk·cont 01:38, 27 June 2008 (UTC)
Regarding Lighmouse's points:
2. Without the context, we can't tell what ANSI/IEEE Std 268-1992 and the U.S. Geological Survey want instead of "metric ton" in non-commercial use; maybe they want megagram.
4. The tonne isn't formally ambiguous anywhere, but it is confusing for many Americans everywhere. If the American does not know what it means, the context of the article won't help. --Gerry Ashton (talk) 01:50, 27 June 2008 (UTC)

Yes, for point (2), they may have been giving Mg priority over tonne/metric ton. I hope so. The world is more complicated because of the low usage of units like Mg and Mm, as our current discussion demonstrates .
For point (4), I meant ambiguity between just two mass units (short or metric tons). Lightmouse (talk) 02:04, 27 June 2008 (UTC)

Incidentally, the difference between long ton and tonne is only 2%. Whereas the difference between short ton and metric ton is 10%. This should have an effect on how seriously people in the US and in the British Commonwealth treat the ambiguity of the old units. Lightmouse (talk) 02:12, 27 June 2008 (UTC)

For what it's worth Googling Australian pages turns up hits for tonne vs metric ton in a ratio of over 240 to 1. For NZ: over 160 to 1. For Ireland: almost 70 to 1. For the UK: over 80 to 1. Even for Canada the same ratio is almost 50 to 1. Worldwide: about 4 to 1. Interestingly enough, for US it's over 2 to 1 ... if I've searched correctly. JIMp talk·cont 03:14, 27 June 2008 (UTC)

What is the correct way to apply prefixes to 'metric ton'? Lightmouse (talk) 10:37, 27 June 2008 (UTC)

The aim should be to convey unambiguous information with the minimum of confusion. For most purposes I think a linked tonne would suffice. And the SI prefixes follow naturally as kilotonne (kt), microtonne (μt), etc. If metric ton is used, it is wise to avoid prefixes. The context should never be used as an alternative to disambiguation. Thunderbird2 (talk) 11:30, 27 June 2008 (UTC)

I think the preferred way to express mass is with multiples and submultiples of the gram. The tonne and metric ton are undesireable, prefixed versions of the tonne are more undesireable, and I have never heard of a two-word unit taking a prefix—megacubic metres, anyone? --Gerry Ashton (talk) 12:50, 27 June 2008 (UTC)

Depending on context, I'd consider either megastere, gigalitre, or (in a pinch) hm to avoid "million cubic metres" LeadSongDog (talk) 14:48, 27 June 2008 (UTC)

In English (UK English) it is common to refer to 1,000 tonnes or 2,000 tonnes. Putting the issue of whether we call it a tonne or a metric ton to the side for one moment, a kilo-metric ton or even 2 kilo-metric tons seems daft. On the other hand 1 or 2 kilotonnes seems more reasonable; and Nuclear weapon yield's are expressed as TNT-equivalents in kilotons (or kilotonnes) and megatons (or megatonnes) - OK for "hairspliters" there a cumulative errors of about 2% between the two tons/tonnes. But, do we really need to dissambiguate a kiloton (or kilotonns) as one mega-kilogram; or one gigagramme?Pyrotec (talk) 16:31, 27 June 2008 (UTC)

Indeed, kilotons sounds like nuclear explosive yield. But then, so too does megaton and the environmental world uses megatons all the time when it comes to CO2 emissions. Different disciplines are used to different terminology. Little of what other editors above are saying above can’t be resolved simply by using language like this:


In 2001, Iowa produced 42.3 million metric tons (42.3 Mt) of corn.

While *awkward* for some, it it confuses absolutely no one (which tonne would) and is fully SI-compliant and is fully in accordance with the teachings and advise of the BIPM. Greg L (talk) 19:13, 27 June 2008 (UTC)

The terms 'tonne' and 'metric ton' are not ambiguous. They may be unfamiliar. I do not believe there is a problem to solve here. The term 'corn' is ambiguous though...  :) Lightmouse (talk) 19:37, 27 June 2008 (UTC)
  • I think we’ve addressed the title issue: the use of “L/T S/T M/T”. I think we’ve also arrived at a consensus that “long ton” is not to be used (leaving only “tonne” and “metric ton”). I believe we have reached a consensus that the proper symbol for “tonne / metric ton” is the SI symbol t and certainly not “L/T” nor any variations of same (all of which are intended to stand for “long ton“). I think we have also determined that no unambiguous and suitable symbol for the short ton exists and the abbreviation S/T should not be used since both the S and the T are taken by the siemens and the tesla (and the lowercase s is reserved for the unit of time second). Therefore, “short ton” should be spelled out and no abbreviations or symbol used. I think we’ve also reached a consensus that the word “ton” should not be used as it is ambiguous since it can mean either 1000 kilograms or 2000 pounds. I think we may have arrived at a consensus that the choice as to whether “tonne” or “metric ton” should be used can be influenced by the subject of the article: in articles that are quite narrow in scope and very much tied to a particular country, such as uranium mining in the Northern Territory of Australia, editors should use “tonne” since it is most familiar to readers speaking the Australian dialect of English and it can reasonably be anticipated that the majority of readers will be Australian. What has not necessarily reached a consensus (but what I support) is that for general articles likely to be of interest to readers speaking the full variety of English dialects, the term “metric ton” should take preference over “tonne” because the latter is not understood by Americans and the former (metric ton)—while not a native first choice in some English dialects—is well recognized by all English dialects because of its intrinsically descriptive name. Greg L (talk) 05:52, 28 June 2008 (UTC)

MOSNUM should prefer tonne because it is unambiguous, is broadly accepted and has an internationally accepted symbol (t). If there is local consensus that "tonne" might cause confusion in a particular context, then let local editors make that decision. In a nutshell, MOSNUM should:

  • prefer tonne
  • permit metric ton, short ton and long ton where spelt out in full and linked
  • deprecate the other abominations

Thunderbird2 (talk) 12:41, 28 June 2008 (UTC)

  • All right. In my previous post, perhaps I should have said “general consensus.” I realize that there is no way all editors are going to be in agreement on this because different dialects have different practices. If it weren’t for a MOS rule, there would be edit warring over “color v.s. colour.” But at least an American understands what “colour” means (even though it looks odd to them, and visa versa). The issue at hand is much more substantial than that. “Tonne” may be unambiguous by definition perhaps, but it is certainly not unambiguous in practical effect because it is virtually unknown by 300 million Americans, many of whom assume it is a British spelling for an Imperial (pound-based) short ton. This is why even the BIPM (the organization that endorsed the name of “tonne”) says that In English speaking countries this unit is usually called "metric ton". The BIPM isn’t concerned about “being right” or “getting its way”. All the BIPM cares about is communicating without confusion; as does Misplaced Pages. Though it may be an unused term in other English dialects, everyone knows what “metric ton” means. That’s also why the symbol t should only be used for the “tonne / metric ton” (both have their uses), and why “ton” should be deprecated (because, indeed, it is quite ambiguous). Greg L (talk) 16:29, 28 June 2008 (UTC)
I say permit but tonne and metric ton & let editors decide which is most appropriate according to context. This is basically what has been happening on WP and thus this is where consensus really lies. One thing we should discourage is the over-kill metric tonne: there is no other tonne. Greg, stop for a moment, we're talking about three different units. Ever heard of a stone? It's a fourteen-pound unit that was once common in English-speaking countries outside of North America. When the Poms adopted the ton they warped it to fit stones in, just like they did to the mile. So a long ton is 160 stone, i.e. 2240 pounds, slightly more than a tonne. Dog, gigalitre, sure but I'd avoid the obsolete megastere, even cubic hectometre (an SI unit) would be preferable. I believe that a ton of TNT is the same as a tonne of TNT: it's not an exact measurement but a conventional definition. JIMp talk·cont 00:29, 30 June 2008 (UTC)
  • Good job Jimp; you figured out my confusion. No. I did not know we were talking about three different units. Yes. I spent a month on the British Isles (England, Scottland, Wales, N & S Ireland) and was quite surprised to be faced with stones when I stepped onto a scale. That was back in 1978 and I believe some of you still measure body weight in stones to this day, yes? And yes, I forgot all about that the long ton stood for 2240 lbs. In fact, now that I think about it, “tonne” is what I long figure stood for “long ton” (the British spelling for a 2240-pound ton). I’m a mechanical engineer who’s not too shabby with my units of measure (for an American engineer even) and I didn’t figure out that “tonne” was the official name for 1000 kg until I was in my 40s. Yes, I know that sounds sad. My point is that I can guarantee the editors here that the average American hasn’t a flying clue what “tonne” means. Given the reality of the situation, I fully agree with you that the reasonable thing to do is permit “tonne” and “metric ton” depending on what is most appropriate according to context. So…

    Where are we at? Fill in the blanks below. I’ll start:

  • Metric ton / tonne (1000 kg). Symbol: t “tonne” to be used in contexts strongly tied to countries with English dialects that use “tonne”.
  • Short ton (2000 lbs). Symbol: None? (can there really be confussion with S/T (siemens/tesla) within an article? Is there a standard symbol or abbreviation?)
  • Long ton (2240 lbs). Symbol: ?? (can L/T really be confused with anything from the SI within an article? Is there a standard symbol or abbreviation?)
  • Ton (to be deprecated as ambiguous).
Greg L (talk) 05:57, 30 June 2008 (UTC)
Thinking outside of the box...
LongT = 2,240 lb
ShortT = 2,000 lb
Therefore, ...her mother-in-law weighs 28.0 metric tons (27.6 LongT; 30.9 ShortT)
Without any "standard" symbols, that's what I came up with. Please improve it if you can... —MJCdetroit 16:29, 30 June 2008 (UTC)f
(unindented)
  • Does any of the above come from real-world practices? Or would it be a home-grown “invention”. And even if the former, it saves little room. I note that Encyclopedia Britannica is big on avoiding symbols and just spells out units of measure unless they repeat a great many times. If there are no symbols that are widely recognized in the real world, I would suggest we just write out “long ton” and “short ton”. Greg L (talk) 19:09, 30 June 2008 (UTC)
We the Brits do measure (human) body weight in stones and pounds; and also kilograms. However if it was a vehicle body we would weigh it in tons and hundred weight (cwt); or tonnes and kilogrammes. I see the US has 100 pounds to the cwt and the UK has 112 pounds to the cwt.

I've just added the following point to Confusing units and symbols

The terms long ton and short ton are written out in full. The the symbol t or the terms tonne or metric ton, as appropriate in context, are used for the metric unit of 1000 kg.

I believe that this reflects the general conclusion of this discussion without going beyond what we seem to have agreed upon. JIMp talk·cont 07:59, 3 July 2008 (UTC)

I believe that to be a fair summary. Lightmouse (talk) 09:41, 3 July 2008 (UTC)

Placement of Jimp's edit

Jimp placed the statement above in the former "Confusing units and symbols" section, but there was similar advise in the Disambiguation section. I feel this structure invites the creation of inconsistent advice in the two sections. Therefore, I have moved Jimp's contribution to the "Disambiguation" section, combining it with what was already there. I also renamed the "Confusing units and symbols" section to Units and symbols often written incorrectly to more precisely indicate the contents of the section. I am not particularly attached to the wording I used, and invite improvements. I would be opposed to having disambiguation advice in two different sections.--Gerry Ashton (talk) 13:58, 3 July 2008 (UTC)

date autoformatting is optional

I'd like to remind users that for some time now, the autoformatting of dates has not been required.

There are four advantages in not linking dates:

  1. Inconsistent raw formatting within an article is obvious to editors and thus less likely to escape our attention. (The autoformatting mechanism conceals the inconsistencies from us, the very people who are most likely to enforce consistency, but the raw formats are displayed in bright blue to almost all readers, who are not registered and logged in. The rules for the choice of format in an article are in MOSNUM, here); they are easily summarised as (a) be consistent within an article; (b) take account of national ties to a topic; and (c) retain the existing format unless there's a good reason not to.
  2. There are fewer bright-blue splotches in the text, which makes it slightly easier to read and improves its appearance.
  3. The following issues concerning the dysfunctional aspects of the autoformatting mechanism do not arise:
    • piped links to date elements (], ] ]) (several forms of piped links break the date formatting function);
    • links to date ranges in the same calendar month e.g. December 13–17 or the night of 30/31 May – the autoformatting mechanism will damage such dates (30/May 31);
    • links to date elements on disambiguation pages;
    • links to date elements in article and section headings; and
    • links to date elements in quotations (unless the original text was wikilinked).
  4. As a minor advantage, edit windows are slightly easier to read and edit.

It may be that WikiMedia can be persuaded to invest resources in revamping the mechanism to avoid or mitigate these problems, but this is unlikely to occur in the short to medium terms. TONY (talk) 14:01, 21 June 2008 (UTC)

  • Oh… I SEE. Autoformatting of dates that adjusts to user preferences. That is quite cool and I would use it if it was a well implemented tool. But… there is no doubt about; having the autoformatting irrevocably accompanied by click-to-be-disapointed blue-link text blows. So I certainly won’t use it. Whats-his-face the developer is wrong to take his “go fish” attitude in the face of so much consensus of opinion. However, I’m sure he is a volunteer contributor (just like the rest of us) and has a perfect right to participate only in what he agrees with; that is an important element of enjoying this hobby. Otherwise, it’s just toil.

    So we’re left with the choice of using the cool, oh-so-logical, Euro-way date convention (14 December 1799) or the stupid American way (December 14, 1799). Though Americans aren’t accustomed to the Euro-cool way, they are able to instantly parse it so there is zero confusion. There’s no point just flipping a coin, so I use the Euro way. A parsing template that looked towards the user’s preferences and doesn’t link to a random, irrelevant list of events would be far superior to forcing editors to make such a formatting convention choice (or using the current autoformatting and its click-to-be-disapointed™). Greg L (talk) 19:10, 21 June 2008 (UTC)

  • Greg—Just as for spelling, there are rules (in MOSNUM, actually) for which date format is most suitable for an article. They're based partly on the rules for EngVar. Brion what's-his-face was not just neutral, but slightly uncooperative. I don't think he's engaged closely in WP editing, somehow. The Bugzilla page remains open, but languishes. The American way is unfortunate in its requirement of a comma (to separate the jostling figures); but I see no reason that both systems not be used on a consistency-within-article basis, just like spelling. I think US readers might be upset to see the Chicago article in European format, and UK readers the London article in North American format. No problem, then ...
  • The only other thing we can do is take it high up the food-chain in WP. ArbCom is really only for dispute resolution; I wonder whether Jimbo might be the best port of call. The best plan might be to say to him that we got 85 signatures a year ago to get the linking and autoformatting mechanisms decoupled, and we could get hundreds now. If we did, would you be willing to make representations for us to WikiMedia's board?
  • Does that idea appeal? TONY (talk) 09:32, 22 June 2008 (UTC)
  • If you want to take the lead, I’ll help. It’s one of those things that isn’t a glaring shortcoming, but I’m pretty confident we are taking the right stance on an issue that will make Misplaced Pages incrementally better. As for keeping the date style relevant to the subject (it’s not 4 July 1776), I agree. I guess I’ve never added a date to a Misplaced Pages topic that was closely tied with particular country. I’ve focused intently to articles like Thermodynamic temperature, Kilogram, Kelvin, Parts-per notation, and Mass versus weight. Since all are universal and scientific in nature, the Euro formatting of dates seems to have been accepted and successful so far. A date tool that adjusts to user preferences would be a better option yet. Greg L (talk) 19:10, 22 June 2008 (UTC)
  • P.S. While we’re getting things done with developers, how say we also inquire into what it takes to get some character-counting parser functions made so magic words and templates can handle delimiting numeric strings without mathematics. Both {{delimitnum}} (also languishing as bz 13025) and {{val}} would benefit; both are too buggy for general use. Greg L (talk) 22:42, 22 June 2008 (UTC)

Is there already a Bugzilla request open for autoformatted dates not to show up blue? --Hroðulf (or Hrothulf) (Talk) 10:35, 23 June 2008 (UTC)

Once again, here is the link to the still-open but moribund Bugzilla link. The petition is presented some way in via a link to a WP page. BTW, someone has said that MediaWiki's developers are all volunteers: not quite true, I believe—there are one or two part-time paid developers among the volunteers. TONY (talk) 00:55, 1 July 2008 (UTC)
  • Dank55 has alerted me to the operation of a bot that is going around linking full dates. The bot text cites MOSNUM as insisting on autoformatting. I've notified the user here and invited him/her to discuss the matter here. TONY (talk) 13:23, 1 July 2008 (UTC)
  • This whole debate has confirmed in my mind that the auto-formatting, while seeming cool on first impression, is not useful and should be disabled. I have disabled mine. I think the autoformatting causes us to lose sight of what we are doing: we are creating an encyclopedia for everyone, not just logged-in users. People who have not logged in or created an account have no autoformatting option, and therefore the whole thing is moot for them. When we as editors have the option, we forget that what we see is not what everyone else sees, and therefore are one further step removed from creating an encyclopedia for everyone.--Aervanath lives in the Orphanage 15:03, 1 July 2008 (UTC)
    • Indeed, Aervanath. But disabling it would cause back-compatibility problems with millions of items all at once. And non-logged in readers (the 99%) do have to put up with the bright-blue rinse, but of course see the raw formatting. No point anyway for them. That's why I'm increasingly inclined to try to change the culture so people just don't use it, rather than trying to fix it by petition. Otherwise, give us an autoformatter for "colour/or" and ize/ise, please. All too silly; we're adults, and accept what are basically two varieties of spelling and two varieties of date formatting. Big deal. TONY (talk) 16:01, 1 July 2008 (UTC)
  • Yes. Having a feature (autoformatting) that is only for registered users is useless for the vast majority of readers. We might as well forget that the “autoformatting” feature exists. That leaves only the “virtue” (plague) of links to random events. By having such extensive detail on autoformating of dates on MOSNUM, we are essentially inviting editors to use the tool. There must be dozens of templates that are not mentioned on MOSNUM that, if used, would actually improve Misplaced Pages. I suggest we nearly delete the entire Autoformatting and linking section. Instead, it would be replaced with this:

Autoformatting and linking

Note that dates can be autoformatted and linked by coding as follows: ]. Depending on the preferences setting of registered users, this autoformatting feature allows some registered users to see that code displayed and linked as October 16, 1925 where still others might see 16 October 1925. However unregistered users (the vast majority of readers on Misplaced Pages) will simply see the code displayed as 1925-10-16. Since the autoformatting feature does not work for unregistered users, and since the accompanying linking feature almost always takes readers to articles that are lists of historical trivia, Misplaced Pages recommends that links to dates generally be limited to articles that are intrinsically historical in nature, such as “French Revolution,” and that such links be limited to years, year ranges, and decades, and—even then—they should be done only judiciously where the link would naturally be of likely interest to that readership. Links to dates (like 16 October) are discouraged for all but the rarest of circumstances.

That’s my suggested text for the current guideline. Greg L (talk) 01:54, 2 July 2008 (UTC)
  • Greg: nicely written indeed. It does suggest to the troops that autoformatting was designed as a link ... but when you look at Brion Vibber's opening statement at Bugzilla, he appears to confirm that he saw that as an advantage (i.e., linking years is useful, so why not couple these functions ... aargh). I hope you don't mind that I changed your "merely" to "almost always", just to avoid possible criticism. In principle, I like it. Yes, the last sentence raises the association with "On This Day" columns in newspapers and, indeed, WP's main page. OK for stimulating armchair interest, but it's diversionary entertainment, isn't it! Angela L., eat your heart out. TONY (talk) 03:25, 2 July 2008 (UTC)

Responding to the question on my talk page:

Well, first of all I'm not operating a bot. My edits are manual, assisted by AWB. Secondly, yes I am aware that some users don't like dates to be wikilinked and I know that date wikilinking is not required. I understand from MOS:SYL that it can be done optionally i.e. it is neither required, nor forbidden. I interpret this to mean that I can do it.
No, I don't know of any bots wikilinking dates in the main text of pages. I'm not, and won't be, doing this in bulk.
Now, I consider that my edits are useful, as:
  1. I'm correcting incorrectly formatted dates in template fields such as dates with ordinals, abbreviated months, dates in / format etc. which I don't believe is at all in question, as is in compliance to WP:DATE and the templates' recommended date format. I am not converting American date format to International or vice versa, nor insisting on a 'default' date format.
  2. Whether or not wikilinking of dates is wanted as part of the user date preference, by linking them as per current functionality I allow users to view dates in a consistent format. I am not converting American date format to International or vice versa, so wikilinking these dates doesn't change the displayed formats for users who aren't logged in. My edits to dates in 'cite' templates are in compliance with the recommended/supported format of the template. If it is agreed that wikilinking of dates is not wanted in Misplaced Pages, all these dates can be unlinked by changing a handful of templates, instead of needing to change thousands of articles.
So, if there is a Wikimedia change to date rendering, I believe my edits will assist compliance to the new format as dates I've changed will be reformatted automatically. Thanks Rjwilmsi 17:27, 1 July 2008 (UTC)
Rjwilmsi's approach highlights a conflict. Rjwilmsi seems to think that the Cite book template says to put dates in ISO format, that is sufficient authority to do so. However, this guideline says to use consistent format throughout an article, including the citations and references. The template has no parameter to specify which format is being used in an article, so there is no way it can reformat dates to match the other dates in the article. It will be correct for articles that happen to use the same format as the template, and wrong for the rest. I have started a new section to discuss this conflict. --Gerry Ashton (talk) 18:46, 1 July 2008 (UTC)

Writing out years at start of sentences?

The MOS states, when a number is at the start of a sentence, it should be written out, unless it's a "Proper name" or "formal numerical designation." I would posit that a year counts as a formal numerical designation, and therefore, when it opens a sentence, it should be "1952 was a bad year for the studio," instead of, "Nineteen fifty-two was a bad year for the studio." This is in re an argument on RKO Pictures. So, when a year is at the start of the sentence, should it stay a number, or should it be written out? --Golbez (talk) 19:41, 24 June 2008 (UTC)

I think Golbez has found another exception. There is at least one more: The stock price fell from 101 to 9 in three hours. should not say nine. Septentrionalis PMAnderson 19:49, 24 June 2008 (UTC)
  • I agree, Golbez has found another exception where beginning a sentence with numerical digits could per permitted. I would add that it might look even better, IMO, to revise the sentence to read “The year 1952 was bad for the studio.” It’s passive voice, but beats starting with digits. At least, that’s the way it seems to me; I’m no expert on this. Greg L (talk) 22:00, 24 June 2008 (UTC)
The MOS specifically is against that, "Avoid inserting the words the year before the digits (1995, not the year 1995), unless the meaning would otherwise be unclear." --Golbez (talk) 23:40, 24 June 2008 (UTC)
  • Greg: It's not passive voice. Yes, MOS does say not to write "The year ...". I'd do it only in desperation. I personally find the spelling out of years impossibly fussy and long-winded. TONY (talk) 04:21, 28 June 2008 (UTC)
  • I see. That makes sense. No point having extra verbiage that doesn’t do anything other than pad a sentence with introductory fluff. I suppose a better way to write the sentence that avoids passive voice, and avoids padding, and doesn’t begin a sentence with digits is “The studio experienced a tough year in 1952.” A declarative statement that provides additional specificity might be better yet: “The studio released a string of poorly received movies in 1952” or “The studio lost money in 1952” (or whatever the problem was). There are probably a hundred ways to accomplish this without begging a sentence—or worse yet—a paragraph, with digits. Greg L (talk) 05:40, 25 June 2008 (UTC)
  • And you’ve probably got a print copy of a manual-of-style book in your possession (or at least heavily refer to an on-line one). Yes? Greg L (talk) 00:11, 26 June 2008 (UTC)
The issue would be resolved by a simple edit to existing exception 3 under Numbers as figures or words. The bullet point currently reads
Numbers that begin a sentence are spelled out; alternatively, the sentence can be recast so that a figure does not begin the sentence.
This might helpfully be edited to read
Numbers—including years—that begin a sentence are spelled out; alternatively, the sentence can be recast so that a figure does not begin the sentence.
This accords with the Chicago Manual of Style, which gives as the pertinent rule: "At the beginning of a sentence any number that would ordinarily be set in figures is spelled out, regardless of any inconsistency this may create." CMS provides an example exactly on point: "Nineteen seventy-six was the year of the nation's bicentennial celebration." Following this, there is a subordinate clause to the primary rule: "If this is impracticable or cumbersome, the sentence should be recast so that it does not begin with a number." According to CMS, the standard is clearly to spell out; clearly, beginning a sentence with a year expressed as a numeral is improper, full stop, without exception. If an extraordinary consideration of "practicality" or "cumbersomeness" applies, then recasting may be pursued; however, spelling out a year at the beginning of a sentence is clearly not regarded as usually "impracticable or cumbersome."
The CMS directive accords with the practice of the New York Times, which commonly publishes sentences that begin with spelled-out years (and, of course, never publishes a sentence—aside from direct transcription—that begins with a year expressed as a numeral). Here are a half-dozen essentially random examples: (see graf 1), (see graf 5), (see graf 1), (see graf 13), (see graf 4), (see graf 1 on this, the second page of the online version of the article). I've restricted my examples to articles that offer free access to all; I have also not included any of the many, many examples where a person is quoted uttering a sentence that begins with a year--which is, of course, invariably spelled out.
A few editors seem to hold the personal opinion that beginning a sentence with a spelled-out year is "pedantic" or somehow odd. The fact is that it is well-established style and one that is commonly seen in leading publications in American English. In sum, while editors should have the option of recasting where it makes a substantial difference, there is clearly no need to force recasting on sentences that demonstrate absolutely admirable, well-supported style. The change I've proposed—or a similar one elsewhere on the page—should nip such unnecessary contortions and the resulting disputes in the bud.—DCGeist (talk) 06:44, 26 June 2008 (UTC)
Well to somebody who doesn't read American newspapers, namely me, the spelled-out style looks clumsy, unnecessarily long-winded, harder to assimilate, and gratuitously at odds with how we represent dates anywhere else. I don't dispute that the sentence shouldn't start with figures - this is, e.g., the first point the Economist style guide makes on numbers generally, though it doesn't specifically discuss years ; but I think the sentence should preferably be re-cast. Jheald (talk) 08:46, 26 June 2008 (UTC)
I believe expressing a general preference in the MoS would be a bad move, as such general preferences are quickly interpreted as universal rules by the narrow-minded. In actual practice, some sentences lend themselves to recasting and others do not. It is instructive to look at the present case in RKO Pictures, where both of the attempts to recast the sentence have resulted in clearly inferior expression—awkward, redundant, conceptually jumbled. Some statements do naturally call for sentences that begin with a year—the evidence both of the present case and of the many instances in the New York Times supports this assertion. I hope we will agree that when stylistic preferences that are essentially visual clash with the demands of clear and felicitous verbal expression, the former must bow to the latter.
As a side—but important—point, please recognize that you are objectively incorrect when you claim that spelling out a year at the beginning of a sentence is "gratuitously at odds with how we represent dates anywhere else." Aside from your inappropriate use of "gratuitously" (I have provided more than enough evidence to demonstrate that the position you happen to disagree with is far from gratuitous), the fact is that we, just like the New York Times and the Chicago Manual of Style and every respectable English-language periodical and publishing house I know of, spell out the year at the beginning of a sentence when we're quoting someone's spoken words.—DCGeist (talk) 10:18, 26 June 2008 (UTC)
Talk about a storm in a teacup! Recasting seems like the best way to deal with this minor infelicity, as I agree spelling the year out looks poor and long-winded. --John (talk) 16:24, 26 June 2008 (UTC)
Thank you. For the record, the recommendation of CMS is, in full: "When a number begins a sentence, it is always spelled out. To avoid awkwardness, a sentence should be recast." Septentrionalis PMAnderson 01:30, 27 June 2008 (UTC)
  • Thank you PMAnderson. The tighter the rule, the better it is. The Chicago Manual of Style on this issue is, IMO, perfect and should be adopted by for Misplaced Pages’s MOS. Greg L (talk) 05:57, 28 June 2008 (UTC)

←Looks good. TONY (talk) 08:04, 28 June 2008 (UTC)

External authorities

I find people here far too willing to refer to a narrow range of American sources, particularly CMOS. Can I say that you'll get more traction here if you occasionally refer to non-American authorities, too? For all its worth, CMOS degrades itself by (1) being extraordinarily unwilling to update itself, and (2) not following its own rules, and (3) making highly questionable dictums. TONY (talk) 04:25, 28 June 2008 (UTC)

Tony, what do you mean by "highl questionalbe dictums"? If you mean they adopt a position that is contrary to what most other publishers adopt, that would indeed be highly questionable. If you mean they make an arbitrary choice from several acceptable alternatives, there is nothing wrong with that, because they don't purport to describe every acceptable usage; they purport to set forth usage for the University of Chicago Press. --Gerry Ashton (talk) 12:40, 28 June 2008 (UTC)
They're alarmingly reluctant to update as the language evolves. And I'm suspicious of styleguides that make lots of money from selling hard copy, and thus not allowing instant, free, wide access. Formatting and punctuation in bibliographies is a particular gripe of mine.
But it's better than the APA guide. And don't get me wrong: there's a lot that's good in CMOS. Here, I'm finding that CMOS is mentioned almost exclusively as an external authority. This is inappropriate. TONY (talk) 11:27, 29 June 2008 (UTC)
Oh, and on the APA guide, which is treated in god-like terms by psychology and even related fields such as sociology: what gets up my nose is how much money they make by making superficial alterations every few years, getting every library and department on the planet to buy the new edition, but persisting with crappy, outdated requirements in many respects. People "love to hate it". Well, that's not good enough. TONY (talk) 00:48, 1 July 2008 (UTC)

monthly update: request for advice

I haven't watchlisted MOSNUM for most of this month (swamped my page when I did). Advice please: almost 100 edits here during June, and from the diff it's hard to know what has settled and what is still in contention. There's such a large volume of changed text that I think it's best to link to the appropriate sections and just give a summary of the substantive changes—in some cases "Significant changes to blah ".

Can people assist me by pointing out the sections that are reasonably stable and substantively changed? And any particular changes you think editors at large should be explicitly warned about, please say so now. It has to be as succinct as possible, and NPOV, of course. In the May update I think I alluded to instability but quailed at grappling with specifics. The June update will be published in the Signpost on 7 June, and I'll start preparing it in the next few days. TONY (talk) 04:31, 28 June 2008 (UTC)

Here are the previous updates. TONY (talk) 04:33, 28 June 2008 (UTC)

Thanks; it's an area I'll flag as having been completely recast, with a link to the actual new text in MOSNUM. Would rather not refer them to the complex history of discussions. TONY (talk) 08:09, 28 June 2008 (UTC)

hard-space sentence

Anderson, do you really think this is well-constructed?

Misplaced Pages recommends using a non-breaking space (also known as a hard space) when a line break would otherwise displace elements to a new line that could be awkward at the beginning of a line:

Now it has become:

Misplaced Pages recommends the use of a non-breaking space (also known as a hard space) when necessary to prevent the end-of-line displacement of elements that could be awkward at the beginning of a new line:

You've more recently added the "when necessary". Why? It says "could be awkward", and it says "recommends". Who would insert a hard space that wasn't necessary in this context? The two additional words are quite redundant. TONY (talk) 11:40, 29 June 2008 (UTC)

Lots of people. If every FAC reviewer were as reasonable as Tony, it might not be necessary to specify that this is not "always make the space before endash non-breaking". But if we do not make clear that this is not what is meant, Tony's wording will be so read; unless there is substantive disagreement, where necessary should be restored. Septentrionalis PMAnderson 22:42, 29 June 2008 (UTC)
  • My 2¢? I never would have noticed such a nuance if you two detail-oriented editors hadn’t brought it up. But logically and grammatically, I think if the “when necessary” is to be included, the text would read best if it concludes with “…would be awkward…”. If there is no “when necessary”, then “…could be awkward…”. I like the former construction here (…when necessary if it would…). In other words, either this:

Misplaced Pages recommends the use of a non-breaking space (also known as a hard space) when necessary to prevent the end-of-line displacement of elements that would be awkward at the beginning of a new line

or this…

Misplaced Pages recommends the use of a non-breaking space (also known as a hard space) to prevent the end-of-line displacement of elements that could be awkward at the beginning of a new line

I’ll so revise to the more declarative (topmost) option. If someone doesn’t like it; be my guest to revert. Greg L (talk) 00:30, 30 June 2008 (UTC)

Autoformatting purposes

Discussion moved from wp:context: start
I am currently engaged in a discussion with User:SilkTork who seems to feel that dates should not be linked for autoformatting purposes unless there is a further contextual need to have the date linked. I believe this is inconsistent with the current WP:MOSDATE, as well as with the following part of this style guideline (emphasis mine):

  • Dates when they contain a day, month, and year — ] ] — or day and month — ]should be linked for date preference formatting.

This would seem to be at odds with the "general rule of thumb" stated a little later on in the guideline:

  • Misplaced Pages has articles on days of the year, years, decades, centuries and millennia. As a general rule of thumb, link to one of these pages only if it is likely to deepen readers' understanding of a topic. Piped links to pages that are more focused on a topic are possible (1997), but cannot be used in full dates, where they break the date-linking function.

Just to clarify that this does not supercede the requirement that dates needing autoformatting should be linked, I made this edit, which was promptly reverted by SilkTork, who told me to take it to the talk page, since it "alters the meaning". I do not believe that this does alter the meaning of the guideline, and the fact that SilkTork is having difficulties understanding the rules concerning autoformatting clearly underscores the need to be a little firmer about this point. Is there any support here for my proposed edit? siℓℓy rabbit (talk) 15:32, 24 June 2008 (UTC)

It seems frustrating that linking and autoformatting are technically inseparable - it would be better if we could autoformat without linking, somehow. Regardless of standing policy, I personally find it objectionable to link an entirely irrelevant article just to improve the presentation of the current article. Dcoetzee 17:11, 24 June 2008 (UTC)

The ideal solution would of course be to have a technical solution in the MediaWiki software allowing for the formatting of dates without linking them. This feature request promises to be fulfilled sometime in the indefinite future. However, the present guideline seems to suggest that, in the meantime, dates must be linked if they are to be autoformatted. Somehow the meaning of the present guideline has been taken, by well-intentioned editors, to mean that autoformatted dates should be unlinked unless they are relevant to the context. This is not, and never has been, the case. siℓℓy rabbit (talk) 18:28, 24 June 2008 (UTC)

Discussion moved from wp:context: end

I have taken the liberty of bringing this discussion here. I hope nobody objects but the issue is relevant to both places and this is a more active forum. Lightmouse (talk) 16:59, 29 June 2008 (UTC)

* If User:SilkTork is making a tool that will allow a date to be input into a template that looks to user preferences to see whether they want the date displayed as “October 16, 1799” or “16 October 1799”, and doesn’t link to a list of trivia, let me know when it’s available. Greg L (talk) 18:46, 29 June 2008 (UTC)

  • I now see that all he is doing is manually removing link dates—not creating a template tool. My mistake. See Lightbot and Lightmouse - issue with years, above, where this whole issue is being discussed. As to Silly rabbit’s statement above: “The ideal solution would of course be to have a technical solution in the MediaWiki software allowing for the formatting of dates without linking them”, I agree, that would indeed be ideal IMO. However, if you read the link above, you will find that there are editors who feel as you do (in the absence of such a tool, they should be linked). I fall into the same camp as SilkTork: loose the links until the tool becomes available. Greg L (talk) 22:40, 29 June 2008 (UTC)
  • First thing: neither of those texts quoted above is actually in MOSNUM. Must be from very old versions. MOSNUM makes it quite clear ("can be autoformatted") that this regrettable practice is optional only. Second: the push to have the techs at WikiMedia decouple the linking and autoformatting mechanisms has a two-year history, and has been met with a less-than-enthusiastic attitude, even in the face of a huge petition of WPians. Don't hold your breath. What's the big deal about having two date formats, provided consistentn with an article? We do this for spelling, yes? TONY (talk) 00:56, 30 June 2008 (UTC)
  • Clarification: The above texts were quoted from WP:CONTEXT before this thread was moved here. Second of all, I still feel that my concern is not addressed (you reverted my change to the WP:CONTEXT guideline). One reading of the current guideline is that autoformatting should not be done unless the date being autoformatted is relevant to the context. If this is a correct reading of that guideline, then it should be made explicit, and we shouldn't edit-war over interpretations. siℓℓy rabbit (talk) 03:11, 30 June 2008 (UTC)
  • I thought it was linking that should be done only where useful and relevant. The fact that linking and autoformatting are scrambled together is very unfortunate, and we have to live with it. But the guidelines are different for each. TONY (talk) 03:35, 30 June 2008 (UTC)
  • My feeling is also that WP:CONTEXT really doesn't have anything to say on whether or not a date should be autoformatted. I think that this should be made clearer at WP:CONTEXT. siℓℓy rabbit (talk) 12:40, 30 June 2008 (UTC)

I think I understand the point that silly rabbit is making. Many users are confused. Autoformatting has been the emporer's new clothes that few dare question, so there is still the popular misconception that 'dates must be linked'. That confusion is partly because the software engineering contains a conceptual error. However, I think we could improve the guidance that exists on several pages. I submit that simple explanations involve simple tests that can be applied by naive editors on a remote talk page i.e. a set of bullets say that solitary years should not generally be linked, days of the week should not generally be linked, month+year combinations should not generally be linked etc. Lightmouse (talk) 19:03, 30 June 2008 (UTC)

  • I’m behind any proposal that addresses the excesses of linking I’ve seen. If the reader is researching a historical article on say, the French Revolution, it makes sense to provide the reader with a link to the “1790s”. But general-interest articles that happen to mention a date or year shouldn’t be cluttered with links to random trivia. Greg L (talk) 22:42, 30 June 2008 (UTC)
Well, maybe it makes sense, if the 1790s article is in reasonable shape and contains enough non-trivial information that is vaguely relevant to the field of the topic. But this idea of just scattergunning the chronology with links must be resisted in favour of disciplined selection for our readers' sakes (just as we select the best and most appropriate sources for them).
Here are two reasons for wanting all chronological items to be linked.
  • The first I've heard explicitly advanced: "I like to go off and browse these things—the Wiki tree is fascinating" (to be resisted as a red-herring: these people are quite capable of keying three- or four-character years or decades into the search box if that's their frisson).
  • The second is not talked about, and is the result of my assumption—that those who have invested their time and energy in constructing chronological pages get a kick out of coming up tops in the linked-to list, and feel that their work might be viewed by a lot more people because of the culture of linking these items (also to be resisted: these desires should not be at the expense of readability, appearance and focus on high-value links).
Now, I haven't heard anything from Francis Schonken or anyone else as to whether and why they're attached to the linking of these items. Reasons, please? TONY (talk) 00:43, 1 July 2008 (UTC)
Do we link years too often? Of course.
But if they are significant dates for the article, the year serves as well as a wikilink for contest as Poland or World War I, neither of which takes long to type. (Tony's argument proves too much; if it were valid we only need wikilinks at explicit cross-references, because we can always cut and paste other terms.)
The second assumption may well be true, but seems likely to be an extreme minority sntiment; rather, years are linked because editors have seen them linked.
It might help to state explicitly that years need not be linked; expecting editors to apply the full force of the distinction between can and should at one glance through MOS is probably unrealistic. Septentrionalis PMAnderson 14:06, 1 July 2008 (UTC)
  • I conducted a non-scientific straw poll of my real-life friends who, while not editors, are regular readers, and found a general feeling that the linking of dates had zero utility. Therefore, I would say that WP:CONTEXT and WP:MOSDATE should be explicitly changed to discourage the linking of dates. I believe that auto-formatting is not a good reason to link them at all, for the simple reason that the vast majority of Misplaced Pages readers don't bother creating an account, and therefore don't get any benefit from the auto-formatting.--Aervanath lives in the Orphanage 14:19, 1 July 2008 (UTC)
    • Well, if the groundswell of support continues, I can see this happening. I've just cleaned out a whole featured nomination that was a sea of blue. Awaiting the response of the nominator. Looks so much better. Compare previous blue clutter HERE with THIS. Scroll down each, preferably side by side. TONY (talk) 17:58, 1 July 2008 (UTC)
      • Nice to have no pointless blue links but really miss the dates in my preferred date format. A win/lose situation. See this bug report for interesting reading. One thing to think of is that without a working date preference system, lame edit wars will (again) start about whether it should be 1 July or July 1. Garion96 (talk) 21:58, 1 July 2008 (UTC)
      • Thanks for your comment, Garion. But you miss your home spelling too? "Colour/or", "ise/ize" and the countless slight variations we all accept? I think date formats are a much smaller issue (my own daily newspaper uses US date format against the prevailing norm in my country: never heard it raised as an issue). That bugzilla link you provided; um ... yeah, we're all very familiar with that. Fruitless, and fixing auto-dud in terms of decoupling it from the linking system won't at all solve the full panoply of dysfunctions. See the date after my sig → TONY (talk) 05:55, 2 July 2008 (UTC)
      • I am not a native English speaker, so color vs colour doesn't really bother me (although I prefer colour). The difference in dates is more worldwide, also for non-native English speakers. It wouldn't solve everything, but I would be happy with a way for auto date formatting without the wiki links. One never knows, I almost gave up hope on global accounts ever working working so.... Garion96 (talk) 11:35, 4 July 2008 (UTC)

AD before or after the year is not a style choice

Using BC/AD or BCE/CE (with or without the dots) in writing historical dates is a matter of choice. However, using either system incorrectly shouldn't be. The problem in the MoS is that it states writing AD after the year is acceptable (it is not). Every style manual I've consulted (e.g. MLA, APA, Chicago,...) agrees that AD should be placed before the year. When writers use AD after the year it is usually because s/he is unaware of the convention. I hope this change appears in the Manual of Style, to educate people who care about writing correctly and to improve the quality of the Misplaced Pages. Omnihistor (talk) —Preceding comment was added at 07:43, 30 June 2008 (UTC)

Style guidelines should not be followed contrary to the usage of careful writers (the present politically correct term for literacy); although one does wonder why, if this isn't a stylistic choice, Omnihistor is consulting style guides. Both choices are frequent, both are commonplace, and a rule on this matter does not contribute to clarity, accuracy, neutrality or attribution. Septentrionalis PMAnderson 20:00, 30 June 2008 (UTC)
I agree with PMAnderson. Style guides' notion of "correctness" notwithstanding, both usages are frequently employed, and both are clearly understood by the reader. As long as the use is consistent within each article, both should be allowed.--Aervanath lives in the Orphanage 14:33, 1 July 2008 (UTC)

Conflict between this guideline and cite templates

The documentation for Template:Cite book (and I imagine most of the other cite tempates) conflictes with the recommendation in WP:MOSNUM#Full date formatting. This guideline states:

The same format should be used in the main text, footnotes and references of each article, except for:
  • dates within quotations and titles, where the original format is retained;
  • explicit comparisons of date formatting.

The Cite book tempate, on the other hand, specifies that dates be given in ISO format (e.g. 1776-07-04). There is no parameter to inform the Cite template what format is being used in an article, so there is no possibility that the template could reformat the supplied date to the correct format for the article. --Gerry Ashton (talk) 18:39, 1 July 2008 (UTC)

Agree with above, there is an inconsistency, but example of 1776-07-04 is a bad one as ISO dates are only valid for dates later than 1970-01-01. Earlier dates have to be put in a different format. Rjwilmsi 19:05, 1 July 2008 (UTC)
If Rjwilmsi's statement about ISO dates only being valid since 1970-01-01 is true, the only reasonable response would be to ban them from Misplaced Pages. --Gerry Ashton (talk) 19:26, 1 July 2008 (UTC)
My source was Template:Cite news but at ISO 8601 this isn't mentioned, so banning ISO dates is not the approach to take! ;) A quick test of a cite news reference with an 'accessdate=' in 1945 displayed fine, yet a 'date=' in 1936 didn't. It seems the constraint is just with the template markup of wikilinked/non-wikilinked ISO dates, certainly not a wider issue. Rjwilmsi 19:54, 1 July 2008 (UTC)
  • I'm glad that Gerry Ashton has identified this issue. In addition, is there an option to turn off the autoformatting of dates in the template? TONY (talk) 04:35, 3 July 2008 (UTC)

This issue also applies to Template:Cite web. It links to solitary months. See the reference section of: Atlanta Falcons seasons. Many templates are responsible for overlinking of dates and common units of measurement. Lightmouse (talk) 15:54, 3 July 2008 (UTC)

Nominator gives thumbs-up to flushing autoformatting down the pan

Yesterday, I attempted to solve a massive overlinking issue with List_of_Final_Fantasy_compilation_albums, a new nomination at WP:FLC, by removing all of the autoformatting. No one minds US date formatting, even if it requires a comma, just as they accept Euro formatting after their signature.

I was delighted that nominator PresN responded at the FLC page: "Well, can't say I'm sad to see the sea of blue leave. It's much easier to read now, thank you."

You may wish to compare the previous autoformatted version with the new, normal script version. Scrolling down side by side is best, but the difference is clear by comparing one after the other, too. TONY (talk) 04:16, 2 July 2008 (UTC)

As I stated above, I am totally in favor of getting rid of auto-formatting. Glad to see you made a start!--Aervanath lives in the Orphanage 05:37, 2 July 2008 (UTC)
I'm all for autoformatting, it's just the blue baggage that comes with it that's the problem. JIMp talk·cont 07:06, 3 July 2008 (UTC) ... Who knows, if this catastrophe in blue is rejected WP-wide, the developers just might even take notice. JIMp talk·cont 07:10, 3 July 2008 (UTC)
  • I’m all for autoformatting (not linking), but don’t see the need to bother if it’s only effective for registered editors. In fact, for all unregistered users (which is the vast majority of readers coming to Misplaced Pages), one of the autoformatting codes results in a date that is particularly unfamiliar to many readers: 2005-05-15 and doesn’t spell out the month (ugly). So I think the practice of autoformatting dates should be discouraged. I’m not sure what the proponents of autoformatting had in mind when they cooked up a feature that only works for registered editors; had they lost track of what Misplaced Pages’s mission is?

    If we’re going to have an autoformatting (with no linking to trivia) function for dates, it should be an I.P.-sensitive one that simply looks to the country the reader hails from. This is a common tool on the Internet and is routinely used to gather statistics of any given Web site’s visitors. The MOSNUM guideline would then say that for articles about a particular country, the dates would be in fixed text in the format typically used in that country. But for articles of a general nature, the dates could use an I.P.-sensitive autoformatting template. But, actually, I’m convinced most readers don’t give a darn about the formatting of dates. I’ve long used the Euro format (and I’m an American) in my general-interest articles (those not tied to a particular country), and haven’t had a single reader ever edit a date to Americanize it.

    Frankly, if there was going to be an I.P.-sensitive function created that could be used in magic words and templates, I’d just as soon see it used so {{dialect|color|colour}} would be read as “color” in the U.S., and as “colour” in England/Australia/etc. It wouldn’t have to be “smart” at all. Simply by looking to the readers’ I.P. address, {{dialect|trunk|boot}} would be read as “the border patrol agents discovered the bomb upon opening the trunk” for Americans, and as “the border patrol agents discovered the bomb upon opening the boot” for others. Now that, would be something I’d really like. Greg L (talk) 13:54, 3 July 2008 (UTC)

Looks like it is time to start a pointy edit war. I don't mean it personally but someone will. This was the entire reason autoformating was started - because we could not agree on dates and got tired of all the edit warring. Please get the developers to change the software again if blue bothers you that much (it doesn't bother me) but stop encouraging edit wars. We have enough already. Rmhermen (talk) 14:04, 3 July 2008 (UTC)
  • Well, I’m certainly not encouraging an edit war; it was my honest perception—based off of long-term observations—that no one really cares about date formatting. Based off of your response, it seems that perception clearly doesn’t apply to 100% of everyone out there. So I trust your “Looks like it is time to start a pointy edit war” statement was facetious, yes? And by “get the developers to change the software again if blue bothers you that much”, I presume you mean they should do so if a way can be found to make it work for non-registered (I.P.) readers. Why bother otherwise? So it makes only registered editors (who’ve taken the time to set their users’ preference on that issue) happy? I would hope we’re all here making contributions for reasons other than that. Greg L (talk) 14:13, 3 July 2008 (UTC)
  • So, Rmhermen, WP has evolved to accept two major varieties of spelling; there have been edit wars, but the gradual improvement in MOS's ENGVAR rules, and the growing maturity of the project, have put paid to almost all of those. Nowadays, an edit war over variety is rare and typically sparked by newbies. No one else would care. The consistent-within-article principle is the magic ingredient. It's only recently that we've had formal rules for date formatting (that is, the raw formatting, nothing to do with auto-lemon). They're here in MOSNUM. Why is it that you're ready to ramp up a war over whether day or month comes first? You accept, don't you, the Euro-style after every signature, don't you? Or perhaps you hadn't noticed it ... 14:46, 3 July 2008 (UTC)This comment posted by Tony1


copied (in bits & pieces) from Template talk:Cite web
  • I agree with Aervanath: ‘flush autoformatting down the pan’. If the vast majority of users (non-registered, plain-folk readers) see “January 1, 2008”, then we might as well simply type January 1, 2008 and shouldn’t be pretending we’re doing any good with {{cite web}} and ] ]. We shouldn’t bother with any tool that only benefits us registered editors. Why?

    Because when registered American editors see “January 1, 2008” and European registered editors see “1 January 2008”, we editors—especially the European ones who are content with the dates they see—are going to loose track that most everyone else in Europe sees American-style dates. I’m American but can imagine that in an article like French Revolution, an English-speaking European reader (there are many) would find “June 10, 1789” just as awkward as would an American seeing “4 July”. Further, new editors who aren’t highly familiar with the idiosyncrasies of these tools will simply copy them from other articles without being aware of their limitations.

    Again: If we’re going to be autoformatting dates, make it work for regular readers or forget it. Otherwise we’re just all patting ourselves on the back by making tools that only we can enjoy, as if we registered editors are privileged Eloi and most every regular reader is just a subterranean Morlock.

    And, of course, loose the damned links to trivia for all but the most topical and relevant circumstances in historical articles. Greg L (talk) 23:26, 4 July 2008 (UTC)

Intuitiveness and year by subject pages

Moved from Misplaced Pages talk:Manual of Style (links): begin
In the section on Intuitiveness it reads: "Years should not be linked to articles, such as 2003 in music or 1985 in film, especially when part of a date." What is meant here? Are these pages not to be linked to or what? __meco (talk) 11:36, 7 March 2008 (UTC)

What is meant is that you should not pipe a link as follows: ]. A user will be confused if he expects to go to an article on the year in general, but arrives at an article on the year in music only. So you should make it explicit where the reader will be taken if he clicks: ]. DiderotWasRight (talk) 14:31, 27 March 2008 (UTC)
How do we know the user would be confused? It isn't like they are being dumped on to some random and unexpected page. This seems perfectly in line with WP:CONTEXT and puts the user in a topic by year article which helps put the events in context. If you are reading about music and click a year link that takes you to other musical events in that year I'd have thought that was more intuitive as well as being more useful.
It is rarely practical to put ("see ]") into an article discussing, say someone's musical career, and I would have thought the link would be useful, putting the single or album they released that year into the context of other musical events, rather than a rather random collection of major events that year. (Emperor (talk) 13:54, 4 July 2008 (UTC))

I'm with Emperor. I think it depends on context, and there can be no hard rule. There will be places where 1990 will more properly contextualize the statement in which it appears, and there will be times where 1990 in comics will, but, as Emperor points out above, there is virtually no reason for a clunker like "1990 in comics" to appear in anyone's prose. I have faith that our readers are not so slow they will be befuddled by the piped link. Ford MF (talk) 14:34, 4 July 2008 (UTC)
Moved from Misplaced Pages talk:Manual of Style (links): end

I have taken the liberty of moving this topic here because of the cross-over with discussions here and this is the more active of the two pages. I hope nobody minds. Lightmouse (talk) 23:06, 4 July 2008 (UTC)

  • My 2¢: If you actually want your link to be clicked on, you should write ], not ]. Many, many users quickly learn not to click on the latter because it looks like they will be taken to a mind-numbing list of random trivia (a problem that is currently under discussion). But if they are reading a music-related article, and have a “2003 in music” link, now that invites exploration. Essentially, you are exploiting the principle of least astonishment and using it to your advantage when you make it clear to the reader that they will be rewarded with more information on the topic they are interested in. Greg L (talk) 06:18, 5 July 2008 (UTC)
    • I'm sorry, I don't understand your argument, which to my ears sounds to be against piped links, period. What you're saying seems to be: yes, readers may want to be linked to a more relevant article, but not if they don't know exactly where they're going beforehand (or somehow haven't figured out that mousing over a bluelink will tell you exactly where you're going in any browser worth 2¢ anyway). Ford MF (talk) 13:53, 5 July 2008 (UTC)
  • No. I’m simply saying that there is no point dressing up an interesting, music-related link as a big bowl of industrial-strength disappointment. Piping is fine. For instance, ] might be clunky for a given context and the following might be preferred by an editor: …and Shania Twain’s '']'' album reached No. 4 on Billboard, which was one of the more notable ]. This code produces the following piped link:

    …and Shania Twain’s Up!  album reached No. 4 on Billboard, which was one of the more notable music milestones of 2003.

And now…
Trivia ↑
The issue at hand is what DiderotWasRight wrote above: “What is meant is that you should not pipe a link as follows: 2003. The reason behind this? One word: disappointment. For years now, Misplaced Pages’s links to dates and years have comprised nothing more than links to trivia. Historically, if a reader clicked on 2006, they were presented with a long list of random trivia, like October 16 - The last MASH was decommissioned.” And if you click on October 16, you’ll learn that Angela Lansbury was born that date in 1925. You can click on “1925”, but unless the reader is particularly slow, they quickly learn that the trivia goes on and on and on. Unless the topic is the M*A*S*H theme song Suicide Is Painless, all the above trivia has nothing whatsoever to do with music. Most experienced Misplaced Pages readers learn to avoid these trivia links because they aren’t relevant to the topic they are interested in at that moment. They anticipate (read: “fear”) a link that reads like this: “Shania Twain’s Up! album reached Billboard’s No. 4 in 2003 will function as I’ve just linked it (try clicking on it). So for many readers, they have learned not to click on such links.

In a nutshell: If you want your links to be clicked on, you don’t want to inadvertently dress them up as something many readers assume/fear is something entirely else.

And no, an editor is not properly addressing the issue of “principle of least astonishment” by assuming that readers will pause their cursor over a link to see the pop-up title of the link. Most readers don’t bother because a properly designed Misplaced Pages page doesn’t require it. Greg L (talk) 19:26, 5 July 2008 (UTC)

Yet another discussion on (de)linking dates...

... this time in relation to stub templates. I think these are clearly meta-data, and they have their own guidelines (at WP:STUB), so I'm highly dubious that article-content style considerations apply, certainly that they would apply unchanged. Please comment here. Alai (talk) 13:24, 5 July 2008 (UTC)

Should MOSNUM continue to deprecate IEC prefixes?

On 7 June 2008 a substantial change was made to WP:MOSNUM, including a virtual ban on the use of IEC units of computer storage such as the mebibyte. At that time, the views of editors arguing against the ban were not taken into account, despite an 11-0 majority against such deprecation only 2 months before that. As far as I know, no attempt was made to seek the views of those 11 editors, even though only 4 of them were involved in the discussions prior to the change in June. Nearly a month has passed since then and it may be time to reconsider whether it is wise for MOSNUM to include a statement for which there is little or no consensus.

It is misrepresentation to write "At that time, the views of editors arguing against the ban were not taken into account" because the fact is every attempt was made by many editors to get substantive reasons from the opposing point of view but no substantive reasons were given. Direct questions were written and good answers were never received, or when something was written in reply those answers did not contain good reasons . The vote cited above does not make consensus, good arguments make consensus. Fnagaton 20:29, 5 July 2008 (UTC)
Indeed it's a gross misrepresentation. I've tried well over ten times if not twenty to get any opposition to justify their position and in two month didn't give a single reason. I've worked very hard with every side to maximize consensus for over two months, even with those who insulted me. Only in the very last day of the rewrite (or the day before that), only one "reason" has was given, and the reason was that three months before, there was an 11-0 vote against the deprecation. I went over that vote, and no one bother to give a reason for there votes other than "I dont like it". This time the vote was anywhere from 10-3 to 11-0 depending on how you count votes for the deprecation. However, consensus is not based on votes, it's based on the quality of arguments, and the three (at most) oppose vote were not supported by any argument whatsover other than "I don't like it". You know what, I like IEC prefixes. I personally use them. However they are unfamiliar, and unaccepted, and therefore are unfit for Misplaced Pages. Headbomb {ταλκWP Physics: PotW} 23:24, 5 July 2008 (UTC)
  • Agreed. T-bird’s stating in the opening paragraph, above, that “…the views of editors arguing against the ban were not taken into account…” lacks that necessary virtue of “truthiness”. How, T-bird, can you possibly believe that over the course of four damned months of continuous debate, your reasoning wasn’t considered? I believe the actual facts T-bird observed would be best described as “the views of editors arguing against the ban were considered but rejected for not adequately addressing the essential concerns.” That, T-bird, is why the consensus in the final analysis was to send the IEC prefixes packing. You don’t have to agree with that decision; just accept it. When you see the IEC prefixes enjoying a fair deal of real-world usage (by a good proportion of computer manufacturers and general-interest magazines) and it’s clear that the IEC prefixes are recognized and understood by a most readers, let us know and Misplaced Pages can quickly jump on the bandwagon. Until then, give it a rest, will you? Greg L (talk) 00:47, 6 July 2008 (UTC)
And since Headbomb who likes IEC prefixes states they "are unfamiliar, unaccepted and therefore unfit for Misplaced Pages" then the "arguments" (for want of a better word) for using IEC here have obviously been very weak compared to the stronger arguments for their deprecation. Fnagaton 23:30, 5 July 2008 (UTC)

A brief summary of events leading up to the change is discussed here. Details of the long discussion leading to the change can be found here. Two subsequent attempts to discuss this point were made by Omegatron and by Quilbert.

Below I list some arguments for and against deprecation.

The list as added by Thunderbird2 was incredibly one-sided and also in the "arguments against the deprecation of IEC prefixes" contain just statements of fact, which in themselves are not good reasons.Fnagaton 20:35, 5 July 2008 (UTC)

arguments in favour of the deprecation of IEC prefixes

  1. IEC prefixes are rare and unfamiliar to many readers
  2. One of the goals of disambiguation is to help clarify for the reader, this is not accomplished by using umfamiliar IEC prefixes.
  3. The main stream media does not use IEC prefixes, Misplaced Pages reflects that real world use.
  4. The policy WP:UNDUE applies here. IEC Prefixes do not have equal weight or use in the real world, therefore most articles should not use IEC prefixes.
  5. Here’s one T-bird: Scroll up to the top of this page. How many “Binary” archives do you see? I count 14. Over the last three years, no other single issue on MOSNUM has involved so much dispute and bickering. The ill-thought-out push to use the IEC prefixes (kibibyte, mebibyte, etc.) here on Misplaced Pages three years ago put us all alone as the only general-interest on-line publication to use these unfamiliar units of measure. No computer manufacturer uses such terminology when communicating to their customer base; not in their advertisements, brochures, product packaging, and owners manuals. As a consequence, no general-interest computer magazines (PC World and Mac World ) use the IEC prefixes in either their on-line or print publications. No other encyclopedia, like Encyclopedia Britannica and World Book uses them; not in their print versions or their on-line versions. And all these publications have paid, professional editors (probably with advanced journalism degrees too) at the helm making judgements. Why is it that you do not understand their reasoning for doing as they do? Why is it, after endless discussion, you refuse to accept the POINT? Why is it that all this debate, you still think you have a better solution for the world’s readers than all these other paid, professional editors?

    After four straight months of intensive debate, this failed guideline was abandoned and Misplaced Pages was finally brought in line with real-world practices. What’s it been… a month since we finally put an end to it? Nothing has changed since that time except to put Misplaced Pages’s computer articles well on the path to using terminology and language that is familiar to readers. Really, the worse thing about the way Misplaced Pages used to be, was that Misplaced Pages didn’t even have project-wide consistency; only some articles used the IEC prefixes and this meant that the conventional terms like “megabyte” had one specific meaning in one article and an entirely different meaning in still other articles.

    Do you really think you’re going to reverse this and make it so some (or all?) of Misplaced Pages’s articles once again use terminology that everyone here agreed weren’t even recognized by the typical Misplaced Pages reader? That is just so unfathomly unrealistic. Greg L (talk) 20:19, 5 July 2008 (UTC)

  6. (from Binary Archive 0, posted three years ago, on 21:41, 12 July 2005)

    Misplaced Pages is an encyclopedia, not an instrument for special interest groups (like IEC) to try to push the way they would like the world to work. We should reflect in the encyclopedia what the world is like, not what we think it should be. The reality is that kilobyte means 1024 bytes most of the time it's used. Many people who use computers (including much of the IT industry) have never heard of a kibibyte and don't use the term. We shouldn't be social engineering.

  7. (also from Binary Archive 0)

    The standard's not established enough yet. I had never heard of these things before I came to Misplaced Pages.

arguments against the deprecation of IEC prefixes

  1. IEC prefixes are unambiguous, simple to use and simple to understand
    False, since IEC prefixes are virtually unknown they confuse the average reader. They are not simple to use for the average reader because they are little understoof and virtually unknown.
  2. the use of IEC prefixes is supported by national and international standards bodies (IEC, BIPM, IEEE, NIST)
    A statement of fact that is not a good reason.
  3. use of IEC prefixes in scientific publications is increasing: 1999-2001 (17 hits); 2002-2004 (34 hits); 2005-2007 (53 hits)
    A statement of fact that is not a reason. It also ignores that other fact that if you do the same search but with "megabyte gigabyte" you wil3 see that IEC prefixes are used by <0.1% (See this) of the total number of papers from that search. Also the search you did "MiB GiB" finds lots of matches that do not relate to computers or memory, for example what does "Chlamydia and programmed cell death" have to do with your point? Nothing. Or how about "A phase II evaluation of a 3-hour infusion of paclitaxel, cisplatin, and 5-fluorouracil in patients"? Nothing. Or how about "Word Order And Phrase Structure in Gothic..."? Nothing. I could go on for hundreds of examples, suffice to say your search is flawed. You should repeat the test with the search terms "mebibyte gibibyte", I'll save you the bother because you will get 1, 3 and 5 hits for the same year ranges. If you do the same searches with "megabyte gigabyte" you will get 425 ,518 and 436 matches. Easily proving just how little IEC prefixes are used.
  4. the alternative (binary use of SI-like prefixes) is deprecated by the same standards bodies
    A statement of fact that is not a good reason. Misplaced Pages does not reflect what standards bodies might say, especially when the real world does not follow the "standards bodies", Misplaced Pages reflects what the reliable sources we use in articles say. And mostly the sources do not use IEC prefixes.
  5. deprecation (of IEC prefixes) increases the difficulty threshold for disambiguation, reducing the rate at which articles can be disambiguated by expert editors
    No it doesn't. Using unfamiliar IEC prefixes increases the difficulty threshold for disambiguation and reduces the rate at which articles can be disambiguated. It is better for our readers that we disambiguate using more familiar terms such as the number of bytes.
  6. in turn this reduces the total number of articles that can be further improved by less expert editors with footnotes etc (assuming that there is consensus to do so)
    Since the conclusion above is fallacious then this above statement is also fallacious.
  7. deprecation is interpreted by some editors as a justification for changing unambiguous units into ambiguous ones
    And a valid reason since it improves articles by using more familiar terms that are better understood by the majority of readers.
  8. removing IEC prefixes from articles, even when disambiguated with footnotes, destroys a part of the information that was there before, because it requires an expert to work out which footnote corresponds to which use in the article
    It does not "destroy" part of the information. The information is the number of bytes, by using the number of bytes explicitly from the sources there is no confusion and none of this "destruction".

discussion

I have little doubt that both lists are incomplete. Comments are invited, as well as new additions to either one. Thunderbird2 (talk) 18:50, 5 July 2008 (UTC)

I am not so concerned how disambiguation happens, whether or not it's through IEC prefixes, as that it happens. However, the disambiguation should be in the article text, not a footnote. Therefore, "2 MB (2 bytes)" is acceptable, as this provides an unambiguous and exact number. "2 MiB" would also be acceptable, as this is unambiguous, provided that the appropriate binary or decimal values are used in each article. "2 MB" with disambiguation in a footnote would not be acceptable, as this would not provide disambiguation that each reader would see. Seraphimblade 20:03, 5 July 2008 (UTC)
IEC Prefixes are not acceptable in the majority of cases though because 1) Most article sources do not use IEC prefixes and will at some point mention how many bytes, by using exact numbers, so there is that continuity disconnect between the sources and the article, this confuses the readers 2) IEC prefixes do not help the reader to understand as well as using more easily understood and familiar techniques such as "2 MB (2 bytes)".Fnagaton 20:10, 5 July 2008 (UTC)
Using "2 MB (2 bytes)", disambiguation inline in the article text, is preferable to footnotes though. Although sometimes there are space issues, so a footnote is the way to go. A footnote also allows more explanation in some situations. Fnagaton 20:39, 5 July 2008 (UTC)
The key thing here is that I don't see anything new, that comes even close to a good reason, from Thunderbird2's post at all. Everything he has just posted has already been dealt with by the long talk archive that lead to the current guideline text. Fnagaton 21:18, 5 July 2008 (UTC)
So the conclusion is, of course, that yes the guideline should continue to deprecate the IEC prefixes because no good substantive reasons have been provided to oppose the deprecation and because there exist many good arguments for having the deprecation (as shown by the talk archive).Fnagaton 21:45, 5 July 2008 (UTC)
I don't have any issue with using exact numbers, as discussed above, rather than IEC prefixes, so long as they're in the article text. My only concern is that values be, one way or the other, unambiguous. I have no objection to using an exact parenthetical value of bytes after the "xB" designation. Seraphimblade 21:54, 5 July 2008 (UTC)

Certain proponents of the ban are acting like trolls and making a battleground for a war of attrition. Maybe it would be better not to justify their behavior, and resolve to not debate. The whole matter is subjective, the evidence is made up and prone to change, and the notion that something "should" be done is bullshit. This discussion is not necessarily working toward a logical conclusion. Furthermore, parties represented by single-use accounts are clearly not interested in the betterment of Misplaced Pages, but are simply average internet trolls. Considering the opposition argument to the ban is comparable to the backing, and clearly underhanded methods have been employed, why not just seek wp:arbitration to end the "debate" once and for all. Then, this terminology can be decided as all other, by free Wikipedians. Potatoswatter (talk) 23:05, 5 July 2008 (UTC)

The rude misrepresentation above is a good example of poor behaviour and a good example of a lack of substantive argument. Arbitration has already been suggested many times in the past, just read the talk page archive already linked. Fnagaton 23:18, 5 July 2008 (UTC)
  • Well… just pardon me all over the place if I don’t put any credence whatsoever into Potatoswatter’s implication that he has somehow cornered the market and “Truth, Justice, and the Misplaced Pages Way™. Pure rubish. Greg L (talk) 02:55, 6 July 2008 (UTC)

I'm not going to waste my time responding in detail to the incredibly biased statement of arguments above; they do not even attempt to fairly state the positions. I have been more or less following this issue for about a year now, and was not aware of the proposed rewrite of the MOSNUM nor of the "vote". Had I been aware, of the discussion, I would have opposed deprecating. I notice a number of folks opposed to the deprecation of IEC are also missing from this so-called consensus - a coincidence or manipulation? Looks like the latter to me! FWIW, IMO, 2 is in many ways worse than IEC prefixes. Most readers don't have a clue to these exponential disambiguations so any objection to IEC should equally apply to both! Those of us who can deal with exponents can also deal with IEC. IEC has the advantage of compactness and can be wiki linked for disambiguation for those who really care about meaning. I would much rather see:

1GB (1GiB)

which I think is a whole lot better than either:

1GB (2 Bytes) or 1GB (1,???,???,??? Bytes)

To make a point, I didn't bother to calculate the number of bytes in a GiB, I can never remember binary prefix multipliers beyond 1 KiB :-)
I for one would like to see the deprecation of Binary IEC prefixes removed. Tom94022 (talk) 01:40, 6 July 2008 (UTC)

Fellow editors, this interminable debate is getting in the way of our main purpose, which is to create an encyclopedia. I dutifully spent quite some time bringing an article into compliance with the prior version of WP:MOSNUM. After the change, I dutifully changed the article. This wasted time that I could have spent doing useful editing. Please quit bickering amongst yourselves and let us get on with the real job. I note that there is no actual debate about precision: we all agree that it would be best if the article accurately reflect the actual precise number, at least internally. The debate is about waht is displayed to the reader. Each side is attempting to dictate what the reader actually sees. I recommend that we us a template similar to the date template, and let each user select a default view. Each number is actually of the form Nx2 x Mx10. The simplest template would simply use KB/MB/GB or KiB/MiB/GiB (user's choice), and would present the full expansion on mouse-over. Example: {{GiB|3.5}} expands to 3.5 GB or to 3.5 GiB, depending on user preferenced. It is the height of arrogance to dictate your prejudice to the reader. Please quit this silliness and get back to work. -Arch dude (talk) 02:20, 6 July 2008 (UTC)
  • User preference settings for a which-view template wouldn’t be good because it would only work for registered editors. The vast majority of readers (non-registered I.P. users) would just see GB. So why bother? To me, this is military-grade sillyness. You don’t see computer magazines bothering to explain what “2 GB of RAM” means, nor does Encyclopedia Britannica bother; it’s clear enough. The whole push to “disambiguate” these common expressions is just residue left over from arguments advanced by the pro-IEC prefix crowd trying to make their point about the “ambiguity” of the SI prefixes. We’re trying to fix a “problem” that exists only in our minds. A simple, one-time-only link to GB is sufficient. And I agree with you: it’s time to move on to other things. The only way I know of to enforce that is to ignore the pro-IEC prefix crowd next time they come here to complain about the last consensus vote. Greg L (talk) 02:47, 6 July 2008 (UTC)
  • GregL, it is not permissible to "ignore" anyone, and your suggestion to do so is not civil. MOS is pretty clear that disambiguation is required. I would also disagree that MB is "clear enough", as if you asked the average reader of such an article how much memory is in a "megabyte", they would interpret "mega" according to its standard meaning of one million. Given that computer measurements vary from this centuries-old standard, I think some form of disambiguation is demanded. How it is done is not all that important to me (I would personally prefer IEC prefixes and did not support their deprecation), but so long as we disambiguate it in some way or another, I'm alright with it. However, failing to disambiguate is a wholly unacceptable option. I think it also telling that the implementation of this decision is bringing others along who also disagree with it, this should be a clear warning sign that perhaps it does not have a community-wide consensus after all. The solution to that is not to ignore, it is to discuss further. Seraphimblade 03:04, 6 July 2008 (UTC)
  • What the blue blazes are you talking about? Who do you think you are, the thought police? Anyone can ignore anyone they want—anytime; get that much straight in your head. You are totally wasting your time if you presume to tell me that I—or anyone else—have to respond to someone here. “Ignoring someone isn’t civil”: what load of half-cooked tripe. As for the rest of your arguments that Misplaced Pages needs to disambiguate “2 megabytes of RAM” when no one else on this damned planet bothers to, well… I’m ignoring you. Watch:

    (*sound of crickets chirping*)

    Greg L (talk) 04:22, 6 July 2008 (UTC)

Date links are required to populate 'What links here' for year pages

Moved from Lightmouse talk page.
File:R2D2 Replica.jpg
Working tirelessly to make your life better. And they’re “Three-rule safe™

Please tell your bot to stop doing this. De-linking years screws up "what links here" for our year pages, breaking an important, handy, research tool for our readers. -- Kendrick7 16:02, 5 July 2008 (UTC)

I totally agree with you. The bot needs to shutdown. --SkyWalker (talk) 16:35, 5 July 2008 (UTC)
I agree too. Hervegirod (talk) 22:27, 5 July 2008 (UTC)
  • The process of tweaking Lightmouse’s bot to make it better will no doubt be a never-ending one. In the mean time, it is performing an important service that improves Misplaced Pages. Greg L (talk) 01:24, 6 July 2008 (UTC)
Misplaced Pages talk:Manual of Style/Dates and numbers: Difference between revisions Add topic