Wikipedia talk:Manual of Style/Dates and numbers

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 Wikipedia: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 Wikipedia: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 Wikipedia's mission to promote a failing standardization effort. If the IEC binary prefixes gain significant support Wikipedia 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 wikipedia or citing wikipedia, it excludes any kind of result which mentions or links wikipedia 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. Wikipedia 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 Wikipedia 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 Wikipedia'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 Wikipedia 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^3x, means that everything is rounded in thousands; and powers of ten in binary, e.g. 2^10x, 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×10³bytes)" Fnagaton 18:09, 18 January 2008 (UTC)

How about: "This memory stick from company X is labelled as 1MB (2¹⁰×10³bytes)" (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 Wikipedia 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 Wikipedia 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 Wikipedia. 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 Wikipedia 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 [and?] 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×2¹⁰ bytes)".

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 Wikipedia. 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.[1]

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 wikipedia that causes problems it is inconsistent use of units in the computer industry that causes the problems. Wikipedia 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 Wikipedia, 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 Wikipedia 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 Wikipedia, 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)

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 [[February 14]] [[2008]] 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]] (February 14 2008), and removed in [[14 February]], [[2008]] (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 [[February 14]] [[2008]] format, but I'm less clear on recommending it. No comma seems to confuse editors. With [[14 February]], [[2008]], 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 "[[January 15]], [[1961]" or "[[January 15]], [[1961]", 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 [[February 14]] [[2008]] 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, Wikipedia:Citing sources includes language regarding that:

"Any style or system is acceptable on Wikipedia 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 Wikipedia: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 [[1777]]", I can simply change it to "happened on [[14 September]] [[1777]]". 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, [[July 4]], [[1776]] or [[July 4]] [[1776]].
• 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: [[July 4]], [[1776]] or [[4 July]] [[1776]], 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 Wikipedia. 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 [[July 4]], [[1776]] or [[July 4]] [[1776]]. 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 [[July 4]] [[1776]] 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 "[[May 15]] [[2005]]" 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 Wikipedia 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 [[February 29]], [[2007]] 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 [[February 29]] [[2007]] 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 [[February 29]] [[2007]] in the wiki code itself is going to really screw up that kind of WP content re-use. — SMcCandlish [talk] [cont] ‹(-¿-)› 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 [talk] [cont] ‹(-¿-)› 05:50, 5 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⁻¹¹ m³kg^-1s^-2. A longer expression for the same thing would be 6.67259 ×10⁻¹¹ ±0.00085 ×10⁻¹¹ m³kg^-1s^-m3kg-1s-2.

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[37] 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 [talk] [cont] ‹(-¿-)› 00:43, 5 April 2008 (UTC)

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

Resolved

 – Consensus agreed to (edited) change.

Wikipedia 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

“

• Abbreviations indicating long periods of time ago—such as BP (before present), as well as various annum-based units such as Ka (kiloannum) and kya (thousand years ago), Ma (megaannum) and mya (million years ago), and Ga (gigaannum or billion years ago)—are given as full words and wikilinked on first occurrence.

• BP: Do not convert other notations to BP unless you are certain of what you are doing. In some contexts the unit BP is actually defined as "years before 1950 CE/AD", not "years before the literal present", and the conversion may introduce an error if the date being converted is not a wide approximation (18,000 BP) but a more narrow one or an actual known year. BP years are given as 18,000 BP or spelled out as 18,000 years before present (not 18,000 YBP, 18,000 before present, 18,000 years before the present, etc.)

”

I would suggest a change to read

“

• Abbreviations indicating long periods of time ago—such as BP (before present), as well as various annum-based units such as Ka (kiloannum), Ma (megaannum)and Ga (gigaannum or billion years ago) are given as full words and wikilinked on first occurrence. Where older source quotations use the now-deprecated abbreviations kya (thousand years ago), mya (million years ago), or bya (billion years ago) this should be explained to the reader as in "a measured Libby radiocarbon date of 35.1 mya" (million years ago, 35.1 Ma in modern usage) had to be calibrated against then newly available stratigraphic dating references in order to estimate a Cambridge standardized date of 30.2 Ma BP.

• BP: Do not convert other notations to BP unless you are certain of what you are doing. In some contexts the unit BP is actually defined as "years before 1950-01-01", not "years before the literal present", and the conversion may introduce an error if the date being converted is not a wide approximation (18,000 BP) but a more narrow one or an actual known year. BP years are given as 18,000 BP or spelled out as 18,000 years before present (not 18,000 YBP, 18,000 before present, 18,000 years before the present, etc.)
• Caution: Some source materials will indicate whether a date is calibrated or not simply by a change in capitalization. This is often a source of confusion for the unwary user.

”

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

“

• Abbreviations indicating long periods of time ago—such as BP (before present), as well as various annum-based units such as ka (kiloannum), Ma (megaannum) and Ga (gigaannum) are given as full words and wikilinked on first occurrence. Where older source quotations use the now-deprecated abbreviations kya (thousand years ago), mya (million years ago), or bya (billion years ago) this should be explained to the reader, as in "a measured Libby radiocarbon date of 35.1 kya" (thousand years ago, or 35.1 ka in modern usage) had to be calibrated against then newly available stratigraphic dating references in order to estimate a Cambridge standardized date of 30.2 ka BP cal.

• BP: Do not convert other notations to BP unless you are certain of what you are doing. In some contexts the unit BP is actually defined as "years before 1950-01-01", not "years before the literal present", and the conversion may introduce an error if the date being converted is not a wide approximation (18,000 BP) but a more narrow one or an actual known year. BP years are given as 18,000 BP or spelled out as 18,000 years before present (not 18,000 YBP, 18,000 before present, 18,000 years before the present, or similar.)
• Caution: Some source materials will indicate whether a date is calibrated or not simply by a change in capitalization. This is often a source of confusion for the unwary user.

”

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)^{(no kb!)}

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 [talk] [cont] ‹(-¿-)› 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

“ Template:Delimitnum ”

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.

In furtherance 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:

. 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

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 [sic] 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 Wikipedia’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 Wikipedia 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 [talk] [cont] ‹(-¿-)› 01:26, 5 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 ^{What's up, Doc?} 12:59, 20 March 2008 (UTC)

You were already blocked once for this activity. STOP IT. Baseball Bugs ^{What's up, Doc?} 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 Wikipedia 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 ^{What's up, Doc?} 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 ^{What's up, Doc?} 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^{(Han shot first!)} 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 Wikipedia 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 [talk] [cont] ‹(-¿-)› 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

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 $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 Wikipedia 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.Wikipedia 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: $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 Wikipedia, 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 Wikipedia, 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 Wikipedia 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? Wikipedia 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. Wikipedia 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)

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 Wikipedia 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 Wikipedia. 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 [talk] [cont] ‹(-¿-)› 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 ^(yak) 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 ^(yak) 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 [talk] [cont] ‹(-¿-)› 02:16, 5 April 2008 (UTC)

I have updated wp:overlink.
Lightmouse (talk) 10:58, 6 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 ^(yak) 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)

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 Wikipedia. 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 ^(yak) 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 [talk] [cont] ‹(-¿-)› 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 [talk] [cont] ‹(-¿-)› 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 [talk] [cont] ‹(-¿-)› 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 [talk] [cont] ‹(-¿-)› 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 [X] 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 [talk] [cont] ‹(-¿-)› 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 idea[l]s 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 [talk] [cont] ‹(-¿-)› 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 [talk] [cont] ‹(-¿-)› 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 [sub]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 [talk] [cont] ‹(-¿-)› 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)

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 Wikipedia 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) Wikipedia wisely follows the example of the real world and ignoring the standards organisations when needed, see the BIPM issue.[2]. 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 [3] and [4].

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 Wikipedia articles. So this means adopting a system like "256 KB (256×2¹⁰ bytes)".

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 Wikipedia guideline pushing any one standard over another and to remove any bias coming from Wikipedia. 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.[5]. 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 Wikipedia 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 is 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 Wikipedia guidelines. Fnagaton 14:41, 6 April 2008 (UTC)