Wikipedia talk:Manual of Style/Dates and numbers/Archive/Complete rewrite of Units of Measurements (June 2008)

Overview of the rewrite
This is the archive of the rewrite of the Units of Measurements section. This spanned over two months and gained consensus at 10 (11) vs. 2(3) on June 7, 2008. For: Headbomb, Greg L, Fnagaton, Pyrotec, Marty Goldberg, SWTPC6800, MJCdetroit, Franci Schonken, Jimp, Rilak. Altough Dfmclean did not vote, he gave implicit endorsement by agreeing on every colour box. Against: Woodstone, Thunderbird2. Altough he did not vote, Seraphimblade would probably have voted against considering his opposition to the deprecation of IEC units.

Reasons for opposition were opposition to the partial deprecation of IEC units. Opposition was asked repeatedly to provided examples of how deprecation went against the spirit of the MOS, but failed to provide any. Other than personal opposition to partial deprecation, previous votes were brought up to support "lack of consensus", but the reasons given for the previous votes failed to convince editors that deprecation of IEC units is unsound or that IEC units are compatible with the spirit of the MOS.

This was written after archiving, as a post-commentary to give newcomers a quick-recap. Headbomb (ταλκ · κοντριβς) 18:15, 7 June 2008 (UTC)

Units of measurements (Greenbox)
{{hidden |headercss=background:#E9FFEF; border:1px 1px solid #96FFA8; |contentcss=border:1px 1px solid #96FFA8;|header=Greenbox|content=

{{Quote box | quote = There is consensus that this proposal cannot be uploaded until there is consensus on the content of the Purplebox and Redbox | source = Headbomb | width = | align = center }}

Follow Current Literature
This section is presently reserved for eventual replacement with the contents of the Redbox. The below votes have been made on the condition that the redbox gains consensus and becomes part of this section. If the redbox does not gain consensus, the greenbox shall not be uploaded to MOSNUM.

Which units to use

 * Broadly accepted units should be given preference. Usually, but not always, this means units approved by the Bureau International des Poids et Mesures (BIPM) (SI units, SI derived units, and non-SI units accepted for use with SI) are preferred over other units (e.g., write 25 °C (77 °F) and not 77 °F (25 °C)).
 * Since some disciplines uses units not approved by the BIPM, or may format them in a way that differs from BIPM-prescribed format, when such units are normally used by a clear majority of relevant sources articles related to those disciplines should reflect this (e.g., using cc in automotive articles and not cm3). Such use of non-standard units are always linked on first use.


 * Familiar units are preferred over obscure units—do not write over the heads of the readership (e.g., a general interest topic such as black holes would best be served by having mass expressed in solar masses, but it might be appropriate to use Planck units in an article on the mathematics of black hole evaporation).
 * Uses of units should be consistent within an article. An article should only have one set of primary units (e.g., write A 10 kg (22 lb) bag of potatoes and a 5 kg (11 lb) bag of carrots, not A 10 kg (22 lb) bag of potatoes and an 11 lb (5 kg) bag of carrots).
 * There is consensus to use US customary units as default units in US-related topics and that it is permissible to have imperial units as primary units in UK-related topics.


 * The use of ambiguous units is discouraged (e.g., do not write gallon, but rather imperial gallon or US gallon). Only in the rarest of instances should ambiguous units be used, often in direct quotations to preserve accuracy to the quoted material.
 * Use scientific notation with discretion—not all quantities are best served by it (e.g., do not write John is $2.2 y$ old, but rather John is 22 years old).
 * When you feel there is a need to depart from these guidelines, or when there is a conflict between two (or more) guidelines, mention the problem on the talk page and try to find a solution that satisfies the spirit of the MOS rather than the letter. Mentioning the issue on the MOSNUM talk page and on the article's associated Wikiproject might also be a good idea if the problem is not restricted to a specific article, and will ensure project-wide consistency.

Conventions

 * Values and unit symbols are separated by a non-breakable space ( &amp;nbsp; ) (e.g., write 10 m or 29 kg, not 10m or 29kg).
 * Exceptions: Non-alphabetic symbols for degrees, minutes and seconds for angles and coordinates are unspaced (e.g., write 5° 24′ 21.12″ N for coordinates, 90° for an angle, but 18 °C for a temperature). See also Manual of Style—Geographical Coordinates.


 * Unit symbols are written in upright roman type, never in italics as they could be mistaken for dimensions, constants, or variables (e.g., write "10 m" or "29 kg", not "10 m" or "29 kg).
 * Standard symbols for units are undotted (e.g., write m for metre (not m.), kg for kilogram (not kg.), in for inch (not in., " (double quote), or &prime;&prime; (double prime)), and ft for foot (not ft., ' (single quote), or &prime; (prime))).
 * Non-standard abbreviations should be dotted.


 * Symbols have no plural form—an s is never appended (e.g., write kg, km, in, lb, not kgs, kms, ins, lbs. Write bit, not bits unless bits used as a word rather than a symbol).
 * Units named after a person are not proper nouns, and thus are not capitalized when written in full (e.g., write A pascal is a unit of pressure, not A Pascal is a unit of pressure).
 * When unit names are combined by multiplication, separate them with a hyphen. A kilogram-calorie (kg&middot;cal) is not the same thing as a kilogram calorie (kcal). Pluralization is achieved by adding an s at the end (e.g., write A force of ten newton-metres).
 * When units names are combined by division, separate them with per (e.g., write meter per second, not meter/second). Pluralization is achieved by adding an s to the unit preceding the per since it reads this many units of this per one unit of this (e.g., write An energy flow of over ten joules per second).
 * When units are combined by multiplication, use a middle dot (&amp;middot;) to separate the symbols. For example ms is the symbol for a millisecond, while m&middot;s is a metre-second.
 * When units are combined by division, use a slash to separate the symbols (e.g., for metre per second use the symbols m/s (not mps)) or use negative exponents (m·s&minus;1).
 * There should be no more than one slash per compound unit symbol, e.g., kg/(m·s), not kg/m/s or kg/m·s.


 * Powers of unit symbols are expressed with a superscript exponent (write 5 km2, not ''5 km^2).
 * A superscript exponent indicates that the unit is raised to a power, not the unit and the quantity (3 metres squared is 9 square metres, or 9 m2).
 * For areas and volumes, squared and cubed US customary or imperial length units may instead be rendered with sq and cu between the number and the unit symbol (write 15 sq mi and 3 cu ft, not 15 mi sq and 3 ft cu).
 * The symbols sq and cu are not used with BIPM-approved metric/SI unit symbols.


 * Numerical range of values are formatted as (lower value/en dash/higher value/non breaking space/unit symbol) (e.g., write 5.9–6.3 kg, not 5.9 kg – 6.3 kg or 5.9 – 6.3 kg), or can be specified in written form using either unit symbol or unit names, and units can be mention either after both numerical values or after the last (e.g., write from 5.9 to 6.3 kilograms, from 5.9 kilograms to 6.3 kilograms, from 5.9 to 6.3 kg and from 5.9 kg to 6.3 kg are all acceptable, but only one of these format should be in use in a given article).
 * When dimensions are given, values each number should be followed by a unit (e.g., write 1 m × 3 m × 6 m, not 1 × 3 × 6 m3 or 1 × 3 × 6 m).

Confusing units and symbols

 * The degree symbol is °. Using any other symbol (e.g., masculine ordinal º or ring above &#x2da;) for this purpose is incorrect.
 * The symbol for the bit is bit, not b. The byte may be represented by either one of the symbols B and byte, but not b or o (French octet). Unless explicitly stated otherwise, one byte is eight bits (see Binary prefixes).
 * By extension, the symbols for the units of data rate kilobit per second, megabit per second and so on are kbit/s (not kbps or Kbps), Mbit/s (not Mbps or mbps), etc. Similarly, kilobyte per second and megabyte per second are kB/s (not kBps or KBps) and MB/s (not Mbps or MBps).


 * The symbol for Celsius degrees, Fahrenheit degrees and kelvins are °C (not C), °F (not F), and K (not °K).
 * If you need to express years as a unit, use the symbol a (from the latin annum) along with SI prefixes (e.g., write The half life of thorium-230 is 77 ka and The Cambrian is a geologic period that dates from 540 Ma to 490 Ma).
 * There are many types of years and anna (see year and annum). When years are not used in the layman's meaning (e.g., Julie is 20 years old) clarify which type of year is meant.


 * Roman prefixes are not used (M (103), MM(106), B (109)). Use SI prefixes instead.

Binary prefixes
This section is presently reserved for eventual replacement with the contents of the purplebox. The below votes have been made on the condition that the purplebox gains consensus and becomes part of this section. If the purplebox does not gain consensus, the greenbox shall not be uploaded to MOSNUM.

Disambiguation

 * Identify and define ambiguous units on their first use in an article.
 * Avoid the use of unit abbreviations that have conflicting meanings in common units systems such as SI and US customary units:
 * Use nmi (or NM) to abbreviate nautical mile rather than nm (nanometre).
 * Use kn to abbreviate knot rather than kt (kilotonne).
 * Link such units to their definitions on first use.
 * Some different units share the same name. These examples show the need to be specific.
 * Use nautical mile or statute mile rather than mile in nautical and aeronautical contexts.
 * Use long ton or short ton rather than just ton (the metric unit—the tonne—is also known as the metric ton).
 * Use troy or avoirdupois ounce rather than just ounce in articles concerning precious metals, black powder, and gemstones.
 * Use fluid ounce explicitly to avoid confusion with weight, and specify, if appropriate, Imperial, U.S. or other.
 * Use US or imperial gallon rather than just gallon (and the same logic applies for quarts, pints, and fluid ounces).
 * A calorie (symbol cal) refers to a gram calorie while the kilocalorie (symbol kcal) refers to the kilogram calorie (also known as small calorie and large calorie respectively). When used in a nutrition related article, use kilogram unit as the primary unit. For articles with only a U.S. readership, use dietary calorie(s) with a one-time link to kilogram calorie.
 * For bits and bytes, specify whether the binary or decimal meaning of the prefixes kilo (k, K), mega (M), giga (G) and tera (T) is intended. See Binary prefixes


 * In tables and infoboxes, use unit symbols and abbreviations—do not spell them out.
 * It may be appropriate to note that given quantities and conversions are approximate.
 * When part of a full sentence, write approximately in full (e.g., write Earth's radius is approximately 6,400 kilometres, not Earth's radius is approx. 6,400 kilometers or ''Earth's radius is ~ 6,400 kilometers).
 * In tables, infoboxes, or within brackets, use a tilde (~) or use approx. (e.g, write The capacity of a ship is sometimes expressed in gross register tons, a unit of volume defined as 100 cubic feet (~2.83 m³)).
 * Do not note a conversion as approximate where the initial quantity has already been noted as such, (e.g., write Earth's radius is approximately 6,400 km (4,000 mi), not Earth's radius is approximately 6,400 (approx. 4,000 mi).

Unit conversions

 * Conversions to and from metric units and US units should generally be provided. Conversions to and from imperial units should be supplied for the limited fields where they are still in use. There are some exceptions:
 * Articles on scientific topics where there is consensus among the contributors not to convert the metric units, in which case the first occurrence of each unit should be linked.
 * When inserting a conversion would make a common expression awkward (the four-minute mile).
 * In topics such as the history of maritime law in which imperial units (e.g. miles and nautical miles) are part of the subject, it can be excessive to provide SI conversions at each instance a unit occurs. In such cases, it is best to explicitly mention that this topic will use these units without providing conversion at each instance in the lead or in the introduction, in which case the first occurrence of each unit should be linked.


 * Converted values should use a level of precision similar to that of the source value (e.g. write the Moon is approximately 380,000 kilometres (240,000 mi) from Earth, not the moon is approximately 380,000 kilometres (236,121 mi) from Earth).
 * In the main text, spell out the main units and use unit symbols or abbreviations for conversions in parentheses (e.g a pipe 5 centimetres (2 in) in diameter and 37 kilometres (23 mi) long).
 * When there is consensus to do so, the main units may also be abbreviated in the main text after the first occurrence.


 * In a direct quotation, always keep the source units.
 * Conversions required for units cited within direct quotations should appear within square brackets in the quote.
 * Alternatively, you can annotate an obscure use of units (e.g. five million board feet of lumber) with a footnote that provides conversion in standard modern units, rather than changing the text of the quotation. See the style guide for citation, footnoting and citing sources.


 * Convert or unit-specific templates from Category:Conversion templates can be used to convert and format many common units in accordance with this manual of style.

Scientific notation, engineering notation, and uncertainties
This section will be updated by the content of the bluebox, once the bluebox proposal gains consensus (if it is deemed to be fitting in section of units of measurement). If the bluebox does not gain consensus by the time the greenbox does, nothing will be placed here. Bluebox may be added to the current MOS regardless of the status of the consensus of greenbox and purplebox. }}

Figure of Merit - Rewrite of section 4 (Greenbox)
{{hidden |headercss=background:#E9FFEF; border:1px 1px solid #96FFA8; |contentcss=border:1px 1px solid #96FFA8;|header= Vote and vote comments|content=

5 - Greenbox is perfect, it is as if a benevolent deity (which I may or may not believe in) came down on earth and gave us this version of MOSNUM. Anyone who disagrees is a retard. I understand my votes reflects my degree of comfort with the non-IEC prefix content of the greenbox and that my concerns for the IEC prefix-content will be voiced at the purplebox 4 - Greenbox is a vast improvement over the current section 4 of MOSNUM and while I may or may not have some minor objections to this version of the greenbox, I can fathom that there is a possibility that someone comes along with a new way of doing things that might be better than this one, but this is good enough for me. I understand my vote reflects my degree of comfort with the non-IEC prefix content of the greenbox and that my concerns for the IEC prefix-content will be voiced at the purplebox 3 - Greenbox is an improvement over the current section 4 of MOSNUM. However, I still have some major concerns that were are not addresses by this version of the purplebox. Someone needs to comes along with a better way of doing things before I can say I'm comfortable with things. I understand my vote reflects my degree of comfort with the non-IEC prefix content of the greenbox and that my concerns for the IEC prefix-content will be voiced at the purplebox 2 - Greenbox is an downgrade over the current section 4 of MOSNUM. I have some severe objections to this version of the purplebox. Someone needs to comes along with a better way of doing things before being I can say I'm comfortable with things. I understand my vote reflects my degree of comfort with the non-IEC prefix content of the greenbox and that my concerns for the IEC prefix-content will be voiced at the purplebox 1 - Greenbox is a severe downgrade over the current section 4 of MOSNUM. I have some nearly irreconcilable objections to this version of the Purplebox. Someone needs to comes along with a better way of doing things before being saying that I am even remotely comfortable with things. I understand my vote reflects my degree of comfort with the non-IEC prefix content of the greenbox and that my concerns for the IEC prefix-content will be voiced at the purplebox 0 - Greenbox is the the pinnacle of counter-productiveness that all trolls strive for. It's as if the authors wrote it with the goal of maximizing the ill-effects that would ensue if people are retarded enough to adopt this version of things. I may or may not understand my vote should reflect my degree of comfort with the non-IEC prefix content of the greenbox and that my concerns for the IEC prefix-content should be voiced at the purplebox

Vote Comments
}}

Resolved or old discussion
{{hidden |headercss=background:#E9FFEF; border:1px 1px solid #96FFA8; |contentcss=border:1px 1px solid #96FFA8;|header= Discussion pertaining to resolved debates|content=

General remarks

 * For what it's worth, I made a few changes to the 'example' above (see diff). I don't think they will ruffle any feathers, but if they do we can discuss it more.  &mdash; MJC detroit  (yak) 20:46, 20 May 2008 (UTC)
 * I made some changes to lower the priority of ambiguous related points because it should not go against the parts about usage found in sources. also if anything might be ambiguous then it can be disambiguated with familiar methods. The stuff about "strongly" has been removed since it can be read as pushing an agenda.DavidPaulHamilton (talk) 21:40, 20 May 2008 (UTC)


 * What's a "bao"? --217.87.126.99 (talk) 22:08, 20 May 2008 (UTC)


 * I think A blind application of these principles will yield good results in 99% of cases, but for the remaining 1%, use judgment. is blind optimism; toning down to most and the others. I would ask those who believe 99% to be correct why we need to have this argument. (And even where it yields good results, there is a cost; it's really not worth the obscurity of &amp;nbsp; in text which is never going to break.) Septentrionalis PMAnderson 21:45, 20 May 2008 (UTC)
 * I agree that most and others is a better way to say things. Headbomb (&tau;&alpha;&lambda;&kappa; · &kappa;&omicron;&nu;&tau;&rho;&iota;&beta;&sigmaf;) 22:30, 20 May 2008 (UTC)


 * I'd recast sentences in the passive to avoid using MOSNUM, e.g. "familiar units are prefered" rather than "MOSNUM prefers familiar units". Strictly speaking it's not MOSNUM but we editors who prefer this or that but this is getting pedantic.  My worry is that people will be thinking "MOS-who, MOSNUM, what, who cares what this MOSNUM prefers?" J IM ptalk·cont 00:15, 21 May 2008 (UTC)


 * Some places you've got US other places U.S. Stick to one, preferably US especially since you've got a UK in there too. J IM ptalk·cont 00:18, 21 May 2008 (UTC)


 * Were it at the top of the MOSNUM page, I'd see no problem but such a disclaimer could be put atop just about any section of any MoS page, surely we don't want one on each. J IM ptalk·cont 00:27, 21 May 2008 (UTC)


 * SI derived units are SI units. We don't need to link to NIST.  We've got our own articles on these. J IM ptalk·cont 00:40, 21 May 2008 (UTC)


 * "Em dashes should not be spaced at Wikipedia." according to the MoS. J IM ptalk·cont 00:55, 21 May 2008 (UTC)


 * Ranges can also be formatted in words, e.g. "127 to 254 millimetres" or "between 1.8 and 2.4 kilderkins". J IM ptalk·cont 00:55, 21 May 2008 (UTC)


 * If we are to have the following two points, since they are so closely related, might they not be combined?
 * When there is a conflict between two (or more) guidelines, then take things to the article's talk page and seek a compromise that satisfies the spirit of the conflicting guidelines.
 * When you depart from these guidelines, it would be a good idea to give the reasons for doing so on the article's talk page, as there are bound to be people that will blindly apply the MOSNUM.
 * However, are we again stating something with a far more general application? I suggest this be removed ... or at least moved to a more general position.  Also, if we're keeping this somewhere in some form, let's eliminate any possible implication that there may be something wrong with following MoS guidelines. J IM ptalk·cont 00:28, 22 May 2008 (UTC)


 * I've merged them for now. I agree that they should probably be relocated. Headbomb (ταλκ · κοντριβς) 00:54, 22 May 2008 (UTC)


 * I agree with JimP. Let's not give editors an additional license to go against (or depart from) the MoS. Doesn't WP:IAR give them enough ammo?  I say that those are best left unsaid.  &mdash; MJC detroit  (yak) 01:03, 22 May 2008 (UTC)


 * Better ... can we not unbold MOSNUM talk page, it does draw a deal of attention to itself bolded like that, undue attention I reckon ... since nothing else in the section's prose is bolded? J IM ptalk·cont 02:27, 22 May 2008 (UTC)


 * MOSNUM talk page is not in bold, it is wikilinked, and since this page is the talk page, it appears in bold. It will not be in bold when on the MOSNUM page.Headbomb (ταλκ · κοντριβς) 03:58, 22 May 2008 (UTC)
 * Oh, that makes sense, I should've checked, sorry. J IM ptalk·cont 04:20, 22 May 2008 (UTC)


 * "squared and cubed U.S. customary length units" change this to "squared and cubed imperial/US customary length units": the inch, foot, etc. are not exclusively US customary. J IM ptalk·cont 03:15, 22 May 2008 (UTC)


 * WP:PUNC specifies that double inverted commas be used (single ones within a set of double ones). J IM ptalk·cont 03:15, 22 May 2008 (UTC)


 * Can we not add the quasi-Roman-numeral-short-scale prefix set, {M for 103, MM for 6, B for 109, T for 1012 and lower-case variations}, to the list of "Confusing symbols"? J IM ptalk·cont 03:15, 22 May 2008 (UTC)
 * This has been discussed before with a general feeling against these obscure and ambiguous symbols. J IM ptalk·cont 07:18, 22 May 2008 (UTC)

Inspiration from NIST

 * We have the following statement."These were mostly inspired from the rules used by the CGPM, NIST, and National Physical Laboratory (UK)."It should be "inspired by" not "inspired from". Why the parenthetical UK after National Physical Laboratory when there's no parenthetical US after NIST?  Why abbreviate the first items but not the third?  Why exactly is ths sentence here?  The MoS derives its authority from consensus not from the authority of outside bodies.  If we mean to point editors in the direction of these bodies when MOSNUM doesn't cover a particular case, let's come straight out and say so. J IM ptalk·cont 02:48, 22 May 2008 (UTC)


 * I removed the mention since it does not contribute anything as far as policies go.19:07, 27 May 2008 (UTC)

Dotting of abrevitation

 * "Non-standard abbreviations should be dotted." What? Why should non-standard abbreviations be dotted?  I'd say they should generally be avoided but if used, dotted only according to general practice.  The non-standard abbreviation, "cc", for "cubic centimetre" should definitely not be dotted. J IM ptalk·cont 03:15, 22 May 2008 (UTC)


 * I'm no metrologist, but my general impression is that CGPM divides short forms of units into two classes: symbols, which are suitable for inclusion in equations, and may be operated on like variables, and abbreviations, which are not suitable for use in equations, and should be treated like words. I've never seen a full discussion of how this all plays out, but symbols don't get dots, because the dots might be confused with a multiplication operator in an equation. Since abbreviations are not to be used in equations, it's OK to dot them. (When using systems with limited typographic capability, an ordinary period—full stop—is sometimes used in place of the preferred mid-dot to show multiplication.) --Gerry Ashton (talk) 03:31, 22 May 2008 (UTC)

Disambiguation and IEC (intermingled)

 * Disambiguation should be considered using methods that also follow these guidelines. For example prefer broadly accepted familiar unambiguous methods to disambiguate rather than unfamiliar or obscure methods.
 * The case for using familiar units has already been made at this point. There is no need to repeat it here.  The emphasis for disambiguation should always be the use of unambiguous units.  If they are also familiar that is a good thing, but the emphasis here should be on unambiguity. Otherwise we are sending conflicting messages. Thunderbird2 (talk) 10:56, 23 May 2008 (UTC)


 * It does need to be repeated because some people have a history of using obscure unfamiliar methods to disambiguate when other unambiguous familiar methods exist. That does not make the article better and does not help the reader. The priority for disambiguation is to be unambiguous and understood by the readers. To be understood means to clearly state the need for familiar broadly accepted methods. It does not send a conflicting message because the message is the same as the main body of the proposed text. What would be sending a conflicting message would be allowing unfamiliar obscure methods to be used. That is why it is better to include the text, to make sure the spirit of the guideline is understood.DavidPaulHamilton (talk) 13:26, 23 May 2008 (UTC)


 * I'm with Thunderbird here. It's already mentioned and I really don't see anyone who would go "Hmm... this unit is ambiguous, therefore the MOS doesn't apply". Disambiguation needs to use unambiguous units, if they are familiar, that's a plus. And since I see you coming with the IEC prefixes, if you insist on not having them, you can disambiguation "Megabyte" by saying "binary megabyte" or "decimal megabyte" or specify the number of bytes, if you insist on not having IEC prefixes around. Or perhaps it would be acceptable to disambiguate with Mebibytes&but that's a debate for the purplebox. If you fear that someone will not follow the "spirit of the MOS", then mention in the MOS lead or intro that when people don't follow the letter of the MOS, they should try to follow the spirit of the MOS. It's hardly a section 4 item. Headbomb (ταλκ · κοντριβς) 13:33, 23 May 2008 (UTC)


 * I do fear that someone will not follow the "spirit of the MOS" that is why the text should be there. I will agree to the removal of the text if Thunderbird2 agrees to the following common sense interpretation of the proposed guideline: "As you imply Headbomb above, the spirit of MOS means IEC should not be used because it is unfamiliar and obscure and because more familiar methods exist." Then Headbomb if we see that Thuderbird2 disagrees with the spirit of MOS will you then agree with me that the proposed guideline needs to specifically make it clear?DavidPaulHamilton (talk) 13:55, 23 May 2008 (UTC)
 * Votes are not a currency to be exchanged. If someone does not follow the spirit of the MOS, then that person will be called on that. If that doesn't work, there is arbitration. I am however, inclined to agree the spirit of the MOS would call for a better means of disambiguation than the IEC prefixe. Explicitly mentioning binary and decimal for instance, or perhaps using a new convention such as MB2 and MB10. But that's the IEC debate and I don't want to get into it at the moment.Headbomb (ταλκ · κοντριβς) 14:21, 23 May 2008 (UTC)


 * I fully agree with you Headbomb! The world-wide Wikipedia community knows better than a bunch of French fries who have never written a single line of assembly code. We certainly don't need the IEC to tell us what's ambiguous and what isn't. We can come up with our own conventions which are much better and to the point. The IEC should have sticked to standardizing plugs and sockets. --217.87.62.108 (talk) 16:33, 23 May 2008 (UTC)


 * He has made changes to the text that relate to a specific IEC issue. I would like to see his interpretation of what those changes specifically mean with regards to the spirit of MOS before agreeing to the changes. Can't say fairer than that can I? I agree with you that the spirit of the proposed guideline means IEC should not be used. I am not sure Thunderbird2 agrees IEC should not be used so that is why there is the direct question so he can clarify. it would not be good if the guideline was agreed and then someone is not agreeing with the spirit.DavidPaulHamilton (talk) 15:01, 23 May 2008 (UTC)


 * (ec) To DavidPaulHamilton: It is pointless repeating the same argument again and again. The requirement for using familiar units is there.  The requirement for using unambiguous units is also there.  That is enough.  Otherwise you could just as well state "and by the way the units have to be familiar" or "by the way, the units must also be unambiguous" after every single bullet.  Doing so adds nothing. Thunderbird2 (talk) 13:52, 23 May 2008 (UTC)


 * See reply belowDavidPaulHamilton (talk) 15:24, 23 May 2008 (UTC)
 * It is pointless repeating the same argument again and again about claiming ambiguous things and ignoring the unfamiliar obscure nature of some disambiguation methods. please answer the direct question put to you in my comment above. Then Headbomb and I will see exactly where your point of view is.DavidPaulHamilton (talk) 14:11, 23 May 2008 (UTC)


 * I will say this one last time. The guideline calls for use of familiar units and it calls for use of unambiguous units.  There is nothing gained by repeating either statement. Thunderbird2 (talk) 15:01, 23 May 2008 (UTC)
 * That does not make it clear. Just so Headbomb and I are absolutely sure: Do you agree that the spirit of the proposed guideline means IEC should not be used? DavidPaulHamilton (talk) 15:24, 23 May 2008 (UTC)


 * Agreed, that's the spirit. Maybe we could make it more explicit by adding "If you use IEC prefixes, you are provably Sarenne. Sarenne is banned indefinitely. If you use IEC prefixes, you are wrong." How's that? --217.87.62.108 (talk) 15:29, 23 May 2008 (UTC)


 * Well, it seems clear enough to me. Which one of "familiar" and "unambiguous" don't you understand?  Headbomb has made it clear that his proposal does not address the IEC prefix debate, so I see no benefit in discussing that matter here.  As far as I'm concerned, his wording neatly encapsulates the agreed principles. Thunderbird2 (talk) 15:39, 23 May 2008 (UTC)


 * I understand the proposed guideline with regards to familiar and unambiguous and how it means IEC should not be used. Headbomb said "I am however, inclined to agree the spirit of the MOS would call for a better means of disambiguation than the IEC prefixe." So we both agree. The question put to you is: Do you agree that the spirit of the proposed guideline means IEC should not be used? DavidPaulHamilton (talk) 15:57, 23 May 2008 (UTC)


 * Headbomb. Thunderbird may complain about how this is a “personal attack.” It isn’t. Personal attacks (racist remarks, degrading someone’s position because they have a biased view based on their religion and that makes them unqualified, threats of personal attacks or death threats, etc) are things I have no desire to engage in. He also may claim I am being uncivil, but that’s just being thin skinned. In discussions here on Wikipedia talk pages, criticism of and ridicule of someone’s positions are fair game. I also don’t care to listen to any arguments over how I am not “assuming good faith.” While that is a good policy when starting out with someone, Wikipedia and no army can tell anyone they have to suspend all common sense in their dealings with someone after they have made their method of operation consistently clear time after time after time. I think you could well be wasting your time here with Thunderbird2. It is my experience that he will suggest that he will support a proposal of yours if you make concessions on verbiage he is asking for. But in the end, the promised support doesn’t somehow materialize. On at least two points (and if I can dig far enough, I may be able to come up with a third), I have done precisely what Thunderbird2 asked for, but his support vote simply never materialized. Whether intentional or not, it is my well-supported belief that the end result of caving to Thunderbird2’s wishes in hope of meeting his objections will only result in ambiguous language in a guideline that can be interpreted any way someone likes. It seems to be an issue of passive resistance. For instance, he once wrote here on B11, that “ Something isn't working. I have attempted to apply Greg's new guideline on a number of different articles, but the success rate is patchy. One example is Mac Pro, where I cannot make head or tail of the various footnotes. The article is a mess. I will continue to try, but I fear this problem will not go away.”  and further complained “ Take a look at the disambiguation footnotes. I think there are 6 in all. They are necessary because the article doesn't stick with one use for longer than about 2.3 milliseconds at a time, but in the end I fear they just serve to confuse - kinda defeats the object.” . But if you actually look at what he did (his version of Mac Pro here), it didn’t appear to me that he really had his heart in doing as good a job as an experience editor really could. In short order, I was able to disambiguate the article using the techniques used in current, general-interest computer magazines; check out my version Mac Pro here. At the time, it just struck me as one of those teen-age-like stunts of “see what a crappy job of mowing the lawn happens if you make me use that old lawn mower?” Sorry T-bird, I simply believe you are far better of an editor than that to have not been able to solve the Mac Pro article on your own; it was just too simple. The objective of this post is not to denigrate you; it’s an attempt to help some other poor editor from wasting enormous amounts of time for no reason whatsoever. That’s an extremely important objective and it’s worthwhile doing. I’m beginning to feel that the way you deal with other editors—whether intentional or not—simply isn’t fair treatment in the end. Headbomb, you started out here with a “4” vote on FCL and after seeing how easily and sensibly it resolved an issue of nanometers v.s. angstroms, you upgraded your vote to a “5” vote. And you managed to get the spirit of FCL fairly intact into your green box. As you can see though, one aspect of FCL—the binary prefixes—has proven to be a sticking point. I think you will find that after negotiating with T-bird long enough, you will come away feeling that it is “pretty to think” that you’ve arrived at wording that seems to be clear enough, but you’ll have this nagging feeling in the back of your mind that it’s a little ambiguous and m-a-y-b-e someone could exploit that ambiguity. I don’t think that will have been by accident. If you are willing to accept ambiguous guidelines that can be interpreted any way an editor desires, be my guest. But note that FCL is currently rather clear that the IEC prefixes are not to be used on Wikipedia because the average reader doesn’t know what they are, hasn’t seen them elsewhere, and won’t ever see them again after leaving Wikipedia. Call me “mean” or “uncivil”, but just pardon me all over if I believe that Thunderbird2 likes the IEC prefixes and his objective of being able to continue using them underlies all his dealings with you. I would suggest that if you want to see what the future portends for you, just ask him directly if he wants to continue to use the IEC prefixes in computer articles—either as a primary unit, or as a parenthetical “disambiguation”. Greg L (talk) 04:00, 24 May 2008 (UTC)


 * First, (while this is not relevant to what you are trying to argue, you did spend a paragraph on it and I feel I need to reply). I am also of the opinions that you have personally attacked several people here, and that you have assumed more than your fair share of bad faith. Personal attacks aren't limited to what a Wikipedia entry on it says. It goes more than racism bigotry and the like, personal attacks are ad hominem. It's not being thin skinned, it's being mocked for your opinions without being given proper rebuttals and counter arguments and it is most certainly not appropriate on talk pages. In fact it is on the talk page that it is most important to keep your cool, be civil, not ridicule people for having an opinion but rather explain to them what is wrong with the opinion, or why you feel differently using sound and intellectually satisfying arguments. When you know better than someone, you educate him/her. When you disagree, you give the reason to see if the other person will react to your rebuttals, and perhaps give some rebuttals of his own to your position and it is you who will react to that. Disagree with Thunderbird if you want, but don't give us some BS crap about how civil discourse can go out the window the minute we step on talk pages. As for my earlier agreement with Thunderbird, I explicitly mentionned that votes should not be used as currency. I can't control what people do with their votes, but mine isn't for sale. Quite frankly, I don't see what my agreement with Thunderbird that the case for familiar units was already clear has to do with anything or what concessions I made to his verbiage, nor do I get why exactly you're bringing it up in the first place, why you're warning me that Thunderbird may not end up keeping some "promise" I'm not aware of. I won't comment on Thunderbird's worth as an editor, because I don't feel like browsing those link nor do I particularly care about whatever shortcoming he has, but I do find it pretty strange that you go out of your way to make sure I think lowly of him or that I disregards what he says. Current greenbox says you should not use ambiguous units and that you should not use unfamiliar units. Megabyte is ambiguous, but familiar, mebibyte is unambiguous but unfamiliar, thus neither is optimal. Common sense (see spirit of MOS) would suggest to find a compromise that is the least ambiguous and the least unfamiliar, and that is—to use use your own words—rather clear from the greenbox. I say use "decimal megabyte" and "binary megabyte", with possible symbols 'MB2' and 'MB'10. But that is IEC debate material, and the greenbox is independent of that. Thunderbird should answer the question because the question was asked and answering questions is the civil thing to do, but given your own concern for civility, you've perhaps brought the lack of response on yourself. BTW, if you were talking about the aspect of the FCL that ended in the current purple as the one being a "sticking point", I put it there because it was something addressing the IEC debate you seemed particularly fond of, so that people may debate what to do with it. I think the whole binary prefixe section is convoluted and cluttered with useless stuff, and I'm not endorsing any of it right now. I haven't given it thought, and I won't for a while because I'm not concerned with the IEC debate right now.Headbomb (ταλκ · κοντριβς) 05:00, 24 May 2008 (UTC)


 * Headbomb you say answering questions is the civil thing to do, but Thunderbird2 has not given an unambiguous answer to the question "Do you agree that the spirit of the proposed guideline means IEC should not be used?" I'd like to give him a bit more time to give an unambiguous answer, but if it is not given I think a short unambiguous statement in the proposed guideline text about the spirit related to IEC is definitely needed. Also then we would not need the Binary Prefixes section at all since your proposed text would cover the issue. This would kill two birds with one stone. As Thunderbird2 mentioned in his vote comment he would prefer the Binary Prefixes section removed. If there are any objections to that then it will be a clear demonstration of the intention to ignore the spirit of the proposed text and to push for IEC to be used.DavidPaulHamilton (talk) 06:11, 24 May 2008 (UTC)


 * Huh? What does this “ the spirit of the proposed guideline ” mean? If the guideline is not clear, then the pro-IEC minority has again managed to get the authors of proposed guideline to paint themselves into yet another ‘ambiguity’ corner from which there is no escape. If Thunderbird were to actually “ agree that the **spirit** of the proposed guideline means IEC should not be used ” then he would have no problem having an explicit statement in the guideline to that effect. Greg L (talk) 07:21, 24 May 2008 (UTC)


 * If the greebox covers what the IEC prefix things adequatly, I think the section should stay to give a bit of the history of the debate and elaborate on the reason for why because IEC prefixes are advised against/for/allowing in special cases. The issue went on for quite a while and since proponents can feel strongly either way, the explicit mention of the resolution of the IEC debate and its conclusion should be given, even if it's redundant and follows from an application of the spirit of the MOS.Headbomb (ταλκ · κοντριβς) 06:32, 24 May 2008 (UTC)


 * As Greg suggests I've made a change that specifically mentions the spirit but it also keeps the binary prefix section archived for reference as per your suggestion Headbomb. Now if anyone removes the change they will be demonstrating they disagree with the spirit of this proposed guideline.DavidPaulHamilton (talk) 11:12, 24 May 2008 (UTC)


 * I agree that this is the spirit of the MOS, but consensus has not been reached for that at the purple box debate. Purplebox is exactly as it was when I placed it there, so it seems no one bothered to actually debate the IEC prefix things in the proper channel. It's premature to suppose that this solution will be favoured (even though I don't see why it would not). If you want things to move in the IEC debate, then argue for the change at the purplebox section, not the greenbox. Headbomb (ταλκ · κοντριβς) 15:42, 24 May 2008 (UTC)


 * The green box is the place for it though. You now what the proposed text means with regards to IEC. I know what it means. Greg seems to know. Thunderbird2 claims to know. i see nobody disagree with what the spirit of the text means for IEC. So the green box represents that conclusion.DavidPaulHamilton (talk) 18:23, 24 May 2008 (UTC)


 * No, the purple box is the place for it. When the purple box gains consensus, then Binary prefix section will replaced by the purple box content. So instead of disrupting the greenbox and cluttering this discussion with IEC debate things, why don't you edit the purplebox? Having the current purplebox—text from the FCL, and the current binary prefix section— and slapping a tag over it saying this is the archives is ugly as hell. I'm reverting. If you don't like the current binary prefix content, then change it. Headbomb (ταλκ · κοντριβς) 20:18, 24 May 2008 (UTC)


 * I insist this is included as part of the green box because it is too important not to be included. The point is this is a matter of she spirit of the green box. there is no point trying to split this issue into a separate box because the issues are too closely linked. DavidPaulHamilton (talk) 21:31, 24 May 2008 (UTC)


 * And I insist that it doesn't. The binary prefix debate has went on long enough, and deserves its own section just so everyone knows that it was resolved (or that it is still under dispute). Just slapping a tag over the current Binary prefix section saying "debate resolved, don't use IEC prefixes and BTW here's what was on the MOS before it was resolved" will not cut it. If the debate is settle, as you claim, then edit the purple box to reflect what you consider to be the consensus. Do I agree that the debate is settled and that IEC prefixes should not be used? Yes. If you actually edited the purplebox to reflect what the consensus is on the binary prefix situation. All the material is there, yet no one bother to present something to the wikipedia community. And ideal purplebox would include:
 * A brief history of the debate and arguments from both sides
 * Which side got consensus
 * List IEC prefix and SI-prefixes (current table is fine IMO)
 * How to disambiguate the megabytes.

That could probably be done in less than 10 lines. Not a lot of work, but you seem to be very reluctant to do it. If you don't want to do the work, don't complain that it's not done. Headbomb (ταλκ · κοντριβς) 21:53, 24 May 2008 (UTC)


 * well that is just rude, I'm not "very reluctant to do it" but I do see you did the work, thank you for that. My point is the guideline text you are proposing to replace tackles the issue as one part because the subjects are very closely linked and now you've split it into three. It may seem like a good idea but it is not because one part might reach consensus and the other parts may not and what happens then is that we get a mess of conflicting guidance which does not help.DavidPaulHamilton (talk) 22:43, 24 May 2008 (UTC)


 * Headbomb, I don’t understand your point with “ As for my earlier agreement with Thunderbird, I explicitly mentioned that votes should not be used as currency. I can't control what people do with their votes, but mine isn't for sale. ” What I’m talking about is modifying a proposed guideline per input from a wide variety of editors in order to find compromise wording that is supported by the widest number of editors. *Consensus.* That’s what I did during the crafting of “First draft”, “Second draft”, “Third draft” and “Fourth draft” (which became “Follow current literature”). I listened to everyone’s objections and comments, tried to resolve diametrically opposing views by jettisoning controversial text, and tried to develop maximum consensus. If you’re not doing that, then I don’t know what the holy hell you are doing. As for how Thunderbird interacted with all of that process, it’s a matter of record. Like all off all the editors involved here, I listened to his input because he wrote directly to me that incorporating certain text he desired (mentioning how the IEC prefixes had meritorious virtues) and deleting still other text he opposed (mention of the uno) was necessary for his being able to support the proposal, and after doing what he asked, he still didn’t support it in the end? You call that an “attack” “ without being given proper rebuttals and counter arguments ” that shouldn’t be allowed on talk pages? I reject that charge as utter nonsense; I call my statement as simply stating a relevant fact that is very, very germane to trying to obtain a wide consensus on a proposed guideline. Further, he and others have every opportunity to rebut my statement if it is untrue or incomplete. You may enjoy wasting your time but I don’t. I tend to be goal oriented. You’ve stated here that you’re only writing ‘what you’d like to do if it were you’, not necessarily what you hope will necessarily be adopted on MOSNUM. If that’s still the case, I don’t understand why all the effort; you need wide consensus to accomplish anything here. Are you expecting that you’re going to be taken seriously if you’re really just writing what you would personally like to see on MOSNUM and not what you think really has a chance of achieving a consensus? Greg L (talk) 06:37, 24 May 2008 (UTC)
 * I changed one instance of BIPM units to metric units, as it seemed simpler and more appropriate for that particular context. I also changed it so that "&prime;&prime;" showed up as "&amp;prime;&amp;prime;".  As always, this change is open to be changed.  Regards,&mdash; MJC detroit  (yak) 12:56, 27 May 2008 (UTC)

Dispute tag

 * We should not include the dispute tag; in this text it is redundant with the explanation of the dispute, and the purpose of this is to write an undisputed (if incomplete) text. Septentrionalis PMAnderson 23:43, 20 May 2008 (UTC)

Overlap with rest of MOS

 * The intro ..."These are guidelines, not unbreakable laws. No set of rules could ever be written in a few lines that can cover the scope of all the topics of Wikipedia. A blind application of these principles will yield good results in most cases, but for the rest, use judgment. If you feel there are good reasons to depart from MOSNUM, then go ahead and depart from it."... delete it. This is far to general to be in a section of a MoS subpage.  Words to this effect may have their place at the top of the main MoS page. J IM ptalk·cont 00:07, 21 May 2008 (UTC)


 * We can certainly put it in more than once; indeed the present introduction to WP:MOS has attempted and failed to say this, to the ruin of FA. But it's true here, as elsewhere, and needs to be said. Septentrionalis PMAnderson 00:11, 21 May 2008 (UTC)


 * I agree with both the removal of the dispute tag and removal of the intro. I'll edit in consequence. Headbomb (ταλκ · κοντριβς) 00:13, 21 May 2008 (UTC)

Inverted commas

 * WP:PUNC calls for double inverted commas. Let's follow suit. J IM ptalk·cont 03:36, 26 May 2008 (UTC)


 * What do you mean by that? What are double inverted commas? And where do we need them?Headbomb (ταλκ · κοντριβς) 04:08, 26 May 2008 (UTC)


 * Inverted commas are quotation marks & we'd put double ones around the symbols/abbreviations like "kg", "in", etc. J IM ptalk·cont 09:08, 26 May 2008 (UTC)

Order
I prefer the order produced by DRHamilton:
 * MOSNUM prefers broadly accepted units. Since some disciplines uses non-modern units or may format metric units in a way that differs from SI format, when there is a consistent usage of such units by a clear majority of relevant sources, articles related to those disciplines should reflect this (e.g. using 'cc' in automotive articles and not 'cm&sup3;').
 * MOSNUM prefers familiar units &mdash; do not write over the heads of the readership (e.g. a general interest topic such as black holes would best be served by having mass expressed in solar masses, but it might be appropriate to use Planck units an article on the mathematics of black hole evaporation).
 * MOSNUM prefers consistent use of units within an article. Only in the rarest of instances should units be used inconsistently.
 * MOSNUM prefers SI and SI derived units, or units accepted for use with SI units as the main units (e.g. 25°C (77°F) and not 77°F (25°C)).
 * There is consensus to use U.S. customary units as default units in US-related topics and that it is permissible to have imperial units as primary units in UK-related topics.
 * MOSNUM prefers unambiguous units (e.g do not use gallon, but rather use imperial gallon or U.S. gallon). Only in the rarest of instances should ambiguous units be used (usually (but not limited to) direct quotations to preserve accuracy to the quoted material).

This seems to be in the right order of importance. We would not be right to prefer SI if it were not broadly accepted, so broad acceptance should come first. Septentrionalis PMAnderson 23:39, 20 May 2008 (UTC)

I disagree. The focus of any MOS is to avoid ambiguity and to ensure uniformity (consistent usage within articles and wikipedia as a whole), everything else is details. As such, emphasis should be on those two point first, with the rest being the agreed upon means to achieve unambiguity and uniformity.Headbomb (ταλκ · κοντριβς) 23:52, 20 May 2008 (UTC)
 * A foolish consistency is the hobgoblin of little minds; a useful MOS will enforce uniformity where it is useful and not elsewhere. Septentrionalis PMAnderson 23:55, 20 May 2008 (UTC)
 * Perhaps, but it remains that unambiguity and uniformity are the primary concerns of any MOS. Headbomb (ταλκ · κοντριβς) 23:57, 20 May 2008 (UTC)
 * No, the primary concern of any manual of style worth having is clarity. Disambiguation of what is already clear is a waste of electrons; uniformity which does not contribute, eventually, to clarity is petty tyranny. However, uniformity is often a help to clarity; ambiguity is normally an enemy. Septentrionalis PMAnderson 00:00, 21 May 2008 (UTC)


 * I agree with Septentrionalis on the order. A broadly accepted unit adds more to a article than an unheard of unambiguous unit. Obscure units are by definition, ambiguous.  -- SWTPC6800 (talk) 00:27, 21 May 2008 (UTC)


 * I think that the general senses of the terms ambiguousCambridgeAHD and obscureCambridge 12AHD are somewhat distinct ... very close to be sure, but whilst I'd call the gigibit obscure I don't agree that it's ambiguous in the usual sense of the word. (Note only one of the dictionary sources I add really supports this interpretation of mine.)  Either way, obscurity in itself is bad enough. J IM ptalk·cont 01:16, 21 May 2008 (UTC)
 * While you're at it, see ambiguity for an insightful (if rather dazzlingly meta) discussion.LeadSongDog (talk) 02:36, 21 May 2008 (UTC)


 * Years ago I worked for a Korean born computer engineer who had a PhD. One day at lunch he was complaining about how dumb a Budweiser beer commercial was. I said, "Maybe Budweiser is not targeting Korean PhDs." Some of the folks here have advanced degrees in science and want everything to be exact and precise. Sometime this makes the article difficult to understand for a typical Wikepedia reader. -- SWTPC6800 (talk) 05:22, 21 May 2008 (UTC)


 * Care to provide an example of one instance when being precise and exact obfuscated things for the typical Wikipedia reader? Headbomb (ταλκ · κοντριβς) 05:51, 21 May 2008 (UTC)
 * Inserting IEC prefixes into articles is a good example. There are better ways to disambiguate MB without needing to use obscure IEC. I made some further tweaks to the text in the green box to demonstrate what kind of wording would get my support and also would be more compatible with not promoting obscure units. If my changes stay without too much change I can then change my vote to a support.DavidPaulHamilton (talk) 15:41, 21 May 2008 (UTC)


 * Exactly! Only IEC binary prefix warriors use these obscure units. --217.87.63.197 (talk) 16:16, 21 May 2008 (UTC)


 * A less controversial example may be what we do in all too many mathematical articles: beginning with the most general and abstract definition possible of the subject, usually from category theory. This is fine for someone who already understands both the subject and the terminology; it is guaranteed to lose a reader who doesn't. Septentrionalis PMAnderson 15:54, 21 May 2008 (UTC)

Years

 * Gigaannum (Ga) vs. Gigayears (Gy): These are ambiguous units, we should clarify what they mean in "confusing symbols", and which should be used. Date section says Ga (and Ka, Ma...) should be prefered. Is this sound? Does anyone have additional feedback on this? This is my last "major" concern. Headbomb (ταλκ · κοντριβς) 13:58, 23 May 2008 (UTC)


 * My suggestion it to clearly state that the the symbol for the year is "a" ... only. This will be taken as the Julian year (365.25 days).  Different years can be specified by use of subscripts as described in Annum.  State also that only SI prefixes are to be added.  Remove the examples of other notation: they could mislead editors into thinking that these are accepted. J IM ptalk·cont 01:40, 26 May 2008 (UTC)


 * Seems reasonable. I'll give it a shot, tell me what you think. Headbomb (ταλκ · κοντριβς) 22:48, 26 May 2008 (UTC)


 * You write that "yr" is "usually used in fields such as astronomy, nuclear physics,..." Is this the case?  If it is, then we've got a few articles needing an up-date. For example, kyr has this to say."The symbol kyr was formerly common in some English-language works, especially in geology and astronomy, ... Modern, ISO 31-1 recommended usage is ka for kiloannum, which avoids the implicit English bias of 'year' by using a Latin root."We have the following from myr. (Note the lower case "m".)"The symbol myr was formerly used in English-language geology and astronomy ... It is an abbreviation for 'million years' and lower case is usually used. In English-language technical literature in these fields, the term 'Ma' is preferred, as this conforms to ISO 31-1 and NIST 811 recommended practices. ... The correct ISO 31-1 usage is megaannum or Ma which unambiguously denotes a duration of 106 years. To denote a date one would add ago or bp to denote before present. In non-SI usage, Ma was used to denote a specific number of millions of years ago, but it was not properly used to describe a duration, so: the Cretaceous started 145 Ma and ended 65 Ma, but it lasted for 80 myr (or 80 My). More often, the term 'mya' (million years ago) is used in these contexts."Next we have Byr with this. (Note that Gyr is a disambiguation page.)"Byr was formerly used in English-language geology and astronomy ... The 'B' is an abbreviation for 'billion' ... Today, the term gigaannum (Ga) is also used, but Gy or Gyr are still sometimes used in English-language works (at the risk of confusion with the gray). Because a billion means 1000 million in some countries but can mean a million million in others its use is deprecated in favour of giga- ..."I say we ditch "yr" altogether: it's finished.  Use "a", "ka", "Ma", "Ga", etc. to express a duration add "ago" or "BP" to express "years ago".  Where precision is important the year is taken to be a Julian year (unless context clearly indicates otherwise). If other types of year are meant, the meaning should be clarified. J IM ptalk·cont 06:45, 28 May 2008 (UTC)


 * I based this on a quick Google search (didn't specify years though so it might be mostly old websites and sources) and some (admittedly old) books I had around. I know for a fact that the BIPM deprecated kyr, Myr,... ky, My,... and every other symbol except a. I also know for a fact that many astronomical journals have made the switch, so I guess astronomy is in the process of switching if it didn't already completely switched. Let's go for all-accross a then. Headbomb (ταλκ · κοντριβς) 07:43, 28 May 2008 (UTC)


 * Whew! For a while I feared I'd have to break out the yr=yottaruble argument.  Glad to see we can agree on this, anyway. LeadSongDog (talk) 20:50, 29 May 2008 (UTC)

Unit combination under scalar product and vector product
I thought of this the other day.

Work is $$W=\vec{F} \cdot \vec{d} $$. The unit of work is therefore the N&middot;m. Torque is $$\tau=\vec{F}\times \vec{r}$$. The unit of torque is therefore the N&middot;m.

I haven't heard of any convention at all to distinguish between the two. I suggest we combine scalar multiplied units with dots and vector multiplied units with crosses. A.k.a.

Work is $$W=\vec{F} \cdot \vec{d} $$. The unit of work is therefore the N&middot;m. Torque is $$\tau=\vec{F}\times \vec{r}$$. The unit of torque is therefore the N&times;m.

Headbomb (ταλκ · κοντριβς) 00:59, 28 May 2008 (UTC)


 * Units are not vectors so there can be no mathematically sound distinction between cross and dot multiplication. Convention is always to use the dot.  This is the convention followed on WP per currrent MOSNUM.  The SI unit of work is the joule but you know that of course so what are you driving at? J IM ptalk·cont 01:21, 28 May 2008 (UTC)


 * The expression for torque is not τ = r×F, it is τ = r×F. The units for the force vector is not just newtons, it is also degrees (or radians) for the two angles necessary to orient the force; likewise for the position vector and the torque vector. Thus, the fact that a quantity is a vector can be detected because in addition to a unit of measure for the magnitude, there are two instances of an angle unit. (In some cases, one or both of the angles may be implicit.) --Gerry Ashton (talk) 01:34, 28 May 2008 (UTC) (Corrected 29 May 2008 as suggested by Jimp below.)


 * You are twice wrong. The unit of force is just Newtons. The angle and direction properties of the force are handled by the vector nature of force, not by the units of force. Units behave like scalars not vectors. If you like, think of a force vector as (3 N, 6 N, -9 N)= (3, 6, -9) N just like (3, 6, -9)= (1, 2, -3)*3. Units behave like scalars which do not have any notion of direction or angle. Furthermore, you have torque expressed wrong. The standard definition of torque is τ = r × F. The order is important.


 * I accept your correction concerning the order of the cross product. I maintain that a force explicitly or implicitly has three units, newtons for the magnitude and degrees or radians for the orientation angles. As you say, a single unit behaves like a scalar; only a collection of units can sometimes behave as a vector. --Gerry Ashton (talk) 16:29, 29 May 2008 (UTC)


 * Perhaps this will convince you of the remaining issue. Orientation angles require a coordinate system (or at a minimum the "zero angle" reference vector) but a vector is a geometric quantity independent any given coordinate system. If I don't state a coordinate system or reference, the value of the angles aren't even defined. Furthermore, your argument requires that the number of "units" for force (or any vector or tensional quantity) change with the dimension of the space. In 2D, force would have only one orientation angle, in 3D two orientation angles, and so forth. Additionally but more technical, angles are only given in vector spaces that allow an inner product. The system, could have been defined in the way you suggest (there exists an 1-to-1 mapping between R^3 and "magnitude,angle1,angle2"-space as sets) but the reasons I've given above I hope show why it would be a bad idea that doesn't generalize well. These are partly the reasons why units are not taught in physics courses nor handled by standardization institutions the way you are suggesting. You are right that angles are implicitly handled however. When one says that force (or velocity or displacement or electric field) is a vector quantity, bundled into the term vector is the ability to calculate angles with respect to other vectors (assuming an inner product). If you wanted to include angular measure as "units" in addition to using the 3i+3j+4k notation, every vector would carry along a lot of redundant baggage that isn't necessary. This is just off the top of my head. They might even be more subtle but profound problems with your idea too. Jason Quinn (talk) 18:59, 29 May 2008 (UTC)


 * Of course, direction can be given in other ways besides specifying angles ... but we all know that too ... right? Okay, if not, here's an example of a vector, F, split into three components: F = (Fx, Fy, Fz); one for each dimension, x might be north, y east and z up.  Sorry to bore those who already know this stuff. J IM ptalk·cont 05:40, 28 May 2008 (UTC)

I'm losing tract of what exactly we're talking about. My concern is this: Under current rules, N&middot;m can refer to either torque units or Joules. While not de facto problematic, it is ambiguous. Should the rule that dot products (scalar product) are to combined with middots, and cross products (vector product) units with crosses be made for non-ambiguity's sake? Headbomb (ταλκ · κοντριβς) 10:40, 28 May 2008 (UTC)


 * I don't see the rules anywhere explicitely ruling "N&middot;m" out as a unit of energy but I'd argue that this would not be necessary since "N&middot;m" is not a unit of energy. The unit of energy is the joule, "J".  In short, you're barking up the wrong tree using SI units as your examples, try foot-pounds force ... pound force-feet. Sure, let it be the rule that the scalar product of two vectors be denoted with mid-dots and the vector product of two vectors be denoted with a cross.  However, units are not vectors.  Suggesting "ft×lbf" for the unit of torque is a dead-end. J IM ptalk·cont 15:52, 28 May 2008 (UTC)


 * This is a very wrong idea as Jimp explained. The dot between units has nothing to do with the dot product; it is merely a spacer and reminder that we are multiplying units. The units of work and torque are formally identical (when expressed as N&middot;m) so there is no need to distinguish between them. We must decline this idea. Jason Quinn (talk) 15:40, 29 May 2008 (UTC)

The units are not identical. If the two units were identical (as current rules imply), the joule (J, or N&middot;m, or kg&middot;m2&middot;s-2) would be a unit of torque (N&middot;m, or kg&middot;m2&middot;s-2). If we distingish between scalar and vector combination, then the units become distinct (which they are), a joule (J, or N&middot;m, or kg&middot;m2&middot;s-2) would not be a unit of torque (N&times;m, or kg&middot;m&middot;s-2&times;m) Headbomb 20:26, 29 May 2008 (UTC)


 * There is no mathematical distinction between a×b and a&middot;b where a and b are not vectors. Units are not vectors.  Therefore N×m is mathematically identical to N&middot;m.  It's just plain old scalar multiplication.  So what we're talking about here is introducing a new notational convention of our very own invention, the use of which might make us look somedeal naïve to those who actually went and studied first year maths or physics ... and would fly right over the heads of those who didn't. Do excuse my strong wording.  J IM ptalk·cont 00:34, 30 May 2008 (UTC)


 * It would be a new convention indeed, I'm just throwing ideas out there to see if there was a need for such a convention. Consensus seems to be that there isn't (I'm neutral on this). Headbomb (ταλκ · κοντριβς) 02:23, 30 May 2008 (UTC)

I'd say that if there were a need, someone would have addressed it already. The outside world is getting along without this kind of thing, we can follow suit lest we leave readers completely baffled. J IM ptalk·cont 04:08, 30 May 2008 (UTC)

I want to mention a few more things and then we should consider this matter closed. It is true that units are not unique, Headbomb. Any combo of units that is equivalent to "m N" can be a Joule or torque or what-have-you. When you specify that a combination of units are work or torque, you are giving the context under which the units are being used. This is part of the power of the current seven fundamental unit SI system and not a flaw. It gives every physical quantity an equivalence class of units based upon the physical units of the defining equation for that property. (There's sort of an analogy here between the SI system using a base-10 number system verses a vector-unit system giving every number its own unique character.) In any case, you guys are really arguing against the SI system and Wikipedia is not the place to start new conventions. Since there still seems to be some confusion regarding the scalar and non-vector nature of units, let me be more explicit. Lets examine torque and work:


 * τ = r&times;F = (rx m, ry m, rz m)&times;(Fx N, Fy N, Fz N) = (m*N)*(rx, ry, rz)&times;(Fx, Fy, Fz)


 * W = F&middot;r = (Fx N, Fy N, Fz N)&middot;(rx m, ry m, rz m) = (m*N)*(Fx, Fy, Fz)&middot;(rx, ry, rz)'''

By the defining properties of a vector field and the mathematical properties of the cross and dot product, the multiplication of m and N is seen to be via the operation on the field on which the vector field is defined (aka scalar multiplication). The type of unit-multiplication is now seen to be the same regardless of a cross or dot product being used. Lastly, I don't think it is obvious what the units would be for the components of a vector under the alternative system being proposed since they are tied to vector itself. Jason Quinn (talk) 18:18, 31 May 2008 (UTC)

}}

Unresolved debates
{{hidden |headercss=background:#E9FFEF; border:1px 1px solid #96FFA8; |contentcss=border:1px 1px solid #96FFA8;|header= Discussion pertaining to unresolved debates|content=

I've grouped the debates in two. Resolved issues are above in the thingamajig (click and it'll display), as well as those no one seem to care about anymore. Feel free to move things from here to there and there to here (please keep some sort of order in things). Headbomb (ταλκ · κοντριβς) 19:29, 27 May 2008 (UTC)

Conversions

 * Consistent use of units within an article will often require giving primacy to a conversion whilst putting the source value in brackets. In cases where precision is important it is best to make note of such a reversal of the standard order.  This can be done using a footnote. J IM ptalk·cont 00:24, 21 May 2008 (UTC)


 * "Uses of units should be consistent within an article" ... whilst generally true there are valid exceptions e.g. a pub might sell beer in 375-millilitre bottles and in pint glasses, a pusher might sell small quantities of dope by the gram and larger quantities by the ounce, an aristocratic family might have been granted so many acres of land way back when but are now having to sell it off by the square metre, the average price of rum in Australia might have increased from x pounds per imperial gallon to y dollars per litre in the last hundred years. Also, as elluded to above, I'd argue that, wherever precision is important, it is preferable to put the source values first with conversions in brackets even if this leads to inconsistancy unless you're willing to take the time to make note of the reversal (e.g. in a footnote). J IM ptalk·cont 07:37, 21 May 2008 (UTC)


 * Agree on both points here. Please rephrase. Septentrionalis PMAnderson 15:59, 21 May 2008 (UTC)


 * The above, of course, leads me to another point that we're overlooking, i.e. original values should generally be given first with conversions (where appropriate) given in brackets. By "original values" I mean those measurements or specifications which we have reasonable cause to believe were the values obtained by the original act of measurement or by the original specification or as close to this as we can possibly get.  This will generally be those values that we find in the sources.  Exceptions will probably be so rare and glaring that we might as well leave it up to common sense.  Thus a general rule to follow the sources when it comes to deciding which system to use would seem a sensible addition.  Such a rule is similar to the general thrust of following the current literature but avoids a couple of its difficulties.  Questions as to what constitudes "the literature", "the level" and "the disipline" are avoided—refer to the article's sources.  Where the source we're using employs a unit not widely used in the rest of the literature, use it, e.g. if your source talks of cubic metres of crude oil put these first (giving conversions to barrels in brackets, of course) ... this was an exception to the follow the current literature rule.  This is about fidelity to the sources, though, so I'm not saying that if a source calls a micrometre a "micron" so must we.  Stick with the sources' measurement systems but feel free to reexpress the values in more standard/familiar/unambiguous/etc. terms where appropriate ... i.e. balance this with the other principles we've got here. J IM ptalk·cont 07:37, 21 May 2008 (UTC)


 * The proposal states the following."Conversions to and from SI (and SI-related) units and US units should generally be provided."
 * What do we mean by "SI-related"? Do we mean any metric unit?  Do we mean any unit acceptable for use with the SI?  Can we not state exactly what we mean ... even give a list?  Can we not make that "imperial/US" units?  The bullet point then goes on as follows.
 * There are some exceptions:
 * Articles on scientific topics where there is consensus among the contributors not to convert the metric units, in which case the first occurrence of each unit should be linked.
 * When inserting a conversion would make a common expression awkward (the four-minute mile).
 * In topics such as the history of maritime law in which imperial units (e.g. miles and nautical miles) are part of the subject, it can be excessive to provide SI conversions at each instance a unit occurs. In such cases, it is best to explicitly mention that this topic will use these units without providing conversion at each instance in the lead or in the introduction, in which case the first occurrence of each unit should be linked.
 * What's so special about scientific topics? Newton did his science in feet and pounds.  What about the grey area between science and non-science.  Is medicine a science?  What about information theory?  Now if the original/source units were natural units, providing no imperial/US conversions might make sense, giving no metric conversions either might make sense too.  Also if there exists no reasonable and familiar imperial/US equivalent to a given metric unit (e.g. the nanometre, the ohm, etc.) then a conversion may be out of place or even impossible. What exactly constitutes a topic "such as the history of maritime law"?  What does it mean for an imperial unit to be "part of" a subject?  What one person might find excessive the next might find necessary.  This third point seems to me a perfect rule for those interested in removing and/or prohibiting conversions wave about.  I'd like to see this loophole closed.  We don't want the anti-metric nuts staking out claims on this article or that declaring them to be conversion-free zones ... nor, on the other hand, do we want the metric-only nuts doing the same.  If your prose seems cluttered with conversions, it's cluttered with measurements and is in need of a reorganisation to make it easier for all to understand; the removal of conversions is not what's needed, this just makes it more difficult to understand for those thinking in the other system.  We don't, though, need to have the same conversion appear twice in an article (unless, perhaps, they are in different sections). J IM ptalk·cont 06:35, 22 May 2008 (UTC)


 * I disagree, for the most part, with Jimp's suggestion to provide conversions to imperial as well as customary American units. So far as I know, imperial units are only used for automotive travel (in which case the imperial and customary American units are the same) and beer sold in public houses (pints). So unless the article is about small quantities of beer, I see no need for conversions to imperial units.


 * I also feel there are indeed areas where customary American units have never been used, or have not been used for a long time, such as the measurement of blood pressure. I see no need to write that a typical systolic blood pressure is 120 millimeters of mercury (16 kPa, 2.3 PSI). --Gerry Ashton (talk) 14:48, 22 May 2008 (UTC)


 * A new rule has appeared."When giving a non-exact conversion, indicate it with a '~' ..."To me this seems rather unnecessary in most instances. Generally, you'll be dealing with measurements which are already approximate.  Conversions of measurements are, by nature, approximate.  The "~" therefore tells you nothing that common sense has not already told you.  This is not how things are now being done.  There is no need to require the addition of this symbol, moreover, it would be a logistical nightmare.  This proposed rule would affect tens (hundreds maybe) of thousands of conversions.  The process of adding the "~" would likely never be completed, leaving us with some conversions with and other without the "~".  The job half done would lead to a great deal of confusion ... "Why does this conversion have a '~' whilst that doesn't?"  However, I can see a sensible use for such notation.  Suppose it is an exact figure you start with and your conversion is an approximation, then the addition of the "~" might give the reader something he doesn't already know. J IM ptalk·cont 03:36, 26 May 2008 (UTC)


 * Yes, I've been meaning to mention this, but I got hungry and forgot I meant to during my quest for food. I thought perhaps if we limited the use of ~ to units that were much less precise than the non-converted value, but that shouldn't happen since conversions should be of similar precisions. Mentioning that it can be used instead of "approximetaly" might be a smarter suggestion to make (e.g you can write either Bob ran 20 m (approximately 60 ft) before being hit by a car or Bob ran 20 m (~60 ft) before being hit by a car). Headbomb (ταλκ · κοντριβς) 04:08, 26 May 2008 (UTC)


 * What I was thinking is "Bob ran 20 metres (60 ft) before hitting the car." but "Bob run along the 20-metre (~60 ft) track before hitting the car." the difference being that in the first sentence the 20 metres is already an approximate measure whereas in the second the track was exactly 20-metres long.  But, yeah, "~" to indicate other significant reductions in precision would also be in order.  Sure conversions should generally be of similar precision but we shouldn't generally need "~", I don't reckon. J IM ptalk·cont 09:19, 26 May 2008 (UTC) ... Perhaps, though, as you suggest, mentioning the it can be used to represent "approximately" is best.  How about an example like "To become a candidate for core city status in Japan, a city must have a total area of at least 100 square kilometres (~40 sq mi)." to get the hint that you can use it when you're converting an exact figure? J IM ptalk·cont 19:44, 26 May 2008 (UTC)


 * When part of a full sentence, write "approximately" in full, do not use "~" or "approx." (e.g. do not write "Earth's radius is approx. 380,000 km" or "Earth's radius is ~380,000 km).
 * When giving approximate quantities and conversions, you may indicate it with a "~" or "approx." (e.g you may write "Earth's radius is approximately 380,000 km (~240,000 mi)" or "Earth's radius is approximately 380,000 km (approx. 240,000 mi)").


 * The above is the current version. Another approach would be to have "approximately" when the unit is written out in full & "~" otherwise.  Whether that would be better is another question.  I'd like to see an even stronger stance against the over use of "~".  In the Earth-radius example above we already have an "approximately" we don't need the "~". I recall reading some popular science book, The Emperor's New Mind by Roger Penrose if my memory serves me correctly, in which there was something like a dozen exclamation marks per page (if I eggagerate, it was a decade ago).  Perhaps I'm a punctuation pedant but I tend not to end anything but an exclamation with an exclamation mark but this book was crammed with them.  After a while the exclamation marks began to loose their impact and served as nothing more than an irritatingly shaped full stop. Over-use of a symbol dilutes its meaning.  Let's not allow "~" to be liberally thrown around at just any conversion.  The symbol should be reserved for values/conversions where there is less precision than would otherwise be assumed. J IM ptalk·cont 02:30, 27 May 2008 (UTC)


 * ...approximately 380,000 km (approx. 240,000 mi)... It seems redundant to say "approximately" then have "approx." in the conversion too. Wouldn't common sense dictate that if the default unit is "approximately" then the converted value would also be "approximately" without needing to be expressly written?  And yes, I know that today common sense is sometimes all too uncommon, but still...  &mdash; MJC detroit  (yak) 15:48, 27 May 2008 (UTC)


 * There having been no objection in over a week I intend to adjust the green box accordingly. J IM ptalk·cont 18:10, 2 June 2008 (UTC)

Headbomb, you removed"Where the level of precision not singnificantly lower than expectable for the quantity or conversion in question it need not be noted as approximate.""since it is up to judgement," as you write "and that judgement part was already invoke by 'it may be appropriate to...'." Fair enough, but I have argued that good judgement is to follow this removed point and would therefore object to the addition of examples which go against it. A measured quantity is, by nature, approximate. Conversions from approximate values are necessarily approximate. We need not mark them as such. I argue that we should not mark them as such. Look around at the thousands of conversions on WP & you'll see that we do not mark them as such. We'll end up missing the mountain for the mole hills. There is included an example where it would be appropriate to note the conversion as approximate (the gross register ton example being in reference to a defined and therefore exact quantity). Let's have the examples where this would be inappropriate omit the "~". J IM ptalk·cont 08:13, 3 June 2008 (UTC)

The current advice is to spell approximately out in full sentences. Again I pose the question "How about connecting it to the way that the unit is written instead?" The MOSNUM advice is generally to spell units out in full when they appear in prose. However, allowance is made for symbols/abbreviations. This is useful when there are many instances of units or when the unit names are long (e.g. "pounds force per square inch" vs. "psi"). Would it not make sense to treat approximation in parallel? How about we allow (or even recommend) "~" and "approx." whenever the unit is written in abbreviated or symbolic form? J IM ptalk·cont 08:36, 3 June 2008 (UTC)
 * Allowing "~" and "approx." in full sentences

Bluebox and purplebox location

 * Locations of blue and purple boxes may be debated here, but please debate their content on the appropriate talk section.Headbomb (ταλκ · κοντριβς) 14:29, 22 May 2008 (UTC)


 * Does this scientific notation discussion belong in this section? It's worth discussing, certainly, just not here.  Scientific notation is a means of expressing numbers be they attached to units of measurement or not.  MOSNUM is the place for this but it should be moved to a different section. J IM ptalk·cont 01:40, 21 May 2008 (UTC)

Gram vs. Kilogram calorie

 * Can we strike this bullet: Use small calorie or large calorie (also known as gram calorie or kilogram calorie) rather than just calorie.? Three-fifths of the links go nowhere and it seems (to me) out of place with the other bullets. &mdash; MJC detroit  (yak) 02:48, 21 May 2008 (UTC)


 * Update: Someone added redirects to the 3 dead-links above. &mdash; MJC detroit  (yak) 12:03, 21 May 2008 (UTC)


 * I made the redirect pages, but I don't care if the wikilinks are removed. In fact it would probably be best to remove them since they all direct to the calorie page anyway.Headbomb (ταλκ · κοντριβς) 14:55, 21 May 2008 (UTC)

The dinosaur units are rarely used outside of food energy discussion where it's the big calorie refered to. Can we not just drop the example altogether? J IM ptalk·cont 01:28, 28 May 2008 (UTC)


 * Fine with me. I guess I thought they were more widespread in use than they really are. Headbomb (ταλκ · κοντριβς) 01:37, 28 May 2008 (UTC)

Referring to talk pages—Relevant to section 4?
Unnecessarily redundant or not?


 * Unnecessarily redundant I reckon. J IM ptalk·cont 01:22, 28 May 2008 (UTC)

}}

Follow Current Literature (Redbox)
{{hidden |headercss=background:#E9FFEF; border:1px 1px solid #96FFA8; |contentcss=border:1px 1px solid #96FFA8;|header= Redbox|content=

FCL Summary
The objective of technical writing is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. Wikipedia generally prefers international systems of measurement, such as the SI, over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, editors should write “He was 1.83 meters (6 foot) tall”, not the reverse. However, wherever a discipline has an English-language, world-wide practice of consistently using its own terminology, units, and symbols—either conventional or non-SI metric—editors should follow those practices so readers can readily converse with those knowledgeable in the discipline. For articles that cover several disciplines, which use diverse units, find units shared by all the disciplines; failing that, use SI units. For guidance, look towards current literature for any given subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, and number notation typically employed in reliable periodicals directed to a similar readership.

The following section could be summarize into 3 bullets. In order of importance, they are:
 * Unambiguousness: Do not write so you can be understood, write so you cannot be misunderstood.
 * Familiarity: The less one has to look up for definitions, the easier it is to be understood.
 * International scope: Wikipedia is not country-specific, unless tackling region-specific topics, use international units.

If you have trouble balancing these three bullets, head on talk pages to consult other editors and try to reach consensus. }}

Figure of Merit—FCL (Redbox)
{{hidden |headercss=background:#E9FFEF; border:1px 1px solid #96FFA8; |contentcss=border:1px 1px solid #96FFA8;|header= Vote and vote comments |content=

5 - Redbox is a must have addition to the greenbox, it is as if a benevolent deity (which I may or may not believe in) came down on earth and wrote it for us. Anyone who disagrees is a retard. 4 - Redbox is a great addition to the greenbox. While I have some minor concerns, it addresses all of my major concern in a satisfactory way. I can fathom that there is a possibility that someone comes along with a new way of doing things that might be better than this one, but this is good enough for me. 3 - Redbox is a good addition to the greenbox. However, I still have some major concerns that are not addresses by this version of the redbox. Someone needs to comes along with a better way of doing things before I can say I'm comfortable with things. 2 - Redbox is a bad addition to the greenbox. I have some severe objections to this version of the redbox. Someone needs to comes along with a better way of doing things before being I can say I'm comfortable with things. 1 - Redbox is a deeply flawed addition to the greenbox. I have some nearly irreconcilable objections to this version of the redbox. Someone needs to comes along with a better way of doing things before being saying that I am even remotely comfortable with things. 0 - Redbox is the the pinnacle of counter-productiveness that all trolls strive for. It's as if the authors wrote it with the goal of maximizing the ill-effects that would ensue if people are retarded enough to adopt this version of things. Anyone who disagrees is a retard.

Vote Comments
}}

Discussion
{{hidden |headercss=background:#E9FFEF; border:1px 1px solid #96FFA8; |contentcss=border:1px 1px solid #96FFA8;|header= Discussion of redbox |content=
 * Comments goes here.


 * It's really hard to know what text each editor's vote applies to when the text changes so radically. And clearly, the below bullet points don't have the foggiest relationship to the basic principle of following current literature whenever a given discipline consistently uses other units of measure. The below voting should be considered at this juncture as applying to the above text and its related tweaks. Greg L (talk) 21:50, 5 June 2008 (UTC)


 * Subbullet 1 of Bullet 1 of greenbox specifically addresses this. It's been nearly two weeks since I first asked you how that principle was not covered by
 * {{blockquote|text=Since some disciplines uses units not approved by the BIPM, or may format them in a way that differs from BIPM-prescribed format, when such units are normally used by a clear majority of relevant sources articles related to those disciplines should reflect this (e.g., using cc in automotive articles and not cm3). Such use of non-standard units are always linked on first use.}}


 * and you still did not give an answer. Headbomb (ταλκ · κοντριβς) 21:59, 5 June 2008 (UTC)


 * I didn't see that. I need to ponder this some more. I might allow Fnagaton to vote on my behalf if that text stays. Greg L (talk) 22:32, 5 June 2008 (UTC)


 * Votes prior to today were made for the FCL redbox(Greg L[4], Fganaton[4], Headbomb[1], Jimp[1], Woodstone[1]). Votes from today and onwards were made for the Summary redbox (Headbomb [4], Pyrotec[4]).

The objective of technical writing

 * "The objective of technical writing is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere."


 * MOSNUM is a guideline not a lecture on technical writing. This is waffle. J IM ptalk·cont 04:28, 2 June 2008 (UTC)


 * And if it were, it would not belong in the section on units of measurement as it is a general statement about writing style. Moreover, the "juice" of this point is already covered by bullet 1 and 2 of the greenbox. Headbomb (ταλκ · κοντριβς) 04:39, 2 June 2008 (UTC)

Where a discipline uses its own terminology

 * "However, wherever a discipline has an English-language, world-wide practice of consistently using its own terminology, units, and symbols—either conventional or non-SI metric—editors should follow those practices so readers can readily converse with those knowledgeable in the discipline."


 * Whilst the point has some validity a balance should be made with other factors such as consistency across WP and the use of familiar terms, units, symbols, etc. Furthermore we should take care not to imply that conversions are ruled out if they happen not to appear in this literature.  Finally we could see disputes as to what constitutes a discipline. J IM ptalk·cont 04:28, 2 June 2008 (UTC)


 * Already addressed by the 1rst bullet (and sub-bullet). This is redundant and wording is inferior. Headbomb (ταλκ · κοντριβς) 05:19, 2 June 2008 (UTC)

The current literature for a subject and level

 * "For guidance, look towards current literature for any given subject and level of technicality."


 * Are we going to have disputes as to what constitutes "the literature" or what the "subject" or "level" are exactly? Who's read all the literature?  Would it not be more straight-forward to rely on an article's sources? J IM ptalk·cont 04:28, 2 June 2008 (UTC)


 * Already addressed by the 2nd bullet (and sub-bullet). This is redundant and wording is inferior. Headbomb (ταλκ · κοντριβς) 05:19, 2 June 2008 (UTC)


 * Using the articles sources is a terrible idea. Not all editors have easy access to all the sources. The sources may be outdated. The law may have changed since the sources were written; the units used in the sources might be illegal today. The units used in the article might have to be changed if someone adds several new sources. People with an axe to grind could stack the reference list so that their favorite unit is in the majority. --Gerry Ashton (talk) 17:16, 2 June 2008 (UTC)


 * Potential reference stacking is a serious flaw, yes. It is also true that not all editors have easy access to the sources but how do you write an article without them?  If I measure something in cubic cubits and a decade later cubic cubits are outlawed, my original measurement was still in cubic cubits shouldn't this fact be recognised? J IM ptalk·cont 17:58, 2 June 2008 (UTC)

When in doubt

 * "When in doubt, use the units of measure, prefixes, unit symbols, and number notation typically employed in reliable periodicals directed to a similar readership."


 * How do we judge this readership? Do the units of measure used in these reliable periodicals trump those used in the article's sources?  What happens in the case where these prefixes and unit symbols are unfamiliar, ambiguous or confusing?  Is this the end of any hope for a reasonable degree of consistancy with respect to the use of symbols/abbreviations across WP? J IM ptalk·cont 04:28, 2 June 2008 (UTC)


 * Already addressed by the 1rst bullet (and sub-bullet) and 2nd bullet. This is redundant and wording is inferior. Headbomb (ταλκ · κοντριβς) 05:19, 2 June 2008 (UTC)

Need for explicit Follow Current Literature subsection

 * Follow the sources, with perhaps a note about the rare case in which 'the sources are demonstrably unrepresentative of the literature on the subject? Septentrionalis PMAnderson 15:59, 21 May 2008 (UTC)


 * Don't attempt to follow this "literature". Follow your sources.  An explicite subsection?  I don't think we need it with the form no under discussion. J IM ptalk·cont 01:26, 28 May 2008 (UTC)


 * What? Headbomb (ταλκ · κοντριβς) 04:52, 28 May 2008 (UTC)


 * Sorry, a typo, now fixed in red. As discussed above this whole idea of pointing to "the literature" is sure-fire recipe for strife.  Where does this literature begin, where does it end?  Is that peice of literature relavant to this article?  Do we regard only academic pubilcations, do we consider newspaper articles?  How wide, how narrow is our scope?  Has anyone read all "the literature"?  What we can point to in relatively black & white terms are the sources for a particular article.  Indeed, if I'm not mistaken, Fnagaton once expressed that his idea of "the literature" was just that (at odds with mine). If your sources use the imperial system, use those units as the primary units and convert to metric (& US customary where needed).  I'd even go so far as saying that even if the sources are demonstrably unrepresentative of the literature on the subject (assuming that we've been able to pin that "literature" down after all), we can still follow those unrepresentative sources.  For example, if our article on some Albertan oil well gets its information from some source which gives oil volumes in cubic metres, we should not give barrels as the primary unit, we should give the original cubic-metre values first with the barrel conversions in brackets. Just follow the sources, damn simple.  That way we can even forget about that US-related and UK-related clause as well.  By nature, the sources for a US-related article will generally be based in the US customary system.  Follow the sources and the US-customary system is the primary system for the article.  Similarly with UK-related articles.  Indeed this catches stuff like pre-metrication-Australia/Canada/etc.-related articles too.  Clear-cut & to-the-point a simple rule such as this might not fill a whole section.  J IM ptalk·cont 05:31, 28 May 2008 (UTC)


 * These arguments over “how does one ‘define’ current literature” and its scope doesn’t hold water. If Wikipedia has run off doing its own thing (again) and isn’t following the practices observed in current literature on that subject, that’s a sure-fire warning sign that something’s wrong here. Greg L (talk) 01:16, 1 June 2008 (UTC)


 * You claim that the argument does not hold water, Greg, but you don't follow that up with a counter-argument explaining why they don't hold water. The point under discussion here is how one determines that "current literature on that subject" for if we can't pin that down, there's no determining whether or not WP is following it or running "off doing its own thing". J IM ptalk·cont 17:31, 1 June 2008 (UTC)


 * I still don't see how FCL adds to the MOS. Commonly used units inside a discipline is already covered (Which unit to use, bullet 1, sub-bullet 1). Level of technicality is already covered (Which unit to use, bullet 2). Familiarity is already covered (Which unit to use, bullet 2). It's a bunch of fat.Headbomb (ταλκ · κοντριβς) 05:20, 1 June 2008 (UTC)


 * I find the last minute insertion of the FCL section highly irregular in this far progressed stage of building agreement. I revoke my vote. &minus;Woodstone (talk) 10:13, 1 June 2008 (UTC)


 * I also find it very irregular. I'll vote a 3 (I'll update later) if Greg cannot justify the inclusion of FCL.Headbomb (ταλκ · κοντριβς) 14:00, 1 June 2008 (UTC)


 * All: I’ve seen editors argue against FCL by stating that it is impossibly difficult to determine “who the readership is”, or the “level of difficulty”, or “what constitutes current literature.” Yet all these issues are the basic elements of authorship and technical writing. If you are editing a Wikipedia article on a technically oriented topic, such as Parts-per notation (to which one might link an instance of “parts per billion”), then the use of scientific notation is perfectly appropriate. However, far too many editors—not necessarily those participating here—employ scientific notation because they smitten with the power and beauty of scientific notation. But any quick look at Encyclopedia Britannica would reveal that general-interest articles don’t employ such techniques unless it is absolutely necessary to do so. One would also find that scientific notation isn’t typically used in PC World to disambiguate big quantities of bytes. Yet, that is a technique that seems to be advocated by some here on Wikipedia. If editors don’t understand why this is the case, perhaps they need to spend more time reading current literature to understand who it is we’re really trying to communicate to: another Wikipedia editor with whom we’re debating an issue, or some typical computer user who never had an occasion to use scientific notation since their school days and forgot how it works decades ago. As for demonstrating that it is easy to determine what constitutes current literature (and the counter-argument that this is impossibly difficult task), that’s simple. First, we apply common sense. FCL says “ Wherever a discipline consistently uses its own terminology, units, and symbols…”. Let’s take an obvious example: computer-related subjects. Whether you want to call it “balkanization of units” or “decay of modern society”, we do no good whatsoever by ignoring current literature on that subject and using using unfamiliar terminology like “gibibytes” rather than the infinitely more familiar “gigabytes”. It isn’t hard to figure out that virtually unused terms like “gibibytes” are only used when writing for highly advanced programmers and software developers. It’s also not hard to figure out what a “general-interest readership” is. If it’s really hard to figure out what “current literature” is for computer-related subjects, then you look towards reliable periodicals like PC World and Mac World. That’s what FCL calls for. If one follows FCL and looks to reliable periodicals, one would quickly find what is the proper units to use so as to not confuse readers coming to Wikipedia. Another example where FCL is of great facility in resolving dispute is in an example Headbomb participated in recently. It was over whether angstroms should be used in discussing U.V. spectroscopy instead of nanometers. As Headbomb saw firsthand, simply looking towards current literature demonstrated that there was no consistent practice; it was more complex. That made a believer (at least at that time) of Headbomb. MOSNUM can’t possibly have a specific rule for every conceivable unit of measure. Many conflicts would have—and will be—settled by simply following FCL’s guiding principle. It is not Wikipedia editors’ role to debate the virtues and shortcomings of units of measure in wide use on subjects; it is our job to follow the practices widely observed in current literature so readers don’t have a WTF?!? reaction when they land here. Anything else just amounts to a minority subset of editors who fancy themselves as cadet members of the BIPM and the IEC (and any other standards organization that comes up with a good idea) hijacking Wikipedia to help promote the adoption of some new standard. In case any of us here haven’t figured it out yet, that is not a suitable role for any contributing Wikipedia editor. Greg L (talk) 19:53, 1 June 2008 (UTC)

P.S. to Woodstone: The proper reaction to my taking the time to give a full response to all your comments isn’t to seemingly react as if “I don’t like his response” and fly off and strike the text with an edit summary of “remove undiscussed addition”. In case you haven’t noticed, 1) over a dozen editors had a hand in crafting FCL, 2) Elements of FCL had originally been in the greenbox but very, very, slowly (incrementally) got erroded until nothing was left of the basic principle, 3) we’re discussing it here and haven’t provided nearly enough time for its effect on votes to become clear and for sufficient discussion to occur. Who do you think you are? In case you haven’t noticed, this is a collaborative writing environment. I’ve pretty much kept my hand off the greenbox the entire time it was crafted. This is my contribution to it now; something that over a dozen editors worked on, liked a great deal, and voted on. Just how about we give it a try for more than the god-damned 18 hours you seem to be willing to give it? Huh? 20:52, 1 June 2008 (UTC)


 * The FCL section in its current form creates an inherent conflict with the principle of using consistent primary units throughout an article. Since SI units are the world standard, it follows that every discipline that uses non-SI units is a niche. Inevitably some articles will be wider in scope than any of these niches. The FCL section could have been worded to make it clear that it only applies when the topic of the article fits entirely within one of the niches, but it was not so worded. --Gerry Ashton (talk) 20:45, 1 June 2008 (UTC)


 * To Gerry: Good point. Let me think about it. I’m too pissed off with Woodstone to do much good right now. Greg L (talk) 20:52, 1 June 2008 (UTC)


 * Clarify for me Gerry: In your opinion, if a Wikipedia article, like “World energy production”, wherein a variety of power sources were being discussed, should “barrels” of oil not be the primary measure when one gets to the portion of the article that discusses the production of crude oil? Greg L (talk) 21:51, 1 June 2008 (UTC)


 * If I were writing an article on world energy production, I would try to find several articles in reliable sources that give just such an overview. If all or most of the external sources agreed on what units to use, I would follow suit. In the absence of any agreement, I would use an SI unit, such as terrawatts, or terajoules for a particular recent year. I would give conversions to appropriate units for each sub-topic, such as barrels per year for crude oil, tonnes per year for coal, etc. However, only reliable sources that were addressing all forms of energy would count in deciding what primary units are appropriate. The fact that sources that limit themselves to petroleum use barrels would be of no consequence. --Gerry Ashton (talk) 23:12, 1 June 2008 (UTC)


 * I tried to use examples in the posted version of FCL that had the dual virtues of 1) being a true reflection of real-world usage as measured by looking at current literature, and 2) happen also to be exactly how Wikipedia’s articles handled it. The FCL fragment in the greenbox doesn’t address details like conversions. Note that, World_energy_production uses barrels of oil and includes a conversion to cubic meters; the conversion is fine by me. I’ve tweaked the greenbox FCL wording to show a clear preference for the SI, and how one follows current literature in its diversion from that only when an discipline consistently does otherwise. Examples that come to mind are “barrels of oil” and “megabytes of RAM”. I can’t think of a single example where a discipline might consistently (or universally) use non-SI units of measure and Wikipedia shouldn’t follow the practice. Do you? Let me know what you think of the greenbox FCL now. Greg L (talk) 00:02, 2 June 2008 (UTC)


 * I think Greg's most recent revision is too repetitive with the "Which units to use" section, and does not squarely address the issue. I suggest this (new part underlined):


 * The objective of technical writing is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. Wherever a discipline consistently uses its own terminology, units, and symbols—either conventional or non-SI metric—editors should follow those practices so readers can readily converse with those knowledgeable in the discipline. For articles that cover several disciplines, which use diverse units, find units shared by all the disciplines; failing that, use SI units. For guidance, look towards current literature for any given subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation typically employed in reliable periodicals directed to a similar readership.
 * --Gerry Ashton (talk) 00:32, 2 June 2008 (UTC)


 * unindented


 * Gerry, I don’t think I have a problem with that addition whatsoever. It would be helpful in understanding the effect of this, if you could provide an example article where a specific discipline would use its own, non-SI units (and where Wikipedia would follow that practice), but where a larger discussion would not? I can think of only one off the top of my head. I don’t know of any specific articles to cite, but, hypothetically, it would be where the topic of U.V. spectroscopy on the Hubble Space Telescope is apparently always discussed in terms of angstroms (to measure wavelength). So  if  Wikipedia were to have an article dedicated exclusively to this topic (I don’t know of one), then, as I see it, Wikipedia should follow observe that practice (all the cited scientific papers would be using angstroms). However, in an article on color and spectroscopy in general—where the U.V. portion would just be part of a larger topic—we should use nanometers. This makes gobs of sense to me. Is this the issue you’re addressing? If so, do you have a specific example with actual articles you could share? Greg L (talk) 01:19, 2 June 2008 (UTC)


 * Consider articles about engines. If the article was limited to American automobiles of the 1960s, cubic inches would be the primary unit. If it was about automobile engines in general, cubic centimeters (abbreviated cc. if necessary) would be an appropriate primary unit. If the article was about internal combustion engines of all types, from model airplanes to supertankers, cubic centimeters (symbolized as cm3 if necessary) might be the most appropriate primary unit. --Gerry Ashton (talk) 01:28, 2 June 2008 (UTC)

Insisting that the SI unit (or some compatible metric unit) be included (at least as a parenthetical conversion) is nothing akin to abusing WP to promote the SI. It is merely ensuring that our articles are comprehensible to those who think in metric ... and we do exist. Assuming that all the literature on crude used barrels exclusively never converting to metric, should we just follow suit? Why should we not have articles make sense to those who don't think in barrels? As for the arugment that no-one can grasp a million cubic metres anyway ... 1 E+6 m³‎ is a good place to start ... that's a small lake. Do we have a 1 E+8 bbl article? Of course, it's not so black and white with crude ... there might be some literature out there using metric. Greg writes "the conversion is fine by me". Good to hear, this seems to me a bit of a change in tune but never mind. So conversions are fine & yes, they're quite common on WP at present. The allow us to put the conversion back into the example on FCL. Don't make it contingent on the unrelated issue of the presence of a "disputed" tag. That particular part of FCL "doesn’t address details like conversions", no, but we've argued that it should exemplify then lest it imply that they be proscribed. J IM ptalk·cont 01:14, 2 June 2008 (UTC)

}}
 * Jimp: I don’t understand why you are making hay about conversions. This new min-treatment of FCL doesn’t touch on the subject. The greenbox has a comprehensive treatment of conversions. I don’t perceive the need to even begin touching on conversions in FCL, it will just keep on getting bloated with overlapping turf. OK, now fixed. It no longer touches upon conversions. Happy? Greg L (talk) 01:27, 2 June 2008 (UTC)

Scientific notation and uncertainty (Bluebox)
{{hidden |headercss=background:#E9FFEF; border:1px 1px solid #96FFA8; |contentcss=border:1px 1px solid #96FFA8;|header=Bluebox |content=

Notations

 * Scientific notation is done in the format of 1 leading digit/decimal marker/rest of digits/×10n, where n is the integer that gives one leading digit.
 * $1.602$ is a proper use of scientific notation.
 * $160.2$ is not a proper use of scientific notation.


 * Engineering notation is done in the format of leading digits/decimal marker/rest of digits/×10n, where n is a multiple of 3. The number of leading digits is adjusted accordingly.
 * $132.23$ is a proper use of engineering notation.
 * $1.322$ is a not proper use of engineering notation.


 * When using either scientific or engineering notation in articles, consistency is preferred (e.g., do not write "A $2.23 m$ region covered by $234 grains of sand$".
 * Use discretion when it comes to using scientific and engineering notation. Not all values need to be written in it (e.g., do not write "the house is $1.25 y$ old", but rather "the house is 125 years old").
 * Sometimes it is useful to compare values with the same power of 10 (often in tables) and scientific or engineering notation might not be appropriate.

Uncertainty

 * Uncertainties can be written in various ways:
 * Value/±/uncertainty/×/10n/unit symbol (e.g. $1.534 m$
 * Do not group value and uncertainty in parenthesis before the multiplier (e.g. do not write (15.34±0.35) × 1023 m)
 * Value/superscript positive uncertainty/subscript negative uncertainty/×/10n/unit symbol (e.g. $15.34 m$)
 * Value(uncertainty in the last digits)/×/10n/unit symbol (e.g. $1.604 J$)
 * Value/±/relative uncertainty(percent)/unit symbol (e.g 12.34±5% m2)
 * Spacing rules go here.

}}
 * Delimitation rules go here. (Do we follow NIST and scientific guidelines or do we follow the current MOS rules for delimitation?)
 * val is meant to be used to automatically handle all of this, but currently has some severe issues (see Talk:val). Use with great consideration and always check that it will give the correct results before using it.

Figure of Merit—Scientific notation and uncertainty (Bluebox)
{{hidden |headercss=background:#E9FFEF; border:1px 1px solid #96FFA8; |contentcss=border:1px 1px solid #96FFA8;|header=Vote and vote comments|content=

5 - Bluebox is perfect, it is as if a benevolent deity (which I may or may not believe in) came down on earth and gave us this version of MOSNUM. Anyone who disagrees is a retard. 4 - Bluebox is a vast improvement over the nothing current section 4 of MOSNUM offers. While I have some minor concerns, it addresses all of my major concern in a satisfactory way. I can fathom that there is a possibility that someone comes along with a new way of doing things that might be better than this one, but this is good enough for me. 3 - Bluebox is a improvement over the nothing current section 4 of MOSNUM offers. However, I still have some major concerns that were are not addresses by this version of the bluebox. Someone needs to comes along with a better way of doing things before I can say I'm comfortable with things. 2 - Bluebox is an downgrade over the current nothing section 4 of MOSNUM offers. I have some severe objections to this version of the bluebox. Someone needs to comes along with a better way of doing things before being I can say I'm comfortable with things. 1 - Bluebox is a severe downgrade over the current nothing section 4 of MOSNUM offers. I have some nearly irreconcilable objections to this version of the bluebox. Someone needs to comes along with a better way of doing things before being saying that I am even remotely comfortable with things. 0 - Bluebox is the the pinnacle of counter-productiveness that all trolls strive for. It's as if the authors wrote it with the goal of maximizing the ill-effects that would ensue if people are retarded enough to adopt this version of things. Anyone who disagrees is a retard.

Discussion of “Vote Comments”

 * Rebuttal and discussion goes here.

}}

IEC Prefixes (Purplebox)
{{hidden |headercss=background:#E9FFEF; border:1px 1px solid #96FFA8; |contentcss=border:1px 1px solid #96FFA8;|header= Purplebox|content=

Historical background
When measuring bits and bytes, there are two different de facto standards for defining the symbols "k" (often written "K"), "M", and "G": one follows the International System of Units (SI) prefixes convention using powers of 1000 (103); the other uses powers of 1024 (210). The use of the prefixes "K", "M", "G",... to represent both decimal and binary values of computer memory originates from earliest days of computing. In 1986, the Institute of Electrical and Electronics Engineers (IEEE) and the American National Standards Institute (ANSI) formally ratified the binary usage, making units of measure such as “kilobyte” officially mean 1024 (210) bytes, “megabyte” to mean 10242 (220) bytes, etc. However, these prefixed forms of the byte and bit were still ambiguous because the IEEE/ANSI resolution failed to reverse the practice of taking the same unit symbols (KB, MB, GB, etc.) to mean decimal values for hard-drive capacities.

In an effort to resolve this ambiguity, the International Electrotechnical Commission (IEC) introduced distinct binary prefixes in 1998. Kibi-, mebi-, gibi- (symbols "Ki", "Mi", "Gi",...) to replace kilo-, mega-, giga. These would exclusively mean powers of 2. In 2005, the IEEE adopted the IEC proposal after a two-year trial, thus reversing its previous position. While the IEC proposal has seen a gradual adoption in the scientific literature, virtually all general-interest computer publications (both online and print), computer manufacturers, and software companies continue to follow the long-held practice in which SI-prefixed versions of byte and bit have the binary meanings for solid-state memory, and the decimal meanings for most spinning-disk mass storage. Consequently, the IEC-prefixed forms of the byte and bit, such as "kibibyte" and "mebibyte", and their unit symbols ("KiB" and "MiB") are unfamiliar to the typical Wikipedia reader.

MoS convention
After many years of debate, it was agreed that the prefixes "K", "M", "G",... although familiar, were ambiguous for quantities of bits and bytes. It was also agreed that IEC prefixes, while not ambiguous, were rarely used and therefore unfamiliar. Consensus was reached that the spirit of the MoS was better reflected by having familiar but ambiguous units, rather than unambiguous but unfamiliar units.


 * Editors should use the conventional prefixes, such as "kilobyte (KB)" and "megabyte (MB)", and disambiguate where necessary.
 * Editors should specify if the binary or decimal meanings of "K", "M", "G",... are intended as the primary meaning. Consistency within each article is desirable, but the need for consistency may be balanced with other considerations.
 * The definition most relevant to the article should be chosen as primary one for that article (e.g., specify a binary definition in an article on RAM, and decimal definition in an article on hard drives).
 * Where consistency is not possible, specify wherever there is a deviation from the primary definition.


 * To avoid controversy—the IEC prefixes debate did span over many years—disambiguation should be shown in bytes or bits, clearly showing the intended base (binary or decimal). There is no preference in the way to indicate the number of bytes and bits, but there should be consistency (e.g., write "A 64 MB (64×10242 bytes) video card and a 100 GB (64×10003 bytes) harddrive", "A 64 MB (64×220 bytes) video card and a 100 GB (64×109 bytes) hard drive" or "A 64 MB (67,108,864 bytes) video card and a 100 GB (64,000,000,000 bytes) harddrive" are all acceptable, but not "A 64 MB (67,108,864 bytes) video card and a 100 GB (64×10003 bytes) hard drive"). Footnotes may be used for this purpose.
 * IEC prefixes are not to be used on Wikipedia except under the following circumstances:
 * when the article is on a topic where the majority of cited sources use the IEC prefixes,
 * when directly quoting a source that uses the IEC prefixes,
 * in articles specifically about or explicitly discussing the IEC prefixes.

}}

Figure of Merit—Binary prefixes (Purplebox)
{{hidden |headercss=background:#E9FFEF; border:1px 1px solid #96FFA8; |contentcss=border:1px 1px solid #96FFA8;|header= Vote and vote comments|content= 5 - Purplebox is perfect, it is as if a benevolent deity (which I may or may not believe in) came down on earth and gave us this version of MOSNUM. 4 - Purplebox is a vast improvement over what the current section 4 of MOSNUM offers. While I have some minor concerns, it addresses all of my major concern in a satisfactory way. I can fathom that there is a possibility that someone comes along with a new way of doing things that might be better than this one, but this is good enough for me. 3 - Purplebox is a improvement over what the current section 4 of MOSNUM offers. However, I still have some major concerns that were are not addresses by this version of the purplebox. Someone needs to comes along with a better way of doing things before I can say I'm comfortable with things. 2 - Purplebox is an downgrade over what the current section 4 of MOSNUM offers. I have some severe objections to this version of the purplebox. Someone needs to comes along with a better way of doing things before being I can say I'm comfortable with things. 1 - Purplebox is a severe downgrade over what the current section 4 of MOSNUM offers. I have some nearly irreconcilable objections to this version of the Purplebox. Someone needs to comes along with a better way of doing things before being saying that I am even remotely comfortable with things. 0 - Purplebox is the the pinnacle of counter-productiveness that all trolls strive for. It's as if the authors wrote it with the goal of maximizing the ill-effects that would ensue if people are silly enough to adopt this version of things.

Vote Comments
}}

Discussion of “Vote Comments”
{{hidden |headercss=background:#E9FFEF; border:1px 1px solid #96FFA8; |contentcss=border:1px 1px solid #96FFA8;|header= Discussion of vote comments|content=

Initial discussion

 * Rebuttal and discussion goes here.


 * To some of the above voters who complain that the “explicit ban on IEC keeps returning”. Where is your common sense? Do you really think it’s lost on professional, degreed editors who get paid to edit print encyclopedias like Encyclopedia Britannica and magazines like PC World that the conventional prefixes are ambiguous?!? To suggest otherwise is utterly preposterous. Of course they know the conventional prefixes are used two different ways depending primarily on whether the topic is transistorized RAM and cache memory, or is spinning-disk mass storage. And for many decades (since before some of the editors here were even born), the rest of the publishing industry and general-interest computer magazines have managed to get along just fine using simple disambiguations in those rare cases where extreme accuracy is required in order to discuss a point; usually, simply writing “500 GB hard drive” is close enough. Arguments that Wikipedia should be off all by itself doing its own thing with terms like “3 GiB of RAM” (while still other articles are using the well recognized “3 GB of RAM” so some readers who notice this different usage are left wondering “WTF”), make no sense whatsoever. Such arguments amount to nothing less than saying “Hell yes; I am much, much smarter than all the professional, paid editors at PC World and Encyclopedia Britannica and want Wikipedia to be “different” and use units of measure that haven’t seen any real-world adoption and are therefore totally unfamiliar to the typical reader. No. I reject such an attitude as arrogant and utter nonsense. It violates the most basic principles of technical writing. Its a damn shame that Wikipedia’s dispute-resolution process and policy-setting process allows itself to be hijacked by a vocal, extreme minorities. Like it or not, the rest of the computer and publishing world will be using the conventional binary prefixes decades from now. This three-year-old experiment where some articles on Wikipedia use the failed IEC prefixes is coming to and end. I won’t rest until I’ve done my part to help put an end to this hogwash. Greg L (talk) 20:53, 31 May 2008 (UTC)


 * I will not react to the venomous tone of the comment above, except to say that insulting people generally does not lead to convincing them, and neither does calling their given reasons utter nonsense. Now to the subject matter. There is now an explicit statement that the ambiguous units KB, MB and GB should be disambiguated by expressing the values as powers of 10 or 2 (c.q. 1000 or 1024). That should be enough. There is no need to add any statements about how to use other units (like KiB, GiB, MiB). Trying to explicitly ban them inhibits consensus, while leaving them out may lead to a consensus that they will factually not be used as disambiguation, just like you prefer. &minus;Woodstone (talk) 21:18, 31 May 2008 (UTC)


 * So what you're trying to say is that even though the guideline means "express the values as powers of 10 or 2 and don't use IEC" you don't want the guideline to specifically say "don't use IEC"? Fnagaton 21:27, 31 May 2008 (UTC) Woodstone's reply that sort of overlapped this one (see edit history) clarified his position. Fnagaton 22:02, 31 May 2008 (UTC)


 * There we go. I bound into the brush like a hunting dog to flush ‘em out, and Fnagaton swings around his ol’ 12-gauge. Greg L (talk) 21:39, 31 May 2008 (UTC)


 * Woodstone: Using ridicule to call stupid policies “utter nonsense” is “venomous”? I call it “trying to put an end to utter nonsense.” As for your statement “ There is now an explicit statement that the ambiguous units KB, MB and GB should be disambiguated by expressing the values as powers of 10 or 2 (c.q. 1000 or 1024). That should be enough. ?” I agree; it should be enough. But some editors here really, really want to keep on using the unknown IEC prefixes. You haven’t noticed that yet? I’ve seen a certain editor’s argument style and method of operation; leave him a hole big enough to slide your finger into and he’ll drive an M1 Abrams right on through. IMO, you position comes under the heading of “Well… it’s ‘pretty’ to think so.” Greg L (talk) 21:39, 31 May 2008 (UTC)


 * P.S. Woodstone: Oh, and now that the verbiage has been struck (the verbiage that explicitly detailed the limited circumstances under which using the IEC prefixes would be suitable); verbiage you say isn’t necessary because the guideline is clear enough without it, let’s see some “3” or “4” votes here then.


 * *(sound of crickets chiping)*


 * …well? Did striking the text not improve the general consensus on this section?  Greg L (talk) 22:02, 31 May 2008 (UTC)


 * Ah Hah! Apparently the wording was still air-tight and there was insufficient loophole. Thunderbird responds by reducing his vote! See the following post. Greg L (talk) 23:12, 1 June 2008 (UTC)


 * Thunderbird. I have a high sensitivity threshhold for illogical statements and utter nonsense. In your recent vote downgrade from a “3” to a “2”, you wrote “The IEC deprecation is still there. It is subtle, but it is completely unnecessary and does not reflect consensus .” (my emphasis). Why do your arguments rely so much on breathtaking displays of non-factual tripe? “Does not reflect consensus”? By my count, there are two votes up there that could be considered as “oppose” votes and one of them is yours. So your comment about the current state of whether there is a consensus or not is actually self-referential. We (might) not have consensus only because you made it so . So why not stop acting like you are making your vote the way you did because there is some sort of army of like-minded edtiors who share your views on this matter? There isn’t. You can’t cite one damned high-circulation, general-interest publication in the world that uses the IEC prefixes other than Wikipedia. Give it up. Whether today or next month, the battle has been lost. No one but a handful of fringe advocates think Wikipedia’s continued use of the IEC prefixes is a good idea. Greg L (talk) 22:37, 1 June 2008 (UTC)

Further discussion I

 * P.S. Fnagaton and I were wondering if the purplebox had been neutered to the extent that the use of IEC prefixes could possibly be interpreted as still being permitted. Thank you. You’ve clarified for us that, even with its struck text, it still called for no longer routinely using the IEC prefixes. That you perceived this to still be the case, and finally resorted to trying the tactic of reducing your vote, makes it clear as glass that you full-well intend to continue to use the IEC prefixes. You’ve tried everything in your power to do keep on using these weird units of measure, including torpedoing Mac Pro with an purposely inept, half-hearted attempt to rewrite it without the IEC prefixes. Don’t give me any of your self-righteous indignation about how that is a “venomous personal attack”; you are an experienced editor and the end result clearly proves that you accomplished exactly what you set out to do: “prove” how cumbersome it is to disambiguate a page without the IEC prefixes. It took me a half-hour to clean up the article and make it clear as glass using conventional techniques that readers have seen a hundred times before. In light of the fact that you’ve revealed your true spots, I’ve restored the previously struck text which declares all the circumstances under which it is permissible to use the IEC prefixes. Perhaps this will bring back the “3” vote from you. I really do wish you’d stop waiving your hands in the air, playing a logical game of “you can’t catch me”, and just admitted that you really intend on fully messing up Wikipedia with even more of these units of measure that even you agreed are not widely recognized by the typical Wikipedia reader. Greg L (talk) 23:08, 1 June 2008 (UTC)


 * Woodstone changed his vote from a 2 to a 4. TB2 changed his vote on the exact same text from a 3 to a 2 once he noticed Woodstone changed his vote from 2 to 4. Then TB2 writes something about "deprecation still being there" despite the comments and vote from Woodstone showing the contrary. TB2's vote movements are not consistent with logic or any reasonable argument, as such TB2's vote can be ignored. Fnagaton 23:15, 1 June 2008 (UTC)


 * Since Fnagaton feels free to ignore votes Fnagaton does not like, I feel free to ignore each and every attempt by Fnagaton to count any vote, or any attempt by Fnagton to assess whether or not consensus exists. --Gerry Ashton (talk) 23:27, 1 June 2008 (UTC)


 * Read what I posted again because "does not like" (as you used the phrase) is irrelevant. The point is TB2's vote changes downward when Woodstone's vote improves, TB2's vote changing is not logical. Since TB2 has not answered Headbomb's question the principle here is that unsubstantiated objections may be disregarded/ignored. Fnagaton 23:33, 1 June 2008 (UTC)


 * Fnagaton: T-bird’s vote should be ignored as far as trying to get the measure of the proper consensus here. “Consensus” has never been 100% of the editors being in complete agreement. When “oppose” elements resort to nonsense and diversionary tactics because they know a truthful admission of their real agenda would be soundly rejected, their votes should no longer be considered as carrying nearly as much weight as those who debated here in good faith, read other editors’ arguments, responded appropriately, and tried to craft compromise wording in order to build understanding and consensus. That’s all hard work and is damned time consuming. However, I think all of Thunderbird’s arguments and behavior shouldn’t truly be “ignored”, they should be spotlighted in neon lights for all to see how not to conduct ones self here . Gerry: After reading your above post, I’m not sure what you intend to do now with your vote. I ask that we all argue and vote in good faith and not react to frustrated writings of others with equally frustrated votes. I really want to know how everyone here feels about this issue. All I’ve wanted in the purplebox is unambiguous text so we all clearly know what the effect of the purplebox would be. I see trying to make it ambiguous so editors can do whatever the hell they want is just a continuation of the same old shit that has gone on for three years now; that’s no good whatsoever and must end. Greg L (talk) 23:35, 1 June 2008 (UTC)


 * Exactly. A good example of debating with good faith and responding to questions would be Woodstone's honest answers, even when those answers might be something he doesn't particularly like he was still honest and gave good answers that helped to improve the text. On the other hand we have the example shown by TB2 where difficult questions (looking at Headbomb's question here) are ignored and instead makes changes to the text that have little chance of support. As demonstrated with my discussions with Woodstone I have all the patience and time in the world for someone who is being honest and debating in good faith. TB2 has just demonstrated he is not following the good example shown by Woodstone, I have no patience for people who are just going to waste other people's time. Fnagaton 23:45, 1 June 2008 (UTC)


 *  I motion that the purplebox has been tweaked to the point of maximum consensus and is ready to be incorporated into the greenbox. The remaining holdouts have hardened positions that are unlikely to change with further debate. “Consensus” is not 100% of the editors being in complete agreement and never has been. I think it is clear that the consensus is that the current contents of the purplebox, while still able to benefit from further tweaking, is good enough at this time. Greg L (talk) 00:13, 2 June 2008 (UTC)


 * I see that you two are at it again. Did you ever think of asking me what my objections were before your accusations of bad faith?  I can think of a few good editors who, following similar accusations, no longer feel comfortable contributing on this page.  And judging from the inflammatory tone of the above remarks who can blame them?
 * You know perfectly well what is required to gain my support because I have repeated it many times: just avoid deprecation of IEC prefixes. There is no need for it and, more importantly, no consensus for it.
 * Fnagaton: No, by "consensus" I do not mean "my opinion", which by itself is unimportant, just as yours is. I'm talking about the opinion of a wide range of editors in this recent archive.
 * Greg L: It makes sense for MOSNUM to make unambiguous statements where there is consensus for them. Where there is less consensus there is a need for a little ambiguity. Where there is no consensus, silence is the best option.
 * Both: Headbomb has worked hard on this. Please show some respect for his efforts, concentrate on the issues, and try to move towards consensus.
 * Thunderbird2 (talk) 21:17, 2 June 2008 (UTC)


 * Numerous times by many editors your exact objections have been sought and you consistently dodged the questions put to you. Yes you do mean in your opinion because the link you cited does not support what you have been writing, when you read the whole archive and consider all points instead of picking one or two votes in isolation. Consensus is clearly against your point of view, this is because the consensus is that IEC are not to be used because better methods exist that do have consensus and as Woodstone wrote above it is obvious that is what the guideline means. You voted a 2 when Woodstone voted a 4, this demonstrates how your votes are illogical as already explained above. I also note, again, that you have not answered Headbomb's question. The fact that you keep on avoiding the question shows that you do not respect Headbomb's hard work. Since you do not respect Headbomb's hard work and since you have not provided any valid reasoning then, as Headbomb wrote, your unsubstantiated objections may be disregarded/ignored. Fnagaton 22:04, 2 June 2008 (UTC)

Further discussion II

 * Fnagaton, this is getting beyond a joke. I am running out of patience, but I will make one more attempt at reasoning with you and would appreciate your responding in kind: I see no contributions from Headbomb in the above exchange - What question are you talking about? Thunderbird2 (talk) 22:33, 2 June 2008 (UTC)


 * As shown by Woodstone's honest replies and debate the problem is not with reasoning with me, I am perfectly fine reasoning with Woodstone because he shows good faith, so don't try to insinuate otherwise. The problem is that you have still not answered Headbomb's question at "22:09, 31 May 2008 (UTC)". Fnagaton 22:54, 2 June 2008 (UTC)


 * This is getting surreal. Are you now implying I am somehow dishonest because I did not reply to Headbomb's question to Woodstone? Thunderbird2 (talk) 15:17, 3 June 2008 (UTC)

Further discussion III

 * It is dishonest to claim the question is only to Woodstone because the question contains Woodstone's name and yours, which is still on 31 May and still located in the post I pointed out to you with the time shown as "'22:09, 31 May 2008 (UTC)" . Fnagaton' 15:30, 3 June 2008 (UTC)


 * That edit was made at 23:27, not 22:09. I will read the question when you withdraw your accusation of dishonesty. Thunderbird2 (talk) 22:37, 3 June 2008 (UTC)


 * At time "15:17, 3 June 2008 (UTC)" you claimed the question was only to Woodstone, that is not true. This is the revision at that time. On that revision search for the time index ("22:09, 31 May 2008 (UTC)") I told you to look for and look for Headbomb's comment. Now I quote the first three words of that post and what we see is this "Woodstone or Thunderbird,". Therefore at the time you made your post it is dishonest to claim the question is only to Woodstone. So, are you going to answer Headbomb's question? Fnagaton 22:50, 3 June 2008 (UTC)


 * I'm not interested in petty bickering, but if you're not going to read what other people write because someone else called you dishonest, then your voice lose any weight and all it carried since you aren't interesting in addressing the concerns of others. Headbomb (ταλκ · κοντριβς) 22:55, 3 June 2008 (UTC)


 * Headbomb, I am trying to help here, but Fnagaton's accusation is a personal attack, which I feel no obligation to respond to. It is up to him to withdraw it. Thunderbird2 (talk) 23:14, 3 June 2008 (UTC)


 * Claiming something that is then proven to not be true at the time it was written is dishonest. Why would I withdraw a word ("dishonest") that you first used with regards to yourself? Easily proven since if you look at the revision of this page and do a search for "dishonest" then only you used that word first. You tried to accuse me of using the word "dishonest" when before then I had not used the word "dishonest" at all, so you only have yourself to blame because you have been proven to have written something that is not true. If you are really interested in helping then answer Headbomb's question and you can also retract your untrue claim and accusation you made at "15:17, 3 June 2008 (UTC)". Fnagaton 23:27, 3 June 2008 (UTC)


 * Fact: Thunderbird2 asked for me to write concessions on FCL’s wording when he wrote “ The point about the uno is that by putting it alongside the IEC prefix you are tarring both with the same brush. In other words, the wording (last time I checked) gives the impression that the MiB is an equally pointless unit. To gain my support you need to make clear that the MiB does have a valuable role to play ” (my emphasis). So I did exactly as Thunderbird2 asked; I deleted any mention of the uno, and I added wording that the IEC prefixes was a meritorious proposal of the IEC. What was did Thunderbird2 really do in response? Fact: He voted against it. Then I see what he did with Mac Pro to “prove” how cumbersome it is to disambiguate articles without being able to use the IEC prefixes (something that took me only a half hour to clear up). And then there’s Omegatron’s Administrators’ noticeboard complaint about my “uncivil” behavior; a red herring if I ever saw one. So just pardon me all over the place if I’m a little skeptical about ever being able to have a reasonable expectation of what any given bargain or compromise with certain editors here will result in. Maybe it’s just me, but I view “outcomes” like this as evidence that the arguments of the pro-IEC prefix crowd are weak. Whether or not I agree or disagree with people, I tend to respect them better when they are forthright. T-bird: Do you really think that the outcome of all this is going to be the continued use of the IEC prefixes being permitted? I suggest that you come to grips with the reality of the situation and compromise. If I were you, I’d make peace with Fnagaton, agree that no more articles are to use the IEC prefixes, and hammer out wording on a policy regulating how the IEC prefixes will be deprecated from existing articles. I personally don’t think any such regulation is needed; Fnagaton knows these idiosyncrasies better than anyone and clearly has abundant energy to devote to correcting them and bringing them into compliance with the rest of the planet. Greg L (talk) 00:35, 4 June 2008 (UTC)

}}

Comments on binary prefix
{{hidden |headercss=background:#E9FFEF; border:1px 1px solid #96FFA8; |contentcss=border:1px 1px solid #96FFA8;|header= Comment on Binary prefix (purplebox)|content=
 * Comments go here


 * Re this text: "There is consensus that editors should not change prefixes from one style to the other", that is not a accurate statement. A more truthful statement would be "A consistent and clear majority of editors stated they don't want the IEC prefixes used on Wikipedia via various votes leading up to a vote for "Follow current literature". As regards the details of deprecating their use, FCL deferred to a version of "Binary prefixes" that was in dispute at the time, but it was hoped, would evolve into a non-contentious way to accomplish that end. Whether any of those majority votes constituted a Wikipedia-style consensus is currently disputed." Greg L (talk) 15:19, 23 May 2008 (UTC)


 * To start things here, because no one seems to be willing to actually tackle the problem and would rather go on endlessly about how the greenbox doesn't talk about the IEC prefixes, here's what I think should go in the purple box:


 * A brief history of IEC prefixes
 * A brief overview of the debate and main arguments for both sides
 * The consensus on the issue, along with the agreed upon way to disambiguate decimal and binary megabytes
 * The current table
 * Short list of fields with traditional binary megabytes, and fields with traditional decimal megabytes.

Headbomb (ταλκ · κοντριβς) 22:01, 24 May 2008 (UTC)


 * Headbomb: Regarding your above statement, “ because no one seems to be willing to actually tackle the problem ”, you’re in the drivers seat here. It’s difficult for other editors to keep current on all the parallel discussion threads and sort it al out. We know that since you are the sponsor of this proposal, you are fully engaged and motivated. You are the shepherd on this one so we’re looking to you to take a guess at wording that will achieve consensus, throw it up, and see if it sticks. So lead away. To help you in this endeavor, check out the references section of Mac Pro. Only three footnotes disambiguated the entire article. And it did so using conventions lifted straight out of common, familiar industry practices. It seems to have been a successful technique. For a wider variety of ways to disambiguate, see Third, hybrid proposal. Note however, that “Third, hybrid proposal” received only a 13:10 support vote at that time. I suggest that you study both and try to adopt the best parts you think might fly today. Greg L (talk) 23:54, 24 May 2008 (UTC)


 * P.S. If you can get an unambiguous treatment (something that doesn’t require people to go to other editors and ask “what does this mean to you?”) of the IEC prefixes (purple box) folded into your green box, I believe it will be something I can support. Greg L (talk) 00:01, 25 May 2008 (UTC)


 * Ah. I didn't know that was the perception. I guess I should apologize to the people who didn't seem willing to actually tackle the problem. Apologies offered to those who feel they need some. I'll try to review the debates tonight and give my shot at the purple box. Headbomb (ταλκ · κοντριβς) 01:53, 25 May 2008 (UTC)


 * That's better, it certainly addresses IEC according to the spirit of the current consensus.DavidPaulHamilton (talk) 04:07, 25 May 2008 (UTC)


 * I’m sure we’re all quite interested in what you come up with; I know I am. Greg L (talk) 04:09, 25 May 2008 (UTC)


 * I guess you’ve already got a good start. One thing jumps out me that I think is 1) not even necessary, and 2) is an odd, custom method rarely (or never) seen in the real world: • When it will be awkward to specify that a unit is decimal or binary every time, the ad-hoc symbols KB{{sub|2}}, MB{{sub|2}}, GB{{sub|2}},... and KB{{sub|10}}, MB{{sub|10}} GB{{sub|10}} may be used with explanation of the symbols. I’ve never seen this in current literature and thus it would be unfamiliar. Many readers are technically minded enough to recognize and understand symbols like “MB” and “GB” (they see “GB” all the time, like on the basic feature card on a laptop computer at Wal-Mart) but aren’t sufficiently well versed in the sciences to understand what a subscripted postscript means. To you and me, it is a bit of extra specificity added to a familiar symbol. To many readers though, the product is simply an unfamiliar symbol that matches nothing in prior experience. I would propose a bit of verbiage from FCL: “Parenthetical conversions should be given where appropriate and should generally also follow the practices in current literature on that subject unless there is good reason to do otherwise.” I really can’t imagine a real-life situation on Wikipedia where a meaning jumps around so frequently that this sort of notation is necessary. If you look at Mac Pro, you will see that a simple global footnote statement like “megabyte means based-2 math (1024{{sup|2}} bytes) for solid state memory and base-ten math (1000{{sup|2}} bytes, i.e. one million bytes) for hard drives” will be sufficient to disambiguate an entire paragraph of mixed-use instances of “megabyte”. Given the extraordinary power of global footnotes and the extraordinary variety of disambiguation methods seen in current literature, I really don’t believe Wikipedia needs to invent its own ad-hoc terms; I don’t think that is at all appropriate. Greg L (talk) 04:33, 25 May 2008 (UTC)


 * I think the ad-hoc approach as a last resort is better than using IEC though. Although in nearly all cases the article will be able to be edited in such a way to make other disambiguation methods effective.DavidPaulHamilton (talk) 04:56, 25 May 2008 (UTC)


 * David, so… we would totally avoid the use of the IEC prefixes, which are unfamiliar units of measure that the typical Wikipedia reader has never ever seen before and won’t ever encounter anywhere else after leaving Wikipedia (but are at least often recognized by professional software developers and at have been endorsed by a standards organization). And in accomplishing that end, we would—in rare cases—permit the use of different, unfamiliar units of measure that the typical Wikipedia reader has never ever seen before and won’t ever encounter anywhere else after leaving Wikipedia, and further, have not even been endorsed by a standards organization and are unrecognized even by professional software developers since they are a wholesale, ad-hoc invention of some Wikipedia editors who were trying to find a work-around to the IEC prefixes? That remedy would be worse that the illness. Simple solution: “The IEC prefixes shall not be used as a primary measure nor as a parenthetical conversion. Parenthetical conversions of the conventional binary prefixes should be given where appropriate and should generally also follow the practices in current literature on that subject.” Greg L (talk) 05:55, 25 May 2008 (UTC)


 * OK so thinking about it we can ditch the ad-hoc approach and if we ever have a situation where MB needs to be disambiguated because it isn't clear from the article body and we have limited space then we can ref link it as a footnote. That should cover all the rare situations. DavidPaulHamilton (talk) 08:49, 25 May 2008 (UTC)


 * In previous versions we had "IEC is acceptable" but now the situation has changed so I think we need to explictily state what is unacceptable to leave no doubt what is meant.DavidPaulHamilton (talk) 12:52, 25 May 2008 (UTC)


 * For some they are unacceptable, for others they are the perfect way of disambiguation. A consensus might be reached by ending somewhere in between, like explicitly showing a preferred way of disambiguation, without explicitly deprecating the other one. &minus;Woodstone (talk) 14:42, 25 May 2008 (UTC)


 * But the end result is that what once might have been acceptable is now not. There is no nice way to break a relationship, someone is always hurt. I hope that editors will appreciate the clear unambiguous direction in the guideline is good for Wikipedia, even if it goes against their personal preference for IEC.DavidPaulHamilton (talk) 15:45, 25 May 2008 (UTC)


 * No, there is no need to hurt people. I can support requiring disambiguation in explicit powers. I cannot support outright banning the IEC prefixes. We can both agree on a practical level without the need to reach full philosophical agreement.&minus;Woodstone (talk) 19:47, 25 May 2008 (UTC)


 * Woodstone, the original wording had already voted on by four others before your rather substantive edit. The text you struck (“IEC prefixes are not to be used…”) is an important point to many (or all) of us. And in the end—even after your modification—all the purple box garnered from you was a “three-pointer”. Yes, I’ve been making some edits to this but I viewed them as being more along the lines of clarifications and tweaking of syntax. Rather than downgrade my vote (and with his stated permission, Fnagaton’s), I’ve un-struck the text. I ask that you vote on it in that form. If you have to downgrade to even a 1 or a zero, then so be it. If you feel the need to so downgrade your vote, may I suggest that you also post a new version of the purple box (a yellow box?) more to your choosing and give that your “3” vote. Or, better yet, tweak it further so you can give it a 4 or 5 vote. The rest of us want to give the current purple box a whirl as is. It isn’t calling for deprecating existing articles of the IEC prefixes (although, I think that would be an outstanding idea); it does however, call for no no longer using them. IMO, that’s also an outstanding idea. Why? Because Wikipedia currently has some articles using the IEC prefixes and that means that the conventional prefixes have only a decimal meaning in those articles. Still other articles are using the conventional prefixes to mean the classic, binary meaning. This inconsistent use within Wikipedia is no good at all in my opinion. All this confusion and chaos (two years of it) really should come to an end and we’re searching for a mechanism that will accomplish that. Greg L (talk) 21:16, 25 May 2008 (UTC)


 * Woodstone I have one question for you regarding your strike out: Do you agree the spirit of the proposed text means that IEC should not be used, even if it is not explicitly stated?DavidPaulHamilton (talk) 21:41, 25 May 2008 (UTC)


 * I have made some minor (hopefully uncontroversial) changes, removing factual errors and unnecessary bias.  I have not addressed the main problem though, which is in the paragraph entitled MoS Conventions. This paragraph needs a rewrite. Thunderbird2 (talk) 16:04, 28 May 2008 (UTC)


 * First, I’ve seen these kind of “whittling away” edits before out of you but you didn’t change your vote. So… Are you going to upgrade your vote? If not, your edit doesn’t improve the overall score, it only lessens the support of many of the rest of it who voted. And if all you can manage is a “half point” (be removing your funny looking extra “X”), then why bother with the edit? Lastly, SWTPC6800 is usually pretty damned good with his research. Cite your evidence for striking the “factual errors”.  Greg L (talk) 16:26, 28 May 2008 (UTC)


 * P.S. To SWTPC6800: It appears to me that Thunderbird2’s edit summary statement that followed his striking of your text is a non sequitor. He wrote “the decimal prefixes were in use before the binary ones”. That argument doesn’t support his edit in the slightest. The text you wrote doesn’t address the issue of which meaning came first, nor is that point at all relevant. What matters is that in the context of computer memory, the IEEE approved the SI-style prefixes for use with bytes and bits to mean base-2 values and that it did so well before the IEC smeared lipstick on their pig and tried to pass it off as a prom date (sorry no takers for that date so far in the professional publishing world). Greg L (talk) 16:43, 28 May 2008 (UTC)


 * The point I am disputing is that binary prefixes were in use before the decimal ones. The decimal use always came first because, for any given value of the prefix, that value was reached for hard drives before it was reached for semiconductors.  Is someone seriously claiming the opposite? Or (reacting to your last post to Swtpc6800) are we reading different things into the same text? Thunderbird2 (talk) 16:48, 28 May 2008 (UTC)


 * Thunderbird2: You’re reading more meaning into the wording than is (was) there. The order is: 1) BIPM says M=1,000,000. 2) IEEE says “M” means 1,000,000 for everything else, but for binary memory, means 2{{sup|20}}, 3) This becomes the world standard for computers, 4) the IEC proposes Klingon talk like “kibibits”, 5) the computing and publishing world soundly ignores the IEC. What SWTPC6800 wrote is just to point out that the current real-world usage isn’t the bastard child you think it is; he discovered that today’s real-world practice sprung from a proposal from a legitimate standards organization and it stuck. The IEC prefixes are a good idea that didn’t stick. It’s an important distinction that is highly relevant and topical to the point of trying to reach a consensus here. Greg L (talk) 17:08, 28 May 2008 (UTC)


 * I don't get it. You make an edit and you have to upgrade your vote because otherwise the overall score isn't improved ... but aren't we trying to improve the guideline? It lessens the support of everyone else ... or strengthens it ... or neither.  Maybe votes are evil after all.  If all you've contributed to a discussion is an ex in a box, lessen that or strengthen that a hundred-fold and it still isn't worth a well-reasoned paragraph.  Give us a paragraph and we can better guess whether an edit would be viewed as an improvement ... an improvement to the guideline not some score. J IM p{{sub| talk·cont}} 17:06, 28 May 2008 (UTC)


 * See above post. Greg L (talk) 17:08, 28 May 2008 (UTC)


 * I took a stab at revising the text to pay proper homage to the IEC and layout a relevant synopsis of history and why we’re all where we are now. Greg L (talk) 17:44, 28 May 2008 (UTC)


 * The 1st sentence is OK. The 2nd one reads:
 * The use of binary meanings for "K", "M", "G",... had been used since the very early days of computing and, in acknowledgment of this real-world usage, the Institute of Electrical and Electronics Engineers (IEEE) and the American National Standards Institute (ANSI) in 1986, formally ratified this usage to mean the powers of 2 in computing. However, the binary meaning in computing wasn’t perfectly well adhered to because hard drive capacity followed the decimal values of the SI.

This second sentence, while not incorrect, is biased. For example, it implies that decimal prefixes were not used in the early days of computing (they were). It also suggests (taken together with the remainder of the purple box) that hard drive manufacturers who did not follow the early standards were wrong to do so, while today's semiconductor manufacturers who do not follow modern standards are faultless. Finally (again, taking it with the rest of the box), it implies that the IEEE recognises the binary use of the prefixes (it doesn't). Do you see the problem? Thunderbird2 (talk) 18:05, 28 May 2008 (UTC)


 * Your first two points are easy to correct. As to your last point (the IEEE recognizes the binary use of hte prefixes), I didn’t know that was the case. They proposed them in 1986 and retracted that since then? Is that what you’re saying? If true, the text should be revised to reflect reality: It was ratified by a standards body, (since retracted), but that retraction did nothing to diminish real-world usage and nothing to promote the adoption of the IEC prefixes. Please work it out with SWTPC6800. Greg L (talk) 18:17, 28 May 2008 (UTC)


 * Anyway, are we wasting our time here. I got a hunch that this wording: “• IEC prefixes are not to be used, unless directly quoting a source or when in an article specifically about the IEC prefixes” may be more problematic. No? Greg L (talk) 18:38, 28 May 2008 (UTC)


 * Yes, the big problems are all in the second half of the box - I said as much in my opening post. But no, I do not see this as a waste of time, but as an exercise in consensus building. Let's agree on the first half, and with that under our belt, list the remaining problems with the second half.  I cannot speak for others, but for me the main problems with FCL have more to do with balkanisation (exemplified by CID, kg/cm2 and MWt) than with IEC prefixes. Headbomb has neatly addressed my concerns in that direction, so I do not see why we can't find a middle way here, as we did before. Thunderbird2 (talk) 18:54, 28 May 2008 (UTC)


 * What’s wrong with Mac Pro? It reads pretty much like any magazine or computer-related Web site anyone would ever visit, except that ours has gobs of links so readers who might want to know exactly what these things mean, can click on them. Do you really think the shortcomings (slight, at most) of “Mac Pro” are so bad that we can’t allow the rest of Wikipedia’s articles to follow suite? Greg L (talk) 20:22, 28 May 2008 (UTC)


 * I don't have a problem with Mac Pro. It is the result of a form of words that we both agreed on.  Isn't that what we are working towards now? Thunderbird2 (talk) 20:45, 28 May 2008 (UTC)


 * OK, now I’m baffled. If Mac Pro is a satisfactory way of doing things, then why not put Wikipedia into alignment with the rest of the computer magazine world and the professionally edited encyclopedias and put a silver stake through the heart of the IEC prefix issue once and for all? Is your opposition over the manner in which existing articles would be brought into alignment? You don’t want Fnagaton doing the deprecation? Whazup? Greg L (talk) 21:41, 28 May 2008 (UTC)


 * I don’t understand your point. There have been occasions with individual articles in which a retrograde step has been taken (replacing IEC prefixes with ambiguous ones, without disambiguating footnotes) and when I see that I always revert, regardless of who makes the change. My position as far as the purple text is concerned is that I am happy to support a form of words similar to that used in the current FCL: state clear need for disambiguation; state clear preference for doing so using familiar units/notation (e.g., a footnote, as in Mac Pro). But I see no need and no justification for explicitly ruling out IEC. Thunderbird2 (talk) 22:08, 28 May 2008 (UTC)


 * The IEEE Standards Association reviews all of its standards periodically (every five years or so). They can be renewed for another 5 years. They could be renewed again and again but most are outdated in 10 years. The ANSI/IEEE 1084 standard from 1986 is no longer active. However, it shows that the computer industry took the de facto use of binary units and made them an official standard. The use of kilobyte to mean 1024 bytes was not just a colloquial term. The current IEEE 100 The Authoritative Dictionary of IEEE Standards Terms (Seventh Edition) has the definitions for kilo, mega and giga for both decimal and binary use.  They recommend a footnote to specify which value is being used. As is their practice, the IEEE will review the adoption of the IEC prefixes after a 5 year period. -- SWTPC6800 (talk) 21:39, 28 May 2008 (UTC)


 * I was under the impression that IEEE 100 had been superseded, but you seem to be saying that that is not the case. If IEEE 100 is still current, the IEEE is publishing two conflicting standards and the purple box should be updated to reflect that.  What is the publication date of the 7th edition? Thunderbird2 (talk) 21:54, 28 May 2008 (UTC)
 * According to binary prefix the 7th edition was published in 2000. Unless it has been ratified since then, it is superseded by IEEE 1541 (dated 2005). I think I got the dates wrong though.  I will update them. (IEEE Std 260.1-2004 is also relevant, but it is predated by IEEE 1541) Thunderbird2 (talk) 22:21, 28 May 2008 (UTC)


 * SWTPC6800: Please revise the purplebox to ensure it is factually correct. I don’t think we need an expansive treatement on all the history; just enough to get the most important, key, historical points down that establish 1) the “rightness” of various practices and proposals, and 2) the “reality” of current practices. Greg L (talk) 21:44, 28 May 2008 (UTC)


 * I don't think the IEEE 100 The Authoritative Dictionary of IEEE Standards Terms (Seventh Edition) is a standard per se. It is a dictionary of terms used in other IEEE standards. Anyway, the IEEE has adopted IEEE 1541, so it modifies all other IEEE standards. The point that I was trying to make was that after 25 years of de facto use by the computer industry, kilobyte as 1024 bytes became an official standard in 1986. In 1999 the standard bodies started to change but the industry stayed with the old usage.


 * I am going out tonight so I don't have time to edit the Purplebox now. We don't have to list every standard, just point out that the dual use was a standard in 1986. -- SWTPC6800 (talk) 23:34, 28 May 2008 (UTC)


 * I have just edited the most controversial part of the text, to bring it in line with what has previously been considered acceptable. Any comments? Thunderbird2 (talk) 17:49, 29 May 2008 (UTC)


 * My comments and thoughts? Regardless of what we decide to permit or not permit, I have little interest in MOSNUM being ambiguous as to the circumstances under which it might be permissible to use the IEC prefixes. Looking over the total content of the purple box, it seems pretty clear to me as to the recommended ways to communicate binary values. To explore this issue a bit more, I restored and expanded one bullet point. I'll be able to offer a more cogent comment after hearing from you how the newly added bullet point might encumber you or not in your future edits. Greg L (talk) 20:24, 29 May 2008 (UTC)


 * P.S. So that there is no jumping the gun here, I think it should be pretty clear that with Thunderbird2's struck text, the previous votes from Fnagaton, me, and possibly SWTPC6800 and others, should be considered as potentially obsolete and subject to change. Greg L (talk) 20:35, 29 May 2008 (UTC)


 * I've unstrucked the part about disambiguation in bytes and bits. I think everyone agrees (looking back in the binary archives), that disambiguation in bytes and bits is a perfectly good way to do things, as it is not ambiguation, clear and familiar. And we all (regardless of our feelings on wheter it would be right to disambiguate in IEC prefix units) know that disambiguation in KiB, MiB, etc, WILL cause a ton of revert wars, so I think it would be wise to agree to disambiguate in bytes and bits since everyone agrees that this is a valid method. Also I moved the preference for KB and kbit to the greenbox.Headbomb (ταλκ · κοντριβς) 03:18, 30 May 2008 (UTC)


 * I don't understand your reasoning Headbomb. Statements included in MOSNUM need to reflect consensus, which means that controversial ones should be removed.  IEC units have been adopted by respected international institutions like IEEE and their use in scientific literature is growing; their deprecation is therefore controversial. Thunderbird2 (talk) 08:41, 31 May 2008 (UTC)


 * And consensus is what we're trying to achieve. I did google searches a while ago, and this is what I got.


 * Search entry were in the "kilobyte OR kilobytes -wikipedia" format, for pages in the last year. The IEC prefix have 0.6% penetration (this is lower than the average for the last 10 years). Deprecation is not something that can't be revoked. Right now, no one uses them, save a few computer science journals. If their usage spread, MOS will change accordingly. In the meantime, this is the reasonable course, and you can still use IEC prefix where there is a dominant use of IEC prefix (pretty much nowhere), on IEC prefix related pages, in direct quotations, or whenever there's a good reason to not follow the letter of the MOS. Headbomb (ταλκ · κοντριβς) 16:18, 31 May 2008 (UTC)


 * Added google scholar hits (all years) Headbomb (ταλκ · κοντριβς) 19:19, 31 May 2008 (UTC)


 * The (lack of) google hits serves only to remind us of something we knew already: that IEC prefixes are unfamiliar to many. The IEC prefixes were adopted by the IEEE in 2005, and their use in scientific literature is growing. Why do you think that is? Thunderbird2 (talk) 16:34, 31 May 2008 (UTC)


 * Scientist follow SI standards because using SI prefixes for non SI-meanings is simply wrong. The rest of the world uses what they feel like and don't care if it makes sense or not. Wikipedia targets mobs so it follows what mobs want. Note that if you're tackling a topic of computer science, IEC prefix use is perfectly fine if computer science uses IEC prefixes too.Headbomb (ταλκ · κοντριβς) 16:44, 31 May 2008 (UTC)


 * Let me explain to you why I think the present text is biased. Imagine for a moment that I were to propose the following text:
 * Disambiguation using exact numbers of bytes is not to be used on Wikipedia except under the following circumstances:
 * when the article is on a topic where the majority of cited sources use exact numbers of bytes,
 * when directly quoting a source that used exact numbers of bytes,
 * in articles specifically about or directly discussing exact numbers of bytes.

Would you agree to that? Thunderbird2 (talk) 16:50, 31 May 2008 (UTC)


 * I think the above post has missed the point. The "Disambiguation using exact numbers of bytes is not to be used..." is biased because it advises to do something that goes against what is observed in the majority of the sources, meaning that of course the real world commonly sees numbers of bytes used as disambiguation for KB/MB/GB etc. Headbomb's text isn't biased (in the way the post claims) because it reflects what is observed in the real world, i.e. IEC prefixes are unfamiliar and not widely used. The post then misses the point because it tries to equate unfamiliar and virtually unused IEC prefixes with the extremely common and widely used method of using "exact numbers of bytes". Fnagaton 17:44, 31 May 2008 (UTC)


 * Headbomb didn't come right out and say it but the implication is this: IEC Prefixes are not widely used, this is a fact. On the side of the argument that don't agree with the text (that Headbomb added and TB2 struck) there has not been a good argument for continuing to promote/advocate/support/champion/endorse the inclusion of IEC prefixes in articles that do not meet the confitions Headbomb wrote. On the other side the argument has been much stronger to make sure IEC prefixes should not be used in the majority of articles. Greg likes to use the term "grandfathered in" and it applies perfectly to the text that says "IEC prefixes are acceptable". At the very least the "IEC prefixes are acceptable" should be removed. Replacing the "IEC prefixes are acceptable" with Headbomb's version restores the balance to the guideline text that has been missing for the past year or more. Fnagaton 18:11, 31 May 2008 (UTC)


 * Woodstone: Regarding your change with the comment "with the prescribed form of disambiguation [exact numbers of bytes] above it, there is no need for the struck paragraph" does this mean you think the guideline text is clear enough that there is "no need" for IEC prefixes and the "prescribed form" should be used in the majority of situations? If you do think that then I can just about agree to your change in the interests of finding consensus for your version. I ask because I think it is clear that Headbomb thinks adding the text improves the guideline text because it reduces the ambiguity of the instructions given. Fnagaton 18:58, 31 May 2008 (UTC)


 * Yes, the MOS would state as only example of disambiguating the use of explicit powers of 10 or 2 (c.q. 1000 or 1024). That should be clear enough. People sticking to the MOS would do it that way. Adding additonal comment about when the IEC can be used is superfluous. So in practice it would lead to your preference, without explicitly banning IEC units. Actually the sentence below the struck sentence should be struck as well, as it may lead to the mistaken idea that KB etc are always binary. &minus;Woodstone (talk) 21:43, 31 May 2008 (UTC)court


 * Thank you, yes that makes your position clearer. I have to say I hope "that should be clear enough" that people should use explicit powers of 10 or 2 methods. I'm just a little hesitant that leaving out the "don't use IEC" makes it a bit ambiguous. So, it looks like you and I are in agreement about what the guideline sans the struck out text means. Don't you think? So, I have to say, right now in the interests of helping build consensus that I hesitantly agree to the struck out text. I made a tweak the the sentence below, instead of strking it I removed the word binary and just left prefix. That should remove the chance of a mistake that KB etc are always binary. Fnagaton 21:58, 31 May 2008 (UTC)
 * I guess with the strike outs that means you're happy increasing your vote now back to what it was, a 4? I hope that also means Thunderbird2 can also follow you and increase his vote since his sticking point was on the same thing. Headbomb and Greg, maybe we should try seeing what these two say regarding their votes before changing the strike out? Fnagaton 22:10, 31 May 2008 (UTC)




 * Fnagaton. I don’t see why the struck text was so bad. Perhaps you see the wording as a backdoor avenue for abuse. But, if not abused beyond all valid interpretation, it pretty much allows the IEC prefixes to be used in only one or two extraordinarily rare articles on highly advanced programming issues. Beyond that, the rest of the articles that could make use of the IEC prefixes would be articles  on the IEC prefixes and articles about the bit and byte. On a separate note, the “2” votes the pro-IEC prefix elements have given can only be reasonably interpreted as an “oppose” vote; thus, no “consensus” can be called given the limited number of editors who give a damn on this issue. Most “moderate” editors who voted on various incarnations of “Binary prefixes in computer memory and storage” and “Fourth draft (Follow current literature)”, just aren’t as passionate about the issue to see any reason to spend half their free hours here endlessly debating this issue. These editors have previously voted with comments like “Looks like a common-sense guideline that solves a long-standing problem” and then they wander off to happier waters here on Wikipedia, rather than getting bogged down in endless debate, questing the parentage and mental prowess of the other camps here. Even if a consequence of your struck text is that the pro-IEC prefix crowd reduces their votes to a lower value, I don’t see that as as being a real problem; their votes are already an effective “oppose” vote. So… I think we’re wasting our time here and see no further point trying to reason with this handful of editors; their positions are clear and it is unrealistic to expect them to substantially change after three long years. Notwithstanding that all computer manufacturers in all their literature and publications to end users don’t use the IEC prefixes, notwithstanding that all general-interest computer magazines don’t use the IEC prefixes, notwithstanding that all professionally edited print and Web-based encyclopedias (like Encyclopedia Britannica) don’t use the IEC prefixes, the minority pro-IEC Prefix crowd have apparently looked into the future using their tricorders and must know something about the future adoption of the IEC prefixes that isn’t apparent to the rest of us (and all the professional, degreed editors at “real” encyclopedias). {{nowrap|Accordingly…}} I think it’s time to stop wasting our time. As I proposed above in No no… let’s DO, I think it’s time to post a number of invitations on the talk pages of many of Wikipedia’s computer and technical-related articles and conduct a big vote on “Follow current literature”. From then on, only minor edits that don’t substantially change the spirit, intent, and basic effect will be permitted without an equally broad-based consensus. Greg L (talk) 19:44, 31 May 2008 (UTC)
 * * That’s “ridicule” of certain arguments, not a “personal attack”. No whining.


 * I personally don’t think the struck text was so bad either, I think it should stay because it makes the guideline less ambiguous. But I'm willing to believe some people just don't like it for various reasons and if Woodstone answers the question (at 18:58, 31 May 2008 (UTC)) above then I might be inclined to agree with the struck text staying struck. Of course the corollary is that if Woodstone doesn't answer the question then I will be less inclined to agree with his striking of the text. The ball is in Woodstone's court. Fnagaton 20:20, 31 May 2008 (UTC)


 * see response above; &minus;Woodstone (talk) 21:43, 31 May 2008 (UTC)


 * It strikes me as a tactic along the lines of “I bulldozed the police building to make you opine that having more policemen in our city is good.” I’m not so disposed. But then, you are deeper in the trenches on this than I am and will accede to your judgment on this one. But, getting Woodstone to agree to such a point is like trying to compress a balloon between cupped palms: push a bulge in here and one or two others are bound to pop out elsewhere. Someone take the hammer away from me; banging my head over and over with the thing is starting to feel good! Greg L (talk) 21:14, 31 May 2008 (UTC)


 * Woodstone or Thunderbird, would you be so kind as to give us an example of a hypothetical (or real) IEC prefixe use that would be perfectly appropriate in the spirit of the MOS, but somehow prohibited by the unstruck version of the purplebox? We don't have a lot to chew on. It seems to me that the purple box would cover the use of a vast majority of article, and that if there is a need to use KiB and GiB in an article, that people can discuss it on individual talk pages and resort to "MOS is a guideline, not absolute law". Headbomb (ταλκ · κοντριβς) 22:09, 31 May 2008 (UTC)


 * Dang good question. Greg L (talk) 04:11, 1 June 2008 (UTC)


 * I'll point that I could be convinced that striking out that text is a viable option, but unless some sort of example (however far fetched) is given, I'll have to say that the text should be unstruck. A 2-vote for the unstruck text version vs. a 4-vote for the struck version will have a hard time being taking seriously if you can't substantiate it. I'll invoke feature article principles here: unsubstantiated objections may be disregarded. Headbomb (ταλκ · κοντριβς) 04:29, 1 June 2008 (UTC)


 * I don't see TB2 answering your question Headbomb. What I do see is TB2 making changes to the text which don't have support and making inaccurate/unsubstantiated claims in his vote comment. As such TB2's vote can be ignored/disregarded. Fnagaton 23:22, 1 June 2008 (UTC)

The solution you propose here is remarkably compley and ambiguous. We have just had a vote on a consensus solution in the German Wikipedia and the result was to not use IEC but to do the following: Use the KB, MB etc. always as binary for data amounts, use them as decimal for data rates (data rate is basically a frequency). If refering to media that is declared in decimal values (i.e. DVD or harddisk) give the correct size in binary plus a remark about the usual capacity statement. To simplify this we have created a set of standard tool tips (showing the exact value) and footnotes. TheBug (talk) 12:19, 6 June 2008 (UTC)


 * Very well Headbomb. I will swallow my pride and reply to your question (reproduced above below for easy reference and benefit of others). I do so here [Headbomb talk page] to avoid the 500 kB (I’m back on my old computer/slow internet connection).

{{blockquote|text=Woodstone or Thunderbird, would you be so kind as to give us an example of a hypothetical (or real) IEC prefixe use that would be perfectly appropriate in the spirit of the MOS, but somehow prohibited by the unstruck version of the purplebox? We don't have a lot to chew on. It seems to me that the purple box would cover the use of a vast majority of article, and that if there is a need to use KiB and GiB in an article, that people can discuss it on individual talk pages and resort to "MOS is a guideline, not absolute law". Headbomb (ταλκ · κοντριβς) 22:09, 31 May 2008 (UTC)}}

The problem I see is that by far the easiest way to disambiguate is with IEC prefixes. Notice that I do not say best, just easiest. They make it possible for a knowledgeable editor to come along and, with very little effort, disambiguate an article or series of articles. Once that step is made it becomes possible for another editor, with (perhaps) less knowledge but more time, to improve the article still further by replacing the unfamiliar IEC units with a more familiar form of disambiguation. The end result? A better Wikipedia. The effect of forbidding the use for all but the most unlikely situations is to increase the difficulty threshold for that knowledgeable editor (a scarce resource), who as a result is able to improve fewer articles, if he bothers at all.
 * The benefit in a nutshell (of avoiding explicit deprecation): it reduces the effort threshold for small improvements to many articles and therefore improves Wikipedia as a whole.
 * A second problem that I see is related to that second step. I believe that most readers will be far more comfortable with the footnote style of disambiguation (as used by Greg L on Mac Pro) than with the awkward disambiguation with exact numbers of bytes. Although the second problem is not directly related to IEC, both problems are solved by removing the deprecation.

Thunderbird2 (talk) 19:01, 6 June 2008 (UTC)


 * That doesn't answer the question with a specific example though. What you think is easiest is not best for the average reader. The thing is, in sources if there is disambiguation the disambiguation is done by stating the number of bytes, this is what would be cited in the article anyway. So adding KiB to an article when the sources we cite from would say "1024 bytes" is actually not the natural thing to do in the first place. A knowledgable editor having read MOSNUM (Binary prefixes) would just as easily convert straight to stating the number of bytes or footnotes anyway without needing to place IEC prefixes and waiting for someone else to come along and use the "bytes method" or "footnotes method". The result, a better Wikipedia because the article writing process in more streamlined and doesn't rely on two different people to do the job that one person can easily do. Another advantage is that articles then don't get IEC prefixes added that would confuse most readers until someone else comes along and converts to bytes or footnotes. And anyway, just because the guideline says "IEC prefixes should not be used" it doesn't actually stop anyone from adding them anywhere in any article they like. It doesn't magically make it more difficult to type the letters at the keyboard. That is not the point at all because in the same way the guideline which says "use neutral point of view" doesn't stop people from adding POV to articles. The point actually is that the guideline makes it clear that when someone adds something that is not wanted (like IEC prefixes) it gives specific guideance so that someone who wants to tidy the article knows what is preferred in what situations. The proposed guideline text as it is right now does not in any way shape or form hinder or physically stop anyone from adding what they like, it doesn't stop the scenario you describe from happening. It isn't like the edit box for articles will reject any IEC prefixes it finds. Fnagaton 19:18, 6 June 2008 (UTC)


 * First, disambiguation using the number of bits or bytes is universally agreed upon, [Wikipedia talk:Manual of Style (dates and numbers)/Archive B9#Specifying an exact number of bytes is an acceptable method to disambiguat “megabyte”|including you]], as being valid, sane, and non-controversial. That's why disambiguation should be done using the number of bits and bytes. As for "ease of disambiguation", in one case you have to take a value that is given in MB anyway, look up which megabyte is meant, then write either 1024{{sup|2}} bytes or 1000{{sup|2}} bytes and people will know which megabyte you refered to. In the other, you have to write either MiB or MB and people will still not get which megabyte you refer too. If the cost for stopping one of the longest war on Wikipedia and restoring clarity is that editors have to, at worst, type 22 characters instead of 15 at a couple of place, then that is a very small price to pay. Especially if your argument for having IEC prefix is that some people could disambiguate in MiB to pave the path for those who would disambiguate in number of bits and bytes.
 * Second you can still disambiguate using footnotes if you so desire, so I really don't see what that's got to do with anything.
 * To Fnagaton: While he still hasn't come up with an example, at least he's trying to argue his point instead of just stating it this time.

Headbomb (ταλκ · κοντριβς) 19:57, 6 June 2008 (UTC)


 * Just because a method is acceptable does not mean that it should be preferred. To many readers the use of 512 x 1024{{sup|3}} B to disambiguate 512 GB will be just as unfamiliar as 512 GiB.  So where is the advantage to Wikipedia in that? This kind of discussion has been thrashed out countless times before, taking up acres of archives, and without ever reaching a consensus for the deprecation of IEC units (quite the opposite).  That's why I consider it sufficient to refer to these archives rather than hold the entire debate again, for the umpteenth time.  But if you have the time and the patience, then so do I. Thunderbird2 (talk) 21:03, 6 June 2008 (UTC)


 * 512 x 1024{{sup|3}} B is much more obvious, understandable and familiar than using IEC prefixes for the majority of people. Using 512 x 1024{{sup|3}} B is also much less controversial. Thus to someone who is not biased towards IEC prefixes using is 512 x 1024{{sup|3}} B preferred. Fnagaton 21:08, 6 June 2008 (UTC)


 * Fnagaton: editors who come here to denote their time to Wikipedia do so in good faith. They do not expect to be accused of dishonesty without good reason.  The only information you gave me about Headbomb's question was a time and date.  The easiest way to find it was to look through his contributions.  The time and date corresponded to a question to Woodstone.  Now, if we are going to take this discussion further, the first step is for you to withdraw your personal attack. Thunderbird2 (talk) 07:18, 7 June 2008 (UTC)


 * You accused yourself of dishonesty, do not misrepresent the truth because you used the word "dishonest" about yourself first. Again you misrepresent the facts about the question because at the time you claimed the question was only to Woodstone, the question is actually clearly shown as being to Woodstone and to you. The easiest way to search the page for the time and date and I also supplied a link to the edit that clearly shows the question is to you and to Woodstone, yet you continued to deny that simple truth. You have accused me of something I have not done, the proof is on this page so you must retract your repeated attempts to misrepresent the truth and also you must retract your baseless accusation. If you wish to use your proven untrue claims as an excuse for withdrawing from the debate on the consensus for this guideline change then so be it. That is your call, but don't try to shift the blame onto me when the fact is you are to blame because you were caught claiming something that has been proven as not true. The fact you keep on repeating your untrue accusations can be considered a violation of personal attack so you must withdraw all your attempts to misrepresent the truth. Fnagaton 07:44, 7 June 2008 (UTC)

Previous binary prefix standards
The use of the customary binary prefixes predates SI (International System of Units). The 11th CGPM adopted the SI units in 1960. Binary addressed computers existed before that and the user's referred to the memory size in k or K.


 * The author is with the Westinghouse Electric Corporation. Note: the IBM 704 used binary addressing.


 * "The 8K core stores were getting fairly common in this country in 1954. The 32K store started mass production in 1956; it is the standard now for large machines and at least 200 machines of the size (or its equivalent in the character addressable machines) are in existence today (and at least 100 were in existence in mid-1959)."

The traditional binary prefixes KB, MB and GB were standardized in various IEEE standards including ANSI/IEEE Std 1084-1986 and IEEE 100-2000.



Since we don’t want to be ambiguous on the heritage of the binary prefixes we should not call them the SI binary prefixes. The traditional ANSI/IEEE binary prefixes would be more accurate. -- SWTPC6800 (talk) 04:58, 26 May 2008 (UTC)


 * I agree. I'll try to think of something. Give it a shot in the meantime.Headbomb (ταλκ · κοντριβς) 23:04, 26 May 2008 (UTC)


 * Hum... actually there is no inaccuracy. Nobody said that the binary prefixes came from the SI, only that a binary use of K,M,G... was in conflict with the SI usage of K,M,G... Unless I'm missing something, this is accurate (although perhaps incomplete). Headbomb (ταλκ · κοντριβς) 03:51, 27 May 2008 (UTC)


 * This statement is misleading and possibility incorrect. "These two definitions come from the fact that prior to 1999, there were no prefixes for powers of 1024 like there were for powers of 1000." The ANSI/IEEE Std 1084, approved in 1986, defined kilo and mega as binary when used to measure computer storage. (Historically, storage is the memory in a stored program computer. Not tape or disk.) The section reads like before 1999, inebriated computer engineers were out of control with units for computer storage. :-) SWTPC6800 (talk) 14:20, 27 May 2008 (UTC)


 * Ah, I see. I'll edit this passage in consequence. Tell me what you think.Headbomb (ταλκ · κοντριβς) 14:25, 27 May 2008 (UTC)


 * BTW, could you please update your vote on the greenbox? Headbomb (ταλκ · κοντριβς) 19:18, 27 May 2008 (UTC)

Strike outs

 * I've noticed large numbers of strike outs that in against the common sense principles of the text. The largely accepted and familiar sections, first and second part, are common sense. These strike outs have the purpose of adding an exception SPECIFICALLY for OBSCURE and UNFAMILIAR units like IEC. This does not help produce a neutral guideline so don't do it.DavidPaulHamilton (talk) 22:08, 22 May 2008 (UTC)


 * The stricken out beginning of the prefix section is completely redundant with the remainder of that section and is just unncessary IEC-bashing. The other edits try to remove making use of the ambiguous units KB and MB compulsory. This is clearly inconsistent with the main proposal to prefer unambiguous units. Lastly, a description of which meanings are most likely in specific cases is not a task for a MOS.&minus;Woodstone (talk) 21:55, 24 May 2008 (UTC)


 * It isn't redundant. The strike outs promoted IEC by placing too much on the ambiguity. What the sources use matters most and not the supposed ambiguity. Which is why they are reverted.DavidPaulHamilton (talk) 22:08, 24 May 2008 (UTC)


 * I'm not entirely sure of that. The section above, regarding units of measure, specifically state to use unambiguous units of measure, whether or not the source does. How many sources disambiguate between long ton, short ton, and metric ton? How many between calorie and kilocalorie (or improperly use the first as the second?) Disambiguation and precision is far more important. Only in direct quotes must the source's exact words be maintained; in a paraphrase, that is not required at all, and a unit-of-measurement conversion or disambiguation is perfectly allowable. Seraphimblade Talk to me 05:36, 26 May 2008 (UTC)


 * I'm not entirely sure of what you are addressing, but I agree with what was said.Headbomb (ταλκ · κοντριβς) 05:41, 26 May 2008 (UTC)


 * Seraphimblade and Woodstone, I got this policy from someone on Linux talk. The policy wording appears to tackle this exact issue. IEC is very rarely used and it is a tiny minority of sources that actually use it, nobody disagrees with that. To quote WP:WEIGHT "We should not attempt to represent a dispute as if a view held by a small minority deserved as much attention as a majority view. Views that are held by a tiny minority should not be represented except in articles devoted to those views. To give undue weight to a significant-minority view, or to include a tiny-minority view, might be misleading as to the shape of the dispute. Wikipedia aims to present competing views in proportion to their representation among experts on the subject, or among the concerned parties. This applies not only to article text, but to images, external links, categories, and all other material as well. "DavidPaulHamilton (talk) 09:18, 26 May 2008 (UTC)
 * DavidPaulHamilton, my question remains the same then. Why does this apply only to the binary prefixes? Far more sources use "ton" than "long ton", "short ton", or "metric ton". Yet as the unit is ambiguous, we disambiguate it, even though only a small minority of sources use those terms. Most sources, similarly, use only "gallon", not "US gallon" or "imperial gallon". Yet, again, though the vast majority of sources do not disambiguate, we do, because we are a reference work and value precision over the use of common terminology. That is as well it should be. Why, in this one case, do we wish to discard that value? Seraphimblade Talk to me 15:15, 26 May 2008 (UTC)

Time to fix the issue
The discussion on IEC prefixes has gone on far too long, I've previously been a participant, and the argument "against" is clearly stronger. No more red tape, I think it's time that we systematically change all references to the IEC prefixes on the English Wikipedia where appropriate. Who's in? 72.208.254.202 (talk) 01:39, 23 May 2008 (UTC)


 * I agree completely. In reality, that's real-life, no discussion goes on forever. If both sides can't agree on something after excessive discussion, it means war. That is how it works in real-life. Maybe we could ask for UN support? Well I guess those UN pussies ain't gonna cut it. Only true Navy SEALs can save us now. Let's end this IEC tyranny! Let's bring peace to Wikipedia! --217.87.62.108 (talk) 15:34, 23 May 2008 (UTC)


 * Well, all sarcasm aside, that does sound like the American way. I don't think both sides will ever agree, so I'll just do my part to make Wikipedia a better encyclopedia. I'll write the bot. 72.208.254.202 (talk) 01:55, 24 May 2008 (UTC)


 * In view of the allegations of sockpuppetry, and the toxicity of the arguments surrounding this issue, I'm sure we'll all be grateful if anons were to log in before making their comments. TONY   (talk)  08:40, 24 May 2008 (UTC)


 * Note that User:DavidPaulHamilton has been blocked as a sockpuppet of User:Fnagaton. — Omegatron (talk) 00:21, 28 May 2008 (UTC)


 * What Tony said. Log in please. Greg L (talk) 23:38, 24 May 2008 (UTC)


 * I don't have an account. Even if I did, that probably wouldn't be in my best interests since WP administrators probably wouldn't appreciate such a pragmatic approach to solving the problem. I'll let you folks know when I have a working version. 72.208.254.202 (talk) 07:33, 25 May 2008 (UTC)

Can we at least all agree to ignore the anonymous trolls from now on? If they want to be heard, they should register accounts. — Omegatron (talk) 00:18, 28 May 2008 (UTC)

Semiprotect the page?Headbomb (ταλκ · κοντριβς) 00:41, 28 May 2008 (UTC)


 * Semiprotecting talk pages prevents anonymous editors entirely from communication on the subject, so it's only done in very extreme cases. I don't think the comments here warrant such drastic action. Disruptive, unauthorized bots are routinely blocked and reverted, so threats of them aren't terribly serious. I think our best course in the future is just to ignore attempts at inflammation. (Though, as a side effect, the sides here seem to be in agreement on something!) Seraphimblade Talk to me 04:10, 28 May 2008 (UTC)
 * Please don't semiprotect this page (unless it's being continually vandalised). Anon users in this environment will just not be taken much notice of. Fine. TONY   (talk)  03:58, 1 June 2008 (UTC)

}}

General comments
{{hidden |headercss=background:#E9FFEF; border:1px 1px solid #96FFA8; |contentcss=border:1px 1px solid #96FFA8;|header= General comments on the rewrite|content=

Change to GB ref
During May, "(decimal)" was added: "A typical advertisement for a PC in 2008 might specify 2 GB memory (binary) and a 160 GB HDD (decimal)." I'm just checking that it means something; I have no idea. I guess I'll add non-breaking spaces between the units and values. TONY  (talk)  03:40, 1 June 2008 (UTC)


 * The binary means that the giga- is the binary sense, 230(10243); the decimal that it's the decimal, 109 (10003). J IM ptalk·cont 04:33, 2 June 2008 (UTC)
 * Thanks, Jim. Of course. I'm a dummy. TONY   (talk)  08:28, 3 June 2008 (UTC)

Curly quotation marks are not permitted by MOS

 * If anyone persists in using them in MOSNUM, I'll revert immediately. If you have a problem, go argue it out at the main page of MOS, which says: "The exclusive use of straight quotes and apostrophes is recommended. They are easier to type in reliably, and to edit. Mixed use interferes with searching (a search for Korsakoff's syndrome could fail to find Korsakoff’s syndrome and vice versa)".

At the moment, MOS requires words as words to be rendered in italics, not quotes. There's now a clash between this and the (disputed) point here that SI symbols must always be in roman face. This needs to be sorted out. TONY  (talk)  04:47, 1 June 2008 (UTC)


 * Yes, you're right. The inconsistency between MOS and MOSNUM should be tackled. It is important for unit symbols to be upright though; in mathematics and numerical sciences, there is a long tradition of reserving italics for variable names. Suggestions anyone? Thunderbird2 (talk) 16:20, 1 June 2008 (UTC)


 * Headbomb: I see that you've italicised some of the unit symbols. How is that compatible with
 * "In accordance with the rules of CGPM, NIST, National Physical Laboratory (UK), unit symbols are in upright, roman type."


 * and the (hidden) comment i.e. they are never italic; where they could be mistaken as symbols for dimensions, variables or constants? Thunderbird2 (talk) 18:04, 2 June 2008 (UTC)


 * They were italicized because they needed to be highlighted. They were between quotes before, but in some places quotes were cumbersome. The usage is similar to writing "A triquark is a particle made of three quarks". The italics on kg is compatible with MOS because it is not used as a symbol, but as a word. The only place I kept quotes was in the point about italics, so people could distinguish what to do from what not do to. Headbomb (ταλκ · κοντριβς) 05:51, 3 June 2008 (UTC)


 * Headbomb, I don't understand your explanation. We need to think this through more carefully, and attempt to address Tony's concern about consistency with MOS. Thunderbird2 (talk) 18:17, 3 June 2008 (UTC)


 * I don't think I give a shit about CGPM, NIST and the NPL. We've had this argument before, and it was unresolved. I go with Noetica's view that there's no good reason to make some god-given exception to our usage of italics everywhere else on WP (see MOS on italics), just because a few outside authorities, without stated reason, want SI units to be exclusively roman. I used quotes in my recent clean-up of MOSNUM in deference to the current rule, which was inserted, I believe, without proper consensus. You can see how ugly and hard to read they are, and in the case of degree symbols (the little superscript circles), quotes make it almost impossible to see the symbol. We have to mark "words as words" some way, and italics seems the obvious solution, as prescribed by MOS. TONY   (talk)  08:25, 3 June 2008 (UTC)


 * Tony, there is a reason for it, which I gave in my first post just above. Whether the reason is considered good enough is another matter. In what sense was the change here made without consensus? Thunderbird2 (talk) 18:13, 3 June 2008 (UTC)

Copyediting of purple/green/red boxes
I'm totally confused. I see things that need copy-editing in those boxes. Can someone tell me which ones are slated for inclusion? TONY  (talk)  08:49, 3 June 2008 (UTC)

All of them, but hopefully redbox won't make it. Headbomb (ταλκ · κοντριβς) 16:01, 3 June 2008 (UTC)


 * Tony1's question remains. Are the boxes still intended for us to copyedit? LeadSongDog (talk) 06:01, 5 June 2008 (UTC)

If you want to copy edit something, try the proposed text down below (click on show in the Proposed text header). Headbomb (ταλκ · κοντριβς) 01:03, 6 June 2008 (UTC) }}

Uploading the rewrite (June 7th)
{{hidden |headercss=background:#E9FFEF; border:1px 1px solid #96FFA8; |contentcss=border:1px 1px solid #96FFA8;|header= Proposed text|content=

Overview
The following section could be summarized into 3 bullets. In order of importance, they are:
 * Unambiguousness: Do not write so you can be understood, write so you cannot be misunderstood.
 * Familiarity: The less one has to look up definitions, the easier it is to be understood.
 * International scope: Wikipedia is not country-specific, unless tackling region-specific topics, use international units.

If you have trouble balancing these three bullets, head to the talk pages to consult other editors and try to reach consensus. Mentioning the issue on the MOSNUM talk page and on the article's associated Wikiproject might also be a good idea, especially if the problem is not restricted to a specific article.

Which units to use

 * Broadly accepted units should be given preference. Usually, but not always, this means units approved by the Bureau International des Poids et Mesures (BIPM) (SI units, SI derived units, and non-SI units accepted for use with SI) are preferred over other units (e.g., write 25 °C (77 °F) and not 77 °F (25 °C)).
 * Since some disciplines use units not approved by the BIPM, or may format them in a way that differs from BIPM-prescribed format, when such units are normally used by a clear majority of relevant sources articles related to those disciplines should reflect this (e.g., using cc in automotive articles and not cm3). Such use of non-standard units are always linked on first use.


 * Familiar units are preferred over obscure units—do not write over the heads of the readership (e.g., a general interest topic such as black holes would best be served by having mass expressed in solar masses, but it might be appropriate to use Planck units in an article on the mathematics of black hole evaporation).
 * Uses of units should be consistent within an article. An article should only have one set of primary units (e.g., write A 10 kg (22 lb) bag of potatoes and a 5 kg (11 lb) bag of carrots, not A 10 kg (22 lb) bag of potatoes and an 11 lb (5 kg) bag of carrots).
 * There is consensus to use US customary units as default units in US-related topics and that it is permissible to have imperial units as primary units in UK-related topics.


 * The use of ambiguous units is discouraged (e.g., do not write gallon, but rather imperial gallon or US gallon). Only in the rarest of instances should ambiguous units be used, often in direct quotations to preserve accuracy to the quoted material.
 * Use scientific notation with discretion—not all quantities are best served by it (e.g., do not write John is $1.661 kg$ old, but rather John is 22 years old).

Conventions

 * Values and unit symbols are separated by a non-breakable space ( &amp;nbsp; ) (e.g., write 10 m or 29 kg, not 10m or 29kg).
 * Exceptions: Non-alphabetic symbols for degrees, minutes and seconds for angles and coordinates are unspaced (e.g., write 5° 24′ 21.12″ N for coordinates, 90° for an angle, but 18 °C for a temperature). See also Manual of Style—Geographical Coordinates.


 * Unit symbols are written in upright roman type, never in italics as they could be mistaken for dimensions, constants, or variables (e.g., write "10 m" or "29 kg", not "10 m" or "29 kg).
 * Standard symbols for units are undotted (e.g., write m for metre (not m.), kg for kilogram (not kg.), in for inch (not in., " (double quote), or &prime;&prime; (double prime)), and ft for foot (not ft., ' (single quote), or &prime; (prime))).
 * Non-standard abbreviations should be dotted.


 * Symbols have no plural form—an s is never appended (e.g., write kg, km, in, lb, not kgs, kms, ins, lbs. Write bit, not bits unless bits used as a word rather than a symbol).
 * Units named after a person are not proper nouns, and thus are not capitalized when written in full (e.g., write A pascal is a unit of pressure, not A Pascal is a unit of pressure).
 * When unit names are combined by multiplication, separate them with a hyphen. A kilogram-calorie (kg&middot;cal) is not the same thing as a kilogram calorie (kcal). Pluralization is achieved by adding an s at the end (e.g., write A force of ten newton-metres).
 * When units names are combined by division, separate them with per (e.g., write meter per second, not meter/second). Pluralization is achieved by adding an s to the unit preceding the per since it reads this many units of this per one unit of this (e.g., write An energy flow of over ten joules per second).
 * When units are combined by multiplication, use a middle dot (&amp;middot;) to separate the symbols. For example ms is the symbol for a millisecond, while m&middot;s is a metre-second.
 * When units are combined by division, use a slash to separate the symbols (e.g., for metre per second use the symbols m/s (not mps)) or use negative exponents (m·s&minus;1).
 * There should be no more than one slash per compound unit symbol, e.g., kg/(m·s), not kg/m/s or kg/m·s.


 * Powers of unit symbols are expressed with a superscript exponent (write 5 km2, not ''5 km^2).
 * A superscript exponent indicates that the unit is raised to a power, not the unit and the quantity (3 metres squared is 9 square metres, or 9 m2).
 * For areas and volumes, squared and cubed US customary or imperial length units may instead be rendered with sq and cu between the number and the unit symbol (write 15 sq mi and 3 cu ft, not 15 mi sq and 3 ft cu).
 * The symbols sq and cu are not used with BIPM-approved metric/SI unit symbols.


 * Numerical range of values are formatted as (lower value/en dash/higher value/non breaking space/unit symbol) (e.g., write 5.9–6.3 kg, not 5.9 kg – 6.3 kg or 5.9 – 6.3 kg), or can be specified in written form using either unit symbol or unit names, and units can be mention either after both numerical values or after the last (e.g., write from 5.9 to 6.3 kilograms, from 5.9 kilograms to 6.3 kilograms, from 5.9 to 6.3 kg and from 5.9 kg to 6.3 kg are all acceptable, but only one of these format should be in use in a given article).
 * When dimensions are given, values each number should be followed by a unit (e.g., write 1 m × 3 m × 6 m, not 1 × 3 × 6 m3 or 1 × 3 × 6 m).

Confusing units and symbols

 * The degree symbol is °. Using any other symbol (e.g., masculine ordinal º or ring above &#x2da;) for this purpose is incorrect.
 * The symbol for the bit is bit, not b. The byte may be represented by either one of the symbols B and byte, but not b or o (French octet). Unless explicitly stated otherwise, one byte is eight bits (see Binary prefixes).
 * By extension, the symbols for the units of data rate kilobit per second, megabit per second and so on are kbit/s (not kbps or Kbps), Mbit/s (not Mbps or mbps), etc. Similarly, kilobyte per second and megabyte per second are kB/s (not kBps or KBps) and MB/s (not Mbps or MBps).


 * The symbol for Celsius degrees, Fahrenheit degrees and kelvins are °C (not C), °F (not F), and K (not °K).
 * If you need to express years as a unit, use the symbol a (from the latin annum) along with SI prefixes (e.g., write The half life of thorium-230 is 77 ka and The Cambrian is a geologic period that dates from 540 Ma to 490 Ma).
 * There are many types of years and anna (see year and annum). When years are not used in the layman's meaning (e.g., Julie is 20 years old) clarify which type of year is meant.


 * Roman prefixes are not used (M (103), MM(106), B (109)). Use SI prefixes instead.

Disambiguation

 * Identify and define ambiguous units on their first use in an article.
 * Avoid the use of unit abbreviations that have conflicting meanings in common units systems such as SI and US customary units:
 * Use nmi (or NM) to abbreviate nautical mile rather than nm (nanometre).
 * Use kn to abbreviate knot rather than kt (kilotonne).
 * Link such units to their definitions on first use.
 * Some different units share the same name. These examples show the need to be specific.
 * Use nautical mile or statute mile rather than mile in nautical and aeronautical contexts.
 * Use long ton or short ton rather than just ton (the metric unit—the tonne—is also known as the metric ton).
 * Use troy or avoirdupois ounce rather than just ounce in articles concerning precious metals, black powder, and gemstones.
 * Use fluid ounce explicitly to avoid confusion with weight, and specify, if appropriate, Imperial, U.S. or other.
 * Use US or imperial gallon rather than just gallon (and the same logic applies for quarts, pints, and fluid ounces).
 * A calorie (symbol cal) refers to a gram calorie while the kilocalorie (symbol kcal) refers to the kilogram calorie (also known as small calorie and large calorie respectively). When used in a nutrition related article, use kilogram unit as the primary unit. For articles with only a U.S. readership, use dietary calorie(s) with a one-time link to kilogram calorie.
 * For bits and bytes, specify whether the binary or decimal meaning of the prefixes kilo (k, K), mega (M), giga (G) and tera (T) is intended. See Binary prefixes


 * In tables and infoboxes, use unit symbols and abbreviations—do not spell them out.
 * It may be appropriate to note that given quantities and conversions are approximate.
 * When part of a full sentence, write approximately in full (e.g., write Earth's radius is approximately 6,400 kilometres, not Earth's radius is approx. 6,400 kilometers or ''Earth's radius is ~ 6,400 kilometers).
 * In tables, infoboxes, or within brackets, use a tilde (~) or use approx. (e.g, write The capacity of a ship is sometimes expressed in gross register tons, a unit of volume defined as 100 cubic feet (~2.83 m³)).
 * Do not note a conversion as approximate where the initial quantity has already been noted as such, (e.g., write Earth's radius is approximately 6,400 km (4,000 mi), not Earth's radius is approximately 6,400 (approx. 4,000 mi).

Historical background
When measuring bits and bytes, there are two different de facto standards for defining the symbols k (often written K), M, and G: one follows the International System of Units (SI) prefixes convention using powers of 1000 (103); the other uses powers of 1024 (210). The use of the prefixes K, M, G,... to represent both decimal and binary values of computer memory originates from earliest days of computing. In 1986, the Institute of Electrical and Electronics Engineers (IEEE) and the American National Standards Institute (ANSI) formally ratified such usage, making units of measure such as “kilobyte” officially mean 1024 (210) bytes, “megabyte” to mean 10242 (220) bytes, etc. However, these prefixed forms of the byte and bit were still ambiguous because the IEEE/ANSI resolution failed to reverse the practice of taking the same unit symbols (KB, MB, GB, etc.) to mean decimal values for hard-drive capacities.

In an effort to resolve this ambiguity, the International Electrotechnical Commission (IEC) introduced distinct binary prefixes in 1998. Kibi-, mebi-, gibi- (symbols Ki, Mi, Gi,...) to replace kilo-, mega-, giga. These would exclusively mean powers of 2. In 2005, the IEEE adopted the IEC proposal after a two-year trial, thus reversing its previous position. While the IEC proposal has seen a gradual adoption in the scientific literature, virtually all general-interest computer publications (both online and print), computer manufacturers, and software companies continue to follow the long-held practice in which SI-prefixed versions of byte and bit have the binary meanings for solid-state memory, and the decimal meanings for most spinning-disk mass storage. Consequently, the IEC-prefixed forms of the byte and bit, such as kibibyte and mebibyte, and their unit symbols (KiB and MiB) are unfamiliar to the typical Wikipedia reader.

MoS convention
After many years of debate, it was agreed that the prefixes K, M, G,... although familiar, were ambiguous for quantities of bits and bytes. It was also agreed that IEC prefixes, while not ambiguous, were rarely used and therefore unfamiliar. Consensus was reached that the spirit of the MoS was better reflected by having familiar but ambiguous units, rather than unambiguous but unfamiliar units.


 * Editors should use the conventional prefixes, such as kilobyte (KB) and megabyte (MB), and disambiguate where necessary.
 * Editors should specify if the binary or decimal meanings of K, M, G,... are intended as the primary meaning. Consistency within each article is desirable, but the need for consistency may be balanced with other considerations.
 * The definition most relevant to the article should be chosen as primary one for that article (e.g., specify a binary definition in an article on RAM, and decimal definition in an article on hard drives).
 * Where consistency is not possible, specify wherever there is a deviation from the primary definition.


 * To avoid controversy—the IEC prefixes debate did span over many years—disambiguation should be shown in bytes or bits, clearly showing the intended base (binary or decimal). There is no preference in the way to indicate the number of bytes and bits, but there should be consistency (e.g., write A 64 MB (64×10242 bytes) video card and a 100 GB (64×10003 bytes) harddrive, A 64 MB (64×220 bytes) video card and a 100 GB (64×109 bytes) hard drive or A 64 MB (67,108,864 bytes) video card and a 100 GB (64,000,000,000 bytes) harddrive are all acceptable, but not A 64 MB (67,108,864 bytes) video card and a 100 GB (64×10003 bytes) hard drive). Footnotes may be used for this purpose.
 * IEC prefixes are not to be used on Wikipedia except under the following circumstances:
 * when the article is on a topic where the majority of cited sources use the IEC prefixes,
 * when directly quoting a source that uses the IEC prefixes,
 * in articles specifically about or explicitly discussing the IEC prefixes.

Unit conversions

 * Conversions to and from metric units and US or imperial units should generally be provided. There are some exceptions:
 * Articles on scientific topics where there is consensus among the contributors not to convert the metric units, in which case the first occurrence of each unit should be linked.
 * When inserting a conversion would make a common expression awkward (the four-minute mile).
 * In topics such as the history of maritime law in which imperial units (e.g. miles and nautical miles) are part of the subject, it can be excessive to provide SI conversions at each instance a unit occurs. In such cases, it is best to explicitly mention that this topic will use these units without providing conversion at each instance in the lead or in the introduction, in which case the first occurrence of each unit should be linked.


 * Converted values should use a level of precision similar to that of the source value (e.g. write the Moon is approximately 380,000 kilometres (240,000 mi) from Earth, not the moon is approximately 380,000 kilometres (236,121 mi) from Earth).
 * In the main text, spell out the main units and use unit symbols or abbreviations for conversions in parentheses (e.g a pipe 5 centimetres (2 in) in diameter and 37 kilometres (23 mi) long).
 * When there is consensus to do so, the main units may also be abbreviated in the main text after the first occurrence.


 * In a direct quotation, always keep the source units.
 * Conversions required for units cited within direct quotations should appear within square brackets in the quote.
 * Alternatively, you can annotate an obscure use of units (e.g. five million board feet of lumber) with a footnote that provides conversion in standard modern units, rather than changing the text of the quotation. See the style guide for citation, footnoting and citing sources.


 * Convert or unit-specific templates from Category:Conversion templates can be used to convert and format many common units in accordance with this manual of style.

Notations

 * Scientific notation is done in the format of 1 leading digit/decimal marker/rest of digits/×10n, where n is the integer that gives one leading digit.
 * $1.602 C$ is a proper use of scientific notation.
 * $4.535 u/atom$ is not a proper use of scientific notation.


 * Engineering notation is done in the format of leading digits/decimal marker/rest of digits/×10n, where n is a multiple of 3. The number of leading digits is adjusted accordingly.
 * $6.02 atom$ is a proper use of engineering notation.
 * $123,123.123$ is a not proper use of engineering notation.


 * When using either scientific or engineering notation in articles, consistency is preferred (e.g., do not write A $2.2 y$ region covered by $1.602 kg$.
 * Use discretion when it comes to using scientific and engineering notation. Not all values need to be written in it (e.g., do not write the house is $1.602$ old, but rather the house is 125 years old).
 * Sometimes it is useful to compare values with the same power of 10 (often in tables) and scientific or engineering notation might not be appropriate.

Uncertainty

 * Uncertainties can be written in various ways:
 * Value/±/uncertainty/×/10n/unit symbol (e.g. $2.2 y$
 * Do not group value and uncertainty in parenthesis before the multiplier (e.g. do not write (15.34±0.35) × 1023 m)
 * Value/superscript positive uncertainty/subscript negative uncertainty/×/10n/unit symbol (e.g. $1.602$)
 * Value(uncertainty in the last digits)/×/10n/unit symbol (e.g. $160.2$)
 * Value/±/relative uncertainty(percent)/unit symbol (e.g 12.34±5% m2)

}}
 * val is meant to be used to automatically handle all of this, but currently has some severe issues (see Talk:val). Use with great consideration and always check that it will give the correct results before using it.

Votes on proposal
If this get no response by Saturday morning, or that only a minority of people feel that this does not maximizes the level of agreement, I'll upload this text as is (minus perhaps copy-editing) unless there are new developments, in which case I'll incorporate these developments as well. Headbomb (ταλκ · κοντριβς) 18:38, 5 June 2008 (UTC)


 * So... even if no one at all had voted on this by Saturday, you would have taken it upon yourself to upload it?? I think you are overly anxious here. This is consensus-driven, not schedule-driven. See my below comments. But I suggest you start by uploading those sections (colorboxes) that have a clear consensus now. It is wrong to attempt to drag the whole greenbox and all its subboxes into a wholesale replacement of MOSNUM on the pretense that little to no response at all constitutes an unspoken OK to move forwards. Greg L (talk) 22:23, 5 June 2008 (UTC)


 * This received over 500 edits in the last week (with none yesterday). If there was no edits on this by Saturday morning that would've meant everyone was dead. I said that to make sure people had an incentive to respond more than anything else, since no one said a thing in the last day or two. Headbomb (ταλκ · κοντριβς) 22:58, 5 June 2008 (UTC)


 * It looks like nobody has posted substantive reasons to object to the upload. Headbomb would you like to do the honours? :) By the way, I would like to be the first to say congratulations to you for managing to tackle an issue like this at MOSNUM. ;) Once the upload is done I would advocate archiving all of the sections of this talk relating to this topic. This will make this page a lot shorter. :) Fnagaton 08:42, 7 June 2008 (UTC)


 * Thanks. I would certainly like to do the honours :P, but I'll wait until later today when the edit traffic is lower so I can archive things properly. I've also yet to read all the edits made this morning. Headbomb (ταλκ · κοντριβς) 14:50, 7 June 2008 (UTC)


 * Good luck. I'd say any votes about "there is no consensus" belongs in the personal opinion section because the claim is unsubstantiated given the evidence we have here. Fnagaton 15:02, 7 June 2008 (UTC)

Support - The text maximizes the level of agreement between all parties
I, the undersigned, support the uploading of this text. While I may not be happy with everything in the text, I realize that my voice is only one of many, and I agree this text maximizes the level of agreement between all parties as of the time of my signing, and will facilitate later revisions of the MOSNUM.
 * Support: Headbomb (ταλκ · κοντριβς) 18:38, 5 June 2008 (UTC)
 * Support: Fnagaton 19:25, 5 June 2008 (UTC)
 * Support: --Marty Goldberg (talk) 20:02, 5 June 2008 (UTC)
 * Support: --Pyrotec (talk) 22:37, 5 June 2008 (UTC)
 * Support: Greg L (talk) 22:53, 5 June 2008 (UTC)
 * Support: SWTPC6800 (talk) 00:35, 6 June 2008 (UTC)
 * Support: &mdash; MJC detroit  (yak) 03:39, 6 June 2008 (UTC)
 * Support: --Francis Schonken (talk) 12:10, 6 June 2008 (UTC) (note applied some minor cpedit to the collapsible box above )
 * Support: J IM ptalk·cont 20:55, 6 June 2008 (UTC) a step forward though details may need further attention
 * Support: Rilak (talk) - A step forward towards an encyclopedia with consistent usage of units.
 * Support:

Oppose - The text maximizes the level of agreement between all parties
I, the undersigned, oppose the uploading of this text. While I may not be happy with everything in the text, I understand that my personal feelings are inconsequential here and the reason of my opposition has nothing to do with my personal feelings on this. I simply do not think that this text maximizes the level of agreement between all parties as of the time of my signing.
 * Oppose: Thunderbird seems to be opposing because he feels this does not have consensus. - Headbomb (ταλκ · κοντριβς) 15:31, 6 June 2008 (UTC)
 * Oppose: Woodstone (talk) 19:05, 7 June 2008 (UTC). This whole voting process was made into an absurdity by repeated modification of votes by others than the voter. I oppose uploading because by the malicious conduct of some of the participants, a proper process was blocked. I wonder if they will censor this comment as well. I oppose parts of the content:
 * because the bullet explicitly banning IEC does not have consensus and is an unnecessary form of censorship
 * because the criterion of "familiarity" is too vague and given undue weight (especially in the summary).
 * because only one unit is singled out for being banned. Where is the statement explicitly banning all other "unfamiliar "units? Like fathom or cubit?


 * Oppose:

Support - Personal opinion
I, the undersigned, support the uploading of this text, because I personally feel that this text is adequate. That this text does or does not maximize the level of agreement is inconsequential to me. I also understand that, because of my lack of concern for agreement between all parties, my vote will be disregarded.
 * Support:
 * Support:
 * Support:

Oppose - Personal opinion
I, the undersigned, oppose the uploading of this text, because I personally feel that this text is inadequate. That this text does or does not maximize the level of agreement is inconsequential to me. I also understand that, because of my lack of concern for agreement between all parties, my vote will be disregarded.
 * Oppose:
 * Oppose:
 * Oppose:

Headbomb, I leave for you to decide which box this fits in. I oppose statements that do not carry a broad consensus. I oppose guidelines that include such statements. Thunderbird2 (talk) 07:55, 6 June 2008 (UTC)

Comments on votes
{{hidden |headercss=background:#E9FFEF; border:1px 1px solid #96FFA8; |contentcss=border:1px 1px solid #96FFA8;|header= Comments on votes|content=
 * The notion that there could be votes that will be ignored off-hand is too absurd to consider. Also removing some-one else's vote (as happened to mine) is a totally unacceptable action. Restore vote. &minus;Woodstone (talk) 19:51, 5 June 2008 (UTC)


 * Headbomb it looks like Woodstone's oppose vote and Gerry Ashton's oppose vote are both based on personal feelings rather than the more logical and factual issue of "maximising the level of agreement between all parties".Fnagaton 20:03, 5 June 2008 (UTC)


 * If you vote because you don't agree with the text, then you vote for personal reasons, not because you think that the text reflects the highest level of agreement as of now. I apologize for removing Woodstone's vote, the revert was part 1 of two edits. I wanted to restore the voting sections as they were, then re-add Woodstone's vote, but something came up and I had to leave my computer for a while. Woodstone beat me to the re-addition of his vote during the time I was gone. Headbomb (ταλκ · κοντριβς) 20:31, 5 June 2008 (UTC)


 * I agree, they had enough time and warning to substantiate their counter arguments. Fnagaton 20:48, 5 June 2008 (UTC)


 * Headbomb: I reject your contention or plan that there is a fixed timeline to upload this. This is not schedule-driven; where the votes stand and precisely what text the votes really apply to and whether or not it is clear what text truly has a consensus are the only valid metrics here. Notwithstanding what Omegatron and Thunderbird2 feel about FCL and how it didn't have a consensus to be posted, eight editors who voted for it and some outside uninvolved editors who watched over the proceedings at that time say FCL did have a consensus. I just saw someone's proposed "condensing" of FCL into three bullet points that didn't remotely touch upon the issue of what do do when a discipline consistently uses non-SI units. It's entirely unclear to me as to what text the votes on FCL currently apply to. My best guess is that the majority of them apply to the original text and not the three bullet points (which I just struck). Setting aside the issue of whether or not FCL had a proper consensus to be posted in the first place (an issue that is in dispute), there is absolutely, positively, no consensus that FCL should be removed from MOSNUM. If you want to upload the greenbox on a schedule, I suggest that you leave the current, full-size form of FCL in place until a clear agreement can be reached on the truncated form. Another suggestion is that you start replacing the current contents of MOSNUM with the various boxes piece by piece. Some sections, like scientific notation, are effectively stand-alone issues. I can see no reason that sections that currently have a clear consensus can't go to MOSNUM now. Greg L (talk) 22:08, 5 June 2008 (UTC)


 * This version of the red box (the bullets version) has my vote. I'll write why later on after I get some sleep, too tired to post now. Fnagaton 22:18, 5 June 2008 (UTC)


 * As long as the following wording stays in the greenbox:

{{quotation|Since some disciplines uses units not approved by the BIPM, or may format them in a way that differs from BIPM-prescribed format, when such units are normally used by a clear majority of relevant sources articles related to those disciplines should reflect this (e.g., using cc in automotive articles and not cm3). Such use of non-standard units are always linked on first use.}}


 * ...Fnagaton may revise my votes as he sees fit Thursday and Friday. I am out of town on the FDA clinical trial during that time and have limited time to devote to this. Since this is a critical juncture, with impending posting for Saturday (I still think we can't treat this like a runaway train), I will bow to Fnagaton's judgment here in order to help Headbomb's proposal achieve its much-needed consensus. Greg L (talk) 22:53, 5 June 2008 (UTC)


 * I have just reviewed the Proposed Text and think it is the best compromise that can be obtained here on MOSMUN. Good work Headbomb. -- SWTPC6800 (talk) 02:03, 6 June 2008 (UTC)


 * I am not comfortable with the bullet that starts: When you feel there is a need to depart from these guidelines... Maybe it's a necessary evil but, I don't think we should give a loophole statement for people to take advantage of.  There was also a statement on imperial units that was changed to restrict their use from the greenbox I voted on a few day ago so I changed it back.  Also, in the future, can we lose the statement on restricting the use of SI units in maritime law?  It seems too narrow and an unneeded exception to the mosnum. &mdash; MJC detroit  {{sup| (yak) }} 03:39, 6 June 2008 (UTC)


 * You made me realize that this point would fit more naturally into the overview. I moved it there and merged it with current text. Content is the same, only more concise. It's uncontroversial IMO, but please review to ensure that you are still comfortable with it.Headbomb (ταλκ · κοντριβς) 04:15, 6 June 2008 (UTC)


 * Much better. The wording now seems more like a guideline than a loophole.  &mdash; <font color="#0000CD">MJC <font color="#FF0000">detroit  {{sup| (yak) }} 11:46, 6 June 2008 (UTC)

Point of order on vote

 * The refactoring of vote reasons by proponents is intollerable and this vote is null-and-void. --Gerry Ashton (talk) 21:14, 5 June 2008 (UTC)


 * What's so despicable with my wording? I carefully choose these words so people could either agree or disagree that this text represents accurately the maximum level of agreement as of now. THAT is what needs to be considered at this time. If you disagree with the text, then voice your concerns in the appropriate colorbox. But your disagreeing with the text has no bearing on whether or not this text does represent the maximum level of agreement as of now. Opposing the upload because you disagree with the text simply goes against how things should be done on Wikipedia, and thus we can ignore that opposition. I made the option availible for the people who cannot stop their personal feelings from interfering with their assessment of the situation. Note that I did not used the word consensus because people think that consensus is about everyone being in 100% agreement. Headbomb (ταλκ · κοντριβς) 21:23, 5 June 2008 (UTC)


 * I initially indicated opposition to the upload, which I now admit was an error. I should have worded my post better to make it clear that I was only opposed to the despicable vote, which labeled every opposition category as something that would be ignored, as if Headbomb owned the guideline, and had any authority to ignore anything. Just to be clear, I am declaring this vote null-and-void on my own authority as a private individual, and not as a representative or agent of any other entity. --Gerry Ashton (talk) 21:31, 5 June 2008 (UTC)


 * Suit yourself. I still don't see what's so despicable about this vote. And it's not that I have the "authority" to decide which vote is valid and which is not, it's that Wikipedia works on the principle that things should reflect the maximum level of agreement between people. Opposition and support is voiced in each box. Opposition that is substantiated is valid and was addressed (just go through last month's history and you'll see). Sometimes people still disagreed after opposition was addressed, which is a bummer, but to be expected. Opposition that is unsubstantiated, however can be disregarded, because its unsubstantiated and therefore cannot be addressed. Seems like any other vote done on wikipedia to me, with the notable addition that I made it very clear (IMO) what this vote is about—does this represent maximum agreement? If people want to say they disagree with the text, they can do so, however this is completely irrelevant since no one is concerned about whether Jimmy Longshorts disagrees with it, we're concerned about whether or not this is the text that will make the most people the most happy. Headbomb (ταλκ · κοντριβς) 22:03, 5 June 2008 (UTC)


 * No Gery Ashton, it is not "null-and-void". What Headbomb has done is to apply less weight to those editors who vote without a substantive argument for or against, it is completely fair. Failing to substantiate a position means that argument is much weaker than an argument that also has a substantive reason. It is a long standing principle that consensus is reached by good arguments, not by how many editors vote. Fnagaton 21:18, 5 June 2008 (UTC)


 * The vote is null-and-void. However, sufficient information might exist outside of the vote to justify uploading the material. If such an upload is to occur, I think it has a better chance of "sticking" if it is uploaded by an uninvolved editor. --Gerry Ashton (talk) 21:27, 5 June 2008 (UTC)


 * The vote is "null-and-void" because there is already consensus for the changes? I can agree to that.Fnagaton 21:38, 5 June 2008 (UTC)


 * I feel that way too, but I wanted an explicit endorsement for the uploading so no edit war could ensue. Thunderbird will probably oppose because of personal feelings tomorrow, as he cannot vote tonight (he needs to find a better computer, as his current one cannot display the talk page). Headbomb (ταλκ · κοντριβς) 00:46, 6 June 2008 (UTC)

Two points of order: Thunderbird2 (talk) 07:40, 6 June 2008 (UTC)
 * 1) This page is huge.  Yesterday I was able to read it but not edit it.  In previous occasions I have been unable even to load it on my browser.  This is a big change that needs to have broad consensus.  To be sure you have that, please make sure that all editors who may wish to edit it are able to do so.
 * 2) There are several editors who have been alienated by the tactics of other editors on this page, and no longer contribute to this page for that reason.  These editors should be contacted and their views sought.


 * The repeated refusal of some editors here to answer questions and provide valid argument are "tactics" that have driven away other editors who support the deprecation of IEC from contributing to this page. The other edit warring "tactics" of some editors who promote IEC prefixes have also driven away other editors who prefer that IEC prefxies are not used. There is consensus for the change due to the weak unsubstantiated arguments for keeping IEC compared to the much stronger arguments for the partial deprecating of IEC prefixes. Fnagaton 08:22, 6 June 2008 (UTC)


 * Well if your computer can't handle 500 k of text... not much
 * I've contacted many user who've participated in the past debates. For the list, check out the first figure of merit for the FCL greenbox in the archives (about 20 people). Response ranged from none at all, to refusal to get involved because of the tactics of IEC proponents, and some participated in the debates. Headbomb (ταλκ · κοντριβς) 14:57, 6 June 2008 (UTC)


 * I've contacted many user who've participated in the past debates ... I know, and I applaud this action.  But you may not realise that by then the atmosphere had already soured.  Editors who used to contribute regularly, but now do so little or not at all, include Gene Nygaard, Jimp, LeadSongDog, Lightmouse and Omegatron and Tony1. There are also others from the March IEC archive I posted below. Thunderbird2 (talk) 15:42, 6 June 2008 (UTC)


 * Here is something to think about Thunderbird2. Perhaps those people you list are staying away because they know their arguments are weaker than the much stronger arguments already presented. Fnagaton 15:52, 6 June 2008 (UTC)


 * "Thunderbird seems to be opposing because he feels this does not have consensus" is not really a good reason (more like personal opinion) since TB2 did refuse to answer Headbomb's question, which doesn't really demonstrate a willingness to work towards consensus in the first place. Fnagaton 16:01, 6 June 2008 (UTC)


 * ... or maybe they're tired of having their arguments simply brushed aside. As for me, I'm not staying away as such: an idea dawned on me a couple of days ago and I've been busy rewriting a couple of templates. J IM ptalk·cont 21:15, 6 June 2008 (UTC)


 * <Moved from the vote table above because there is also a vote for you there and this comment was in the wrong place> I oppose it because of one statement that flies in the face of existing consensus. To have consensus you need to show that you have tried to address my concern. But all you do is brush it aside, over and over again, claiming that my arguments are unsubstantiated.Thunderbird2 (talk) 07:54, 7 June 2008 (UTC)


 * We have tried to address your concerns, many times, but each time you have failed to give substantive reasons for your claims, so according to Wikipedia guidelines and policy these unsupported claims can be largely rejected. Or you have used untrue accusations as an excuse for not giving answers. Fnagaton 08:02, 7 June 2008 (UTC)


 * <Moved from the vote table above because there is also a vote for you there and this comment was in the wrong place> The statement in question corresponds very closely to the thesis: IEC units should be banned except for direct, verbatim quotes, and articles discussing the units themselves, which was opposed by 11 editors out of 11 in March. There is plenty of discussion in the same archive for the reasons those editors voted the way they did. To overturn such a strong consensus you need to show there has been a shift in the intervening months. Thunderbird2 (talk) 08:01, 7 June 2008 (UTC)

}}
 * Again, you cannot take the results of one vote and try to claim that applies to the whole proposed guideline text. Consensus is made by good arguments, not by the number of people who vote on one question. Fnagaton 08:04, 7 June 2008 (UTC)

Is there consensus for the promotion or deprecation of IEC units?
{{hidden |headercss=background:#E9FFEF; border:1px 1px solid #96FFA8; |contentcss=border:1px 1px solid #96FFA8;|header= Consensus for promotion or deprecation of IEC units|content=

The following is from a recent archive:

{{hidden |headercss=background:#E9FFEF; border:1px 1px solid #96FFA8; |contentcss=border:1px 1px solid #96FFA8;|header= Archived votes that were made two to three months ago|content=

Attempt to find out where everyone stands on separate points
So, here's some statements. Under each one, it would be useful if anyone who feels themselves involved in this debate indicate whether they agree or disagree with the statement. Hopefully, they';ll be no need in this section to say more than that; hopefully we can leave subtle distinctions for now, and caveats will be covered by the other points. However, if you really need to say more, then that could make sense; there's just no need to explain why you agree or disagree here. I've indicated my own views through these. If you want to add an extra statement, go right ahead. Just to note, this time I'm not asking people to judge where there is or isn't consensus, just to give their own views.

The rationale here is that I'm fairly convinced that we've gotten tangled up and don't realise which things we already all (or nearly all) agree upon. If you don't want to pick "agree" or "disagree", feel free to say "undecided". SamBC(talk) 18:17, 27 March 2008 (UTC)

IEC units shall not routinely be used, except in quotes, articles specifically discussing the units, and articles in which they are employed by the primary cited source

 * Question in the interests of comparability, can we read this as being equivalent to the "should be banned" wording, or the "should be discouraged" wording, or neither; if neither, how do you mean it to differ? SamBC(talk) 20:07, 27 March 2008 (UTC) The new title is as close to what the proposal actually calls for as I can make it. As this is essentially voting on the proposal, I think it is fair to assume that the votes below, if everyone weighed in here, would reflect what is seen in the above voting. Greg L (my talk) 23:12, 28 March 2008 (UTC)
 * Agree Greg L (my talk) 18:28, 27 March 2008 (UTC)
 * Disagree Thunderbird2 (talk) 18:40, 27 March 2008 (UTC)
 * Disagree Jeh (talk) 20:48, 27 March 2008 (UTC)
 * Disagree Tom94022 (talk) 05:11, 28 March 2008 (UTC)
 * Agree Fnagaton 16:41, 28 March 2008 (UTC)
 * Disagree LeadSongDog (talk) 23:47, 28 March 2008 (UTC)
 * Disagree Dpbsmith (talk) 23:50, 28 March 2008 (UTC)
 * Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)
 * By the way, if you click on this link: [ edit ], you can vote in all these segments in a single session. Greg L (my talk) 22:51, 28 March 2008 (UTC)


 * Disagree, mathematical conversions to different units of measurement are always allowed, and well that they should be, here and elsewhere. The use of an ambiguous unit over an unambiguous one does readers a tremendous disservice. Seraphimblade Talk to me 15:07, 29 March 2008 (UTC)
 * Disagree, obviously. — Christoph Päper 16:41, 29 March 2008 (UTC)
 * Disagree, for reasons in sections below. — Omegatron 05:47, 6 April 2008 (UTC)

IEC units should be banned from wikipedia outright, except where policy would require their use

 * Disagree SamBC(talk) 18:17, 27 March 2008 (UTC)
 * Disagree Thunderbird2 (talk) 18:40, 27 March 2008 (UTC)
 * Agree (except where policy would require {or permit} their use, which is similar to the above) Greg L (my talk) 18:28, 27 March 2008 (UTC)
 * Disagree Jeh (talk) 20:48, 27 March 2008 (UTC)
 * Disagree Tom94022 (talk) 05:11, 28 March 2008 (UTC)
 * Agree Fnagaton 16:41, 28 March 2008 (UTC)
 * Disagree LeadSongDog (talk) 23:47, 28 March 2008 (UTC)
 * Disagree Dpbsmith (talk) 23:59, 28 March 2008 (UTC)
 * Disagree — Christoph Päper 16:41, 29 March 2008 (UTC)
 * Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)
 * Disagree — Omegatron 05:48, 6 April 2008 (UTC)

IEC units should be banned except for direct, verbatim quotes, and articles discussing the units themselves

 * Disagree SamBC(talk) 18:17, 27 March 2008 (UTC)
 * Disagree (partial solution) Greg L (my talk) 18:32, 27 March 2008 (UTC)
 * Disagree Thunderbird2 (talk) 18:41, 27 March 2008 (UTC)
 * Disagree Jeh (talk) 20:48, 27 March 2008 (UTC)
 * Disagree Tom94022 (talk) 22:31, 28 March 2008 (UTC)
 * Disagree LeadSongDog (talk) 23:49, 28 March 2008 (UTC)
 * Disagree Dpbsmith (talk) 23:59, 28 March 2008 (UTC)
 * Disagree, proper use should be encouraged. Seraphimblade Talk to me 15:05, 29 March 2008 (UTC)
 * Disagree — Christoph Päper 16:41, 29 March 2008 (UTC)
 * Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)
 * Agree DavidPaulHamilton (talk) 23:31, 1 April 2008 (UTC) strike the sock J IM ptalk·cont 08:06, 6 June 2008 (UTC)
 * Disagree — Omegatron 05:49, 6 April 2008 (UTC)

IEC units should be discouraged, except where they are widely used by the sources for an article

 * Question What I mean is that there's a world of difference between deprecating IEC prefixes and encouraging alternatives. Which is intended here? Thunderbird2 (talk) 23:27, 27 March 2008 (UTC)
 * Answer My dictionary defines "discourage" as "show disapproval of". Thunderbird2 (talk) 23:40, 27 March 2008 (UTC)
 * Answer the general meaning of this is meant to be basically the same as the extra point added by Greg. It's probably my worst-worded point, actually. Basically, by discourage I was meaning to indicate that we might say "don't use these without some good reason". Like "should not generally be used", followed by the exceptions that are seemingly accepted by even the most anti-IEC participants here (ie direct quotes, articles talking about the IEC units, and articles whose sources use IEC). SamBC(talk) 00:14, 28 March 2008 (UTC)
 * Agree SamBC(talk) 18:17, 27 March 2008 (UTC)
 * Conditionally If the proposal isn’t adopted, this is a good first step. Greg L (my talk) 23:15, 28 March 2008 (UTC)
 * Undecided My position on this depends on how you define "discouraged". Thunderbird2 (talk) 18:46, 27 March 2008 (UTC)
 * Disagree Thunderbird2 (talk) 23:46, 27 March 2008 (UTC)
 * Disagree Jeh (talk) 20:48, 27 March 2008 (UTC)
 * Disagree Tom94022 (talk) 05:12, 28 March 2008 (UTC)
 * Agree Fnagaton 16:42, 28 March 2008 (UTC)
 * Disagree LeadSongDog (talk) 23:51, 28 March 2008 (UTC)
 * Disagree Dpbsmith (talk) 00:00, 29 March 2008 (UTC)
 * Disagree, conversion of units of measurement is a simple, factual, indisputable mathematical task and has never been forbidden, even if sources may use a different measurement type. There's no difference here. Seraphimblade Talk to me 15:04, 29 March 2008 (UTC)
 * Disagree — Christoph Päper 16:41, 29 March 2008 (UTC)
 * Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)
 * Disagree — Omegatron 05:50, 6 April 2008 (UTC)

IEC units are good, and should be used wherever feasible

 * Comment Would switch to agree if "should be used ..." were replaced with "may be used where appropriate". Thunderbird2 (talk) 10:07, 29 March 2008 (UTC)
 * Disagree SamBC(talk) 18:17, 27 March 2008 (UTC)
 * Disagree Greg L (my talk) 18:32, 27 March 2008 (UTC)
 * Disagree Thunderbird2 (talk) 18:48, 27 March 2008 (UTC)
 * Agree Jeh (talk) 20:48, 27 March 2008 (UTC)
 * Disagree I would agree if the work feasible were changed to appropriate.Tom94022 (talk) 05:14, 28 March 2008 (UTC)
 * Agree if word "feasible" is changed to "appropriate", as with Tom94022. Dpbsmith (talk) 23:50, 28 March 2008 (UTC)
 * Agree if word "feasible" is changed to "appropriate", as with Tom94022. LeadSongDog (talk) 23:53, 28 March 2008 (UTC)
 * Agree for the symbols at least. — Christoph Päper 16:41, 29 March 2008 (UTC)
 * Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)
 * Agree personally, but recognize that some other Wikipedians abhor them. "Appropriate" is better for compromise purposes. — Omegatron 05:53, 6 April 2008 (UTC)

IEC units should not be used in the general text of an article, but are an ideal choice for disambiguation

 * Disagree 18:17, 27 March 2008 (UTC)
 * Disagree Greg L (my talk) 18:32, 27 March 2008 (UTC)
 * Disagree Thunderbird2 (talk) 18:49, 27 March 2008 (UTC)
 * Disagree IEC units SHOULD be used in the general text, that is the whole point. Jeh (talk) 20:48, 27 March 2008 (UTC)
 * Disagree Tom94022 (talk) 05:14, 28 March 2008 (UTC)
 * Disagree Fnagaton 16:42, 28 March 2008 (UTC)
 * Disagree LeadSongDog (talk) 23:55, 28 March 2008 (UTC)
 * Disagree Dpbsmith (talk) 00:00, 29 March 2008 (UTC)
 * Disagree, why not use a well-defined term when appropriate? Seraphimblade Talk to me 15:02, 29 March 2008 (UTC)
 * Undecided, because I disagree with the first part and agree to the second. — Christoph Päper 16:41, 29 March 2008 (UTC)
 * Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)
 * Disagree - Should be used in general text of the article. Relegating disambiguation to footnotes is a poor solution. — Omegatron 05:54, 6 April 2008 (UTC)

}}


 * I see no consensus either for promotion or for deprecation. Therefore MOSNUM should be silent on this issue. Thunderbird2 (talk) 07:45, 6 June 2008 (UTC)


 * There is a difference between use and promotion. J IM ptalk·cont 08:04, 6 June 2008 (UTC)


 * The consensus is as demonstrated by the current votes and discussions. What you have just done is to cherry pick a few votes on individual subjects and you have not considered all of the votes that went on at that time. What that does is not consider the consensus for text of the proposed guideline as a whole. If you actually look at the other votes, the ones you have not quoted, then the situation becomes clear that IEC prefixes are not "the best method to disambiguate “megabyte”". And in any case, consensus is not created by how many people you can show voting, consensus is made by good arguments. And the fact is there have been only weak arguments to keep IEC prefixes and very strong arguments for the deprecation of IEC. Read WP:UNDUE Fnagaton 08:05, 6 June 2008 (UTC)


 * We spent the last two months working on this proposal, many of us now having more bruises than before the start of the re-write, but have been able to set differences aside and argue with arguments rather simply say "I like it" or "I don't like it". I've invited a wide bunch of people to participate and did not pander to a specific crowd. I've repeatedly invited you, amongst others, to explicit the reasons of your concerns with the purplebox, and in two weeks or so, you've yet to give an answer, as well as anyone opposing the partial deprecation of IEC units. You say that this proposal does not have consensus, yet out of the people who weighted on whether or not this proposal has consensus, 8 out of 9 thinks it does, and the only one who thinks it doesn't is you, making your statement pretty self-referential.


 * I don't care that a vote 2 months ago said that people were against the deprecation of IEC units. Headcounts are meaningless on their own. The reasons for opposition were very seldom given, and when a reason was given it was always very weak in the face of the counter-argument. In the last two months, everyone who gave reasons for their position were not only heard, but their input often translated into a modification of one of the boxes that went along what they said. Wikipedia is not a democracy. And before you bring it up, none of the votes here is about having 50%+1 agreement and enforce that decision. The colourboxes were there so people could express their level of agreement with each of the boxes, and voiced their concerns. They were useful tools, as it allowed us to focus the discussion.


 * I think everyone here will recognize that others and I worked hard to mediate the debate, to bring sensible solutions to conflicting viewpoints, and to overall have a debate founded on the quality of the arguments brought to the table. This is reflected by near-unanimous agreement on the content of each colourbox by everyone who bothered to give a reason for their opposition other than "I don't like it". This vote here is to make sure that people agree that this actually has consensus, rather than asking them if they support this version. There are two reasons for this. First, this does not ask if they personally like the text, but if they feel that the text has consensus and can be uploaded. And from the looks of it, all but you think it's ready for upload. Headbomb (ταλκ · κοντριβς) 15:39, 6 June 2008 (UTC)

Thunderbird2 (talk) 16:35, 6 June 2008 (UTC)
 * Some replies:
 * 1) in two weeks or so, you've yet to give an answer What do you mean?  I have repeatedly explained that there is no justification for the deprecation of IEC units, and there are reams and reams of archives explaining why, including a brief summary on your Talk page.  What more are you looking for?
 * 2) You say that this proposal does not have consensus … making your statement pretty self- referential What I am saying is that the deprecation of IEC units has no consensus.  And as I have explained before, that is not my opinion but that of a large majority of editors who voted on this page in March.  The green box has my support.  The purple box would also have my support without said deprecation.  Why do you make no attempt to address the problems introduced by this deprecation?
 * 3) when a reason was given it was always very weak in the face of the counter-argument In what sense is it a weak argument to say that we should not deprecate unambiguous units?  In what sense is it a weak argument to say that we should not deprecate international standard units?


 * No, you haven't repeatedly explained  there there is no justification for partial deprecation, you've repeatedly stated  that there is no justification for partial deprecation. Saying we should not deprecate IEC units is not an argument, it's a statement. Saying we shouldn't deprecate IEC units because of a vote 2 months ago is an argument, but it's poor as hell since those voting for IEC units did not provide good arguments for their vote. Saying we shouldn't deprecate IEC units because there is no consensus is simply nonsensical, as there is consensus to do so. Everyone but you agrees that this text has consensus. Disagree all you want, but the fact remains that everyone but you feels that there is. Headbomb (ταλκ · κοντριβς) 16:56, 6 June 2008 (UTC)


 * I agree with Headbomb because TB2 has only made statements and repeatedly failed to explain why with any kind of valid argument. The only thing that "does not have justification" is TB2 claiming "there is lack of consensus" because that claim is completely false. The justification for the deprecation of IEC prefixes comes from the much stronger arguments that explain why. Fnagaton 17:14, 6 June 2008 (UTC)


 * I am beginning to find this discussion rather amusing - except for the fact that this whole thing has the appearance of a religious war. I have been a software engineer for 20 years but until reading the discussion of the IEC prefixes, I had never heard of them. That clearly tells me that they are far too obscure to be used in a general article without confusion. I contend that many readers (perhaps even most readers) will look at MiB and decide that the author is an idiot who can't even spell MB correctly. Dfmclean (talk) 17:25, 6 June 2008 (UTC)


 * No one is arguing that mebibytes are familiar, only that they are unambiguous. As an experienced software engineer, you will know from the context which kind of MB is being used.  The problem is that most WP readers don't have your knowledge.  That is the problem we are trying to address here. Thunderbird2 (talk) 17:35, 6 June 2008 (UTC)


 * Just repeating "unambiguous" on its own is not a strong argument because you don't explain why IEC prefixes should be used to counter the very strong arguments that do explain exactly why IEC prefixes should not be used. As a demonstration of how fallacious your point is: Explain exactly what is ambiguous about the number "1024". You cannot, of course, because the number itself is completely unambiguous. Fnagaton 17:50, 6 June 2008 (UTC)


 * I will respond to the substance of your remarks when you withdraw your accusation of dishonesty. Thunderbird2 (talk) 17:58, 6 June 2008 (UTC)


 * This is another example of refusing point blank to answer questions and instead misrepresenting the facts as they appear on the talk page. As I already pointed out, you are the one who needs to retract accusations, not me, because you used the word "dishonest" first in relation to yourself and you only have yourself to blame for making claims that have been proven to be false. Fnagaton 18:19, 6 June 2008 (UTC)


 * And until you do respond, your voice will carry little to no weight. If you're more concerned about your personnal reputation than answering valid remarks, suit yourself. But don't flip out that your voice will be disregarded as you effectively removed yourself from the discussion. Headbomb (ταλκ · κοντριβς) 18:12, 6 June 2008 (UTC)


 * Unfortunately, Thunderbird2, the fact that they are ambiguous ONLY matters to people who understand the subject well enough to know what MiB means in the first place. There isn't that much real difference between 200 MB and 200 MiB. Dfmclean (talk) 18:54, 6 June 2008 (UTC)


 * The megabyte is ambiguous because there are two groups who are certain that their definition is correct and that no other valid definition exists; and these definitions are not the same. There is a third group who accept that there is ambiguity. That to me means the megabyte is ambiguous. I've known for almost 40 years that a megabyte is 1024 kilobytes (= 1,048,576 bytes). The second group know that a megabyte is 1,000,000 bytes (you are wrong by the way); and the third group are aware that sometimes a megabyte is 1000 kilobytes (= 1,024,000 bytes). The MiB is not well known, but there has to be a way of removing ambiguity from a number expressed in Mbytes.Pyrotec (talk) 19:23, 6 June 2008 (UTC)


 * Exactly, which is what the disambiguation section is there for. :) Fnagaton 19:34, 6 June 2008 (UTC)


 * Good, we have agreement. Can we sort out this "storm in a tea cup" about IEC units now? :) Pyrotec (talk) 20:12, 6 June 2008 (UTC)


 * Looks pretty sorted to me. Headbomb (ταλκ · κοντριβς) 20:17, 6 June 2008 (UTC)


 * No one is "wrong", it's a matter of which convention they go by. Headbomb (ταλκ · κοντριβς) 20:29, 6 June 2008 (UTC)


 * Some of the most influential professional and international standardisation bodies have accepted the IEC prefixes. That alone is enough reason not to deprecate them in any way in an encyclopedia written by amateurs. Nevertheless, I can agree to preferring disambiguation by powers of 2 or 10. &minus;Woodstone (talk) 20:32, 6 June 2008 (UTC)


 * The stronger counter argument to that statement of fact is that the IEC prefixes are not used by the majority of reliable source we use when writing articles. Wikipedia policy says we do not give minority points of view equal footing to the majority. Fnagaton 20:38, 6 June 2008 (UTC)


 * That is not a counterargument validating a ban. At most it is one to give preference to another unit for disambiguation. &minus;Woodstone (talk) 20:48, 6 June 2008 (UTC)


 * I suggest you read WP:UNDUE and what it has to say about tiny minority points of view only being found on articles that directly discuss those topics, if they appear at all. IEC Prefixes are, at the last count by Headbomb, about 0.1% used in the real world and I'd call that a tiny minority. Effectively then this means they are banned from most articles, so we say so to make it clear and unambiguous. Fnagaton 21:02, 6 June 2008 (UTC)


 * Here's where you give an example of how such a "ban" harms wikipedia. Headbomb (ταλκ · κοντριβς) 20:57, 6 June 2008 (UTC)\


 * The slug, a unit of mass in the English system, is used in a minority of sources, but we do not include conversions to it in parentheses, let alone contemplate its preference. Indeed, the slug is more apt than you might think: "Even amongst the advocates of [the] system..., the slug has never taken shape except on paper; it has, and has had no real material existence" (from OED; 1936 F. W. LANCHESTER Theory of Dimensions & its Application for Engineers). —Centrx→talk &bull; 02:40, 7 June 2008 (UTC)


 * Why would anyone suggest disambiguating with the slug when we have the kilogram? Thunderbird2 (talk) 11:10, 7 June 2008 (UTC)


 * The "slug" is in minority use and is not familiar to most readers. An "IEC prefix" is in minority use and is not familiar to most readers. Why would anyone suggest disambiguating with an "IEC prefix" when we have the "numbers of bytes"? Fnagaton 11:14, 7 June 2008 (UTC)


 * I wonder how influence those organization are if after the 9 years IEC prefixes were around, not even 0.1% of scientific/engineering litterature uses them. Relevant policy here should be WP:Crystal Ball. Headbomb (ταλκ · κοντριβς) 20:57, 6 June 2008 (UTC)


 * The British Computer Society distributed one of its weekly electronic newsletters quite recently with an article on the MiB. The gist of the article was that no one had heard of the MiB although it had been ratified by the IEC since the early 2000s. For an organisation granting Chartered IT Professional status to qualified members; running its own exams; and having over 63,000 members in over 10 countries, the MiB does not seem to be very important a unit of measurement.Pyrotec (talk) 21:28, 6 June 2008 (UTC)


 * Much has been made over the fact that the IEEE Standards Association has adopted IEC binary prefixes. However they are just one part of the IEEE. The IEEE Publications has not adopted the IEC binary prefixes. The April 2008 issue of the flagship publication, IEEE Spectrum magazine, has this article. Tools & toys: Hacking the Nokia N800 "A lot can happen in a decade. You can hold the Nokia N800 in your hand, yet it’s a near-exact match for a high-end desktop PC from 10 years ago. It has a 320-megahertz processor, 128 megabytes of RAM, and a few gigabytes of available mass storage." It appears that IEEE Publications does not appreciate the IEC binary prefixes. -- SWTPC6800 (talk) 00:01, 7 June 2008 (UTC)


 * Yes, we went through that iin B10. To save going through the entire discussion again, here is what was said (Thunderbird2 (talk) 07:45, 7 June 2008 (UTC)):

There is no common usage among readers

 * The dispute over the IEC prefixes should have ended back in March of this year when the facts became clear that no other general-interest computer publication in world uses the IEC prefixes. At the very least, it should have become clear that we should no longer use these confusing units of measure after every voting editor stipulated to the fact that these terms were not recognized by our readers. Way back in July 2005, when Ben Arnold was voting against Omegatron’s push to begin using the IEC prefixes, he wrote “ Wikipedia is an encyclopedia, not an instrument for special interest groups (like IEC) to try to push the way they would like the world to work. We should reflect in the encyclopedia what the world is like, not what we think it should be. The reality is that kilobyte means 1024 bytes most of the time it's used. Many people who use computers (including much of the IT industry) have never heard of a kibibyte and don't use the term. We shouldn't be social engineering. ”. Those words were as true then as they are today and should have been heeded. It doesn’t matter if there is still a minority number of editors here who want to continue to use the IEC prefixes. The clear consensus now (by a wide margin) is to bring Wikipedia back into alignment with how the entire computing world communicates to a general-interest audience. All other professionally edited encyclopedias understand this simple fundamental rule and use the conventional prefixes in their computer articles. That Wikipedia will be doing the same thing, while past due, is a good thing. Greg L (talk) 01:25, 7 June 2008 (UTC)


 * Then it should so when there is consensus to do so. Not a moment before.  The majority that opposed deprecation of IEC prefixes in March was an overwhelming one, and the wording we use here should reflect that. For weeks I have been making this case, but my arguments are ignored because they are "weak" or "unsubstantiated".  Lack of consensus on its own is a strong enough reason not to include the statement.  I realise consensus can change, but I consider it unwise to ignore the opinion of editors who to took the time and trouble to participate in March, just because they are not here now. As for the substance and reasoning, there are 11 archives-full of those.  Do we really want to go through all that again? Thunderbird2 (talk) 07:04, 7 June 2008 (UTC)


 * There is consensus because the arguments the "IEC proponents" have been making are weak and have been countered by much stronger arguments from those who see IEC prefixes shouldn't be used. As Headbomb pointed out, the arguments back then in March for keeping IEC prefixes are also weak, the implication being that even if those editors were active here today and repeating the same arguments they would still be countered by the much stronger arguments. Again, you cannot take the results of one vote and try to claim that applies to the whole proposed guideline text. Consensus is made by good arguments, not by the number of people who vote on one question. Please, for the sake of the talk page stop repeating points of view that have already been discussed at great length over the previous months. Also, when quoting sections from archives it is a good idea to wrap them in sections as I have done which makes it clear they are from an archived talk page, else it will confuse people coming here. Fnagaton 07:49, 7 June 2008 (UTC)


 * It's not as if this was some secret-debate made behind the backs of pro-IEC people, it was wide-open for everyone, and I contacted people indiscriminetaly. I mean they had two friggin' months to chip in! I'm pro-IEC units, I would rather have wikipedia feature them than not feature them, but I also realize what Wikipedia is not. You say that consensus can change, and it looks like it did. Votes as of now are 9 vs 1. If that's not an overwhelming majority, then I don't know what is. And this majority is valid since it bothered to argue its point and adress whatever concerns were raised while the opposition only sat there and said either "I don't like it" or "There's no consensus!". As for going through the archives, I already did. Headbomb (ταλκ · κοντριβς) 14:38, 7 June 2008 (UTC)

}}