Misplaced Pages

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

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

This is an old revision of this page, as edited by Hesperian (talk | contribs) at 12:41, 9 July 2007 (→Roman numerals: thanks folks). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Revision as of 12:41, 9 July 2007 by Hesperian (talk | contribs) (→Roman numerals: thanks folks)(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)
Archiving icon
Archives
General Binary prefixes Years and dates See also

Binary prefixes

editArchive
Binary prefix archives

Should MOS use MB or Mbyte

The Misplaced Pages campaign to "encourage the use of the IEC prefixes". is based on the assumption that the world will someday abide by the IEC 60027-2 / IEEE 1541 standard. A study of current reliable sources shows no significant movement to use these standards. Of the three defined styles for binary prefixes, the IEC prefixes are a distant third.

Some who are advocating for the IEC prefixes claim that accuracy is more important than "common usage." With their miniscule presence in reliable sources you need to totally ignore common usage to justify the IEC prefixes. Misplaced Pages should not be used as a soapbox the push these esoteric units on the readers.

A review of technical specifications and brochures of manufactures of computers, peripherals and components show universal use of KB, MB and GB to describe the capacity of disk storage and memory (RAM). The Western Digital Caviar SE16 has 500 GB of disk storage with a 16 MB cache (RAM buffer.)

A review of the general and technical press shows that MB (megabyte) is the most popular followed by Mbyte. The MiB (mebibyte) usage is very rare. The Kbyte, Mbyte, Gbyte is the traditional IEEE style and is still the most popular in IEEE magazines and journals. The IEEE Computer Society still uses this style. A few technical magazine publishers also use this style.

The IEEE Annals of the History of Computing deals with K as a kilobyte unit by referencing the first use to Kbyte. Here is a sample from a recent article. "Japanese memory chips first achieved a significant market share at the end of the LSI era, with the introduction of the 16K (16-Kbyte) DRAM generation."

The rest of the article just used K. "Still, it was not the 16K but rather the 64K generation that would determine world leadership in DRAM production."

Mollick, Ethan (July-Sept. 2006). "Establishing Moore's Law". Annals of the History of Computing, IEEE. 28 (3). IEEE Educational Activities Department: 62–75. {{cite journal}}: Check date values in: |date= (help)

Some of the IEC prefix advocates insisted on uniformity in all articles on Misplaced Pages. The truth is Misplaced Pages is not consistent and the American/British variant spelling is often given as an example. With binary units the choice is MB or Mbyte; the MiB spelling is used on an isolated remote island.

The IEC binary prefixes attempt to fix a minor problem that the world has learned to live with. Supporters of the IEC 60027-2 / IEEE 1541 standard hope that Misplaced Pages can be used to promote its acceptance. It is not the place of Misplaced Pages to "encourage the use of the IEC prefixes." Here is an example of another IEEE/IEC standard that did not achieve widespread usage. -- SWTPC6800 06:15, 27 May 2007 (UTC)

You'll have to forgive me, but I find it genuinely hilarious that you would begin this sort of monologue by admonishing others for using Misplaced Pages as a soapbox. Is there any particular point you are trying to get at? — Aluvus t/c 06:43, 27 May 2007 (UTC)
A talk page is an appropriate place to get on a soapbox to try to fix a problem. Forcing your uncommon views on Misplaced Pages main pages is prohibited by WP:SOAP. The point is that the IEC binary prefixes are rarely used in the real world. Misplaced Pages should not be used to fix this deficiency. -- SWTPC6800 16:19, 27 May 2007 (UTC)

Here is a proposal on a binary prefix style. A Misplaced Pages wordsmith can put it into correct form.

Misplaced Pages follows the common usage for binary units and does not have a preferred style. An article should use the units given in the reliable sources for the article. If multiple styles of units are in the sources, the article editors should select the predominate unit and use it consistently.

An article on the new DDR3 SDRAM may choose 512 MB or 4 GB while an article on the history of dynamic RAM may describe a memory as 4 K or 16 K. Readers could easily verify the facts in the reference sources cited. -- SWTPC6800 17:18, 27 May 2007 (UTC)

I don't believe that it is generally true that "Readers could easily verify the facts in the reference sources cited." If the source is printed material, the reader might not have easy access at all. If the source is another website, the site might have changed or moved or otherwise might not be accessible. Of course, footnotes might overcome much of this worry. Jɪmp 23:51, 27 May 2007 (UTC)
If the original sources (from around 1978) used 16K DRAM you could Google 16K DRAM and find the original documents or a similar one. If the Misplaced Pages style changes the units to 16 KiB, the Google search will turn up different set documents. (Mostly Misplaced Pages articles.) -- SWTPC6800 02:23, 28 May 2007 (UTC)
SWTPC6800's point about being consistent with the reliable sources relevant to a subject are very important. Misplaced Pages is an encyclopaedia and a reference work that is intended to be searchable. To be able to be found during the types of searches someone may do the articles must use the terms the user is expecting to use. What this means is that a user who has some old books about their 64 K or 64 KB computer will be doing searches using the terms used back in those days (64K or 64KB or KB or kilobyte etc) and the user would be expecting to find other articles. This argument is precisely why the article on American Football uses yards even though yards are not allowed under the metric standards. And yes this is a common usage argument but the common usage argument is stronger than any of the standards based arguments simply because elsewhere in the majority of Misplaced Pages the common usage argument is actually put into practice. For the avoidance of any doubt that is to say in the majority of articles in Misplaced Pages you do not see the encyclopaedia using minority seldom used terms (even if they have been invented by a "standards body") in preference to the commonly used terms. Again for the avoidance of doubt in the majority of Misplaced Pages articles you see common usage trump the use of terms that are seldom used. Those who support binary prefixes could try to argue that it is not "technically correct" but those arguments are entirely irrelevant since the majority of articles in Misplaced Pages show that not using binary prefixes is the right thing to do and is of a greater benefit to Misplaced Pages as a whole. Misplaced Pages articles are not about being "100% technically correct" because if that were the case those supporting binary prefixes must remove yards from the article on American Football or remove the furlong from Horse Racing, but they do not. The Misplaced Pages articles are about being accurate and relevant resources to the subjects they are related to and to be accurate and relevant resources the articles must use the terms found in the majority of reliable sources because it is those terms that are most likely to be used by users. The articles in Misplaced Pages therefore have to accurately reflect common usage. This same point, in different terms of course, was also mentioned by others in the Village Pump. Scroll down to the end of this section to see the Village Pump summary that supports this. Fnagaton 11:34, 28 May 2007 (UTC)
Using the example given by SWTPC6800 above I believe this text below reads slightly better. I propose this text below is added to the guideline:
  • Misplaced Pages follows common usage for binary units and does not have a preferred style. An article should use the units found in reliable sources relevant to the article. If multiple styles of units are used by relevant reliable sources the article editors should select the predominate unit and use it consistently.
In addition to the above proposal I also propose this text from the current guideline is removed "When in doubt, the best guideline is the one laid out in our style guide on national varieties of English: stay with established usage, and follow the lead of the first major contributor to the article." I propose the removal of this text because if in the future the majority of reliable sources do happen to change then the article text can change.
Fnagaton 11:57, 28 May 2007 (UTC)
I think that Fnagaton's wording above could be the entire style entry for binary prefixes. We should remove the promotional language endorsing the IEC standards. It is not Misplaced Pages's mission to prop up failing standards. Remember, the IEC prefix adoption and usage is in third or forth place in the reliable, published sources. The Kbyte, Mbyte and Gbyte units are far more popular in existing and new documents than the KiB, MiB and GiB units. There is no column in the table for this popular binary unit. -- SWTPC6800 17:20, 28 May 2007 (UTC)
I second Fnagaton's proposal, and SWTPC6800's comment. -- Shmget 22:11, 28 May 2007 (UTC)
Third. --Marty Goldberg 23:07, 28 May 2007 (UTC)
If you read current IEEE magazines and journals you can see they do not enforce the IEC 60027-2 / IEEE 1541 standard on their content. (Very little MiB, lots of Mbyte.) Why should Misplaced Pages compel this peculiar style when the sponsor doesn't? -- SWTPC6800 05:08, 29 May 2007 (UTC)
WP != IEEE. Just an observation. We could change all astronomy articles to refer to AU and other such literally "out of this world" units, if we wanted to keep step with journals like Science, but part of our "job" here is to traslate geekspeak into language that everyday people can understand. In the months and months of this "what this this standards group says vs. what that standards group says" debate I think at least some sight has been lost of this. — SMcCandlish ‹(-¿-)› 16:19, 29 May 2007 (UTC)
Gahhh... What a ridiculous nightmare. (Referring to the whole thing; people seem to be outdenting, so I'm just starting one-:-deep with a meta comment or two or twelve. I'd never seen MiB in my life until about maybe four years ago (and I'm a computer professional!), at which point I thought it was either a typo, or a foreignism (which, in a sense, it darned sure is). But "Mbyte"? Please. Yes, of course I've seen it before, but it looks ridiculous and is about as sensible as "the shop'ng center" or "my hous'" Or (an actually common, stupid example) "Jun. 2007". I don't care what standards body, with it collective head...<ahem> in the sand... is coming up with this stuff on their multi-martini lunches, but enough is enough. That's so barely close to not an actual abbreviation as to not even bother with.
This is a general-purpose, general-readership encyclopedia. It needs to use terms and symbols that non-engineers, and non-subscribers to $2500/yr standards documentation, will understand. "Everyone knows what '500–MB' means", basically. They don't really, in the deepesting sense and depending upon context, but that's what we are here for. If the difference between a MB as defined by some standards body to be divisible by 10, and a MB defined by others 1024K not 1000K, has no impact on an article, so what? When and where it does, explain it one way or another in the prose. Don't make our readers, many of whom may be poorly educated, technologically inexperienced, and/or non-native English speakers, have to try to contend with a (for some) obscure set of abbreviations, which are sometimes weren't even from English to begin with; the French have been setting ITU abbreviations for ages; unless you're French, WTF is "bis" supposed to mean?).
'bis' is latin for 'twice', 'again', used commonly in English as a prefix 'bi' (bipolar, bicarbonate,...) ... amusingly using latin contraction are not particularly a 'French' habit. English use 'i.e.' (id est - also latin, for 'that is') where French typically use 'c.-à-d.'. -- Shmget 19:25, 29 May 2007 (UTC)
Rather than argue about which designation is more proper, go with whatever symbolic representation people are seming to grasp, and treat it as symbolic, period, just like an ankh or whather. People can memorize things, but the averge WP reader is not going to actually learn the difference between "someone's idea of a 'megabyte', about which there's going to be a defintional fight", and the competiting idea. Nevermind subjecting them to third symbol, which looks more like a pretend-word written by a three-year-old.
I've been studiously avoiding taking a position on this for months (yes, I've been watchlisting that long; after my abortive overhaul attempt, on various matters of MOSNUM problems, in...Feb.? I think... I've just been reading, hoping this MB/MiB things would just sort itself out. Now its MB/MiB/MByte. What, are we on our way to the Battle of the Five Armies or something? Full circle: Everyone, even my 81-year-old grandmother (I'm not exaggerating at all) knows what "MB" means (linguistically; she has no idea what a megabyte really is; she thinks it means that the computer is very large and heavy); but she can at least read it aloud. As much as I really, really hate the fact that the hard drive instrustry has been abusing the ambiguity to bilk people of out money for years for disks quite considerably less capacitious than they were expecting, that is not Misplaced Pages's fight. I'm quite keen on a article when it has to differentiating between KB and KiB and noting that KB in many contexts is ambiguous, but, well, so what? We are (most of us) here to write articles. Prose, that explains things. We're good at that. Maybe through more efforts of ours, this whole KB/KiB thing will be far less confusing to the kids who are now entering junior high school/middle school/whatever it's called when you get out the little children's school in your part of the world. But lets not force Mbytes and MiBs on anyone in any context in which the distiction is not crucial. End long-coming rant. I sleep now.

Of the three defined styles for binary prefixes, the IEC prefixes are a distant third.

  1. What? What defined styles? Where are you getting usage information?
  2. We don't care about common usage, anyway, as we have said a million times. This is a general-purpose encyclopedia, and needs to use symbols that are useful and meaningful to everyone, not loose jargon. "People familiar with computer science will know what we mean in each context" is not good enough. — Omegatron 17:34, 29 May 2007 (UTC)
  1. The style as defined in the majority of relevant reliable sources for an article.
  2. The "We don't care..." is firstly trying to speak for others and secondly indicative of the lack of rigorous argument presented by those wanting to push binary prefixes onto Misplaced Pages. The useful and meaningful symbols are those presented in the majority of relevent reliable sources, unfortunately for you it's not binary prefixes. Fnagaton 10:54, 30 May 2007 (UTC)
Unfortunately for me?? What do I have to do with this? Are you trying to serve the reader or are you just trying to win an "us vs them" fight regardless of whether it makes the encyclopedia better? I don't use IEC prefixes in daily life, either; it's not important. I say "1 gig of memory" like everyone else. But we need to use prefixes consistently in an authoritative reference work, when the "original sources" mean completely different things in different contexts. Sticking to standards is the easiest, sanest, most logical way to do this. — Omegatron 12:18, 30 May 2007 (UTC)
You started the "us vs them" with the "We don't care..." putting yourself squarely in the frame, unless you now want to retract your statement? As for the "sticking to standards" argument, that's already been refuted numerous times by many people, see the WP:VP links I gave above for examples. The consensus is against your position. Fnagaton 12:28, 30 May 2007 (UTC)
That sounds like an argument not to use words that only computer science jargon aficionados know. Also, the manual of style has no compulsory power to force editors to use words that almost all of them never use. —Centrx→talk • 19:40, 29 May 2007 (UTC)
  1. It's an argument not to use words that have different meanings from one computer science jargon aficionado to another.
  2. Of course it doesnt. So why are you all fighting so hard to have this recommendation removed? — Omegatron 12:18, 30 May 2007 (UTC)
  1. Your argument is irrelevent for the reasons already given in the large section above (the consensus and the actions demonstrated in Misplaced Pages as whole with the WP:VP). Fnagaton 12:28, 30 May 2007 (UTC)
  2. Because it's WP:CREEP and open to incorrect interpretation as demonstrated by the actions of User:Sarenne. Fnagaton 12:28, 30 May 2007 (UTC)
I used the IEEE 100, "The Authoritative Dictionary of IEEE Standards Terms", for Mbyte and MB. I know that IEEE 1541 modified that it but the classic definitions are still widely used. The MiB is defined in IEC 60027-2.
Mbyte Megabyte. Indicates 2 bytes.
megabyte Either 1 000 000 bytes or 2 bytes.
Notes:
1. The user of these terms shall specify the applicable usage. If the usage is 2 or 1024 bytes, or multiples there of, then note 2 below shall also be included with the definition.
2. As used in IEEE Std 610.10-1994, the terms kilobyte (kB) means 2 or 1024 bytes, megabyte (MB) means 1024 kilobytes, and gigabyte (GB) means 1024 megabytes.
SWTPC6800 02:06, 30 May 2007 (UTC)
I don't want to force Kbyte on Misplaced Pages; I was just point out another common prefix. I know Misplaced Pages is not the IEEE nor is it the IEC.
The articles should have the style of the reference documents. This allows readers to search for additional information. The IEC binary prefix experiment that has been run on Misplaced Pages has polluted the encyclopedia. If an item was originally described as a 64K DRAM soft error the reader can search on those terms to find more original documents. A search for 64 KiB DRAM soft error turns up an entirely different set of documents. If someone strips the original prefixes from the Misplaced Pages articles the information is lost to most readers. -- SWTPC6800 03:26, 30 May 2007 (UTC)
Note: this is an example of the reader taking words and phrases from an article then doing a Google search. Switching from K to KiB dramatically changes the search results. There are no quotations involved. -- SWTPC6800 17:11, 30 May 2007 (UTC)
Why would anyone use IEC prefixes in this context? You're quoting an error message, no? — Omegatron 12:19, 30 May 2007 (UTC)
In the late 1970s when 16K and 64K DRAMs were in production (or design) it was discovered that alpha particles caused soft errors. One source of the alpha particles was the IC packages. The problem caused changes in package materials and chip designs. -- SWTPC6800 13:55, 30 May 2007 (UTC)
I think omegatron's question was, "why would anyone change '64K DRAM soft error' to '64KiB DRAM soft error'", when such an error message would presumably be treated as a quote. Bladestorm 15:09, 30 May 2007 (UTC)
It's not an error message as such, that is to say it's not really a message that has been quoted from somewhere, rather it is a problem. For example "Balding rubber tyre" or "mathematical error". Soft error Fnagaton 15:18, 30 May 2007 (UTC)
The text is not a quote of an error message; it is about a common design defect in early DRAM memory systems. When all occurrences of K or KB are changed to KiB to improve the accuracy of Misplaced Pages; the readers lose search access to the source documents. -- SWTPC6800 15:29, 30 May 2007 (UTC)
Fair enough. But, in that case, wouldn't it be treated similarly to a proper name? Don't get me wrong, I agree that it absolutely should remain, "64K DRAM soft error". It's just that this doesn't really seem to be the same issue. If I'm not mistaken (and I very well might be), the main issue here is whether units used in normal prose need to be changed; and, if so, to which notation. But isn't this really a separate issue entirely? And, for that matter, isn't it something that all parties involved can agree wouldn't be changed either way? Bladestorm 15:38, 30 May 2007 (UTC)

Talking about binary unit I think we have left out very real possibility. Drop the ICE prefix and use KB*, MB*, and GB* whenever a manufacture suddenly decide to use SI unit with link to their appropriate articles explaining why base-10 units are being used in a system with all base-2 units. Here is an example: The new Model A 100 GB* hybrid-hard drive has 16 MB DRAM Cache and 512 MB* of non-volatile flash memory. —Dispenser 16:36, June 1, 2007

A review of technical specifications and brochures of manufactures of computers, peripherals and components show universal use of KB, MB and GB to describe the capacity of disk storage and memory (RAM).

Do you even understand what this debate is about? Of course they all use KB, MB, or GB. Those are the only abbreviations that existed. The meaning of those abbreviations is the important point. "Common usage" has always been ambiguous. These units have different meanings and different abbreviations depending on what decade it is and what device, company, and software you're talking about. This is why we "don't care about it". The issue is whether we should encourage a consistent standard between articles to reduce confusion, which almost everyone agrees with.
The idea that we would use some contrived Misplaced Pages-specific abbreviation like MB* because the international standard is "too new" is ludicrous. — Omegatron 17:19, 1 June 2007 (UTC)
Your repeated use of the word "ambiguous" as some kind of mantra is the ridiculous thing here. The current units are not contrived and the preponderance of evidence is against your point of view. Not to mention consensus is also against your point of view. Fnagaton 18:50, 1 June 2007 (UTC)
I have a storage device of unknown type which is described as having 1 GB of storage. Now, please tell me precisely how many bytes it contains. You can't; it is ambiguous. Omegatron described "MB*" etc. as contrived. — Aluvus t/c 23:25, 1 June 2007 (UTC)
What is contrived is that example and the continued denial of consensus. Fnagaton 10:37, 2 June 2007 (UTC)
That example is a pretty straightforward demonstration of the ambiguity. It is not in any way contrived; I fear you are attempting to misrepresent things. A 1 GB hard drive and a "1 GB" stick of RAM are unlikely to contain the same amount of actual space. If you have a "1 GB' storage device of unknown type, it is ambiguous what that actually means unless you have further contextual information. I am not sure how "denial of consensus" can be "contrived", but I am impressed at how you managed to use that device to avoid acknowledging that you were incorrect. — Aluvus t/c 01:57, 3 June 2007 (UTC)
Can I play to? I have a ton of an unspecified substance, now please tell me precisely how many how many onces it contains.... and your point is ?
You have the following SQL DDL : "CREATE TABLESPACE .... MAXSIZE 4G...", how big can my tablespace be ? Should SGBDs break backward compatibility of every existing DDL to please the Marketing department of the harddrive manufacturers ? You must take a memory dump of a 4GB of RAM system, how big will be the dump file ? how big, at least, should be the partition you put it on, how about the disk... how many CD do you need to store it ? That is a fun game, but that is not the point. The point is that in real life there is no ambiguity at all, exept when dealing with the storage industry who can't seems to get any consistancy, floppies, CD in one unit, hard-drive DVD in another, and more recently they are trying to bring the mess into memory-chips based storage... The mess is their own doing, but for some reason they expect the rest of us to change our units to post-rationalized they punny marketing ploy -- Shmget 04:17, 3 June 2007 (UTC)
I'm confused. Why say "there is no ambiguity at all" while simultaneously providing several examples that demonstrate there in fact is an ambiguity? Your list is in fact a very good example of the wackiness that arises from that ambiguity. Whose fault it is does not matter; the reality right now is that "MB" might mean 1 of what, 3 different things? These multiple potential meanings are what make the term ambiguous when additional information is not available. — Aluvus t/c 04:57, 3 June 2007 (UTC)
Yes you are confused because nobody as far as I can see has said "there is no ambiguity at all" because what is being said is that what you see as amibguity is actually not that severe because the issues are well known and documented. Also what you see as ambiguity is also irrelevant since that is not the issue as already explained at great length previously (Read my post at 11:34, 28 May 2007 (UTC) above). By the way I have this device that is labeled as 256MiB and it contains 257433600 total physical raw bytes. This means, following your contrived example to its logical conclusion, that MiB is also ambiguous. Fnagaton 08:31, 3 June 2007 (UTC)
I quoted Shmget, who did in fact write "there is no ambiguity at all". I am amused you're still attempting to push the "contrived" angle; it's not accomplishing anything. As to whether the ambiguity of common usage is relevant, it's pretty obvious that other people do consider it relevant, and your previous "explanation" did not convince them otherwise. Perhaps you can provide a better one? — Aluvus t/c 09:54, 3 June 2007 (UTC)
No you are wrong because you made a partial quote and took it out of context which is dishonest. Your contrived example doesn't actually support your point especially so since you failed to refute what I wrote above. Actually, that is the last straw. Until you retract your statement and apologise to Shmget for misrepresenting what he wrote you're not going to get any more replies from me on this topic. Also do not attempt to reply to me in the future until you apologise and make amends for your actions. Fnagaton 11:51, 3 June 2007 (UTC)
Well, I suppose that was easier than actually demonstrating why the ambiguity being discussed is irrelevant. Sigh... — Aluvus t/c 01:34, 4 June 2007 (UTC)
The websites don’t include the asterisk for some reason like they do on the packaging so its completely ambiguous. Anyway the comment was meant as a half serious joke.—Dispenser 19:26, 1 June 2007 (UTC)
They must be relying on this other 'standard' : Caveat emptor... but if you read carefully and follow the links to the specs, you will end-up finding the fine print that explain that, in some part of their specs, a MB/GB is not really a MB/GB as you know it (presumably since it there is not explanation in the same spec, when they are used in the so-called 'binary' sens), but a special MB/GB, defined with a footnote, an hybrid between the megabyte of memory chips, file size and floppy disk's size and the megabel of the SI standard. -- Shmget 20:45, 1 June 2007 (UTC)

Using K, KB and kilobyte to mean either 1000 or 1024 based on context is not only common usages but is written into many standards. For decades the IEEE Std. 100, "The Authoritative Dictionary of IEEE Standards Terms", defined kilobyte as either 1000 bytes or 1024 bytes, depending on context. Semiconductor memory is normally connected to a binary address bus so the industry standards use kilobyte as 1024. Disk storage has no binary size constraint so disk specifications use a kilobyte as 1000.

Just because some standard's geeks came up with kibibyte to fix the "problem" doesn't mean the world will follow. The IEEE and IEC wanted the world to draw AND gates and other schematic symbols as square boxes in 1984 but the world did not follow. The 1991 version of the standard incorporated the common usage symbols for small gates. This standard has very limited adoption after twenty years. -- SWTPC6800 14:32, 2 June 2007 (UTC)

Time to fix the wording

The previous binary prefix style (April version) clearly does not have a consensus. The current version is still disputed. Do we just remove the entire style?

Maybe it should be replaced with something simpler. Like this:

Misplaced Pages follows common usage for binary units and does not have a preferred style. An article should use the units found in reliable sources relevant to the article. If multiple styles of units are used by relevant reliable sources the article editors should select the predominate unit and use it consistently.

I know some will reject this and want a more prescriptive wording. Propose it. We should avoid the instruction creep of the old version.

The existing wording reads like an advertisement for IEC standards. The original vote was "The MoS should encourage the use of the IEC prefixes in all binary-multiple contexts." It is not Misplaced Pages's job to sell a standard. The outside world selects the winning standard or standards. We should remove the table that sells the IEC proposal. We can just point out the binary prefix page without the endorsement of any particular standard. -- SWTPC6800 01:11, 31 May 2007 (UTC)

It's not going to be a surprise that I like this wording. ;) I know the proposed wording is basically a mixture of existing guidelines such as WP:NPOV, WP:NOR, Disputes over style issues. It could be argued the binary prefix guideline could therefore be removed completely but to be honest I believe not having a binary prefix guideline will again lead to one person taking it upon themselves to change all prefixes against the wishes of the majority. So it's probably better to have a short binary prefix guideline. I also agree with SWTPC6800 about the "advertisements for IEC" because the existing wording is just too pushy. Fnagaton 09:53, 31 May 2007 (UTC)

The original vote was "The MoS should encourage the use of the IEC prefixes in all binary-multiple contexts."

But Misplaced Pages does not work by majority rule. The consensus wording decided from that poll was "The use of the new binary prefix standards are not required but are recommended". That one user abused this and was banned for it does not invalidate the consensus. If you think the wording encourages abuse, change the wording (as I've already done). But the use of consistent units has broad support and will continue to be recommended. — Omegatron 17:35, 1 June 2007 (UTC)
You say "Misplaced Pages does not work by majority rule" and then you cite a poll to support your argument? You say that because it is the Manual of Style "you are not required to follow its recommendations" as justification for making the Manual of Style contradict actual practice and call anyone who disagrees with you "disrupting the project"? You seem to wilfully misunderstand the actual issue, that the recommendation of using binary prefixes is wrong, and to ignore the fact that as a recommendation the Manual of Style does have effective power in causing people to write in a certain way and to resolve disputes in conformance with it. Insofar as the Manual of Style being merely a "recommendation" is justification for your edits, the Manual of Style would be null, but it is not, and you must actually justify why the binary prefixes should be recommended. —Centrx→talk • 17:44, 1 June 2007 (UTC)
and the '2005' wording you wanted to introduce also claimed that "These standards are commonly followed, but are not yet ubiquitous.". This is still complete non-sens even today... so in 2005!!!. These standard are NOT even remotely 'commonly followed'. you can still count on your fingers the softwares that allow you the 'option' to display things using IEC notation. Not a single spec sheet of nay manufacturer use that notation, not the ships founders, not even the hard-drive manufacturers.... -- Shmget 17:46, 1 June 2007 (UTC)
In other words, they were not commonly followed in 2005 and they are not commonly followed in 2007, and neither case are they approaching ubiquity. Saying so then and saying so now is a falsity that promotes a particular point of view. —Centrx→talk • 17:57, 1 June 2007 (UTC)
Well I reverted for two reasons. 1) The text doesn't have broad consensus. 2) The text was added back by a known Tor exit node. I added a note about it here on Omegatron's talk page. Fnagaton 18:23, 1 June 2007 (UTC)
Also Omegatron you owe me an apology for trying to claim my revert was in any way an attempt at "disrupting the project". I'm not the one who made a change without proper consultation, you did. I'm not the one who is putting back edits by known Tor exit nodes, you are. There is a reason your point of view is meeting such a large amount of resistance. You seriously need to think about your actions. Fnagaton 18:26, 1 June 2007 (UTC)
More likely(?) the tor user was Sarenne. — jesup 04:15, 2 June 2007 (UTC)
He is saying that Omegatron reverted to a version of the page that the tor user reverted to, not that Omegatron was using tor. —Centrx→talk • 04:29, 2 June 2007 (UTC)

You say "Misplaced Pages does not work by majority rule" and then you cite a poll to support your argument?

Yep. As you'll recall, the poll results were:
  • 20 support: "The MoS should encourage the use of the IEC prefixes in all binary-multiple contexts"
  • 1 support: "The MoS should encourage the use of the IEC prefixes only in highly technical contexts"
  • 6 support: "The MoS should discourage the use of IEC prefixes anywhere "
  • 0 support: "Don't mention"
  • 2 support: "No more votes"
So we reached a consensus wording that said SI standards for decimal and IEC standards for binary are "not required but are recommended". It was added on July 9, 2005, the wording tweaked a little, and everyone was relatively happy. Some articles used them, some articles did not.
Then Sarenne claimed it as justification to be disruptive and was (rightly) banned. But now a handful of people are responding by revert warring, disrupting articles, and trying to change the section to match their own personal viewpoints to the exclusion of all others.
Sorry, but that's not how it works. Do you think everyone who participated in the original discussion has suddenly changed their minds and support the removal of this recommendation? Why don't you ask them?

This is still complete non-sens even today... so in 2005!!!. These standard are NOT even remotely 'commonly followed'.

How many hard drives are produced each year with standardized SI prefixes? How many DVDs?
how many CD's, hom many memory chips, how many files in how many filesystem ? -- Shmget 06:49, 2 June 2007 (UTC)
How many web servers run the Linux kernel?
oh please!
Linux-2.6.19-gentoo-r5:$ wcgrep 'B' | grep print | wc -l
Linux-2.6.19-gentoo-r5:$ 80
Linux-2.6.19-gentoo-r5:$ wcgrep 'iB' | grep print | wc -l
Linux-2.6.19-gentoo-r5:$ 20
and out of these 80 messages, 3 were a false positive ( nothing to do with megabyte), and just one used MB in the 'hard-drive manufacturer sens: in /drivers/ide/ide-disk.c:971), the 76 other uses are MB as in 1024*1024 bytes. oh! and more than half the MiB/GiB print are in the MTD drivers. (guess why).
so much for commonly followed!!! Furthermore, try du -h, ls -lh or any coreutils function that produce 'human readable' unit and try to guess what these K/M/G means there... Yes, in coreutil was added fairly recently a --si option to alter the meaning of these unit, but still not IEC symbol here either way, and certainly no change to the existing behavior (no Coreutil will not break Posix compliance to please Sarenne :-) ). You would have better luck to mention the Gnome System Monitor who does indeed display IEC notation for memory, but 
for file in `wcgrep -l "iB"` ; do sed -i -e "s/iB/B/" $file ; done
on the source tree, take care of that in a hurry. (there is 3 hit in src/util.c, the rest are all the translations of these 3 messages in all supported language)
BTW if you wonder how things are evolving:
Linux-2.6.15-gentoo-r1:$ wcgrep 'B' | grep print | wc -l
Linux-2.6.15-gentoo-r1:$ 79
Linux-2.6.15-gentoo-r1:$ wcgrep 'iB' | grep print | wc -l
Linux-2.6.15-gentoo-r1:$ 19
-- Shmget 06:49, 2 June 2007 (UTC)
What units do these use? How do you define "common usage", anyway? If you disagree with that sentence's use of "not yet ubiquitous", feel free to reword it, but revert warring the whole section to your own wording is not helpful or acceptable.

I'm not the one who made a change without proper consultation, you did.

You've completely rewritten a section to represent your own viewpoint without any kind of consensus on the talk page. Omegatron 00:55, 2 June 2007 (UTC)
You are wrong, the consensus is demonstrated by the more recent vote, you know the vote that came out overwhelmingly in favour of removing the version you prefer. The current version is the version that has consensus. The version you prefer does not have consensus. Fnagaton 10:52, 2 June 2007 (UTC)

I'm not the one who is putting back edits by known Tor exit nodes, you are.

Oh really? — Omegatron 00:55, 2 June 2007 (UTC)
Yes really, the proof is on your talk page. You still owe me an apology for your misrepresentation. Fnagaton 10:52, 2 June 2007 (UTC)
Perhaps instead of summarizing votes you should summarize the reasoning on each side. I actually don't see any hard drives that use the new prefixes; they are using the old prefixes in the same fashion they used prior to the existence of the new prefixes, specifically with the purpose of misleading customers. There is also almost non-existent usage on Google Books, Google Scholar, and industry magazines. So, where is the "common usage" (let alone the usage that would indicate progress towards ubiquity). Also, objection to this issue pre-dates Sarenne's edits, which only demonstrate the fact that people do and will use the manual of style as a guide for making edits. —Centrx→talk • 04:14, 2 June 2007 (UTC)
Omegatron has incorrectly cited an old vote when there is a much newer vote that proves consensus is the opposite of his point of view edit on the project page. His edit has now been reverted since it is obvious it does not have consensus. Fnagaton 11:52, 2 June 2007 (UTC)
What new vote? When did Misplaced Pages become a democracy? — Omegatron 15:21, 3 June 2007 (UTC)

He is saying that Omegatron reverted to a version of the page that the tor user reverted to, not that Omegatron was using tor.

Oh, I see. Yes, I did revert to a version of the page that the tor user reverted to. I did not use Tor myself.

how many CD's, hom many memory chips, how many files in how many filesystem ?

Those don't follow the standard, do they?
What a shocker. Standardized CD specification do not follow 'the' standard created more than a decade after ?

So, where is the "common usage"

What? The common usage is a mixture of two different styles. I don't think you can put any kind of meaningful numbers on how much of the common usage follows SI and how much does not,
Sure you can, and I just did earlier. In the Linux kernel there is ONE and just ONE message that use MB in the 'hard-drive manufacturer sens', and 76 occurence where MB is used in it's common 1024 KB sens. -- Shmget
but it's pretty obvious to anyone that both styles are part of "common usage".

Omegatron has incorrectly cited an old vote when there is a much newer vote that proves consensus is the opposite of his point of view edit on the project page.

How many times do I need to say that Misplaced Pages is not a democracy? Please please please read that page. Votes are irrelevant except to judge how many people support a particular viewpoint. Votes don't decide policies or guidelines. Votes (or polls, more precisely), are only used to gauge opinion and then form a consensus based on everyone's opinion, not on majority rule.
And where is this "newer vote", anyway? — Omegatron 17:22, 2 June 2007 (UTC)
You were the one who started by citing numerical votes. —Centrx→talk • 17:28, 2 June 2007 (UTC)
You didn't answer my question. Where is this newer vote? And when did Misplaced Pages become a democracy? Guidelines aren't decided by votes. They weren't in 2005, and they aren't now. Disrupting a guideline with incessant stubborn discussion, revert warring and personal attacks until everyone who disagrees with you ducks out or leaves the project is not consensus.

On the other hand, it is very easy to create the appearance of a changing consensus simply by asking again and hoping that a different and more sympathetic group of people will discuss the issue. This, however, is a poor example of changing consensus, and is antithetical to the way that Misplaced Pages works. Misplaced Pages's decisions are based not on the numerical fact of how many people showed up and voted a particular way. It is based on a system of good reasons. Attempts to change consensus must be based on a clear engagement with the reasons behind the previous consensus - not simply on the fact that today more people showed up supporting position A than position B.

A good sign that you have not demonstrated a change in consensus, so much as a change in the people showing up, is if few or none of the people involved in the previous discussion show up for the new one.

— Omegatron 15:21, 3 June 2007 (UTC)
Centrx did alreday answer the question and you already know what vote because you voted in it. Yet again you ask a question where you already know the answer. You are the editor who is revert warring and you are the editor making personal attacks when your edits have been reverted due to lack of consensus. The change in consensus has been demonstrated. The fact is you are repeatedly denying the truth of that change in consensus. Your repeated denial of the truth doesn't work. Fnagaton 17:18, 3 June 2007 (UTC)
Again you are missing the point entirely by throwing up irrelevant red herrings. Centrx is right with his earlier comment you do "wilfully misunderstand the actual issue", you are in effect playing the game of ignoring the facts. Fnagaton 17:29, 2 June 2007 (UTC)
"Ignoring the facts"? Of what? Please show everyone, below this comment, a list of the facts that I am ignoring, and why these facts are relevant to this discussion. — Omegatron 15:21, 3 June 2007 (UTC)
Ignoring the facts like: The consensus that is against your position and yet still making changes to the project page when there isn't consensus. Then edit warring to put your changes back. Then writing lies about the editors who revert your edits. Then asking questions where you already know the answers in an attempt to appeal to ignorance. Centrx and I are having to bring to your attention your behavior, that should cause you to stop and think. Your behavior is why I mentioned on your talk page that you should take a break from editing to consider your actions. Fnagaton 17:04, 3 June 2007 (UTC)
Omegatron has been involved with this binary prefix style from the beginning. There may be some ownership issues at play here. He strongly believes that the IEC style is in the best interest of Misplaced Pages. It appears that many more editors think that matching reliable, published sources is more important. (I personally think that Omgatron is a valuable contributor to Misplaced Pages.) -- SWTPC6800 17:01, 3 June 2007 (UTC)
For starters, saying everyone who disagrees with you is trying to "disrupt the project" for "personal" reasons is inflammatory and plainly false. Saying that there is "broad consensus" for recommending IEC prefixes is also rather blind given the major disagreements with it here. There is also substantial unequivocal evidence that the IEC standards are not "commonly followed", whether in 2005 or 2007, and they have not been "widely adopted". The fact is: most published sources and most people in general do not use these prefixes at all. It is also strange of you to cite the numbers of a poll as though it is relevant and then, when a newer poll that contradicts your own position is mentioned, to say that polls are irrelevant. The poll to which Fnagaton is referring may be , in which all but two support wording that specifically does not "recommend that the SI and IEC standards be followed". —Centrx→talk • 17:18, 3 June 2007 (UTC)
SWTPC6800 was the one that brought up the 2005 poll in this instance. Omegatron attempted to place that poll in context and explain that the wording that was placed into the MOS was the result of discussion and consensus following the poll, not the numerical result of the poll. If I am not mistaken, Omegatron has reiterated that Misplaced Pages is not a democracy several times already (including in reference to the 2005 poll), only to be shouted down. It is unfortunate. — Aluvus t/c 01:47, 4 June 2007 (UTC)
Not accurate because Omegatron (and others) previously kept on referencing the old "consensus" (i.e. the old poll) when trying to shout down those who spoke out against using binary prefixes. The inconsistency is that Omegatron cites the old poll/vote when it suited his cause and then would try to claim other later polls/votes are not relevant (mostly by posting Misplaced Pages is not a democracy) when those polls/votes do not support his cause. It is illogical to do that and of course it is just balderdash to keep on trying to cite "Misplaced Pages is not a democracy" given his previous actions. Fnagaton 09:16, 4 June 2007 (UTC)
Fnagaton, this is where I assume your misunderstanding lies: “referencing the old "consensus" (i.e. the old poll)”. Omegatron was not referencing the poll as consensus, but the text that was written after that poll, taking its result into account. It is a huge difference between building a consensus and selecting one alternative (like some are trying to do currently). A compromise is sometimes similar to consensus, but not the same thing at all, by the way. Christoph Päper 14:33, 4 June 2007 (UTC)
No there is no misunderstanding from me, Omegatron and others have been referencing the vote/poll as "consensus", I say "consensus" because I read through the vote that Omegatron keeps on referencing and actually the results of that poll are inconclusive and don't show the consensus Omegatron seems to think it does. This is because many of the comments in the early poll have caveats that were not reflected in the resulting guideline text. This also means Omegatron isn't referencing the actual consensus, he is trying to push his own point of view and this has been demonstrated by his recent edits to the project page that got reverted. Fnagaton 14:53, 4 June 2007 (UTC)
Although I do disagree with Omegatron on some aspect of this particular issue, I must say that, for the ones I have seen on other topics, his edits are reasonable and measured. The particular feud on this article, may indeed be fueled by a long participation on this topic and a good faith impression about what the 'consensus' on this topic is or was.
I disagree that the strong wording in support of IEC was ever consensual. It is most likely that the MOS was not monitored very closely by most editor with expertise in the field, as illustrated by the reaction of many of them, when forced to look at the MoS due to the action of notorious activist. But one thing is clear: Neither in the real world nor in Misplaced Pages are the IEC notation anywhere close to be 'commonly' used or even accepted. I can imagine the XiB notation being eventually accepted, especially in documents that need to straddle two worlds, but I can't imagine, in my lifetime, being able to say 'tebibyte' or 'gibibyte' without feeling like an extra in a Buck Rogers episode. Time, and the real world will tell if that standardization effort will have more success than the one regarding the logic gates, in the interval, it should not be the role of Misplaced Pages, and even less of the MoS to 'lead the charge'. The mere fact that the MoS actually contain an explanation of what are binary prefix (the whole first paragraph, is a good indication, in itself, of the lack of acceptance of these notations. If an editor need that introduction to understand the situation, he probably is not ready to edit that kind of material. A reference to the appropriate article should be enough to get them started. I'd favor to drop the first paragraph and the infobox, and to wikify 'binary prefix' and the first mention to the IEC recommandation in the second paragraph (that would become the first). the last part listing the 'measure that use this or that' should also be in the appropriate topical page, not in the MoS. -- Shmget 22:45, 3 June 2007 (UTC)

I have a question and an observation. Q: the current wording has "IEC-recommended." Is it correct to say that the IEC encourages the use of these prefixes? Is there a distinction between defining the prefixes in a standards document versus encouraging their use? Observation: many of the links to IEC prefixes on Misplaced Pages are coming from PDFbot, which adds them when it adds the sizes of PDF files. I'm not sure if this is cause for concern (I mentioned it over on User talk:Dispenser#PDFbot binary prefixes, but I thought I should point it out. jhawkinson 03:17, 5 June 2007 (UTC)

Yes the IEC recommends you use kibibyte (KiB) but virtually no one in the computer industry or publishing industry uses it. Since 1984 the IEC has recommended that people draw AND and OR gates as square boxes, nobody does that either. A small group of IEC enthusiast here at Misplaced Pages is promoting this failing standard. The world is going to start using it any day now. Misplaced Pages just has to keep pushing it. -- SWTPC6800 03:50, 5 June 2007 (UTC)

Binary and SI prefixes (MS topic)

I sorry to bring up this flame topic again but I feel that it needs to be addressed. The Xbox 360 uses DVD-9s which hold 8.5×10 (9.0×10 or 7.92 GiB if not using EFMPlus) of data. The problem now here is is the Microsoft reserves a bit of space on the disc. This is quoted as 7 GB , but if you look at all the other information it becomes clear that MS is using binary units in all contexts (there was a better source that state the total disc capacity was 7.9 GB). Now the problem comes in stating this in the article. Obviously, stating it as

...Only 7 GiB out of the 8.5 GB is available to developers...

is unaccepted by the majority of editors as this is "correct" to GB. But the question is how to make it clear to the reader which unit we are referring to? Since we have two different usages out of the horses mouth. —Dispenser 00:50, 20 June 2007 (UTC)

How about using the terms found in the reliable sources relevant to the article and disambiguate using parentheses? It is worth noting that some of these games sites are not really reliable sources because for things like the exact measurements for storage values tend to be overinflated to score points against rival console vendors, are sometimes inaccurate marketing rubbish or vary depending on exactly what protection is used. The really reliable sources tend to be covered by NDA. Fnagaton 08:30, 20 June 2007 (UTC)
I don't understand the question, but there seem to be so many options. You could give the amount of space that is reserved (is that 942KB?), you could use consistent units ("only 7GB out of 7.9GB"), you could use a fraction or a percentage. It seems odd, btw, to use "only" if you're talking about a 12% difference; is it really significant?. jhawkinson 16:44, 20 June 2007 (UTC)
The PS3 fanboys like to tout that blu-ray holds more. So the 1 Gig or 1.5 Gigs wasted becomes important to them. So we should convert the units then? —Dispenser 22:08, 20 June 2007 (UTC)

Years and dates

editArchive
Years and dates archives

Default date display setting

Perhaps MediaWiki should convert all supported date formats (e.g., ] ], ] ], ]) to the default (e.g., "May 28, 2007") for new and unregistered users rather than leaving it in whichever date format was used to link it? I find it more convenient to use the ISO date format than the more verbose form, and since it is automatically converted to the user's date format preference, I figured it would be OK to do that. However, if new and unregistered users will be seeing them as YYYY-MM-DD rather than Month DD, YYYY, that's not good. :/ -Matt 16:14, 28 May 2007 (UTC)

Matt: I took the liberty of reformatting your comment because it didn't come out right if date preferences were set!
I agree with your point of view. I wish the MediaWiki software did that. I too used to write ], assuming that the software would convert it. However, you'll have to lobby the developers for that change, and in general I'm afraid they seem to have little time, and we seem to have little influence. All we can do on this page is give style advice given the current state of the software.
Stephen Turner (Talk) 20:01, 28 May 2007 (UTC)
One problem, of course, would be what to set the default as. Should it be Month DD, YYYY or should it be DD Month YYYY (or even YYYY-MM-DD). Would we ever get consensus there? But, then, on the other hand, should there be a default? Isn't it better to treat this like spelling with consistency within articles but not necessarily across them - leaving the format seen by the unsigned in whichever had been written in the article? Jɪmp 02:53, 29 May 2007 (UTC)
Date formats should be treated like regional spelling. Color and colour, April 4 and 4 April. According to the nature of the article. If we were to settle on one date format or another as a universal default, then we would get howls of outrage from the other side, as well as the recognition of a precedent and license to convert colour to color, feet to metres and so on throughout the wikipedia. This is a can of worms we don't want to open! --Pete 03:15, 29 May 2007 (UTC)
I see Jim and Pete's argument. Myself, I still think either default would be better than none, although you've made me less sure than I was. But it's really a moot point: I don't think the developers are likely to regard this feature as a priority even if we agreed we wanted it, and certainly not if we don't agree. Stephen Turner (Talk) 09:10, 29 May 2007 (UTC)
Really we should be smarter on the preferences, and if not set we could deduce the location, and so have simple localization prefs.... But I didn't want to push for too much. And I'm not sure what's happened to Rob Church's patch anyway. Rich Farmbrough, 11:59 2 June 2007 (GMT).

Just following the rules, folks

The stuff I've delinked has been among the categories that wikipedia's rules of style says should be delinked, such as days of the month or things that have been linked more than once. Treybien 1:56, 5 June 2007 (UTC)

Piped 'Year in xxx' links

Discussion brought from talk:WikiProject Films (starts here)

In a film article, I want to know the proper format for using the 'Year in Film' link. When I create a film article, I write it in the following manner which just shows the year and if you click on the year it takes you to the Year in Film page for that year:

  • Movie Title is a 2006 film starring John Smith and Peggy Sue.

However, some of my films have been edited by others changing the year link to just the year and then adding a {see 2006 in film) to the end:

  • Movie Title is a 2006 film starring John Smith and Peggy Sue (see 2006 in film).

I would like to get a ruling as to which is the proper format. I think the way I do it is, as it is cleaner and there is less "clutter" in the article, but if the other method is correct I will start using it. Thanks! Donaldd23 23:19, 2 November 2006 (UTC)

I have edited hundreds of introductory sentences for films, and I tend to follow the first approach that you listed, since that was what I saw as most common for other films. I just think having a "see 2006 in film" detracts from the introductory paragraph when it can just be included within a wikilink. Also, the title of the film should have both italics and bold around it such as Movie Title to also remain uniform with the thousands of other films on Misplaced Pages. Keep up the good work with your film contributions. --Nehrams2020 23:23, 2 November 2006 (UTC)
I agree with Nehrams. Cbrown1023 23:26, 2 November 2006 (UTC)
Well, the list by year point of view is that it offers the possibility to place this film in relation with other films of the same year or period. So, if there is a place in the article where this link can be given, the code is ], which gives 1968. Hoverfish 23:33, 2 November 2006 (UTC)
Also I personally don't like to come in articles where everything is linked to something. I could ignore the link, but it gets the eye for sure. Hoverfish 23:40, 2 November 2006 (UTC)
Note that WikiProject Music specifically deprecates the use of "piped links" of that form. That is, you should only link to ] without any piping whatsoever. This is compliant with the WP:MOS guidelines about linking text. --Dhartung | Talk 18:25, 5 November 2006 (UTC)
There is no "proper format". There's no clear WP-wide consensus on this (see Misplaced Pages:Manual of Style (dates and numbers)#Partial dates), so policy for film pages is pretty much whatever we say it is.... and fortunately, we do seem to agree on this.
I'm not too keen on the counter-intuitive ] links, but I strongly dislike the "see 2006 in film" approach, which clutters the text, and I see no value in a link to just the year. One possibility would be not to include a link to the year at all, except that somebody would probably add one.
TheMadBaron 17:27, 5 November 2006 (UTC)
The format preferred by WikiProject Music (at WP:MUSTARD#Internal_links), which is probably influencing the use of the "year in X" form, is instead:
  • Album is a 2006 record by John Smith and Peggy Sue (see 2006 in music).
First of all, the manual of style deprecates standalone years except where they are particularly significant, so those may be removed from any article as you edit (I wouldn't bother unless making other changes as well). Second, the idea is that with music articles, having bunches and bunches of year links right next to each other is clutter and only the most significant dates should be linked, for example, if the item itself is placed on the "year in music" page. This is so you don't get an article full of "In 2006, Britney Clarkson released her 203rd album, I'm Boring (see 2006 in music), which contained the singles "So Are You" (see 2006 in music) and "I Forgot Your Mom" (see 2006 in music). I don't know that this concern applies to film articles. In any case, mentioning it once in the lead doesn't bother me in the least, especially if the movie article is already included in the year in film article linked.
I'm not saying we must be compliant with the other WikiProject, but I would prefer that the two projects not have completely opposite standards. --Dhartung | Talk 18:23, 5 November 2006 (UTC)


Is there a good reason why you delink piped links to years in (some topic)? You apparently decided here that 1982 in film is a bad page to link to from Blade Runner. It does seem a decent link, though; perhaps you should cite something other than WP:CONTEXT if you want to remove links like this one. Kusma (talk) 12:46, 30 May 2007 (UTC)

Yes there is a good reason. Hiding links behind routine terms does not help the reader at all. I do not think anyone believes that readers hover over or click all mundane year links to reveal what is hidden. As far as the reader is concerned, it is just another out of context link to a year.
That is why the people over at the music project say:
Do not use piped links to "years in music" e.g. ], instead add (see 1991 in music) where you feel it is appropriate.
That suggestion makes sense more generally than just for music. Perhaps it would be worth raising it in the film project.
I hope that explains it. Lightmouse 13:04, 30 May 2007 (UTC)

I revived this discussion from the archive because of a conversation that Kusma and I were having. Is it time for a policy on this? Lightmouse 19:05, 30 May 2007 (UTC)

I will still continue with ]. It's not about hiding links or out of context links, it's about linking to the right page. Linking to the general year page like ] in the film article is definitely an out of context link.--Crzycheetah 02:18, 31 May 2007 (UTC)
I think in most cases it's better not to link to year pages at all. Jogers (talk) 10:24, 31 May 2007 (UTC)
I always use that method, it is cleaner and less cluttered - • The Giant Puffin • 10:55, 1 June 2007 (UTC)
Discussion brought from talk:WikiProject Films (ends here)

There are lots of piped year links on Misplaced Pages. What do people think about generalising the policy being used at the music project? Lightmouse 11:01, 1 June 2007 (UTC)

There was a time when I used piped year links, but now I strongly dislike them, for two reasons: (1) no-one will ever follow the link, because they think it's just another useless year link; (2) even if they do follow the link, it won't take them where they expect: it's bad if links have a surprising destination. So I would be happy for us to advise against them. Stephen Turner (Talk) 11:40, 1 June 2007 (UTC)
Like Stephen I think piped year links are bad, and even question the value of many links to "X in Y" articles, because they are still very general listy articles. A see also link to "1980's punk scene in New York" where there was some description of how the scene developed, might give useful context to an article, but "1984 in music" or even "1984 in American Music" will give little context, especially if the articles are listy. In summary, I support generalising the music project policy. Rich Farmbrough, 09:10 2 June 2007 (GMT).
Would anyone like to add the appropriate wording? Lightmouse 09:01, 8 June 2007 (UTC)
I disagree & feel you should do more to encourage comment from others before making a blanket policy. If the complaint is about linking to "listy" articles, then the complaint is about those articles really, not about the links. Personally, I find links to years (e.g. 1946 to be helpful, and more so where they are piped to a specific area (e.g. 1946 in architecture). I note that Lightmouse has been busy deleting single-year links from a wide array of articles, but like other visitors to Lightmouse's talk page I find this to be disruptive - the guideline as stated explicitly acknowledges that some editors like these links and I don't think it's appropriate to go through deleting them all in the absence of a clear policy against them. All that does is make more work for us poor editors either putting them back or amending them.
The (see 1946 in architecture) format is fine for an article which is dealing with only one event, person etc, but for an article surveying the historical development of something (e.g. reinforced concrete) it's far too awkward. -- Kvetner 11:19, 11 June 2007 (UTC)
Kvetner: the discussion is not whether linking 1946 is helpful; or whether linking to 1946 in architecture is helpful; but whether it's a good idea to disguise a link to the latter to look like the former, for example: "After the destruction of the Second World War, many new buildings were designed in Germany. In 1946, someone started construction of something". This is the sort of link that I think should be strongly discouraged. Stephen Turner (Talk) 15:30, 11 June 2007 (UTC)
I was addressing that point as well as introducing a new one, but in case that's confusing I'll separate them out. I will say again that I disagree with the proposal to change the style guidelines so that piped year links are deprecated. I think they are useful and for the reasons already discussed - links to the year pages only (1946) are less relevant than a link to a more specific page (1946) - while the (see 1946 in architecture) option remains clumsy for any article which discusses a variety of dates. Therefore the piped links remain a useful compromise between year links which are less relevant or which clutter up the text unnecessarily. I think they have sufficient value that there's no need for a blanket policy, although I have no problem with individual WikiProjects deciding on their own preference. -- Kvetner 20:48, 11 June 2007 (UTC)
Given that example, where only the year is mentioned, IMO it should only be linked if the year is somehow relevant to the article (WP:CONTEXT). Another point worth mentioning: Article content vs. infobox content, I have seen piped-context year links used in infoboxes as an alternative to including non-related year links solely for date-formatting preferences. --Stratadrake 02:32, 13 June 2007 (UTC)
It's come up again at Misplaced Pages talk:WikiProject Aircraft#Easter egg links in user box. I think I am also against having this on a project-by-project basis and I agree that piped links are to be avoided for lack of utility. --John 22:45, 26 June 2007 (UTC)

Discussion brought from talk:WikiProject Aircraft (starts here) I just had an interesting conversation with User:Piotr Mikołajski about the use of links like ]. I had delinked some and he undid my edit. I would submit that these easter eggs are of no value whatsoever and that it would be more useful to use links of the sort: See also 1933 in aviation, and only where the entry linked to contains some relevant information. I believe this is in line with the principle Misplaced Pages:Only make links that are relevant to the context. What do other editors think? --John 21:14, 26 June 2007 (UTC)

I agree with you. Easter egg links like that are really of little value. -- Chrislk02 (Chris Kreider) 21:16, 26 June 2007 (UTC)
I have to disagree - the links take you to the year in aviation page which allows the reader to put the particular event in context of other aviation events. MilborneOne 21:24, 26 June 2007 (UTC)
But the reader doesn't know unless he/she hovers over the link where it will lead! I bet over 99% of the time a reader would assume the link would lead only to the standard ] year article. Surely using them judiciously and making them clear would be better. --John 21:34, 26 June 2007 (UTC)
I think a link in the related content section of the standard specs box would work. On other articles, a link in the See also section would work. If we are going to create a 19xx year in yyyyyy, then what is the point of having year links themselves? I have done alot of work on this project and have always linked to the years because we need to remeber, that overall, this project is part of the greater wiki community and there is often some merit in doing things the same way the rest of the community does. -- Chrislk02 (Chris Kreider) 21:38, 26 June 2007 (UTC)
When you hover over the link it says 19XX in aviation so a reader would know were the link went. MilborneOne 21:40, 26 June 2007 (UTC)
As I said, yes. How many are going to do that though, especially when it is part of a full date (like January 1 1920)? --John 21:48, 26 June 2007 (UTC)
I suspect nobody really clicks through any normal date links as they do not add any real value! but another benefit of the aviation links is when you use what links here on the 19XX in aviation page. MilborneOne 21:56, 26 June 2007 (UTC)
Wouldn't it be better to improve the XXXX in aviation page to mention the aircraft in question, which would achieve the same thing but actually be useful? --John 22:01, 26 June 2007 (UTC)

In a perfect world, where we know the date of a first flight of an aircraft type, the year in aviation article should always link back to that type (year in aviation has a specific subsection for first flights), but I think most of us have been a bit slack in making sure that happens. So, in the context of the infoboxes, years should definitely link to the year in aviation article. In the context of general article prose, it probably doesn't matter whether a year is linked or not, but if it is linked, I think it should link to the year in aviation rather than to just the year, since this is the more specific context. If readers want a more general context again, each year in aviation article provides a prominent link to the more general year. It's only one more click. --Rlandmann 22:15, 26 June 2007 (UTC)

Given the prevalence (and specific advice in the manual of style) that dates should be coded as ] ], I think very few users would expect anything other than the standard year article to link from 1920. On the other hand, if we could improve the ] articles, that would actually be useful. We could then avoid these Easter egg links and use See also ] as a far more useful and encyclopedic way of highlighting these articles.--John 22:21, 26 June 2007 (UTC)
Sorry - could you please direct me to where the MOS says not to do this? I couldn't find it. --Rlandmann 22:30, 26 June 2007 (UTC)
Yes, certainly, that would be at Misplaced Pages:Manual of Style (dates and numbers). --John 22:35, 26 June 2007 (UTC)
Sorry - I couldn't see anything mentioning piped links of this sort. On the other hand, piping to years in aviation has been part of WP:AIR's page content guidelines since April 2004. --Rlandmann 22:39, 26 June 2007 (UTC)
  • Noted, well spotted. In fact there are very few hard rules in Misplaced Pages. However my argument does not (and never did) depend on it being a hard rule, but on the utility or lack thereof which these links add to the project. It seems at least one major project already deprecates this confusing use of piped links. I think it would be unsatisfactory and inefficient if these decisions were to be made on a project basis, so I have raised it at Misplaced Pages talk:Manual of Style (dates and numbers)#Piped 'Year in xxx' links. Best wishes, --John 22:54, 26 June 2007 (UTC)
Discussion brought from talk:WikiProject Aircraft (ends here)

Deleting year links

I'm bringing out my other point separately, which is to ask for opinions on the practice of deleting year links indiscriminately across a wide range of articles despite their being no policy requirement for this and despite the guidelines explicitly acknowledging that many editors like such links. Any views? -- Kvetner 20:48, 11 June 2007 (UTC)

In the past, this has resulted in some user blocks, and some rather nasty revert wars. I recommend reading through the archives of this talk page, and possibly User talk:Bobblewik and associated archives such as here or here before doing this. Neier 10:07, 12 June 2007 (UTC)

Year ranges

Am I missing it, or is there nothing covering year ranges: a) 1352-3, b) 1352-53 c)1352-1353? All I can see is a link to the dash policy, which doesn't cover this question. An editor keeps changing b)s to c)s - which other people change back. b) should be standard, in my view. Johnbod 02:13, 21 June 2007 (UTC)

I think b)s are comprehensible enough. I'd support making them standard. a)s, of course, create consistancy problems when next to ranges spanning across decades (e.g. 1352-69). The problem still exists with b)s when next to ranges across centuries but the problem would be less frequent in this case. Jɪmp 03:20, 21 June 2007 (UTC)


Misplaced Pages:Manual of Style (dates and numbers)#Years, decades, and centuries

Does this section imply that dates that occur AD or CE should not be referred with AD or CE? I know I didn't express my question so I'll provide an example. Is 18th century preferred to 18th century AD/CE? I imagine the context may influence which one is better. If BC/BCE dates are frequenty mentioned then it may be better to add the AD/CEs in too. Am I correct? Gizza 23:15, 4 July 2007 (UTC)

Yes, there's no point in adding AD's all over Voltaire. In a sequential chronological History of metalworking or something, as a minimum you should probably start with a BC, have one or two for your last BC dates, & an AD for your first one or two of those. More may be necessary & all dates may need them if you are jumping around. Or do more, like this list Timeline of clothing and textiles technology Johnbod 23:28, 4 July 2007 (UTC)
I'd say only add AD or CE where not to do so would cause confusion or lead to unnatural prose. Of course, it is context dependant but in your example, I'd suggest that 18th century should be preferred to 18th century AD/CE. Given that BC/BCE dates are frequenty mentioned I don't see that it follows that it may be better to add the AD/CEs in too. These are not symmetric in the mind's eye. To crudely exemplify what I mean, consider 2007 BC & 2007 AD verses 2007 BC & 2007, surely you'd agree that the AD (or use CE if thou wilt) is unnecessary. We don't put plus signs before all positive numerals. P.S. I'll be moving this into the appropriate section above. Jɪmp 00:18, 5 July 2007 (UTC)

Centuries

Centuries should always be written out in prose (i.e. "eighteenth century") and should never be written using numerals. Both the MLA style guide (in section 3.5.5 of the 6th edition) and the Chicago style guide (in section 9.36 of the online edition) recommend this style. Awadewit | talk 21:38, 7 July 2007 (UTC)

The only argument I can think of against this is that those two style guides are aimed at people who are fluent in English, but for some Misplaced Pages readers, English is a second language. It might be easier for someone who is not fluent in English to understand 18th century than eighteenth century. --Gerry Ashton 22:11, 7 July 2007 (UTC)
If someone is having that many problems, wouldn't the simple English wikipedia be better for them? I did think that the English wikipedia was for people fluent in English. Awadewit | talk 22:37, 7 July 2007 (UTC)

Contradiction

  • Nothing against (at least) allowing for centuries to be spelt out (note, however, that their corresponding article titles are not) but I see not reason that we need conform to either MLA or Chicago. Jɪmp 15:16, 8 July 2007 (UTC)
  • I thought that we were aiming for "professional" writing standards. MLA or Chicago is one way to define them. Right now, the MOS is not really a MOS since so much of it simply says, "do what you want, within reason and consistently". It would really be best if wikipedia had an in-house style. MLA and Chicago are the most common. That is why I used those. They are also the two most cited in debates at FAC, etc. Awadewit | talk 21:22, 8 July 2007 (UTC)
  • We are "aiming for 'professional' writing standards." I would agree. "MLA or Chicago is one way to define them." I would agree with this too (emphasis added). I don't know that an MoS becomes more or less of an MoS by becoming more or less prescriptive but in this case perhaps stricter rules might help. Yes, it would be best if Misplaced Pages had an in-house style ... that's what we're working on but it'll be Misplaced Pages's style not someone else's. This should be arrived at through consensus of Wikipedians not simply by reference to some other style guide. Quoting other style guides is all well and good as a step towards reaching such consensus but should not be used in place of it ... not that I'm accusing anyone of so doing (one way of gaining consensus it to throw something on a page and see how long it stays). Note also that I'm not opposing your edit: I'd suggest where ordinals can be spelt out in one or two words they generally should be within text. Jɪmp 04:33, 9 July 2007 (UTC)
A MoS is supposed to be prescriptive, by definition. Consensus usually does not achieve a prescriptive style (note wikipedia's current MOS and this discussion which seems to be drifting off topic slightly). It is helpful to rely on other style guides which ponder these questions much more deeply than we. Awadewit | talk 05:27, 9 July 2007 (UTC)
I s'pose I meant to refer to how much detail the prescription contains. Is it better for an MoS to be more detailed in its prescription? Perhaps consensus does usually "not achieve a prescriptive style" but this is not to say that it cannot. Where it does not succeed, though, you've got to ask why. Is it that parties cannot agree, is it that no one could be bothered, is it that consensus is against a prescriptive approach? For better or worse, though, this is how its done here. It may be helpful to refer to other style guides which may indeed have a greater depth of ponderance but these are no substitute. We are getting off topic, yes, but I did mention I'm not against your edit itself. I reckon that Art LaPella has a very strong argument: this page specifies spelling intergers from zero to ten out & doing the same for ordinals as for cardinals since century names from the tenth BC to tenth AD contain ordinals this entails their spelling out. As for the likes of the twenty-first century, is this any worse than writing 21? I would say that it isn't and so if we've got 21, then we'll have to cop 21st century. My argument is, though, that we needn't have to have 21 either. I fail to see any logic in stopping at ten. It had been mentioned before that an alternative might be to spell out those numbers which can be written as one or two words. Yes, there's an example of consensus' failing: the topic was archived and we're still stuck with ten. It can, of course, be brought up again & I think I might ... Jɪmp 07:07, 9 July 2007 (UTC)

Dates are usually considered separately from other numbers (I don't know why, but they are). One of the reasons that I mentioned these other style guides in the first place is because they define professional writing. When I see "21st century" I recoil in horror. Such typography does not appear in professional prose (at least in the humanities). However contradictory it may seem, that is the way it is - dates are treated differently. I simply wanted to raise the issue that wikipedia's MOS reflects an unprofessional style. Awadewit | talk 07:16, 9 July 2007 (UTC)

Everything else

Incorrect use of unit name for quantity (e.g. 'horsepower' to mean 'power').

Moved from my talk page:

Is there a reason you are changing almost all instances of "horsepower" to "power" as in Triumph Speed Triple? While it is not an SI unit, it is generally acceptable and understood when referring to automobiles and simialr vehicles. Mr.Z-mantalk¢ 04:04, 6 May 2007 (UTC)
It is strange that all edits have the same summary, (copyedit), and they are all marked minor even though they aren't really minor edits at all. Changing every instance of "horsepower" to "power" isn't a minor edit. IrishGuy 23:16, 6 May 2007 (UTC)
I am not changing almost all instances of horsepower to power. I am changing instances where the meaning is for the quantity not the unit. Editore99 15:17, 6 May 2007 (UTC)

Using a unit name to describe a quantity is wrong but it happens occasionally. Saying an something has 'more horsepower' or 'more watts' really means it has 'more power'. Similarly saying 'more pounds' or 'more kilograms' really means 'more weight'.

An edit in those cases seems unremarkable and uncontroversial to me. But Mr.Z-man and Irishguy say they do not want the word power to be used in those cases. My edits were reverted. See the example given above by Mr.Z-man or search wikipedia for 'more horsepower'. Can others comment please? Editore99 11:46, 9 May 2007 (UTC)

In the automotive sense, I think "horsepower" is correct. For example, the standard engineering terms are shaft horsepower, brake horsepower, and rear-wheel horsepower, not shaft power, brake power or rear-wheel power. This is acknowledged in the introductory paragraph of the Horsepower article: "the idea of horsepower persists as a legacy term in many languages, particularly in the automotive industry for listing the maximum power output of internal-combustion engines." Brianhe 21:54, 9 May 2007 (UTC)
That is not the issue being debated. Please look at the example quoted by Mr.Z-man above. Editore99 05:31, 10 May 2007 (UTC)
Although either makes sense, in normal automotive usage "horsepower" is preferred. -- 23:28, 20 May 2007 (UTC)
Firstly, please sign your comment. Secondly say whether you have read the example quoted by Mr.Z-man above. Editore99 16:58, 21 May 2007 (UTC)
Firstly, I did sign my comment, but mistyped the number of tildes, and yes, I did read the example. My comment stands. -- Arwel (talk) 21:56, 24 May 2007 (UTC)
I side rather with "power" - because although "horsepower" is perfectly acceptable English "power" is less idiomatic. We are writing for a general audience. Rich Farmbrough, 12:30 2 June 2007 (GMT).

Superscript "th"

What is the policy on superscripting the "th" in special numbers such as "4th" and "8th"? Is the superscript required or not? I apologize if this is already mentioned in the article. BlueAg09 (Talk) 06:29, 22 May 2007 (UTC)

Good question. I don't think it is mentioned, but my personal view is that the superscript is unconventional, and so shouldn't be used. I realise this may be due to outdated limitations of typewriters, but that seems to be the convention nonetheless. Stephen Turner (Talk) 10:05, 22 May 2007 (UTC)
I also think that if there's consensus, it would be worth adding a bullet point about this. Stephen Turner (Talk) 10:06, 22 May 2007 (UTC)
One more thing. Small numbers are best spelled out in most contexts: fourth and eighth. This applies to ordinal numbers just as much as cardinal numbers. Stephen Turner (Talk) 10:09, 22 May 2007 (UTC)
I agree that there should be a bullet point about the ordinal superscripting. In fact, I found many university publications on style that mention this: Columbia, Davidson, and MIT to name a few. Search for "superscript" in each of these publications and you will be able to find the rule against superscripting ordinals eventually. BlueAg09 (Talk) 09:43, 23 May 2007 (UTC)
Why would this situation ever come up? Wouldn't you always fully spell out the ordinal in words? nadav (talk) 09:47, 23 May 2007 (UTC)
Only ordinals 10 and below (first, second, third, etc.) should be spelled out in words. Numbers greater than 10 should be written in numerals. BlueAg09 (Talk) 09:52, 23 May 2007 (UTC)
After seeing the links you provided, I fully support disallowing use of superscripts for ordinals. nadav (talk) 11:06, 23 May 2007 (UTC)
FWIW, & IIRC, BlueAg's suggestion is supported by the AP style guide. Actually, what I remember is that the AP style guide mandates spelling numbers 10 & below; the ordinal form follows logically. -- llywrch 20:16, 23 May 2007 (UTC)
Yes, I believe you are right; the AP style guide disallows the superscript use. I found a website that seems to have AP style guide rules. BlueAg09 (Talk) 22:01, 23 May 2007 (UTC)
Where would be a good place to add this information? BlueAg09 (Talk) 01:17, 24 May 2007 (UTC)

Everyone seems to be happy with this, so I've added it. Feel free to copy edit it if necessary. Stephen Turner (Talk) 09:59, 25 May 2007 (UTC)

Page protection

In light of today's reverts, perhaps it is time to apply Full or Semi-protection to this section of the MOS. I know there are pros and cons associated with such an action, but I thought I'd float the idea out there to see how others feel. Do you have any thoughts on this? —MJCdetroit 18:22, 22 May 2007 (UTC)

It's an important page; it's a bit disconcerting if its advice changes every few minutes. It seemed fairly obvious that there were 5 or 6 anons making similar edits so I'd be in favour of semi-protection. There might well be a case for full, with some consensus being required before changes. -- roundhouse 19:25, 22 May 2007 (UTC)

Plural for fraction of a unit?

What happens when you use a decimal or fraction, eg 0.6 kilometers. Should the units be plural or singular? There is some disagreement about this. nadav (talk) 05:58, 23 May 2007 (UTC)

If you're spelling out the word, I think it would be pluralised: "0.6 kilometres". But note that the symbol is never pluralised: "0.6 km". Stephen Turner (Talk) 08:58, 23 May 2007 (UTC)
Yes, the abbreviation info is in the guideline. I would like the guideline to specifically address the situation where the full word is used. And I share your opinion. nadav (talk) 09:22, 23 May 2007 (UTC)

Anomaly in example

This section states "Distinguish between the different interpretations of ton by calling the metric unit either tonne or metric ton. However, the following section gives an example of "… between 2.7 and 4.5 tons". Is there a reason for this anomaly? – Tivedshambo (talk) 09:24, 4 June 2007 (UTC)

Yes, those would be "imperial" or "customary" tons. Rich Farmbrough, 16:28 4 June 2007 (GMT).
So ton by itself should always refer to imperial ton, never 1000kg? Would the average reader know this, or would it be better to state that "ton" should always be preceded by "metric" or "imperial"? Also as an example it's confusing as the previous example gives the same weight in kg, which converts to 2.7 and 4.5 metric tons, not imperial tons. – Tivedshambo (talk) 17:27, 4 June 2007 (UTC)
I'd say that ton by itself should never refer to 1 Mg but this is not to say that it should always refer to the imperial ton. There are (or at least till recently were) two (non-metric) tons in use: 2240 lb & 2000 lb. These can be distinguished by adding long or short. 1 Mg is usually called a tonne but, I'd say, if you wanted to call it a ton, you should add metric. Of course, context may make the distinction unnecessary. I've rewritten the point, hope it's clearer. I've also removed the example mentioned, it wasn't adding anything anyway. Jɪmp 18:15, 4 June 2007 (UTC)
(Edit Conflict...hey that's what I was gonna say...) To make it even more confusing (but more correct), there is a short ton (2,000 lb), which is a common to the U.S. and a long ton (2,240 lb), which is common to the U.K.. I think that the spelling matters too— ton vs tonne. Where ton can be either short or long but that tonne refers to the metric tonne. My suggestion would be to use short ton, long ton, and metric tonne in the article or at the very least link to the respective articles e.g. ]. I also think that we should always use metric with tonne. —MJCdetroit 18:32, 4 June 2007 (UTC)
That's a lot clearer - thanks. – Tivedshambo (talk) 20:33, 4 June 2007 (UTC)

Mixing English/SI units in a single article, a single sentence even

One irritating thing not covered in this is using consistent units throughout an article. Why is it so important to use a consistent English dialect throughout an article, yet there's no issue with writing articles that mix SI and American unit orders in the article, because, after all, one should default to what the source says? so, you use 25 sources on a good science article, you could have a dozen or more changes, even using SI first and American first in the same sentence if you quote two sources. This is absurd. KP Botany 04:30, 8 June 2007 (UTC)

It says only when editors can't agree/there is a historical or pragmatic concern. So if we all get along, it should work out fine. Cquan 05:04, 8 June 2007 (UTC)
But I don't agree at all to using mixed units within the same sentence in an article, to mixing the units within an article, either. This simply makes it confusing, partilarly, as I pointed out, when talking about a broad topic. Your method makes tables that have 3 numbers in metric, one in American, another table has 4 numbers in American, and one in SI, another has 3 numbers in American, one in SI centimeters, one in meters. When people read a single article, they have the right to expect that throughout the article the first number will be SI or the the one in parantheses will be SI. This is fairly standard writing style. I know Misplaced Pages does some things different, but to change a sentence to use English weights and measures for the first two instance, with metric in parentheses, then to use SI alone in the third instance is absurd. To have a table list the first measurement in meters, the next three in feet, and the last one in centimeters (probably should be centimetres) is absurd. It makes for a crappy article that strains the reader's ability to follow accurately. When a settlement makes an article less worthy, or downright crappy, it's not a vialbe solution. But, go ahead, change all everythign so it reflects the source. KP Botany 05:11, 8 June 2007 (UTC)
Um...unless I'm losing my sight, I'm pretty sure I said "only when editors can't agree". IMHO, you're blowing this out of proportion...you're absolutely right, mixing all over is a bad idea and the MOS reflects that in saying to stick to a single convention, but it also provides for exceptions as most rules should. This is a very particular case and can even be circumvented (presumably) by gaining a consensus one way or another since the MOS is just a guideline and not policy. Cquan 05:16, 8 June 2007 (UTC)
But it can't be circumvented by gaining a consensus when one editor opts to edit war instead of discussing the issue. Also, frankly, the entire article has to be considered when deciding these things, not just one sentence--that's why the policy for being consistent is so important in at least part of the MOS--because that's how you wind up with a cohesive readable article. Try editing at FAC for a while, and you'll see what I mean, how hard it is to read these articles where one editor unilaterally decides that a single sentence must be one way no matter what. These articles get sent packing from FAC. Why not let Tree be readable? KP Botany 05:32, 8 June 2007 (UTC)
I swear, I won't try so hard for a compromise again. Personally, I'm with you on the consistency thing (and I HATE english units anyway, despite being American). Since there was (what I thought to be) clear guidance on the issue, I decided to opt to that before wholesale going one way or another...oh well. Cquan 05:41, 8 June 2007 (UTC)
No good dead ever goes unpunished. Any American who has ever had to figure out ounces in a gallon or convert quarts and pints hates them. KP Botany 20:22, 8 June 2007 (UTC)
While I agree that the units should be used in a consistent order, I would also support not including the converted numbers themselves in the wikitext, but instead use the {{convert}} template. Measures are often rounded, especially when divisible with 10, and converting them can indeed lead to false precision. It would be best not to include converted numbers as such in the wikitext, but imply by use of this template that they has been converted. "40 feet" for example can be automatically converted to "40 feet (12 m)" with {{convert|40|ft|m|0}}. The template seems to have been discussed at the administrators' noticeboard as unwanted, but they didn't make this particular point. --Para 06:13, 8 June 2007 (UTC)
This, again, is an issue that we would not face if we had kept our preference of SI units. Any other unit including English ones – be they US or UK – should only appear if it is the defining source unit. This applies to articles on the units themselves and where they are used to set a standard, e.g. “American football is played on a rectangular field 120 yards (110 m) long”, but not when they are used to measure, e.g. “Mount Rainier (…) is the highest peak in the Cascade Range at 4,392 metres”, no matter what unit the selected source used. Christoph Päper 11:07, 8 June 2007 (UTC)
Yes, it would have been easier had Misplaced Pages simply gone metric--it's not as if Americans, of all people, are unusued to converting. I believe the arguments used to include American units neglected the fact that SI units are taught in every accredited K-12 school in the United States and are used in all of our textbooks. Nut with American units in, you're always going to run into these situations where one person rampantly demands their inclusion in some part of an article, or some part of a sentence as in this case. KP Botany 20:22, 8 June 2007 (UTC)
It may have been easier for you, if Misplaced Pages was metric only, but not for all. The same is true for the many articles about American subjects that have do not have metric units in them. Displaying both systems gives a fuller/richer sense of understanding to readers who do not "think" metric (even if they were taught it in the 6th grade) or "think" in pounds, feet and fahrenheit. A reader should not get to a part in the article on Mount Rainier and ask themselves, "what's 4,392 meters? Damn it now I have to convert. This website sucks". Just as a reader from Europe might ask themselves, "What is 14,409 feet? Jetzt muß ich umwandeln. Diese Web site ist schrecklich" It's unfair to the reader either way.
However, the original gripe was that an editor was not allowing the unit order to be changed for the sake of being consistent through out the article in much the same way as the American English/British English is done. This editor was doing so because the MOSNUM says to place the source unit first; sometimes English, sometimes metric. I believe that as along as there are citations given for the measurements, then the editors of an article should be able to make the order of units consistent to their liking with guidance from the MOSNUM. If the article is a general subject dealing with an American or British subject then the unit order should be English (metric). Many articles are pretty much already done this way anyway.
Also, I agree with Para, we should encourage editors to use one of the conversion templates found at Category:Conversion templates —MJCdetroit 01:28, 9 June 2007 (UTC)
The funny thing about this discussion is that almost never someone shows up and says that he needed or wanted US customary units – there is never ever any reason to include a conversion to imperial measurements –, it’s always about some of his fellow citizens who might need them. The essential difference between metric and English units relevant here is that virtually everyone knows enough about the former to justify their exclusive use in any international project (and they are legal everywhere for almost all purposes) – and those who actually don’t know enough metric are unlikely to use an electronic encyclopædia anyway. (Yes, that last argument is almost as weakly founded as the basic opposing one.) Christoph Päper 11:39, 9 June 2007 (UTC)
Yes, it is weak all around. More universal or less universal— plain and simple. First, not everyone who reads articles in wikipedia, edits those articles. I know I didn't for a very longtime. Secondly, not everyone who edits wikipedia knows that this little section of the MOS even exists. Therefore, they may just express their views on units at a local talk level. Here are some examples at the local talk level that I could think of where someone wanted either the US measurement listed first, metric units not listed, or US units added to a metric only page: 1, 2, 3, 4. An article should be relative and understandable to the reader of the article; no matter where they call home. More universal or less universal— plain and simple. —MJCdetroit 18:18, 9 June 2007 (UTC)
Well, plain and simply is not going to happen with users here suggesting that one can list SI first followed by American throughout most of an article, then change to a single sentence in an article with some 20 other uses of measurements, and list English first, followed by SI for two instances in the sentence and SI only in the third instance in the same sentence. The entire reason that being consistent is firstmost in importance when dealing with various styles is that you confuse and mislead readers and cause them to focus on a minute detail, "Oh, here it's English units first, then metric, maybe I read the rest of the article incorrectly," rather than focusing on the content--"Wow, Darwin found a big one of these, I wonder if his measurement is correct considering how much larger it is." Instead, the article is about one single editor's decission to rewrite a single line of a single article to worthlessness. KP Botany 19:03, 9 June 2007 (UTC)
In the article in question, Tree, it looks like the editor wanted to keep the Darwin statement as the source stated it— 130 feet (39.6 m). As I stated earlier, if there are references for the measurements (as there are in that article), then I would not oppose editors of an article placing the units in a consistent order. In that article it would be metric (English). Maybe we should give better guidance in the MOSNUM to allow this. :) —MJCdetroit 03:01, 10 June 2007 (UTC)
This is not the only place in the article where units are used--it is simply the only sentence where they are given English first, then SI second for the first two instances, then given in the third instance as SI only. There are other sources quoted in this article which variably use SI or English first in the source. So, the question remains, which everyone keeps dancing around, should units be given in consistent order throughout an article rather than change ways throughout the article. If you go by sources, this article would require some dozen changes of order of units. Try to understand, it's not about the ONE sentence, it's about continuity in the article. KP Botany 03:21, 10 June 2007 (UTC)
I went through the whole article and double checked all the references dealing with the measurements. I properly formated the references using Template:Cite web and quoted the original unit of measure in the "quote" parameter of that template. That being done, all units were placed in the metric (English) order throughout the article. With all original units being referenced and "quoted", all metric units were displayed in same unit (meters) even if the source unit was centimeters. I think that we can use this article as a test to give better guidance on continuity in an article where many different types of measurements are used by the sources. —MJCdetroit 06:57, 10 June 2007 (UTC)

Units of measurement

The guidelines currently say to "spell out units in text". That works fine for something like "Template:Ft to m", but is this also how multi-dimensional conversions are supposed be formatted? Consider, for example: 

2 feet × 5 feet (0.6 m × 1.5 m)

Somehow it does not look right. Would 

2 feet by 5 feet (0.6 m × 1.5 m)

be more correct, as far as the MOS is concerned? I would appreciate an advice regarding this.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 02:20, 16 June 2007 (UTC)

The second one looks more correct to me because the X in the first is a symbol to represent by. In my dialect of English it is always spoken that way. MJCdetroit 18:17, 18 June 2007 (UTC)
Thanks. Perhaps this MOS should be updated to mention this?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 18:22, 18 June 2007 (UTC)
I don't think the MoS needs guidance about this. It can be sorted out on a case-by-case basis if necessary. Stephen Turner (Talk) 21:34, 18 June 2007 (UTC)

Units of measurement abbreviations

Surely it would make sense to spell out the name of a unit only the first time that it is used in the text of a given article, since short forms are well recognised, and the long forms are, for SI units particularly, cumbersome Sammalin 15:06, 23 June 2007 (UTC)

Listing order for people's names

Hello all. I don't know if this has been proposed before, but to make entries easier to find I think that the the listings on dab pages of people's names should be in order of age, oldest to youngest, i.e. the oldest birth years on top and the youngest birth years on the bottom. That should not only make the page easier to navigate, but should also reduce the incidence of duplicate listings. Thoughts? —Elipongo (Talk contribs) 22:48, 24 June 2007 (UTC)

The question should be resolved on the talk page for MoS:DP instead of this page, but the guideline already considers that as an option. The overriding consideration, however, is usefulness to the reader, not uniformity, so you will meet resistance from other editors who have arranged the entries with the more frequently linked people at the top. Chris the speller 02:32, 25 June 2007 (UTC)
I had thought I WAS on the Mos:DAB page. I just went looking for the conversation now and couldn't find it and had to dig around in my history. I think I had both pages open on separate tabs and got confused as to which tab I had open. Sorry for bringing in an off topic debate! —Elipongo (Talk contribs) 11:43, 25 June 2007 (UTC)

Coordinates, again - time to deprecate 'coor *' templates

Now that Google Earth have confirmed that they are parsing {{coord}}, and WikiWorld and Geo Names have said that they will do so, are people content to restore the wording removed in this edit, deprecating the older coor * coordinates templates? Andy Mabbett 14:56, 26 June 2007 (UTC)

Put it another way: I shall do so, shortly, unless anyone objects. Andy Mabbett 16:41, 27 June 2007 (UTC)
Do we have a real world in the wild example of {{coord}} actually being parsed and appearing in the wild? If not, it is too early. Regan123 17:43, 27 June 2007 (UTC)
I fail to see why that's a requirement. Andy Mabbett 17:52, 27 June 2007 (UTC)
How do we know it is working until we can see an example. Therefore I object until one is seen. Regan123 17:57, 27 June 2007 (UTC) Additonal: It appears that {{coord}} has not made it over to Google Earth yet. See . Regan123 18:01, 27 June 2007 (UTC)
See http://earth.google.com/userguide/v4/geoweb_faq.html Andy Mabbett 18:26, 27 June 2007 (UTC)
I have seen the FAQ. There is still the issue that coord is not actually shown to be working with Google Earth in the wild, unless you have an example that shows that it is? When that can be shown then depreciation, conversion, deletion and amending the MOS is not an issue. At the moment it is. Regan123 18:41, 27 June 2007 (UTC)
We do have examples in the wild of {{coord}} showing up in geonames (Para captured one - Netherton Tunnel Branch Canal) plus http://earth.google.com/userguide/v4/geoweb_faq.html (which announces that coor has been deprecated by Misplaced Pages, rather to my surprise) so I am content to accede to the restoration of the wording per nom. (I think conversion and deletion need an overall plan as adumbrated on AM's talk page by the Anome, which I would also support.) -- roundhouse0 20:19, 27 June 2007 (UTC)
Curiously that particular article is no longer visible in GeoNames service, though some others with coord are. The disappearance may be related to a bug on their side where they weren't showing the most important coordinates from the article, but the first found. Anyhow, people are mostly interested of Google's support, and Google Earth doesn't show any of the coordinates that have been on Misplaced Pages with coord only. On the support they have said that "We can make our parsing tools recognize the new template; however, we definitely do not want our decision to support this template to be misconstrued as an endorsement or ultimatum." The arguments here shouldn't then be that Google is recommending the template, but that they are now supporting it. We seem to have trouble agreeing on what "support" actually means.
Almost everyone involved in this so far has agreed that we should help maintain the quality of Misplaced Pages data in notable external services, and that's why we're talking about it here. Basically we could deprecate a data entry format with external dependencies when a) a wikipedian says that an external service is planning to support the new template, or b) when an external service announces that they are planning to support the new template, or c) when an external service announces that they are currently supporting the new template, or d) when we can verify that an external service is supporting the new template but seems to be struggling, or e) when we can verify that an external service is correctly supporting the new template in all the use cases we have.
Personally I would go somewhere after c, where we actually are now for the most part. Our database dumps are so few and far apart that if someone has problems changing their parser, it may push our migration months forward. In this case that might not matter though, as the change isn't critical. I'm just disappointed on how the new template has been allowed to spread without ensuring the support before. With Google Earth we're currently in the situation where the new coordinates added using coord are not visible to the users, and it's also uncertain what has happened with coordinates that have been converted from the current templates to coord. But that's where we are now, and it wouldn't be very convincing to pretend that we can keep a narrow field such as geographical coordinates under control, when we have seen how people determined to get their way through really can do so. What the Manual of Style says now as a guideline isn't going to change a whole lot one way or the other. --Para 23:46, 27 June 2007 (UTC)
"The arguments here shouldn't then be that Google is recommending the template" - See http://earth.google.com/userguide/v4/geoweb_faq.html Andy Mabbett 08:58, 28 June 2007 (UTC)
What's written in the FAQ is just a misunderstanding of what's going on in Misplaced Pages, based on what a single wiki contributor out of hundreds of thousands has told them. They may just be far-sighted and don't want to constantly be updating the page to reflect the state of an everchanging community. So far nothing has been deprecated and the only Google person who has communicated with us has said that "we definitely do not want our decision to support this template to be misconstrued as an endorsement or ultimatum". Therefore you must not use anything from Google to endorse deprecation. The issue here is whether for us support means a public announcement of it or our verification of the data being visible. --Para 11:54, 28 June 2007 (UTC)
"based on what a single wiki contributor ... has told them" - really? Who's that? Google have said more than once that they're parsing coord, and are happy for us to start converting existing coor * templates to coord. That's a matter of record. the argument for deprecating coor * templates in favour of coord is that coord offers far greater functionality for our editors and users. That should be enough, but some wanted to wait until Google Earth and other external bodies were aware of, and then until they were parsing, coord. Now that they are, they seem to want to introduce further, unnecessary, delays. Andy Mabbett 12:09, 28 June 2007 (UTC)
This is not about how Google feels about the template, they're not part of Misplaced Pages. The community here wants to see the data in Google's service, and so far none of it is there, despite it having been available in all the database dumps since April. The single contributor who has agressively pushed the change forward regardless of support or its absence would be you my dear Andy. You could have avoided all this if you had just discussed with the community in the beginning of the terms of the change and tried to reach consensus, instead of ignoring them and then pretending to be representing the whole of the community with your personal opinion. The delay may feel unnecessary to you, but as you have seen repeatedly, it is not for others. --Para 12:31, 28 June 2007 (UTC)
"This is not about how Google feels about the template, they're not part of Misplaced Pages" - quite, which is why (that fact we know that they're aware of coord, and have said they will parse it, not withstanding), we should go ahead on the basis described by SEWilco, below. I have been discussing coord and trying to reach consensus for some time now; it's difficult to do so when the goalposts keep moving, as I've recently described, and when a handful of editors keep making unfathomable or simply false claims about what's proposed. Andy Mabbett 13:30, 28 June 2007 (UTC)
Coord follows no standard, it's just an improvement over the existing templates, and unrecognised at that. Had you tried to reach consensus at first before starting to apply coord in articles and templates, you could always refer to that discussion and its goals, pointing out that that's what the community wants. Instead it's all in bits and pieces everywhere of the shortcomings of the template and about it having been applied prematurely. The discussions always get sidetracked and you never try to direct it back to the original propositions. Such discussions show no consensus. It is very tiring to have this bickering every time you try to move forward with whatever it is you're doing. I can just see you insisting on doing the eventual conversion little by little starting as soon as possible, instead of all at once after a long discussion somewhere. Disagreeing people will come in trickle and you end up defending your position over and over again without anything to back it up with, but still go ahead with the project. Oh yes, my crystal ball is mighty, and I for one want nothing to do with all that. --Para 16:21, 28 June 2007 (UTC)
Coord both follows standards and is a standard. Of course it is "recognised"; and I did reach consensus first. I agree with you about the tiresomeness of the bickering; feel free to stop at any point. If your arguments rely on a crystal ball, don't expect me or anyone else to be swayed by them. I can't see how your edit summary, "AM fails" is either meaningful or helpful. Andy Mabbett 16:33, 28 June 2007 (UTC)
Or we just use coord because it follows a standard, whether an external service is presently using the information or not. (SEWilco 00:16, 28 June 2007 (UTC))
Amen! All the services concerned are aware of that standard, have said that they will use it, and in the case of Google Earth, have said that they are happy for us to convert existing coordinate templates to it. I still fail to see why we are delaying the provision of {{coord}}'s extra functionality to our many users. Andy Mabbett 08:58, 28 June 2007 (UTC)

Whatever it's worth, there seems to be some misunderstanding by the author of http://earth.google.com/userguide/v4/geoweb_faq.html as Misplaced Pages hasn't really depreciated the other templates.

Either solution would still need to address the problem of {{coor dms}} or {{coord}} being used within other templates. In these cases, {{coord}} just adds a lot of overhead and formatting problems, but it's unlikely that it's being parsed by anyone.

A solution, formulated by sk on Wikipedia_talk:WikiProject_Geographical_coordinates#Formats, is to standardize variable names (e.g. "latitude_degree") to indicate coordinates in other templates, such as Template:Geobox Settlement (which currently uses lat_d, lat_m, lat_s, lat_NS, long_d, long_m, long_s, long_WE). -- User:Docu

Meersbrook (53.353889,-1.472778) tagged with coor title d by Anombot2 on March 14 and then subjected to a struggle between coor title d and coord, doesn't seem to show up in either geonames or Google Earth. Sheffield Cathedral (53.383,-1.4694), which I changed from coor title to coord on May 18, also shows on neither. (Google Earth has added a lot of Sheffield tags in the last week, eg Fargate, coor title d, April 17.) An example of coord showing up unequivocally on Google Earth would certainly be handy. -- roundhouse0 08:15, 28 June 2007 (UTC)
why would it? Andy Mabbett 08:58, 28 June 2007 (UTC)
I withdraw the support given above, as AM persists in turning a blind eye to objections. -- roundhouse0 12:15, 28 June 2007 (UTC)
Oh FFS! To what objections do you think I have "turned a blind eye"? The evidence cited in your now struck-through post remains: We do have examples in the wild of {{coord}} showing up in geonames (Para captured one - Netherton Tunnel Branch Canal). Andy Mabbett 12:21, 28 June 2007 (UTC)
"In these cases, {{coord}} just adds a lot of overhead and formatting problems" - please don't make such claims, without substantiating them. -- Pigsonthewing
The formatting problem was acknowledge by Pigsonthewing himself here and the overhead question raised on here, but eluded by pigsonthewing as well. -- User:Docu
What I said about the supposed "formatting problem" was: "This is a bug with the template's use of font-size:90%. Please fix that and do not remove microformat markup as a work-around." In the end, I did fix it, but you reverted that. I "eluded" nothing; you asked if something was a problem, and nobody seemed to think it was; though I pointed out to you that "it would seem far more sensible for any concerns you may still have to be raised on the template's talk page, where the author of the template is more likely to see them". Did you do that? Andy Mabbett 11:18, 28 June 2007 (UTC)
"it's unlikely that it's being parsed by anyone" - that's already provably false. You keep making false claims about coord. Why? Andy Mabbett 08:58, 28 June 2007 (UTC)
Why is that claim false? You already avoid responding answering to questions about {{coord}} being used directly in articles, so why do think using {{coord}} on Templates would work? Are there any users who claim they would support it? -- User:Docu
Just a few entries above your claim is roundhouse0's post time-stammped "20:19, 27 June 2007 (UTC)". If you think I've failed to answer any questions about coord, please point them out and I shall do so ASAP. Using coord on templates does work. Why would you think otherwise? Many users do support it, not least in this section of this page. Andy Mabbett 11:18, 28 June 2007 (UTC)
Google doesn't. Googel even claims it's "depreciated" to use coordinates on article in any other template on articles, but {{coord}} - odd no? -- User:Docu
<sigh> Google does'. See http://earth.google.com/userguide/v4/geoweb_faq.html Andy Mabbett 11:26, 28 June 2007 (UTC)
Would you provide us with a quote explaining that google does support using {{coord}} on Templates? -- User:Docu
See http://earth.google.com/userguide/v4/geoweb_faq.html Andy Mabbett 11:41, 28 June 2007 (UTC)

This FAQ does not say that Google supports using {{coord}} in templates. Since this is also an issue for other geo data consumers I think sk's approach is worth considering. I think it is premature to change this MoS until it has been decided whether to use that approach. -- Patleahy 16:00, 28 June 2007 (UTC)

The cited FAQ makes it abundantly and unambiguously clear that coord in other templates is parsed by Google Earth. sk's approach is untenable, for the reasons given at the link you cite. Andy Mabbett 16:36, 28 June 2007 (UTC)
Let me re-iterate my request, would you provide us with a specific quote from the FAQ, rather than just an URL? -- User:Docu
"This template can be used anywhere within the article text.". My emphasis. Andy Mabbett 16:58, 28 June 2007 (UTC)
"article text" = Article namespace. -- User:Docu

Accuracy of coordinates

Pardon me for jumping in here. I have not been following this discussion, and am unsure whether this is the proper forum for raising an objection to the current usage of coord. Perhaps what I have to say will be relevant to the ongoing discussion & reevaluation. I have found that the coordinates published in Wiki for many high-rise buildings are seriously incorrect, compared with NGS benchmarks, surveyor measurements, GPS measurements, and the FAA & FCC databases. This is apparently because the "coord" information has been derived from Google Earth. The latter has a notorious parallax problem with high-rise structures due to not looking straight down on these structures. Centering on a rooftop will generally give a considerable error. (Somewhat better accuracy is achievable using a building's footprint, when that is sufficiently visible). The illusion of great accuracy is given when the coordinates are stated to the hundredth of an arcsecond, but what use is that when the error can be two full seconds or more? If I substitute well-established NGS, FAA and/or FCC coordinates for the erroneous ones, will my edits only be reverted by a robot? Am I misleading users of Google Earth who will expect the erroneous coordinates, in order to facilitate locating the structure? That would seem a case of the tail wagging the dog. Shouldn't we be providing the best available information, regardless of possible impact? Hertz1888 23:33, 28 June 2007 (UTC)

This is better discussed at Misplaced Pages talk:WikiProject Geographical coordinates (feel free to move my comment). I agree with everything you said, though Google Earth certainly isn't the only source for our coordinate data. Perhaps the footprint part would actually be on topic in the Manual of Style as well? It would be best if any automatic changes would first compare the distance of the two points and put differences too long on the talk pages instead. Could there be a database rights issue with the use of the whole of such data though? Anyhow, please continue at the project talk page. --Para 00:02, 29 June 2007 (UTC)
Note also that WikiProject Geographical coordinates has a section on issues of precision. Andy Mabbett 09:05, 29 June 2007 (UTC)

Thank you both, Para and Andy. I will pursue as time permits. Clearly the global or generic implications of this issue are far-reaching, when the question of automated reference to databases is brought in (well beyond the scope of my original query). For all its easy access and convenience, Google Earth and its cousins seem to have brought with them a tendency for overdependence. When coordinates are derived by centering on portions of structures well above ground level (e.g., rooftops or spires), and the camera was not directly above the structure, the results will inevitably embody gross errors. Hertz1888 01:04, 3 July 2007 (UTC)

On re-reading your original comment; I should also point out that the issue is not related to {{coord}} and applies equally to the old coor * templates, and indeed any others which use coordinates. Andy Mabbett 14:46, 5 July 2007 (UTC)

Misplaced Pages has announced that Google Earth supports coord

Note also that Misplaced Pages itself has now announced that Google Earth supports coord. Andy Mabbett 14:46, 5 July 2007 (UTC)

Please see Template_talk:Infobox_UK_place#Google_Earth_compatibility:_geotags_are_invisible Regan123 17:14, 5 July 2007 (UTC)
Thank you. I have done, and have replied there. My point remains: Misplaced Pages has announced that Google Earth supports {{coord}}. Andy Mabbett 19:26, 8 July 2007 (UTC)
We have articles using coord that have vanished from Google Earth. Regardless of what they say, evidence these articles have reappeared is needed before changes. Regan123 20:38, 8 July 2007 (UTC)

It looks like the Misplaced Pages Signpost got it somehow wrong as Google doesn't claim to support {{coord}} within templates. -- User:Docu

I refer you to my earlier refutation of your fallacious belief. Please stop spreading FUD. Andy Mabbett 08:07, 9 July 2007 (UTC)

Standardize names for coordinate variables in template namespace

Following the lenghty discussion above, please see a proposal for a section to be added to MoS at Wikipedia_talk:WikiProject Geographical coordinates#Standardize names for coordinate variables in template namespace. -- User:Docu

(previous comment by Docu (talk · contribs) There is no consensus for this change, which was not included in the proposal at the above link. Andy Mabbett 14:16, 5 July 2007 (UTC)

minus signs

This page says:

The minus sign may be represented by a hyphen ("-") or by &minus; ("−").

The hyphen is far too short for that purpose. No respectable typesetter would use it. Compare:

5 - 3
5 − 3

Within TeX, of course one uses a hyphen, and the reader sees this:

5 − 3 {\displaystyle 5-3\,}

Michael Hardy 22:48, 27 June 2007 (UTC)

WP:DASH seems to agree with you. Stephen Turner (Talk) 08:55, 28 June 2007 (UTC)
Misplaced Pages editors are not, in the main, typesetters, respectable or otherwise. Andy Mabbett 11:27, 28 June 2007 (UTC)
See also: Misplaced Pages talk:Manual of Style#Minus signs Jɪmp 15:41, 28 June 2007 (UTC)

Roman numerals

The Transactions of the Linnean Society of London express their volume numbers in Roman numerals. Should I follow their lead and write:

"... and was published in Volume X of Transactions of the Linnean Society of London."

or should I convert to Hindu-Arabic:

"... and was published in Volume 10 of Transactions of the Linnean Society of London."

? Hesperian 04:42, 29 June 2007 (UTC)

  • Why not

    "... and was published in Transactions of the Linnean Society of London, Volume X."

    thereby making it clear that "Volume X" is their usage? Andy Mabbett 09:07, 29 June 2007 (UTC)
Nothing wrong with Roman numerals in my book. Go ahead. I like Andy's suggestion: not only would it be clear to readers that this is their usage but also to any editor who might otherwise feel like changing it to Hindu-Arabic. Jɪmp 23:55, 2 July 2007 (UTC)
Thanks folks. Hesperian 12:41, 9 July 2007 (UTC)

Metric/SI only

Why is their any allowance for non metric systems of measurement? Ancient units I can see, simply for historical purposes, but only the US still uses a system other than metric today; even they are starting to move over. Should not, due to the fact this is a global encyclopaedia, only use the metric system? Spacedwarv 07:19, 7 July 2007 (UTC)

Because the articles should be accessible to everyone. So it's appropriate, especially in articles about the U.S., to use units which Americans are familiar with. Of course, a conversion to metric should always be provided. Stephen Turner (Talk) 09:55, 7 July 2007 (UTC)
And another reason: it's usually correct to quote the units which the source used. Stephen Turner (Talk) 10:23, 7 July 2007 (UTC)
Also, many people from British commonwealth countries still don't "think" in terms of metric measurements, despite some of there governments being officially metric for years. To use only metric units would actually make the encyclopedia less universal. —MJCdetroit 19:52, 7 July 2007 (UTC)