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 103 | Archive 104 | Archive 105 | Archive 106 | Archive 107 | → | Archive 110 |
The documentation for Template:Cite book (and I imagine most of the other cite tempates) conflictes with the recommendation in WP:MOSNUM#Full date formatting. This guideline states:
The Cite book tempate, on the other hand, specifies that dates be given in ISO format (e.g. 1776-07-04). There is no parameter to inform the Cite template what format is being used in an article, so there is no possibility that the template could reformat the supplied date to the correct format for the article. -- Gerry Ashton ( talk) 18:39, 1 July 2008 (UTC)
This issue also applies to Template:Cite web. It links to solitary months. See the reference section of: Atlanta Falcons seasons. Many templates are responsible for overlinking of dates and common units of measurement. Lightmouse ( talk) 15:54, 3 July 2008 (UTC)
... this time in relation to stub templates. I think these are clearly meta-data, and they have their own guidelines (at WP:STUB), so I'm highly dubious that article-content style considerations apply, certainly that they would apply unchanged. Please comment here. Alai ( talk) 13:24, 5 July 2008 (UTC)
Moved from Lightmouse talk page
Stub templates:
Why would you be removing these? Bear in mind they're not article text, they're scoping statements: delinkifying them seems extremely odd.
Alai (
talk)
00:40, 5 July 2008 (UTC)
I'm not arguing from construction, I'm arguing from function. If a template is included into the body of the article, and functions as a part of the article text, then certainly MoS considerations apply. But stub templates are clearly not that, but meta-data for editorial purposes. I'll drop a line at the MoS page to refer people to the discussion I started at WPSS. Alai ( talk) 13:19, 5 July 2008 (UTC)
Infoboxes:
Since it apparent that you're 'bot is operating without human oversight and removing inks where they are acceptable exceptions, please see what you can do to fix the problem.
Example:
The first change is within the infobox for the article. This is a use that is an acceptable exception within the WP:MOSLINK#Dates guideline.
- J Greb ( talk) 14:50, 6 July 2008 (UTC)
Moved from
Wikipedia talk:Manual of Style (links): begin
In the section on
Intuitiveness it reads: "Years should not be linked to articles, such as
2003 in music or
1985 in film, especially when part of a date." What is meant here? Are these pages not to be linked to or what? __
meco (
talk)
11:36, 7 March 2008 (UTC)
I'm with Emperor. I think it depends on context, and there can be no hard rule. There will be places where
1990 will more properly contextualize the statement in which it appears, and there will be times where
1990 in comics will, but, as Emperor points out above, there is virtually no reason for a clunker like "1990 in comics" to appear in anyone's prose. I have faith that our readers are not so slow they will be befuddled by the piped link.
Ford MF (
talk)
14:34, 4 July 2008 (UTC)
Moved from
Wikipedia talk:Manual of Style (links): end
I have taken the liberty of moving this topic here because of the cross-over with discussions here and this is the more active of the two pages. I hope nobody minds. Lightmouse ( talk) 23:06, 4 July 2008 (UTC)
[[2003 in music]]
might be clunky for a given context and the following might be preferred by an editor: …and Shania Twain’s ''[[Up! (album)|Up!]]'' album reached No. 4 on Billboard, which was one of the more notable [[2003 in music|music milestones of 2003]]
. This code produces the following piped link: …and Shania Twain’s Up! album reached No. 4 on Billboard, which was one of the more notable music milestones of 2003.
In a nutshell: If you want your links to be clicked on, you don’t want to inadvertently dress them up as something many readers assume/fear is something entirely else.
And no, an editor is not properly addressing the issue of “principle of least astonishment” by assuming that readers will pause their cursor over a link to see the pop-up title of the link. Most readers don’t bother because a properly designed Wikipedia page doesn’t require it. Greg L ( talk) 19:26, 5 July 2008 (UTC)
…Shania Twain’s album Up! ( 2003) reached No. 4 on Billboard.
The 2008 movie Wanted was based (loosely) on the 6-issue 2003- 2004 comic book miniseries of the same name by Mark Millar and J. G. Jones.
Powers is an American comic book series by Brian Michael Bendis (writer) and Michael Avon Oeming (artist), originally published by Image Comics ( 2000 to 2004).
This diff recently deleted the bit in WP:DATE#Dates of birth and death which said that locations of birth and death shouldn't go in the parenthesis with the dates. Has this been discussed anywhere, or is it (as I suspect) one editor's personal point of view? cheers, Struway2 ( talk) 16:17, 9 July 2008 (UTC)
I started a discussion on numbers as figures and words at WT:MOS#Comparable quantities. Until we decide where the detailed coverage of this issue is going to be, it is predictable that it will be discussed in both places. Septentrionalis PMAnderson 02:35, 8 July 2008 (UTC)
The draft is done; to the best of my ability, I have omitted nothing, and changed no guidance; this may, however, be more memorable. I would add
Septentrionalis PMAnderson 18:54, 10 July 2008 (UTC)
I'm not sure I believe this article, but even if the accusative were the unit, its plural would be annos, not anna; and there should only be one value of it. Septentrionalis PMAnderson 22:09, 10 July 2008 (UTC)
I'm not latin speaker, but my understanding of this [2] suggests to me that annum is a nominative of -um form, meaning that the plural is anna. Headbomb { ταλκ – WP Physics: PotW} 13:20, 11 July 2008 (UTC)
The MOS here states in the date autoformatting section The year should be wikilinked separate from the date except for dates in ISO 8601 format, which is correct as entries like [[April 21, 2005]] don't produce a wikilinked date. However, such a link goes to a valid article ( April 21, 2005), so if I come across a link to [[April 21, 2005]] under the MOS it would seem correct to change it to [[April 21]], [[2005]], but that could be an aricle link. An apparrent inconsistency. Help! Rjwilmsi 08:23, 12 July 2008 (UTC)
Please tell your bot to stop doing this. De-linking years screws up "what links here" for our year pages, breaking an important, handy, research tool for our readers. -- Kendrick7 talk 16:02, 5 July 2008 (UTC)
I agree too. Hervegirod ( talk) 22:27, 5 July 2008 (UTC)
I agree. OMG, these people have let the cat out of the bag! Tony (talk) 03:30, 6 July 2008 (UTC)
I see that as a pretty reasonable proposition, Aervanath. But there are simply so many year links to trivia in so many articles, it seems much easier to let the bot remove them all and simply restore the small percentage that are truly germane to the article. For instance, in Kilogram, I had “On 7 April 1795, the gram was decreed in France to be equal…” and someone linked the date and year. There are simply too few readers who are researching the kilogram who will want to explore the “fascinating” events that occurred on 1795, such as “ January 19 - The Batavian Republic is proclaimed.” Now if there is an article about the War of 1812, the readers going there are naturally interested in historical topics and some year linking (and range linking and decade linking) makes sense. Maybe the bot can be tuned to cut historical articles some slack. If not, it should be easy enough to restore some of them. In the mean time, there must be thousands of articles that need to be de-linked, and that’s simply too gargantuan of a task for anything but a bot. Greg L ( talk) 06:38, 6 July 2008 (UTC)
I think Greg has a valid point here. It makes sense to link years and dates on historical articles. For instance, Lightbot has recently delinked all dates from the intro section to Trajan, but these are important dates, concerning historical turning points in the Roman Empire (wars, assassinations, accessions, etc...). Lightbot seems to behave quite inconsistently too. Some dates are delinked, others are left alone. -- Steerpike ( talk) 11:55, 6 July 2008 (UTC)
I just made a few corrections, but most of the dates in this section do not conform with WP:DASH:
On this page, date elements that have spaces are incorrectly joined with unspaced endashes. No wonder I deal with constant fixes and confusion at FAC; most of the examples on this page are wrong. SandyGeorgia ( Talk) 08:32, 12 July 2008 (UTC)
Yesterday, I attempted to solve a massive overlinking issue with List_of_Final_Fantasy_compilation_albums, a new nomination at WP:FLC, by removing all of the autoformatting. No one minds US date formatting, even if it requires a comma, just as they accept Euro formatting after their signature.
I was delighted that nominator PresN responded at the FLC page: "Well, can't say I'm sad to see the sea of blue leave. It's much easier to read now, thank you."
You may wish to compare the previous autoformatted version with the new, normal script version. Scrolling down side by side is best, but the difference is clear by comparing one after the other, too. Tony (talk) 04:16, 2 July 2008 (UTC)
If we’re going to have an autoformatting (with no linking to trivia) function for dates, it should be an I.P.-sensitive one that simply looks to the country the reader hails from. This is a common tool on the Internet and is routinely used to gather statistics of any given Web site’s visitors. The MOSNUM guideline would then say that for articles about a particular country, the dates would be in fixed text in the format typically used in that country. But for articles of a general nature, the dates could use an I.P.-sensitive autoformatting template. But, actually, I’m convinced most readers don’t give a darn about the formatting of dates. I’ve long used the Euro format (and I’m an American) in my general-interest articles (those not tied to a particular country), and haven’t had a single reader ever edit a date to Americanize it.
Frankly, if there was going to be an I.P.-sensitive function created that could be used in magic words and templates, I’d just as soon see it used so {{dialect|color|colour}}
would be read as “color” in the U.S., and as “colour” in England/Australia/etc. It wouldn’t have to be “smart” at all. Simply by looking to the readers’ I.P. address, {{dialect|trunk|boot}}
would be read as “the border patrol agents discovered the bomb upon opening the trunk” for Americans, and as “the border patrol agents discovered the bomb upon opening the boot” for others. Now that, would be something I’d really like.
Greg L (
talk)
13:54, 3 July 2008 (UTC)
January 1, 2008
and shouldn’t be pretending we’re doing any good with
{{cite web}} and [[1 January]] [[2008]]. We shouldn’t bother with any tool that only benefits us registered editors. Why?Because when registered American editors see “January 1, 2008” and European registered editors see “1 January 2008”, we editors—especially the European ones who are content with the dates they see—are going to loose track that most everyone else in Europe sees American-style dates. I’m American but can imagine that in an article like French Revolution, an English-speaking European reader (there are many) would find “June 10, 1789” just as awkward as would an American seeing “4 July”. Further, new editors who aren’t highly familiar with the idiosyncrasies of these tools will simply copy them from other articles without being aware of their limitations.
Again: If we’re going to be autoformatting dates, make it work for regular readers or forget it. Otherwise we’re just all patting ourselves on the back by making tools that only we can enjoy, as if we registered editors are privileged Eloi and most every regular reader is just a subterranean Morlock.
And, of course, loose the damned links to trivia for all but the most topical and relevant circumstances in historical articles. Greg L ( talk) 23:26, 4 July 2008 (UTC)
Per footnote 2 on Wikipedia:Only make links that are relevant to the context, it is being stated that some metric units are considered common measurements. Also related to this is the statement in this document that, "Articles on scientific topics where there is consensus among the contributors not to convert the metric units, in which case the first occurrence of each unit should be linked." I'd like to point out that in the U.S., metric units are most certainly not common. In fact I've seen messages from some U.S. readers who don't have a clue about the metric system. Thus I don't think it is especially beneficial for Lightbot to be removing wikilinks of metric units from scientific articles, as some readers may not be able to relate well to "m" or "km" as units without a link to go read up on the subject. Is there some way these policies can be rectified in a manner that is more beneficial to our readership? Thank you.— RJH ( talk) 15:23, 7 July 2008 (UTC)
How about this sort of a step-back-and-look-at-the-whole-picture. If SI units are unfamiliar, ought we not be providing conversions to imperial/US units? If there are such conversions, those unfamiliar with the primary units can ignor them and look at the conversion. If the units being used have no particular connexion to the topic at hand, what worth is there in linking them? Should we therefore not bring into question this notion of allowing metric units to go unconverted in "scientific" contexts (... and how exactly do we draw that line?). WP:OVERLINK does recommend (and wisely, in my view) not linking common units of measure (I wouldn't count any deci~ units amongst these, even decibel would be worth linking). Something's got to give. JIMp talk· cont 02:02, 8 July 2008 (UTC)
If there are disciplines where there really is common use of a non-SI unit, such as cubic inches of displacement for auto engines, then sure, we should provide the conversion. And the reasoning is simple: because there really are readers who really think that way, so the conversion is helpful. I’m about as pro-SI as they come. But I also hate cluttering up articles with conversions for the sake of providing a conversion. For instance, closely examine Thermodynamic temperature. Spend a good couple of minutes looking it over. I wrote much of that. It would become one big eyesore if we just didn’t stick with joules, kelvins, J/K, °C, etc. It clearly doesn’t look like a suitable candidate for being hit with a 12-gauge shotgun of conversions. Let’s think though why it appears so. Well, it meets the first test: the original science is always done in SI with no conversions. And it also even meets a second test, which alone should exempt it: the basic measures are abstract enough to not have any real connection to American brains, which think in U.S. customary units. It does no one any good whatsoever to know that the Boltzmann constant, kB = 1.3806504(24)×10−23 J/K is equivalent to 7.270023(13)×10−27 BTU/°R. Does the latter mean anything to anyone? Certainly not.
So I would advance the following rule to be considered:
In disciplines and fields where Americans {we might as well not beat around the bush here} routinely think of measures in U.S. customary terms and the value is expressed in SI units, provide a parenthetical conversion to U.S. customary where appropriate. Do not provide conversions in articles on scientific disciplines when current literature on that topic is always in SI units. And do not provide conversions where the measures are abstract (because either the values are very large or small, or because the measure is intrinsically arcane in nature). In deciding whether or not to add a parenthetical conversion, the basic question editors should ask themselves is “do readers exist who really think this way so a conversion would truly be helpful?” If the answer is “yes”, then it should generally be true that there currently is, or recently once was, a significant amount of U.S. literature using those non-SI units of measure.
←outdent
sounds reasonable enough ...
JIMp
talk·
cont
04:02, 8 July 2008 (UTC)
Which is already covered by the MOSNUM... Headbomb { ταλκ – WP Physics: PotW} 04:07, 8 July 2008 (UTC)
Here are some points to think about:
I happen to think that the current guidance at wp:context is fine as it is. It could perhaps contain an additional comment that the presence of a conversion usually eliminates the requirement for a link. Lightmouse ( talk) 23:13, 8 July 2008 (UTC)
Can we at least agree about conversions. Where a unit is part of a conversion e.g. '6 foot (1.8 m)', the link is not needed to support conversion. A huge number of links to common units are part of conversions. Lightmouse ( talk) 22:19, 9 July 2008 (UTC)
Note that even a broad, blanket rule for a bot which allows the first instances of units of measure to be linked and then delinks the rest isn’t necessarily a “fits-all”, universal solution that works in all articles. Sometimes, in my articles, I repeat a link if the first link was up in the overview and the second link is further down in a much different or more detailed context. I don’t know if I ever bothered doing this with a unit of measure, but I do know I make links only for good reason and try hard not to overlink. I’m really not seeing where authors’ linking the first instance or two of units of measures—even in conversions—is such an egregious case of over-linking that bots need to be let loose to solve Wikipedia’s problems.
Some bots, like spelling-correction bots, are uncontroversial and it is a no-brainer to let them loose. Letting a bot loose to de-link damned dates ( October 16), while somewhat more controversial, is a sound technical writing objective to 1) get away from the blue turd of “link-itis” and 2) avoid desensitizing readers to links that are nothing more than easter egg hunts that only take them to non-relevant lists of trivia. De-linking years is more of a grey area because intrinsically historical articles might conceivably use them to good effect. But I support the bot because there are simply so many unsuitable date/year links, it is easier to let the bot do all the dirty work and hand-restore those that are suitable.
But this “units” bot needs to be discussed more. I’m sorta thinking aloud here, but maybe it would be OK if there was a bot that delinks units of measure that are linked more than twice in an article, or more than once if the second one is too close. And, yeah, I’m thinking that parenthetical conversions can have their units delinked too. But if there is a bot that is delinking units of measure on the false presumption that certain metric units are “universally common,” that needs to be stopped at once. If we can’t properly self-regulate our use of bots to ensure that what they accomplish is generally well-accepted in the authoring community, onerous hurdles to employing them can get imposed on us. Greg L ( talk) 23:47, 9 July 2008 (UTC)
As far as I know, bots can only apply per-page rules and can't count instances within a page. I did a quick survey and found that about 50% of links to common units of measure have conversions e.g. Blue Streak missile, Carnivora, Ethan Allen, Greenpeace. Linking common units of measure in conversions seems to be one of those things that people just do because they can. It seems bizarre to me. Lightmouse ( talk) 09:11, 10 July 2008 (UTC)
The United States would develop an Intercontinental ballistic missile (ICBM) of 5,000 nautical mile (9,300 km) range, while the United Kingdom…
Having said all that, I am beginning to drill down better into the nuances of this. It appears to me that in this expression (also a paradigm example, from Carnivora):
“11 cm (4.3 in)”
So I think RJH’s 15:23, 7 July 2008 post that started this thread hit the entire issue precisely on the head. I couldn’t have said it better and believe he is 100% correct. Greg L ( talk) 17:20, 10 July 2008 (UTC)
There is no delinking bot. I think that we are much in agreement here. Remember, the issue is only related to common units in either system. You will see lots of examples like the ones I gave. To be specific, I meant:
About 50% of links are like that. —Preceding unsigned comment added by Lightmouse ( talk • contribs)
I agree with you. It got messy. Let us take things step by step. There is a bot that does date delinking. Whilst it is in an article it does many supplementary tasks including but not limited to:
It also delinked common units in accordance with wp:context. On the basis of strong feelings expressed here, the scope was further confined to *common units in conversions*. On the basis of further strong feelings expressed here, even that was stopped. I hope that calms things down a bit. [I think that would. Thanks. Greg L ( talk) 21:53, 10 July 2008 (UTC)
I know that the example articles contain several units. Can we address the issue of *common units inside conversions*. There are many examples but here are just four:
Regards Lightmouse ( talk) 21:48, 10 July 2008 (UTC)
Allow me to address the latter point first. The vast majority of what the bot is doing could be considered as “housekeeping,” which is pretty much uncontroversial. As such, I trust your judgement on these housekeeping chores. And I am really, really pleased that (you?) have invested so much of your volunteer efforts into it. Wikipedia is much better off. I wouldn’t ever want to make it so a task that you’ve undertaken as an enjoyable hobby becomes nothing but drudgery and conflict; you’d simply take a ‘screw you’ attitude (I wouldn’t blame you) and go and find something else to do on Wikipedia. Wikipedia would be worse off for it too. I do submit, however, that issues like de-linking common units of measure inside of parenthetical conversions isn’t clear-as-glass, “uncontroversial housekeeping” and is treading a tad close to content editing. So too was date delinking, but the consensus view of our best editors was that it is a good thing. On these sort of grey areas, I suggest you discreetly solicit input first, rather than after-the-fact. Maybe there are some trusted editors you can e-mail.
As to your first point (delinking *common units inside conversions*), I see your point. The logic for de-linking common units in parenthetical conversions—both metric and U.S. customary—is a bit convoluted to go into here, but as long as it’s a parenthetical conversion and is a common unit, whether it’s metric or not, there really would never be any practical value to having it linked. I haven’t studied this issue very well and can imagine there might be unforeseen ramifications for wadding into this one. I also don’t really see much harm in leaving these things alone because the principle of least astonishment isn’t violated with these links (and they’re usually small); I know precisely what article I’d end up on if I clicked on it (so I never do). So I would recommend we get the input of several more editors here (which is no doubt what you had in mind). An alternative objective to consider would be to de-link after the first occurrence of common units in parenthetical conversions. Greg L ( talk) 22:26, 10 July 2008 (UTC)
P.S. I suppose, taking my “convoluted” (but undisclosed) logic to its logical conclusion, there would be no point linking the primary common unit (metric or U.S. customary) that is accompanied by a parenthetical conversion. That’s separate from the issue of whether it is wise to even attempt to address this issue with a bot. Greg L ( talk) 22:43, 10 July 2008 (UTC)
Thanks, it can sometimes seem that I could have an easier life if I just copy edited a few articles. Yes, let us hear from other editors. I think we are on similar lines here. I think:
should be simply
Regards Lightmouse ( talk) 22:50, 10 July 2008 (UTC)
Have you read the examples given at wp:context? Lightmouse ( talk) 09:21, 11 July 2008 (UTC)
But the more I think about it, I think it is unwise to delink the first occurrences of these. If an American sees “6 feet (1.8 m)” and doesn’t know that “m” is the symbol for meter (which the American may or may not be familiar with even by name), they should be able to click on the linked symbol (m) and see what the hell that means. If we were going to unlink anything, we would do as Tony suggested above: de-link the “foot” “since no one else needs to know about them.” The issue we’re trying to address is concerns over overlinking in articles—some of them have had people go ape-shit with links. But I just don’t see the disadvantages as being all that onerous of putting up with just a first occurrence link in an article. These links to units of measure and their unit symbols are small and don’t violate the principle of least astonishment whatsoever (unlike “She was crowned June 2”). Readers either recognize what they are and don’t click on them, or they are don’t recognize the unit or unit symbol and do choose to click on them.
I propose that if the bot is to do Wikipedia an unquestionable good service, that it simply hunt down and delink the 2nd+ occurrences of common units of measure that are accompanied by a parenthetical conversion. That’s a number of tests: 1) is the unit of measure “common”; that is, is either centimeter/inches or meters/feet (but not their squares and cubes), or kilograms/pounds, or °C/°F, and kilometers/miles? 2) is it accompanied by a parenthetical conversion? 3) Is it linked? 4) Is there already another instance earlier in the article that is linked? If the answer to these four questions is ‘yes,’ then the bot delinks both sides. Now I see that as doing some good: getting rid of multiple linked units in conversions that repeat and repeat in articles. Greg L ( talk) 19:18, 11 July 2008 (UTC)
P.S. Given how benign this bot would be in this regard, we might even consider delinking the 2nd+ occurrences even if they’re not “common”—so long as they are a parenthetical conversion. This is quite distinct from the 2nd+ occurrences of linked units of measure that are not parenthetical conversions. Sometimes I link units of measure or terms more than once if the first occurs early in an article—in the overview for instance—and another instance is way further down in the article in a more detailed or much different context. Greg L ( talk) 19:28, 11 July 2008 (UTC)
When a bot finds a page where there are multiple instances of the very same measure and parenthetical conversion, and further, the unit of the measure is a common, well-recognized one, can there possibly be any harm in letting the bot simply de-link only the redundant instances? For instance, if the article mentions “6 feet (1.8 m)”, could there possibly in any harm in de-linking the next instance, which might read “14.5 feet (4.4 m)”? And the next one, which might read “3.5 feet (1.1 m)”? With the bot so highly limited on this very specific issue, I’m in agreement with Lightmouse; I’m just not seeing where having the units linked again and again adds anything to an article whatsoever and can see that it amounts to simple massive clutter-itis with links. Is there a legitimate reason for linking again and again in conversions that I can’t think of? Greg L ( talk) 22:52, 11 July 2008 (UTC)
Possible overlinking: I noticed that the unit symbol ‘km’ is mentioned eight times and three of those instances are linked. Unless some of these other links are in very different contexts in the article, you might consider linking only the first occurrence and leaving the rest unlinked.
The new date formatting convention is confusing editors at FAC (it seems to mostly be a situation where it's not being explained correctly). Since the citation templates don't work right, it's not possible for editors to be consistent within articles; asking them to delink dates when the citation templates can't be made to agree isn't working. Further, the instructions here aren't crystal clear (they are now a hybrid of old understanding of the old method plus new convention, with a disconnect inbetween) and there's no one section I can point to that editors will understand. I ended up having to spell it all out myself three times today after two editors delinked dates incorrectly (they delinked only partial dates, not understanding the intent of delinking): for example, see Wikipedia:Featured article candidates/United Airlines Flight 93. We need a clear explanation somewhere that users who didn't understand even the old method can digest. I spent hours delinking Samuel Johnson today, and with the inconsistent citation templates, I wonder if it was worth it. SandyGeorgia ( Talk) 07:06, 12 July 2008 (UTC)
The citation templates can and should be fixed. What we can't do is apply autoformatting to dates such as 11–14 May 1987. If we've got one od these in an article, then there should be no autoformatting at all. JIMp talk· cont 00:58, 14 July 2008 (UTC)
If an FA reviewer is rejecting an article because it links a couple of highly significant dates, or because it uses auto-formatting, or because the raw formats in footnotes are ISO not localised, then that reviewer is not acting in the spirit of FA or the spirit of MOS. Auto-formatting has not been conclusively deprecated, despite the smoke and noise. -- Hroðulf (or Hrothulf) ( Talk) 12:49, 15 July 2008 (UTC)
The section at Wikipedia:Manual of Style (dates and numbers)#Chronological items - "Longer periods" is misleading. All through wikipedia decades such as the 1960s are considered as beginning on 1 January 1960, 1950s on 1 January 1950, and so. The 1890s began in 1890 and ended in 1899: the next decade, century began the next day. In popular usage the 20th century began 1 January 1900 along with the new decade. The third millennium, 21st century, the "noughties" (first decade of the century) all began on 1 January 2000. The manual should reflect this usage. 62.64.205.30 ( talk) 17:27, 18 July 2008 (UTC)
Hello, in my moonbook I have an old script designed to format dates according to previous versions of MOSDATE. Question(s): Is there an upgrade avaliable anywhere to mirror the recent changes in MOSDATE? If not, is there a way to change my monobook script manually to reflect this? If neither option is avaliable, I think someone more monobook-inclined would be doing a great service if they could look at this to help keep articles MOS compliant. -- Jza84 | Talk 01:00, 19 July 2008 (UTC)
For as long as I can remember, I was told to follow the convention to link full dates (mm-dd-yyyy et al), and never to link mm-yyyy or lone years. Have conventions changed, or is this still universal, since I had trouble finding anything definitive in this MOS.-- 十 八 01:27, 19 July 2008 (UTC)
Coming to grips with this reality (that autoformatting is of no benefit whatsoever to the vast majority of visiting readers on Wikipedia) and therefore abandoning the practice, also reduces unnecessary link clutter because readers will no longer be tempted to click on Easter-egg links like “ August 8” while reading up on, for instance, a fusion experiment at a national lab. They will no longer be presented with a random list of historical events that amount to nothing more than trivia like “1220 - Sweden was defeated by Estonian tribes in the Battle of Lihula.” While each of these entries was significant and meant something to some contributing author somewhere on this planet, links to this sort of stuff—more often than not—have no particular relevance to the subject matter within the article; readers’ minds learn to start ignoring links as a result. Greg L ( talk) 18:57, 20 July 2008 (UTC)
This came up while reviewing this FA: the editor had used decimal feet in the article, for example "152.9 feet" instead of "152 ft 11 in". It was also discussed briefly at User_talk:Epbr123. The consensus seems to be that when using English units that do not customarily use decimal fractions that they should be avoided, but there's no MOS for this. I'd like to propose the following addition to the "Which units to use" section of this guide:
Or, perhaps some better version. Fractional pounds are sometimes seen in real life, but decimal fractions of feet seem off. Would anyone have any objections to this change? JRP ( talk) 03:41, 19 July 2008 (UTC)
Is linking complete dates a preference or a must? -- Efe ( talk) 04:07, 23 July 2008 (UTC)
I'm just piping up here to say that the fact that we are now allowed to delink full dates is going down very well on the ground (look at Tonys talk!) I delinked a bunch of my articles last night and it was very very satisying work. Personally I never use cite templates and I strongly believe they should be depriecated; but whatever, lets end date linking at all costs. ( Ceoil sláinte 15:41, 27 July 2008 (UTC)
MOSNUM's "Numbers as figures or words": Anderson is unilaterally trying to change the analogous text at the MoS main-page, as yet unsuccessfully.
I believe that his changes this month at MOSNUM to the traditional default boundary of nine/10 (with exceptions) are not based on consensus. This needs to be resolved on this talk page. Apart from all else, we now have unsuitable statements such as:
The reader should not be confused by the manner of expressing a quantity.
Gee, that helps. And his home-grown patronising statement—
Careful readers may object to the use of 100,000 troops as a rough description of a force of 103 thousand;...
Now Anderson's usual smoke-bomb, the dispute tag, has gone up at MOS main page. I call for discussion on how to harmonise both MOSNUM and MOS main-page texts in this area. I'm posting a note at MOS main-page talk with a link here. Tony (talk) 06:19, 24 July 2008 (UTC)
I do not find MOSNUM's "Numbers as figures or words" clear. I consulted it recently for an FAC article and did not see a rule regarding the nine/10 issue. Maybe I am blind. — Mattisse ( Talk) 18:21, 29 July 2008 (UTC)
MOSNUM currently says: "it is permissible to have imperial units as primary units in UK-related topics." Shouldn't that be Commonwealth as the units were used there as well? Or is there some reason to restrict their use on Wikipedia to just Great Britain and Northern Ireland? Caerwine Caer’s whines 21:43, 27 July 2008 (UTC)
* The intent of the guideline seems clear. So my bet is that “UK” was unintentionally used in place of the more appropriate—and broader—“Commonwealth”. Why shouldn’t an article about an Australian-related topics be able to use imperial units? I can think of no valid reason.
Greg L (
talk)
21:47, 27 July 2008 (UTC)
On 7 June 2008 a substantial change was made to WP:MOSNUM, including a virtual ban on the use of IEC units of computer storage such as the mebibyte. At that time, the views of editors arguing against the ban were not taken into account, despite an 11-0 majority against such deprecation only 2 months before that. As far as I know, no attempt was made to seek the views of those 11 editors, even though only 4 of them were involved in the discussions prior to the change in June. Nearly a month has passed since then and it may be time to reconsider whether it is wise for MOSNUM to include a statement for which there is little or no consensus.
A brief summary of events leading up to the change is discussed here. Details of the long discussion leading to the change can be found here. Two subsequent attempts to discuss this point were made by Omegatron and by Quilbert.
Below I list some arguments for and against deprecation.
After four straight months of intensive debate, this failed guideline was abandoned and Wikipedia was finally brought in line with real-world practices. What’s it been… a month since we finally put an end to it? Nothing has changed since that time except to put Wikipedia’s computer articles well on the path to using terminology and language that is familiar to readers. Really, the worse thing about the way Wikipedia used to be, was that Wikipedia didn’t even have project-wide consistency; only some articles used the IEC prefixes and this meant that the conventional terms like “megabyte” had one specific meaning in one article and an entirely different meaning in still other articles.
Do you really think you’re going to reverse this and make it so some (or all?) of Wikipedia’s articles once again use terminology that everyone here agreed weren’t even recognized by the typical Wikipedia reader? That is just so unfathomly unrealistic. Greg L ( talk) 20:19, 5 July 2008 (UTC)
Wikipedia is an encyclopedia, not an instrument for special interest groups (like IEC) to try to push the way they would like the world to work. We should reflect in the encyclopedia what the world is like, not what we think it should be. The reality is that kilobyte means 1024 bytes most of the time it's used. Many people who use computers (including much of the IT industry) have never heard of a kibibyte and don't use the term. We shouldn't be social engineering.
The standard's not established enough yet. I had never heard of these things before I came to Wikipedia.
I have little doubt that both lists are incomplete. Comments are invited, as well as new additions to either one. Thunderbird2 ( talk) 18:50, 5 July 2008 (UTC)
Certain proponents of the ban are acting like trolls and making a battleground for a war of attrition. Maybe it would be better not to justify their behavior, and resolve to not debate. The whole matter is subjective, the evidence is made up and prone to change, and the notion that something "should" be done is bullshit. This discussion is not necessarily working toward a logical conclusion. Furthermore, parties represented by single-use accounts are clearly not interested in the betterment of Wikipedia, but are simply average internet trolls. Considering the opposition argument to the ban is comparable to the backing, and clearly underhanded methods have been employed, why not just seek wp:arbitration to end the "debate" once and for all. Then, this terminology can be decided as all other, by free Wikipedians. Potatoswatter ( talk) 23:05, 5 July 2008 (UTC)
I'm not going to waste my time responding in detail to the incredibly biased statement of arguments above; they do not even attempt to fairly state the positions. I have been more or less following this issue for about a year now, and was not aware of the proposed rewrite of the MOSNUM nor of the "vote". Had I been aware, of the discussion, I would have opposed deprecating. I notice a number of folks opposed to the deprecation of IEC are also missing from this so-called consensus - a coincidence or manipulation? Looks like the latter to me! FWIW, IMO, 220 is in many ways worse than IEC prefixes. Most readers don't have a clue to these exponential disambiguations so any objection to IEC should equally apply to both! Those of us who can deal with exponents can also deal with IEC. IEC has the advantage of compactness and can be wiki linked for disambiguation for those who really care about meaning. I would much rather see:
which I think is a whole lot better than either:
To make a point, I didn't bother to calculate the number of bytes in a GiB, I can never remember binary prefix multipliers beyond 1 KiB :-)
I for one would like to see the deprecation of Binary IEC prefixes removed.
Tom94022 (
talk)
01:40, 6 July 2008 (UTC)
(*sound of crickets chirping*)
Nothing new is being said here these last few days. All this has been hashed through over and over and over and the issue keeps on coming up. We tried the IEC prefixes on Wikipedia for three years with nothing but bloody continuous bickering the entire time. And there was good reason for the bickering: the IEC prefixes were still not finding any real-world traction and were still unfamiliar to our readers. Just because the “loosing” side is dissatisfied with the outcome and keeps raising the same old arguments doesn’t mean we have to reopen the case. It’s closed. I am baffled that the proponents of the IEC prefixes would still be agitating to go back to the old policy, which has to be one of the least successful guidelines in all Wikipedia history.
If circumstances change as far as the real-world adoption of the IEC prefixes, I’m sure you’ll let us know. In the mean time, please exhibit the grace to accept with serenity the things that cannot be changed. I accept that you’ve certainly got the courage to change the things you think should be changed; I’m just beginning to question whether you’ve got the “wisdom” thing down when it comes differentiating between the two. Greg L ( talk) 23:22, 6 July 2008 (UTC)
Refusal to 'get the point'
In some cases, editors have perpetuated disputes by sticking to an allegation or viewpoint long after it has been discredited, repeating it almost without end, and refusing to acknowledge others' input or their own error. Often such editors are continuing to base future attacks and disruptive editing upon the erroneous statement to make a point.
Wikipedia is based upon collaborative good faith editing, and consensus. When a stance passes the point of reasonableness, and it becomes obvious that there is a willful refusal to 'get the point' despite the clear statement of policy, and despite reasoned opinions and comments provided by experienced, independent editors, administrators or mediators, then refusal to get the point is no longer a reasonable stance or policy-compliant - it has become a disruptive pattern, being used to make or illustrate a point.
Note that it is the disruptive editing itself, not the mere holding of the opinion, that is the problem.
(un-indent_
You seem obsessed that ‘there was this vote or that vote, or people did or didn’t change their minds’ and you seem to ignore our stated reasoning that if we did as you want, Wikipedia would be the only general-interest publication on the planet that uses the IEC prefixes. No other publication for general-interest readerships uses them. No computer manufacturers use them to communicate to their customer base; not in their advertising, owners manuals, or whatever. If the operating system of my computer or yours states file sizes, it’s in kilobytes. If general-interest computer magazines write of file sizes, they don’t use the IEC prefixes. All other professionally edited encyclopedias use the conventional prefixes. I wrote of all of this above. You conveniently ducked all that too. I wrote about how every single editor who was engaged in the discussion in late March agreed that—because of this military-strength non-use of the IEC prefixes— the word “mebibyte” (symbol MiB) is not widely recognized by the typical Wikipedia reader. None of these facts seem to deter you. You come across as “I want my IEC prefixes! I want my IEC prefixes! We had them for three years and I want them baaaaack!. Well… tough.
I, for one, won’t go one one inch further with you playing your games until you stop ducking these inconvenient truths and directly and properly address each and every one of these issues. What you’re asking violates the most basic of all technical writing principles: your asking that Wikipedia use terminology that is generally unrecognized by the vast majority of common folk interested in the subject of computing. WTF! What part of “sound technical writing practices” do you not understand? I don’t want to hear the same ol’ saw about how “the IEC prefixes have been anointed with holiness and goodliness by major standards organizations.” Like I said in my above post, it doesn’t matter if some obscure publications from standards bodies use the IEC prefixes if the average Joe has never even heard of the organization. We heard that argument and rejected it as insufficient to overcome the disadvantages inherent in their use.
Now, it’s your turn to acknowledge and address each of these points. Like Headbomb said, he never got a satisfactory answer out of either you or Thunderbird2 over the course of two months. Now get cracking and put up or shut up. Otherwise both you and Thunderbird2 are just wasting our time with circuitous babble that isn’t addressing the issue. Both of you will be ignored (and for damned good cause) if you keep up this game of yours. What we really need here is to create a special page ( WP:MOSNUM/IEC Prefixes:Waaaaaa ) with rubber-padded walls and the next time you two post something that amounts to nothing more than a big fat helping of WP:POINT, we’ll simply move it over there where you two can bounce off the walls. This thread is already destined to become the 14th “Binary” archive (smooth move). Moving this nonsense somewhere else will avoid having to create a 15th. Greg L ( talk) 16:24, 7 July 2008 (UTC)
10.1.3 IEC units should be banned except for direct, verbatim quotes, and articles discussing the units themselves
* Disagree Tom94022 (talk) 22:31, 28 March 2008 (UTC) * Disagree LeadSongDog (talk) 23:49, 28 March 2008 (UTC) * Disagree Dpbsmith (talk) 23:59, 28 March 2008 (UTC) * Disagree, proper use should be encouraged. Seraphimblade Talk to me 15:05, 29 March 2008 (UTC) * Disagree — Christoph Päper 16:41, 29 March 2008 (UTC) * Disagree SamBC(talk) 18:17, 27 March 2008 (UTC) * Disagree (partial solution) Greg L (my talk) 18:32, 27 March 2008 (UTC) * Disagree Thunderbird2 (talk) 18:41, 27 March 2008 (UTC) * Disagree Jeh (talk) 20:48, 27 March 2008 (UTC)
* Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC) *Agree DavidPaulHamilton (talk) 23:31, 1 April 2008 (UTC)strike the sock JIMp talk·cont 08:06, 6 June 2008 (UTC) * Disagree — Omegatron 05:49, 6 April 2008 (UTC)
I still find it amazing that a clear consensus as of March 30th can be diametrically reversed. I intend to invite those other missing editors to join the discussion. Tom94022 ( talk) 05:40, 7 July 2008 (UTC)
Had the situation been fairly presented, the status on 7 June 2008 could have been:
That is, 11 for and 10 against - some consensus. It might even be 10:10 since the against are explicit while Dfmlean is by implication! ( talk) 21:19, 7 July 2008 (UTC)
Alternatively, the status on 7 June 2008 could have been:
It is truly amazing that the deprecation advocates can claim consensus when their so-called consensus, that is, a "vote", is followed within a few lines on the talk page (and preceded by a few weeks in time) by clearly stated opposition, also a "vote", but somehow this "vote" doesn't count. And for all the harping otherwise, the reasons against deprecation have been clearly stated many time overs and have nothing contrary to WP:UNDUE or WP:CRYSTALBALL. I won't bother to again state them because I know Fnagatron will again, without basis or cause, denigrate, deny or dispute them. I will; however, add a disputed notation to the sub-paragraph of section 4.3.4.2 of WP:MOSSUM Tom94022 ( talk) 21:19, 7 July 2008 (UTC)
But before we do that, I challenge you to address each and every point above in my 16:24, 7 July 2008 (UTC) post. I don’t think any of us here have heard a satisfactory answer from you on this; only what Fnagaton calls “I don’t like it.” Greg L ( talk) 03:58, 8 July 2008 (UTC)
And speaking of "whining", I am tired of you trying to name-call and ridicule your opponents into silence. You've threatened to ignore us? Your privilege, of course, but if you do so, others will define a new consensus without you. Jeh ( talk) 04:46, 10 July 2008 (UTC)
It is clear from the above discussion that the deprecation does not have the widespread consensus it would need for it to stay, at least in its present form. The explicit deprecation would appear to have its roots in the following statement:
I for one do not support this - familiarity and unambiguity are both needed in an encyclopaedia. What do others feel? Thunderbird2 ( talk) 06:17, 8 July 2008 (UTC)
And please explain why you are smarter than all the professional, paid editors at Encyclopedia Britannica and World Book and PC World and Mac World and pretty much all other English-language publications on the planet that communicate to a general-interest audience.* They don’t use the IEC prefixes because it would be using terminology that is unfamiliar to their readers (and ours). You don’t seem to give a flying crap about that little detail. So please explain why you are so smart and all these other editors throughout the world are all so wrong that you’d have Wikipedia be all alone on this one.
And if you actually do have the chutzpah to tell us here that every one of these professional editors are so wrong and you have it alllllll figured out, I would be deeply interested in hearing about your journalism credentials and education. Because you come across as if you have insight and understanding on this issue that is at a plane of consciousness that I can’t even comprehend. Do you have an advanced journalism degree with a special emphasis on technical writing or something? I’m serious about this question. Or is it because the IEC prefixes are recommended by some standards organizations the average Joe has never even heard of? You must think that the editors at the other encyclopedias and magazines don’t know that. You’re going to ‘show them’, aren’t you? Greg L ( talk) 15:09, 8 July 2008 (UTC)
I think the decisions of print publications and other web sites are fine for them within their constraints. But it is entirely possible that Wikipedia knows better for Wikipedia than anyone not involved with Wikipedia. None of the publications you mentioned is a) a general-purpose encyclopedia that b) is on the web and c) so effectively uses in-line links to explain unfamiliar words and principles. In my opinion the genius of the IEC prefixes is that they look close enough to their decimal counterparts that the user who doesn't care about the difference doesn't need to understand them; they can read "MiB" as "MB" and remain no worse off than they were before. But if they want to know what it means, on WP they can click on the "MiB" wikilink and will thenceforth be informed.
Now it has often been claimed before (and no doubt will be again) that disambiguation and footnotes of the conventional prefixes will accomplish the same goal. The problem with that is that the conventional prefixes remain ambiguous and therefore require the reader to check the footnotes or understand the disambiguation on every usage. Whereas if IEC prefixes are used consistently, once they are understood by the user they never have to be explained again. I think that's a powerful advantage and I don't think there has been any sort of effective rebuttal to that point, other than the value judgement that familiarity is more important than accuracy and lack of ambiguity (a value judgement with which I of course disagree).
Finally: Greg, I will ask you once again: Please try to avoid name-calling, ridicule and dismissiveness in your replies. Really, it only makes you appear weak. Jeh ( talk) 06:17, 12 July 2008 (UTC)
I see only one editor defending the use of ambiguous units without disambiguation, so I propose rewording and simplifying the opening text from
to
Any objections? Thunderbird2 ( talk) 06:34, 9 July 2008 (UTC)
Well, we don’t agree with you and know that your logic and values on this issue are 110% faulty. We’re going to follow what the professional editors at Encyclopedia Britannica and World Book and PC World are doing, not you. Are you going to accept that or cop a big fat WP:POINT attitude until the Heat death of the universe? Because if you expect us to go along with what you are agitating for, I expect you to first prove how all the professional editors at these print encyclopedias are complete retards who shouldn’t be looked to for guidance on this matter and you’re some sort of Einstein who’s “got it all figured out”. Forgive my skepticism, but I’m not holding by breath for that one. Greg L ( talk) 17:47, 10 July 2008 (UTC)
Given the contention over proper style, the volume of text going into the disclaimer footnotes, and the number of articles in "need" of tagging, it would be a good idea to make a reusable and modifiable template to simplify maintenance of articles. Potatoswatter ( talk) 00:56, 10 July 2008 (UTC)
You know that's not a crazy idea at all. I'll write the drafts. Headbomb { ταλκ – WP Physics: PotW} 01:23, 10 July 2008 (UTC)
Here you go: {{ BDprefix}} (for Binary-Decimal Prefix) Headbomb { ταλκ – WP Physics: PotW} 01:54, 10 July 2008 (UTC)
After reading about this being changed (yet again) in the Signpost, I considered coming here to comment on the new methods of disambiguation called for in this guideline (IMO, the only one that makes any sense in this morning's version is to use footnotes). But after skimming through the above, I'm not going to touch this mess, and I doubt I'm the only one who takes one look at this and decides WP:IAR applies; please remember that any "consensus" here will probably be made up of only those people who can stand GB (GiB, 10243s of bytes, 230s of bytes, or 1,073,741,824s of bytes) of arguing. FWIW, I will not watch for any replies to this comment as this page is simply insane. Anomie ⚔ 13:29, 12 July 2008 (UTC)
Well, Anomie, do you feel better now after that little fourth-graders’ rant? Because that sort of argument doesn’t do much to sway opinion your way. Indeed, the guideline has been changed *again*! And now we’re actually using units of measure the rest of the planet uses (imagine that). The only trouble is that we’ve got all the intrusive disambiguations (so I agree with you on that point). Those “disambiguations” will eventually become less intrusive as editors gain experience and some users stop editing in order to disrupt Wikipedia to illustrate a point (“Look! Look how ugly all these disambiguations are now that I have to use the ambiguous conventional prefixes”). Greg L ( talk) 22:26, 12 July 2008 (UTC)
I have completed a request for cabal mediation here. Thunderbird2 ( talk) 16:49, 13 July 2008 (UTC)
Why don’t you actually answer this direct question: are you up to binding arbitration on whether the current policy was the product of a properly arrived at general consensus? Even if you are, I’m not up to all the heavy lifting necessary to go through with arbitration; it’s going to take a heavy dose of Headbomb’s efforts here, as well as Fnagaton’s. But I’m terribly interested in first hearing whether you, T-bird, are willing to abide by the ruling of an arbitration committee.
Note that the better solution, in my mind, would be for you to admit that the four-month-long debate/discuss/poll process that resulted in the current guideline should serve as a paradigm for how dispute resolution is conducted on Wikipedia and that the consensus that developed was fair and should be observed by all. You don’t think so? Ergo, binding arbitration. Greg L ( talk) 20:06, 13 July 2008 (UTC)
Please, just drop the issue. Headbomb { ταλκ – WP Physics: PotW} 22:13, 13 July 2008 (UTC)
Relevant discussion at | → Wikipedia talk:Manual of Style (dates and numbers)/Archive 105#Should MOSNUM continue to deprecate IEC prefixes? |
Normally you would use it between ref tags
Examples: <ref>{{BDprefix|p=B}}</ref> [1] <ref>{{BDprefix|p=D}}</ref> [2] <ref>{{BDprefix|p=F}}</ref> [3]
produces
Snazzy. Potatoswatter ( talk) 02:22, 10 July 2008 (UTC)
Ok, did that. (I wish it could be less wordy while still being correct.) The change shows up when I call the template but not in the documentation page? I thought the doc page was generated from the template? Jeh ( talk) 01:02, 13 July 2008 (UTC)
Google gives about 233,000,000 for colour verses about 1,150,000,000 for color but we allow the former. More relevant to this question, though, are the points made here, which are backed up by the fact that this British dictionary draws a blank on floppy disc. JIMp talk· cont 04:37, 10 July 2008 (UTC)
I agree that this template is a good way to make progress towards sorting out some of the confusion. I also agree with Gerry Ashton that kB/s (or kbit/s) is preferable to KB/s (or Kbit/s). However, I like Arch Dude's idea of a user preference even better. Do we have the tools to implement his suggestion? Thunderbird2 ( talk) 01:03, 13 July 2008 (UTC)
Since some disciplines use units not approved by the BIPM, or may format them in a way that differs from BIPM-prescribed format, when such units are normally used by a clear majority of relevant sources articles related to those disciplines should reflect this (e.g., using cc in automotive articles and not cm3). Such use of non-standard units are always linked on first use.
It was also agreed that IEC prefixes, while not ambiguous, had seen little real-world adoption and were therefore unfamiliar to the typical reader.
Kbps
[uppercase as it started a sentence] transfer rate = kilobit per second transfer rate. There are 8 bits in a byte, so we would divide kbps by 8 to get KB/sec transfer rate.
”Kilobit = 1000 bits per second
”As far as I'm aware, Kbit/s,kbit/s, kbps, Kbsp etc.. all refer to decimal kilobits per second and no one uses them in binary meanings. Headbomb { ταλκ – WP Physics: PotW} 20:42, 14 July 2008 (UTC)
I disagree. The correct symbol for 1000 bits per second is kbit/s. That is what we should use. Thunderbird2 ( talk) 05:17, 15 July 2008 (UTC)
Since some disciplines use units not approved by the BIPM, or may format them in a way that differs from BIPM-prescribed format, when such units are normally used by a clear majority of relevant sources articles related to those disciplines should reflect this (e.g., using cc in automotive articles and not cm3). Such use of non-standard units are always linked on first use.
I agree with you that kbit/s solves the potential ambiguity of bit/byte confusion, but—tempting as it is—that is not our roll here to figure out a better way to a brighter future.
The only relevant point is whether or not there is a clear industry-wide practice observed by a clear majority of sources. And most are using a lowercase k followed by “bps” and a few are using an uppercase K followed by “bps”. Thus, the use of “…bps” instead of “…bit/s” (as in “Mbps” and “kbps”) is standard and is to be used here.
Much of your above argument Gerry, is centered around the theory that “there is a better way so we should go with that”. MOSNUM guidelines are clear that this line of reasoning doesn’t matter. We’ve got to get beyond this notion that we are leading the way and are somehow making a difference; that has been proven false with the IEC prefixes. All we do is confuse readers. You know that kbit/s is the exact same thing as kbps. Many readers won’t find that equivalency so easy to discern. To them, they appear much different. The industry’s methods for communicating these values is clear and our job is to follow those practices as best we can. Greg L ( talk) 00:04, 16 July 2008 (UTC)
Greg L: the idiom is that clear majority means more than a bare majority; it means a substantial, convincing mandate. Fifty percent plus one is not a clear majority. Why are you so anxious to make it as easy as possible to introduce ambiguity and confusion to Wikipedia? I deny that a clear consensus exists for any symbol; there is kbps, Kbps, kbit/s, kb/s, and just k. In the absense of a proven clear consenus, use the standard unit. (The burden of proof lies on those who wish to perpetuate non-standard symbols.) -- Gerry Ashton ( talk) 01:01, 16 July 2008 (UTC)
As for your statement “I deny that a clear consensus exists for any symbol”, well, just because you deny reality doesn’t mean it doesn’t exist. The only question here is whether my sample of all the speed-checking sites I know of (all in 100% harmony I might add—even with Comcast thrown into the mix) is truly representative of the industry. I’ve long had all the above speed checking sites booklinked for speed tests (not for proving a point regarding which unit of measure they use). I didn’t know what symbol they used for “1000 bits per second” in advance of this discussion thread. If you want to prove me wrong, go find at least five speed-checking sites that don’t use kbps or Kbps. Short of that, merely stating that you deny the simple facts is about as useful to making your case here as pulling a trash can over your head, banging on it, and yelling “I can’t hear you!” Whether or not you find the current guideline inconvenient or not, it is our current guideline, it was put there for a good reason, and it does need to be heeded.
As to your question of why would I want “to introduce ambiguity and confusion to Wikipedia”, I just don’t understand your inability or refusal to see the important principle here: using units of measure that make “perfect sense” to mathematicians at the BIPM, but which are unfamiliar to readers introduces its own “ambiguity”. Whereas it may be blindingly obvious to you that kbit/s and kbps are equivalent, this is not at all true for very many readers. Let’s not do a re-hash of the entire three-year-long IEC prefix argument shall we? That ship has sailed and the current guideline—which was well considered and thoroughly discussed and debated—is the product of all that. Whether you agree that it is wise, it was the consensus view of many, many editors who labored for three straight months that it is wise policy.
Again, all these sites…
"
k | M | G | line total | |
---|---|---|---|---|
bps | 110 | 12 | 6 | 128 |
bit/s | 8 | 7 | 7 | 22 |
b/s | 13 | 38 | 1 | 52 |
Search entry | Hits |
---|---|
Megabit per second | |
"Mbps" +"megabit per second" -"megabyte per second" -"wikipedia" | 7,260 |
"Mb/s" +"megabit per second" -"megabyte per second" -"wikipedia" | 1,580 |
"Mbit/s" +"megabit per second" -"megabyte per second" -"wikipedia" | 813 |
Megabyte per second | |
"MBps" +"megabyte per second" -"megabit per second" -"wikipedia" | 831 |
"MB/s" +"megabyte per second" -"megabit per second" -"wikipedia" | 610 |
Kilobit per second | |
"kbps" +"kilobit per second" -"kilobyte per second" -"wikipedia" | 2,640 |
"kbit/s" +"kilobit per second" -"kilobyte per second" -"wikipedia" | 397 |
"kb/s" +"kilobit per second" -"kilobyte per second" -"wikipedia" | 648 |
Kilobyte per second | |
"kBps" +"kilobyte per second" -"kilobit per second" -"wikipedia" | 1,760 |
"kB/s" +"kilobyte per second" -"kilobit per second" -"wikipedia" | 1,140 |
The article Address space layout randomization contains the statement
Footnote [2] reads (verbatim):
I find the footnote far too complicated and confusing (notice that it doesn't even mention stacks - whatever they are), when all it needs to say is: 1 KB = 1024 B; 1 MB = 1024 KB. I withdraw my support for the footnote in its present form. Thunderbird2 ( talk) 21:16, 3 August 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 103 | Archive 104 | Archive 105 | Archive 106 | Archive 107 | → | Archive 110 |
The documentation for Template:Cite book (and I imagine most of the other cite tempates) conflictes with the recommendation in WP:MOSNUM#Full date formatting. This guideline states:
The Cite book tempate, on the other hand, specifies that dates be given in ISO format (e.g. 1776-07-04). There is no parameter to inform the Cite template what format is being used in an article, so there is no possibility that the template could reformat the supplied date to the correct format for the article. -- Gerry Ashton ( talk) 18:39, 1 July 2008 (UTC)
This issue also applies to Template:Cite web. It links to solitary months. See the reference section of: Atlanta Falcons seasons. Many templates are responsible for overlinking of dates and common units of measurement. Lightmouse ( talk) 15:54, 3 July 2008 (UTC)
... this time in relation to stub templates. I think these are clearly meta-data, and they have their own guidelines (at WP:STUB), so I'm highly dubious that article-content style considerations apply, certainly that they would apply unchanged. Please comment here. Alai ( talk) 13:24, 5 July 2008 (UTC)
Moved from Lightmouse talk page
Stub templates:
Why would you be removing these? Bear in mind they're not article text, they're scoping statements: delinkifying them seems extremely odd.
Alai (
talk)
00:40, 5 July 2008 (UTC)
I'm not arguing from construction, I'm arguing from function. If a template is included into the body of the article, and functions as a part of the article text, then certainly MoS considerations apply. But stub templates are clearly not that, but meta-data for editorial purposes. I'll drop a line at the MoS page to refer people to the discussion I started at WPSS. Alai ( talk) 13:19, 5 July 2008 (UTC)
Infoboxes:
Since it apparent that you're 'bot is operating without human oversight and removing inks where they are acceptable exceptions, please see what you can do to fix the problem.
Example:
The first change is within the infobox for the article. This is a use that is an acceptable exception within the WP:MOSLINK#Dates guideline.
- J Greb ( talk) 14:50, 6 July 2008 (UTC)
Moved from
Wikipedia talk:Manual of Style (links): begin
In the section on
Intuitiveness it reads: "Years should not be linked to articles, such as
2003 in music or
1985 in film, especially when part of a date." What is meant here? Are these pages not to be linked to or what? __
meco (
talk)
11:36, 7 March 2008 (UTC)
I'm with Emperor. I think it depends on context, and there can be no hard rule. There will be places where
1990 will more properly contextualize the statement in which it appears, and there will be times where
1990 in comics will, but, as Emperor points out above, there is virtually no reason for a clunker like "1990 in comics" to appear in anyone's prose. I have faith that our readers are not so slow they will be befuddled by the piped link.
Ford MF (
talk)
14:34, 4 July 2008 (UTC)
Moved from
Wikipedia talk:Manual of Style (links): end
I have taken the liberty of moving this topic here because of the cross-over with discussions here and this is the more active of the two pages. I hope nobody minds. Lightmouse ( talk) 23:06, 4 July 2008 (UTC)
[[2003 in music]]
might be clunky for a given context and the following might be preferred by an editor: …and Shania Twain’s ''[[Up! (album)|Up!]]'' album reached No. 4 on Billboard, which was one of the more notable [[2003 in music|music milestones of 2003]]
. This code produces the following piped link: …and Shania Twain’s Up! album reached No. 4 on Billboard, which was one of the more notable music milestones of 2003.
In a nutshell: If you want your links to be clicked on, you don’t want to inadvertently dress them up as something many readers assume/fear is something entirely else.
And no, an editor is not properly addressing the issue of “principle of least astonishment” by assuming that readers will pause their cursor over a link to see the pop-up title of the link. Most readers don’t bother because a properly designed Wikipedia page doesn’t require it. Greg L ( talk) 19:26, 5 July 2008 (UTC)
…Shania Twain’s album Up! ( 2003) reached No. 4 on Billboard.
The 2008 movie Wanted was based (loosely) on the 6-issue 2003- 2004 comic book miniseries of the same name by Mark Millar and J. G. Jones.
Powers is an American comic book series by Brian Michael Bendis (writer) and Michael Avon Oeming (artist), originally published by Image Comics ( 2000 to 2004).
This diff recently deleted the bit in WP:DATE#Dates of birth and death which said that locations of birth and death shouldn't go in the parenthesis with the dates. Has this been discussed anywhere, or is it (as I suspect) one editor's personal point of view? cheers, Struway2 ( talk) 16:17, 9 July 2008 (UTC)
I started a discussion on numbers as figures and words at WT:MOS#Comparable quantities. Until we decide where the detailed coverage of this issue is going to be, it is predictable that it will be discussed in both places. Septentrionalis PMAnderson 02:35, 8 July 2008 (UTC)
The draft is done; to the best of my ability, I have omitted nothing, and changed no guidance; this may, however, be more memorable. I would add
Septentrionalis PMAnderson 18:54, 10 July 2008 (UTC)
I'm not sure I believe this article, but even if the accusative were the unit, its plural would be annos, not anna; and there should only be one value of it. Septentrionalis PMAnderson 22:09, 10 July 2008 (UTC)
I'm not latin speaker, but my understanding of this [2] suggests to me that annum is a nominative of -um form, meaning that the plural is anna. Headbomb { ταλκ – WP Physics: PotW} 13:20, 11 July 2008 (UTC)
The MOS here states in the date autoformatting section The year should be wikilinked separate from the date except for dates in ISO 8601 format, which is correct as entries like [[April 21, 2005]] don't produce a wikilinked date. However, such a link goes to a valid article ( April 21, 2005), so if I come across a link to [[April 21, 2005]] under the MOS it would seem correct to change it to [[April 21]], [[2005]], but that could be an aricle link. An apparrent inconsistency. Help! Rjwilmsi 08:23, 12 July 2008 (UTC)
Please tell your bot to stop doing this. De-linking years screws up "what links here" for our year pages, breaking an important, handy, research tool for our readers. -- Kendrick7 talk 16:02, 5 July 2008 (UTC)
I agree too. Hervegirod ( talk) 22:27, 5 July 2008 (UTC)
I agree. OMG, these people have let the cat out of the bag! Tony (talk) 03:30, 6 July 2008 (UTC)
I see that as a pretty reasonable proposition, Aervanath. But there are simply so many year links to trivia in so many articles, it seems much easier to let the bot remove them all and simply restore the small percentage that are truly germane to the article. For instance, in Kilogram, I had “On 7 April 1795, the gram was decreed in France to be equal…” and someone linked the date and year. There are simply too few readers who are researching the kilogram who will want to explore the “fascinating” events that occurred on 1795, such as “ January 19 - The Batavian Republic is proclaimed.” Now if there is an article about the War of 1812, the readers going there are naturally interested in historical topics and some year linking (and range linking and decade linking) makes sense. Maybe the bot can be tuned to cut historical articles some slack. If not, it should be easy enough to restore some of them. In the mean time, there must be thousands of articles that need to be de-linked, and that’s simply too gargantuan of a task for anything but a bot. Greg L ( talk) 06:38, 6 July 2008 (UTC)
I think Greg has a valid point here. It makes sense to link years and dates on historical articles. For instance, Lightbot has recently delinked all dates from the intro section to Trajan, but these are important dates, concerning historical turning points in the Roman Empire (wars, assassinations, accessions, etc...). Lightbot seems to behave quite inconsistently too. Some dates are delinked, others are left alone. -- Steerpike ( talk) 11:55, 6 July 2008 (UTC)
I just made a few corrections, but most of the dates in this section do not conform with WP:DASH:
On this page, date elements that have spaces are incorrectly joined with unspaced endashes. No wonder I deal with constant fixes and confusion at FAC; most of the examples on this page are wrong. SandyGeorgia ( Talk) 08:32, 12 July 2008 (UTC)
Yesterday, I attempted to solve a massive overlinking issue with List_of_Final_Fantasy_compilation_albums, a new nomination at WP:FLC, by removing all of the autoformatting. No one minds US date formatting, even if it requires a comma, just as they accept Euro formatting after their signature.
I was delighted that nominator PresN responded at the FLC page: "Well, can't say I'm sad to see the sea of blue leave. It's much easier to read now, thank you."
You may wish to compare the previous autoformatted version with the new, normal script version. Scrolling down side by side is best, but the difference is clear by comparing one after the other, too. Tony (talk) 04:16, 2 July 2008 (UTC)
If we’re going to have an autoformatting (with no linking to trivia) function for dates, it should be an I.P.-sensitive one that simply looks to the country the reader hails from. This is a common tool on the Internet and is routinely used to gather statistics of any given Web site’s visitors. The MOSNUM guideline would then say that for articles about a particular country, the dates would be in fixed text in the format typically used in that country. But for articles of a general nature, the dates could use an I.P.-sensitive autoformatting template. But, actually, I’m convinced most readers don’t give a darn about the formatting of dates. I’ve long used the Euro format (and I’m an American) in my general-interest articles (those not tied to a particular country), and haven’t had a single reader ever edit a date to Americanize it.
Frankly, if there was going to be an I.P.-sensitive function created that could be used in magic words and templates, I’d just as soon see it used so {{dialect|color|colour}}
would be read as “color” in the U.S., and as “colour” in England/Australia/etc. It wouldn’t have to be “smart” at all. Simply by looking to the readers’ I.P. address, {{dialect|trunk|boot}}
would be read as “the border patrol agents discovered the bomb upon opening the trunk” for Americans, and as “the border patrol agents discovered the bomb upon opening the boot” for others. Now that, would be something I’d really like.
Greg L (
talk)
13:54, 3 July 2008 (UTC)
January 1, 2008
and shouldn’t be pretending we’re doing any good with
{{cite web}} and [[1 January]] [[2008]]. We shouldn’t bother with any tool that only benefits us registered editors. Why?Because when registered American editors see “January 1, 2008” and European registered editors see “1 January 2008”, we editors—especially the European ones who are content with the dates they see—are going to loose track that most everyone else in Europe sees American-style dates. I’m American but can imagine that in an article like French Revolution, an English-speaking European reader (there are many) would find “June 10, 1789” just as awkward as would an American seeing “4 July”. Further, new editors who aren’t highly familiar with the idiosyncrasies of these tools will simply copy them from other articles without being aware of their limitations.
Again: If we’re going to be autoformatting dates, make it work for regular readers or forget it. Otherwise we’re just all patting ourselves on the back by making tools that only we can enjoy, as if we registered editors are privileged Eloi and most every regular reader is just a subterranean Morlock.
And, of course, loose the damned links to trivia for all but the most topical and relevant circumstances in historical articles. Greg L ( talk) 23:26, 4 July 2008 (UTC)
Per footnote 2 on Wikipedia:Only make links that are relevant to the context, it is being stated that some metric units are considered common measurements. Also related to this is the statement in this document that, "Articles on scientific topics where there is consensus among the contributors not to convert the metric units, in which case the first occurrence of each unit should be linked." I'd like to point out that in the U.S., metric units are most certainly not common. In fact I've seen messages from some U.S. readers who don't have a clue about the metric system. Thus I don't think it is especially beneficial for Lightbot to be removing wikilinks of metric units from scientific articles, as some readers may not be able to relate well to "m" or "km" as units without a link to go read up on the subject. Is there some way these policies can be rectified in a manner that is more beneficial to our readership? Thank you.— RJH ( talk) 15:23, 7 July 2008 (UTC)
How about this sort of a step-back-and-look-at-the-whole-picture. If SI units are unfamiliar, ought we not be providing conversions to imperial/US units? If there are such conversions, those unfamiliar with the primary units can ignor them and look at the conversion. If the units being used have no particular connexion to the topic at hand, what worth is there in linking them? Should we therefore not bring into question this notion of allowing metric units to go unconverted in "scientific" contexts (... and how exactly do we draw that line?). WP:OVERLINK does recommend (and wisely, in my view) not linking common units of measure (I wouldn't count any deci~ units amongst these, even decibel would be worth linking). Something's got to give. JIMp talk· cont 02:02, 8 July 2008 (UTC)
If there are disciplines where there really is common use of a non-SI unit, such as cubic inches of displacement for auto engines, then sure, we should provide the conversion. And the reasoning is simple: because there really are readers who really think that way, so the conversion is helpful. I’m about as pro-SI as they come. But I also hate cluttering up articles with conversions for the sake of providing a conversion. For instance, closely examine Thermodynamic temperature. Spend a good couple of minutes looking it over. I wrote much of that. It would become one big eyesore if we just didn’t stick with joules, kelvins, J/K, °C, etc. It clearly doesn’t look like a suitable candidate for being hit with a 12-gauge shotgun of conversions. Let’s think though why it appears so. Well, it meets the first test: the original science is always done in SI with no conversions. And it also even meets a second test, which alone should exempt it: the basic measures are abstract enough to not have any real connection to American brains, which think in U.S. customary units. It does no one any good whatsoever to know that the Boltzmann constant, kB = 1.3806504(24)×10−23 J/K is equivalent to 7.270023(13)×10−27 BTU/°R. Does the latter mean anything to anyone? Certainly not.
So I would advance the following rule to be considered:
In disciplines and fields where Americans {we might as well not beat around the bush here} routinely think of measures in U.S. customary terms and the value is expressed in SI units, provide a parenthetical conversion to U.S. customary where appropriate. Do not provide conversions in articles on scientific disciplines when current literature on that topic is always in SI units. And do not provide conversions where the measures are abstract (because either the values are very large or small, or because the measure is intrinsically arcane in nature). In deciding whether or not to add a parenthetical conversion, the basic question editors should ask themselves is “do readers exist who really think this way so a conversion would truly be helpful?” If the answer is “yes”, then it should generally be true that there currently is, or recently once was, a significant amount of U.S. literature using those non-SI units of measure.
←outdent
sounds reasonable enough ...
JIMp
talk·
cont
04:02, 8 July 2008 (UTC)
Which is already covered by the MOSNUM... Headbomb { ταλκ – WP Physics: PotW} 04:07, 8 July 2008 (UTC)
Here are some points to think about:
I happen to think that the current guidance at wp:context is fine as it is. It could perhaps contain an additional comment that the presence of a conversion usually eliminates the requirement for a link. Lightmouse ( talk) 23:13, 8 July 2008 (UTC)
Can we at least agree about conversions. Where a unit is part of a conversion e.g. '6 foot (1.8 m)', the link is not needed to support conversion. A huge number of links to common units are part of conversions. Lightmouse ( talk) 22:19, 9 July 2008 (UTC)
Note that even a broad, blanket rule for a bot which allows the first instances of units of measure to be linked and then delinks the rest isn’t necessarily a “fits-all”, universal solution that works in all articles. Sometimes, in my articles, I repeat a link if the first link was up in the overview and the second link is further down in a much different or more detailed context. I don’t know if I ever bothered doing this with a unit of measure, but I do know I make links only for good reason and try hard not to overlink. I’m really not seeing where authors’ linking the first instance or two of units of measures—even in conversions—is such an egregious case of over-linking that bots need to be let loose to solve Wikipedia’s problems.
Some bots, like spelling-correction bots, are uncontroversial and it is a no-brainer to let them loose. Letting a bot loose to de-link damned dates ( October 16), while somewhat more controversial, is a sound technical writing objective to 1) get away from the blue turd of “link-itis” and 2) avoid desensitizing readers to links that are nothing more than easter egg hunts that only take them to non-relevant lists of trivia. De-linking years is more of a grey area because intrinsically historical articles might conceivably use them to good effect. But I support the bot because there are simply so many unsuitable date/year links, it is easier to let the bot do all the dirty work and hand-restore those that are suitable.
But this “units” bot needs to be discussed more. I’m sorta thinking aloud here, but maybe it would be OK if there was a bot that delinks units of measure that are linked more than twice in an article, or more than once if the second one is too close. And, yeah, I’m thinking that parenthetical conversions can have their units delinked too. But if there is a bot that is delinking units of measure on the false presumption that certain metric units are “universally common,” that needs to be stopped at once. If we can’t properly self-regulate our use of bots to ensure that what they accomplish is generally well-accepted in the authoring community, onerous hurdles to employing them can get imposed on us. Greg L ( talk) 23:47, 9 July 2008 (UTC)
As far as I know, bots can only apply per-page rules and can't count instances within a page. I did a quick survey and found that about 50% of links to common units of measure have conversions e.g. Blue Streak missile, Carnivora, Ethan Allen, Greenpeace. Linking common units of measure in conversions seems to be one of those things that people just do because they can. It seems bizarre to me. Lightmouse ( talk) 09:11, 10 July 2008 (UTC)
The United States would develop an Intercontinental ballistic missile (ICBM) of 5,000 nautical mile (9,300 km) range, while the United Kingdom…
Having said all that, I am beginning to drill down better into the nuances of this. It appears to me that in this expression (also a paradigm example, from Carnivora):
“11 cm (4.3 in)”
So I think RJH’s 15:23, 7 July 2008 post that started this thread hit the entire issue precisely on the head. I couldn’t have said it better and believe he is 100% correct. Greg L ( talk) 17:20, 10 July 2008 (UTC)
There is no delinking bot. I think that we are much in agreement here. Remember, the issue is only related to common units in either system. You will see lots of examples like the ones I gave. To be specific, I meant:
About 50% of links are like that. —Preceding unsigned comment added by Lightmouse ( talk • contribs)
I agree with you. It got messy. Let us take things step by step. There is a bot that does date delinking. Whilst it is in an article it does many supplementary tasks including but not limited to:
It also delinked common units in accordance with wp:context. On the basis of strong feelings expressed here, the scope was further confined to *common units in conversions*. On the basis of further strong feelings expressed here, even that was stopped. I hope that calms things down a bit. [I think that would. Thanks. Greg L ( talk) 21:53, 10 July 2008 (UTC)
I know that the example articles contain several units. Can we address the issue of *common units inside conversions*. There are many examples but here are just four:
Regards Lightmouse ( talk) 21:48, 10 July 2008 (UTC)
Allow me to address the latter point first. The vast majority of what the bot is doing could be considered as “housekeeping,” which is pretty much uncontroversial. As such, I trust your judgement on these housekeeping chores. And I am really, really pleased that (you?) have invested so much of your volunteer efforts into it. Wikipedia is much better off. I wouldn’t ever want to make it so a task that you’ve undertaken as an enjoyable hobby becomes nothing but drudgery and conflict; you’d simply take a ‘screw you’ attitude (I wouldn’t blame you) and go and find something else to do on Wikipedia. Wikipedia would be worse off for it too. I do submit, however, that issues like de-linking common units of measure inside of parenthetical conversions isn’t clear-as-glass, “uncontroversial housekeeping” and is treading a tad close to content editing. So too was date delinking, but the consensus view of our best editors was that it is a good thing. On these sort of grey areas, I suggest you discreetly solicit input first, rather than after-the-fact. Maybe there are some trusted editors you can e-mail.
As to your first point (delinking *common units inside conversions*), I see your point. The logic for de-linking common units in parenthetical conversions—both metric and U.S. customary—is a bit convoluted to go into here, but as long as it’s a parenthetical conversion and is a common unit, whether it’s metric or not, there really would never be any practical value to having it linked. I haven’t studied this issue very well and can imagine there might be unforeseen ramifications for wadding into this one. I also don’t really see much harm in leaving these things alone because the principle of least astonishment isn’t violated with these links (and they’re usually small); I know precisely what article I’d end up on if I clicked on it (so I never do). So I would recommend we get the input of several more editors here (which is no doubt what you had in mind). An alternative objective to consider would be to de-link after the first occurrence of common units in parenthetical conversions. Greg L ( talk) 22:26, 10 July 2008 (UTC)
P.S. I suppose, taking my “convoluted” (but undisclosed) logic to its logical conclusion, there would be no point linking the primary common unit (metric or U.S. customary) that is accompanied by a parenthetical conversion. That’s separate from the issue of whether it is wise to even attempt to address this issue with a bot. Greg L ( talk) 22:43, 10 July 2008 (UTC)
Thanks, it can sometimes seem that I could have an easier life if I just copy edited a few articles. Yes, let us hear from other editors. I think we are on similar lines here. I think:
should be simply
Regards Lightmouse ( talk) 22:50, 10 July 2008 (UTC)
Have you read the examples given at wp:context? Lightmouse ( talk) 09:21, 11 July 2008 (UTC)
But the more I think about it, I think it is unwise to delink the first occurrences of these. If an American sees “6 feet (1.8 m)” and doesn’t know that “m” is the symbol for meter (which the American may or may not be familiar with even by name), they should be able to click on the linked symbol (m) and see what the hell that means. If we were going to unlink anything, we would do as Tony suggested above: de-link the “foot” “since no one else needs to know about them.” The issue we’re trying to address is concerns over overlinking in articles—some of them have had people go ape-shit with links. But I just don’t see the disadvantages as being all that onerous of putting up with just a first occurrence link in an article. These links to units of measure and their unit symbols are small and don’t violate the principle of least astonishment whatsoever (unlike “She was crowned June 2”). Readers either recognize what they are and don’t click on them, or they are don’t recognize the unit or unit symbol and do choose to click on them.
I propose that if the bot is to do Wikipedia an unquestionable good service, that it simply hunt down and delink the 2nd+ occurrences of common units of measure that are accompanied by a parenthetical conversion. That’s a number of tests: 1) is the unit of measure “common”; that is, is either centimeter/inches or meters/feet (but not their squares and cubes), or kilograms/pounds, or °C/°F, and kilometers/miles? 2) is it accompanied by a parenthetical conversion? 3) Is it linked? 4) Is there already another instance earlier in the article that is linked? If the answer to these four questions is ‘yes,’ then the bot delinks both sides. Now I see that as doing some good: getting rid of multiple linked units in conversions that repeat and repeat in articles. Greg L ( talk) 19:18, 11 July 2008 (UTC)
P.S. Given how benign this bot would be in this regard, we might even consider delinking the 2nd+ occurrences even if they’re not “common”—so long as they are a parenthetical conversion. This is quite distinct from the 2nd+ occurrences of linked units of measure that are not parenthetical conversions. Sometimes I link units of measure or terms more than once if the first occurs early in an article—in the overview for instance—and another instance is way further down in the article in a more detailed or much different context. Greg L ( talk) 19:28, 11 July 2008 (UTC)
When a bot finds a page where there are multiple instances of the very same measure and parenthetical conversion, and further, the unit of the measure is a common, well-recognized one, can there possibly be any harm in letting the bot simply de-link only the redundant instances? For instance, if the article mentions “6 feet (1.8 m)”, could there possibly in any harm in de-linking the next instance, which might read “14.5 feet (4.4 m)”? And the next one, which might read “3.5 feet (1.1 m)”? With the bot so highly limited on this very specific issue, I’m in agreement with Lightmouse; I’m just not seeing where having the units linked again and again adds anything to an article whatsoever and can see that it amounts to simple massive clutter-itis with links. Is there a legitimate reason for linking again and again in conversions that I can’t think of? Greg L ( talk) 22:52, 11 July 2008 (UTC)
Possible overlinking: I noticed that the unit symbol ‘km’ is mentioned eight times and three of those instances are linked. Unless some of these other links are in very different contexts in the article, you might consider linking only the first occurrence and leaving the rest unlinked.
The new date formatting convention is confusing editors at FAC (it seems to mostly be a situation where it's not being explained correctly). Since the citation templates don't work right, it's not possible for editors to be consistent within articles; asking them to delink dates when the citation templates can't be made to agree isn't working. Further, the instructions here aren't crystal clear (they are now a hybrid of old understanding of the old method plus new convention, with a disconnect inbetween) and there's no one section I can point to that editors will understand. I ended up having to spell it all out myself three times today after two editors delinked dates incorrectly (they delinked only partial dates, not understanding the intent of delinking): for example, see Wikipedia:Featured article candidates/United Airlines Flight 93. We need a clear explanation somewhere that users who didn't understand even the old method can digest. I spent hours delinking Samuel Johnson today, and with the inconsistent citation templates, I wonder if it was worth it. SandyGeorgia ( Talk) 07:06, 12 July 2008 (UTC)
The citation templates can and should be fixed. What we can't do is apply autoformatting to dates such as 11–14 May 1987. If we've got one od these in an article, then there should be no autoformatting at all. JIMp talk· cont 00:58, 14 July 2008 (UTC)
If an FA reviewer is rejecting an article because it links a couple of highly significant dates, or because it uses auto-formatting, or because the raw formats in footnotes are ISO not localised, then that reviewer is not acting in the spirit of FA or the spirit of MOS. Auto-formatting has not been conclusively deprecated, despite the smoke and noise. -- Hroðulf (or Hrothulf) ( Talk) 12:49, 15 July 2008 (UTC)
The section at Wikipedia:Manual of Style (dates and numbers)#Chronological items - "Longer periods" is misleading. All through wikipedia decades such as the 1960s are considered as beginning on 1 January 1960, 1950s on 1 January 1950, and so. The 1890s began in 1890 and ended in 1899: the next decade, century began the next day. In popular usage the 20th century began 1 January 1900 along with the new decade. The third millennium, 21st century, the "noughties" (first decade of the century) all began on 1 January 2000. The manual should reflect this usage. 62.64.205.30 ( talk) 17:27, 18 July 2008 (UTC)
Hello, in my moonbook I have an old script designed to format dates according to previous versions of MOSDATE. Question(s): Is there an upgrade avaliable anywhere to mirror the recent changes in MOSDATE? If not, is there a way to change my monobook script manually to reflect this? If neither option is avaliable, I think someone more monobook-inclined would be doing a great service if they could look at this to help keep articles MOS compliant. -- Jza84 | Talk 01:00, 19 July 2008 (UTC)
For as long as I can remember, I was told to follow the convention to link full dates (mm-dd-yyyy et al), and never to link mm-yyyy or lone years. Have conventions changed, or is this still universal, since I had trouble finding anything definitive in this MOS.-- 十 八 01:27, 19 July 2008 (UTC)
Coming to grips with this reality (that autoformatting is of no benefit whatsoever to the vast majority of visiting readers on Wikipedia) and therefore abandoning the practice, also reduces unnecessary link clutter because readers will no longer be tempted to click on Easter-egg links like “ August 8” while reading up on, for instance, a fusion experiment at a national lab. They will no longer be presented with a random list of historical events that amount to nothing more than trivia like “1220 - Sweden was defeated by Estonian tribes in the Battle of Lihula.” While each of these entries was significant and meant something to some contributing author somewhere on this planet, links to this sort of stuff—more often than not—have no particular relevance to the subject matter within the article; readers’ minds learn to start ignoring links as a result. Greg L ( talk) 18:57, 20 July 2008 (UTC)
This came up while reviewing this FA: the editor had used decimal feet in the article, for example "152.9 feet" instead of "152 ft 11 in". It was also discussed briefly at User_talk:Epbr123. The consensus seems to be that when using English units that do not customarily use decimal fractions that they should be avoided, but there's no MOS for this. I'd like to propose the following addition to the "Which units to use" section of this guide:
Or, perhaps some better version. Fractional pounds are sometimes seen in real life, but decimal fractions of feet seem off. Would anyone have any objections to this change? JRP ( talk) 03:41, 19 July 2008 (UTC)
Is linking complete dates a preference or a must? -- Efe ( talk) 04:07, 23 July 2008 (UTC)
I'm just piping up here to say that the fact that we are now allowed to delink full dates is going down very well on the ground (look at Tonys talk!) I delinked a bunch of my articles last night and it was very very satisying work. Personally I never use cite templates and I strongly believe they should be depriecated; but whatever, lets end date linking at all costs. ( Ceoil sláinte 15:41, 27 July 2008 (UTC)
MOSNUM's "Numbers as figures or words": Anderson is unilaterally trying to change the analogous text at the MoS main-page, as yet unsuccessfully.
I believe that his changes this month at MOSNUM to the traditional default boundary of nine/10 (with exceptions) are not based on consensus. This needs to be resolved on this talk page. Apart from all else, we now have unsuitable statements such as:
The reader should not be confused by the manner of expressing a quantity.
Gee, that helps. And his home-grown patronising statement—
Careful readers may object to the use of 100,000 troops as a rough description of a force of 103 thousand;...
Now Anderson's usual smoke-bomb, the dispute tag, has gone up at MOS main page. I call for discussion on how to harmonise both MOSNUM and MOS main-page texts in this area. I'm posting a note at MOS main-page talk with a link here. Tony (talk) 06:19, 24 July 2008 (UTC)
I do not find MOSNUM's "Numbers as figures or words" clear. I consulted it recently for an FAC article and did not see a rule regarding the nine/10 issue. Maybe I am blind. — Mattisse ( Talk) 18:21, 29 July 2008 (UTC)
MOSNUM currently says: "it is permissible to have imperial units as primary units in UK-related topics." Shouldn't that be Commonwealth as the units were used there as well? Or is there some reason to restrict their use on Wikipedia to just Great Britain and Northern Ireland? Caerwine Caer’s whines 21:43, 27 July 2008 (UTC)
* The intent of the guideline seems clear. So my bet is that “UK” was unintentionally used in place of the more appropriate—and broader—“Commonwealth”. Why shouldn’t an article about an Australian-related topics be able to use imperial units? I can think of no valid reason.
Greg L (
talk)
21:47, 27 July 2008 (UTC)
On 7 June 2008 a substantial change was made to WP:MOSNUM, including a virtual ban on the use of IEC units of computer storage such as the mebibyte. At that time, the views of editors arguing against the ban were not taken into account, despite an 11-0 majority against such deprecation only 2 months before that. As far as I know, no attempt was made to seek the views of those 11 editors, even though only 4 of them were involved in the discussions prior to the change in June. Nearly a month has passed since then and it may be time to reconsider whether it is wise for MOSNUM to include a statement for which there is little or no consensus.
A brief summary of events leading up to the change is discussed here. Details of the long discussion leading to the change can be found here. Two subsequent attempts to discuss this point were made by Omegatron and by Quilbert.
Below I list some arguments for and against deprecation.
After four straight months of intensive debate, this failed guideline was abandoned and Wikipedia was finally brought in line with real-world practices. What’s it been… a month since we finally put an end to it? Nothing has changed since that time except to put Wikipedia’s computer articles well on the path to using terminology and language that is familiar to readers. Really, the worse thing about the way Wikipedia used to be, was that Wikipedia didn’t even have project-wide consistency; only some articles used the IEC prefixes and this meant that the conventional terms like “megabyte” had one specific meaning in one article and an entirely different meaning in still other articles.
Do you really think you’re going to reverse this and make it so some (or all?) of Wikipedia’s articles once again use terminology that everyone here agreed weren’t even recognized by the typical Wikipedia reader? That is just so unfathomly unrealistic. Greg L ( talk) 20:19, 5 July 2008 (UTC)
Wikipedia is an encyclopedia, not an instrument for special interest groups (like IEC) to try to push the way they would like the world to work. We should reflect in the encyclopedia what the world is like, not what we think it should be. The reality is that kilobyte means 1024 bytes most of the time it's used. Many people who use computers (including much of the IT industry) have never heard of a kibibyte and don't use the term. We shouldn't be social engineering.
The standard's not established enough yet. I had never heard of these things before I came to Wikipedia.
I have little doubt that both lists are incomplete. Comments are invited, as well as new additions to either one. Thunderbird2 ( talk) 18:50, 5 July 2008 (UTC)
Certain proponents of the ban are acting like trolls and making a battleground for a war of attrition. Maybe it would be better not to justify their behavior, and resolve to not debate. The whole matter is subjective, the evidence is made up and prone to change, and the notion that something "should" be done is bullshit. This discussion is not necessarily working toward a logical conclusion. Furthermore, parties represented by single-use accounts are clearly not interested in the betterment of Wikipedia, but are simply average internet trolls. Considering the opposition argument to the ban is comparable to the backing, and clearly underhanded methods have been employed, why not just seek wp:arbitration to end the "debate" once and for all. Then, this terminology can be decided as all other, by free Wikipedians. Potatoswatter ( talk) 23:05, 5 July 2008 (UTC)
I'm not going to waste my time responding in detail to the incredibly biased statement of arguments above; they do not even attempt to fairly state the positions. I have been more or less following this issue for about a year now, and was not aware of the proposed rewrite of the MOSNUM nor of the "vote". Had I been aware, of the discussion, I would have opposed deprecating. I notice a number of folks opposed to the deprecation of IEC are also missing from this so-called consensus - a coincidence or manipulation? Looks like the latter to me! FWIW, IMO, 220 is in many ways worse than IEC prefixes. Most readers don't have a clue to these exponential disambiguations so any objection to IEC should equally apply to both! Those of us who can deal with exponents can also deal with IEC. IEC has the advantage of compactness and can be wiki linked for disambiguation for those who really care about meaning. I would much rather see:
which I think is a whole lot better than either:
To make a point, I didn't bother to calculate the number of bytes in a GiB, I can never remember binary prefix multipliers beyond 1 KiB :-)
I for one would like to see the deprecation of Binary IEC prefixes removed.
Tom94022 (
talk)
01:40, 6 July 2008 (UTC)
(*sound of crickets chirping*)
Nothing new is being said here these last few days. All this has been hashed through over and over and over and the issue keeps on coming up. We tried the IEC prefixes on Wikipedia for three years with nothing but bloody continuous bickering the entire time. And there was good reason for the bickering: the IEC prefixes were still not finding any real-world traction and were still unfamiliar to our readers. Just because the “loosing” side is dissatisfied with the outcome and keeps raising the same old arguments doesn’t mean we have to reopen the case. It’s closed. I am baffled that the proponents of the IEC prefixes would still be agitating to go back to the old policy, which has to be one of the least successful guidelines in all Wikipedia history.
If circumstances change as far as the real-world adoption of the IEC prefixes, I’m sure you’ll let us know. In the mean time, please exhibit the grace to accept with serenity the things that cannot be changed. I accept that you’ve certainly got the courage to change the things you think should be changed; I’m just beginning to question whether you’ve got the “wisdom” thing down when it comes differentiating between the two. Greg L ( talk) 23:22, 6 July 2008 (UTC)
Refusal to 'get the point'
In some cases, editors have perpetuated disputes by sticking to an allegation or viewpoint long after it has been discredited, repeating it almost without end, and refusing to acknowledge others' input or their own error. Often such editors are continuing to base future attacks and disruptive editing upon the erroneous statement to make a point.
Wikipedia is based upon collaborative good faith editing, and consensus. When a stance passes the point of reasonableness, and it becomes obvious that there is a willful refusal to 'get the point' despite the clear statement of policy, and despite reasoned opinions and comments provided by experienced, independent editors, administrators or mediators, then refusal to get the point is no longer a reasonable stance or policy-compliant - it has become a disruptive pattern, being used to make or illustrate a point.
Note that it is the disruptive editing itself, not the mere holding of the opinion, that is the problem.
(un-indent_
You seem obsessed that ‘there was this vote or that vote, or people did or didn’t change their minds’ and you seem to ignore our stated reasoning that if we did as you want, Wikipedia would be the only general-interest publication on the planet that uses the IEC prefixes. No other publication for general-interest readerships uses them. No computer manufacturers use them to communicate to their customer base; not in their advertising, owners manuals, or whatever. If the operating system of my computer or yours states file sizes, it’s in kilobytes. If general-interest computer magazines write of file sizes, they don’t use the IEC prefixes. All other professionally edited encyclopedias use the conventional prefixes. I wrote of all of this above. You conveniently ducked all that too. I wrote about how every single editor who was engaged in the discussion in late March agreed that—because of this military-strength non-use of the IEC prefixes— the word “mebibyte” (symbol MiB) is not widely recognized by the typical Wikipedia reader. None of these facts seem to deter you. You come across as “I want my IEC prefixes! I want my IEC prefixes! We had them for three years and I want them baaaaack!. Well… tough.
I, for one, won’t go one one inch further with you playing your games until you stop ducking these inconvenient truths and directly and properly address each and every one of these issues. What you’re asking violates the most basic of all technical writing principles: your asking that Wikipedia use terminology that is generally unrecognized by the vast majority of common folk interested in the subject of computing. WTF! What part of “sound technical writing practices” do you not understand? I don’t want to hear the same ol’ saw about how “the IEC prefixes have been anointed with holiness and goodliness by major standards organizations.” Like I said in my above post, it doesn’t matter if some obscure publications from standards bodies use the IEC prefixes if the average Joe has never even heard of the organization. We heard that argument and rejected it as insufficient to overcome the disadvantages inherent in their use.
Now, it’s your turn to acknowledge and address each of these points. Like Headbomb said, he never got a satisfactory answer out of either you or Thunderbird2 over the course of two months. Now get cracking and put up or shut up. Otherwise both you and Thunderbird2 are just wasting our time with circuitous babble that isn’t addressing the issue. Both of you will be ignored (and for damned good cause) if you keep up this game of yours. What we really need here is to create a special page ( WP:MOSNUM/IEC Prefixes:Waaaaaa ) with rubber-padded walls and the next time you two post something that amounts to nothing more than a big fat helping of WP:POINT, we’ll simply move it over there where you two can bounce off the walls. This thread is already destined to become the 14th “Binary” archive (smooth move). Moving this nonsense somewhere else will avoid having to create a 15th. Greg L ( talk) 16:24, 7 July 2008 (UTC)
10.1.3 IEC units should be banned except for direct, verbatim quotes, and articles discussing the units themselves
* Disagree Tom94022 (talk) 22:31, 28 March 2008 (UTC) * Disagree LeadSongDog (talk) 23:49, 28 March 2008 (UTC) * Disagree Dpbsmith (talk) 23:59, 28 March 2008 (UTC) * Disagree, proper use should be encouraged. Seraphimblade Talk to me 15:05, 29 March 2008 (UTC) * Disagree — Christoph Päper 16:41, 29 March 2008 (UTC) * Disagree SamBC(talk) 18:17, 27 March 2008 (UTC) * Disagree (partial solution) Greg L (my talk) 18:32, 27 March 2008 (UTC) * Disagree Thunderbird2 (talk) 18:41, 27 March 2008 (UTC) * Disagree Jeh (talk) 20:48, 27 March 2008 (UTC)
* Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC) *Agree DavidPaulHamilton (talk) 23:31, 1 April 2008 (UTC)strike the sock JIMp talk·cont 08:06, 6 June 2008 (UTC) * Disagree — Omegatron 05:49, 6 April 2008 (UTC)
I still find it amazing that a clear consensus as of March 30th can be diametrically reversed. I intend to invite those other missing editors to join the discussion. Tom94022 ( talk) 05:40, 7 July 2008 (UTC)
Had the situation been fairly presented, the status on 7 June 2008 could have been:
That is, 11 for and 10 against - some consensus. It might even be 10:10 since the against are explicit while Dfmlean is by implication! ( talk) 21:19, 7 July 2008 (UTC)
Alternatively, the status on 7 June 2008 could have been:
It is truly amazing that the deprecation advocates can claim consensus when their so-called consensus, that is, a "vote", is followed within a few lines on the talk page (and preceded by a few weeks in time) by clearly stated opposition, also a "vote", but somehow this "vote" doesn't count. And for all the harping otherwise, the reasons against deprecation have been clearly stated many time overs and have nothing contrary to WP:UNDUE or WP:CRYSTALBALL. I won't bother to again state them because I know Fnagatron will again, without basis or cause, denigrate, deny or dispute them. I will; however, add a disputed notation to the sub-paragraph of section 4.3.4.2 of WP:MOSSUM Tom94022 ( talk) 21:19, 7 July 2008 (UTC)
But before we do that, I challenge you to address each and every point above in my 16:24, 7 July 2008 (UTC) post. I don’t think any of us here have heard a satisfactory answer from you on this; only what Fnagaton calls “I don’t like it.” Greg L ( talk) 03:58, 8 July 2008 (UTC)
And speaking of "whining", I am tired of you trying to name-call and ridicule your opponents into silence. You've threatened to ignore us? Your privilege, of course, but if you do so, others will define a new consensus without you. Jeh ( talk) 04:46, 10 July 2008 (UTC)
It is clear from the above discussion that the deprecation does not have the widespread consensus it would need for it to stay, at least in its present form. The explicit deprecation would appear to have its roots in the following statement:
I for one do not support this - familiarity and unambiguity are both needed in an encyclopaedia. What do others feel? Thunderbird2 ( talk) 06:17, 8 July 2008 (UTC)
And please explain why you are smarter than all the professional, paid editors at Encyclopedia Britannica and World Book and PC World and Mac World and pretty much all other English-language publications on the planet that communicate to a general-interest audience.* They don’t use the IEC prefixes because it would be using terminology that is unfamiliar to their readers (and ours). You don’t seem to give a flying crap about that little detail. So please explain why you are so smart and all these other editors throughout the world are all so wrong that you’d have Wikipedia be all alone on this one.
And if you actually do have the chutzpah to tell us here that every one of these professional editors are so wrong and you have it alllllll figured out, I would be deeply interested in hearing about your journalism credentials and education. Because you come across as if you have insight and understanding on this issue that is at a plane of consciousness that I can’t even comprehend. Do you have an advanced journalism degree with a special emphasis on technical writing or something? I’m serious about this question. Or is it because the IEC prefixes are recommended by some standards organizations the average Joe has never even heard of? You must think that the editors at the other encyclopedias and magazines don’t know that. You’re going to ‘show them’, aren’t you? Greg L ( talk) 15:09, 8 July 2008 (UTC)
I think the decisions of print publications and other web sites are fine for them within their constraints. But it is entirely possible that Wikipedia knows better for Wikipedia than anyone not involved with Wikipedia. None of the publications you mentioned is a) a general-purpose encyclopedia that b) is on the web and c) so effectively uses in-line links to explain unfamiliar words and principles. In my opinion the genius of the IEC prefixes is that they look close enough to their decimal counterparts that the user who doesn't care about the difference doesn't need to understand them; they can read "MiB" as "MB" and remain no worse off than they were before. But if they want to know what it means, on WP they can click on the "MiB" wikilink and will thenceforth be informed.
Now it has often been claimed before (and no doubt will be again) that disambiguation and footnotes of the conventional prefixes will accomplish the same goal. The problem with that is that the conventional prefixes remain ambiguous and therefore require the reader to check the footnotes or understand the disambiguation on every usage. Whereas if IEC prefixes are used consistently, once they are understood by the user they never have to be explained again. I think that's a powerful advantage and I don't think there has been any sort of effective rebuttal to that point, other than the value judgement that familiarity is more important than accuracy and lack of ambiguity (a value judgement with which I of course disagree).
Finally: Greg, I will ask you once again: Please try to avoid name-calling, ridicule and dismissiveness in your replies. Really, it only makes you appear weak. Jeh ( talk) 06:17, 12 July 2008 (UTC)
I see only one editor defending the use of ambiguous units without disambiguation, so I propose rewording and simplifying the opening text from
to
Any objections? Thunderbird2 ( talk) 06:34, 9 July 2008 (UTC)
Well, we don’t agree with you and know that your logic and values on this issue are 110% faulty. We’re going to follow what the professional editors at Encyclopedia Britannica and World Book and PC World are doing, not you. Are you going to accept that or cop a big fat WP:POINT attitude until the Heat death of the universe? Because if you expect us to go along with what you are agitating for, I expect you to first prove how all the professional editors at these print encyclopedias are complete retards who shouldn’t be looked to for guidance on this matter and you’re some sort of Einstein who’s “got it all figured out”. Forgive my skepticism, but I’m not holding by breath for that one. Greg L ( talk) 17:47, 10 July 2008 (UTC)
Given the contention over proper style, the volume of text going into the disclaimer footnotes, and the number of articles in "need" of tagging, it would be a good idea to make a reusable and modifiable template to simplify maintenance of articles. Potatoswatter ( talk) 00:56, 10 July 2008 (UTC)
You know that's not a crazy idea at all. I'll write the drafts. Headbomb { ταλκ – WP Physics: PotW} 01:23, 10 July 2008 (UTC)
Here you go: {{ BDprefix}} (for Binary-Decimal Prefix) Headbomb { ταλκ – WP Physics: PotW} 01:54, 10 July 2008 (UTC)
After reading about this being changed (yet again) in the Signpost, I considered coming here to comment on the new methods of disambiguation called for in this guideline (IMO, the only one that makes any sense in this morning's version is to use footnotes). But after skimming through the above, I'm not going to touch this mess, and I doubt I'm the only one who takes one look at this and decides WP:IAR applies; please remember that any "consensus" here will probably be made up of only those people who can stand GB (GiB, 10243s of bytes, 230s of bytes, or 1,073,741,824s of bytes) of arguing. FWIW, I will not watch for any replies to this comment as this page is simply insane. Anomie ⚔ 13:29, 12 July 2008 (UTC)
Well, Anomie, do you feel better now after that little fourth-graders’ rant? Because that sort of argument doesn’t do much to sway opinion your way. Indeed, the guideline has been changed *again*! And now we’re actually using units of measure the rest of the planet uses (imagine that). The only trouble is that we’ve got all the intrusive disambiguations (so I agree with you on that point). Those “disambiguations” will eventually become less intrusive as editors gain experience and some users stop editing in order to disrupt Wikipedia to illustrate a point (“Look! Look how ugly all these disambiguations are now that I have to use the ambiguous conventional prefixes”). Greg L ( talk) 22:26, 12 July 2008 (UTC)
I have completed a request for cabal mediation here. Thunderbird2 ( talk) 16:49, 13 July 2008 (UTC)
Why don’t you actually answer this direct question: are you up to binding arbitration on whether the current policy was the product of a properly arrived at general consensus? Even if you are, I’m not up to all the heavy lifting necessary to go through with arbitration; it’s going to take a heavy dose of Headbomb’s efforts here, as well as Fnagaton’s. But I’m terribly interested in first hearing whether you, T-bird, are willing to abide by the ruling of an arbitration committee.
Note that the better solution, in my mind, would be for you to admit that the four-month-long debate/discuss/poll process that resulted in the current guideline should serve as a paradigm for how dispute resolution is conducted on Wikipedia and that the consensus that developed was fair and should be observed by all. You don’t think so? Ergo, binding arbitration. Greg L ( talk) 20:06, 13 July 2008 (UTC)
Please, just drop the issue. Headbomb { ταλκ – WP Physics: PotW} 22:13, 13 July 2008 (UTC)
Relevant discussion at | → Wikipedia talk:Manual of Style (dates and numbers)/Archive 105#Should MOSNUM continue to deprecate IEC prefixes? |
Normally you would use it between ref tags
Examples: <ref>{{BDprefix|p=B}}</ref> [1] <ref>{{BDprefix|p=D}}</ref> [2] <ref>{{BDprefix|p=F}}</ref> [3]
produces
Snazzy. Potatoswatter ( talk) 02:22, 10 July 2008 (UTC)
Ok, did that. (I wish it could be less wordy while still being correct.) The change shows up when I call the template but not in the documentation page? I thought the doc page was generated from the template? Jeh ( talk) 01:02, 13 July 2008 (UTC)
Google gives about 233,000,000 for colour verses about 1,150,000,000 for color but we allow the former. More relevant to this question, though, are the points made here, which are backed up by the fact that this British dictionary draws a blank on floppy disc. JIMp talk· cont 04:37, 10 July 2008 (UTC)
I agree that this template is a good way to make progress towards sorting out some of the confusion. I also agree with Gerry Ashton that kB/s (or kbit/s) is preferable to KB/s (or Kbit/s). However, I like Arch Dude's idea of a user preference even better. Do we have the tools to implement his suggestion? Thunderbird2 ( talk) 01:03, 13 July 2008 (UTC)
Since some disciplines use units not approved by the BIPM, or may format them in a way that differs from BIPM-prescribed format, when such units are normally used by a clear majority of relevant sources articles related to those disciplines should reflect this (e.g., using cc in automotive articles and not cm3). Such use of non-standard units are always linked on first use.
It was also agreed that IEC prefixes, while not ambiguous, had seen little real-world adoption and were therefore unfamiliar to the typical reader.
Kbps
[uppercase as it started a sentence] transfer rate = kilobit per second transfer rate. There are 8 bits in a byte, so we would divide kbps by 8 to get KB/sec transfer rate.
”Kilobit = 1000 bits per second
”As far as I'm aware, Kbit/s,kbit/s, kbps, Kbsp etc.. all refer to decimal kilobits per second and no one uses them in binary meanings. Headbomb { ταλκ – WP Physics: PotW} 20:42, 14 July 2008 (UTC)
I disagree. The correct symbol for 1000 bits per second is kbit/s. That is what we should use. Thunderbird2 ( talk) 05:17, 15 July 2008 (UTC)
Since some disciplines use units not approved by the BIPM, or may format them in a way that differs from BIPM-prescribed format, when such units are normally used by a clear majority of relevant sources articles related to those disciplines should reflect this (e.g., using cc in automotive articles and not cm3). Such use of non-standard units are always linked on first use.
I agree with you that kbit/s solves the potential ambiguity of bit/byte confusion, but—tempting as it is—that is not our roll here to figure out a better way to a brighter future.
The only relevant point is whether or not there is a clear industry-wide practice observed by a clear majority of sources. And most are using a lowercase k followed by “bps” and a few are using an uppercase K followed by “bps”. Thus, the use of “…bps” instead of “…bit/s” (as in “Mbps” and “kbps”) is standard and is to be used here.
Much of your above argument Gerry, is centered around the theory that “there is a better way so we should go with that”. MOSNUM guidelines are clear that this line of reasoning doesn’t matter. We’ve got to get beyond this notion that we are leading the way and are somehow making a difference; that has been proven false with the IEC prefixes. All we do is confuse readers. You know that kbit/s is the exact same thing as kbps. Many readers won’t find that equivalency so easy to discern. To them, they appear much different. The industry’s methods for communicating these values is clear and our job is to follow those practices as best we can. Greg L ( talk) 00:04, 16 July 2008 (UTC)
Greg L: the idiom is that clear majority means more than a bare majority; it means a substantial, convincing mandate. Fifty percent plus one is not a clear majority. Why are you so anxious to make it as easy as possible to introduce ambiguity and confusion to Wikipedia? I deny that a clear consensus exists for any symbol; there is kbps, Kbps, kbit/s, kb/s, and just k. In the absense of a proven clear consenus, use the standard unit. (The burden of proof lies on those who wish to perpetuate non-standard symbols.) -- Gerry Ashton ( talk) 01:01, 16 July 2008 (UTC)
As for your statement “I deny that a clear consensus exists for any symbol”, well, just because you deny reality doesn’t mean it doesn’t exist. The only question here is whether my sample of all the speed-checking sites I know of (all in 100% harmony I might add—even with Comcast thrown into the mix) is truly representative of the industry. I’ve long had all the above speed checking sites booklinked for speed tests (not for proving a point regarding which unit of measure they use). I didn’t know what symbol they used for “1000 bits per second” in advance of this discussion thread. If you want to prove me wrong, go find at least five speed-checking sites that don’t use kbps or Kbps. Short of that, merely stating that you deny the simple facts is about as useful to making your case here as pulling a trash can over your head, banging on it, and yelling “I can’t hear you!” Whether or not you find the current guideline inconvenient or not, it is our current guideline, it was put there for a good reason, and it does need to be heeded.
As to your question of why would I want “to introduce ambiguity and confusion to Wikipedia”, I just don’t understand your inability or refusal to see the important principle here: using units of measure that make “perfect sense” to mathematicians at the BIPM, but which are unfamiliar to readers introduces its own “ambiguity”. Whereas it may be blindingly obvious to you that kbit/s and kbps are equivalent, this is not at all true for very many readers. Let’s not do a re-hash of the entire three-year-long IEC prefix argument shall we? That ship has sailed and the current guideline—which was well considered and thoroughly discussed and debated—is the product of all that. Whether you agree that it is wise, it was the consensus view of many, many editors who labored for three straight months that it is wise policy.
Again, all these sites…
"
k | M | G | line total | |
---|---|---|---|---|
bps | 110 | 12 | 6 | 128 |
bit/s | 8 | 7 | 7 | 22 |
b/s | 13 | 38 | 1 | 52 |
Search entry | Hits |
---|---|
Megabit per second | |
"Mbps" +"megabit per second" -"megabyte per second" -"wikipedia" | 7,260 |
"Mb/s" +"megabit per second" -"megabyte per second" -"wikipedia" | 1,580 |
"Mbit/s" +"megabit per second" -"megabyte per second" -"wikipedia" | 813 |
Megabyte per second | |
"MBps" +"megabyte per second" -"megabit per second" -"wikipedia" | 831 |
"MB/s" +"megabyte per second" -"megabit per second" -"wikipedia" | 610 |
Kilobit per second | |
"kbps" +"kilobit per second" -"kilobyte per second" -"wikipedia" | 2,640 |
"kbit/s" +"kilobit per second" -"kilobyte per second" -"wikipedia" | 397 |
"kb/s" +"kilobit per second" -"kilobyte per second" -"wikipedia" | 648 |
Kilobyte per second | |
"kBps" +"kilobyte per second" -"kilobit per second" -"wikipedia" | 1,760 |
"kB/s" +"kilobyte per second" -"kilobit per second" -"wikipedia" | 1,140 |
The article Address space layout randomization contains the statement
Footnote [2] reads (verbatim):
I find the footnote far too complicated and confusing (notice that it doesn't even mention stacks - whatever they are), when all it needs to say is: 1 KB = 1024 B; 1 MB = 1024 KB. I withdraw my support for the footnote in its present form. Thunderbird2 ( talk) 21:16, 3 August 2008 (UTC)