![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 100 | ← | Archive 102 | Archive 103 | Archive 104 | Archive 105 | Archive 106 | → | Archive 110 |
Should the endash in date ranges be spaced or unspaced? It says unspaced in the "Dates" section of the MoS but both occur in the "Dates of Birth and Death" section (including the Darwin example which is the basically the example everybody actually looks at to see what the standard is!). Also is there a preference for the "–" character vs the control code "–" (–)? It seems to me that the control code is better. The MoS uses both so it seems like there's no policy. I think there should be one. Jason Quinn ( talk) 01:34, 29 May 2008 (UTC)
En dash in ranges is unspaced, so I don't see why it should be different for year ranges. Either – or – are fine (just make sure the – is a – and not a hyphen - or an em dash — or a minus sign −) Headbomb ( ταλκ · κοντριβς) 03:46, 29 May 2008 (UTC)
This page is now humungously big, and must be hell to navigate for anyone on a dialup connection. Dank55 has kindly added an archiving robot to MOS talk, and I've asked him whether he'll do the same for FLC talk, where they like the idea a lot. Does anyone object to this? At MOS talk, it automatically archives any section that hasn't been touched for 10 days. Is that the right duration for here? TONY (talk) 03:49, 1 June 2008 (UTC)
During May, "(decimal)" was added: "A typical advertisement for a PC in 2008 might specify 2 GB memory (binary) and a 160 GB HDD (decimal)." I'm just checking that it means something; I have no idea. I guess I'll add non-breaking spaces between the units and values. TONY (talk) 03:40, 1 June 2008 (UTC)
What is the reasoning behind the policy to not make the suffix of ordinal numbers superscript? As far as I can tell, styles like 23rd and 496th are the standard outside of Wikipedia. -- Arctic Gnome ( talk • contribs) 03:31, 2 June 2008 (UTC)
Since the only objection in the past 3¾ days is an WP:ILIKEIT-esque argument and there isn't any objective material to challenge the Columbia, Davidson and MIT style guides linked from the archive, shall I proceed with replacing all the ordinal suffix templates? For what it's worth, I also found the Apple Style Guide, University of Tennessee Editorial Style Guide, and BCIT writing style guide while browsing the first page of Google results for ordinal superscript style guide. CMSD reads "In Inside District News, superscript the ordinal endings", but "Inside District News" is probably not notable because of the sub-10 Google results. CMoS provides evidence of superscripts in ordinals; however, it seems to only apply to "monarchs and such" and Wikipedia does not use ordinal suffixes in sovereign titles ( WP:NCNT#Sovereigns). — LOL ( talk) 22:40, 5 June 2008 (UTC)
A request for comments has been filed concerning the conduct of Greg L ( talk · contribs). You are invited to comment on the discussion at Wikipedia:Requests for comment/Greg L. -- — Omegatron ( talk) 00:28, 6 June 2008 (UTC) — Omegatron ( talk) 00:28, 6 June 2008 (UTC)
Which is preferred, "June of 2008", "June 2008", or either format, when providing a date with only a month and year? -- Silver Edge ( talk) 03:28, 6 June 2008 (UTC)
At the moment, MOS requires words as words to be rendered in italics, not quotes. There's now a clash between this and the (disputed) point here that SI symbols must always be in roman face. This needs to be sorted out. TONY (talk) 04:47, 1 June 2008 (UTC)
In accordance with the rules of CGPM, NIST, National Physical Laboratory (UK), unit symbols are in upright, roman type.
I would propose that MOS and MOSNUM policy be harmonized and also updated with the additional caveat that when an article has reached a level of completeness and polish that it is undergoing little in the way of substantial rewrite or addition, that typographers’ quotes are permissible. This will keep Wikipedia easy to edit when articles are in a state of growth and flux, but will also put Wikipedia on the slow track towards looking more like a professional-grade publication. Greg L ( talk) 18:47, 7 June 2008 (UTC)
Both the
Basic Manual of Style and the
Mathematical Manual of Style recommend that proper superscripts be used for exponents (<sup>2</sup>
, <sup>3</sup>
) instead of mixing in the legacy Unicode characters ² and ³. This is for consistency (see 1²³4 vs. 1234), for accessibility (the Unicode superscripts are impossible to read on some monitors at the default size), and because the Unicode standard recommends they not be used when markup is available.
For consistency, this guide should reiterate what the other guides state, that the two characters ² and ³ should not be used in articles except when necessary (such as in templates or links that require them). — Werson ( talk) 04:44, 5 June 2008 (UTC)
<math>2^{32}</math>
(rendered as ) is the preferred method when dealing with mathematical expressions. --
KelleyCook (
talk)
13:22, 6 June 2008 (UTC)I'm currently archiving the rewrite. Please give me an hour to do so. I will post here again when I'm done. Headbomb ( ταλκ · κοντριβς) 17:56, 7 June 2008 (UTC)
Everything was archived at Wikipedia talk:Manual of Style (dates and numbers)/Archive/Complete rewrite of Units of Measurements (June 2008). I understand that usually only old threads are archived, but there was just so much that can't be separated that I couldn't only archive half of it coherently. I've left the votes here for now so Woodstone can update his vote. I'll update the archive accordingly.
You can head over there to check if your links still work.
Discussion is not closed, if you want to talk about anything from there, just bring back whatever text is relevant as needed. Headbomb ( ταλκ · κοντριβς) 17:56, 7 June 2008 (UTC)
Archive completed. Headbomb ( ταλκ · κοντριβς) 19:31, 7 June 2008 (UTC)
I've put archive tags around it. This was a rather old part of the discussion, wasn't it? Propose to make a fresh start, if someone feels like reactivating that part of the discussion. -- Francis Schonken ( talk) 21:58, 7 June 2008 (UTC)
Sequence of events:
Thunderbird2 ( talk) 07:33, 8 June 2008 (UTC)
If it's archived, then it's archived. No need to have it here too. Headbomb ( ταλκ · κοντριβς) 02:28, 9 June 2008 (UTC)
This is not how consensus is built. Thunderbird2 ( talk) 19:35, 7 June 2008 (UTC)
The section Scientific notation, engineering notation, and uncertainty could be better positioned. This section deals with the representation of numbers. Such notation can occur outside the context of measurements and is certainly something besides units. I propose moving it from Units of measurements. It could stand alone as its own section but what I propose is to move it into Numbers since that's what it deals with. JIMp talk· cont 01:26, 9 June 2008 (UTC)
Headbomb,
You write "Makes sense. Feel free to edit." did you mean to delete it or was that a mistake? I will edit. There is no content change involved just a more logical organisation of content. It had been brought up before but I can't find it in the archives and I'm not really up for picking through diffs.
JIMp talk· cont 03:10, 9 June 2008 (UTC)
found JIMp talk· cont 03:19, 9 June 2008 (UTC)
I'm not quite sure I'm following. I deleted the collapse box containing the content of archive 102, since it's archived. What's that got to do with the moving of the Sci/eng notation section?
Headbomb (
ταλκ ·
κοντριβς)
04:04, 9 June 2008 (UTC)
Should've been nothing, or so you'd guess, but see the diff. JIMp talk· cont 04:06, 9 June 2008 (UTC)
Well, which is right? I prefer to use wikidates, but for date ranges that means I have to give two full wikidates, because otherwise, as the second reference notes, these will be damaged. Using wikidates is the only way that readers with preferences set will see the date range correctly, regardless of whether they are using International Dating or American Dating format. -- Pete ( talk) 23:15, 2 June 2008 (UTC)
[[2009-01-04]]–[[2009-02-15]]
to 4 January – 15 February 2009, but turn [[2009-01-04]]–[[2009-01-09]]
to 4–9 January 2009. It's pretty basic; I can't believe there's so much inertia to add slightly clever functionality to MediaWiki. —
Werson (
talk)
02:43, 11 June 2008 (UTC)My suggestion is to move the polls alone to the new name, and leave just the discussion in the B9 archive with a link back to it. What do you all think? — Omegatron ( talk) 23:26, 7 June 2008 (UTC)
Start a new one if you want, but that would be pretty pointless considering we just had one, and that polls mean diddly squat on their own. See WP:DEMO. Headbomb ( ταλκ · κοντριβς)
Please respect the fact that many editors labored here in good faith to debate the proposed contents and develop a consensus on the current MOSNUM wording. You apparently had no interest in the goings on here, or boycotted the proceedings. But for whatever reason, you chose not to participate. The majority of editors who labored on the latest wording have zero interest whatsoever in your trying to resurrect the IEC prefix issue for further discussion. Please respect the consensus. Do all protons in the universe have to decay before you let this rest? If you dispute that there was a consensus in the latest decision, please take your complaint somewhere else. Greg L ( talk) 04:52, 8 June 2008 (UTC)
Because of the clear deprecation that was considered so important by some, the new guideline is being interpreted as preferring ambiguous units to unambiguous ones. User:Warren may or may not be the first editor to interpret the guideline in this way, but I am certain he will not be the last. The solution is simple: Remove the deprecation of IEC units. Thunderbird2 ( talk) 14:56, 8 June 2008 (UTC)
unindented
unindented
Editors should use the conventional prefixes, such as kilobyte (KB) and megabyte (MB), and disambiguate where necessary.
The IEC prefixes are not to be used on Wikipedia except under the following circumstances:
• when the article is on a topic where the majority of cited sources use the IEC prefixes,
• when directly quoting a source that uses the IEC prefixes,
• in articles specifically about or explicitly discussing the IEC prefixes.
The consensus was that for the byte and bit prefixes, the spirit of the MoS is better reflected by having familiar but ambiguous units, rather than unambiguous but unfamiliar units.
WP:DEADHORSE
--
Francis Schonken (
talk)
08:03, 8 June 2008 (UTC)
I should also add that Power Macintosh 5500 should have had the first instances of each use of “KB” and “MB” spelled out. Some of us here are assuming that the typical reader is more knowledgeable about computer terminology that should be presumed. Note that Encyclopedia Britannica spells out every instance and doesn’t use the unit symbols. Of course, that’s where the number of instances of “megabyte” in the article is limited. I’m going to revise the article to show what I mean. Greg L ( talk) 20:31, 8 June 2008 (UTC)
If you look at Billion it can be 10^9 or 10^12, but I was not trying to make that point. (It might even be 1,024 * 1,024 * 1,024 or even 1000 * 1,048,576 - but that would be flogging a dead horse :)) Pyrotec ( talk) 21:52, 8 June 2008 (UTC)
A 100 GB (100,000,000,000 bytes) hard drive
Should this be written as
A 100 GB (100,000,000,000-byte) hard drive
to match the style of hyphenating adjectival units that aren't abbreviated? — Werson ( talk) 02:32, 11 June 2008 (UTC)
Lots of specs and you should be using symbolic/abbreviated forms, thus you'll not need the hyphen; you certainly won't be spelling it out long hand (as in the example above) each time ... generally not more than once. As for the specific example, I'd be more inclined to write "A 100-gigabyte (100,000,000,000 B) hard drive" or, more inclined still, "A 100-gigabyte (100×109 B) hard drive" (using engineering notation).
JIMp
talk·
cont
07:57, 11 June 2008 (UTC)
Whoever that person is, it's getting pretty damn annoying to revert his/her edits on a bunch of articles. You guys are more familiar with this, so you probably know what history is associated with this.
Let's build User talk:Headbomb/Request for the 217.237.xxx.xxx I.P.s to be blocked. Headbomb ( ταλκ · κοντριβς) 13:47, 11 June 2008 (UTC)
Page has been updated to cover most of that IP'S activity. Please add whatever info you feel is useful, such as past verdicts, details about IP 217.87.xxx.xxx activities, as well as Sarenne etc... Headbomb ( ταλκ · κοντριβς) 19:02, 11 June 2008 (UTC)
All: How are editors going to be able to make MOSNUM-compliant edits if other editors flout MOSNUM policy and revert the edits in a fashion that flies totally in the face of what MOSNUM calls for?
Note this paragraph of our “Itanium” article. Note also its #27 footnote. This is the result of a single edit session I made a few days ago ( ∆ here). Then Thunderbird2 simply reverted the article ( here is the ∆ between the article before my work and after he reverted it; it was a straight reversion). He is even keeping a log ( User:Thunderbird2/my sandbox) of the articles other editors try to bring into compliance with MOSNUM that he reverts so he doesn’t seem at all shy about this whatsoever. The end effect of his edits are to simply denote computer memory using the MOSNUM-banned (and highly unfamiliar) units of measure like MiB and KiB.
Note also that I did my math when I disambiguated the article. Where it says, “The bus transfers 2x128 bits per clock cycle, so the 200 MHz McKinley bus transferred 6.4 GB/s…”, I had confirmed that at 200 MHz, the value of “6.4 GB/s” was precisely 6.4 × 230 bytes per second, and thus, footnote #27 correctly described the value of “GB” for that transfer rate too.
I just do not have any idea how to resolve this. An enormous amount of discussion has occurred here on Talk:MOSNUM and Thunderbird2 seems determined to just ignore the consensus and edit-war here. Any suggestions? What is the most expedient way to get an editor to follow the rules without going through a tedious, formal RfC or something? Greg L ( talk) 03:10, 14 June 2008 (UTC)
Hi to all – I have created this experimental sub-page as an effort towards finding a consensus. Hope it works. Cheers -- Quilbert ( talk) 11:18, 11 June 2008 (UTC)
There is wide consensus on not using the IEC prefixes. The consensus is not only on the MOSNUM talk page but in the entire publishing and computer industry. We have just spent 3 month finding an acceptable binary prefix guideline. It pass 10 (11) to 2(3). It is not just ten people, we are going to follow what the rest of the world is doing. The only problem is the Thunderbird2 will not accept the decision. We don't need an ongoing debate on a secret sub-page. -- SWTPC6800 ( talk) 15:15, 11 June 2008 (UTC)
Alright, I see, all are sick about this. So let’s leave it as it is. I just had the impression that there is still much hostility in the air. Anyone who is interested in “substantiated arguments” for IEC prefixes can read User:Quilbert/IEC. Just for your interest, as I’m hereby retracting my commitment, as it seems unsolicited. Peace is most important. See you -- Quilbert ( talk) 15:41, 11 June 2008 (UTC)
I'm very relieved to hear that. Thank you for being reasonable and not dragging this into another multi-month debate. Headbomb ( ταλκ · κοντριβς) 15:47, 11 June 2008 (UTC)
Dito. Greg L ( talk) 16:00, 11 June 2008 (UTC)
The United States Department of Commerce has the authority to interpret the International System of Units for the USA. On May 9, 2008, the Federal Register carried a notice that "announces the publication of the latest interpretation of the SI for the United States in the 2008 Edition of NIST Special Publication 330 "The International System of Units." That publication, in turn, states on page 29, "These SI prefixes refer strictly to powers of 10. They should not be used to indicate powers of 2 (for example, one kilobit represents 1000 bits and not 1024 bits). The IEC has adopted prefixes for binary powers in the international standard IEC 60027-2: 2005 . . ."
The Federal register notice also states the Special Publication contains not only the authoritative interpretation of SI for the USA, but also "editorial style guidelines". The format of the publication does not make it absolutely clear what is authoritative and what is a guideline. So that leaves it to readers to decide whether using SI prefixes as if they had binary meanings is merely contrary to an official United States guideline, or outright illegal.
Either way, this change illustrates that this section of the Manual of Style may have to be revisited either if the IEC prefixes become more popular, or if they are definitively found to be illegal in a marketplace of significant size. -- Gerry Ashton ( talk) 23:41, 18 June 2008 (UTC)
I’ve replied to Greg_L's note on my talk page, and posted most of you on your respective talk pages. Just in case I’ve left someone out, please see my detailed response here. Thunderbird2 ( talk) 19:00, 15 June 2008 (UTC)
As I stated here before, I am perfectly content with conducting a h-u-g-e, Wikipedia-wide vote, with invitations to editors across all of Wikipedia’s computer and technical-related articles. For too long, MOSNUM policy has been unduly influenced by a small club of the self-appointed elite who camped out here and gamed the system to make Wikipedia conform to their desires. As happened with the IEC prefixes, all it took was one, single editor like Sarenne to spread a cockamamie policy across a hundred articles like napalm (until he was banned for life). Once done, such things are hard to undo.
As happened in our latest vote, the litmus test in deciding the new vote will not be whether there is 100% buy-in from all editors, but whether there is a “general” consensus. And, as I proposed in the preceding link, I will seek to ensure that the discussion and voting is monitored and arbitrated by a panel of three mediators, whose ruling will be final. This particular Wikipedia policy is too important to have settled by simply wearing editors down until some 5-to-3 vote conducted on a remote, backwater page somehow manages to reverse policy. Wikipedia’s technical pages have Ph.D.s with curriculum-writing experience and similar contributing experts; most have no knowledge whatsoever about MOSNUM and Talk:MOSNUM. If this issue comes up for a vote again, there will be a much wider diversity of input than ever before. In my opinion, it’s high time for that; Wikipedia will be much better off for it.
In the mean time, give it a rest will you? Everyone else—even the editors you are now trying to sway—are sick to death of this issue; either that, or they are wise enough to recognize the reality of the situation and don’t have the stomach for the bickering and revenge you seem to seek. Greg L ( talk) 19:46, 16 June 2008 (UTC)
The Manual of Style (dates and numbers) now follows the binary unit style used by the publishing and computer industry. This was not a 10 to 3 vote but the overwhelming consensus of the real world. Greg's "Follow current literature" proposal has been removed from MOSNUM and replaced by one developed under the leadership of Headbomb. The binary prefix debate is over, can we move on? -- SWTPC6800 ( talk) 03:22, 17 June 2008 (UTC)
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)
- Numbers that begin a sentence are spelled out; alternatively, the sentence can be recast so that a figure does not begin the sentence.
- 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.
←Looks good. TONY (talk) 08:04, 28 June 2008 (UTC)
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 [link]".
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)
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)
Anderson, do you really think this is well-constructed?
Wikipedia 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:
Wikipedia 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)
Wikipedia 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
Wikipedia 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
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)
Agreed. Just my opinion; but I remember the first time I saw a linked year on Wikipedia (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)
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)
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)
Just focussing on the issue of guidance... There are various elements of guidance but one is:
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)
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 all-platinum kilogram prototype to the Archives of the Republic in June and on 10 December 1799, the prototype was formally ratified…
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:
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
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)
Tthe United States of America had been pulling away from England for many years and, on July 4, 1776, finally declared its independence.
…For instance, the United States of America declared its independence from England on July 4, 1776…
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).
For instance, the United States of America declared its independence from England on July 4, 1776.
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)
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)
-- Hroðulf (or Hrothulf) ( Talk) 10:40, 23 June 2008 (UTC)
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 Wikipedia. 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 “[on this date in] 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)
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 Wikipedia 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)
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:
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)
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 Wikipedia (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 Wikipedia 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 Wikipedia 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 Wikipedia: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 ( Wikipedia: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)
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)
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.
Wikipedia 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)
The assembly voted to adopt the new measure on 16 October 1799 (other notable events of 1799)
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 Wikipedia pages into one big turd of blue. Hooray for the bot! Greg L ( talk) 17:56, 29 June 2008 (UTC)
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:
[[20 June|20]]
, [[20 June]] [[1997 in South African sport|1997]]
) (several forms of piped links break the date formatting function);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)
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)
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)
Autoformatting and linking
Note that dates can be autoformatted and linked by coding as follows:
[[1925-10-16]]
. 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 Wikipedia) 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, Wikipedia 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.
Responding to the question on my talk page:
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 Wikipedia. Omnihistor ( talk) —Preceding comment was added at 07:43, 30 June 2008 (UTC)
{{ 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)
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)
JIMp talk· cont 05:50, 19 June 2008 (UTC)
In English speaking countries this unit is usually called "metric ton".
{{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
(yak)
03:04, 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)
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 Wikipedia 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)
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:
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)
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:
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 Wikipedia 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)
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)
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)
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)
Depending on context, I'd consider either megastere, gigalitre, or (in a pinch) hm3 to avoid "million cubic metres" LeadSongDog ( talk) 14:48, 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)
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:
Thunderbird2 ( talk) 12:41, 28 June 2008 (UTC)
Where are we at? Fill in the blanks below. I’ll start:
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)
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)
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):
[[25 March]] [[2004]]
— or day and month — [[February 10]]
— 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:
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)
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 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)
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 100 | ← | Archive 102 | Archive 103 | Archive 104 | Archive 105 | Archive 106 | → | Archive 110 |
Should the endash in date ranges be spaced or unspaced? It says unspaced in the "Dates" section of the MoS but both occur in the "Dates of Birth and Death" section (including the Darwin example which is the basically the example everybody actually looks at to see what the standard is!). Also is there a preference for the "–" character vs the control code "–" (–)? It seems to me that the control code is better. The MoS uses both so it seems like there's no policy. I think there should be one. Jason Quinn ( talk) 01:34, 29 May 2008 (UTC)
En dash in ranges is unspaced, so I don't see why it should be different for year ranges. Either – or – are fine (just make sure the – is a – and not a hyphen - or an em dash — or a minus sign −) Headbomb ( ταλκ · κοντριβς) 03:46, 29 May 2008 (UTC)
This page is now humungously big, and must be hell to navigate for anyone on a dialup connection. Dank55 has kindly added an archiving robot to MOS talk, and I've asked him whether he'll do the same for FLC talk, where they like the idea a lot. Does anyone object to this? At MOS talk, it automatically archives any section that hasn't been touched for 10 days. Is that the right duration for here? TONY (talk) 03:49, 1 June 2008 (UTC)
During May, "(decimal)" was added: "A typical advertisement for a PC in 2008 might specify 2 GB memory (binary) and a 160 GB HDD (decimal)." I'm just checking that it means something; I have no idea. I guess I'll add non-breaking spaces between the units and values. TONY (talk) 03:40, 1 June 2008 (UTC)
What is the reasoning behind the policy to not make the suffix of ordinal numbers superscript? As far as I can tell, styles like 23rd and 496th are the standard outside of Wikipedia. -- Arctic Gnome ( talk • contribs) 03:31, 2 June 2008 (UTC)
Since the only objection in the past 3¾ days is an WP:ILIKEIT-esque argument and there isn't any objective material to challenge the Columbia, Davidson and MIT style guides linked from the archive, shall I proceed with replacing all the ordinal suffix templates? For what it's worth, I also found the Apple Style Guide, University of Tennessee Editorial Style Guide, and BCIT writing style guide while browsing the first page of Google results for ordinal superscript style guide. CMSD reads "In Inside District News, superscript the ordinal endings", but "Inside District News" is probably not notable because of the sub-10 Google results. CMoS provides evidence of superscripts in ordinals; however, it seems to only apply to "monarchs and such" and Wikipedia does not use ordinal suffixes in sovereign titles ( WP:NCNT#Sovereigns). — LOL ( talk) 22:40, 5 June 2008 (UTC)
A request for comments has been filed concerning the conduct of Greg L ( talk · contribs). You are invited to comment on the discussion at Wikipedia:Requests for comment/Greg L. -- — Omegatron ( talk) 00:28, 6 June 2008 (UTC) — Omegatron ( talk) 00:28, 6 June 2008 (UTC)
Which is preferred, "June of 2008", "June 2008", or either format, when providing a date with only a month and year? -- Silver Edge ( talk) 03:28, 6 June 2008 (UTC)
At the moment, MOS requires words as words to be rendered in italics, not quotes. There's now a clash between this and the (disputed) point here that SI symbols must always be in roman face. This needs to be sorted out. TONY (talk) 04:47, 1 June 2008 (UTC)
In accordance with the rules of CGPM, NIST, National Physical Laboratory (UK), unit symbols are in upright, roman type.
I would propose that MOS and MOSNUM policy be harmonized and also updated with the additional caveat that when an article has reached a level of completeness and polish that it is undergoing little in the way of substantial rewrite or addition, that typographers’ quotes are permissible. This will keep Wikipedia easy to edit when articles are in a state of growth and flux, but will also put Wikipedia on the slow track towards looking more like a professional-grade publication. Greg L ( talk) 18:47, 7 June 2008 (UTC)
Both the
Basic Manual of Style and the
Mathematical Manual of Style recommend that proper superscripts be used for exponents (<sup>2</sup>
, <sup>3</sup>
) instead of mixing in the legacy Unicode characters ² and ³. This is for consistency (see 1²³4 vs. 1234), for accessibility (the Unicode superscripts are impossible to read on some monitors at the default size), and because the Unicode standard recommends they not be used when markup is available.
For consistency, this guide should reiterate what the other guides state, that the two characters ² and ³ should not be used in articles except when necessary (such as in templates or links that require them). — Werson ( talk) 04:44, 5 June 2008 (UTC)
<math>2^{32}</math>
(rendered as ) is the preferred method when dealing with mathematical expressions. --
KelleyCook (
talk)
13:22, 6 June 2008 (UTC)I'm currently archiving the rewrite. Please give me an hour to do so. I will post here again when I'm done. Headbomb ( ταλκ · κοντριβς) 17:56, 7 June 2008 (UTC)
Everything was archived at Wikipedia talk:Manual of Style (dates and numbers)/Archive/Complete rewrite of Units of Measurements (June 2008). I understand that usually only old threads are archived, but there was just so much that can't be separated that I couldn't only archive half of it coherently. I've left the votes here for now so Woodstone can update his vote. I'll update the archive accordingly.
You can head over there to check if your links still work.
Discussion is not closed, if you want to talk about anything from there, just bring back whatever text is relevant as needed. Headbomb ( ταλκ · κοντριβς) 17:56, 7 June 2008 (UTC)
Archive completed. Headbomb ( ταλκ · κοντριβς) 19:31, 7 June 2008 (UTC)
I've put archive tags around it. This was a rather old part of the discussion, wasn't it? Propose to make a fresh start, if someone feels like reactivating that part of the discussion. -- Francis Schonken ( talk) 21:58, 7 June 2008 (UTC)
Sequence of events:
Thunderbird2 ( talk) 07:33, 8 June 2008 (UTC)
If it's archived, then it's archived. No need to have it here too. Headbomb ( ταλκ · κοντριβς) 02:28, 9 June 2008 (UTC)
This is not how consensus is built. Thunderbird2 ( talk) 19:35, 7 June 2008 (UTC)
The section Scientific notation, engineering notation, and uncertainty could be better positioned. This section deals with the representation of numbers. Such notation can occur outside the context of measurements and is certainly something besides units. I propose moving it from Units of measurements. It could stand alone as its own section but what I propose is to move it into Numbers since that's what it deals with. JIMp talk· cont 01:26, 9 June 2008 (UTC)
Headbomb,
You write "Makes sense. Feel free to edit." did you mean to delete it or was that a mistake? I will edit. There is no content change involved just a more logical organisation of content. It had been brought up before but I can't find it in the archives and I'm not really up for picking through diffs.
JIMp talk· cont 03:10, 9 June 2008 (UTC)
found JIMp talk· cont 03:19, 9 June 2008 (UTC)
I'm not quite sure I'm following. I deleted the collapse box containing the content of archive 102, since it's archived. What's that got to do with the moving of the Sci/eng notation section?
Headbomb (
ταλκ ·
κοντριβς)
04:04, 9 June 2008 (UTC)
Should've been nothing, or so you'd guess, but see the diff. JIMp talk· cont 04:06, 9 June 2008 (UTC)
Well, which is right? I prefer to use wikidates, but for date ranges that means I have to give two full wikidates, because otherwise, as the second reference notes, these will be damaged. Using wikidates is the only way that readers with preferences set will see the date range correctly, regardless of whether they are using International Dating or American Dating format. -- Pete ( talk) 23:15, 2 June 2008 (UTC)
[[2009-01-04]]–[[2009-02-15]]
to 4 January – 15 February 2009, but turn [[2009-01-04]]–[[2009-01-09]]
to 4–9 January 2009. It's pretty basic; I can't believe there's so much inertia to add slightly clever functionality to MediaWiki. —
Werson (
talk)
02:43, 11 June 2008 (UTC)My suggestion is to move the polls alone to the new name, and leave just the discussion in the B9 archive with a link back to it. What do you all think? — Omegatron ( talk) 23:26, 7 June 2008 (UTC)
Start a new one if you want, but that would be pretty pointless considering we just had one, and that polls mean diddly squat on their own. See WP:DEMO. Headbomb ( ταλκ · κοντριβς)
Please respect the fact that many editors labored here in good faith to debate the proposed contents and develop a consensus on the current MOSNUM wording. You apparently had no interest in the goings on here, or boycotted the proceedings. But for whatever reason, you chose not to participate. The majority of editors who labored on the latest wording have zero interest whatsoever in your trying to resurrect the IEC prefix issue for further discussion. Please respect the consensus. Do all protons in the universe have to decay before you let this rest? If you dispute that there was a consensus in the latest decision, please take your complaint somewhere else. Greg L ( talk) 04:52, 8 June 2008 (UTC)
Because of the clear deprecation that was considered so important by some, the new guideline is being interpreted as preferring ambiguous units to unambiguous ones. User:Warren may or may not be the first editor to interpret the guideline in this way, but I am certain he will not be the last. The solution is simple: Remove the deprecation of IEC units. Thunderbird2 ( talk) 14:56, 8 June 2008 (UTC)
unindented
unindented
Editors should use the conventional prefixes, such as kilobyte (KB) and megabyte (MB), and disambiguate where necessary.
The IEC prefixes are not to be used on Wikipedia except under the following circumstances:
• when the article is on a topic where the majority of cited sources use the IEC prefixes,
• when directly quoting a source that uses the IEC prefixes,
• in articles specifically about or explicitly discussing the IEC prefixes.
The consensus was that for the byte and bit prefixes, the spirit of the MoS is better reflected by having familiar but ambiguous units, rather than unambiguous but unfamiliar units.
WP:DEADHORSE
--
Francis Schonken (
talk)
08:03, 8 June 2008 (UTC)
I should also add that Power Macintosh 5500 should have had the first instances of each use of “KB” and “MB” spelled out. Some of us here are assuming that the typical reader is more knowledgeable about computer terminology that should be presumed. Note that Encyclopedia Britannica spells out every instance and doesn’t use the unit symbols. Of course, that’s where the number of instances of “megabyte” in the article is limited. I’m going to revise the article to show what I mean. Greg L ( talk) 20:31, 8 June 2008 (UTC)
If you look at Billion it can be 10^9 or 10^12, but I was not trying to make that point. (It might even be 1,024 * 1,024 * 1,024 or even 1000 * 1,048,576 - but that would be flogging a dead horse :)) Pyrotec ( talk) 21:52, 8 June 2008 (UTC)
A 100 GB (100,000,000,000 bytes) hard drive
Should this be written as
A 100 GB (100,000,000,000-byte) hard drive
to match the style of hyphenating adjectival units that aren't abbreviated? — Werson ( talk) 02:32, 11 June 2008 (UTC)
Lots of specs and you should be using symbolic/abbreviated forms, thus you'll not need the hyphen; you certainly won't be spelling it out long hand (as in the example above) each time ... generally not more than once. As for the specific example, I'd be more inclined to write "A 100-gigabyte (100,000,000,000 B) hard drive" or, more inclined still, "A 100-gigabyte (100×109 B) hard drive" (using engineering notation).
JIMp
talk·
cont
07:57, 11 June 2008 (UTC)
Whoever that person is, it's getting pretty damn annoying to revert his/her edits on a bunch of articles. You guys are more familiar with this, so you probably know what history is associated with this.
Let's build User talk:Headbomb/Request for the 217.237.xxx.xxx I.P.s to be blocked. Headbomb ( ταλκ · κοντριβς) 13:47, 11 June 2008 (UTC)
Page has been updated to cover most of that IP'S activity. Please add whatever info you feel is useful, such as past verdicts, details about IP 217.87.xxx.xxx activities, as well as Sarenne etc... Headbomb ( ταλκ · κοντριβς) 19:02, 11 June 2008 (UTC)
All: How are editors going to be able to make MOSNUM-compliant edits if other editors flout MOSNUM policy and revert the edits in a fashion that flies totally in the face of what MOSNUM calls for?
Note this paragraph of our “Itanium” article. Note also its #27 footnote. This is the result of a single edit session I made a few days ago ( ∆ here). Then Thunderbird2 simply reverted the article ( here is the ∆ between the article before my work and after he reverted it; it was a straight reversion). He is even keeping a log ( User:Thunderbird2/my sandbox) of the articles other editors try to bring into compliance with MOSNUM that he reverts so he doesn’t seem at all shy about this whatsoever. The end effect of his edits are to simply denote computer memory using the MOSNUM-banned (and highly unfamiliar) units of measure like MiB and KiB.
Note also that I did my math when I disambiguated the article. Where it says, “The bus transfers 2x128 bits per clock cycle, so the 200 MHz McKinley bus transferred 6.4 GB/s…”, I had confirmed that at 200 MHz, the value of “6.4 GB/s” was precisely 6.4 × 230 bytes per second, and thus, footnote #27 correctly described the value of “GB” for that transfer rate too.
I just do not have any idea how to resolve this. An enormous amount of discussion has occurred here on Talk:MOSNUM and Thunderbird2 seems determined to just ignore the consensus and edit-war here. Any suggestions? What is the most expedient way to get an editor to follow the rules without going through a tedious, formal RfC or something? Greg L ( talk) 03:10, 14 June 2008 (UTC)
Hi to all – I have created this experimental sub-page as an effort towards finding a consensus. Hope it works. Cheers -- Quilbert ( talk) 11:18, 11 June 2008 (UTC)
There is wide consensus on not using the IEC prefixes. The consensus is not only on the MOSNUM talk page but in the entire publishing and computer industry. We have just spent 3 month finding an acceptable binary prefix guideline. It pass 10 (11) to 2(3). It is not just ten people, we are going to follow what the rest of the world is doing. The only problem is the Thunderbird2 will not accept the decision. We don't need an ongoing debate on a secret sub-page. -- SWTPC6800 ( talk) 15:15, 11 June 2008 (UTC)
Alright, I see, all are sick about this. So let’s leave it as it is. I just had the impression that there is still much hostility in the air. Anyone who is interested in “substantiated arguments” for IEC prefixes can read User:Quilbert/IEC. Just for your interest, as I’m hereby retracting my commitment, as it seems unsolicited. Peace is most important. See you -- Quilbert ( talk) 15:41, 11 June 2008 (UTC)
I'm very relieved to hear that. Thank you for being reasonable and not dragging this into another multi-month debate. Headbomb ( ταλκ · κοντριβς) 15:47, 11 June 2008 (UTC)
Dito. Greg L ( talk) 16:00, 11 June 2008 (UTC)
The United States Department of Commerce has the authority to interpret the International System of Units for the USA. On May 9, 2008, the Federal Register carried a notice that "announces the publication of the latest interpretation of the SI for the United States in the 2008 Edition of NIST Special Publication 330 "The International System of Units." That publication, in turn, states on page 29, "These SI prefixes refer strictly to powers of 10. They should not be used to indicate powers of 2 (for example, one kilobit represents 1000 bits and not 1024 bits). The IEC has adopted prefixes for binary powers in the international standard IEC 60027-2: 2005 . . ."
The Federal register notice also states the Special Publication contains not only the authoritative interpretation of SI for the USA, but also "editorial style guidelines". The format of the publication does not make it absolutely clear what is authoritative and what is a guideline. So that leaves it to readers to decide whether using SI prefixes as if they had binary meanings is merely contrary to an official United States guideline, or outright illegal.
Either way, this change illustrates that this section of the Manual of Style may have to be revisited either if the IEC prefixes become more popular, or if they are definitively found to be illegal in a marketplace of significant size. -- Gerry Ashton ( talk) 23:41, 18 June 2008 (UTC)
I’ve replied to Greg_L's note on my talk page, and posted most of you on your respective talk pages. Just in case I’ve left someone out, please see my detailed response here. Thunderbird2 ( talk) 19:00, 15 June 2008 (UTC)
As I stated here before, I am perfectly content with conducting a h-u-g-e, Wikipedia-wide vote, with invitations to editors across all of Wikipedia’s computer and technical-related articles. For too long, MOSNUM policy has been unduly influenced by a small club of the self-appointed elite who camped out here and gamed the system to make Wikipedia conform to their desires. As happened with the IEC prefixes, all it took was one, single editor like Sarenne to spread a cockamamie policy across a hundred articles like napalm (until he was banned for life). Once done, such things are hard to undo.
As happened in our latest vote, the litmus test in deciding the new vote will not be whether there is 100% buy-in from all editors, but whether there is a “general” consensus. And, as I proposed in the preceding link, I will seek to ensure that the discussion and voting is monitored and arbitrated by a panel of three mediators, whose ruling will be final. This particular Wikipedia policy is too important to have settled by simply wearing editors down until some 5-to-3 vote conducted on a remote, backwater page somehow manages to reverse policy. Wikipedia’s technical pages have Ph.D.s with curriculum-writing experience and similar contributing experts; most have no knowledge whatsoever about MOSNUM and Talk:MOSNUM. If this issue comes up for a vote again, there will be a much wider diversity of input than ever before. In my opinion, it’s high time for that; Wikipedia will be much better off for it.
In the mean time, give it a rest will you? Everyone else—even the editors you are now trying to sway—are sick to death of this issue; either that, or they are wise enough to recognize the reality of the situation and don’t have the stomach for the bickering and revenge you seem to seek. Greg L ( talk) 19:46, 16 June 2008 (UTC)
The Manual of Style (dates and numbers) now follows the binary unit style used by the publishing and computer industry. This was not a 10 to 3 vote but the overwhelming consensus of the real world. Greg's "Follow current literature" proposal has been removed from MOSNUM and replaced by one developed under the leadership of Headbomb. The binary prefix debate is over, can we move on? -- SWTPC6800 ( talk) 03:22, 17 June 2008 (UTC)
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)
- Numbers that begin a sentence are spelled out; alternatively, the sentence can be recast so that a figure does not begin the sentence.
- 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.
←Looks good. TONY (talk) 08:04, 28 June 2008 (UTC)
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 [link]".
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)
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)
Anderson, do you really think this is well-constructed?
Wikipedia 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:
Wikipedia 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)
Wikipedia 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
Wikipedia 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
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)
Agreed. Just my opinion; but I remember the first time I saw a linked year on Wikipedia (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)
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)
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)
Just focussing on the issue of guidance... There are various elements of guidance but one is:
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)
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 all-platinum kilogram prototype to the Archives of the Republic in June and on 10 December 1799, the prototype was formally ratified…
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:
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
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)
Tthe United States of America had been pulling away from England for many years and, on July 4, 1776, finally declared its independence.
…For instance, the United States of America declared its independence from England on July 4, 1776…
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).
For instance, the United States of America declared its independence from England on July 4, 1776.
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)
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)
-- Hroðulf (or Hrothulf) ( Talk) 10:40, 23 June 2008 (UTC)
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 Wikipedia. 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 “[on this date in] 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)
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 Wikipedia 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)
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:
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)
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 Wikipedia (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 Wikipedia 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 Wikipedia 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 Wikipedia: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 ( Wikipedia: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)
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)
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.
Wikipedia 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)
The assembly voted to adopt the new measure on 16 October 1799 (other notable events of 1799)
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 Wikipedia pages into one big turd of blue. Hooray for the bot! Greg L ( talk) 17:56, 29 June 2008 (UTC)
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:
[[20 June|20]]
, [[20 June]] [[1997 in South African sport|1997]]
) (several forms of piped links break the date formatting function);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)
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)
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)
Autoformatting and linking
Note that dates can be autoformatted and linked by coding as follows:
[[1925-10-16]]
. 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 Wikipedia) 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, Wikipedia 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.
Responding to the question on my talk page:
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 Wikipedia. Omnihistor ( talk) —Preceding comment was added at 07:43, 30 June 2008 (UTC)
{{ 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)
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)
JIMp talk· cont 05:50, 19 June 2008 (UTC)
In English speaking countries this unit is usually called "metric ton".
{{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
(yak)
03:04, 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)
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 Wikipedia 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)
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:
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)
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:
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 Wikipedia 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)
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)
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)
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)
Depending on context, I'd consider either megastere, gigalitre, or (in a pinch) hm3 to avoid "million cubic metres" LeadSongDog ( talk) 14:48, 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)
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:
Thunderbird2 ( talk) 12:41, 28 June 2008 (UTC)
Where are we at? Fill in the blanks below. I’ll start:
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)
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)
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):
[[25 March]] [[2004]]
— or day and month — [[February 10]]
— 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:
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)
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 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)