Misplaced Pages

Revision as of 00:03, 11 April 2008

Archives

General 1, 2, 3, 4, 5, vote, 6, 7, 8, 9 (AD/CE), 10, 11, 12, 13, 14, 14a, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 49a, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161 Binary prefixes B0, B1, B2, B3, B4, B5, B6, B7, B8, B9, B10, B11, B12, B13, B14, B15, B16, B17 Years and dates D1, D2, D3, D4, D5, D6, D7, D8, D9, D10, D11, D12, D13, D14 See also Misplaced Pages:WikiProject Dates Misplaced Pages talk:Date debate Misplaced Pages talk:Naming conventions (calendar dates) Misplaced Pages talk:Timeline standards Misplaced Pages:Measurements Debate Misplaced Pages talk:Manual of Style (dates and numbers)/Date autoformatting Complete rewrite of Units of Measurements (June 2008) Dec. 2008 RfC on Date linking/autoformatting (three proposals) Dec. 2008 RfC on Date linking/autoformatting (detailed)

This page has archives. Sections older than 15 days may be automatically archived by Lowercase sigmabot III.

edit Years and dates archives

Archive D1 1.1 A new parallel syntax for autoformatting dates Archive D2 2.1 Date preferences and Jogersbot's massive undoing of edits Archive D3 3.1 What about date ranges? 3.2 UTC± Notation 3.3 Question 3.4 Clarification 3.5 Proposed 3.6 Misplaced Pages:Manual of Style (dates and numbers)#ISO date formats 3.7 AD/BC CE/BCE issues 3.8 Ranges of years 3.9 When did the year-without-date recommendations change? Archive D4 4.1 Comma in dates 4.2 Linking dates 4.3 Link only years? Archive D5 5.1 Default date display setting 5.2 Just following the rules, folks 5.3 Piped 'Year in xxx' links 5.4 Deleting year links 5.5 Year ranges 5.6 Misplaced Pages:Manual of Style (dates and numbers)#Years, decades, and centuries Archive D6 too many topics to link here, all related to date autoformatting, date autolinking, whether either of these should be used, or which date format to use in different contexts

General IT prefix discussion

The IEC prefixes were approved in January 1999. After nine years, virtually nobody uses them. Esperanto is in wider use. When Steve Jobs introduced the MacBook Air (skinny notebook) at Macworld he did not use the term gibibyte once. The news reports give the RAM size as 2 gigabyte, 2GB or 2Gbyte. The Manual of Style should reflect what the outside world is doing. The computer industry and the publishing world have ignored the IEC prefixes. -- SWTPC6800 (talk) 06:09, 17 January 2008 (UTC)

Do you have any opinion on the topic that is being discussed here? — Aluvus t/c 13:02, 17 January 2008 (UTC)

Yes I do. A few peoples here are trying to get the Manual of Style to adopt an obscure method of measuring computer storage. This edit war has been going on for several years. You are arguing over the rules of the edit war. The real question is should the Manual of Style follow a standard that had not reached 1% adoption in the real world after 9 years. -- SWTPC6800 (talk) 14:52, 17 January 2008 (UTC)

Just let me extract the interesting parts of your text: "few people", "an obscure method of measuring computer storage", "war", "1% adoption", "real world". Hopefully people will realize how pointless this discussion is. Don't waste your time, don't let them trick you. As long as this topic is under tight control of certain individuals, you can't win. Again don't waste your time with facts. They shall be ignored, absolutely, without remorse. --217.87.122.179 (talk) 05:57, 2 February 2008 (UTC)

You are wrong and do not attempt to misrepresent other editors with your incorrect anonymous rants about "certain individuals". Fnagaton 10:03, 2 February 2008 (UTC)

Whether manufacturers are using these units is irrelevant. Fact is that the units are used inconsistently. Sometimes they have a binary meaning, sometimes a decimal one. Many of the readers wil not be aware which meaning is applicable in a specific mention of the unit. Therefore it is the task of an encyclopedia to make sure the reader is able to draw the correct conclusion. This can be achieved by always adding a conversion to (or a confirmation of) a standardised and well documented unit. We achieved consensus to do it that way a while ago. According to the guidelines units from a primary source should come first. So the usage would be:

• with decimal meaning: 64 MB (61 MiB)
• with binary meaning: 64 MB (=MiB)

−Woodstone (talk) 19:42, 17 January 2008 (UTC)

Fact, KB, MB, GB are defined by standards organisation to be power of two. Fact, some manufacturers use other meansing. Lets say for the sake of argument some manufacturers started using KiB but in a decimal sense, that would be inconsistent use, so what then? It's not *always* needed though, just disambiguate (if you need to at all) the first occurrence in an article. Fnagaton 22:18, 17 January 2008 (UTC)

Regardless of how inconsistent sources are, a conversion to standard units would always tell the user unambiguously what the correct meaning is. I agree that if the same number is used several times, one conversion might be enough. But it is just a welcome service to the reader to convert every number at least once. −Woodstone (talk) 22:31, 17 January 2008 (UTC)

I'm just going to quote "Fact is that the units are used inconsistently" and "Regardless of how inconsistent sources are" then grin for a while because I find it funny. ;) Seriously though the JEDEC, who are the standard organisation for memory and who have majority consensus, do define kilobyte etc in their standard. So which standard body is the better one to choose, the one that has a tiny 0.5% use (no consensus) in the real world or the one that has the huge majority consensus? And then if there is any use that differs from the JEDEC standard then make a point of disambiguating it with exact numbers of bytes. Fnagaton 22:56, 17 January 2008 (UTC)

I see your point about fun: it is funny: the more inconsistent usage is, the more there is a need for conversions. You may know exactly in which cases a particular interpretation is standardised by JEDEC, most people have never even heard about JEDEC. Why not help them by addding a conversion? −Woodstone (talk) 23:03, 17 January 2008 (UTC)

Because according to the JEDEC it's not inconsistent, it is powers of two in size. Following on from the above I could point to companies using KiB but in the decimal sense. Then I could say "inconsistent" and then you'd have to drop pushing for KiB to be used, to ape the arguments used by some IEC supporters for example. Pushing for a particular style of prefix isn't actually the point, as we'll see in a second. What happened is that some other "standards organisation" came along and invented a new term, but it's not used except by a microscopic minority. However the question isn't about what standards organisation is best or whatever, no matter how tempting that is it doesn't actually tackle the real issue and it just causes people to sit behind their preferred camp. Remember you cannot say IEC is consistent since it has been shown IEC is inconsistent with the consensus in the real world. Also remember you cannot say IEC is not ambiguous because of the companies that use KiB in the decimal sense and also because JEDEC define it to be not ambiguous. The question is, why advocate something that only has a tiny 0.5% support, i.e. doesn't have consensus? Fnagaton 23:09, 17 January 2008 (UTC)

Well, a kilobyte appears to be 2 raised to the power 10 (=1,024) in most systems and one megabyte can be either 1,000 kilobytes or 1,024 kilobytes; it gets a bit difficult to determine how many bytes there are in a particular wiggit. Some system is need to sort it out. I've lost track of the arguments, what's your proposal to sort it out - I don't think context is a valid approach.Pyrotec (talk) 23:45, 17 January 2008 (UTC)

The most common use being power of two. The only non-ambiguous way which also doesn't use neogolisms, i.e. is consistent with consensus, would be the following: Follow JEDEC or be consistent with the sources relevant to the article. If something uses JEDEC specified prefixes but in a non-standard sense then use the units found in the source but disambiguate by stating the exact number of bytes in brackets. Otherwise (and rarely) if some other units are used (like IEC) in the article due to being consistent with sources then disambiguate with JEDEC. Fnagaton 00:00, 18 January 2008 (UTC)

Or we forget it all for now and just make sure the guideline stays as it is in its stable state. Fnagaton 00:02, 18 January 2008 (UTC)

There is some confusion on binary versus decimal units of computer storage. However the computer industry and the technical press do not think is significant enough to change to a new units system. Fnagaton is very generous to say that the IEC prefixes have 0.5% acceptance. The industry treats kibi and gibi as something the IEC made up one day. It is not Misplaced Pages's mission to promote a failing standardization effort. If the IEC binary prefixes gain significant support Misplaced Pages could consider using them. -- SWTPC6800 (talk) 01:55, 18 January 2008 (UTC)

Now that's one horrible misuse of a quote. Did you think it applies because the headline looks fitting? I suggest you actually read this policy. It's also not legit (and I don't need any policy to back this up) to use arbitrary made up numbers like "0.5%" in a discussion. --217.87.122.179 (talk) 22:03, 2 February 2008 (UTC)

0.5% is not arbitrary and is not "made up".

Historical use search terms	Results
kilobyte -wikipedia	1,940,000
megabyte -wikipedia	6,190,000
gigabyte -wikipedia	3,640,000

Total: 11,770,000

IEC Search terms	Results
kibibyte -wikipedia	28,800
mebibyte -wikipedia	17,100
gibibyte -wikipedia	19,000

Total: 64,900

Consensus for historical use: 99.449%

Fnagaton 22:51, 2 February 2008 (UTC)

It's good that you explain how this figure was determined. This shows that the value is less than useless. Many results may to a certain extent show that something is widely known. The opposite is not true. Lack of results does not prove anything. Not to mention that this method is still arbitrary because it excludes the short forms which are far more common in my experience. Of course it's obvious that MiB has more meanings than Mebibyte and MB has also many meanings in different areas. Last but not least, this method excludes not only results from[REDACTED] or citing wikipedia, it excludes any kind of result which mentions or links[REDACTED] which may have nothing to do with this topic. --217.87.122.179 (talk) 00:15, 3 February 2008 (UTC)

The preponderance of evidence shows that real world consensus is against your point of view. What evidence have you given in reply? Nothing, no evidence, you've just written waffle about "less than useless". The numbers are facts that do not support your point of view so you are wrong again because when you claim "it's less than useless" does not make it so. Misplaced Pages is excluded for the very good reason that a while ago someone made many hundreds of changes to use kibibyte etc and that means including Misplaced Pages would contaminate real world results. Also Wikiepedia is excluded from the results to show real world use. You also showed a search earlier on that did "-wikipedia", unless you now want to retract your earlier post? Trying to do a search for the much shorter versions like MiB ("Men in Black" for example) is also much more likely to pickup use of those three letters that has nothing to do with computers so your point is not well thought out because your proposal would have less much meaningful results. Fnagaton 01:07, 3 February 2008 (UTC)

It is Misplaced Pages's mission to provide clear and accurate information to the general readership. If unit like MB is met, it is never obvious what quantity this represents. Usage depends on the context (e.g. disk, memory chip, data tranfer). Many people do not know which is used when, and even less what JEDEC is and if it applies to the particular occurrence of the unit. The solution is giving a conversion to a world standard. Even if that standard not often used, it is still well documented and unambiguous—just what is needed to eliminate uncertainty. −Woodstone (talk) 09:33, 18 January 2008 (UTC)

Woodstone, as explained above what you see as "never obvious" is a red herring because what you call "the world standard" is not actually a "world standard" and it is not unambiguous. The real question is this, why advocate something that only has a tiny 0.5% support, i.e. doesn't have consensus? Fnagaton 12:04, 18 January 2008 (UTC)

No, the real question is: how can we inform the reader clearly and unambiguously about the meaning of quanties given. Just using MB does not do that, because its meaning is context dependent. So what device are you proposing to achieve the goal of being informative. −Woodstone (talk) 12:41, 18 January 2008 (UTC)

Like I said above, express the exact number of bytes as disambiguation in brackets. For example 2KB (2 bytes) is the only unambiguous way of stating the number of bytes without using neologisms and it also shows that in this case it is using the binary context. Fnagaton 13:27, 18 January 2008 (UTC)

No, "2 KB (2^11 bytes)" is not unambiguous at all because there is always the possibility of mistakes. In this case, I'd assume the editor forgot the "i" and typed KB instead of KiB. Or worse, maybe someone added (2^11 bytes) because he assumed 2 KB was meant to mean 2048 when in reality it's really 2000. You might think it's "obvious" from the context, but context can only provide a rule of thumb. In many cases, the editor was just careless and typed "KB" instead of "kB". Many people don't know that SI prefixes are case-sensitive and that 'K' is incorrect as abbrevation for kilo (1000, one thousand). Thus, a chain of errors and "well-meant" edits can cause the following: 2000 bytes -> 2kB -> 2KB -> 2048 bytes. Same applies to "bits". Last but no least, this kind of hint reinforces the idea that KB absolutely means 1024. Sometimes less is more. If you think writing "(2^11 bytes)" is useful at all, why don't you drop the "2 KB" completely? It's not common practice in Misplaced Pages to write the same twice in different words. --217.87.122.179 (talk) 21:13, 2 February 2008 (UTC)

You are incorrect because "2 KB (2^11 bytes)" is not ambiguous and because it expresses exactly the number of bytes that are used. You are also incorrect because your "what if there is a mistake" scenarios are also irrelevant red herrings because as already stated in the guideline "...one must be certain... before disambiguation" and trying to throw out using a particular unit just because someone might edit an article incorrectly is no valid reason at all. Taking your point of view that would mean nobody changing anything because there might be a mistake somewhere. Thus your "many people" point is also irrelevant because if someone is not certain then they shouldn't be editing on a topic they are not certain about. Also changing KB to KiB when in the uncertain "many people" scenario you use is also wrong because the person is not sure what they are doing and could change something incorrectly. Dropping the "2 KB" completely is also not correct since as I have posted before consistency with the terms used in the reliable sources relevant to the subject is important. You are also wrong because disambiguation, "writing the same twice in different words", is very common. Fnagaton 21:24, 2 February 2008 (UTC)

(unindent) That makes sense. Perhaps more recognisable would be to use only multiples of 3 for decimal and of 10 for binary powers:

• with decimal meaning: 64 MB (64×10 bytes)
• with binary meaning: 64 MB (64×2 bytes)

−Woodstone (talk) 16:15, 18 January 2008 (UTC)

I really like the way this is heading, if it can be made to work. If there were such a guideline, I wonder whether it would actually be followed though. I think it is worth trying. Thunderbird2 (talk) 16:30, 18 January 2008 (UTC)

Yes using 2 and 10 notation would make it completely unambiguous and it also gives a very good hint as to what format is used for binary or more rarely decimal. Also it lets articles use the type of units that are used in the sources. Which is a bonus since maintaining consistency with sources as well as following the real world consensus is a really important issue for me and I suspect many others think the same. Of course as with disambiguation it need not be everywhere, just so that the article makes sense. Fnagaton 17:00, 18 January 2008 (UTC)

The suggestion appears to have some merit. Note: powers of three in decimal, e.g. 10, means that everything is rounded in thousands; and powers of ten in binary, e.g. 2, means that everything is rounded in kilobytes (=1,024).Pyrotec (talk) 17:11, 18 January 2008 (UTC)

I'm not sure how many readers wil be comfortable with this notation. In any case, I think what is being suggested is that for the binary meaning of the prefixes, it should be written as a power of 2, where the exponent is a multiple of 10. For the decimal meaning of the prefix, it should be written as a power of ten, where the exponent is a multiple of 3. --Gerry Ashton (talk) 17:28, 18 January 2008 (UTC)

I'm not sure whether Gerry Ashton's comment relates to my comment above, or an early one. My comment related to a question by Fnagaton which has since been edited, so it reads differently now & is no longer a question. My interpretation of Woodstone's comment, was a sequence of thousands & kilobytes, e.g 0.02*10, 0.2*10, 2.0*10, 0.02*10, 0.2*10, 2*10, etc, and a similar sequence for kilobytes (sorry I'm too lazy to do the binary sequence in kilobyte sequences). But if someone wants to see it?Pyrotec (talk) 17:43, 18 January 2008 (UTC)

Yes, of course. Very simple: keep the number as it is (no rounding needed) and convert, depending on context:

• KB to ×2 bytes or ×10 bytes
• MB to ×2 bytes or ×10 bytes
• GB to ×2 bytes or ×10 bytes (etc)

Furthermore, it is not very important if all editors follow up on the guidelines. There will always be volunteers that will add proper conversion. Having it in the MOS will hopelfully prevent reversions. We still have to find a way out of the occasional MB = 1024,000 bytes. −Woodstone (talk) 18:03, 18 January 2008 (UTC)

How about: "This memory stick from company X is labeled as 1MB (1024×10bytes)" Fnagaton 18:09, 18 January 2008 (UTC)

How about: "This memory stick from company X is labelled as 1MB (2×10bytes)" (not "*" as above). Rich Farmbrough, 14:03 1 February 2008 (GMT).

or "This memory stick from company X is labelled as 1 MB (1.024 million bytes)" Thunderbird2 (talk) 14:10, 1 February 2008 (UTC)

No. These are the worst options. In one regard it fails as soon as you get to a billion and especially beyond because US and European billion differ. The next higher magnitude which will be common in 2-4 years (tera respectively tebi) has no layman equivalent. If you write "1 MB (2^30 bytes)" any sensitive reader would assume that 1 MB is always exactly 2^30 bytes. There is no reason to assume a unit would differ depending on context. The solution is very simple, use units correctly or don't use them at all. If a unit has supposedly more than one meaning, it is by definition not a U-N-I-T. unit comes from unity. No unity, no unit. Kindergarten logic suffices. --217.87.122.179 (talk) 06:07, 2 February 2008 (UTC)

You are wrong 217.87.122.179 because the units are de facto standards used in the real world and Misplaced Pages is descriptive not prescriptive. To use neologisms that are very rarely used in the real world (<1%) only confuses the matter even further. Fnagaton 09:53, 2 February 2008 (UTC)

He is right in so far that the IT industry’s adoption of metric prefixes, beginning 40 years or so ago, in a different than standardised sense is the root of the problem. Only that made ambiguity possible. Separate binary prefixes should have been developed back then, but they weren’t, leaving us with the mess.

You are right that Misplaced Pages is descriptive – in intention at least, by its importance and influence nowadays, being part of the real world, it is defacto quite prescriptive! –, but you are also wrong, because its style guide, unlike encyclopaedic information, has to be prescriptive to some degree. MOS may very well choose to adopt a rule by reason that would not have been derived from observing common usage. IT prefixes used to be such a case, where MOS editors came to the conclusion that it’s better to diverge from common and source usage, adopting an international public standard instead to make the project less ambiguous and more homogenous. Some months ago this changed (after epic-length, tiresome discussions), because some article authors, like you, didn’t like to adapt their habits. The descriptivism myth evolved.

You are also wrong in that you didn’t respond to any of the points the IP user raised; just called him wrong, repeating your weak arguments once again. He does have at least one very valid argument: “There is no reason to assume a unit would differ depending on context.” — Christoph Päper 14:07, 2 February 2008 (UTC)

The IP user and you are wrong because it is fallacious to try to claim something is "different than standardised sense" just because a so called standards body decides to produce something contrary to what is the de facto standard. You are also wrong because the MOS is not prescriptive beyond what is actually common sense. You are also wrong because I did respond to the "points" the IP user raised, you will note this is the case since I wrote "because the units are..." giving a perfectly valid and correct reason. What you claim is the IP user's "valid argument" is actually shown to be a red herring by the very fact that the units have well known use. You are also wrong because the arguments put forward by me are stronger than what you have put forward and just because you disagree doesn't mean you are correct. Actually I'm giving you the benefit of the doubt here because you have put forward no such counter argument, instead you have attempted to question my motives and claimed a valid logical reason is somehow "repeating your weak arguments" without giving any supporting evidence. You are also wrong in your summary of the history of this topic and I demand that you retract your misrepresentation about what you think my motives are. Fnagaton 18:39, 2 February 2008 (UTC)

You are reacting on trigger words again instead of reading carefully and responding adequately. First came decimal metric prefixes (which I wrote about), then came bits and bytes (and octets and words), then came binary “adaptation” of SI prefixes in IT – with the side effect of capital k which I welcome –, then came disambiguity, then came IEC prefixes, then came Misplaced Pages. Where am I wrong here?

There is no such thing as common sense, never use it as an argument. The MOS is not prescriptive in the sense that it would say people what to do, but it’s prescriptive in the sense that it says what articles should look like in the end. (And yes, it’s often watered down in that regard, which I consider a failure.)

The IP users said, a unit with multiple meanings was not a unit by definition. You say that (he’s wrong and) the units under discussion were being used with multiple meanings, trying to prove your but actually also proving his point. His definition can’t be wrong, it just may not match yours.

The (here logical, not empirical) expectations of the readership are quite the opposite of a “red herring” argument in a discussion about our style guide! If the prefixes, when applied to bits and bytes, always were used in a binary sense (and decimal everywhere else), your point might stand, but they ain’t, e.g. in rates (kbit/s etc.).

I tried to limit my response (after I couldn’t suppress it completely), because I think everything has been said on the matter, although people still come to different conclusions, because their views about the role of Misplaced Pages and its MOS differ. (You try, intensional or not, to devalue the other position by calling it prescriptive and neological, which aren’t bad things per se, neither is de facto.) If I agreed with your presuppositions I would probably come to the same conclusion, because I don’t contest most of the facts you bring up again and again, thinking or at least implying that this was what needs to be discussed when actually we disagree on a higher level, which makes your points irrelevant – weak probably was an inappropriate or misleading term.

You’re in no position to demand anything from me (nor anyone else here), but, please, feel free to correct or at least discredit my summary, my view of the process.

Gee, I wish there was anything besides carnival outside so I hadn’t felt the temper to engage in this again. — Christoph Päper 01:24, 3 February 2008 (UTC)

You are incorrect because you are at fault here for not "reading carefully and responding adequately" (as you put it). This is because you misrepresent what I write and you attempted to misrepresent my motives in your summary of the history of this topic when you wrote "because some article authors, like you, didn’t like to adapt their habits". You are utterly wrong to try to misrepresent what you think are my motives. You are also wrong when you say there is no such thing as common sense because common sense is a large part of building consensus. Next we get onto you misrepresenting what I write. This is because I point out his "argument" (from 06:07, 2 February 2008 (UTC)) is a red herring and yet you insist on trying to rewrite my point to mean something else entirely. Just so you are perfectly clear, what you wrote is rubbish because I never wrote what you claimed I wrote. You are using a straw man, so your "point" is irrelevant and false. Fnagaton 02:01, 3 February 2008 (UTC)

I’m sorry it took me so long to respond, but I had much more important, non-WP things to do lately. Actually, I’m just taking a break from them.

So you think I misunderstood you or your motives. Maybe I did, big deal, happens all the time. You wouldn’t even have noticed if I hadn’t paraphrased what I understood and remembered (“misrepresent” you call it), just like I noticed your misreading. It doesn’t help, though, that you don’t explain where and how I misunderstood exactly. I assume it’s only about the changing habits part.

Nobody denies that kilo, mega and giga (at least) with bit or byte are often being used and understood in a binary sense instead of their classic, metric decimal one. Nobody denies that this occasionally results in ambiguity (in any imaginable way). Nobody is happy with the situation, although many take it as a given. Nobody intends a unit (or prefix) to have more than one meaning, although in practice (i.e. your de facto) occasionally one does. The IP user raises this point to a defining quality of a unit, you pragmatically don’t and call this (intentionally) irrelevant to the discussion (“red herring”). Am I right so far?

My main argument, which you ignored, still stands: We have different ideas of the purpose and foundations of this style manual. Therefore we cannot come to the same conclusion! So every argument is moot until we agree on the basic principles.

Whenever you claim the MoS was descriptive not prescriptive you are right and wrong at the same time, because a descriptive observation once published becomes a prescriptive rule in the understanding of many. This is how grammar and orthography “rules” came to be (for most natural languages).

Anyhow, a suggestion for compromise for the time being, although I would much prefer consensus in the long run:

SI prefixes are decimal and do not need disambiguation in general, but when applied to bits or bytes (incl. words and octets) without composition with any other units (as in rates, e.g. kbit/s) their meaning has to be disambiguated (one possibility is the replacement by IEEEIEC prefixes, which are always binary), except for RAM chips when used with a preferred number based on a power of 2 where they take a binary default meaning and only need disambiguation when having a decimal meaning. — Christoph Päper 19:36, 21 February 2008 (UTC)

I can see you are continuing to misrepresent me because I did not ignore your argument, your "argument" is fallacious for the reasons I have already given above and previously on this topic. Your compromise is not good because it does not represent real world consensus. Your "compromise" chooses IEEE which you prefer, which is not a compromise at all, it is pushing your own point of view. For example it is disingenuous to say "SI prefixes are decimal" and not mention the fact that the JEDEC defines K = 2, M = 2 and G = 2 when being used for semiconductor storage capacity and also because recent legal rulings have stated that despite what SI/IEEE/IEC claim the de facto standard is different. RAM chips commonly use the units KB, MB, GB in the binary sense, for example and this is defined in the JEDEC standard. If you really want to get into the whole "orthography" argument then you're going to be refuting your own point of view because orthography is to use correct spelling according to what is considered to be accepted (i.e. generally approved) and established use. In this case orthography easily refutes using the -bi prefixes because it is obvious they are not accepted and established use. Fnagaton 08:42, 22 February 2008 (UTC)

Gosh, either my English is worse than I thought or productive discussion with you (on this subject) is close to impossible.

I don’t care whether we use IEC prefixes for disambiguation. I just want to limit ambiguity inside and among WP articles. (Ambiguity outside WP is outside the scope of this style manual.) To achieve this we can either

1. adopt something with mutual exclusive meanings (e.g. SI and IEC prefixes, despite ambiguous usage outside WP),
2. disambiguate (SI prefixes) inline each and every time or
3. specify in MoS where we assume which default meaning (for SI prefixes), that wouldn’t have to be disambiguated, and where it’s too dubious to choose a default.

The current guideline does nothing to achieve the goal, uses only partially the second option. My suggestion for compromise does the third, although I very much prefer the first. Maybe I set the requirements for a binary meaning of SI prefixes higher than you would like, but with preferred numbers in the field of semiconductor storage capacity most cases would still be covered to your satisfaction. I see no good solution for file sizes, though, because files can be stored on different media (binary or decimal) and can be transmitted (decimal). — Christoph Päper 17:10, 22 February 2008 (UTC)

I note your continued misrepresentation and use of weak personal attacks, this shows that you are not interested in valid debate. You are also wrong because the current guideline fixes what you think is ambiguous by encouraging the exact number of bytes to be specified in the disambiguation or in footnotes. For example "256 KB (256×2bytes)".

The first option "adopt something with mutual exclusive meanings" ignores real world consensus and makes articles inconsistent with their sources and actually doesn't solve the problem of using -bi units that can also be ambiguous.

The second option "disambiguate (SI prefixes) inline each and every time" is not logical since the purpose of disambiguation is not to include brackets (or similar inline text) after every number in an article, it is usually the case that only the first occurrence of any such number needs disambiguation.

The third option "specify in MoS where we assume..." is only going to get my support if it follows the real world consensus, i.e. not use -bi. Otherwise it is just going to be pushing point of view against consensus.

The best option, which you don't list, is to use the terms found in the majority of reliable sources relevant to an article. This means internal consistency for articles over and above consistency for the whole of Misplaced Pages. Fnagaton 17:33, 22 February 2008 (UTC)

Like I said, the current guideline, if anything, uses the second option. It’s the worst! It being basically optional doesn‘t make it any better. 256 KB would default to binary meaning by my proposed compromise (in the context of semiconductor storage at least) and thus would only have to be diambiguated if it had a decimal meaning instead.

I didn’t deny that the first option would only be internally consistent. Unlike you I don’t consider this a huge problem. I tried to point that out earlier. IEC prefixes are always binary and thus unambiguous, even if you should find someone using them wrongly.

Read it as “disambiguate (SI prefixes) in each and every article” if you must.

Real world consensus is that IEC prefixes are one way to achieve disambiguity where needed; the real world isn’t just very often unambiguous. For symbols the little i is probably the least cumbersome, least space-taking and – like it or not – most established solution. If you don’t like the terms “kibibyte” etc. – I don’t – you may use “binary kilobyte” or something like that where needed.

What you call a best (or fourth) option is not solving the problem at all, because it would mostly result in SI prefixes being used with varying meaning. Every reader would have to make a (hopefully educated) guess. My proposal was to provide a rule of thumb for that guess in the MoS. I already tried (without success) to discuss our different views of the scope for consistency. — Christoph Päper 10:11, 11 March 2008 (UTC)

To tie this thread with the new thread this comment demonstrates why Crissov is still wrong for the same reasons as above. Fnagaton 19:13, 24 March 2008 (UTC)

The IP user raises only one valid point, that even more confusion will arise when larger memory becomes available. In respect of (computer) memories, in the real world units do change depending on context - read the discussions above: a million can mean 1024 x 1000 and 1024 x 1024 depending whether is a megabyte of storage on a hard drive, memory stick, etc - go and look at amazon.com. The IP user appears to be confused, it is not misuse of units in[REDACTED] that causes problems it is inconsistent use of units in the computer industry that causes the problems. Misplaced Pages MOS is attempting to add clarity to the confusion that already exits.Pyrotec (talk) 19:52, 2 February 2008 (UTC)

I've changed my view upon reflection. The computer industry uses megabytes, Gigabytes, etc, the difference in UK and US definitions of a billion is irrelevant as it is unlikely that billion will be used as a description of the number of bytes.Pyrotec (talk) 20:20, 2 February 2008 (UTC)

Indeed, that's what I meant when I said earlier the point put forward "is actually shown to be a red herring". It's like saying "the sky is blue and that proves that I'm right about cell meiosis". Fnagaton 20:35, 2 February 2008 (UTC)

• That difference is irrelevant everywhere, except perhaps nursing homes in the UK. Tony (talk) 23:28, 2 February 2008 (UTC)

Maybe you don't know that "billion" is not only an English word. Billion is still frequently mistranslated as "billion" when it actually means 10^9 in one (European) language and 10^12 in the other like French or German. The UK might have adopted the US meaning by now, that's not true for any other country. You see it's almost the same issue as Megabyte vs. Megabyte. One is 10^6 and the other is 2^20. Keep in mind that this neither the American nor the British Misplaced Pages, it is an international effort. As there is no official authority for the English language, really nobody can decide which meaning of billion is correct but it is trivial to avoid these few well-known sources of confusion. --217.87.122.179 (talk) 00:00, 3 February 2008 (UTC)

No, you didn't mean that. If you read carefully, the term billion was only a part of argument. Calling it a "red herring" makes clear that you assume bad faith, especially your "sky is blue..." blah blah shows that you are interested in facts or any kind of useful discussion. There actually over 120000 Google hits for '"billion bytes" -wikipedia'. I don't know which formula Pyrotec used to determine his assumed probability but I'd think we can all agree that this isn't the right place for speculation about the future. For the record, a billion bytes is in US-American English equivalent to a gigabyte, that's why it's already in use. I was talking about Terabyte (tera means 10^12) which is less common for now and which has no well-known -illion equivalent. So it'd be called 1000 billion or a million million but nobody knows what's the marketing industry is going to establish. Nonetheless "billion bytes" is actually used despite the assumed low probability. —Preceding unsigned comment added by 217.87.122.179 (talk) 20:56, 2 February 2008 (UTC)

Yes I did mean that so do not presume to tell me what you think I really meant because when you do so you are misrepresenting me and what I wrote. Also your incorrect accusation of "bad faith" shows you have not presented a valid argument because the term "red herring" is actually referring to the logical fallacy, which your "argument" is actually using. This is also pointed out by Pyrotec as being irrelevant. Fnagaton 21:08, 2 February 2008 (UTC)

Okay, then I'm relieved that I could help in making clear what you actually meant because it wasn't obvious at least to me. I don't quite agree with your presumed definition of red herring but discussing this would be another one and off-topic anyway. --217.87.122.179 (talk) 21:58, 2 February 2008 (UTC)

Red herring fallacy also known as irrelevant thesis or conclusion. You'll see what I wrote is correct. Fnagaton 22:43, 2 February 2008 (UTC)

Not taking either side, but the Google test is worthless. As is citing voluntary standards (as are the IEEE's, IEC's, and JEDEC's) as examples of "policy". Voluntary standards are just that, and it's hardly surprising you can find standards which reflect common usage. Consider:

mile -wikipedia - 24,300,000

kilometer -wikipedia - 1,520,000

inch -wikipedia - 26,000,000

centimeter -wikipedia - 6,800,000

pound -sterling -wikipedia - 11,200,000

kilogram -wikipedia - 8,240,000

acre -wikipedia - 3,420,000

square kilometer -wikipedia - 1,660,000

Can these results be used to argue that preference should always be given to imperial units of measure, since apparently more English-speaking people will be familiar with them? Can they be used to decide on a case-by-case basis which units are preferable? Can you say that common use is universally more important than standardization in every case or vice versa? No matter how you concoct the Google Test argument, it is always flawed.

Experience with Misplaced Pages should tell you that no amount of dialog on this will ever settle the issue wholly in favor of or against IEC prefixes. There's zero editorial direction on this site, and unfortunately the MOS as a whole is more or less a farce (used merely when it is convenient in an argument), so fights like this will keep breaking out. I strongly suggest you look for a middle ground where the use of IEC prefixes is accepted in some contexts and the common prefixes are accepted in others. Pages like the one on floppy disks really do need some concise method to deal with the prefix ambiguity, and the IEC prefixes are one such way.

Basically, the way the MOS currently reads is the only way it can read. In reality there's no such thing as standardization on Misplaced Pages, so that argument won't work. The current reading explains the history of the debate, lays out the facts (common use versus ambiguity) and doesn't take any strong position. The only change that might be useful is provision for changing prefixes to IEC variants where appropriate and discussed beforehand. This excludes contentious en masse changes, but still acknowledges that there are some circumstances in which utilization of IEC binary prefixes might be useful. (maybe also remove the mention of the JEDEC, which is utterly comical since their standards have nothing at all to do with standard prefixes for unit measures)

You will never convince each other. You will not be able to defeat the common usage argument. You will not be able to defeat the ambiguity argument. You will never end this debate by brow beating the same tired and cyclical arguments into one another. I humbly suggest just leaving the dead horse alone and letting the editorial ebb and flow take its course. Otherwise you're just wasting your own time in neverending trite rhetoric. -- 74.160.99.252 (talk) 20:27, 11 February 2008 (UTC)

Unfortunately the IP user from Germany (not you 74.160.99.252) but the other user from 217.87.122.179 above (and their other IPs in that ISP range) decided that instead of trying dialog they would vandalise ANI, several talk pages including mine and an admin. Eventually leading to several semi-protects and range blocks. The ambiguity argument has been refuted since it relies on the false premise "nobody uses -bi in other ways except binary" because it has been shown that -bi has been used in the decimal sense. Fnagaton 20:39, 11 February 2008 (UTC)

I'm pretty sure 74.160.99.252 is the same person you're talking about. --85.25.12.31 (talk) 21:28, 11 February 2008 (UTC)

I'd like to add a note concerning the argument about base 2 centric prefixes somehow being out of agreement with SI base 10 prefixes. It is my understanding that the prefixes are not strictly measures of absolute value, but rather shorthand for differeing degrees of magnitude. As such, it makes perfect sense that in a base 10 system, the exact values of the prefixes are different from a base 2 system. Suggesting otherwise is akin to saying that a statement "...the majority of GDP..." should always have the same meaning in direct dollar amount, regardless of whether you are talking about Alaska or New York. Additionally, outside of marketing materials, I have never seen the base 10 interpretation of prefixes used in referring to computer hardware or internals.

That said, I do see a need for disambiguation for laymen. However, some non-standard (in common useage) alternate form of the abbreviations, such as MiB, does not seem a good idea, as it does not present the best interpretation for translation to real world experience. An encyclopedia is supposed to inform within context of reality, not impose some non-standard environment that makes integration of the information in to the life experience of the reader more difficult. In addition, where the prefixes are used ambiguously (eg GB = 1000X1024KB etc), specificity is of less importance. In such instances (the main one I could see being lists of products with marketed disk sizes etc), if absolutely necessary, a disambiguation such as "GigaDisk Pro 750GB (actual size XXXGB)" would seem the best solution.--207.14.29.3 (talk) 21:56, 8 April 2008 (UTC)

I think including powers of 10 or of 2 is going to add to confusion rather than reduce it. The clearest scheme I can see looks like this:-

• 1KB = 1,024 bytes
• 1MB = 1,024×1,024 bytes or 1MB = 1,000×1,024 bytes or 1MB = 1,000,000 bytes
• 1GB = 1,024×1,024×1,024 bytes or 1GB = 1,000,000,000 bytes etc.

This can be put into a footnote (or follow in parentheses) after the first usage of the unit to mean this amount. Sheffield Steel_stalk 22:56, 8 April 2008 (UTC)

Exactly. A solution that is immediately more understandable to the average reader than using the IEC prefixes. Fnagaton 16:36, 9 April 2008 (UTC)

Concern: commas and dates

MOS:DATE#Dates (or any other section I'm aware of) does not clarify that commas have to be inserted for full dates which are wiki-linked. Example; a comma automatically appears in February 14 2008 (see the linked ] ] here, note that it does not for February 14 2008 and February 14 2008). In other words, if the date is linked, the comma is visible to viewers even though it is not edited into the context. So, can someone see the logic in this revert? To me, this is like placing the |right| to an image which already has a mark-up like |frame| or |thumb| which sets the image to the right by default. My proposal — the guideline should say that a comma does not need to be inserted for a correctly linked date. Is this understandable? Lord Sesshomaru (talk • edits) 02:52, 5 March 2008 (UTC)

See also Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/Archive_94#Commas_in_linked_dates. Some people still don't realize a comma is added in ] ] (February 14 2008), and removed in ], ] (14 February, 2008), even for IP editing. The revert was based on a misunderstanding. Gimmetrow 03:03, 5 March 2008 (UTC)

So you agree that these things should be mentioned in the guideline? Lord Sesshomaru (talk • edits) 03:08, 5 March 2008 (UTC)

I can agree with saying a comma does not need to be inserted with the ] ] format, but I'm less clear on recommending it. No comma seems to confuse editors. With ], ], I think the comma should be removed and not restored, since MediaWiki removes it anyway for viewing, but editing solely for this would be a trivial edit. Gimmetrow 03:30, 5 March 2008 (UTC)

The guideline doesn't say that is HAS to be added, but it also doesn't say it HAS to be removed. If the comma is optional, the guideline probably should note that, but I don't think that should be a justification to remove them. Does having the comma there cause any actual problems? If not, when doing February 14, 2008, why remove the comma? It seems like a personal editing preference, and not one that needs to be "corrected" unless there is an actual reason to do so. Collectonian (talk) 03:35, 5 March 2008 (UTC)

This argument is a bit pointless. When a complete date is wikilinked, it will always display correctly—for the American style the comma will be inserted where it is not present. The opposite applies for British style, where the comma is deleted if present. This applies also for unregistered users. But mention should be made of this somewhere to prevent unnecessary editing. I had a discussion about this before (here) and still have the test in my sandbox (if anyone's interested be sure to switch of dates preferences beforehand). TINYMARK 04:07, 5 March 2008 (UTC)

It's just like the image sample I cited: why add |right| if |thumbnail|, |frame|, etc., already does the job? It's past redundant. Therefore, the guideline should make note of this. Do we have an agreement? Can this be indicated in the guideline now? Lord Sesshomaru (talk • edits) 04:17, 5 March 2008 (UTC)

I'd link to see an alternative way of formatting dates than using double brackets (]). The problem I see lies in there not being consensus on how dates should appear (American vs international), leading to a system where user preferences can be set to recognise and format all dates marked in a certain way. Fine, up to a point. However, in using the article linking mechanism, dates are being linked left right and centre, when there is no real reason to - many dates in articles have no great historical significance, and do not even warrant a mention in the linked date article. Nevertheless, there appear to be editors who spend most of their time manually making these links. This labour-intensive and overlinking to dates and years articles (just check their backlinks and you will see what I mean - there are well in excess of 20,000 articles linked to January 1 alone), and the paranoïa apparently associated with it drives me nuts. Ohconfucius (talk) 05:15, 5 March 2008 (UTC)

You're absolutely right. There should as well be a section on which layout is preferred. That'll be hard to decide, albeit there really isn't a standard preference, it'll have to be one or the other. Lord Sesshomaru (talk • edits) 05:34, 5 March 2008 (UTC)

What we should not be doing is what you did in your original post, Sesshomaru. Don't link February to the article on the month, link 14 (meant to be the day of the month) to article on the year AD 14 and 2008 to article on the year AD 2008. That's already covered in the MoS, isn't it?

Our standard "look and feel" is the results we get from dates properly formatted for user preferences. There is no preference from among those options, if that's what you are talking about. It is best to enter it the way it appears, but the missing or extra comma we are talking about there won't make much difference in the results, and in not in itself reason to edit an article.

Yes, the software will fix some of the problems even for users who are not logged in. I used to think, after the software started acting that way, that it no longer mattered if a linked-for-preferences date was linked as "], " or "], ", but if I recall correctly, somebody pointed out some case in which it does make a difference. But maybe I just imagined that, I cannot tell you what it would be. Gene Nygaard (talk) 15:18, 5 March 2008 (UTC)

Not quite sure if you're upset or bothered by anything Gene. I was making a simple point about the comma in those samples. In any case, shall I update this page per discussion or are there any opposing? Seems to be legit. However, I'll refrain from mentioning how dates should appear, American vs international-wise, since that would require a separate section. Agreed by all parties? Lord Sesshomaru (talk • edits) 16:55, 5 March 2008 (UTC)

If I understand your point, and going by what you were edit-warring about, we most certainly should not be saying not to use commas on the edit page, in places where they would normally appear in what readers see on the article page. Why in the world are you even asking for that? Gene Nygaard (talk) 17:51, 5 March 2008 (UTC)

Edit warring? What in the world are you talking about? Lord Sesshomaru (talk • edits) 18:04, 5 March 2008 (UTC)

Okay, I take that back; not edit-warring. It was just a first impression, when you were complaining about someone's reversion of your edit removing commas from the Month DD, Year format. I don't think you have any cause for complaint; we should not be running around removing the commas. That's the point I'm trying to get across. Gene Nygaard (talk) 18:31, 5 March 2008 (UTC)

Compromise: how about having the guideline say something like, "commas for the ] ] format do not need to be inserted since they are visible even without them in the edit."? Implying not to use commas no matter the circumstance is a tiny bit irrational, I guess. This makes sense? Lord Sesshomaru (talk • edits) 18:52, 5 March 2008 (UTC)

Okay. I'll do the compromised edit to the guideline tommorrow. Any additional comments? Lord Sesshomaru (talk • edits) 06:04, 8 March 2008 (UTC)

(deindent) Make sure to note that just because they are not needed is no reason to run around removing them from existing articles. Collectonian (talk) 21:13, 10 March 2008 (UTC)

I think I know why you're saying this. You don't want the commas removed in pages that you heavily edited, like List of Star Ocean EX episodes? Can I ask why? If someone has enough spare time on their hands, I don't see why they should not run around and get the job done. It's optional. Thoughts? Lord Sesshomaru (talk • edits) 21:28, 10 March 2008 (UTC)

I'd have thought the reason is obvious. Do you want to see your watchlist explode ?? ;-) TINYMARK 21:34, 10 March 2008 (UTC)

You're right, I don't. I see no point to it. I find it rather annoying, as it isn't needed or useful at all. If people have time on their hands, I'd rather them do something that actually improves the articles rather than just do such an extremely meaningless edit. It would be one thing if removing the commas actually fixes anything, but it doesn't. Even tag and go is more useful than stripping out the commas. Its about as pointless an edit as one can get. And, as TinyMark notes, it is another watchlist addition that gets to be doubly annoying when someone comes along, is editing, noticing there are none, and feels they need to fix it. I also find the code looks very ugly without the commas and I think it would be very confusing to anyone who doesn't understand that the commas are not needed (a good chunk of editors, I'd suspect). Maybe I'm an anal web developer, but I seriously abhor ugly code :P Collectonian (talk) 21:51, 10 March 2008 (UTC)

I don't really think the layman will assume that a comma is missing (that's what the preview button is for). But I see both of your points. What about the dates in pages that already have no commas? Are you two suggesting that the commas should be inserted because the layman will think they are missing and will "explode" one's watchlst? Lord Sesshomaru (talk • edits) 22:10, 10 March 2008 (UTC)

If any article is already without commas, then no need to insert either. So my basic position is, if they are there, leave them there, if they aren't, leave them out, though if a newbie editor comes alongs and adds them because they think they are missing, no need to yell either (though feel free to undo and explain). Its kind of like referencing, I guess. If a valid referencing style is already in heavy use (such as Harvard referencing), don't run through and completely redo to your preferred referencing style (maybe using templates). In the case of citation styles, Misplaced Pages:Citing sources includes language regarding that:

"Any style or system is acceptable on Misplaced Pages so long as articles are internally consistent. You should follow the style already established in an article, if it has one; where there is disagreement, the style or system used by the first editor to use one should be respected."

Perhaps something similar would work here? Collectonian (talk) 22:26, 10 March 2008 (UTC)

I guess that could work, but what about Death Note? Some dates there have a comma, others do not. And if someone comes along and removes the commas while doing other good faith edits, like I did here, one should not revert blindly or undo only the removal of the commas, as that seems to be a case of Misplaced Pages:Ownership. So can we integrate what I just said into the guideline as well? Lord Sesshomaru (talk • edits) 22:37, 10 March 2008 (UTC)

For Death Note, if we use the citation guideline, then whichever was used first should be kept and the rest changed to match. As for the Star Ocean issue, well, as has already been noted, removing wasn't necessary. The list was created with them (first editor to use), and that shouldn't have been changed. Your other good faith edit (only one other thing) was put back. Collectonian (talk) 01:09, 11 March 2008 (UTC)

So how should it be written in the guideline? I know what to include, but don't know how to phrase it. Any thoughts or suggestions? Lord Sesshomaru (talk • edits) 01:18, 11 March 2008 (UTC)

I think a slight modification of the quote from cite, retooled to dates, would be fine. So something like: "Commas are not required to be used in full format American dates. Their inclusion or exclusion is a stylistic and editorial preference. Either style is acceptable so long as articles are internally consistent. You should follow the method already established in an article, so that if the article has dates with commas, then the commas should be left alone and new dates added to the article should have commas. If the dates in the article do not have commas, then they should not be added to existing dates and new dates should not have them. Where there is disagreement or the article currently has a mix of commas and no commas, then the earliest format used should be respected and the article changed to be consistent with that format." Collectonian (talk) 20:02, 11 March 2008 (UTC)

Sounds great! I noted that the Death Note page first used commas, then some were removed. I shall correct this problem soon. Okay, go ahead and update the guideline, would you? Lord Sesshomaru (talk • edits) 20:08, 11 March 2008 (UTC)

The page is currently edit protected, so before I put in an editprotected request, does anyone else want to comment on this? Collectonian (talk) 04:04, 12 March 2008 (UTC)

Go for it. Seems we have concluded. Lord Sesshomaru (talk • edits) 20:09, 12 March 2008 (UTC)

Added. I wasn't completely sure where to put it, so I put it in the section on full date formatting. If someone feels it should be positioned differently, feel free to shift around.Collectonian (talk) 17:57, 13 March 2008 (UTC)

This has not been thought through. It is not necessary or even useful to have a different standard for articles that pertain to American topics. If I am editing a section of an article on a clearly British topic to correct a misspelled word, and then also see a mess like "happened on the 14^th of Sept ]", I can simply change it to "happened on ] ]". If I see this in a section of an article on a clearly American topic, I would, according to these new instructions. need to:

• get out of edit mode on that section.
• view or edit the entire article, examining it to see if there are any dates in either of 2 formats, ], ] or ] ].
• if there are none, pick one format and use it for the mess I found.
• if all other dates are in one of those 2 formats, use that format to fix the messy date.
• if there are several dates in each format, spend half the afternoon digging through the revision history trying to find the revision that first introduced one of these 2 formats, and use that format to fix the other dates that were added since, and the messy date.

If this strikes anyone as an unrealistic burden to throw on the back of editors who are trying to clean up articles on American topics, I agree and sympathize with you completely. Before the manga edit skirmish began, we had 2 formats: ], ] or ] ], for west of the Atlantic and east of it. I feel that adding a 3rd format and encouraging its use (just because it is known that the software will fix it for general display) detracts from Misplaced Pages. I will remove that recommendation from the guideline. An agreement between two editors doesn't constitute much of a consensus. Chris the speller (talk) 18:19, 19 March 2008 (UTC)

No one is saying anything about adding a 3rd format. The article already says you can use ], ] or ] ]. The paragraph just clarifies that people shouldn't go around removing all the commas in an article because the comma isn't needed, nor should they be added in, rather as with sources, stick with the method already in use in the article. Collectonian (talk) 18:35, 19 March 2008 (UTC)

Your statement is completely incorrect. Nowhere does the guideline say that ] ] is an acceptable format. Please remove that paragraph or allow me to remove it again. Chris the speller (talk) 20:40, 19 March 2008 (UTC)

It is shown in the table lower in the page. Personally, I agree, but as other editors have used this guideline to say commas are not required and have removed them (and not just the case noted here), something should be added to clarify. The paragraph is an attempt to do so. Do you have another suggestion for a better way to deal with it? Collectonian (talk) 20:46, 19 March 2008 (UTC)

I think you will see that I am on your side if you read the discussion "Commas in linked dates" in Archive 94 of this talk page. Back then I was afraid that including "] ]" in the table would lead to some editors to think that it was an acceptable format, but there was an insistence on leaving it in to provide a complete list of formats that the autoformatting software could or could not handle. You have shown that my fears were justified. The omission of the comma has come up several times, but a consensus to allow dropping it has never been achieved. My last comment in that discussion clearly shows that I opposed editing just to remove a comma from the British-style dates, so I wholeheartedly oppose removing them from American-style dates. The removal of commas from the manga article was not only a waste of time for that editor and a waste of Misplaced Pages resources, but turned into a further burden on those taking part in discussions here. I kept getting beat up about that table and the green check marks and red X's. If you want to support adding a couple of red X's to that table instead of the 2 wimpy asterisks, maybe we can get this cleared up. Chris the speller (talk) 21:55, 19 March 2008 (UTC)

That might be a good idea, and I could see it being cleaner than the paragraph addition. I'd support making it clearer for sure. Collectonian (talk) 22:22, 19 March 2008 (UTC)

What do you think of the green checks and red X's that were in the table here? Never mind that the legend below it is inaccurate in this version. Would something like this work to show what formats are acceptable? Chris the speller (talk) 01:20, 20 March 2008 (UTC)

I think that would work. It makes it clearer what formats are acceptable and much easier to quick read. Collectonian (talk) 01:23, 20 March 2008 (UTC)

How about adding green check marks on the left of the table, just for the two formats that are accepted by the MOS? Red X's are already used on the right to indicate what will display as a dead link. Chris the speller (talk) 15:30, 26 March 2008 (UTC)

Totally different perspective (on original issue raised in this thread): The comma absolutely must be used in the ], ] format (and never in the other). The geeky reason is that the entire web has been evolving for over a decade now toward the complete separation of content and presentation markup, and this violates that principle. The more practical and immediate WP reason is that, as most of you know, Tony1 and others have been working hard to raise awareness of the absolute suckitude of the current date formatting system, with the eventual badly-desired result of removing the ] markup that causes the dates to be wikilinked for no reader-useful reason, to be replaced by something as yet undetermined. It is very likely in my opinion that the developers will eventually fix this with an "intelligent" solution that auto-parses correctly formatted dates on-the-fly, in precisely the same way that is auto-parses correctly formatted cases of ISBN followed by an ISBN number, rather than introduce some wacky new markup that no one understands ($#$February 27 2008$#$ or whatever). I'd bet real-world money on it. If I'm right, potentially millions of dates will not be auto-formatted because MOSNUM will have told editors they can be lazy and omit the commas, resulting in malformed dates when the square-brackets are removed for implementation of the new date coding system. For this reason, I correct cases of ] ] on sight. PS: The idea of "oh, well, the smart autoparser can just recognize that format too" does not fly, because WP is open content, meaning that it can be reused in any way that people want, including selectively downloading the wiki, not HTML source and stripping out what they don't like and reworking it; we have no guarantee at all that the MediaWiki parser will be used in any particular case of legitimate re-use of WP content. We cannot permit invalid content just because we're lazy and we assume (in some cases falsely) that tricky aspects of the MediaWiki code transmogrification process will compensate for our errors. By way of analogy, it would be trivial for the MW developers to install code that corrected on-the-fly all instances of "hte" and "corect" so that they were spelled correctly by the time the code was rendered in the browser window, without actually correcting these errors in the source code. No way, José. We have bots (and humans) correcting the source for a reason. This is why you will probably notice plenty of people going around and correcting cases of <br> to <br />. It simply doesn't matter that MW is smart enough to send the latter to the browser on-the-fly without correcting the source. The source has to be clean. A very probable (maybe already common!) use case for repurposing WP content is to get the WP database, load it into a customized instance of MW, remove all unwanted templates, subst all the rest of them with a bot, and replace all wikimarkup with its XHTML equivalents, then export the resulting lovely, validating XHTML code to a completely different kind of server. Not correcting <br> and not fixing ] ] in the wiki code itself is going to really screw up that kind of WP content re-use. — SMcCandlish ‹(-¿-)› 01:07, 5 April 2008 (UTC)

I agree with SMcCandlish that dates formatted like February 29, 2008 should have a comma, because to drop the comma is incorrect, and dates should appear correct to those who do not set any date format preference. I do not agree that dates which totally lack markup will ever be formatted automatically. One obstacle is dates within direct quotations; these should not be reformatted. Another obstacle is cases where the number following the month and day is not a year, but some other quantity. To make up an example, "The number of prisoners taken on February 28 was 2000, and on February 29, 2500." --Gerry Ashton (talk) 01:31, 5 April 2008 (UTC)

Trivial. Unusual cases like that would be handled in exactly the same way as us not wanting to autowikilink in a quotation that read "...I thought it was ISBN 978-1-59874-011-0 but it wasn't...". Just do this: "...I thought it was <nowiki>ISBN 978-1-59874-011-0</nowiki> but it wasn't...", which renders as "...I thought it was ISBN 978-1-59874-011-0 but it wasn't...", as it should. We do this stuff all the time, like when you need to italicize something that begins with an apostrophe, etc., etc., etc. — SMcCandlish ‹(-¿-)› 05:50, 5 April 2008 (UTC)

SMcCandlish is right on the mark: we should not count on questionable MW software to correct our sloppiness. I have added green check marks to the table to show what is approved by this manual. Chris the speller (talk) 18:05, 7 April 2008 (UTC)

My clarification of the table has been reverted twice, on aesthetic grounds. Apparently, not offending one editor's tastes is more important than having a guideline that avoids confusing many editors. I am walking away from this one. In fact, I will now unwatch this discussion page, which has had the benefit of a few very thoughtful and eloquent editors, but has also seen them nearly drowned out by hordes of people intent only on pushing their own personal tastes. This has taken far too much of my time, and I will be happier improving Misplaced Pages articles than trying to wade through all the bickering. Those who stay and continue trying to make this guideline useful have my best wishes. Chris the speller (talk) 04:12, 9 April 2008 (UTC)

• Chris the speller: I’m sorry to see you go. I haven’t been involved in this discussion thread. I only became interested because of the post at the very bottom of this page (∆ here) talking of “awful kindergarten graphics”. That of course, made me curious. Which page? This discussion page? I had to search to find out that the “kindergarten graphics” being referred to was check marks: …which you used in a table. They didn’t seem bad to me and you certainly didn’t deserve the smack down you received.

  I encourage you, Chris, to come on back and get back into the saddle soon after the sting wears off. I really think MOSNUM needs an infusion of new blood. I’m not suggesting that there is anything wrong with the current “regulars”—not at all; we need old-timers to help keep us on track and explain history to us so we aren’t doomed to repeat past mistakes. On the other hand, I think it was wrong for a new arrival to get so soundly stomped on over such a trivial issue as the relative aesthetics of a checkmark. One of the editors posted this for their edit comment when he/she deleted your check marks: “removing yet more ugly check marks; approved by who?” Someone please correct me if I’m wrong here, but anyone can make minor edits on MOSNUM. Yes, like anything else on Misplaced Pages, those changes can always be reverted when another editor disagrees. But I don’t think Chris needed “approval” from one of the regulars around here to add them.

  May I suggest we try to be a bit more accommodating to outsiders here? I think Chris the speller is feeling a bit like the first female firefighter to try to join the NY City Fire Department: more than a bit unwelcome. Only, what is at stake here isn’t as important as the physical ability of a firefighter to “carry a 200-lb mayor out of a burning building”. Talk:MOSNUM is a market for the exchange of thought. I hate to sound like a University poster-boy for politically correct slogans, but some extra diversity of opinion can be very helpful on MOSNUM and we need to help newcomers to feel welcome. If there was more “history” to this spat than is apparent and this issue was just a “straw that broke the camel’s back” so to speak, I apologize for interceding without having researched this better. But at this point, I’m just not seeing a good justification for what lead up to Chris calling it quits on MOSNUM. Greg L (my talk) 05:04, 9 April 2008 (UTC)

We already had this discussion in early February after I pointed out the table showed the wrong rendered formats for the comma cases. Chris the speller then placed red checkmarks with the comma cases, which I removed since they do render to one of the standard date formats, and we came to an agreement to have the double-asterisk ** note. Or so I thought. Sorry for being a bit abrupt, but I was surprised when the same edit appeared a couple days ago claiming some forms were now "approved".

I think it's a bad idea to list "approved forms" for wikitext. If it doesn't concern appearance, it shouldn't concern the Manual of Style, which is a guide for the style and formatting of articles as they are read. The MoS discusses wikitext occasionally to note alternatives producing the same rendered page, such as either one or two spaces after a period. As far as I know, we don't have MoS pages telling people to only use one space, or to write <br />, or to format cite templates with one field per line, or to use cite templates rather than hand-written references. Or do we now? Gimmetrow 07:26, 9 April 2008 (UTC)

• No, you didn’t come across as abrupt at all Gimmetrow; thanks for taking the time to fully explain this. As I feared, this was a “tip of the iceberg” issue. It seemed a lot more trivial than that due to SandyGeorgia’s post, which read “I just tried to remove some awful kindergarten graphics from this page, but edit conflicted with Gimmetrow, who beat me to it. Please, this isn't a picture book, and we don't need these illustrative gimmicks.”. As you can imagine, given that post, and your recent edit summary statement, the conflict seemed much more superficial—and unwaranted—than it really was. Greg L (my talk) 16:07, 9 April 2008 (UTC)

Uncertainty vs. repeating decimal

I have just edited the Conversion of units article because it used parentheses to indicate a repeating decimal. For example, it used "3.3(3) × 10−4 m" to mean that the rightmost 3 repeats forever. I changed it to read "3.3 ×10 m" because this notation is also used for repeating decimals, and it will not be confused with uncertainty.

An example of an expression of uncertainty is in Seidelmann's Explanatory Supplement to the Astronomical Almanac (1992, p. 693) where the Newtonian constant of gravitation is given as 6.67259 (85) ×10 mkgs. A longer expression for the same thing would be 6.67259 ×10 ±0.00085 ×10 mkgs

I believe this guildeline should have a section added to specify that repeating decimals are expressed with overbars, not parentheses, to avoid confusion with an expresion of uncertainty. I also believe that it should have a section recommending that uncertainty should be expressed with ± notation rather than parentheses because people unfamiliar with this notation would not know the order of magnitude of the uncertainty. That is, in the previous example, it isn't obvious whether the uncertainty is ±0.00085 ×10, ±0.000085 ×10, or ±0.0000085 ×10. --Gerry Ashton (talk) 19:22, 8 March 2008 (UTC)

Good point. This looks like sensible advice to me. Thunderbird2 (talk) 19:32, 8 March 2008 (UTC)

±8.5 ×10 may be easier to read, as long as we're recommending; but the deprecations should include a caveat: 3.3(3) × 10−4 m would be fine, if it were clear what was meant. Septentrionalis PMAnderson 21:40, 8 March 2008 (UTC)

BIPM advocates use of parentheses in this way. And that would be fine if it were clear to everyone, but that's a big if isn't it? Thunderbird2 (talk) 21:50, 8 March 2008 (UTC)

• Note above that the plus-or-minus sign requires a space, and en dashes or minus signs are required, not hyphens. Tony (talk) 00:51, 9 March 2008 (UTC)
  • Disputed, as invisible nonsense. Septentrionalis PMAnderson 16:19, 10 March 2008 (UTC)
    • Is it the span tag to create the overbar that you dispute? If so, do you have a solution to the ambiguity? --Gerry Ashton (talk) 19:36, 10 March 2008 (UTC)
      • No, I dispute the mandatory space around ± (we should do what is clearest in the circumstances), and the mandatory use of a endash instead of a hyphen in an exponent, where the difference is invisible to the reader. Septentrionalis PMAnderson 22:47, 10 March 2008 (UTC)
      • The substantive question of ambiguity should be dealt with by suggesting explanatory phrases at first use of any of these notations. Any of them will be clear to some readers and unknown to others. Septentrionalis PMAnderson 22:49, 10 March 2008 (UTC)
        • I still feel we should recommend different typography for uncertainty vs. repeating decimals, but I think PMAnderson's suggestion to use explanatory phrases near the first use is wise. Since this is a matter of typography, it would be particularly difficult for readers who don't understand the convention to think of keywords to search for in their favorite search engine. --Gerry Ashton (talk) 23:23, 10 March 2008 (UTC)

The problem with overlines for repeating digits is that there are at least two variants and both have their issues.

1. Inline CSS: 0.1<span style="text-decoration:overline">37</span> – 0.137
2. Unicode: 0.13̅7̅ = 0.13̅7̅ (U+0305) or 0.13̄7̄ = 0.13̄7̄ (U+0304) – 0.13̅7̅ or 0.13̄7̄

— Christoph Päper 20:30, 13 March 2008 (UTC)

The span approach displays properly on Windows XP, both Internet Explorer 7 and Firefox. The unicode approach does not display properly in either case; it displays as a square after the 3 and the 7. --Gerry Ashton (talk) 02:35, 14 March 2008 (UTC)

Yes, the problem with the Unicode approach is its state of support, but the CSS approach is more fundamentally flawed in that the style, which conveys the information, is lost in plain-text environments, such as copy and paste, text or non-CSS browsers, search engines. Using a different HTML element that, unlike span, has a default styling only helps in few of these cases. Years ago I used a non-combining overline (or macron) in front of the first digit to repeat: 0.1¯37 – 0.1¯37. It doesn’t look as good, but is very safe. One could also imagine using brackets or braces instead of parentheses: 0.1 or 0.1{37}, but I think this would be a WP-specific convention, which we try to avoid. — Christoph Päper 09:09, 14 March 2008 (UTC)

I've never seen a non-combining overline before; I didn't even know this character existed. I suspect few people would know how to enter it. I think it would be just as much a WP-only convention as square brackes or curly braces. --Gerry Ashton (talk) 00:30, 22 March 2008 (UTC)

Major objection: "3.3" is completely illegible-as-intended in Mozilla-based browsers (Firefox, Mozilla, SeaMonkey, Camino) under MacOS X using default fonts (i.e. for probably half of all Mac users, since many have abandoned Safari as a slow, feature-poor and crash-prone piece of frak). For those who will even notice the difference at all, it does not look like a three with an overline, it looks like a three with a flat top, like those found in many serif fonts. — SMcCandlish ‹(-¿-)› 00:43, 5 April 2008 (UTC)

Ga, Ma, ka preferred to bya, mya, tya

Misplaced Pages talk:Manual of Style (dates and numbers)/Archive 78 danced around the question, but never quite addressed the question of whether to discourage use of mya, focussing instead on discouraging MYA. Everyone seemed to prefer ka, Ma, Ga although there was some confusion over capitalization (SI usage for multipliers is quite unambiguous: k for kilo, M for mega, G for giga, T for tera, but it seems this wasn't universally grasped). Once archived, the discussion ended without addressing it. As phrased now, it leaves the impression that mya is an equally desirable choice to Ma, yet I don't believe that was the intention of those discussing the question. Reopen? LeadSongDog (talk) 07:40, 14 March 2008 (UTC)

I prefer to spell it out in full as "million years ago" wherever it occurs in the article, and use Ma where abbreviation is necessary (e.g. in taxobox fossil ranges). I feel this looks smarter and saves people translating it in their heads each time they see it. I agree that mya is obsolete though. That said, I've not got a very firm opinion yet... Verisimilus T 08:36, 14 March 2008 (UTC)

My feeling from working with a number of geophysicists is that Ma is preferable, and I'm quite willing to agree to a prescription here that it should be preferred. I can't agree with Verisimilus that the whole three-word phrase should be trotted out many times in an article, unless used only twice or three times, perhaps: tedious to read. Besides, the fact of the abbreviation itself helps to focus the readers' minds. Tony (talk) 08:47, 14 March 2008 (UTC)

The present text reads

I would suggest a change to read

Would something like this work for us? LeadSongDog (talk) 17:37, 14 March 2008 (UTC)

Is it really necessary to wikilink each term if you've explained what it means? I find excessive links distracting. What more could a user want to know about "mya" than what it means? Verisimilus T 18:18, 14 March 2008 (UTC)

Fair enough. I had them each wikilinked to annum anyhow, the one time should be enough.LeadSongDog (talk) 19:53, 14 March 2008 (UTC)

Now we have

Absent further comment, I'll make the above change in a day or two.LeadSongDog (talk) 18:10, 17 March 2008 (UTC)

emend: strike "and wikilinked"; RC only gd 4 ¬50000a. --Verisimilus T 19:56, 17 March 2008 (UTC)

How on earth did I miss that??? Good catch!LeadSongDog (talk) 21:56, 17 March 2008 (UTC)

Y Done. LeadSongDog (talk) 18:00, 18 March 2008 (UTC)

Just a followup note to the geophysicist point: That may be true, but I know from equally direct experience that anthropologists definitely (and paleontologists sometimes but not always) prefer kya, mya. I'm happy with the current text since it isn't FORCING one or the other. I strongly suspect that anthro types editing anthro articles will initially use, and reject reversal of, the format they use, and geo/astro types will do likewise with their preferred symbols, so it shouldn't be a big deal. — SMcCandlish ‹(-¿-)› 01:39, 5 April 2008 (UTC)

{{delimitnum}} template

Note that if this section becomes structurally complex, with many different sub-discussions and threads, I will, where necessary to avoid confusion, take the liberty of rearranging things here after-the-fact (after people have responded). However, I will do so in ways that makes it clear who was responding to what. I think this will be necessary to keep this topic organized and understandable.

I thought everyone would be interested to know that another of our regular editors, Zocky visited Kilogram and saw all my cumbersome code (like 6.022<span style="margin-left:0.25em">464<span style="margin-left:0.25em">79</span></span>(30)&nbsp;×&nbsp;10<sup>23</sup>&nbsp;kg), which was all just for generating numbers like

So he created a template, {{delimitnum}}, and now all editors need to code is {{delimitnum|6.02246479|30|23|kg}} to accomplish the exact same thing. This is the issue many of us discussed here at Archive #94 of Talk:MOSNUM. In a nutshell though, this template parses as follows:

{{ template name | significand–delimiting | uncertainty | base–ten exponent | unit symbol}}

The advantage of this template is twofold: values with long strings of digits to the right of the decimal marker will 1) now be delimited with thin gaps (so they are much easier to parse), and 2) the spaces aren’t characters so the values can be copied and pasted into programs like Excel, where they will be treated as true numbers.

The Natural logarithm article (first paragraph) and Kilogram (throughout, with 2 kB of savings) have both been updated with this template.

What Zocky did is quite an accomplishment because other template authors said a function this complex couldn’t properly be done with a template and really required a parser function (magic word). Indeed, the effort was not at all trivial; Zocky invested a great deal of effort to get the template bug free. In fact, I created a special proof-checking sandbox here on my talk page to assist him in his effort.

As far as I know, it should be extraordinarily simple to convert articles that use Zocky’s template to one that uses the parser function once it becomes available; perhaps just a global search & replace to exchange a pipe (|) for a colon (:).

My main purpose here is to alert you all to this parallel effort (a template vs. a parser function) and to let you know it is now available for use. Perhaps now would be a good time to begin discussing a formal MOSNUM policy regarding the use of the template. I propose the following:

---

Per current MOSNUM policy, numeric values must have the integer portions of their significand (the digits to the left of the decimal marker) delimited with commas and the decimal marker must be a full stop (.), e.g. 1,234.567. Further now, the use of the {{delimitnum}} template/parser function (magic word) is “encouraged” and is the “preferred” method for delimiting numeric strings with five or more digits in the fractional portion of the significand (the digits to the right of the decimal marker). The use of {{delimitnum}} delimits values like 6.022461342 so they have the following appearance: 6.022461342 (making them easier to parse) and simultaneously retains their functionality as Excel-pasteable numeric values.

Infurtherance of this policy, the fractional portion of significands may no longer be delimited using either spaces or non-breaking spaces (e.g. coding 0.187 985 755 or 0.187 985 755 to produce 0.187 985 755) because such text strings can break at line-end word wraps and/or are not treated as numeric values when pasted into Excel. Values such as these should be irreversibly “upgraded” via use of {{delimitnum}}. “Irreversibly” means that it is impermissible to convert a value that is delimited with {{delimitnum}} to a simple, non-delimited numeric string.

Further,numeric equivalencies that can wrap between the value and its unit symbol (e.g. 75.2 kg), as well as numeric values expressed in scientific notation (e.g. 15.25 × 10) that were neither created with the {{e}} template nor unified with a non-breaking space and can therefore wrap on either side of its times symbol (×), should be “upgraded” via either 1) the use of non-breaking spaces, 2) use of the {{nowrap}} template, or 3) use of {{delimitnum}}—exclusively so if the value has 5+ fractional-side digits.

---

The effect of this proposed policy, if adopted, is that new editors who don’t know of the template/parser function or how to use it wouldn’t be doing anything “wrong” when they write “3,210.123456”. Existing, hand-entered values like this, which meet the proposed MOSNUM policy, would be considered as acceptable (though not ideal) and may be irreversibly upgraded. Articles like Font size, which 1) uses non-Excel-pasteable non-breaking spaces, and 2) also improperly leaves single dangling digits (like this example: 0.187 985 755 2), would formally be considered as “incorrect” and should be irreversibly upgraded.

Greg L (my talk) 22:42, 14 March 2008 (UTC)

I tried this out in the sandbox and the first attempt failed:

• {{delimitnum|1234567.7654321| |12}}
• with template functioning: Template:Delimitnum
• renders to me in IE7 like 1,234,567.765 4321 096 × 10 (with spurious 096 inserted)

−Woodstone (talk) 22:47, 14 March 2008 (UTC)

There's a limit to significant digits and precision in WPs math magic words. The example in the documentation works with 13 digits, but too many digits will break the template:

• {{delimitnum|1579800.2987281}}: Template:Delimitnum
• {{delimitnum|1579800.29872801}}: Template:Delimitnum
• {{delimitnum|0.2987281}}: Template:Delimitnum
• {{delimitnum|0.29872801}}: Template:Delimitnum

Woodstone's example has 14 digits. A different issue:

• {{delimitnum|1.000001}}: Template:Delimitnum

Gimmetrow 23:00, 14 March 2008 (UTC)

• Indeed. The template sometimes has problems beyond twelve digits—particularly if lots of them are in the integer portion of the signficand, which will be a rare occurance indeed. Still, it is a potential problem and certainly is a legitimate issue to discuss. This was a known inadequacy of the template-based method that was foreseen. Note however, that maybe 95% of the time, values will be a single digit in the integer portion and most of the digits will be in the fractinoal side. It could be that this might be enough of a problem that it can’t be considered as “ready for prime time.” However the Kilogram is likely very representative of the kind of article that will be using this and has encountered no difficulties. Greg L (my talk) 23:21, 14 March 2008 (UTC)

There is still a problem with a single digit in the integer portion: {{delimitnum|1.01}} = Template:Delimitnum, {{delimitnum|1.001}}: Template:Delimitnum. This can be fixed, though, as it's not a fundamental limitation (like 13-14 digits). Gimmetrow 23:38, 14 March 2008 (UTC)

• I can see that the template may be too buggy. I noticed that while in preview mode while making my edits, all my examples were working fine but no longer worked after I saved the page. I believe what was occurring is that previous wonked-out examples (for instance, Woodstone’s examples weren’t parsed as he intended), and your 14-digit values left the template on the fritz. I can’t defend this behavior. As you can see from Kilogram, it worked great there. I don’t know whether to pull this proposal. Please see this sandbox, which really exersized the template (I think). Greg L (my talk) 23:27, 14 March 2008 (UTC)

• Clearly, given that there are still some problems with some values, I’m withdrawing my proposal that the template be formally made available for general use. Zocky and I both worked hard to proof-check the template and thought it had been thorougly wrung out. I can now see it wasn’t. I’ll continue to use it in Kilogram as it works damn nicely there. However, I am rather expert in its use and pay particularly close attention to the numbers when I use the template. It clearly can't be put into the hands of general users until it can reliabily work with ≤12 digits. I know Zocky has put so much work in this too.

Show below is what it does do rather well now (at least in "Show preview" mode. I’ll see how they look when I click “Save page” here…

NOTE: THE BELOW MAROON EXAMPLES USE A MONOSPACED <code> FONT. THERE ARE NO SPACES INSERTED BETWEEN BLANK VERTICAL SEPARATORS (|) OR “PIPES” (adviso added later by Greg L (my talk) 21:22, 15 March 2008 (UTC))

{{delimitnum|12345.6789012}} → Template:Delimitnum
{{delimitnum|12345.6789012||12|}} → Template:Delimitnum
{{delimitnum|12345.6789012||12|Hz}} → Template:Delimitnum
{{delimitnum|6.02214179|30|23|kg}} → Template:Delimitnum
{{delimitnum|1579800.298728}} → Template:Delimitnum
{{delimitnum|1.356392733||50|Hz}} → Template:Delimitnum
{{delimitnum|0.45359237|||kg}} → Template:Delimitnum
{{delimitnum|6.022461}} → Template:Delimitnum
{{delimitnum|6.0224613}} → Template:Delimitnum
{{delimitnum|6.02246134}} → Template:Delimitnum
{{delimitnum|6.022461342345}} → Template:Delimitnum
{{delimitnum|1579800.298728|||}} → Template:Delimitnum
{{frac|{{delimitnum|1.602176487||–19|}}}} → 1⁄Template:Delimitnum

Greg L (my talk) 23:51, 14 March 2008 (UTC)

Zocky, Here’s additional examples, most of which doesn’t work:

{{delimitnum|1.01}} → Template:Delimitnum (I note that no one would use this template to delimit a number that doesn’t need delimiting)
{{delimitnum|1.00001}} → Template:Delimitnum
{{delimitnum|1.10001}} → Template:Delimitnum
{{delimitnum|1.11001}} → Template:Delimitnum
{{delimitnum|1.11201}} → Template:Delimitnum
{{delimitnum|1.11231}} → Template:Delimitnum
{{delimitnum|1.11232}} → Template:Delimitnum (this one doesn’t end with a 1 and works)
{{delimitnum|0.29872801}} → Template:Delimitnum
{{delimitnum|0.29872821}} → Template:Delimitnum (this one doesn’t end with an 01 and does work)

Greg L (my talk) 00:03, 15 March 2008 (UTC)

OK, I thought just showing the problem with 1.01 would be enough illustration, but apparently not given the above examples. The problem can manifest itself in various ways with any group of three starting with a 0. It doesn't just happen with numbers ending in '1', and it's not just a symptom of numbers too short to delimit. Gimmetrow 01:41, 15 March 2008 (UTC)

{{delimitnum|1.0001}}: Template:Delimitnum

{{delimitnum|1.00001}}: Template:Delimitnum

{{delimitnum|1.00101}}: Template:Delimitnum

{{delimitnum|1.00102}}: Template:Delimitnum

{{delimitnum|1.000001}}: Template:Delimitnum

{{delimitnum|1.000002}}: Template:Delimitnum

• I understood that Gimmetrow. I appreciate that you’re in this with us trying to figure out its current limitations. Thanks. In my last example above, I made a it a point to show that a number that finally didn’t end with 01 would work. Clearly, it has a problem with anything ending in an 01. But the bugs don’t end there. I just added a over 200 new progressions to my test sandbox in a special section titled Progressions of features and digits. Please check it out. You can see where it’s having problems and maybe that will guide you in other directions. As you will see there, I tried all 100 progressions that end with two-digit groupings from 00–99. I also added 100 progressions with three-digit groupings from 000–099. It shows that numbers ending with two-digit groupings like 25 or three-digit groupings like 026 can be a problem. The patterns are unobvious. Maybe someone who really understands templates can discern a pattern. Greg L (my talk) 02:47, 15 March 2008 (UTC)

• One problem (the spurious 09x) is roundoff error in the math used to separate the digits. The other problems appear to be: two digit groups with "0" (07) are evaluated as 7 rather than 70 (so treated as a single digit), and a first group of 000 loses the decimal point. Gimmetrow 02:59, 15 March 2008 (UTC)

• Thanks Gimmetrow. Hopefully all this will assist Zocky. That is, if he isn’t sick to death of this exceedingly complex template. Are you out there Zocky?
  
  *crickets chirping*
  
  

  Let me know if I can be of further assistance. Greg L (my talk) 04:17, 15 March 2008 (UTC)

I'm not very proficient with template magic, but may I suggest to do it character based instead of math based? That would avoid problems with number of digits and 01 being seen as 1, or groups of 000 being overlooked. It would place restrictions on the input, such as forbidden commas or spaces, but that would not be a problem in my view. −Woodstone (talk) 13:35, 15 March 2008 (UTC)

Unfortunately, we can't make it character-based with a template, because we don't have the appropriate parser functions. I made a general template for this kind of spacing, {{spaced}}, which can be used to space anything:

v t e Spaced
Characters Soundtrack

. That's a good workaround for numbers that need more precision than parser functions can handle, but it's awkward, especially for the powers of ten.

As for the bugs, the missing . is easy to fix, so I'll go and do that now. I'll also look into the other reported bug and get back to you. Zocky | picture popups 14:42, 15 March 2008 (UTC)

I've fixed two more bugs - the missing leading 0 in 1.01, and the 099 additions that were caused by rounding errors in the parser functions. Any more problems? Zocky | picture popups 15:47, 15 March 2008 (UTC)

Starting to look good. My 14 digit example above works as well now. To even improve more on size of numbers, would it be an alternative to split the integer and mantissa part into separate arguments? So the template would be like {{formatnum|integer|mantissa|accuracy|exponent|unit}}. −Woodstone (talk) 17:22, 15 March 2008 (UTC)

(unindented)

• All: I created an all new section of Delimitnum sandbox with all 3960 possible variations of two, three, and four-digit groupings. I was really tempted to just declare that this is good to go but knew we would have been making the judgment based largely on what we see in the sandbox. I knew better than that and added all possible combinations I can think of which might cause rounding errors. I’m glad I did too because two-digit groups following 5 thru 9 still suffer from rounding errors (with trailing “9”s). Three and four-digit groups are all good though! To see what I’m talking about, go to the two-digit groupings section (click the underlined “two” link, above), and search on the value 0.12501. Greg L (my talk) 20:10, 15 March 2008 (UTC)
  
  

• That was fast. All those have apparently been fixed. Please now search here for all occurrences of these (in both maroon input values and the black output values):

  0.125019
0.125069
0.125101
0.125241
  and
  0.125569
0.125597
0.125601–0.125603
0.125629–0.125631
0.125735–0.125741

  Greg L (my talk) 21:52, 15 March 2008 (UTC)

Section start

Template:Delimitnum

Section end

the above result comes out of {{delimitnum|100000.000001}}
showing to me as 1.0E+5.000001

I had to insert a subsection here because this behaviour is very erratic. I have seen it only happening at the beginning of a section at the beginning of a line with nothing following. Probably not important, but you never know what is lurking behind. −Woodstone (talk) 21:56, 15 March 2008 (UTC)

• It seems to randomly display as 100,000.000 half the time and as 1.0E+5.000 the other half for me (on Safari). Greg L (my talk) 05:25, 16 March 2008 (UTC)

• I created an Excel spreadsheet to help me identify breaks in the progression. Here is a more concise list:

  0.125013
0.125021
0.125041
0.125048
0.125069
0.125075
0.125097
0.125101–0.125104
0.125124
0.125131
0.125153
0.125186
0.125208
0.125214
0.125236
0.125241
0.125263–0.125271
0.125291
0.125298
0.125319
0.125325
0.125346
0.125353
0.125375–0.125381
0.125402–0.125408
0.125431–0.125436
0.125457
0.125485
0.125492
0.125513
0.125520
0.125541–0.125547
0.125568
0.125575
0.125596–0.125603
0.125624–0.125631

  The list goes on but if this all gets fixed, I suspect everything after this will too. Greg L (my talk) 22:56, 15 March 2008 (UTC)
  
  

• For convenience, I’ve here provided a triple-view of some of the above. They parse as follows:

  input → live template return / (at time of this posting)

  0.125402 → Template:Delimitnum / (0.125 402) ✓ The following are all supposed to end with three-digit groups
  0.125403 → Template:Delimitnum / (0.125 402)
  0.125404 → Template:Delimitnum / (0.125 403)
  0.125405 → Template:Delimitnum / (0.125 404)
  0.125406 → Template:Delimitnum / (0.125 405)
  0.125407 → Template:Delimitnum / (0.125 407) ✓
  0.125408 → Template:Delimitnum / (0.125 407)
  0.125431 → Template:Delimitnum / (0.125 43)
  0.125432 → Template:Delimitnum / (0.125 431)
  0.125433 → Template:Delimitnum / (0.125 433) ✓
  0.125434 → Template:Delimitnum / (0.125 433)
  0.125435 → Template:Delimitnum / (0.125 434)
  0.125436 → Template:Delimitnum / (0.125 436) ✓
  0.1235436 → Template:Delimitnum / (0.123 543 599) This one is supposed to end with the four-digit group “5436”
  0.29872821 → Template:Delimitnum / (0.298 728 209) This one is supposed to end with the two-digit group “21”

  Most of this data was discovered at Delimitnum sandbox in the newly added section with 3960 possible variations, which displays all possible variations of numbers ending in two, three, and four-digit groupings.

  Greg L (my talk) 00:34, 16 March 2008 (UTC)

Greg, this looks very promising. Pleasing to see that the MOS requirements for the spacing of the × are observed by the template (although the + sign seems to be squashed, but is of course relatively uncommon). Tony (talk) 02:08, 16 March 2008 (UTC)

Thanks Tony. I’m not trying to be difficult, but what plus sign? Greg L (my talk) 03:01, 16 March 2008 (UTC)

My overall impression here is that the fundamental way of working in the template is too vulnerable. If so many special cases need to be distinguished and remedied, we can never be sure the output will be dependable. You never reacted to my suggestion above to split the integer and fractional part in the input to the template. So it would be like {{formatnum|integer|mantissa|accuracy|exponent|unit}}. With an example of use {{formatnum|1000|.0001}} (note the dot). This would allow easier manipulation of the fractional part and double the maximum number of digits. Also, as remarked by above by Tony, a leading explicit "+" sign should be maintained. −Woodstone (talk) 09:14, 17 March 2008 (UTC)

• Woodstone, I tend to agree with you; it doesn’t look very promising that anyone—even Zocky—can overcome the fundamental limitations of templates. Perhaps in the future, templates will have access to character-based parser functions. Unless Zocky pulls a rabbit out of the hat on this one, it seems the template-based version of {{delimitnum}} won’t be something that can be put into the hands of the general editing community. However, it will only be a short time before one of our behind-the-scenes developers delivers a parser function-based magic word by the same name. As it will use character-based (not math-based) delimiting, it is a much simpler process. I heard yesterday from the developer that the magic word is done but he isn’t happy with the look of the code. “Programmers,” you see; they like tight code.
  
  In response to your above statement: “Also, as remarked by above by Tony, a leading explicit "+" sign should be maintained”, I assume you mean a default + sign should precede positive base-ten exponents (e.g. ×10). I’m sure there are different ways to format scientific notation. However, the way it has been implemented here is a very common and exceedingly professional way to do it; both the NIST and BIPM, for instance, format scientific notation the exact same way (see NIST:Fundamental Physical Constants and SI Brochure, Section 3.1). As you can see, both default to omitting the utterly unnecessary + sign in front of positive base-ten exponents. This reality is acknowledged in Misplaced Pages’s own Scientific notation and SI Prefixes articles as well as the {{SI multiples}} and {{e}} templates. Coding {{e|9}}} and {{subst:e|9}} omits the preceding + sign and returns ×10. I note however, that the {{e}} template doesn’t properly add spaces on each side of the × sign (see the above-linked NIST site, as well as SI Brochure: 5.3.5 for examples of proper formating in this regard). This oversight was addressed with {{delimitnum}}, which takes care of delimiting both the integer and fractional sides of the significand, and handles uncertainty, and base-ten exponents, and the unit symbol. One-stop shopping for expressing numeric equivalencies.
  
  Don’t despair though, if a user really has a “thing” for the unnecessary + sign and doesn’t care if he or she is flouting the BIPM and NIST, they can always code {{delimitnum|1.567892||+9|kg}} to obtain Template:Delimitnum, just as can currently be done with the existing {{e}} template. You can put anything in these templates, including Template:Delimitnum. In my opinion though, the practice of using the plus sign in front of positive exponents should be generally discouraged by official MOSNUM policy unless it is being used in Misplaced Pages articles on advanced mathematical concepts where the distinction must be emphasized for some reason.
  
  Note that every single aspect of this template was debated for a long time by many users—including Tony—here at Archive #94 of Talk:MOSNUM and everyone was quite pleased with the proposal. It seems to me that that was the time for appearance issues like adding a + in front of positive exponents to be raised so all the others could weigh in on the subject. Does it strike either you or Tony that now is the time to try to change things after all that discussion has transpired (and after a near-unanimous consensus has already been achieved)? There were one or two things I might have changed after-the-fact on this template myself but I was disinclined to even head down that path since I am entrusted with shepherding the group’s consensus decision through to completion in good faith. Greg L (my talk) 17:10, 17 March 2008 (UTC)

Actually I was referring to an explicit "+" for the whole number. Entering {{delimitnum|+123}} results in "123" without "+" sign. But I now realise the problem can be circumvented by entering +{{delimitnum|123}}. This trick should be added to the description of the template (whenever it comes to releasing it). −Woodstone (talk) 10:49, 18 March 2008 (UTC)

Sandbox moved

All: I moved the proof-checking sandbox to User:Greg L/Delimitnum sandbox. Greg L (my talk) 23:06, 17 March 2008 (UTC)

Deadly failure

I think I found a deadly failure of this concept for the template (using arithetic for formatting). Look at:

• {{delimitnum|1.1200|25}}
• which should lead to 1.1200(25),
• but with current methods would come out like 1.12(25) (my hard coding)
• or from the current template as Template:Delimitnum (for me now mysteriously looking like 1.012(25))

The problem is that in such cases the trailing zeroes are significant. Leaving them out changes the meaning of the accuracy indicator.
−Woodstone (talk) 09:27, 19 March 2008 (UTC)

• Thanks Woodstone. I’ll copy this to the top of the sandbox to ensure it is noticed. Greg L (my talk) 18:29, 20 March 2008 (UTC)

• I posted it over on the sandbox. I doubt that a math-based template can do anything about this one. The upcoming character-based magic word should be able to properly digest it. But just to make sure this issue is dealt with, I notified the developer of the magic word than trailing zeros in the significand shouldn’t be truncated if the uncertainty pipe has a value in it. Greg L (my talk) 18:53, 20 March 2008 (UTC)

In my opinion, numbers should never be truncated. Just use whatever digits the editor supplies. −Woodstone (talk) 09:18, 24 March 2008 (UTC)

• It's not impossible to overcome this type of thing with templates (look at {{rnd}} for example) but if there's a magic word in the works, might we not just be happy to hold our breath? Jɪmp 03:49, 24 March 2008 (UTC)

In template "rnd" this can be achieved because the number of digits is an explicit parameter. Requiring that in this case would make the template less usable.−Woodstone (talk) 09:18, 24 March 2008 (UTC)

Consensus?

Um, since when was there any consensus at all that this weird and user-confusing spacing of long numbers was going to be sanctioned by MOS in the first place? I realize I've been off doing other things for a while but the last time I checked in on that debate, there was a strong majority against it, as a geeky practice that no one but mathematicians is likely to understand, with most users experiencing strings like that as a bunch of separate numbers. Just because some people have spent inordinate amounts of time developing elegant templates to do something doesn't mean that doing them makes any sense on WP. If I really did miss an overwheming consensus shift, then we at least need to make the spaces way smaller, like half that size.

PS: Lest I be thought to be nothing but a nay-sayer today, I will add that I like the fact that the spacing effect (which I hate in this case, because no one writes numbers that way but people in lab coats) is done entirely in CSS and does not touch the content in any way. I think a solution like this would probably be much better than  -spacing in a lot of other cases, and would also obviate all the angsting over at WP:MOS proper about the inability to use   because some browsers don't support it – you could simply have one template that took a space character and made it smaller for cases where a space really does belong there in the content but looks too big on-screen, and another to use the above pure-CSS spacing trick to make things visually easier to read without actually inserting any spaces. But I'm rambling... — SMcCandlish ‹(-¿-)› 01:26, 5 April 2008 (UTC)

{{val}}

Just to add to the conversation, I created {{val}} (or {{ScientificValue}} as it was originally known). It has some of the features that {{delimitnum}} has, but lacks the spacing. It does have a few added features, which I think make it better. I am looking at copying the spacing code from {{delimitnum}} into val (or just transcluding it). I hope that we can merge the two into one template that covers all requirements for values. Since {{val}} is still "in production", we can make breaking changes there without having to modify large amounts of pages. Once {{val}} is done, maybe we can deprecate one or the other name and get a bot to modify all current use of both {tl|val}} and {{delimitnum}} and manually coded values to use the new template?
-- SkyLined (talk) 16:53, 9 April 2008 (UTC)

I'm no bot expert but with a combined total of about a dozen articles ...

Template:Delimitnum (edit | talk | history | links | watch | logs)

Template:ScientificValue (edit | talk | history | links | watch | logs)

... it may be easier to convert them over manually. JЇѦρ 17:02, 9 April 2008 (UTC)

Perfect, though I'd like to look at converting manually entered values to use of this new template, which would include a much larger number of instances (and would be substancially harder to do correctly)
-- SkyLined (talk) 17:06, 9 April 2008 (UTC)

Years

Start of discussion moved from Lightmouse talk page
You had best stop un-bracketing years until you get some consensus. I'm reporting this to WP:ANI. Baseball Bugs 12:59, 20 March 2008 (UTC)

You were already blocked once for this activity. STOP IT. Baseball Bugs 13:03, 20 March 2008 (UTC)

Right I don't know what is going on here but please stop for now. Contribute to the discussion on the AN/I but stop delinking the dates. Theresa Knott | The otter sank 13:10, 20 March 2008 (UTC)

As I understand it, the place to debate policy on dates is Misplaced Pages talk:Manual of Style (dates and numbers). Feel free to raise it there. Lightmouse (talk) 13:13, 20 March 2008 (UTC)

First rule: Don't cop an attitude with an admin. Baseball Bugs 13:17, 20 March 2008 (UTC)

That's fine I don't care. Lightmouse I do not wish to debate the policy. I only wish to make sure that you actually have concensus for your changes. Can you point me to the discussion that shows this please. Theresa Knott | The otter sank 13:20, 20 March 2008 (UTC)

At the very least, the user did not get consensus from anyone to clobber the "year in baseball" template entries. Baseball Bugs 13:41, 20 March 2008 (UTC)

Lightmouse, you continued making controversial edits after you've been contacted abouts this. I've withdrawn your AWB approval for duration of discussion at WP:ANI#Units and Years. Please respond there. MaxSem 14:02, 20 March 2008 (UTC)

Baseball Bugs, I am not sure what 'cop an attitude' means but that phrase along with the word 'defiant' used elsewhere sounds like an accusation of incivility. I have no incivil intentions in my responses. I try to be polite and expect the same from others. Please assume good faith.

There are popular misconceptions about date links so it does not surprise me that it is being questioned. I would prefer not to describe the policy here. Quite apart from anything else, you may not feel comfortable with what I say about it. There are plenty of other editors there that have extensive experience with this issue at Misplaced Pages talk:Manual of Style (dates and numbers). I would be happy to see you there. I hope that helps. Lightmouse (talk) 14:36, 20 March 2008 (UTC)

End of discussion moved from Lightmouse talk page

• Hard to discern what this is about. If Lightmouse is delinking trivial chronological itmes, such as 1998 and 1970s and 20th century, I applaud it. He has the weight of MOS behind him. Read the guidelines, please.Tony (talk) 02:57, 23 March 2008 (UTC)

I randomly selected about 25 of Lightmouse's recent edits of this nature, and they all seem well within current date policy to me. -/- Warren 04:25, 23 March 2008 (UTC)

I have the impression that Lightmouse was, as usual, implementing MOSNUM consensus, when an admin over-reacted to a change that was not to his liking. The discussion of the entire non-incident is archived here. Thunderbird2 (talk) 15:31, 23 March 2008 (UTC)

I've just noticed that Lightmouse has not done any editing since posting the avove message. I hope he is just taking an Easter break. Thunderbird2 (talk) 15:36, 23 March 2008 (UTC)

I have been watching the discussion. I appreciate the contributions made by all. I would appreciate your further assistance in getting my AWB approval reinstated. See the statement above by MaxSem (I've withdrawn your AWB approval for duration of discussion at WP:ANI#Units and Years) and my request for reinstatement at Wikipedia_talk:AutoWikiBrowser#Please_reinstate_approval.

Lightmouse (talk) 11:03, 24 March 2008 (UTC)

If Baseball Bugs is the admin in question (I'm not sure I followed the rant correctly), he should actually be severely sanctioned at ANI. It is unbelievably inappropriate for an admin to attempt to intimidate another editor into yielding on a legitimate editing dispute by pulling rank and very obviously implying a blocking or other admin-level retaliation threat, especially a borderline-incivil one at that. — SMcCandlish ‹(-¿-)› 02:13, 5 April 2008 (UTC)

Scientific notation (aka Standard Form) discussion

There's a discussion at the main MOS talkpage about the prescribed formatting of exponential notation/scientific notation/standard form. Just to make sure interested folks know. SamBC(talk) 22:02, 21 March 2008 (UTC)

Delimitnum revisited

I am no mathematician, but I am a crazy software engineer and researcher that like to think outside the box. Or rather look at problems from many angles, like for instance backwards.

So {{delimitnum}} did get a "deadly failure". (See discussion in an earlier section.)

So lets do it the other way around. Instead of chopping up a number using maths and put in commas etc, instead lets put the number together only using strings and no maths.

Here is a basic example:

{{dnum|1|.|123|45|x|10|25|kg}}

Which would render something like this :

1.123 45 × 10 kg

And a monster example:

{{dnum|-|1|500|000|.|123|45|(30)|x|10|25|kg}}

Which would render something like this :

−1,500,000.123 45(30) × 10 kg

Template:Delimitnum

Such numbers should be pretty simple to input since the user only has to input normal dashes "-" and a normal "x", not the special maths symbols. I let them input the base 10 too, since that makes the input more readable and is more flexible. Oh and this of course means that inputting "+" and "000" is no problem either, they will not be dropped when the number is rendered, since it isn't a number that is rendered but rather a string.

I think I know how to code up such a template. The only maths involved here would be to detect that the string "(30)" is not a number, since it seems you guys don't want any spacing between the 45 and the (30). But if you allow a spacing there the template code gets much simpler.

With spacing I of course do not mean "spaces" but the narrow spacing trick mentioned before that makes the numbers copy-and-pasteable to other programs.

Would such a template be useful?

--David Göthberg (talk) 23:43, 22 March 2008 (UTC)

• David, it’s great to hear from someone who’s really interested in what {{delimitnum}} has to offer. As you’ve no-doubt witnessed at the Delimitnum sandbox, using math-based parser functions within a template is a recipe for banging one’s head against a wall. Your proposal sounds like it would be perfectly workable. As you may also have seen on the initial proposal, here on Archive #94 of Talk:MOSNUM, the delimiting is done with <span> tags. That itself shouldn’t be a problem except that spans following the digit 1 are specified slightly narrower so they have the same visual appearance. The magic word-based version of {{delimitnum}} will use character-based parser functions as you are proposing. With any luck, we should have it within about a week. Since it will used character-based parsing, it will be imune from rounding issues. For instance, {{delimitnum|1.1200|25||kg}} will return 1.1200(25) kg, not 1.12(25) kg.
  

  Where I could really use some support right now is on an issue of computer nomenclature. It involves abandoning the use of terms like “250 GiB file size” and proposes to adhere to the better-recognized units (e.g. “250 GB file size”). What do you think about this position statement and this specific MOSNUM policy (in light green)? Greg L (my talk) 00:23, 23 March 2008 (UTC)

Ah okay. So the {{delimitnum}} magic word is not that far away. Right, then no use in spending time on making a template for it. I noticed some days ago that you were banging your head in the wall with {{delimitnum}}, just had to think for some day what to say.

Ok, I'll take a look at the GB vs GiB issue although I have to admit I dislike style issues. I am a software engineer, not a stylist. But I guess in the GiB issue you need some engineers.

--David Göthberg (talk) 01:21, 23 March 2008 (UTC)

Silly, I always forget to ask this, been thinking about it for days: Greg L: Why didn't you use MediaWiki TeX to render the numbers? It does have text output for simpler formulas. Or does it render the text to bad?

--David Göthberg (talk) 01:30, 23 March 2008 (UTC)

• David, the biggest advantage of the upcoming magic word is it will automate the job of a grouping the digits. Many users will simply forget that you don’t leave a single dangling digit, like 1.234 456 8. No matter what the editor inputs, the {{delimitnum}} magic word knows to parse as follows:

2.1
2.12
2.123
2.1234
2.12345
2.123456
2.1234567
2.12345678
2.123456789
2.1234567890
2.12345678901
2.123456789012
2.1234567890123

Regarding the use of MediaWiki TeX, I do if it’s absolutely necessary, such as for ${\displaystyle V={\sqrt {\frac {{K_{b} \over 2}\cdot T}{m \over 2}}}}$

But for straightforward numeric equivalencies, like this:

“

…the quantity known as the Avogadro constant, is an experimentally determined value that is currently measured as being Template:Delimitnum atoms (2006 CODATA value).

”

…I use either hand coding or the {{delimitnum}} template to avoid the change in text associated with <math>, which interrupts the reading flow. Regards. Greg L (my talk) 02:54, 23 March 2008 (UTC)

1: Ah, I didn't know about how to handle those dangling digits. We delimit numbers differently in my country (Sweden). So yeah, automating it is nice. He, come to think of it, that puts that magic word into trouble, since preferably it should be able to delimit numbers in the right way on all the different language Wikipedias. That coder has a big task ahead of him... Or of course, he could be "lazy" and just do English delimiting and the other languages have to do hand delimiting. Ehm, perhaps I should code a {{dnum}} template for my language instead.

2: I think you might have misunderstood what I meant by using MediaWiki TeX. The default is that it outputs text, not images, for simpler "formulas". So it doesn't interrupt the reading flow as you thought. Perhaps you have set TeX to only show images in your Misplaced Pages user preferences?

--David Göthberg (talk) 03:19, 23 March 2008 (UTC)

• Regarding your point #1 above, Americans don’t usually delimit the fractional side of the significand. Professionally done work does and the only proper way I know originally came from the ISO and is done as illustrated here at the NIST and here at the BIPM (SI Brochure: 5.3.5 Expressing the measurement uncertainty in the value of a quantity). Here is the NIST’s last two-digit grouping, their 3-digit and their four-digit last group.

  As for your point #2, I don’t understand. I’ve set my Wiki prefs to “Recommended for modern browsers” and it shows the above example as large symbols. You seem to be suggesting that simple formulas show as straight text. Please provide an example. I am inclined though, to continue to use hand-coded text or use of magic words and templates, as I am certain what the appearance will be for all readers irregardless of their browser and user prefs. Greg L (my talk) 05:02, 23 March 2008 (UTC)

• P.S. If by “ differently in my country” you mean, the Euro-way: narrow spaces on both sides of the decimal marker, and the decimal marker is a comma, not a full-stop, then yes, it’s done differently in America. And that’s the convention the en.Misplaced Pages standardized upon: comma delimiting to the left of the decimal marker, which is a full a full-stop. The magic word does not even pretend to change any of that; advocating to do so just would never happen. All it does is add much-needed narrow-space delimiting to the fractional side of the decimal marker. Greg L (my talk) 05:25, 23 March 2008 (UTC)

2: Ah, the point is moot. I tested my user settings for math (MediaWiki TeX rendering). As I remembered I can get it to show as HTML for simple formulas and as PNG when more complex. But in both cases it doesn't delimit numbers. So 123456789.123456789 just shows up like this when using TeX: ${\displaystyle 123456789.123456789}$ So doesn't help us at all. (Of course, I might be using TeX the wrong way.)

1: Well, the way I learnt to delimit numbers in school in Sweden is like this:

• English: 1,234,567.123 456
• Swedish1: 1 234 567,123456
• Swedish2: 1.234.567,123 456 or was it 1.234.567,123456

My bank statements and my Swedish MS Windows use Swedish 1, and that is the more common way we do it. I have mostly seen Swedish 2 in really old printed matter, as in early 1900s and older.

I also took a quick look at the Swedish Misplaced Pages, and there MediaWiki TeX clearly is set to use the decimal comma ",".

See what I mean with that the delimitnum magic word will need localisation if to be used in other language Wikipedias? I am not advocating to change the delimiting in English Misplaced Pages, why would I? But magic words are part of the MediaWiki software and as such is supposed to work on all language Wikipedias. And that is why I mentioned it since you seem to be in contact with the dev that is coding that magic word.

--David Göthberg (talk) 06:07, 23 March 2008 (UTC)

• Yes. I understand enough about the details of the magic word to know that it should be almost trivial to customize it for any language. The hard part is all the parsing logic and the rules governing span width. I was familiar with Swedish1 (and a variant that delimits the same way on the fractional side too). I didn’t know about Swedish2. I like Misplaced Pages because it is such an awesome way to learn. It’s my bed time. Bye. Greg L (my talk) 06:14, 23 March 2008 (UTC)

Yeah, I agree. Since using narrow spaces seems to be the most popular in most languages it should be trivial to switch between using a decimal "." or ",". And narrow spaces is anyway the delimiting that has the lowest risk of misunderstanding. Anyway, sleep well. Bedtime for me too I think.

--David Göthberg (talk) 06:26, 23 March 2008 (UTC)

It certainly can be done. {{Formatnum:}} is language dependant. Jɪmp 04:00, 28 March 2008 (UTC)

Units

Which system to use

* For US-related articles, the main units are US units; for example, 23 miles (37 km). * For UK-related, the main units are either metric or imperial (consistently within an article).

* For other country-related articles, the main units are metric; for example, 37 kilometres (23 mi).

Let us end the confusion by adopting the Metric first, Colonial/Imperial second rule (Option 3). It will make editing easy when the U.S. metricates. I must also add that some items like broadcast antenna heights are always listed in meters and the current rule is a very ambiguous burden to subjects such as these. SirChan (talk) 17:18, 25 March 2008 (UTC)

I agree - it does seem confusing and unnecessary to make a special exception from the general "use SI units" rule in this instance. Verisimilus T 21:07, 25 March 2008 (UTC)

I diagree. There is no guarantee that the US will ever metricate, and for US articles it makes sense to have the nationally preferred system of measurement listed first. Cheers, Rai-me 22:48, 25 March 2008 (UTC)

To Verisimilus: The American has to tilt their head to read the Colonial units on a non-US or international article, the Brit might have to change mindsets every time he reads an article, and the others have to tilt their heads in order to read the metric units in a US specific article or might not have an appropriate metric value in a British article.

To Rai-me: My mom has a maxim, "Always be prepared." The U.S. government has stated since 1866 that this is the preferred system but has been busy with other matters. Metrication has been increasing in recent years--just look at bottled water! This is on the internet; any English-speaking person can find out information about something U.S. or U.K. specific. (To all:) These rules are Byzantine! I might as well include Julian dates in articles also to accommodate historians and Eastern Europeans. SirChan (talk) 02:30, 26 March 2008 (UTC)

By your mother's philosophy, should we also create an article for the 2096 Summer Olympics to be prepared? Misplaced Pages is not a crystal ball. It is very unlikely that the US will metricate completely at any point in the near future. Whether the US government has stated that the metric system is the preferred system or not has no bearing on this situation. What matters here is what readers will understand, and for Americans, that is obviously imperial units over SI ones. Metrictaion may be increasing slightly (bottled water is actually still mostly in imperial units - soda bottles, however, are in litres), but the system used by far the most often is imperial. I fail to see how the feet (m) system is "Byzantine" when used in American-related articles, as the imperial system is the one that Americans, who are the most likely to read about American topics, understand the best. Misplaced Pages is optimized for readers over editors, so the guidleines should remain as is. Cheers, Rai-me 01:35, 29 March 2008 (UTC)

By the same token, it is very much true that many measurements in U.S.-related articles were originally made in metric units. The present rule is ludicrous. Original units should be first; for articles related to the United States, that will often mean English customary units—but that is by no stretch of the imagination an invariable truth, nor something to aspire to in our MoS. Gene Nygaard (talk) 03:47, 29 March 2008 (UTC)

I am not arguing that we should continue to use the "imperial (metric)" system because it was used first in American-related articles, and shouldn't be changed now. The rules are not, nor should be, the same as those outlined in WP:ENGVAR. The present rule is no more "ludicrous" than the rule to use US$ for American articles, £ for British articles, € for French articles, etc., and not US$ throughout. It makes sense to use the system in an article that is used by the readers of the country relating most to the article topic, so the status quo should not be changed. -- Rai-me 17:06, 29 March 2008 (UTC)

I fail to see how the feet (m) system is "Byzantine" when used in American-related articles, as the imperial system is the one that Americans, who are the most likely to read about American topics, understand the best.

I'm not talking about the measuring systems here, I'm talking about the rules on the units. (BTW, the Imperial system is not used in the U.S., only in the U.K. and the pre-metric system for the Commonwealth realms.)SirChan (talk) 02:02, 31 March 2008 (UTC)

I am talking about the rule as well. The rule is not "Byzantine" if it makes sense to use in order to optimize conditions in American-related articles for American readers. See the article about United States customary units, "Imperial units" is often used to describe US units. It is not used in the same context as English units, but it is still correct. -- Rai-me 02:14, 31 March 2008 (UTC)

←outdent←
I'd been meaning to put my thripence in but Gene's pretty much stated my main point. Currently we've got the following.

1. For US-related articles, the main units are US units; for example, 23 miles (37 km).
2. For UK-related, the main units are either metric or imperial (consistently within an article).
3. For other country-related articles, the main units are metric; for example, 37 kilometres (23 mi).
4. American English spells metric units with final -er (kilometer); in all other varieties of English, including Canadian English, -re is used (kilometre).
5. In scientific articles, use the units employed in the current scientific literature on that topic. This will usually be SI, but not always; for example, natural units are often used in relativistic and quantum physics, and Hubble's constant should be quoted in its most common unit of (km/s)/Mpc rather than its SI unit of s.
6. If editors cannot agree on the sequence of units, put the source value first and the converted value second. If the choice of units is arbitrary, use SI units as the main unit, with converted units in parentheses.

I've replaced the bullet points with numbers for ease of reference. Suppose we replace all of that with "Original units should be first."

1. For US-related articles, the original units will generally be units US units.
2. For UK-related articles, the original units will generally be either metric or imperial units.
3. For other country-related articles, the original units will generally be metric.
4. How a unit is spelt in this or that dialect is irrelevant here.
5. In scientific articles, the original units will be use the units employed in the current scientific literature on that topic.
6. If editors cannot agree on the sequence of units, the original units should be first.

What have we not covered?

• the case where the choice of units is arbitrary
• consistency within an article

The choice would be arbitary if the source(s) give(s) both metric/SI and imperial/US/other. Consistency within an article is a minor concern when stacked up against fidelity to the sources. If the order is changed, this should be noted as a footnote, unless the original was a rough approximation to start with. Jɪmp 07:41, 31 March 2008 (UTC)

Regarding Option 2 (UK Articles), an American or anyone else who reads a UK-centric article that's only in Imperial units is going to be a useless article if the metric value isn't included in parenthesis. The site is worldwide, so the information must be available to the widest possible audience. This Babel of units narrows audiences to a specific group and restricts the flow of information. SirChan (talk) 06:22, 1 April 2008 (UTC)

Similarly, an article with only US units is going to be useless to a non-American. In fact, as an Australian, I have a better feel for imperial units than I do for US units. Conversions to metric should generally be given. JЇѦρ 08:07, 7 April 2008 (UTC)

Ton vs. Tonne

• • Use long ton or short ton rather than just ton (the metric unit—the tonne—is also known as the metric ton).

The tons are very confusing especially in this international context (the Internet). In the U.S. a "ton" is the aforementioned short ton while in the rest of the Anglosphere, the "ton" is the aforementioned long ton. Someone might unknowingly, incorrectly use "tonne" because it is similar to "ton." I'd rather use Megagram over tonne and put the type of unit when talking about the non-metric tons (e.g. Imperial Ton, U.S. Ton).SirChan (talk) 02:55, 26 March 2008 (UTC)

The problem is that megagram is not all that familiar a term to most. Jɪmp 04:01, 28 March 2008 (UTC)

The comfort of a familiar "word", even when you (whether referring to the editor adding the information, or "you" as readers of Misplaced Pages in general) don't have the foggiest idea what it means, is an illusionary goal. I'd say we should just outlaw all "tons" of any sort on Misplaced Pages. Use megagrams, teragrams, and the like for metric units of mass; use meganewtons and the like for the metric units of force; use megawatts and the like for the units of power, joules with appropriate prefix for the units of energy, use pounds for the English units of mass, Btu per hour for the English tons as units of power, cubic feet for the English tons as units of volume, etc. Gene Nygaard (talk) 03:54, 29 March 2008 (UTC)

One of the key concepts of the metric system is, if you know what mega- means, and you know what gram means, then you know what megagram means. I think most people know what mega- means; I'm not so sure about gram. --Gerry Ashton (talk) 04:24, 29 March 2008 (UTC)

Sea of blue

The template name {{nowrap}} is linked four times (on every occurrence) in the section Non-breaking spaces. I would like that we do as we teach, so I would like to fix that. That is, only have the first occurrence linked and the other as normal text. Easy enough to do, just use {{tlf|nowrap}} instead of {{tl|nowrap}}, which will render like this: {{nowrap}}. Any one that disagrees?

--David Göthberg (talk) 18:41, 27 March 2008 (UTC)

So fix it. Nobody's going to worry about as minor an edit as that. If anyone even notices, they'd probably wonder why they hadn't noticed such a glaring oversight. Jɪmp 23:30, 27 March 2008 (UTC)

Well, personally I think that any edit to the MOSxxx pages should be discussed first (except really minor things like fixing some spelling etc). And even though tradition and recommended style is to not wikilink a word many times in one page or section, tradition up until now has been to wikilink template names on every occasion in documentation. So I don't like to just be bold and make an edit to the MOSNUM that goes against tradition.

Of course, the reason people have been wikilinking the template names all the time might have been that up until now they did not have a simple way to write a {{template name}}. But now we have the brand new {{tlc}}, {{tld}} and {{tlf}}. They produce output like this: {{name|parameters}}, {{name|parameters}} and {{name|parameters}}.

Anyway, I did the edit to the MOSNUM since it seems no one disagreed.

--David Göthberg (talk) 18:21, 28 March 2008 (UTC)

Generally I'd agree that edits should be discussed first except minor ones. I'd call that minor. Jɪmp 15:32, 31 March 2008 (UTC)

WP:BOLD, WP:BRD. While the R in BRD is more likely to happen here than on many other pages, the B is policy, and the D is the only way that WP works in the first place. Major changes certainly should be discussed, but I've seen a great number of really good ideas introduced into MOS* pages by bold edits, often reverted, discussed, modified and reinstated, less often but still pretty frequently simply accepted because they were wise. — SMcCandlish ‹(-¿-)› 02:20, 5 April 2008 (UTC)

sq mi v. mi²

While I had no part in the edit to this page that User:MJCdetroit reverted (save for indirectly making him aware of it that changed the use of sq mi instead of mi² for square miles and other square and cubic U.S. customary units from a shall to a may. I'd argue that may is the better option, especially where the metric measurement is the primary measurement and the customary is a conversion. Caerwine Caer’s whines 05:53, 31 March 2008 (UTC)

Or that the page uses too many bytes. His hatred of the metric system made him call the SI symbols abbreviations on my edit. SirChan (talk) 06:12, 31 March 2008 (UTC)

Every change to this page, no matter how small, should be discussed first. SC's changes were not discussed and they changed content that was thoroughly discussed and agreed upon in the past. That's why I reverted your changes.—MJCdetroit 13:43, 31 March 2008 (UTC)

Could you kindly point out that prior discussion? Unless this was settled very recently, I'd like to bring this point up now that it's been brought to my attention. The general style guide that I most often refer to, the GPO Style Manual is fairly conservative in its usages, but it calls for mi² and doesn't even discuss the possibility of sq mi. Caerwine Caer’s whines 18:44, 31 March 2008 (UTC)

The two most recent times it came up was here and here. I think that some of those early discussions also explored the usage of non superscripted abbreviations for metric units; which were pretty heated discussions. There is an earlier discussion somewhere regarding this, but I haven't found yet. —MJCdetroit 20:34, 31 March 2008 (UTC)

The discussion was rather thin in both those links, and given that the style guide I've got access to specifies the use of exponents only, banning the use of exponents for customary units in science articles strikes me as excessive. The arguments given for the current policy stuck me as mostly (with some slight exaggeration) of the variety that since customary units are so quaint and archaic, the people who understand them better than SI can't possibly know what exponents are anyway. Caerwine Caer’s whines 01:05, 1 April 2008 (UTC)

Symbols are only used in SI; all other systems use abbreviations. It is obvious that calling shorthand SI abbreviations instead of symbols is incorrect thus doesn't need to be discussed. Pushing a half-truth to further your agenda is intellectually dishonest. SirChan (talk) 06:12, 1 April 2008 (UTC)

ISO 8601 dates

I'm seeing a rash of these in various articles within the text. Any chance there is a bot that can go in and change these when not used with a reference? Vegaswikian (talk) 06:52, 31 March 2008 (UTC)

Any such bot would have to be semi-automatic, with a person approving every change, because there is no automatic way to detect whether a piece of text is a direct quotation. --Gerry Ashton (talk) 17:45, 31 March 2008 (UTC)

Links to common units of measurement

There are thousands of links to common units of measurement, some in templates. As with links to plain english words, this is contrary to wp:overlink.

It might be hard to get agreement on a complete list of common units. However, the *most common* are responsible for the most overlinking. The following are the most common units:

• inch, foot, yard, mile, millimetre, centimetre, metre, kilometre. Plus their squares and cubes.
• avoirdupois pound, avoirdupois ounce, milligram, gram, kilogram
• millilitre, litre
• millisecond, second, minute, hour, day, week, month, year
• Any combination of the above

Comments? Lightmouse (talk) 17:00, 31 March 2008 (UTC)

Hi Lightmouse. Welcome back :). My view is that there is no need to link to common units of time, nor to the most common SI units (eg m, kg); the entire universe is familiar with these! But I see some units in your list (like pound, inch and foot) that, while common to native speakers of English, are not to those who have learnt it as a second language. I think WP should be accessible to non-native speakers, which means that such units should be linked. Thunderbird2 (talk) 17:33, 31 March 2008 (UTC)

Thanks for your support. I agree with your first and second sentences. In your third sentence, I agree with the principle but not the concluding word 'linked' i.e. I would say 'should be converted'. Lightmouse (talk) 20:34, 31 March 2008 (UTC)

Glad to help.

Yes, if a conversion is included, that weakens the case for a link. I'm not sure if it eliminates it though. What do others think?

A separate, but related point that is specific to feet and inches is the widespread use of ' and " to represent these. Can these be replaced by ft and in? Thunderbird2 (talk) 21:02, 31 March 2008 (UTC)

• Hand, chain, furlong, fathom? Fnagaton 21:45, 31 March 2008 (UTC)
• Scoville, quart, pint, mole? Fnagaton 21:48, 31 March 2008 (UTC)

I think it is time for a proposal. I propose that where wp:overlink says common units should not generally be linked, the following are given as a *examples*:

• millimetre, centimetre, metre, kilometre. Plus their squares and cubes.
• milligram, gram, kilogram
• millilitre, litre
• millisecond, second, minute, hour, day, week, month, year
• Any combination of the above

The list can be extended, but I think it is important to get a small list in place than to spend ages in debate. Lightmouse (talk) 09:22, 1 April 2008 (UTC)

I agree with Lightmouse's list. Thunderbird2 (talk) 16:23, 1 April 2008 (UTC)

There's nothing special about unit names. Common unit names are common words. We needn't link them. We certainly want the encyclopædia to be accessable not only to native speakers of English also to those who have learnt it as a second language. However, if we link every word that may be unfamiliar to these people, WP will turn blue. There exists no word in the English language that everyone in the World knows. A balance must be arrived at, it'll be case by case, but the names of units are not special amongst the words of the language. Also, I think we should not underestimate how well known the common imperial/US units are outside of the English speaking world. JЇѦρ 02:24, 2 April 2008 (UTC)

I concur with the gist of all this; don't care what the specifics of the list are, unless they get goofy. — SMcCandlish ‹(-¿-)› 02:16, 5 April 2008 (UTC)

I have updated wp:overlink.
Lightmouse (talk) 10:58, 6 April 2008 (UTC)

It has now been reverted. Lightmouse (talk) 21:35, 6 April 2008 (UTC)

I thought that it was a fairly uncontroversial edit. Is anyone else willing to resolve this? Lightmouse (talk) 21:31, 8 April 2008 (UTC)

I have added a section at the talk page of wp:overlink inviting contributions here. Lightmouse (talk) 21:53, 9 April 2008 (UTC)

I was the one who reverted it. I did so not because I disagreed but because it seemed so patently obvious that it was unnecessary to explicitly list these examples. Instruction creep is a real problem for Misplaced Pages policy and guideline pages. My concern is that when we list out the measurements, someone will misunderstand and one of two things will happen. Either they will attempt to expand the list with all the thousands of other common words that shouldn't be overlinked and we'll end up with a page that's unreadable and ignored or they will try to argue that the lack of inclusion of something from the list now means that it should be linked. A general statement of principle is better for our readers.
WP:OVERLINK already says "Plain English words, including common units of measurement." It's even the very first bullet on the page. If that's not clear enough, I can't see how including a longer list of examples will make it any clearer. Rossami (talk) 22:42, 9 April 2008 (UTC)

If the issue is confusion over the definition of a "common" unit of measurement (as opposed to an uncommon one, I suppose), perhaps the list could be included as a footnote rather than in-line with the text? Or perhaps a footnote linking to a relevant section of this MoS page? I'm still concerned about instruction creep and would only recommend that approach if there is evidence of significant confusion and/or dispute rather than mere ignorance about the policy. If people are overlinking because they don't know any better, we just need to fix those. Rossami (talk)

I understand and even share your worry about instruction creep. However, some people still insist on linking terms such as those listed here and I have found myself trying to persuade them that everybody else thinks they are common even if they do not. An explicit statement would allow such tedious debates to be resolved quickly. We do not have a big problem with common words but we do with common units. The common unit articles rank almost as high as year articles in terms of number of links to them. Square mile and square kilometre are in the top 50 destination articles, just above '1996'. Metre is almost in the top 100, just above '1969' and 'foot' is in the top 250, just above '1954' (it is interesting to me that 'metre' is more linked than 'foot' even though the former is more common). I don't care how this issue is fixed so if you have a suggestion, that is fine by me. I can't see any means of educating users about this but I can see that explicit statements would allow janitorial editors to remove unremarkable links without getting bogged down in metaphysical discussions about what 'common' means to each disputing user. Lightmouse (talk) 23:20, 9 April 2008 (UTC)

I took a crack at it in footnote format. (And added some things that seemed obvious to me even though they may have gone beyond the short discussion here.) Opinions on readability would be appreciated. If it's too cumbersome, we can always back it out. Rossami (talk) 04:57, 10 April 2008 (UTC)

Thank you. It looks fine in general. I do not understand why the human body weight comment is relevant. What do you want editors to do with that information? The phrase 'regardless of measuring system' appears to suggest that readers must always consider the non-metric reference value that is written there even if using kilograms. The unit symbols are 's' and 'lb' rather than 'sec' and 'lbs'. But thanks for reconsidering, I appreciate that. And I agree that some non-metric units should be there. Lightmouse (talk) 08:54, 10 April 2008 (UTC)

Pressures

I've asked for a conversion template to be made to convert pounds per square inch into kilograms per square centimetre. I'd like the format to be displayed as x lb/in (y kg/cm) but apparantly this may be against the MOS. The discussion is here, along with my reasoning for the use of the display in the proposed format. Comments please. Mjroots (talk) 08:11, 1 April 2008 (UTC)

It seems we have three possible abbreviations:

1. psi
2. lb/sq in
3. lb/in²

Mjroots points out that 2 and 3 are used in the locomotive industry. 1 is a common abbreviation elsewhere. Which do we allow which do we ban? How do we weigh the desire for consistency against the desire to reflect what is used in specific industries? Is 3 against the rules being a US unit (it's also an imperial one) with an exponent 2 instead of "sq" or do we now apply different rules since pounds per square inch could be considered a unit unto itself? JЇѦρ 08:40, 1 April 2008 (UTC)

It is largely a historical unit, although it is still used by various heritage railways in connection with their steam locomotives today. What I'm aiming to achieve is to enable readers in Europe, where kg/cm is the normal measurement to easily be able to compare our boiler pressures to their locomotives. It will also help us to understand their boiler pressures in comparison to our locomotives. Do you know what 12 kg/cm is in lb/in? I don't, wouldn't have a clue without a conversion! Mjroots (talk) 10:39, 1 April 2008 (UTC)

This reminds me of using mi/h for miles per hour. While mi/h may be used by some technical publications, the vast majority of people would better recognize mph. As a matter of being consistent throughout the encyclopedia, we should do our best to use one abbreviation—the most common one. In this case psi is the most common so we should use it. However, it also reminds me of the automotive industry (the one I work in) using cid for cubic inches displaced and the medical fields using cc for cubic centimeters. Question being: Do we want to be consistent throughout the entire encyclopedia; even if that means that certain industry articles (locomotive, auto, medical, etc) would use abbreviations different than what is normally encountered in that industry (psi for in/sq in; cu in for cid; cm³ for cc)? Or do we want to make exceptions? —MJCdetroit 13:59, 1 April 2008 (UTC)

It is not possible to convert from a unit of pressure to kg/cm, because kg/cm is a unit of mass per unit area, not pressure. I advise against making such a template. Thunderbird2 (talk) 16:22, 1 April 2008 (UTC)

I agree with Thunderbird2. The one and only correct unit of pressure in the International System of Units is the pascal. No template should be created to convert to any other metric pressure unit; all the others are obsolete and depricated. --Gerry Ashton (talk) 16:34, 1 April 2008 (UTC)

Just because you don't like the units, it is no reason to make untrue statements. psi or lb/in is pounds per square inch, strictly pounds force per square inch (sometimes written as lbf/in); and it is a pressure measurment. kg/cm is strictly kilograms force per square centimetre, which is also a unit of pressure. 1 lb/in is 0.07 kg/cm.Pyrotec (talk) 17:06, 1 April 2008 (UTC)

As Pyrotec has pointed out, both are valid units of pressure. As far as I'm aware, 1 kg/cm is equal to 1 technical atmosphere (at). Although the Pascal is the modern unit of measurement that does not invalidate the kg/cm as a historical unit of measurement. All I'm asking for is a comparable, easy to understand conversion. Mjroots (talk) 18:01, 1 April 2008 (UTC)

It's just not something that should be converted on a regular basis; if a reference unit is non-SI, we convert to SI; if it's SI but there's a reason to express it in some non-SI unit, we might give that as well SamBC(talk) 18:24, 1 April 2008 (UTC)

I think that some editors that have entered the discussion on this subject need to go back to school. Pressure is the force applied over a unit of area. This is where people forget the difference between force and weight. A kilogram is a unit of mass, which is a fundamentally different quantity to weight, which is actually a force. As an example, 1 kilogram does not weigh the same on the moon as is does on the earth, but the mass (1 kg) is the same. To some extent the kg/cm unit is not truly a unit of pressure, as a kilogram is not a unit of force! So it cannot be an SI unit of pressure. Olana North (talk) 18:51, 1 April 2008 (UTC)

Also being pendant, can I suggest that you read what I and Mjroots (and others) said above. For pressure the units have to be strictly pounds force per square inch, written as lbf/in and kilogram force per square centimetre, written as kgf/cm. We are not intending to run steam engines on the moon, so on Earth the units are measures of pressure; and I'm not aware of any claims that they are an SI unit. kg/cm is apparently a common unit used in Europe for recording boiler pressures; and lb/in has been used in the UK for a very long time as a unit of pressure. Even if we accept unconditionally that lb/in and kg/cm are not units of force it is still possible to convert from one set of units to the other set; since they have the same dimensions of weight per unit area. Please explain, as you have apparently been to school, why two authors above consider lb/in to be a (Non-SI) unit of force whereas they regard kg/cm as not. Being pendant, it is lbf and kgf per unit area. It is also possible to convert from lbf/in to kgf/cm since they have the same dimensions of weight per unit area. They are being used as gauge pressures not absolute pressures; and we are not intending to compare boiler pressures on different planets, or in space.Pyrotec (talk) 19:38, 1 April 2008 (UTC)

The psi is a unit of pressure that is defined unambiguously as one pound-force per square inch. As a unit of pressure it can be converted to another unit of pressure, like the pascal. You will find a list of valid pressure conversions (which does not include kg/cm) in the psi article. Thunderbird2 (talk) 21:24, 1 April 2008 (UTC)

Actually, it is there, under a different name, the Technical atmosphere. So, all I'm asking for is an alternative way to display an existing conversion. Mjroots (talk) 22:16, 1 April 2008 (UTC)

In that case could you rephrase the question so that we can understand the requirement more clearly? Are you saying you need a conversion from psi to technical atmospheres? Thunderbird2 (talk) 11:36, 2 April 2008 (UTC)

(outdent)Rephrase As 1 kg/cm = 1 Technical Atmosphere, what I need is a different way of displaying Technical Atmospheres as kg/cm, to enable an easy comparison with lb/in, with the two units displayed in a similar format.

The trouble with that is that the at is a unit of pressure, whereas kg/cm^2 is not, so you can't convert between them the way you'd like to. Do you have an example article in mind where you see the need for such a conversion? Thunderbird2 (talk) 13:50, 2 April 2008 (UTC)

Well, there's the Chemin de Fer du Finistère article for a start. There are plenty of articles on UK steam locomotives that would benefit from conversion in the other direction.Mjroots (talk) 17:37, 2 April 2008 (UTC)

I see. That helps illustrate the problem. If it were me doing the editing the first thing I would do is change all those kg/cm to kgf/cm. Is that what is meant? (For the reasons pointed out by Olana North, kg/cm is not correct). Regarding unit conversions I would say the most important one would be to pascals. Do I understand correctly you wish to convert also to psi? Thunderbird2 (talk) 18:51, 2 April 2008 (UTC)

I'm just trying to stick to what is common usage. i.e lb/in and kg/cm. This is the usual way of writing boiler pressures, even if it is not strictly accurate. I have no problem with an additional conversion into HPa being added it that is the correct modern unit to use. We convert imperial to metric and metric to imperial throughout wikipedia. Again, I've no problem with that. I understand feet and inches, miles and chains etc. Others understand metres and kilometres. Personally, I would prefer not to have psi displayed. One never sees boiler pressures quoted as 120 psi, it would be quoted as 120 lb/in or 120 lb/sq in. Mjroots (talk) 20:09, 2 April 2008 (UTC)

I'm afraid that takes us back to where we started. The kg/cm is not a unit of pressure. Thunderbird2 (talk) 22:41, 5 April 2008 (UTC)

What is written - kg/cm. What is meant - kgf/cm! Looks like I'll just have to enter a manual conversion. Mjroots (talk) 06:48, 7 April 2008 (UTC)

Cubic feet

According to Cubic foot the following abbreviations are used.

• CCF for a hundred cubic feet
• MCF for a thousand cubic feet
• MMCF for a million cubic feet
• BCF for a thousand million (10) cubic feet
• TCF for a billion (10) cubic feet

No mention of abbreviations for such large units of volume is made on the the page. It could be useful to have some abbreviation for these units for use on WP but would we want abbreviations such as these? On the other hand, it might be best to stick with "cu ft" and use scientific notation. JЇѦρ 02:50, 2 April 2008 (UTC)

The "Cubic foot" article does not cite any reference for these abbreviations. I think they are too obscure to use in Misplaced Pages. While they might be used in certain industries, the deceptive similarity to metric prefixes make them undesireable. --Gerry Ashton (talk) 03:04, 2 April 2008 (UTC)

More or less my feelings about them. I wonder whether the MOS should expressedly ban these and/or ban the quasi-Roman numeral/"short scale" prefixes that form them. I don't want to see the likes on WP but on the other hand I don't recall ever having done. JЇѦρ 03:16, 2 April 2008 (UTC)

"... don't recall ever having done ..." but I didn't have to look too far. JЇѦρ 03:26, 2 April 2008 (UTC)

Actually put it down to a bad memory. I went looking for "mcf" and found one that I'd been meaning to kill. I found a couple more. JЇѦρ 04:27, 2 April 2008 (UTC)

I've found nine hits for "MMCF" three of which were mentions of the abbreviation itself. The other six are listed below.

• North American natural gas crisis 2 Apr 08 version
• Natural gas storage 2 Apr 08 version
• EOG Resources 2 Apr 08 version
• Leor Energy 2 Apr 08 version
• Qatar Petroleum 2 Apr 08 version
• Helium 2 Apr 08 version

It's time to fix this. JЇѦρ 05:10, 2 April 2008 (UTC)

Given that most usages of cubic foot will be either US based or historical, it seems sensible to use the short scale billion and trillion vice the long scale thousand million and billion in explaining the prefixes B and T (if the initialisms are retained.) Certainly I would like to see clear disambiguation to the real-world metric units that define them (per the US NIST).LeadSongDog (talk) 05:33, 2 April 2008 (UTC)

I reserve the right to stick stubbornly to logic, tradition and dialect thus shunning this short scale nonsense ... on talk pages. Yeah, you're right, it is sensible. The question is whether these prefixes should be allowed on WP at all (apart from in articles which describe the abbreviations themselves). JЇѦρ 06:32, 2 April 2008 (UTC)

I wouldn't object to their use, especially if they were the source units. However, they'd definitely have to be wiki-linked back to the cubic foot article (which needs references for these abbreviations) and we'd have to make some note of them in the MOSNUM. I've only seen CCF used (on water and gas bills) in the past. If they were not the source units it would probably be better to use "cu ft" in scientific notation. —MJCdetroit 14:04, 2 April 2008 (UTC)

I support the general tone of this discussion. I am sure that most, if not all, instances of those obscure and esoteric abbreviations can be replaced with something that is more widely accessible. Lightmouse (talk)

Decades fix rationale

Sometime in the intervening long while since I looked at it, someone added an "okay" to abbreviate decades as long as the century was obvious. This is clearly untenable, because we (people who write and speak, I mean) simply don't do this outside of our own immediate past and future (with exceptions, like "Gay '90s" or "'49ers", that have become stock phrases and even re-used for other purposes like sports teams). When's the last time you saw something like "In 1075 BC King Grognar was ousted from his throne by his brother, but by the '60s had regained his kingdom with the help of the neighboring Fnord Empire"? I can't imagine ever seeing that in a scholarly or even vaguely serious work. Furthermore, the text as of a few hours ago ignored the fact that we use abbreviated decades most often, most pointedly, to refer to social periods that roughly coincide with decades, and with such consistency that they can become (sourceable) buzzwords or even signifiers for everything about society at a vaguely-defined range of time, and that this really isn't related in any way to identifiability of the century (see previous 2 examples). When I say "I grew up in the '80s" that conveys an enormous amount of information about me and my probable world-view. If I say "that model of our product was discontinued in the '80s", referring to a literal decade, this (lazy and unencyclopedic) usage conveys no such additional latent information. The usages are radically different, and the current (as of this writing) re-draft solves these problem. The redraft clearly also reflects consensus current practice, as it is a very regular AWB/bot or gnome edit to convert things like "the next phase of her career began in the early '40s" to "...1940s" (as far as I know I have never been reverted, ever, on such a correction), but articles about counterculture, civil rights, etc., can and do use "the '60s" when appropriate because it has nothing to do with the literal span of 1960 to 1969, but the societal changes that began happening in the mid-1960s and carried through to the early 1970s. No one would go to the article on the 1890s and change the phrase "popularly called the 'Gay '90s'" to read "'...Gay 1890s'". Anyway, I don't think anyone would revert me on this, but I like to provide rationales for major changes, especially here. — SMcCandlish ‹(-¿-)› 02:55, 5 April 2008 (UTC)

We might want to add a clarification along the lines of "Decades should not be abbreviated in this manner even if they can be unless there is some connection between the usually-abbreviated social period and what is being discussed in the sentence (She grew up in the 1960s, and moved to Boston in 1971. Growing up in the '60s, her attitude about civil rights differed significantly from that of her parents.)" Maybe someone can come up with shorter examples that get the point across as clearly. The lead sentence could probably be tightened too. Season 3 of Battlestar Galactica is about to start so I'm losing focus... Anyway, I think the clarification is important; I really have seen articles consistently abbreviating "'60s" but not other decades, because someone is not quite realizing that every reference to the "special" time period is not a reference to what was defining about the period and its societal goings-on. There's a world of difference between a '60s rock band in San Francisco and a 1960s classical quintet (even in S.F.!), or a '60s civil rights activist in Chicago and a 1960s accountant in the same city (or a 1960s activist for better funding of Chicago elementary schools). The distinction is important. I'll see if I can think of a way to stick the idea in there in just a few words, but may need help. — SMcCandlish ‹(-¿-)› 03:18, 5 April 2008 (UTC)

After a dozen or so attempts, I think I finally got it. I managed to compress (I think) every single idea above into a passage that's only slightly longer than when I raised the "meaningful connection" issue above, and also took the time to tighten up, clarify, flow-improve and bulletize. I think it is quite clear and readable now, and hints at all of the guidance that it needs to. Yes/no? — SMcCandlish ‹(-¿-)› 03:54, 5 April 2008 (UTC)

Binary prefixes redux

This is a reboot. MOS* editors are collectively very tired of the overblown invective in this argument "series"; consider it "canceled". Think of this as getting to do ONE wrap-up episode (or even a Serenity-style feature film, as it were). But please keep your positions grounded in WP policy, MOS, logic and civility bounds. We all realize this is an important issue for many participants, but endless fighting serves no purpose.

Informal mediation

Given that I effectively have no position on this issue whatsoever, other than (and do I not take this trivially) service to our readers, I volunteer to mediate this dispute, in all honesty and fairness, with the caveat that I have a life and cannot respond in realtime. Given that this dispute has gone on for years, and that that I have successfully mediated WP disputes in the past, I don't see that as a real issue. Step up. — SMcCandlish ‹(-¿-)› 12:27, 6 April 2008 (UTC)

And yes, I am being way WP:BOLD in archiving the "debate" (read: flamewar), yet quite short of WP:IAR.

I can't remember and don't care who said what, but the notion that dispute resolution has to go through some kind of official channels is incorrect. There are all sorts of mediation venues leading up to the official ones. Consider me the first line in this forum. The Mediation Cabal is the next step, and they aren't "official" either. If I fail, call in Kim Bruning, who is probably even more suited to the task, given that he mediated trans-continentally with me and via Skype for several hours over WP:ATT issues back in the day, at a point where it was really needed.

Anyway, youse guys need to STOP. Take a break of a day or two away from this, agree on a time to resume and be willing to agree on willingness to develop a compromise position.

PS: What drove me to this to bold intervention is that your (plural) arguments were getting so long that you were crashing my browser, I kid you not.

You are already an involved editor and therefore not suitable to mediate. Fnagaton 12:31, 6 April 2008 (UTC)

Fnagaton, I honestly do not care at all how this debate plays out. I care about things like whether terminal punctuation goes inside or outside of quotation marks. And I care about end-user (i.e. non-editor encyclopedia reader) experience. The rest is "noise" to me. I have both criticized and agreed with you in the past; I think neither situation is relevant to my ability to mediate here. As far as I can recall, my stance on the position at hand is that the current wording a) reflects a reasonably neutral wording and is WP:POLICY consistent; and b) can't be deleted without a strong show of consensus. If you think this disqualifies me from mediation, feel free to say so. — SMcCandlish ‹(-¿-)› 12:59, 6 April 2008 (UTC)

In the past I have witnessed SMcCandlish showing scrupulous fairness to other editors, whether or not he agreed with their views. I welcome his offer to help. Thunderbird2 (talk) 12:41, 6 April 2008 (UTC)

But that doesn't change the fact that he is an involved editor and is therefore not suitable to mediate on this issue. Fnagaton 12:45, 6 April 2008 (UTC)

I am involved, yes, but only (so far as recall) in advancing the ideas of reader usability and WP policy adherence. I have no position to advance other than consensus really has to change, in a specific direction, in order to change. I offer (again not in realtime, but checking in often) to informally mediate in this particular dispute, because I honestly couldn't care less about what unit symbols are preferred as long as the readers are served adequately, and I have some WP mediation experience. I don't think anyone else here can say the same. I'm a first-line chance at resolution. Next is the MC, after that formal mediation. Let's not "go there". It's tiresome (been there...). — SMcCandlish ‹(-¿-)› 12:59, 6 April 2008 (UTC)

Give me a try. When I go into mediator mode that's all I do; my own opinions are shunted aside. I've done this pretty effectively. Ask WP:SNOOKER if there are any doubts. — SMcCandlish ‹(-¿-)› 13:22, 6 April 2008 (UTC)

I would certainly recuse myself and refer this to a higher-up form of mediation if my neutrality were to be questioned during mediation.

Disclaimers: I feel neither positive nor negative toward units like Mib. They make sense to me, but their lack of public adoption within my culture gives me pause. I feel the same way about kilograms. I.e., I do not oppose the metric system in any way, but recognize that it does not make sense to some people and needs conversion. If this is seen as a radical position, then I may not be the appropriate moderator. — SMcCandlish ‹(-¿-)› 13:38, 6 April 2008 (UTC)

I am slightly disquieted by this form of mediation, but I am prepared to go along with it based on the following factors; if I'm wrong about them, then I guess I'm not prepared to do so, probably.

1. There's no commitment to "abide by" the conclusion of the moderator, as that isn't what moderation is about
2. If there's a view (of more than one or two editors) that SMcCandlish has become biased, recusal will follow.
3. There won't be an unhealthy fixation with any previous behaviour or proposals or polls, only an honest and civil attempt to move forward.

I think those will be necessary for any fruitful discussion. SamBC(talk) 14:24, 6 April 2008 (UTC)

Precisely. The only point of mediation like this is to get people to listen to each other. As far as I know, the only binding mediation of any kind on WP is the ArbCom, and that's like going to court. Very much like going to court. Ick. I have fortunately never been involved in any way on any side of an ArbCom fight, and hope never to be. — SMcCandlish ‹(-¿-)› 00:55, 7 April 2008 (UTC)

• Just my two cents. SMcCandlish: I think what you are doing here (archiving, organizing, fresh start) is a good thing. I can also see that you have (wisely or fortunately) stayed out of the issue on binary prefixes. I would say that if you can not get Fnagaton to agree to mediation by you, that pretty much settles the issue that it will have to be someone else. I am heading into an FDA animal study in a bit over a week and will have to have very limited involvement from hereon. Fnagaton: I’ve read SMcCandlish’s writings above as to his values and method of operation and it is unclear to me why you think he is unsuitable to help bring peace and organization to all of this. I don’t think he is proposing binding arbitration—just mediation (what he is already sort of doing here). I see that he professes to have a deep interest in the reader’s experience on Misplaced Pages. What’s wrong with his help? Greg L (my talk) 17:53, 6 April 2008 (UTC)

• P.S.: I also believe that the “{{disputed}}” tag preceding the current policy on binary prefixes is insuficient. Current policy was improperly rammed through without a proper consensus (see Archive 22). And there clearly isn’t a current consensus that it should be retained—far from it. There exists no rightful argument that the current policy is now sort of “grandfathered in” and enjoys the protection of a properly framed consensus to overturn it—not when it was rammed through the way it was. I think the proper thing to do is make MOS silent on the issue of binary prefixes, other than a simple statement that a new policy is being worked on. Now that’s a fresh start. Greg L (my talk) 18:09, 6 April 2008 (UTC)
  • Greg, following on from what you say I'll be wiling to go along with SMcCandlish doing mediation and see how it goes. Fnagaton 18:17, 6 April 2008 (UTC)

• I think SMcCandlish has the right idea here, and I hope with his help we can find some solutions. Seraphimblade 19:10, 6 April 2008 (UTC)

• Very well. Lead on, SMcCandlish. Fnagaton: As I stated above, I will be relatively inactive here for a while. When you wrote “…and see how it goes”, I ask that your litmus test not be whether or not you are getting everything you want; only that progress is being made. Your end objective is the same as mine. The current policy produced only endless discord among the editors, even well-read readers now encounter terminology on Misplaced Pages they’ve never seen before, and—worst of all—terminology like “256 MB” and “2 GB” have different meanings in different Misplaced Pages articles. We differ possibly only in the manner in which we might pursue our end goal. SMcCandlish can not possibly make any progress without buy-in from you. I ask that you afford him the greatest degree of “assumption of good faith,” and that you make his job as easy as possible. Greg L (my talk) 20:06, 6 April 2008 (UTC)

“Terminology like “256 MB” and “2 GB” have different meanings in different Misplaced Pages articles” – whatever the outcome of this discussion, this will remain, unless we adopted decimal-only meaning for SI prefixes and something else for binary. Heck, if Fnagaton gets his way they’ll even mean different things in one article. You really can’t have all at once, familiarity, readability and (inline) disambiguity.

Btw., I have a (currently busy) real life, too, so I’ll stay out of this from now on. I’ve said all there is to say at least once. I hope the best, fear the worst. — Christoph Päper 21:08, 6 April 2008 (UTC)

Issue summary discussion

A summary for this issue is:

There are two definitions by different standards organisations, these definitions are for the prefixes used in computing where sizes can either use decimal or binary powers of two numbers. About ten years ago some standards bodies (for example IEC/IEEE) proposed that new prefixes are used, these would be KiB/MiB/GiB etc and kibibyte/mebibyte/gibibyte etc. These new "IEC prefixes" have very limited use in the real world sources we use for articles, this is a fact and is not disputed as can be seen in the straw polls you archived.

The common use of the terms KB/MB/GB etc and kilobyte/megabyte/gigabyte etc can represent different values depending on their context. This use is defined by the JEDEC standards body and the JEDEC specifically deal with standards relating to computer memory. These older common use prefixes are still widely used today by most computing literature, manufacturers and even the IEEE use these terms in their publications. The IEEE also have a standard IEEE 100 and in this standard these common use prefixes are defined with both values. These are also facts that are not disputed. Fnagaton 14:41, 6 April 2008 (UTC)

The problem starts when some editors start to insert references to IEC prefixes into articles where the sources relevant to an article do not use IEC prefixes. Common reasons given for such changes are:

1) Just because I prefer IEC prefixes.

2) IEC prefixes are defined by the standards bodies therefore they should be used.

3) Readers could be confused about the number of bytes so we must disambiguate.

Refuting those arguments:

1) Individual preferred style is not a valid reason to promote one particular style over another. The overriding concern for editors writing Misplaced Pages articles is to be unbiased and to reflect the use of prefixes found in sources relevant to the article. Putting it another way, consistency with relevant reliable sources is more important than individual style preference.

2) Misplaced Pages wisely follows the example of the real world and ignoring the standards organisations when needed, see the BIPM issue.. For example Encyclopedias like Britannica do not use IEC prefixes in their articles related to computers. (Go to http://www.britannica.com/ and search for kibibyte, mebibyte or gibibyte, the search finds no such terms in the encyclopedia.)

3) a) Disambiguation is a valid method but disambiguation should also be free from personal preference and free from promoting one particular style over another.

3) b) Disambiguation should also use terms that help the reader to understand and because the IEC prefixes are virtually unknown this does not significantly help the reader. Also the problem arises that decimal numbers cannot be accurately expressed using binary powers of two is used. For example a hard drive of 100GB, which might actually be 100,000,000,000 bytes, expressed as some multiple of a power of two is 93.1322574615478515625×2 bytes. Of course for brevity this needs to be shortened to be 93.1×2 which then results in 99965363814.4 bytes this leaves an accuracy difference of 34636185.6 bytes. The reader is left with the impression that either this difference doesn't matter or that fractional bytes can exist in computing hardware and both are not true in computing articles.

3) c) Some editors will try to claim that actually the exact number of bytes doesn't matter and what matters instead is that the difference between decimal and binary prefixes is highlighted, this is fine but it is not true that the best way to accomplish this is to use the virtually unused IEC prefixes. That said, if the IEC prefixes were widely used and understood then of course it would serve the interests of the reader to disambiguate with them, however they are not widely used or understood so it does not serve the interests of the reader to use them when better methods (3d below) already exist. The claim is then sometimes made that IEC prefixes can be wikilinked, but again by introducing virtually unused terminology does not help to explain to the reader why this change was made and gives the false impression that MB can be equated with MiB. (Just look at the disagree comments for and .

3) d) What would help the reader, i.e. be better for the reader, is a short footnote explaining that there exist decimal and binary systems and giving links to articles that explain the issue much more fully without needing to promote IEC prefixes in the article itself, for example linking to Binary prefix. The fair and balanced solution is therefore to use some other form of precisely disambiguating decimal or powers of two numbers that doesn't push/promote any prefix style. Being fair, balanced and unbiased is something that should be true for Misplaced Pages articles. So this means adopting a system like "256 KB (256×2bytes)".

3) e) Some people say that removing IEC prefixes from the guideline unfair or unbalanced deprecation of IEC prefixes, this is fallacious because the definition of deprecation is "to express earnest disapproval of". Removing advocation of IEC prefixes does not specifically express earnest disapproval of only IEC prefixes. The argument is therefore fallacious because in the current text specifically mentioning IEC prefixes is to advocate IEC prefixes and that is pushing a biased POV. Putting it another way, specifically mentioning IEC prefixes is actually unfair and unbalanced advocating of IEC prefixes. Pushing a biased POV towards either of the prefix style should be unacceptable in the guideline, especially considering that we should have the reader's best interests at heart. So, removing a push for a biased POV from the guideline is not deprecation, it is actually removing bias.

Given that supporting one style of prefixes over another is not welcomed, especially when that style is obviously in the minority. Given that some people also don't like it when a particular prefix style is deprecated, note this means specifically saying "do not use these terms" and does not mean removing advocation of such terms. Given that MOSNUM also has the wise guideline about using prefixes/units employed in the current scientific literature. The only logical and fair conclusion is to remove reference to any hint of support or deprecation for any of the standards organisation styles at all and make it clear that the units must defer to the sources for the article which will then logically defer to what is the real world consensus. In doing so all the text about "no consensus for using IEC prefixes" is removed as is the text explaining the history of the prefixes and as is the text that says "Use of IEC prefixes is also acceptable for disambiguation". This is because the respective articles (Binary prefixes etc) already contain the history of these prefixes and already explain why these differences between decimal and powers of two systems happen. Also gone would be the text about not changing from one style to the other and keeping with the original style, this is important because it allows articles to naturally change over time to reflect what is the consensus in the real world if the sources for that article considerably change from using KB to KiB for example. I don't see that happening any time soon but this is a compromise to those that feel it just might. This would also try to remove what is seen as a Misplaced Pages guideline pushing any one standard over another and to remove any bias coming from Misplaced Pages. The guideline would then becomes a series of examples of what to do for disambiguation, wikilinking and footnotes.

Now we get onto the topic of the "third hybrid proposal" text.. As can be seen from the support comments these mostly follow a similar vein of using technical reasoned argument against using IEC prefixes based on the Misplaced Pages principle that consistency with reliable sources is important. On the oppose comments we have, 1) "votes are evil", 2) "the proposal is messy" along with personal style, 3) we need to discuss, 4) a claim that it deprecates which is not true and a claim that it doesn't address "ambiguity" when actually the proposal specifically addresses this, 5) another fallacious deprecation argument, 6) another fallacious "out right ban" and misrepresentation about the motives of myself and Greg, 7) fallacious deprecation, 8) the "standard body defines this" argument which is refuted above, 9) point of view, 10) fallacious argument claiming there has been no valid argument and a comment about "ILIKEIT votes".

Looking at the oppose votes it is clear to me that most of them use falacious reasons that are already refuted and can be disregarded when considering this issue on aspects that are relevant to putting the interests of the reader first within the scope of existing Misplaced Pages guidelines. Fnagaton 14:41, 6 April 2008 (UTC)

I believe Fnagaton misstates the facts as follows:

1. "JEDEC is the leading developer of standards for the solid-state industry" and as such has no dealings with computer memory - semiconductor chips and modules, yes, but computer memory no!
2. Historically mega (M) and giga (G) were well established as 1,000,000 and 1,000,000,000 long before they acquired a binary meaning. Furthermore, MB (Mbyte or megabyte) and GB (Gbyte or gigabyte) were also well established as 1,000,000 bytes and 1,000,000,000 bytes long before they acquired a binary meaning.

It is particularly disturbing that some anonymous editor reverted this comment with the justification, "misrepresentation." The above statements are factual. The solid state industry is a supplier to the computer industry. The MB history is well documented in the time line. You may disagree with my interpretation of these facts, you may even call it POV, but it is improper to supress this, especially on a talk page. Tom94022 (talk) 23:08, 6 April 2008 (UTC)

Fnagaton is completely correct. The JEDEC does set standards for computer memory and it is the industry leader. Your statement is incorrect. DavidPaulHamilton (talk) 23:51, 6 April 2008 (UTC)

JEDEC memory standards proves they set computer memory standards. I propose Tom's incorrect statement and these following comments are moved out of this section to keep the thread clear of rubbish.DavidPaulHamilton (talk) 00:30, 7 April 2008 (UTC)

Except that flash RAM devices, which certainly come under the heading of "computer memory" and "semiconductor devices," are quoted in decimal MB or GB (as are hard drives). JEDEC member companies' practice therefore seem to be internally inconsistent. IMO this means we should adopt a more useful and internally-consistent standard. Jeh (talk) 03:02, 7 April 2008 (UTC)

That is inaccurate. The chips used for flash memory are defined in their technical data sheets to use binary MB. We aim higher by not using unknown confusing IEC prefixes.DavidPaulHamilton (talk) 06:44, 7 April 2008 (UTC)

I guess I wasn't clear enough. I said "flash RAM devices", meaning the likes of CompactFlash, SecureDigital, etc., devices. How the internal chips are spec'd means notbing to the buyer. What is relevant here is that when one buys a "4 GB" flash device, it will be a bit more than 4×10... but most OSs then display that capacity by using a power of two divisor and an SI-style prefix, so one sees a number like "3.72 GB". If that doesn't demonstrate that use of a single prefix with two different meanings is confusing, or why we must disambiguate these numbers in some way, I don't know what will. Jeh (talk) 07:26, 7 April 2008 (UTC)

You know as well as I do that when memory chips which are defined as binary powers of two by the JEDEC standards are repackaged into other offline storage devices they are are marketed as drive storage and therefore not "computer memory" as such. You might not know this but also when the powers of two memory chips are used in something like a USB stick some part of the memory can be used to store extra information not related to the storage of files, for example recovery software, ISO images of CDs so the device can initially appear as a CD device to install drivers, encryption key storage, etc. This still means my statement is correct because the computer memory part still follows the JEDEC standard. Tom94022 is also wrong because semiconductor chips are the same as computer memory (RAM) in the context of using the phrase with the JEDEC, as such the statement "JEDEC specifically deal with standards relating to computer memory" is completely accurate. Cites from manufacturers and technical sites that also show why you are wrong: "All Kingston memory is JEDEC compliant, an important specification used by leading semiconductor manufacturers. JEDEC sets the standards for semiconductor engineering and is well respected throughout the industry. " "JEDEC is a standards body for the global semiconductor industry. ... JEDEC sets the basic specifications to which all RAM must adhere at a minimum.". "JEDEC is famous for its computer memory (RAM) standards, for example, DDR SDRAM and DDR2 SDRAM. " If you need more links Google: "computer memory JEDEC". Or you could just look at the article JEDEC memory standards and JEDEC which says "JEDEC memory standards for computer memory (RAM)". It cannot get any clearer than that, really. Also, don't insert your comments half way inbetween my post, it makes things harder to read. Fnagaton 08:47, 7 April 2008 (UTC)

A hard disk drive industry standards group, IDEMA, has defined Gbyte as 1,000,194,048 bytes in order to avoid confusion in the reporting of capacity of ATA and SATA drives. With this definition all HDDs with the same labeled capacity (to several digits after the decimal point) will report the same number of 512 byte blocks. IDEMA is close to but not a decimal prefix definition. IDEMA is no more or no less an authority to the computer industry than JEDEC. I do not dispute that JEDEC sets standards for memory modules but I do dispute that in resolving this Wikepedia issue they have any more significance than IDEMA, or IEC or the HDD manufacturers or the DVD manufacturers. To that extent Fnagaton's summary, emphasizing JEDEC is his POV and needs clarification. Tom94022 (talk) 19:09, 8 April 2008 (UTC)

Mentioning IDEMA is a red herring since that is not relevant to and does not refute my statement that "the JEDEC specifically deal with standards relating to computer memory". The fact that the IEC prefixes are virtually unused by the real world shows that the IEC has to be given less weight when considering what scheme to use. To do anything else is illogical and is pushing a POV. Fnagaton 19:28, 8 April 2008 (UTC)

• Tom94022: It’s not complex. The manufacturers of USB flash drives are no different from anyone else in the transistorized computer memory market and follow the convention used by the rest of the computer industry. A “2 GB” flash drive has 2 × 2 bytes of memory inside. Because of that fact, they advertise using binary values to denote device capacity. However, the memory inside the USB drive is not made available to the computer like ordinary RAM; the drives are treated like hard drives and the internal memory must be formatted. To ensure the drives can be recognized by both Macs and Windows machines, manufacturers usually format using FAT32. To quote Edge Tech Corporation: “ The usable size of the DiskGO™ should be within about 10-12% of the device's stated size.” The actual thumb drive memory available to your computer after formatting will be displayed to you per the convention used by your operating system. Your computer likely uses the same convention my Mac does, which right now displays this regarding my 512 MB USB flash drive: “Capacity: 483.5 MB (506,970,112 Bytes)”. Greg L (my talk) 21:03, 8 April 2008 (UTC)

For the record, I wrote to JEDEC for a clarification on JESD100, and they state that it is not at all a requirement, but just a list of definitions. They say that these definitions are only included to document common usage, and to document the fact that they are deprecated. "The standard meanings of the terms kilo, mega, giga, etc are defined in the SI system of measurement by international agreement to be powers of 10".

They do say that one could hypothetically self-impose an obligation to these definitions, by saying "in this document, we use the definitions as per JESD100", but 1. this would be entirely voluntary, and is not necessary for compliance with JEDEC and 2. the manufacturer could use either the traditional prefixes or the IEC prefixes in this situation, since both are defined in the document. — Omegatron (talk) 00:18, 10 April 2008 (UTC)

For the record I wrote to the JEDEC as well and your statement is incorrect. The definitions they show in their standard are not deprecated as you claim. Also you misrepresent the facts because to claim compliance with the JEDEC standards KB/MB/GB have to be used in powers of two sizes. The fact is the JEDEC standard says "No claims to be in conformance with this standard may be made unless all requirements stated in the standard are met.". That disproves what you just claimed. IEC prefixes are not defined as part of the standard either, they are mentioned as a footnote. Fnagaton 09:12, 10 April 2008 (UTC)

I will also bring up your recent edits here including this one, since you chose to to make a few chnages to binary prefix related articles and people here need to be made aware of the changes you have tried to make. This is because the text reads as "JEDEC Solid State Technology Association, the semiconductor engineering standardization body of the Electronic Industries Alliance (EIA) in Standard 100B.01 continues to include definitions in the binary sense K, M and G as prefixes to units of semiconductor memory, though these definitions are “only included to reflect common usage” and are deprecated. All standards published by JEDEC are still using the common usage, including end-user packaging recommendations for memory chips.". This bit highlighted in bold is completely wrong, the JEDEC have not deprecated K/M/G at all. Your edits are not representative of the facts related to this subject. Fnagaton 15:08, 10 April 2008 (UTC)

As you know, all JEDEC memory standards use the terms MB and Mb for megabyte and megabit. Here is a JEDEC standard published in January 2008. "PC3-6400/PC3-8500/PC3-10600/PC3-12800 DDR3 Unbuffered SO-DIMM Reference Design Specification" Look on page 20. The memory modules in your computer are based on JEDEC standards like this one.-- SWTPC6800 (talk) 01:27, 10 April 2008 (UTC)

Yes SWTPC6800 the JEDEC define and use the prefixer so it is incorrect for anyone to say they are deprecated.DavidPaulHamilton (talk) 21:11, 10 April 2008 (UTC)

There is no disagreement that MB stands for megabyte. Both, IEC and JEDEC define MB as short for megabyte. --217.87.124.227 (talk) 21:33, 10 April 2008 (UTC)

Only consensus opinion should appear on MOSNUM

• All: It is wholly inappropriate for a policy that was improperly adopted in the first place (without a proper consensus) to proudly masquerade on MOSNUM as a legitimate guideline of any sort (see Archive 22). The proper thing to do is for MOSNUM to remain silent on the issue until a consensus of any sort is arrived at. No matter how small the point of agreement is on the issue of binary prefixes, anything that appears on MOSNUM should be arrived at via a Misplaced Pages-style consensus. I have made it so (∆ here) and I ask all other editors, if they feel strongly about MOSNUM’s silence on the issue, to join in here and find some common ground with each other. Greg L (my talk) 23:03, 6 April 2008 (UTC)

Greg_L, I feel that it is only according to your and a few others' assertion that the current wording was not properly adopted. Your standard for "consensus" seems to be a unanimous vote, but that is not at all a requirement under WP:CON. Since you have raised the question, this is one of the points I listed (now archived) upon which I would like to see a mediator's decision -- did the current wording represent, at one time, a consensus? In the meantime, there is certainly no consensus that previous consensus was NOT achieved, therefore YOUR recent changes to WP:MOSNUM are out of bounds by your own standards -- and IMO, are bordering on disruptive behavior. Disputes on talk pages should not be brought to the subject main page, particularly pages concerning WP policy and guidelines. Jeh (talk) 00:21, 7 April 2008 (UTC)

• The solution according to the xkcd standards committee Gimmetrow 00:32, 7 April 2008 (UTC)

• I wholeheartedly agree with the xkcd standards committee’s views on the binary prefixes. Thanks Gimmetrow. I’ll let SMcCandlish deal with 1) whether 20:7 was ever a proper “consensus” as the term is typically understood, and 2) whether it is wise/warranted to have such a disputed and poorly supported policy in MOSNUM (13:10 to replace the current guideline lock stock & barrel with one that would prohibit their routine use and deprecate many existing uses) while we’re trying to agree on anything here; I think its existence hinders progress here. But I’ll leave it alone for the moment. Greg L (my talk) 01:39, 7 April 2008 (UTC)

• Greg, please read WP:CON. The way I read it, consensus on WP is arrived at when the "edit loop" ends. It seems to me that the edit loop, and even the discussions on the talk page, ceased for many months after the current wording (or something very very close to it) was established. Therefore (again, in my opinion) it does constitute consensus -- or did at one time, as of course, consensus can change. And maybe it has. But that possibility is not justification for removing long-standing text from an existing article. Jeh (talk) 01:50, 7 April 2008 (UTC)

• Regarding the consensus about the 20:7 vote: I'll quote Omegatron "There was no consensus in Archive 22...". I remember Bladestorm mentioning that he was being told there was consensus for the proposed guideline text and that being given as the reason to only use IEC prefixes, which was against the spirit of the guideline because it was only recommended and not mandatory. Just look at the changes made by Sarenne before she was banned, she used the old guideline text as justification for only using IEC prefixes and forcing them into hundreds of articles. So yes, people in the past have misrepresented the consensus issue with the guideline text that was being used and misrepresenting that to force using IEC prefixes. Fnagaton 16:16, 7 April 2008 (UTC)

You've got it half right:

1. There was no consensus to use IEC prefixes throughout the project
2. There was no guideline that said to use IEC prefixes throughout the project

There was a strong majority in favor of them, so the guideline said they were recommended in cases of dispute, but to my knowledge it has never required their use, since even a strong majority wanting to mandate their use does not equal a consensus per Misplaced Pages policy. — Omegatron (talk) 01:16, 10 April 2008 (UTC)

Goals

Okay, so I would love it if each interested party would in a RfC or XfD style bullet-comment briefly (1-4 sentences?) express what their personal goals are with regard to this debate and its outcome. I think this would help us all understand each others' positions better. Like, is it important to you that both styles be usable, but always be given a conversion for max. reader understanding? Is it crucial that the KiB-style units be promoted and the KB ones be deprecated, for standards reasons? Or the KiB ones be avoided because their general-public buy-in is low? Or whatever. Without getting into why the other side(s) are "wrong". I think we can probably all agree that the meta-goal is of course consensus, and that further one is surely an increase in mutual editor respect, leading to peace and calm and all 'at. I have to go run a pool tournament right now, but will read the summary discussion issues above as soon as I get back. PS: I'll go first; I'm not a party, but I think you should all know where I come from on the topic. — SMcCandlish ‹(-¿-)› 01:07, 7 April 2008 (UTC)

• My preferred outcome here is that, whatever the resulting consensus is, the average reader will not be confused or mislead in any way. By nature I tend to lean towards preferring standardized ways of doing things mostly (I'm a fanatic about Web standards), but I don't in real life use the metric system at all (except where it has been forced on me, e.g. soda pop being available in liter but not quart bottles). This makes me either flexible or a hypocrite. :-) Secondarily, I want MOS to be consistent and guiding, and accepted by the community. — SMcCandlish ‹(-¿-)› 01:07, 7 April 2008 (UTC)

• Well, I guess I'll start here then. My main goal is to avoid confusion, and, as a formal reference work, to see the terms Misplaced Pages uses be unambiguous, technically correct, and clear. I believe that this can be best achieved by using the binary prefixes to represent binary values, as these values are clear and unambiguous, and to use decimal prefixes to represent only decimal values. These uses are clearly defined by standards bodies, so veriication of the terms' values is not problematic. However, the only way ambiguity can be avoided is for a clear practice to be adopted sitewide. Seraphimblade 08:09, 7 April 2008 (UTC)

• Rationale: The IEC prefixes are not clear to the average reader because they are virtually unknown. It is not the place of Misplaced Pages to advocate a style of prefix especially when it is unused by the vast majority of the computer industry. The vast majority of formal references works by manufacturers do not use IEC prefixes, the Encyclopedia Britannica doesn't even mention IEC prefixes, so Misplaced Pages should not promote their use either. Common use, real world consensus and the sources we use for articles defines what is correct for Misplaced Pages to use, not a standards organisation that proposed a standard which is very rarely used. Goals: My goals are those of the Misplaced Pages policies and guidelines. Consistency with relevant reliable sources used in an article. Unbiased articles that represent the real world consensus. Making the contents of articles clear to readers where needed. This can be accomplished without needing to push virtually unknown and unused IEC prefixes onto our readers. A good test is to look at what Misplaced Pages uses itself for representing powers of two sizes. As can be seen from this link to a search the sizes of the pages use KB. As can be seen from the history page for the Cat article it shows "16:29, 6 April 2008 Ramdrake (Talk | contribs) (88,610 bytes)" and this displays in the search results as "87 KB (13627 words)". Since 88,610/1024 = 86.533203125 = 87 KB (rounded up) it is therefore a fact that Misplaced Pages search uses KB in the powers of two sense and doesn't need to disambiguate using IEC prefixes. Fnagaton 09:29, 7 April 2008 (UTC)

• Misplaced Pages should use correct prefixes not wrong ones just because they are still in wide use. This is an encyclopdia that should focus on the truth and not on public opinion. Please also remember the confusion of somewhat inexperied users buying a 320GB harddisk and expecting to get 320 GiB but only receiving 320GB (312.5 GiB). To avoid confusion or reverts on articles with binary prefixes they probably should have a hidden notice on top of the article like "This article use Binary prefixes" and/or this info should go to a Notes section just above references.--Denniss (talk) 13:02, 7 April 2008 (UTC)

• My goal is to minimise ambiguity to the greatest extent possible without compromising the fundamental objective of an encyclopaedia as I see it, which is to provide informative and readable articles.

I see two main disambiguation approaches. These are a) quote exact number of bytes; b) use IEC prefixes. What I would like the guideline to do is spell out both approaches, and encourage the editors of individual articles to consider which of the two approaches works best for that particular article. I believe this flexibility is needed due to the wide variety of articles that we need to cater for. One size doesn't fit all.

Unfamiliar terms should be linked on first use.

Thunderbird2 (talk) 18:43, 7 April 2008 (UTC)

• I'm still working on how to phrase my goals, but I wanted to say that I can't help noticing that people are using this section to, yet again, voice their opinions rather than state their goals. This makes it seem worryingly like a number of editors' goals are to win the debate... SamBC(talk) 18:52, 7 April 2008 (UTC)

• Goals Produce a guideline that's in keeping with the spirit of wikipedia. Misplaced Pages is not the place to right great wrongs. We report the truth as found in reliable sources, neutrally and giving due weight to majority and minority positions. Position Regardless of what might be argued as "correct", we should use the units that our sources use - and that our readers understand - in the context of the article in question. If those units are ambiguous (I bought a hard drive in the '90s whose manufacturer defined 1MB as 1,000 KB, or 1,024,000 bytes) then we must make clear what the units mean - whether that is by wikilinking, footnoting, etc. I do not mind. The one thing I do not think I could agree to would be a guideline encouraging use of KiB etc in articles where the sources do not use those units. Sheffield Steel_stalk 18:59, 7 April 2008 (UTC)

• I agree with everything Fnagaton and Sheffield Steel wrote above, and which SWTPC6800, DavidPaulHamilton, and agr wrote below regarding goals. The Goal should be that Misplaced Pages always embraces the time-accepted objective of all technical writing: to communicate clearly, comfortably, and with minimal confusion to any given target readership (which can vary depending on the technical level and subject) using level-appropriate terminology and units of measure that the readership is accustomed to encountering on that subject.

  As that applies to this debate, wherever a unit of measure—such as kilobyte—has an ambiguous meaning, editors should not vary from widely adopted, familiar industry practices and should disambiguate where appropriate using terminology and techniques that are themselves familiar and well recognized by that readership. In short, Misplaced Pages should use terminology that 1) a typical, well-read reader who will be visiting that article already recognizes in order that they can quickly and easily learn more about the subject, and 2) a relatively novice readership should recognize in order to be properly primed to absorb what they will likely encounter elsewhere on the subject.

  An important component of achieving this objective is to have consistent practices across all of Misplaced Pages’s articles so a unit of measure has consistent meaning and connotation no matter which Misplaced Pages article a reader visits. Further, Misplaced Pages’s articles must be consistent with the way Misplaced Pages itself calculates file sizes (which currently eschews the IEC prefixes and observes the convention of 1024 bytes per “kilobyte”). To eventually achieve that end, editors should use only agreed-upon editing practices that afford the greatest possible courtesy and patience to all the volunteer editors who have labored on many of these articles and have helped make Misplaced Pages what it is.

  My stated goal could be achieved with this MOSNUM policy:

Units of measure: In any given article, editors should use the units of measure and methods of disambiguation commonly used in that discipline to communicate to a given readership.

Greg L (my talk) 20:27, 7 April 2008 (UTC)

• I have a decade of experience on standards committees and know that the successful standards are quickly adopted by industry and users. If the potential users of the new standard don't think the improvement outweighs the cost of change, the standard is ignored. My goal would be for Misplaced Pages to use the same terminology that the leaders of the computer industry use. Intel, Samsung, Apple, Microsoft, PC World, IEEE Spectrum and everybody else has not seen the benefit of switching to the IEC binary prefixes. The MOS states we should use the "units employed in the current scientific literature". After a decade, the IEC prefixes are virtually unused outside of a few standards groups. -- SWTPC6800 (talk) 20:41, 7 April 2008 (UTC)

• Unfamiliar terms like IEC prefixes should not be used when the sources do not use them.DavidPaulHamilton (talk) 14:02, 8 April 2008 (UTC)

• My goal is to do what is best for our readers. Misplaced Pages is written for a general audience. The one thing universally agreed upon in the polls above is that our audience is not familiar with the IEC prefixes. They have not been adopted by print encyclopedias, newspapers, trade magazines or the major computer and operating system vendors. And given the time that has passed since the IEC prefixes were introduced, this failure to adopt can be considered a rejection of their use in literature aimed at the general public. Misplaced Pages is a tertiary source. We should follow the practice other print publications, not attempt to lead them. There are other ways to resolve the ambiguities in industry use of the terms megabyte, etc., and we should use them to the extent we have a sourced basis for doing so. (Sourcing can be an issue, particularly when dealing with articles on computer history.) The spirit, if not the letter, of WP:SOAP, WP:NEO, and WP:V should apply here.--agr (talk) 14:35, 8 April 2008 (UTC)

• My primary goal at this point is to end this stupid debate. It's been going on for years now and generated a lot of incivility and wikidrama with no resolution whatsoever. Previously, my goals included minimizing confusion, eliminating ambiguity, and maximizing reliability of Misplaced Pages as a reference work. After several decades, the idiosyncratic redefinition of SI units are virtually unused outside of a few sub-fields of computing, are not used consistently even within those fields, and are virtually unknown to the average reader. Since Misplaced Pages is a general reference work spanning many fields, and not a computer science textbook, we should use the standardized units used in the real world. — Omegatron (talk) 01:28, 10 April 2008 (UTC)

  If you really think "this stupid debate" then you don't have to keep on writing here. I think it is unhelpful for you to state the debate is stupid. The international standard units for computer memory are those defined by the JEDEC and those are KB/MB/GB using powers of two. By the way, your three stated goals are better accomplished by not using IEC prefixes in the vast majority of cases, I've already shown why with my previous posts. Fnagaton 10:02, 10 April 2008 (UTC)

  It's stupid because it's gone on for three? years with no resolution and everyone repeating the same arguments over and over again: The best way to accomplish my stated goals would be to consistently use SI prefixes for decimal units and IEC prefixes for binary units. It's simple, unambiguous, standardized, and wouldn't confuse readers like the KB = 1024 convention does. — Omegatron (talk) 23:46, 10 April 2008 (UTC)

Search result methodology

FYI, search results are cached, so the page size reported there may not correspond to the current version of the page. Gimmetrow 16:12, 7 April 2008 (UTC)

I conducted multiple tests with lots of different articles to check. There just isn't space to include all of the tests carried out and the single example proves the point succinctly. Fnagaton 16:23, 7 April 2008 (UTC)

You do understand the search results *are cached* - that means 87 KB there may or may not have anything to do with the 6 April version. For instance, a search for my talk page currently lists it as 49 KB (7420) words, with last size in history as 49736 bytes, and it reports 48 KB when edited. This is just a FYI about your methodology. Gimmetrow 19:02, 7 April 2008 (UTC)

Yes I know. That is why I conducted lots of tests to make sure. The time and date of the "cached revision" is listed on the search page and I was careful to choose the exact revision in the article history corresponding to the exact time and date listed in the search results. The article I cited belongs to those search results that are updated quite often, i.e. the caching time is quite small. This means the 87 KB I cited is directly related to the size of the article history I cited. The conclusion is therefore the same, that is Misplaced Pages uses KB and kilobyte in the powers of two sense and doesn't use IEC prefixes in the example I gave. Fnagaton 10:51, 8 April 2008 (UTC)

Oh. I thought the date was just the date of last edit and wasn't connected to the search size. I've tested it to make sure, and you're right. Gimmetrow 04:02, 10 April 2008 (UTC)

• Well isn’t that an inconvenient truth?? Indeed, Fnagaton, Misplaced Pages’s itself follows the industry-wide practice where “KB” in the context of file size equals 1024 bytes. I’ve long been keeping careful track of certain article’s file sizes and have long known this obvious fact. Yet I’ve never made the logical connection between that reality and this debate. It’s sort of a ‘Well… Duh!’ point that should have been brought up here earlier. I’ve got a special test page to exercise the {{delimitnum}} magic word and the template by the same name here at User:Greg L/Delimitnum sandbox. It has been stable for quite some time and I’ve been keeping track of its size. It measures precisely 402,845 bytes in size. And what happens when you click the edit this page tab on it? Anyone want to venture a guess what Misplaced Pages itself says is the article’s size? Anyone?

  *(sound of crickets chirping)*

  Does it say it is “393 kibibytes” or “403 kilobytes”? No. It uses the convention which causes the least confusion among readers; the same convention used by the rest of the computer industry and general-interest computer magazines: “This page is 393 kilobytes long.”

  That’s also why this table showing the total HTML download burden of four, large Misplaced Pages articles on the nuclides uses “KB” in the conventional, 1024-byte manner: so Misplaced Pages doesn’t baffle the reader with absolutely schizophrenic behavior. Greg L (my talk) 17:28, 7 April 2008 (UTC)

That doesn't mean anything. The user interface itself has even been edit warred due to this dispute. The outcome of this guideline determines what happens to those system messages, not the other way around. — Omegatron (talk) 01:37, 10 April 2008 (UTC)

• The three stages of great ideas:

1. Ridicule the idea as preposterous.
2. Dismiss the idea as being obvious.
3. Claim that you thought of it in the first place.

I believe your post above is a variation of step #2 above; sort of “pay no attention to that man behind the curtain!” Greg L (my talk) 03:30, 10 April 2008 (UTC)

The long page warning does not need to be unambiguous. It doesn't matter if the page “393 kilobytes” or “403 kilobytes" long. "400 kilobytes" is good enough. Most people know that kilobyte is some kind of file size measurement. When someone is editing the article on Ima Hogg they don't need to learn about an obscure computer science measurement that is unused in the real world. -- SWTPC6800 (talk) 02:29, 10 April 2008 (UTC)

Questions to explore

Ambiguity and consistency, flexibility

The first question that comes to my mind out of the "Goals" discussion above is how to resolve the tension between the view that WP must be consistent, across the board, in how to handle these units, in order to avoid ambiguity and user confusion, versus the countervailing opinion that "one size does not fit all" when it comes to article writing here. Neither of these viewpoints are nutty – MOS effectively enforces consistency in some cases (e.g. always use double-quotes for a quotation and single-quotes for a quotation within a quotation), and by consensus avoids forcing consistency in other areas (UK vs. US spelling, for example). I have an opinion on this, but will reserve it since I'm trying to moderate, so I need to act like a judge not a jury member. PS: Good job everyone on being civil so far. Very refreshing. :-) Anyway, can we come to a consensus that consistency in this case is more important than flexibility or vice versa? — SMcCandlish ‹(-¿-)› 23:39, 9 April 2008 (UTC)

Regardless of the style we settle on, consistency is of critical importance here. In other areas, such as the American-British example, it's not so critical that all articles be consistent—"color" and "colour" mean exactly the same thing. On the other hand, we must settle here on terms which have a single, unambiguous meaning, and then use those terms consistently across the board. Inconsistency would only increase the ambiguity problem already present, and would be the worst of all possible outcomes. Seraphimblade 00:12, 10 April 2008 (UTC)

Consistency with what? Consistency with sources? Yes. Consistency with Misplaced Pages? Yes. Consistency with the IEC? No. DavidPaulHamilton (talk) 00:17, 10 April 2008 (UTC)

• The practices of other encyclopedias should serve as a guide here. Encyclopedia Britannica doesn’t use “megabyte” differently depending on which article you read. The reasons for using terminology consistently from article to article within an encyclopedia are too obvious to belabor here. When you (SMcCandlish) ask whether consistency is “more important,” I submit that we may have to go more fundamental than that and ask whether or not our top objective is to appease factioned camps of editors in order to avoid editing conflicts (which doesn’t seem to solve anything in the long run), or if the objective is to have the best possible encyclopedia for the visiting reader. If it’s the latter, then consistency in this case is more important than flexibility. Greg L (my talk) 00:18, 10 April 2008 (UTC)

Yes, consistency across the entire project is important, which is why we need to follow the international standards. :) See the problem here? — Omegatron (talk) 01:07, 10 April 2008 (UTC)

JEDEC define international standards for computer memory and their standards define KB/MB/GB in powers of two sizes. Fnagaton 09:37, 10 April 2008 (UTC)

I would prefer to see consistency between articles, but see that as unattainable in the short term. It is even more important (and attainable) to have

• consistency within articles
• unambiguous use of prefixes (of whichever variety) within articles

Thunderbird2 (talk) 06:08, 10 April 2008 (UTC)

Those strike me as two bullet points worthy of a clear show of consensus (or not). I.e., if we can agree on those (or some alternative) then we have a basis from which to move forward collectively, whatever our disagreements. — SMcCandlish ‹(-¿-)› 09:35, 10 April 2008 (UTC)

Using IEC prefixes for disambiguation is ambiguous. Here is an example: Using the MiB prefix express 10,000,000 bytes using one decimal place (9.5 MiB). Then express the quantity of 9,970,000 bytes using the MiB prefix with one decimal place (9.5 MiB). Then express the quantity of 10,001,000 bytes using the MiB prefix with one decimal place (9.5 MiB). Then express the quantity of 10,010,000 bytes using the MiB prefix with one decimal place (9.5 MiB). As you can see the different quantities of bytes are shown using the same 9.5 MiB. This makes using MiB ambiguous unless you start using lots of decimal places of accuracy. Using lots of decimal places does not make it easier for the average reader to understand. What does make it easier for the average reader to understand and what does make prefixes (using any system) cited from sources completely unambiguous is disambiguate (using parenthesis or footnotes) by explicitly stating the exact number of bytes being used in the context of the artcle and the sources relevant to the article. Fnagaton 09:40, 10 April 2008 (UTC)

Ambiguity and understandability

The second most obvious point to discuss is whether one, the other, both, or neither unit symbols are useful in Misplaced Pages. If I am reading the debate correctly, the major viewpoints are:

• The KB/MB/GB-style symbols are perfectly clear despite having multiple meanings, because the meaning is clear from the context. Sometimes 1 KB is 1000 bytes (and is equivalent to 1 KiB) (which is equivalent to 0.9766 KiB) and sometimes usually it is 1024 bytes, but we know which is what by whether we are talking about storage or RAM. (The counter-argument is that our readers cannot always be expected to understand the difference.) I think we have people agreeeing with some errors. Isn’t the above correct with my underlined corrections? Greg L (my talk) 18:51, 10 April 2008 (UTC)
• Stick with KB/MB/GB and just translate for the reader, e.g.:

With decimal meaning: 64 MB (64×10 bytes)

With binary meaning: 64 MB (64×2 bytes)

or something like this, and avoid the KiB/MiB/GiB style. (Counter: This is awkward and could potentially mislead readers who see the first into thinking that MB always means 10^6 bytes, or those who see the latter into thinking it always means 2^20 bytes.)

• The KB/MB/GB-style symbols are essentially "polluted" for WP purposes, and should not be used at all. Where appropriate KiB/MiB/GiB should be used because they are definable by a standards-issuing body, and otherwise specific byte amounts should be used. (The counter-argument is that KiB-style units are not well-accepted, and our readership won't, on average, understand them.)
• The KB/MB/GB-style symbols should stand for 1024-based, not 1000-based units, period, and units that could be expressed in KiB/MiB/GiB-style units should be given in long form. The fact that the latter are nominally standardized is irrelevant, because the standard has not been widely adopted. (Counter: Many readers will still think of them in 1000-based terms and get confused; also, we do not ignore sourceable standards on the basis of their adoption level today; it might be very different tomorrow, and at least it satisfies WP:V.)
• They're both humped; specify byte numbers in every case instead of using abbreviatorial symbols, even if this is awkward. (Counter: It is awkward to do this, and we can expect later editors to change "1,700,000 bytes" to "1.7 MB" or "1.7 MiB" with either the result of "MB" ambiguity or "MiB" unfamiliarity; so we need to pick one of the above options, else we'll have to editorially correct them to full byte values day after day).

Are these summaries inaccurate in any way? Are any missing? — SMcCandlish ‹(-¿-)› 10:34, 10 April 2008 (UTC)

• Yes, that's about it. We all know the computer harddrive industry mostly uses KB as 1000. We all know that the computer memory industry mostly uses KB as 1024. We know the computer industry as a whole very rarely uses IEC prefixes. Misplaced Pages has to rely on sources for its articles. So we have to decide on what gives most benefit to the reader. One thing that is universally understood and are universally unambiguous are exact numbers. When we say, "there are 30 apples" we know exactly how many apples there are. When we say "there is a box of apples" this box might contain 30 apples, but it could also be 32 or 28 apples. If a "standards body" comes along and then says "there is this standard box and it shall be used for all apples" yet the fruit growers don't use the standard box, the market stalls don't use the standard box and the general public don't know about the standard box, then obviously the "standard box" is not a de-facto standard. Fnagaton 10:45, 10 April 2008 (UTC)

• Thinking some more. I don't think anybody is saying "never use IEC prefixes" because they do have their place in articles where the sources mostly use IEC prefixes or the topic is specifically about the IEC prefixes. Also I don't think anybody is trying to say we should only use KB as 1024 bytes and disregard the 1000 byte version because as you say there are plenty of sources that show use with either way. What is clear from the majority of comments in the above sections is that using IEC prefixes is not preferable for the majority of topics, so we need to agree on something else like using the exact number of bytes for disambiguation. (To be prefix agnostic.) Also I have to point out a small error in your summary: "Sometimes 1 KB is 1000 bytes (and is equivalent to 1 KiB)" this is because 1 KiB is not 1000 bytes, it is 1024 bytes. ;) But I do think this demonstrates the sort of general confusion the IEC prefixes cause by being virtually unknown. *Even bigger grin*. Fnagaton 13:38, 10 April 2008 (UTC)

I noticed this immediately too. He even did it twice, also in the example of 1,700,000 bytes. This doesn't seem to be explainable by a typo. Apparently he got the meanings of KiB/MiB/GiB backwards. Considering that the relevant articles or tables can hardly be misunderstood, it says very little about the IEC-defined prefixes. I hope SMcCandlish can clarify this. --217.87.124.227 (talk) 18:03, 10 April 2008 (UTC)

I would include a coupe of additional options. (I've numbered them in the hope SMcCandlish will go back and number his options).

• 6. Use KiB/MiB/Gib when the meaning is clearly binary and use KB/MB/GB when it is clearly decimal or when we aren't sure of the exact meaning but that is what the source uses. In oddball situations that aren't covered, give the actual number. (I think this is the natural option if we go with IEC prefixes).

• 7. Write an article that explains the whole story and link to it from all articles that deal with computer memory. There are various place such a link might go, including:
  • After the first occurrence of a prefix with binary meaning
  • After each occurrence of a prefix with binary meaning
  • In a Notes section
  • In See also
  • In a head note template (This article deals with computer memory. See XXX for an explanation of units used.)
  • or some combination.

(This is my preferred option. It informs readers who are interested, without getting in the way of others.)--agr (talk) 14:43, 10 April 2008 (UTC)

• Which we could certainly do, agr, if we can all agree that the shortcomings in the conventional options for disambiguating are so severe and so compelling, that our use of protologisms justifies violating the spirit of WP:SOAP, WP:NEO, MOSNUM:Which system to use, and WP:V so that Misplaced Pages can be justified in using terminology that no other general-interest computer magazine in the observable universe has seen fit to use.

  I submit further, we should all have a show of hands as to who else here thinks we Misplaced Pages contributing editors are somehow more *enlightened* and somehow know better than the editors at all the general-interest computer magazines and all the professional print encyclopedias like Encyclopedia Britannica and World Book. I know this may seem combative. But there’s no ducking it; this is precisely what is underlying this debate. So let’s see an honest show of hands.

No, I am not more enlightened than the editors at all the general-interest computer magazines and professional print encyclopedias.

1. Greg L (my talk) 23:19, 10 April 2008 (UTC)

As a matter of fact, yes, I am more enlightened than all the editors at all the general-interest computer magazines and professional print encyclopedias.

There is a risk of underestimating the difficulty of the disambiguation task. In my view there is no one solution of those described above that solves all of the problems. Further, the actual problems encountered vary from article to article. Because of this, MOSNUM should prescribe not one disambiguation method but a range of acceptable ones (to be decided). The advantages and disadvantages of each approach should be spelled out to help the editors make a good decision for each article. The hope is that over time it will become clear which disambiguation methods are adopted in practice, and at that point perhaps true consensus can be reached. But if we are over-prescriptive and enforce an impractical solution now, there is a danger the guideline will just be ignored. To come to my point, I would like to see one more option added to the list, along the lines of:

• permit two or more different (specified) disambiguation styles; describe the associated pros & cons with each; let WP evolve until a clear preference emerges.

Thunderbird2 (talk) 18:24, 10 April 2008 (UTC)

• Picking up on what T-bird touched upon above (“MOSNUM should prescribe not one disambiguation method but a range of acceptable ones”), please note that in my hybrid proposal, I used some example footnotes to illustrate ways to disambiguate. There were two tables in the proposal that showed five different ways of expressing equivalencies; all of these would be perfectly acceptable ways to disambiguate. Further, disambigutions don’t have to be in the form of footnotes; they can be as in-line parentheticals or whatever any given editor thinks is suitable given the context and where he or she is going.

  SMcCandlish: I believe the root of the problem between the editors is centered around your third bullet point above but should be rephrased to focus on the crux of the dispute: Whether it is good practice for an encyclopedia to use units of measure that the average reader is unfamiliar with. Not a single author disagreed with the fact that the IEC prefixes are not widely recognized by the typical Misplaced Pages reader. Most of the editors who have weighed in on this issue lately don’t believe it is the proper thing to do. The counter argument is that the prefixes hijacked from the SI are used ambiguously in the real world and Misplaced Pages should recognize and use the IEC prefixes even though this has the effect of “leading the way” given that they are only rarely if ever used elsewhere in places the typical reader would visit. Greg L (my talk) 19:19, 10 April 2008 (UTC)

Graphics

I just tried to remove some awful kindergarten graphics from this page, but edit conflicted with Gimmetrow, who beat me to it. Please, this isn't a picture book, and we don't need these illustrative gimmicks. SandyGeorgia (Talk) 02:35, 8 April 2008 (UTC)

Misconstruing of the manual of style

There is a discussion at Misplaced Pages:Bot_requests#Misconceived_links_to_date_fragments_such_as_Wednesday_and_April. Please look at the comments by User:Huaiwei. It indicates that there is confusion about what wp:mosnum means in respect of linking dates. Either it is compulsory or it is not, yet two experienced editors have read the text and one concluded that it is compulsory and the other concluded that it is not. Please help clarify this point. Lightmouse (talk) 09:13, 10 April 2008 (UTC)

Proposal to create a new talk page

There is a lot of discussion about a single topic. Discussion is a good thing.

I have various mechanisms of keeping up to date with the wider range of topics discussed this page:

• The page appears at the top of my watchlist.
• I sometimes scan the page history to check activity
• I review the edit summaries to see if there is something I am interested in

Unfortunately, those means are becoming less useful. The page is almost always at the top of my watchlist, the page history is so full that it gets hard to pick out things of interest, and the edit summaries frequently look like other other topics. Consequently, I have to work harder or I reduce the amount of attention I pay to page activity.

I am sure other editors use similar mechanisms. Consequently, I am convinced that the quality of discussion on other topics has got worse.

I propose that we create a separate page for the single topic. I think that would benefit all topics, including the single topic. Lightmouse (talk) 10:04, 10 April 2008 (UTC)

Micron, micrometre

Conversation copied from WP:MoS, and closed there. It is sloppy for me to bring this over here without reading the archives, but I'm pressed for time. There's nothing on micron on MOSNUM, or (other than the following) in recent MoS discussions.

• Temperatures doesn't explain why one uses °C and °F for Celsius and Fahrenheit, but just K (not °K) for Kelvin; it's because, unlike the other two, the Kelvin scale is absolute and thus not measured in degrees.
• This section ought to include the rule that, to avoid ambiguity, millionths of a metre (μg) are known as microns, not as "micrometres" or, worse, "micrometers", because a micrometer is a measuring instrument.
• Squared and cubic metric-symbols: what is the Misplaced Pages standard for the inverses of such units? For instance, in stationery shops I've seen good-quality paper as having a weight of "80g/m" or of 80gm, both meaning "80 grams per square metre". Does Misplaced Pages have any preference for one or the other? —Preceding unsigned comment added by 217.171.129.75 (talk) 17:29, 9 April 2008 (UTC)

My comments:

• Temperatures I've never seen an authoritative statement about why "degree" was dropped from Kelvin. The change was made by the General Conference on Weights and Measures. If you want to claim this is why, please supply an authoritative citation.

• Microns are obsolete (See http://www.bipm.org/utils/common/pdf/si_brochure_8_en.pdf page 155). Micrometre and, in the USA, micrometer are correct. If you don't like the possible confusion between micrometer the instrument and micrometer the unit, write to your congressman. If you don't have a congressman, you're out of luck. --Gerry Ashton (talk) 17:54, 9 April 2008 (UTC)

I'm going to take your word for that, Gerry, rather than pulling up a PDF with at least 155 pages, but this is a complete surprise to me. American Heritage does say "no longer in use". Micrometre and Merriam-Webster say that micron is fine. Scientists and engineers still use the word frequently. I'm fairly sure that a MoS rule that says to avoid micron will be widely and forcefully ignored by scientists and engineers, at least in 2008. I agree that micrometre/er is completely fine. - Dan Dank55 (talk) 20:36, 9 April 2008 (UTC)

This is the wrong venue for this discussion. The section in question is simply a summary of what is at Misplaced Pages:Manual of Style (dates and numbers), so any issues with its advice should be raised at WT:MOSNUM (other than MOS corrections to the accurate summarization of what is actually said at MOSNUM). — SMcCandlish ‹(-¿-)› 06:47, 10 April 2008 (UTC)

Actually, Dan's summary of the Micrometre article isn't quite accurate, it says "Some people (especially in astronomy and the semiconductor industry) use the old name micron and/or the solitary symbol µ (both of which were official between 1879 and 1967) to denote a micrometre." My electronics engineering experience was that μ in writing was common up to the early eighties, but after that μm was generally used. (The computers back then often didn't support Greek letters, and sometimes didn't even support lower-case, so "u" was often substituted for "μ".) The word micron was often spoken long after the written form had become "μm". --Gerry Ashton (talk) 16:49, 10 April 2008 (UTC)

I agree with Gerry Ashton. There is no need for the word "micron" to appear in any WP articles except those relevant to the history of the term. The modern term is micrometre (symbol μm). Thunderbird2 (talk) 17:02, 10 April 2008 (UTC)

The primary source for SI units is the official SI website. Terms like 'micron', 'Centigrade', and 'degrees Kelvin' were once part of SI, but they are not anymore. The continued use of legacy terms is widespread in all sorts of domains and it should not surprise anyone that this happens in SI too.

This debate started because somebody wanted to know what the current SI units are. The answers are at the official SI website. Lightmouse (talk) 17:40, 10 April 2008 (UTC)

• We don't need to cling to outdated terminology. A foot is a body part but if I mention a 100-foot tram, who's going to think it looks like a centipede?
• Yes, that there's no need for degrees when it comes to kelvin is due to the scale's being absolute but there is still the degree Rankine. The MoS is no place for such details though.
• I don't believe that any standard exists for inverting units. It seems that the slash is most common, I'd say just be consistant throughout an article.

JЇѦρ 18:13, 10 April 2008 (UTC)

Temperature: Gerry, re the dropping of degree with Kelvin, see this refLeadSongDog (talk) 21:41, 10 April 2008 (UTC)

Micron is used for dot pitch on LCD displays. DavidPaulHamilton (talk) 22:45, 10 April 2008 (UTC)

A Tor exit node is making disruptive edits

These two edits have been made by a Tor node and are clearly disruptive. I thought the early edit might have been Omegatron editing his own comment but now I check the edit comment and IP it is also a Tor exit node. Fnagaton 18:34, 10 April 2008 (UTC)

1. http://www.inwap.com/tivo/disk-sizes.txt