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)

Complete rewrite of section 4 (Greenbox)

Initial remarks

Initial remarks

Since section for was becoming cluttered, I decided to rewrite (with lots of copypasta), incorporating the changes discussed in Wikipedia:Manual of style (dates and numbers)#Third attempt and Wikipedia:Manual of style (dates and numbers)#Skeleton proposal, and some additional changes. Other than chopping fat and reorganization, notable changes include

1. Removal of the "follow current literature" section because it is covered in the "which units to use" and "unit conversion" sections.
2. Clarified what to do with direct quotation conversions
3. Units are combined by multiplication are now to be exclusively written with hyphens. Spaces aren't allowed anymore because it can lead to some confusion. For example the gram calorie is not a g·cal, but rather is a specific type of calorie. With spaces, such confusion is possible, but not with hyphens.
4. Specified how to format ranges.
5. Binary prefixes were left as is because I don't want to deal with that can of worms right now.
6. Unnecessary vagueness was removed because it should be relocated within the MOS because it doesn't have to do with units, but rather with how to write clearly.
7. Added section on uncertainties and scientific notation.

Headbomb (ταλκ · κοντριβς) 17:02, 20 May 2008 (UTC)

Units of measurements (Greenbox)

Greenbox

There is consensus that this proposal cannot be uploaded until there is consensus on the content of the Purplebox and Redbox

Headbomb

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 cm³). 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×10¹ 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.

Unit symbols

Conventions

• Values and unit symbols are separated by a non-breakable space ( ) (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 ′′ (double prime)), and ft for foot (not ft., ' (single quote), or ′ (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·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 (·) to separate the symbols. For example ms is the symbol for a millisecond, while m·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⁻¹).

• 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 km², 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 m²).
• 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 m³ or 1 × 3 × 6 m).

Confusing units and symbols

• The degree symbol is °. Using any other symbol (e.g., masculine ordinal º or ring above ˚) 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 (10³), MM(10⁶), B (10⁹)). 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

::* KB and kbit are to be preferred over kB and Kbit.

• 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)

Degree of support

User	5	4	3	2	1	0
Greg L (talk) 00:27, 3 June 2008 (UTC)			X
Headbomb (ταλκ · κοντριβς) 20:27, 30 May 2008 (UTC)		X
Jimp			×
Rilak		X
SWTPC6800			X
Thunderbird2 (talk) 07:22, 6 June 2008 (UTC)			X	X
Fnagaton 19:36, 25 May 2008 (UTC)		X
MJCdetroit 15:12, 27 May 2008 (UTC)		X
Woodstone (talk) 20:50, 2 June 2008 (UTC)				X
Pyrotec 21:57, 5 June 2008 (UTC)		X
New user

Vote and vote comments

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

Discussion of “Vote Comments”

Discussion of vote comments

Rebuttal and discussion goes here.

Greg L's vote: It is neither schizophrenic nor an attempt to "game the system". It is an attempt to make the rest of the MOSNUM go forward EVEN IF the IEC prefix debate is in a deadlock. Bizzare how one who was so prone to accused others of "radical extremism" has become a radical extremist himself. Bizzare how one who was so prone to denounce the total opposition votes of the "Follow current policy" is now totally opposing this version of things. - Headbomb (ταλκ · κοντριβς) 03:39, 21 May 2008 (UTC)

• This post is out of sequence. Let it be known to all that Headbomb is rebutting an earlier vote statement accompanying a “zero” vote. In light of his arguments below, I’ve withdrawn my zero vote, upgraded to a “1”, and withdrawn my statement that the effect was schizophrenic or an attempt to game the system. I now feel that this is simply too much to tackle in one fell-swoop and comes up short. Greg L (talk) 16:42, 21 May 2008 (UTC)

• OK, objection noted Headbomb. But over a dozen editors had a hand in crafting “Follow current literature” and they were all fully aware of the paragraph calling for no longer using the IEC prefixes. They all knew it was A) not without controversy, and B) was something that needed to be addressed nevertheless. “Complete rewrite of section 4” would have the effect of undoing all that effort. Ergo, zero. Were you expecting these editors would be pleased with this? Apparently you thought the pre-canned, accompanying vote comment saying “I understand that this is not an endorsement of either side of the binary prefix debate but rather give the state of the debate as it stands now in the binary prefixes debate archives.”… would pacify people (‘Oh, this completely bypasses the whole issue; I’m for that!’). I’m not so sure. To me this isn’t progress. But maybe that’s just me; we’ll see how others feel. Greg L (talk) 04:03, 21 May 2008 (UTC)

• Yes, and I was one of those editors. The "follow current litterature" was meant as an improvement over the old MOSNUM, and now that it was incorporated in the MOSNUM (or possibly removed by Omegatron, I don't know what's the current status), the rewrite is meant as an improvement over the current MOSNUM (including the FCL section), meaning that it will chop fat (and FCL contains a lot of it), clarify previously ambiguous rules, and merge some of contents together (including some of the FCL). IMO, the "which system to use" section of the greenbox below covers pretty much everything the FCL intended to cover and I do not see a need for a separate FCL section. If you feel that important aspects of FCL are missing, then please mention them explicitly in the comments section. If you feel that the current binary prefix section doesn't reflect the current situation of the binary prefix debate, then propose an update to that section specifically rather than paint the whole rewrite as a being hellspawned.

• This rewrite does not have for goal the resolution of the IEC prefix debate (which BTW was never tackled by the FCL in any greater details that the binary prefix section + the proposed "which system to use" section do); if that was one of the goals the MOSNUM would probably never be updated. If the issue is settled before the greenbox goes gold, then it'll be easy to incorporate those changes in the greenbox. If the issue is settled after it goes gold, then it'll be easy to incorporate the changes in the MOSNUM. But since is not the goal of the rewrite, please address this issue separately. Headbomb (ταλκ · κοντριβς) 05:15, 21 May 2008 (UTC)

For reference, here are the main points of the FCL, the rest being a ton of examples, or long-winded explanations.

• Use terminology and symbols commonly employed in the current literature for that subject and level of technicality.

• Addressed by Which unit to use's first point.

• Preference for international units

• Addresed by Which unit to use's first point.

• Discipline-specific practices : Wherever a discipline consistently uses its own units—either conventional or non-SI metric—editors should observe that practice so readers can readily converse with those knowledgeable in the discipline. (redundant with "use terminology and symbols..." if you ask me)

• Addresed by Which unit to use's first point.

• Conversions should be given where appropriate

• Addresed by Unit conversion's first point (and three sub-points).

• • Accuracy of quotes

• • Addresed by Unit conversion's third point.

• • New units unadopted by the "real world" (IEC prefixes) and state of the IEC debate

There have been occasions where standards bodies have proposed new units of measure to better adhere to the SI and/or to address ambiguities but the new units didn’t see widespread adoption. Because existing prefixed forms of the byte are ambiguous ("KB", for instance, can mean either 1024 or 1000 bytes depending on context), the IEC in 1999 released its IEC 60027-2 amendment, introducing new prefixes for bytes and bits, such as "kibibyte (KiB)", "kibibit (Kibit)", and "mebibyte (MiB)". However, the IEC prefixes have seen little real-world adoption and are therefore unfamiliar to the typical Wikipedia reader. In keeping with the principle of follow current literature, editors should use the conventional binary prefixes, such as "kilobyte (KB)" and "megabyte (MB)", for general-interest articles and clarify their meaning where necessary using familiar techniques (subject to "Binary prefixes", below).

• • Addresed by Binary prefix section

• Level of difficulty

• Addressed by Which unit to use's second point.

Headbomb (ταλκ · κοντριβς) 05:35, 21 May 2008 (UTC)

• This all seems to be a bit too ambitious Headbomb. You’ve done a lot here and it obviously took a great deal of work to do what you did. But much debate can transpire just trying to properly address a single, small issue (see Scientific notation and uncertainty, below). Realistically, I think changes to MOSNUM must occur incrementally. Greg L (talk) 15:59, 21 May 2008 (UTC)

• How is this too ambitious? It's a general cleanup and clarification of the content of the current section 4 - minus the IEC prefix. There is a general feeling that section 4 is too wordy, has unnecessary redundancy, and could use some restructuring. To fix this is the scope of this rewrite. You said that change should be incremental—this is one increment. Since scientific notation section is new it needs to be (and is being) extensively discussed before it makes it into the MOS and as such it was given its own bluebox. When that is settled, it'll be another increment. If the IEC debate can be settled once and for all (altough I doubt that'll happen anytime soon), that'll be another increment. If either it becomes apparent in the talk concerning the bluebox or in a future IEC debate that what is in the greenbox needs to be modified, then the greenbox will be modified in time.

To withhold provisional assent because this rewrite maintains statu quo on an unresolved issue that will not be resolved in the foreseeable future is counterproductive. If you have problems A,B,C,D, and E, and that there is a solution to problems A,B,C, and D which doesn't solve E or make it worse than before, then it is only sane to go forward with that solution. You agreed that it was a sound rationale for going forward with the FCL, so I don't see what is the problem with using that rational here.Headbomb (ταλκ · κοντριβς) 17:06, 21 May 2008 (UTC)

• I appreciate your good-faith effort. I have to go now. I’m just one vote. Let’s see how others feel. Greg L (talk) 17:13, 21 May 2008 (UTC)

• When you come back, will you please give us a bone to chew on as for the reasons of your opposition? Headbomb (ταλκ · κοντριβς) 21:01, 21 May 2008 (UTC)

• Thunderbird2 it is not logical to insist on saying IEC are acceptable when the rest of the text prefers familiar units first of all. There are better more familiar methods so that is why is it better to include the qualifier that they should only be used when the sources say so. It is not logical to try to push for IEC to be used.DavidPaulHamilton (talk) 21:08, 21 May 2008 (UTC)

The text that I support is one that requires the editor to use familiar and broadly accepted units in an unambiguous fashion. I disagree with your latest edit (to Binary Prefixes) because it misses the point entirely. (In cases where the sources use IEC units there is no need for disambiguation). Thunderbird2 (talk) 21:25, 21 May 2008 (UTC)

I disagree with your edit because it is inconsistent with the rest of the text. IEC does need disambiguation because it is unfamiliar and therefore ambiguous to the readers. The fact IEC is unfamiliar means IEC is unsuitable for disambiguation in most situations. more familiar methods exist. We could remove, as you suggest, the mention of IEC because it sticks out like a sore thumb.DavidPaulHamilton (talk) 21:54, 21 May 2008 (UTC)

• To clarify, megabyte is ambiguous (binary or decimal?), but familiar. Mebibyte is unambiguous (only one meaning), but unfamiliar (or put another way, obscure).Headbomb (ταλκ · κοντριβς) 22:01, 21 May 2008 (UTC)

Yes, almost. Synonym for ambiguous is obscure. Ignoring the dictionary for a moment, there is one extra point to remember. It is familiar to use numbers of bytes. Numbers are more familiar and common than the use of IEC. The text does say prefer familiar and broadly accepted so it does not make sense to use unfamiliar terms to disambiguate.DavidPaulHamilton (talk) 22:32, 21 May 2008 (UTC)

I would agree, but I don't care to debate this issue at the moment when I could spent my time rewriting section 4 and creating the scientific notation section. IEC debate will not go away for a while, so I'd rather talk about things that we can change in the near future then tackle a problem that will not be solved anytime soon. Headbomb (ταλκ · κοντριβς) 22:38, 21 May 2008 (UTC)

OK I'm glad you would agree but this proposal and IEC SI are linked so it will need to get solved soon.DavidPaulHamilton (talk) 04:15, 22 May 2008 (UTC)

This proposal and the IEC prefix debate are not related. This proposal concerns everything BUT the IEC debate, in the same what the one would say "Let's give the house a clean house except the attic". It does not make sense to lock the house and keep the carpet cleaners outside because "the dirt should stays where it is until the attic is cleaned". If you want to debate the IEC prefix, build a redbox (or yellow box, pick your favourite non-green and non-blue colour) that would, upon gaining consensus, replace the current "Binary prefix" section or something. Headbomb (ταλκ · κοντριβς) 04:56, 22 May 2008 (UTC)

• I've contacted most of those on the Figure of merits box, requesting for votes and comments. Some were unreachable (Real username is not written as provided).Headbomb (ταλκ · κοντριβς) 03:11, 24 May 2008 (UTC)

• I've updated the greenbox taking the recent discussion into account. Headbomb (ταλκ · κοντριβς) 03:11, 24 May 2008 (UTC)

Greg L and DPH's vote: Your votes are still at 1. I tried to figure what your opposition was to this version of the greenbox, but all I heard is a bunch of stuff about the IEC prefixe debate thing, which is irrelevant to this proposal. You did mention that you were concerned that removing the FCL section would yield chaos, but I pointed out how everything in the FCL is already included in the greenbox, so that cannot be an objection. You've been silent on this issue ever since. Please update your votes, or clarify the reason(s) of your opposition. Headbomb (ταλκ · κοντριβς) 15:49, 24 May 2008 (UTC)

SWTP's vote: Everyone is aware that the greenbox does not address the IEC prefixes, that's what the purplebox, which will be merged with the greenbox upon reaching consensus, is for. Headbomb (ταλκ · κοντριβς) 13:55, 25 May 2008 (UTC)

Update of Greg L's vote: Sigh. I'm really getting tired of hearing about IEC prefixes in the greenbox. The greenbox is for changing everything that does not touch the IEC prefixes debate. AKA does it deal with unit conversion appropriately? Does it deal with proper formatting of units? Is it clear that unambiguous units are preferred? Is it clear that familiar unit are preferred? Did the merging of non-IEC prefix FCL content in relevant sections removed redundancy? Purplebox will be the IEC-prefixe solution. If you don't think purplebox tackles the history of IEC prefixes appropriately, voice your concern there. If you think that the solutions proposed by purplebox are not the best possible, mention it there. If you think that IEC-prefix content of the FCL is not appropriately merged with purplebox, voice your concerns there. If you want to wait for the purplebox to reach consensus before we upload the greenbox so there's no "gap" between the time the greenbox is uploaded and the time the purplebox is—fine with me. But say that you want to wait for the purplebox to be complete before uploading the greenbox; not that you oppose the greenbox on the grounds that it does not do things it was never meant to do.Headbomb (ταλκ · κοντριβς) 01:22, 26 May 2008 (UTC)

• Still a 1? Headbomb (ταλκ · κοντριβς) 02:11, 26 May 2008 (UTC)

• The “1” is due to an error of omission and does not speak to the quality of what you do have there. I can see giving this a “4” if a single, important issue gets addressed. Remember, your greenbox is not a contribution into a free vacuum; it purports to replace a lot of existing verbiage, including FCL. It was your choice to employ a strategy of separating the purple box out for separate treatment; I think that was wise. You’ve incorporated the major philosophy of “Follow current literature” into your greenbox and IMO, that’s very good. Still, in my opinion, a major source of endless bickering on MOSNUM must yet be addressed. FCL currently addresses the IEC prefixes by stating that they aren’t to be used but it leaves the details of implementing that broad principle to “Binary prefixes”. If your greenbox were to be posted to MOSNUM, it would replace FCL because your greenbox already touches upon the same points FCL embodies. However, if your greenbox does not include the contents of the purplebox, its adoption would have the effect of weakening what FLC already accomplishes on that issue. You shouldn’t be deterred by this reality. Remember too that Fnagaton feels the same. Though he rewarded your effort with a “4” vote, his vote comes with the same caveat regarding the purple box. His “4” vote is highly conditional. DavidPaulHamilton and SWTPC6800 saw fit to do as I did: make their votes match the totality (including the important omission).

  You’re making progress here. Like SHEFFIELDSTEEL^TALK wrote on a Wikiquette alert on Omegatron: “Consensus is not all editors in 100% happy agreement, and never has been.” It would have been exceedingly unrealistic of you to have set out to tackle what you’ve tackled and believe you could get literally everyone to support it. Part of developing a better consensus entails writing better guidelines, and part of it entails debate and discussion that changes some editors’ opinions along the way. I think you are doing fine so far. Given the magnitude of the task, you need patience. Greg L (talk) 03:31, 26 May 2008 (UTC)

• I can't think of anything else to add to Greg's comment, I am in complete agreement. Headbomb I "want to wait for the purplebox to reach consensus before we upload the greenbox".DavidPaulHamilton (talk) 04:42, 26 May 2008 (UTC)

• The vote was never "Should we upload this section on the MOS now?", but "Does this address everything it needs to address (except the IEC prefixe debate, which is the purplebox's job, and scientific notation/uncertainty, which is the bluebox's job)?". I don't understand why this is still not understood.
  As of now, the rewrite of section 4 involves the greenbox, purplebox and bluebox, each set out to tackle different things. Greenbox covers the entire section, minus specific topics that would be (and is) bothersome to debate as part of the greenbox. Purplebox is there to specifically address IEC debate since there is a lot to say on that specific issue and debate on that could take a while. Bluebox was separated from greenbox because it's something completely new, not merely the reshuffling and rewording of things already in the greenbox and needs special attention before it goes in the MOS, and that too could take a while. Apparently the biggest task of all it to make it clear that the greenbox does not address and was never meant to address these topics and that vote on the greenbox should reflect what it set out to do, rather than on what the purplebox set out to do.Headbomb (ταλκ · κοντριβς) 05:03, 26 May 2008 (UTC)

• Headbomb, you may not like what I’m going to say, but your well intentioned work reminds me of the ‘60s, with a little eastern-European-block nation being played like a pawn in a struggle between two big camps over larger issues. A popular mayor of a small town might not win a vote and the reason for the loss might not make rational sense on first glance. I haven’t been active on MOSNUM long enough to know, but I really doubt that there has ever been a wholesale replacement of so much text on MOSNUM in one fell swoop. You write that the purpose of the vote is to express whether or not it satisfactorily addresses all the issues besides the IEC prefixes. You need to understand this Headbomb: those of us who are holding back on this only got into this fray because of the IEC prefix issue; the rest is peripheral stuff that would have eventually sorted itself out anyway by the subset of us who care about these various issues. Our fear is that if we were to give a “smiley face” vote based only on your criteria, there would be no waiting for a consensus on the purplebox; the greenbox would rapidly be uploaded to MOSNUM and its subset treatment of “Follow current literature” would replace what’s already there—including FCL’s treatment of the IEC prefixes. It is a tactic that can easily be played by the proponents of the IEC prefixes. Whether or not they actually would do this is a matter of conjecture. But the only thing that should matter from your perspective is that we holdouts have a well founded fear that the IEC proponents would avail themselves of the opportuntity.

  In my opinion, you will be frustrated in the final analysis if you insist on being so ambitious and tackling so much at once. It was only a little more than a day ago that I convinced you that you were in the drivers seat and had to take the “IEC prefix” bull by the horns and propose text that could reach a consensus; no one else looked forward to getting a belly full of all that discord and effort. I think the same effect applies to a lot of the rest of your greenbox; it is so ambitious, no one really looks forward to hammering away at each of these issues. Why? In part, because of the latent fear that there are editors who simply don’t want to wade into their pet issue (scientific notation or whatever) right now because it’s ‘all for not’ at this juncture. The circular fear is that the “other” editors will just weigh in on their pet issues later if this gigantic thing were to actually “go to press.” So why bother now? It’s a self-referential physiology thing that effects financial and commodities markets.

  My recommendation to you is to partition each one of the issues touched upon in your greenbox so they can be addressed separately. This will fix the “mass physiology” effect and get other editors better engaged. The perception will instantly be that if an editor gives a crap about a particular issue, they better well get into the saddle on it or it will be posted to MOSNUM. As for the IEC prefixes and “Follow current literature”, FCL is a very broad principle and a clear majority of editors who voted on it believe it is indisputably wise because it brings Wikipedia’s practices into alignment with those of professionally edited encyclopedias. We reject the notion that we volunteer editors are somehow smarter than professional editors with journalism degrees. FCL wouldn’t even be a point of contention were it not for the fact that it sweeps up the IEC prefixes along the way. I see you has having two options if you want to make rapid progress: 1) tackle the IEC prefix issue first, or 2) tackle it last. Either way, you need to completely split this stuff up. That’s my 2¢. Greg L (talk) 21:28, 26 May 2008 (UTC)

• But it is split up. Greenbox (non-IEC related stuff), purplebox (IEC related stuff), and bluebox (new scientific notation section). There is consensus to not upload anything until the purplebox issue is settled (a disclaimer in the text of the greenbox could be added to show this). As far as not gathering input from people who are "afraid" by the scope of the rewrite, I'll point out that many editors have not been intimidated by the scope of this rewrite. Greenbox got input from Jimp, who made a ton of very usefull and pertinent suggestions, DPH gave some insight about the order of things that lead to merging a few points together, PMAnderson raised concerns about general MOS interest stuff being in section 4, MJCdetroit gave some input on the wording of some sections, Thunderbird2 gave concerns about some redundant content, Gerry Ashton gave input on conversions, LeadSongDog gave a few links to debates about ambiguity, etc.
  I've asked you many times about what of the non-IEC content of the FCL section is not covered in the Greenbox, and to voice your non-IEC related concerns and I got no answer (The IEC related content of the FCL section was merged with the rest of things in the purple box, and it got a 4 vote from you, so I suppose you are happy with the merging of the IEC related content of the FCL with the purplebox). It seems you are the only one afraid to give input. Headbomb (ταλκ · κοντριβς) 22:46, 26 May 2008 (UTC)

FCL certainly would have beed a point of contention were it not for the fact that it swept up the IEC prefixes along the way. A good number of the arguments the content of FCL had nothing in particular to do with the IEC prefixes. I've been pretty much neutral with respect to the prefix war but have been voicing my opposition to FCL from the onset. As for there never having been "a wholesale replacement of so much text on MOSNUM in one fell swoop", in terms of change in policy, this is minor compared to the insertion of FCL. JIMp _talk·cont 00:05, 27 May 2008 (UTC)

• The facts speak for themselves Jimp. A majority of editors believed FCL to be wise policy because it stopped Wikipedia from being oddball. Greg L (talk) 00:29, 27 May 2008 (UTC)

The facts do speak for themselves. There has been support for FCL, yes, it does have its merits. There has also been opposition. The debate has raged on and on but has not been focused on the IEC-prefix issue. Regardless of it's level of support, regardless of its merits & demerits, the insertion of FLC into MOSNUM marked a major change in policy. What Headbomb is proposing is more evolutionary. JIMp _talk·cont 01:55, 27 May 2008 (UTC)

Unindented

• As you can see, I’ve now upgraded my vote to a “3” conditional to the purplebox caveats. By “breaking up” the discussion, I meant to do so to a greater extent than before. For instance, the “Disambiguation” section jumped immediately out at me. I don’t have a problem with all but one of the cited examples because they all are fully aligned with current literature on each of the respective subjects. An article on marine navigation might say simply “miles” but an encyclopedic treatment of the subject would be clearer by stating “nautical mile”.

  However, I suggest you revise or jettison the “calorie” example so we can make rapid progress. Again, we editors are rather up to speed on the science underlying gram or kilogram calories. A scientist would simply call it a kilocalorie. That’s also the way English-language food labeling handles it in Europe (I was there last year). But just what sort of readership do you think will be going to an article on diet and food? Some wouldn’t know the difference between a kilocalorie and a picocalorie—to them, there both just “different” calorie. All any American sees on a food label is “calorie.” And now, on an article on a general-interest article on nutrition, a reader is supposed to understand that “large calorie” is the same thing as “calorie”. Many would simply assume that the additional specificity is actually supposed to signify a difference. This confusion is so unnecessary since “calorie” could be linked to an article on “kilocalorie” if we wanted to. The extra specificity (disambiguation) that is being called for is simply unnecessary unless it was for some sort of mixed-use, chemistry-related article.

  This is just one example of why it might be wise to further break up this huge green box into separate topics. It’s also yet another example of why we need to closely follow FCL; do you think Encyclopedia Britannica uses “large calorie” when talking about the nutritional energy content of an apple? How about most (or virtually all) diet books? Greg L (talk) 00:26, 27 May 2008 (UTC)

The text contains the bullet

• KB and kbit are to be preferred over kB and Kbit.

Where did this come from? I don't recall it ever being discussed and don't agree with it.Thunderbird2 (talk) 16:01, 1 June 2008 (UTC)

To Woodstone: re Still object to statement about "familiar units". Familiar to whom? I interpret this statement as favouring units likely to be understood (or at least recognised) by the average WP reader. I agree that sometimes that's not obvious, but often it is. For example, many readers will feel comfortable with power in MW because they have been taught the SI system as school, but are unlikely to have heard of MWt. Yes, I know that example would be covered by the preceding bullet, but I see it as a different principle. Another example, if I can pluck up enough courage to mention it, is the megabyte (a familiar unit) vs the mebibyte (an unfamiliar one). With that in mind, can you suggest a way of rewording the bullet that would result in your support? Thunderbird2 (talk) 20:23, 3 June 2008 (UTC)

In my view the concept of "familiar" is too ill defined to be useful. We would be better off scrapping the whole criterion. I cannot see what useful information it adds to the remainder. Just like you, people will start wondering: what units are (not) familiar? Americans will say "cm" is unfamiliar, much of the rest if the world will say "inches" are unfamiliar. What does the criterion help us here? Your example "mebibyte" is already solved by the "broadly accepted" criterion. −Woodstone (talk) 21:40, 3 June 2008 (UTC)

• We all know that familiar is a subjective term. But we all also know that foes are familiar units. Actually we probably don't know all this given how unfamiliar foes are. There's no need to be philosophical about this. When it's clear that a unit is familiar, there won't be any debate, if it's unclear people will go on talk pages to debate wheter or not a unit is familiar or not. Nobody flips out when the batting average of Bill Gates is removed from an article about the political parties of Portugal, but should we start flipping out because "relevance" is also ill-defined and subjective? Headbomb (ταλκ · κοντριβς) 21:51, 3 June 2008 (UTC)

• Woodstone, Jeh made a similar remark here when we were discussing the principles on which Headbomb built his proposal. He (Jeh) also felt that the two principles could be merged. The distinction I saw between broadly accepted and familiar is that the first is aimed at the writer and the second more at the reader. Would it help if that point were made more explicit? Thunderbird2 (talk) 22:09, 3 June 2008 (UTC)

• I would say if someone wanting to edit an article does not know enough about the subject to make that judgement call then they shouldn't be editing that article in that way and instead ask someone who is more knowledgeable on the subject. Fnagaton 22:19, 3 June 2008 (UTC)

• As usual Fnagaton shows his contempt for the principle that Wikipedia is the encyclopedia anyone can edit. A person may be very knowledgeable about a topic, and have an excellent collection of sources, but not be too sure which units would be famliar to readers from countries other than her own. I'm damn sick and tired of Fnagaton saying that anyone who has difficulty following Fnagton's preferred version of this or any other guideline should stop editing articles. --Gerry Ashton (talk) 22:31, 3 June 2008 (UTC)

• Just because anyone can edit a topic it doesn't mean they should. If someone is unsure there is nothing wrong with saying they should ask others, in fact it is the sensible thing to do. Are you going to try again to make a valid point instead of writing a rude thinly veiled personal attack? I do hope so because at the moment you're not helping to support your point of view. Fnagaton 22:37, 3 June 2008 (UTC)

Discussion of the rewrite of section 4

Resolved or old discussion

Discussion pertaining to resolved debates

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. —MJCdetroit ^(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   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 (ταλκ · κοντριβς) 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?" JIMp _talk·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. JIMp _talk·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. JIMp _talk·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. JIMp _talk·cont 00:40, 21 May 2008 (UTC)

• "Em dashes should not be spaced at Wikipedia." according to the MoS. JIMp _talk·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". JIMp _talk·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. JIMp _talk·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. —MJCdetroit ^(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? JIMp _talk·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. JIMp _talk·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. JIMp _talk·cont 03:15, 22 May 2008 (UTC)

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

• Can we not add the quasi-Roman-numeral-short-scale prefix set, {M for 10³, MM for ⁶, B for 10⁹, T for 10¹² and lower-case variations}, to the list of "Confusing symbols"? JIMp _talk·cont 03:15, 22 May 2008 (UTC)

• This has been discussed before with a general feeling against these obscure and ambiguous symbols. JIMp _talk·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. JIMp _talk·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. JIMp _talk·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 MB₂ and MB₁₀. 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 'MB₂' and 'MB'₁₀. 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 "′′" showed up as "′′". As always, this change is open to be changed. Regards,—MJCdetroit ^(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. JIMp _talk·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. JIMp _talk·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. JIMp _talk·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³').
• MOSNUM prefers familiar 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 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.[1] -- SWTPC6800 (talk) 00:27, 21 May 2008 (UTC)

I think that the general senses of the terms ambiguous^CambridgeAHD and obscure^{Cambridge 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. JIMp _talk·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. JIMp _talk·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 10⁶ 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. JIMp _talk·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·m .

Torque is $\tau ={\vec {F}}\times {\vec {r}}$.
The unit of torque is therefore the N·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·m.

Torque is $\tau ={\vec {F}}\times {\vec {r}}$.
The unit of torque is therefore the N×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? JIMp _talk·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 = (F_x, F_y, F_z); one for each dimension, x might be north, y east and z up. Sorry to bore those who already know this stuff. JIMp _talk·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·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·m" out as a unit of energy but I'd argue that this would not be necessary since "N·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. JIMp _talk·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·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·m, or kg·m²·s^-2) would be a unit of torque (N·m, or kg·m²·s^-2). If we distingish between scalar and vector combination, then the units become distinct (which they are), a joule (J, or N·m, or kg·m²·s^-2) would not be a unit of torque (N×m, or kg·m·s^-2×m) Headbomb 20:26, 29 May 2008 (UTC)

There is no mathematical distinction between a×b and a·b where a and b are not vectors. Units are not vectors. Therefore N×m is mathematically identical to N·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. JIMp _talk·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. JIMp _talk·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×F = (rx m, ry m, rz m)×(Fx N, Fy N, Fz N) = (m*N)*(rx, ry, rz)×(Fx, Fy, Fz)

W = F·r = (Fx N, Fy N, Fz N)·(rx m, ry m, rz m) = (m*N)*(Fx, Fy, Fz)·(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

Discussion pertaining to unresolved debates

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. JIMp _talk·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). JIMp _talk·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. JIMp _talk·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). JIMp _talk·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. JIMp _talk·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. JIMp _talk·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? JIMp _talk·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.

  JIMp _talk·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... —MJCdetroit ^(yak) 15:48, 27 May 2008 (UTC)

There having been no objection in over a week I intend to adjust the green box accordingly. JIMp _talk·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 "~". JIMp _talk·cont 08:13, 3 June 2008 (UTC)

Allowing "~" and "approx." in full sentences

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? JIMp _talk·cont 08:36, 3 June 2008 (UTC)

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.
  JIMp _talk·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. —MJCdetroit ^(yak) 02:48, 21 May 2008 (UTC)

• Update: Someone added redirects to the 3 dead-links above. —MJCdetroit ^(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? JIMp _talk·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. JIMp _talk·cont 01:22, 28 May 2008 (UTC)

IEC prefixes: impact of section 4

Impact of rewrite

• Has anyone asked themselves why all the computer manufacturers haven’t availed themselves of these wonderful and perfectly unambiguous IEC prefixes when communicating to their customers? Or why all the principle, general-interest computer magazines don’t use them either? Or why professionally edited encyclopedias of all things don’t make use of them and instead communicate to their readers using ambiguous units? Is it because they are all just stupid and/or ignorant? Is it because the people who make a living as professional editors and undoubtedly have advance degrees in journalism just aren’t as wise as some of editors here who make Wikipedia their hobby? Why is it that I just had to write this paragraph? What the holy hell is wrong with Wikipedia that this much effort (eleven archives dedicated exclusively to bickering over this one issue) has had to transpire and the clear majority of editors still can’t get a vocal minority to cease and desist?

  This whole proposal is being shepherded by someone who declared above that “As a matter of fact, yes, I am more enlightened ON THIS TOPIC [choosing units of measure] than the professional, paid editors at all the general-interest computer magazines and print encyclopedias.” I respect that Headbomb had the courage to state the logical consequences of his position; he doesn’t have to resort to utterly fallacious arguments to make his case. And that attitude fully explains why Wikipedia is all alone on various articles in the use of units no one else uses in those disciplines. It is the judgment of the clear majority of editors here that the desires of the pro-SI/pro-IEC prefix crowd is thoroughly unwise and they rejected this minority position with the effective conclusion of ‘Well… Duhhh, we should be observing the practices used by all the other professionally edited encyclopedias like Encyclopedia Britannica and World Book rather than off doing our own thing.’ And in my opinion, the hurdles this vocal minority has forced us to jump through in listening to their objections has risen to the level of galactic-grade absurdity. We don’t have to accept any of this; this issue has had a more than fair hearing. To those editors who are thoroughly more humble: I know two ways I think we can put end to this charade. I’m heading down for more work on an FDA animal trial and will be back on the weekend. I’ll run it by some of you over the weekend. Greg L (talk) 04:55, 22 May 2008 (UTC)

An FDA trial?? Are you now threatening with legal actions? That's SOOO cool! But... the IEC and the SI law departments will definitely counter-sue and charge you with Grand Theft Prefix. --217.87.60.244 (talk) 05:27, 22 May 2008 (UTC)

Yes, I have meditated and discussed this with my inner self. It has nothing to do with stupidity at all. What a horrible thing to assume! Please stick to "assuming good faith"! This rule exists for a reason. The reasons for not adopting the new prefixes are "not invented here", "we don't give a damn" and last but not least "i don't want to be compared to klingons or space-cadets". --217.87.60.244 (talk) 05:44, 22 May 2008 (UTC)

Well I guess it's a good thing that THIS PROPOSAL IS NOT CONCERNED WITH THE IEC DEBATE. How many times do I have to say it? Will we need 20 archives of "Declarations made by headbomb to the effect that the rewriting of section 4 is not concerned with the IEC debate."? Headbomb (ταλκ · κοντριβς) 05:06, 22 May 2008 (UTC)

• What an absurd thing to say (and in triple-big no less). The topic is right there in Complete rewrite of section 4:Binary prefixes. It discusses the IEC prefixes, lays out some pro & con lip service, and then says existing articles shouldn’t be changed. So if you mean “the proposal is not concerned with the IEC debate”, then no, that is patently false. But if you mean “the proposal doesn’t do anything to effectively change Wikipedia policy on the IEC prefixes”, then I agree with you 100%. Greg L (talk) 05:14, 22 May 2008 (UTC)

• The only people who ever mentionned something about the IEC debates in this proposal were you and PaulDavidAnderson (with the exception of the removal of the disputed tag since it was explicitely mentioned in the binary prefixe text that the whole thing is being debated and a minor comment from Thunderbird02). At your first post expressing your concerns of the IEC debates (which was the vote with a lead section that explicitly mentionned that the resolution of the IEC debate was not the concern of this rewrite), I've bent over backwards to explain that this rewrite was concerned with everything BUT the IEC prefixes, I've tried to understand what your objections were to this rewrite. You vaguely mentioned something about the FCL policy that was adopted so I've pointed out how this rewrite addresses everything the FCL policy did in neat bullet form, while having the additional benefit of being much more concise, even altough I didn't really see what this had to do with the IEC thing. I've asked you many times that you address the IEC issue seperatly so that a deadlock there would not stop the rest of the MOSNUM to progress forward. I've even suggested that a redbox is created, in a similar fashion to the blue box, so the greenbox — which addresses a bunch of things and while not settling the IEC issue once and for all, is not a step backwards — could go forward. But no, you still say that somehow this proposal is about the IEC debate. So excuse my use of triple big, but I'm running out of ways to express that the rewrite is not concerned with settling the IEC prefix debate once and for all, much like you can clean a house without cleaning the attic. Headbomb (ταλκ · κοντριβς) 05:40, 22 May 2008 (UTC)

Headbomb, you seem to be confuse about the reason and origin of this current discussion. It started here: [2]. So the IEC prefixes aren't just an aspect, they are the very reason for it. It is simply a vast over-generalization supposed to make the IEC prefix debate a tiny, irrelevant aspect. A trojan nuke so to say - in a good way! --217.87.60.244 (talk) 06:07, 22 May 2008 (UTC)

The reason and origins of the current discussion is irrelevant to the reason and origins of the rewrite. The rewrite aims to clean up and clarify everything but the IEC debate. If you want to change the binary prefix section, then make a redbox and gain consensus, and the binary prefix section will be updated accordingly. Headbomb (ταλκ · κοντριβς) 06:12, 22 May 2008 (UTC)

That's pure horse crap! You wondered and asked why Greg L was bringing up the seemingly irrelevant IEC prefix issue. I told you and showed you why. Take it or leave it. I really don't care that much about Wikipedia's view on this. I'm much more worried about my local computer hardware dealers. I'm constantly running out of RAM but everytime I try to buy another gibibyte RAM module, the store clerks start laughing hysterically and I have to leave the shop. Okay, this was really irrelevant. --217.87.60.244 (talk) 06:28, 22 May 2008 (UTC)

This proposal of Headbomb's calls for preference to be given to broadly accepted and familiar units. Are the units formed with IEC prefixes broadly accepted? Are they familiar? Doesn't this proposal give the anti-IEC faction enough gunpowder to blow these prefixes right out of the water anyway? Of course, there is the rule not to use ambiguous units ... wouldn't that rule "kilobyte", "megabyte", etc. out regardless? Yes, the waffly subsection about these and how there's no consensus about where to begin dealing with this mess remains as part of Headbomb's proposal. Greg didn't remove it either, though. JIMp _talk·cont 05:30, 22 May 2008 (UTC)

You are wrong. IEC 60027-2 defines "kilo" and "mega" in accordance with the SI prefixes. That's the sole point of the standard and they could have cared less about powers of 1024 namely by not defining kibi and mebi at all. Instead the assembler hackers would have had to establish their own convention. However last time they failed horribly and lazily just redefined existing prefixes for their own convenience. So if you want to prohibit IEC prefixes that means essentially NO prefixes. --217.87.60.244 (talk) 05:35, 22 May 2008 (UTC)

I'm wrong ... yeah, 217.87.60.244, Humpty Dumpty defined glory as "a nice knock-down argument". We are not the IEC. JIMp _talk·cont 06:50, 22 May 2008 (UTC)

Okay, you're not the IEC. I'm not the IEC either. I admit I own IEC plugs and IEC sockets but so do you. Anyway what message are you trying to get across? --217.87.60.244 (talk) 06:59, 22 May 2008 (UTC)

My message ...

'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean -- neither more nor less.'

Similarly when the IEC uses a word they can mean whatever they want by it. Since we are not them, though, we are not bound by their definition. We are, of course, free to adopt their definition. However, were we to do so, we'd be setting ourselves apart from general usage of the terms in the English language. This, as I read it, is Greg's big concern with the current proposal under discussion. JIMp _talk·cont 07:11, 22 May 2008 (UTC) ... P.S. Who are you, 217.87.60.244? JIMp _talk·cont 07:12, 22 May 2008 (UTC)

The IEC is an international standards organization and IEC 60027-2 has been adopted by other organizations and is at least supported by even more national and international organizations. I could be wrong but I dare to say that gives it a little more weight than Humpty Dumpty's ideas. Regardless of the IEC's "ideas" different definitions which are by sheer incident are identical to those of IEC 60027-2 have been in use for decades. That's also in part to the sheer incident that the prefixes are borrowed (Grand Theft Prefix) from the SI. I suspect Greg assumes the IEC is just a clique of baguette munching Frenchmen making fun of Englishmen and trying to cause a riot in the computing industry to destroy the US economy. Close but off, it has more to do with Area 51 and little gray men but I can't tell you the details. With respect to your P.S., I'm the same person I was yesterday and that's all what matters. --217.87.60.244 (talk) 07:37, 22 May 2008 (UTC)

You weren't around yesterday, but no, it doesn't really matter. We're writing to a general audience who may well never have heard of these definitions ... but if we have to be the ones to tell them ... oh well. JIMp _talk·cont 07:57, 22 May 2008 (UTC)

Let's try this again:

'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean -- neither more nor less.'

I rather thought that to apply to the people that say KB can mean 1000 bytes or 1024 bytes, and they can just let the reader guess at what it happens to be this time? −Woodstone (talk) 13:55, 22 May 2008 (UTC)

Humpty Dumpty follows the standards of this IEC. -- SWTPC6800 (talk) 15:58, 22 May 2008 (UTC)

It could apply to anything but all the king's horses and all the king's men may never put MOSNUM back together again. JIMp _talk·cont 23:26, 22 May 2008 (UTC)

• Headbomb your intention may not have been to address the IEC issue but the fact is the current guideline text on the project page does specificaly address it and this is the section you are proposing to change. So this means either directly or indirectly what use propose affects the IEC issue. You have multiple editors saying how your proposal relates to IEC and making edits related to it. i think you should accept this as a demonstration that this proposal debate has to also include the IEC issue to have any hope of gaining consensus. DavidPaulHamilton (talk) 08:13, 22 May 2008 (UTC)

• It’s early and I’m heading out the door. Not much time. Yes, the proposal addresses the IEC prefixes. More to the point, this is proposal would replace FCL, which also touches upon the IEC prefixes. If adopted, it would have the effect of weakening the declaration about them. Thus, the proposal, which you say “doesn’t have anything to do with” the IEC prefixes, actually and clearly does. Setting aside the issue of the IEC prefixes, FLC also broadly swept up a bunch of other unwise practices with units of measures by stating a common-sense principle: by instructing Wikipedia’s editors to adopt the units used in current literature, the effect would be to use the units used by other encyclopedias. Your proposal weakens that principle IMO. Greg L (talk) 12:48, 22 May 2008 (UTC)

Follow Current Literature (Redbox)

Redbox

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)

Degree of support

User	5	4	3	2	1	0
Headbomb (ταλκ · κοντριβς) 20:52, 5 June 2008 (UTC)		X
Jimp					×
Woodstone (talk) 08:25, 2 June 2008 (UTC)					x
Greg L (talk) 00:24, 3 June 2008 (UTC)						X
Fnagaton 08:17, 3 June 2008 (UTC)	X
Pyrotec 21:57, 5 June 2008 (UTC)		X

Vote and vote comments

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 of “Vote Comments”

Discussion of vote comments

• I’m not seeing where the greenbox remotely addresses the broad principle of FCL; it seems to attempt to do so by using many examples. Would someone please point out where I’m wrong with this impression? Greg L (talk) 00:24, 3 June 2008 (UTC)

• Good thing to know that you think we're all retards. Headbomb (ταλκ · κοντριβς) 03:10, 3 June 2008 (UTC)

• As for pointing out where the greenbox remotly addreses the broad principle of FCL, I have done so since day 1. I've replied to you every time you brought this up and every time you did not even acknowledge that I've replied to it. Hell, I've pointed it out in this very discussion, just below, way before you voted, and you still maintain that you can't see it. So I don't see how pointing it out a 9th time will open your eyes.
  You may search the tags 05:15, 21 May 2008 (UTC); 05:35, 21 May 2008 (UTC); 15:49, 24 May 2008 (UTC); 22:46, 26 May 2008 (UTC); 05:20, 1 June 2008 (UTC); 04:28, 2 June 2008 (UTC); 04:39, 2 June 2008 (UTC); 05:19, 2 June 2008 (UTC), for times where I asked you to either express your concerns about some of FCL content being missing or unadressed, or explanations of how FCL was merged with the greenbox, with explicit comparison between FCL and greenbox etc... There's problably some in the archives too, but I don't feel like going through them right now. Headbomb (ταλκ · κοντριβς) 06:05, 3 June 2008 (UTC)

• To Fnagaton: Yes comments would be nice, because right now this "common sense" section's principles are already in the greenbox and there is nothing in the redbox that isn't covered by the greenbox. You pummel Thunderbird for not giving examples of how the purple box is deficient, but neither you nor Greg L are giving us examples of how greenbox is deficient, even though it's been asked many times in the last month. Headbomb (ταλκ · κοντριβς) 15:58, 3 June 2008 (UTC)

• I've already given examples how the greenbox is deficient, see comment written "19:36, 25 May 2008 (UTC)". Would you like to cite exactly which posts relate to the "it's been asked many times in the last month" claim where you or anyone else has specifically asked me to comment on the greenbox and has not been answered? Fnagaton 16:39, 3 June 2008 (UTC)

• Your 19:36, 25 May 2008 (UTC) comment was that IEC prefixes were not addressed. Purplebox was devised to tackle the IEC prefixes and you gave the purplebox a 5, so I guess you're happy with how IEC prefix are handled. I did not ask you specifically to give examples, but I did ask Greg L every time he mentionned the greenbox not covering FCL enough (see those 8 time tags just above). Now that your mentioning it, I'm asking such examples out of you too, and to point out how the redbox is not completely redundant. Headbomb (ταλκ · κοντριβς) 18:36, 3 June 2008 (UTC)

• Appology accepted. And since you now asked: The green box (plus all of the other boxes to be included) is quite large and to be honest it is likely to be skimmed, it needs a paragraph summary right up at the top. The red box tackles this important issue of clarity and direction in an easy to read summary that can hopefully be understood even by the most cursory examination. That's why I do not think the red box is redundant. Fnagaton 19:05, 3 June 2008 (UTC)

• A summary of the section 4 could be given I guess, but I really don't see how it would be section-4 specific, as it would really just be a rephrasing of the general guidelines of the MOS. I'll try to come up with something that's more summary-oriented than what's written right now. Headbomb (ταλκ · κοντριβς) 21:56, 3 June 2008 (UTC)

• To Greg L, glad to see that you came to see that FCL was redundant, but do you agree with the 3 bullet summary? Headbomb (ταλκ · κοντριβς) 22:46, 5 June 2008 (UTC)

Discussion

Discussion of redbox

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

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. JIMp _talk·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. JIMp _talk·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? JIMp _talk·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? JIMp _talk·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? JIMp _talk·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. JIMp _talk·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. JIMp _talk·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". JIMp _talk·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. −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#History_of_predictions_about_future_energy_development 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 cm³ 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. JIMp _talk·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)

Bluebox

Scientific notation, engineering notation, and uncertainty

Notations

• Scientific notation is done in the format of 1 leading digit/decimal marker/rest of digits/×10ⁿ, where n is the integer that gives one leading digit.

• 1.602×10⁻¹⁹ is a proper use of scientific notation.
• 160.2×10⁻¹⁷ is not a proper use of scientific notation.

• Engineering notation is done in the format of leading digits/decimal marker/rest of digits/×10ⁿ, where n is a multiple of 3. The number of leading digits is adjusted accordingly.

• 132.23×10⁶ is a proper use of engineering notation.
• 1.3223×10⁸ 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×10² m region covered by 234.0×10⁶ 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×10² 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/×/10ⁿ/unit symbol (e.g. (1.534±0.35)×10²³ m

• Do not group value and uncertainty in parenthesis before the multiplier (e.g. do not write (15.34±0.35) × 10²³ m)

• Value/superscript positive uncertainty/subscript negative uncertainty/×/10ⁿ/unit symbol (e.g. 15.34+0.43
  −0.23×10²³ m)
• Value(uncertainty in the last digits)/×/10ⁿ/unit symbol (e.g. 1.604(48)×10⁻⁴ J)
• Value/±/relative uncertainty(percent)/unit symbol (e.g 12.34±5% m²)
• 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)

Degree of support

User	5	4	3	2	1	0
Headbomb (ταλκ · κοντριβς) 20:40, 27 May 2008 (UTC)			X
Greg L (talk) 19:23, 25 May 2008 (UTC)			X
Thunderbird2 (talk) 08:26, 31 May 2008 (UTC)			X
Woodstone (talk) 19:50, 29 May 2008 (UTC)			X
Pyrotec 22:26 05 June 2008 (UTC)			X
New user

Vote and vote comments

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.

Vote Comments

Discussion of “Vote Comments”

Rebuttal and discussion goes here.

Discussion of Scientific notation (bluebox)

Discussion of Scientific notation (bluebox)

• I do not believe Scientific notation uses non-breaking spaces ( ) to separate the various elements (e.g write 1.23 × 10²³ kg, not 1.23×10²³kg). should be stated as a rule; it's the prejudice of one editor, and it can be undesirable (for example, when multiplying numbers in scientific notation). Septentrionalis PMAnderson 21:51, 20 May 2008 (UTC)

• Could you give me an example of multiplying numbers in scientific notation that would be problematic with those rules?Headbomb (ταλκ · κοντριβς) 22:30, 20 May 2008 (UTC)

• Ambiguous? No. Problematic? Consider 4.54 × 10² × 6.02 × 10²³; to my eye, 4.535×10² × 6.02×10²³ is easier to read both in edit space and as rendered in article space; the contrast between the notation of the single numbers and the multiplication is reflected in the spacing. It is also, experto crede, much easier to type correctly. Septentrionalis PMAnderson 22:47, 20 May 2008 (UTC)

• I agree, that when multiplying two scientific notation values, the compacted form is easier to parse. And for these circumstances, using either math notation or using the style you showed above makes sense. The {val} template conveniently produces simple numeric equivalencies that are fully formatted, consistent, and their entire significands can be copied and pasted into Excel. Such as this: atomic mass unit u = 1.660538782(83)×10⁻²⁷ kg. Numeric equivalencies such as this are extremely ubiquitous on Wikipedia and {val} will be fabulous once its decimal problems are fixed. Alternatively, there is still technically a Bugzilla out on {delimitnum} that is supposed to get a developer to make a proper, character-based parsing of this. The current, math-based parser functions just don’t cut it for something where no math is involved. Greg L (talk) 18:04, 21 May 2008 (UTC)

• To be honest, I wanted to go with thinspaces at first because it looked better but I decided to write that section with non-breaking spaces as this was what editors were familiar with. I didn't dawn on me that it would be a problem with multiplying different numbers since I always write such multiplications with parenthesis to make it clear what are the quantities involved, but you are right, it is ugly when written like that. With thinspaces it would look like 4.535 × 10² × 6.02 × 10²³ which isn't much better. However, you should write those multiplication with the units (same reasoning as 1 m × 1 m × 1 m vs. 1 × 1 × 1 m³) so that would look like 4.535 × 10² u/atom × 6.02&;nbsp;× 10²³ atoms

• Do not use   it produces boxes in some browsers and will remain when copied and pasted. Instead use {{delimitnum}} or {{val}} which automatically give non-breaking thin spaces which vanish on copy and past (if you're delimiting numbers in this fashion). JIMp _talk·cont 01:40, 21 May 2008 (UTC)

• Previous discussions on the spacing of scientific notation seems to have come down in favour of using thin spaces (not necessarily  ). Again, {{val}} can be used to achieve this (without the boxes). Also {{convert}} and {{scinote}} use this. JIMp _talk·cont 01:40, 21 May 2008 (UTC)

(break)

• I’m with Jimp. You guys know that {val} doesn’t use thin spaces for delimiting, right? It uses span-based spacing and this allows the entire significand to be copied and pasted into Excel and similar applications so the values can be treated as real numbers. Although some of {val}’s tolerance and uncertainty features may not be ideal, it does some stuff wonderfully. Note this output from {val}, which conforms perfectly to the NIST and the BIPM: Elementary charge, e = 1.602176487(40)×10⁻¹⁹ C (2006 CODATA value). At least this portion of {val} (in the context of {delimitnum}) had been extensively discussed on both Talk:MOSNUM and (later on one particular feature) Talk:MOS and it obtained broad support. Try it; select and copy the whole significand above and paste it into Excel. Its use solves a bunch of problems with editors using plain spaces, thin spaces, and non-breaking spaces, in significands; and pretty much the same stuff (along with no gaps) alongside the × symbol. I think the use of {val} should be mentioned in the Scientific notation and uncertainty box, above. Greg L (talk) 15:48, 21 May 2008 (UTC)

• Actually, I would use those particular numbers (Avogadro's number and the number of grams in a pound) without units, and explain in text. There are also mathematical articles, where the two numbers may be the two factors of a large number, and so unitless. We should not drive our choices in prose for the sake of layout; I have emended my typo. Septentrionalis PMAnderson 23:33, 20 May 2008 (UTC)

• I did plan to mention the val template that streamlines scientific notation, but there are problems with the decimals writing those two quantities. Writting the above would be as easy as writing

  {{val|4.535|e=2|u=u/atom}} × {{val|6.02|e=23|u=atom}}

  . Headbomb (ταλκ · κοντριβς) 23:20, 20 May 2008 (UTC)

• {{val}} does many things first and should definitely be mentionned in the Sci.not section in the future. However, there are many problems with val as of now, mostly with the 0s at the end of values, the length of numbers, and rounding issues. Until those are fixed, {tl

IEC Prefixes (Purplebox)

Purplebox

Quantities of bytes and bits

Historical background

Multiple-byte units
Decimal Value Metric 1000 kB kilobyte 10002 MB megabyte 10003 GB gigabyte 10004 TB terabyte 10005 PB petabyte 10006 EB exabyte 10007 ZB zettabyte 10008 YB yottabyte 10009 RB ronnabyte 100010 QB quettabyte	Binary Value IEC Memory 1024 KiB kibibyte KB kilobyte 10242 MiB mebibyte MB megabyte 10243 GiB gibibyte GB gigabyte 10244 TiB tebibyte TB terabyte 10245 PiB pebibyte — 10246 EiB exbibyte — 10247 ZiB zebibyte — 10248 YiB yobibyte — — —
Orders of magnitude of data

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 (10³); the other uses powers of 1024 (2¹⁰). 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 (2¹⁰) bytes, “megabyte” to mean 1024² (2²⁰) 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×1024² bytes) video card and a 100 GB (64×1000³ bytes) harddrive", "A 64 MB (64×2²⁰ bytes) video card and a 100 GB (64×10⁹ 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×1000³ 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)

Degree of support

User	5	4	3	2	1	0
Headbomb (ταλκ · κοντριβς) 05:30, 2 June 2008 (UTC)		X
Greg L (talk) 15:16, 30 May 2008 (UTC)		X
Fnagaton 19:08, 25 May 2008 (UTC)	X
Woodstone (talk) 20:42, 2 June 2008 (UTC)				X
SWTPC6800 (talk) 18:01, 30 May 2008 (UTC)		X
Seraphimblade Talk to me 05:42, 26 May 2008 (UTC)				X
MJCdetroit 19:50, 27 May 2008 (UTC)		X
Thunderbird2 (talk) 07:28, 6 June 2008 (UTC)					X
Dfmclean 19:00, 28 May 2008		X
Pyrotec 22:35 05 June 2008		X
New user

Vote and vote comments

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”

Discussion of vote comments

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. −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)

There’s loopholes, and then there’s loopholes.

• 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

Comment on Binary prefix (purplebox)

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₂, MB₂, GB₂,... and KB₁₀, MB₁₀ GB₁₀ 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² bytes) for solid state memory and base-ten math (1000² 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. −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.−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²⁰, 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. JIMp _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. −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)

File:20071210-672 startrektosclassictricorder.jpg

After ten long years, the IEC prefixes still aren’t any closer to real-world adoption than at first. Maybe the pro-IEC crowd is making use of forecasting tools not available to the rest of us.*

• 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). 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; −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).

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”

Google hits for last year pages
(May 212008)

prefix	Standard	IEC	%Standard	%IEC
K	267 000	3 540	98.7	1.3
M	433 000	3430	99.2	0.8
G	674 000	4 000	99.4	0.6
T	283 000	1 100	99.6	0.4
P	468 000	344	99.9	0.1
Z	8 450	219	98.5	2.5
Yotta	6 960	259	96.4	4.6
Total	2 140 410	12 892	99.4	0.6

Google scholar hits (all years)
(May 312008)

prefix	Standard	IEC	%Standard	%IEC
K	12,700	47	99.6	0.4
M	35,400	29	99.92	0.08
G	66,000	26	99.96	0.04
T	18,700	11	99.94	0.06
P	3,020	7	99.8	0.2
Z	94	1	98.9	1.1
Yotta	56	2	96.6	4.4
Total	135,970	123	99.91	0.09

Target upload date of Wednesday (June 4th)

Target upload date of Wednesday June (4th)

I think we are very, very close of gaining consensus on purple box. I suggest that we all take a good review of everything in the greenbox, bluebox, and purplebox to make sure that we're comfortable with them being uploaded and try to resolve our differences by that time. Make sure your votes are up-to-date in each section, and that they reflect the content of the box you're voting on. Greenbox will not be uploaded if there is no consensus for purplebox, so don't vote 1 in greenbox because you're not happy with purplebox.

We'll need to find a place to put the "These principles are not unbreakable laws" and for the "unecessary vagueness" section.

So let's give a push to polish those boxes as best we can for Sunday Wednesday. If no consensus is reached, then at least we'll be closer to that. If we have consensus when I wake up on Monday Thursday, I'll upload things and archive a copy of everything pertaining to the boxes in Units of Measurement Rewrite of (June 2008) (or something like that), leaving unresolved stuff behind so the bot may archive it in the regular archives as they get settled. Headbomb (ταλκ · κοντριβς) 04:01, 30 May 2008 (UTC)

• Headbomb, I agree that we are close to consensus on this. The only stumbling block that I can see is the deprecation of IEC units in the "purple box". There is no justification for it and no consensus for it. Therefore, trying to include it will only cause more instability. Greg L has said many times that FCL was crafted following many discussions with many editors and that is correct. The words he used for binary prefixes were carefully composed by him to find a solution that was acceptable to me and to him. Judging from Woodstone's reaction to the changing box over the past few days, I have the impression that Woodstone also finds them acceptable. So why don't we just use the relevant part of FCL to resolve this? It can be supplemented if needed by examples of what we all agree is good disambiguation (see Mac Pro and DEC 3000 AXP for examples that spring to mind). Let's include those explicitly and remove the controversial statements for which there is no consensus. Thunderbird2 (talk) 07:09, 31 May 2008 (UTC)

• First, I don't see what is the problem with this current version. You say that this version precludes the use of IEC units and that it should be more FCL aligned. But it is FCL aligned, and it IS possible to use IEC prefixes "when the article is on a topic where the majority of cited sources use the IEC prefixes" (if that ain't FCL inspired I don't know what is), on IEC prefix related topics, and in direct quotes. You agree that disambiguation in bytes and bits is sound (2^20 bytes/1024^2 bytes). And there's always the provision that these are guidelines and that whenever there is a good reason to not follow them, you shouldn't follow them. Headbomb (ταλκ · κοντριβς) 14:40, 31 May 2008 (UTC)

• The problem with the present version is very simple: it is biased. I didn’t say it should be more FCL aligned (there is no consensus for FCL in a wider sense, and introducing it in MOSNUM without consensus created a bad precedent), but suggested that we use the FCL text to resolve this issue. I agree that disambiguation using bits and bytes is acceptable, but not more so than IEC units.

• My main point, though, is that statements for which there is no consensus should not be included in MOSNUM. Doing so only creates instability. Thunderbird2 (talk) 15:07, 31 May 2008 (UTC)

• There should not be an upload because there is still no consensus on the purple box, and the blue box isn't even finished. --Gerry Ashton (talk) 15:15, 31 May 2008 (UTC)

• Thunderbird2, the changes by Headbomb are not biased because what the changes show is the real world consensus on the lack of use of these prefixes. Fnagaton 17:51, 31 May 2008 (UTC)

• Pushed the target date back to Wednesday to give us a bit more time so we do not reach a hasty and half-assed consensus.Headbomb (ταλκ · κοντριβς) 22:17, 31 May 2008 (UTC)

• I'm not for it at all, unless the IEC deprecation is removed. I have no problem with making the use of IEC units optional, but quite realistically, we use units that aren't often used by sources all day long. (How many sources use "long ton"? "Imperial gallon"? Kilocalorie?) Yet we mandate these for disambiguation, despite their infrequent use, they are clear and unambiguous terms. Seraphimblade ^{Talk to me} 13:43, 2 June 2008 (UTC)

• All of the examples you gave are far more commonly used and understood compared to the unfamiliar and virtually unused IEC prefixes. The point then being that using IEC prefixes is unacceptable to the vast majority. To be honest, we don't need a tiny minority to "be all for it" because the tiny minority point of view is just that, a tiny minority. Fnagaton 14:25, 2 June 2008 (UTC)

• When someone says "This pool can hold 35,000 gallons of water" the question people ask when unsure about which kind of gallon their are referring two is "Imperials gallons or US gallons?". When someone says "This hard drive has a capacity of 100 GB " the question people ask when unsure about the meaning of gigabyte is not "Gigabyte or gibibyte?" but rather "Decimal or binary gigabytes?". MOSNUM should reflect this. There's a penetration of ~0.6% (Google hits for IEC units last year) and 0.1% (Google scholar for all years). While Google tests have their flaws, such a bias in the result is very significant. Since wikipedia is not a crystal ball, and that IEC units are not even used by a significant portion of the scientific community, I hardly see why these de facto unrecognized units should be here. Headbomb (ταλκ · κοντριβς) 14:56, 2 June 2008 (UTC)

• I'll give you the same challenge that I gave Thunderbird. Give us an example of a use of IEC prefix perfectly compatible with the spirit of the MOS that is somehow prohibit by the current version of the purplebox. If you can't, your objection would be very weakly supported since your objection is based on the claim that the other disambiguation techniques (for gallons and calories, etc.) do not have majority usage when they actually are used by everyone. Headbomb (ταλκ · κοντριβς) 14:56, 2 June 2008 (UTC)

• All three of those directly challenged by Headbomb's question above have had several days notice of the target upload date. All three editors have not given a response to this question but have edited elsewhere instead, this is despite at least one of the editors specifically being made aware of the question. As Headbomb says "If you can't, your objection would be very weakly supported" so that means the oppose votes are only weakly supported. As Omegatron is so fond of repeating "we don't make decisions with votes" the implication being that we make consensus with reasonable arguments instead, also since the oppose votes are only weakly supported they have failed to demonstrate a reasonable counter argument. The conclusion is that consensus has been reached for the purple box as it now stands. Fnagaton 19:36, 5 June 2008 (UTC)

General comments

General comments on the rewrite

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, 2³⁰ (1024³); the decimal that it's the decimal, 10⁹ (1000³). JIMp _talk·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 #Uploading the rewrite (June 7th) (click on show in the Proposed text header). Headbomb (ταλκ · κοντριβς) 01:03, 6 June 2008 (UTC)

State of the re-write

State of the rewrite (June 3)

A few questionable things has happened here in the last few days that are comprimising what we are trying to achieve here. Many discussion are made assuming bad faith and full of personal attacks. If you think this targets by this, you probably are right, so please stop arguing with little regards for civility. If you cannot keep your cool, then please take an hour or two before replying.

Amongst questionable practices are the addition of the FCL into the greenbox after a month or so of conveniently avoiding to answer why exactly should FCL be included as a separate section. An addition which was conveniently made one day before the target date. I can't say for sure that this was an attempt to hijack the vote/game the system/try to shove a disputed section at the last minute and ride on votes for a FCL-free greenbox (which achieved consensus immediately before the addition of FCL), but I certainly have my suspicions, especially since its proponents consider the rest of us to be retards. At best this was a very unorthodox addition made at a very bad timing, at worse it's exactly how things should not be handled. Regardless of what the intents were with the addition of FCL to the greenbox, the fact remains that its proponents do not address the concerns raised by the opposition. The same phenomena is present at the purplebox: opponents to the partial deprecation of IEC prefix avoid to explain why exactly they are opposing the partial deprecation of IEC units, and it seems they cannot to be convinced to give us examples of how this partial deprecation harms wikipedia.

If people keep saying "Nuh uh it's black" when people argue "We have all these reasons to think it's white, I'm not saying it couldn't be black, but could you tell us why our reasons are bad and explain to us why it's black?", I'll invoked the principles that unsubstantiated objections can be disregarded.

So I ask of everyone, please substantiate your opinions, and stop taking dumps on people with whom you disagree. Headbomb (ταλκ · κοντριβς) 19:15, 3 June 2008 (UTC)

And also, please keep your votes up to date, and please vote on every box even if you aren't overly concerned with it. Headbomb (ταλκ · κοντριβς) 23:20, 3 June 2008 (UTC)

Uploading the rewrite (June 7th)

Uploading the rewrite (June 7th)

Well it's June 4th has gone by and things haven't moved here in 3 or so days. I interpret this meaning that everyone said what they wanted to say on the issue for now.

Since there is a lot that was said, and that things have significantly progressed since the rewrite started, I suggest that we upload what represents the closest thing there is to consensus right now (click show on the Proposed text below), archive the box-related discussion and continue from there. This will clean up the talk page, MOSNUM will have a significant overall, and it'll be easier to talk about what the next steps to take are.

The reasoning for which text maximizes the level of agreement is this.

Greenbox: Greenbox has near universal support (9 for vs. 1 substantiated against), so greenbox is uploaded as is.
Redbox: FCL redbox has strong opposition (2 for vs. 3 substantiated against) and the concerns were not addressed. Fganaton mentionned that a summary was needed because one could lose perspective. I feel that a summary for the units of measurement section is a reasonable request, so I summarized things (Summary redbox). While few weighted into Summary redbox (2 for vs. 0 against), I do not think that anyone has strong opposition (if any) to a summary of units of measurements, and since Fganaton's views are usually aligned with Greg L's, I assume that Greg L would approve of the inclusion of a summary.
Bluebox: Bluebox concerns seems to be centered around the delimitation rules, the rest seems to have consensus (5 for vs. 0 against), so bluebox can be uploaded without the rules, and delimitation rules can be uploaded at a later date.
Purplebox: Purplebox has consensus from everyone that cared to give reasons for things (7 for vs. 3 unsubstantiated against). Opposition to purplebox is based on little to no arguments at all, unsubstantiated opposition may be disregarded.

Cordially, Headbomb (ταλκ · κοντριβς) 18:38, 5 June 2008 (UTC)

Proposed text

Units of measurements

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 cm³). 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×10¹ y old, but rather John is 22 years old).

Unit symbols

Conventions

• Values and unit symbols are separated by a non-breakable space ( ) (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 ′′ (double prime)), and ft for foot (not ft., ' (single quote), or ′ (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·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 (·) to separate the symbols. For example ms is the symbol for a millisecond, while m·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⁻¹).

• 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 km², 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 m²).
• 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 m³ or 1 × 3 × 6 m).

Confusing units and symbols

• The degree symbol is °. Using any other symbol (e.g., masculine ordinal º or ring above ˚) 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 (10³), MM(10⁶), B (10⁹)). 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).

Quantities of bytes and bits

Historical background

Multiple-byte units
Decimal Value Metric 1000 kB kilobyte 10002 MB megabyte 10003 GB gigabyte 10004 TB terabyte 10005 PB petabyte 10006 EB exabyte 10007 ZB zettabyte 10008 YB yottabyte 10009 RB ronnabyte 100010 QB quettabyte	Binary Value IEC Memory 1024 KiB kibibyte KB kilobyte 10242 MiB mebibyte MB megabyte 10243 GiB gibibyte GB gigabyte 10244 TiB tebibyte TB terabyte 10245 PiB pebibyte — 10246 EiB exbibyte — 10247 ZiB zebibyte — 10248 YiB yobibyte — — —
Orders of magnitude of data

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 (10³); the other uses powers of 1024 (2¹⁰). 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 (2¹⁰) bytes, “megabyte” to mean 1024² (2²⁰) 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×1024² bytes) video card and a 100 GB (64×1000³ bytes) harddrive, A 64 MB (64×2²⁰ bytes) video card and a 100 GB (64×10⁹ 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×1000³ 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.

Scientific notation, engineering notation, and uncertainty

Notations

• Scientific notation is done in the format of 1 leading digit/decimal marker/rest of digits/×10ⁿ, where n is the integer that gives one leading digit.

• 1.602×10⁻¹⁹ is a proper use of scientific notation.
• 160.2×10⁻¹⁷ is not a proper use of scientific notation.

• Engineering notation is done in the format of leading digits/decimal marker/rest of digits/×10ⁿ, where n is a multiple of 3. The number of leading digits is adjusted accordingly.

• 132.23×10⁶ is a proper use of engineering notation.
• 1.3223×10⁸ 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×10² m region covered by 234.0×10⁶ 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×10² 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/×/10ⁿ/unit symbol (e.g. (1.534±0.35)×10²³ m

• Do not group value and uncertainty in parenthesis before the multiplier (e.g. do not write (15.34±0.35) × 10²³ m)

• Value/superscript positive uncertainty/subscript negative uncertainty/×/10ⁿ/unit symbol (e.g. 15.34+0.43
  −0.23×10²³ m)
• Value(uncertainty in the last digits)/×/10ⁿ/unit symbol (e.g. 1.604(48)×10⁻⁴ J)
• Value/±/relative uncertainty(percent)/unit symbol (e.g 12.34±5% m²)

• {{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: —MJCdetroit ^(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 [3])
• Support: JIMp _talk·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

Comments on votes

• 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. −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:

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. —MJCdetroit ^(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. —MJCdetroit ^(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:

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.

Thunderbird2 (talk) 07:40, 6 June 2008 (UTC)

• 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)

:: Well if your computer can't handle 500 k of text... What’s that supposed to mean?

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. JIMp _talk·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?

Consensus for promotion or deprecation of IEC units

The following is from a recent archive:

Archived votes that were made two to three months ago

---

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 JIMp _talk·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. JIMp _talk·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)

• 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?

Thunderbird2 (talk) 16:35, 6 June 2008 (UTC)

• 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. −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. −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 • 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."

  Wallich, Paul (April 2008). "Tools & toys: Hacking the Nokia N800". IEEE Spectrum. 45 (4). IEEE: 25. doi:10.1109/MSPEC.2008.4476441.

  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

Section from a March archive titled "There is no common usage among readers"

---

I see a lot of people saying "we should not use IEC prefixes because readers are unfamiliar with them" or "we should use the ambiguous units because readers are familiar with them". But I don't think there's any merit to this argument.

Wikipedia is a general-purpose encyclopedia, not a computer science textbook. The vast majority of our readers don't know that "KB" is supposed to mean 1,024 in the first place. "KB = 1024" is just as unfamiliar as "KiB = 1024". This is especially true in metric countries (which is pretty much all of them except the US). Ask friends who are not from technical backgrounds or look through Yahoo Answers:

• Resolved Question - how many bytes are in a kilobyte? how many kilobytes are in a megabyte? how many megabytes are in a gigabyte?
  • Best Answer - Chosen by Voters: "1000 1,000,000 1,000,000,000"
• "1,000,000 kb in 1 g"
• "1000 Bytes in a Kilobyte, 1000 KB in a Megabyte, 1000 MB in a Gigabyte, 1000 GB in a Terabyte - So the answer is a million."
• "1000 bytes to make a kilbyte, 1000 kb = 1 mb, 1000 mb = 1 gb"
• "a byte is a size measurement of memory stored by a device. a kilobite (KB) is 1000 bites. a megabite (MB) is 1,000,000 bites (1000KB). A gigabite (GB) is 1,000,000,000 bites (1,000,000KB, 1,000MB) and a terabite (TB, probably) is one trillion 1,000,000,000,000 bites."
• "a hundred thousand approximately... i guess..."
• "10,000 kilobytes are in a gigabyte"
• "kilobyte 1000 bytes / megabyte 100,00 byte / gigabyte 1,000,000 bytes"

Regular people have no clue.  :) There are certainly people on there who know the Microsoft definition, but there are many more who don't. I don't think we're confusing anyone any more by using IEC prefixes than we would using Microsoft prefixes. — Omegatron 16:04, 30 March 2008 (UTC)

The vast majority of encyclopedias use the terms that are commonly found in the real world. i.e. They don't use IEC prefixes because IEC prefixes are not common. Fnagaton 01:02, 31 March 2008 (UTC)

We are not talking about "common" terms, but about uncommon technical terms used in articles about technical matters. Nor do I believe it is true that the standard is "common" usage, whatever that means! Since IEC prefixes have been adopted by IEEE and are unambiguous their usage in appropriate technical articles should be encouraged - an encyclopedia is about teaching, isn't it? Tom94022 (talk) 17:34, 1 April 2008 (UTC)

An encylopedia is about teaching what is in the real world and not in the business of supporting failed standards. Fnagaton 18:03, 1 April 2008 (UTC)

The "IEEE" does not use the IEC binary prefixes. The IEEE Standards Association is just one part of the IEEE. The IEEE Publications have 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."

Wallich, Paul (April 2008). "Tools & toys: Hacking the Nokia N800". IEEE Spectrum. 45 (4). IEEE: 25. doi:10.1109/MSPEC.2008.4476441.

I guess the 385,000 technology professionals in industry, government, and academia that read the IEEE Spectrum each month[4] can deal with the ambiguous "128 megabytes of RAM". -- SWTPC6800 (talk) 01:33, 2 April 2008 (UTC)

I dare say that IT professionals can work out from the context what kind of megabyte is meant. I can do so myself sometimes, but certainly not always. Either way, it is a red herring - the majority of WP readers don't even know that MB has more than one meaning, let alone how to differentiate between the different meanings. That's why there is a need to disambiguate. Thunderbird2 (talk) 19:14, 2 April 2008 (UTC)

But not to disambiguate by using IEC prefixes since that way doesn't have consensus. The consensus at the moment looks like disambiguation by stating the exact number of bytes is acceptable. Don't you agree? Fnagaton 19:45, 2 April 2008 (UTC)

It's not a red herring since it shows quite nicely that even the IEEE don't enforce their standard in their own publications, which just goes to show you can't always work against real world consensus for common use. ;) Fnagaton 19:46, 2 April 2008 (UTC)

Three points:

• The red herring is that the experts can work it out for themselves. The experts can work it out for themselves, but the point is an irrelevant one here.
• No evidence has been presented to support the statement that IEEE journals do not follow their own standard.
• I have always agreed that an exact number of bytes is an acceptable disambiguation method, but Swtpc6800 implied with his statement that disambiguation was not necessary. It is.

Thunderbird2 (talk) 22:09, 2 April 2008 (UTC)

No, just because experts might be able to work it out does not preclude the fact that the IEEE journel cited above uses prefixes in a non-IEC way. What is a red herring is you mentioning "experts can figure it out" since that is an irrelevant point and does not alter the presented facts. The evidence is the cite from the IEEE journal, since if the IEEE do follow IEC prefixes then the journal entry cited above would not show those prefixes being used in a non-IEC way. Q.E.D. What you are doing is denying that the cite has been made when it is a fact that the cite has been made and then trying to waffle about "no evidence" when that is the evidence, which is silly. It's like trying to deny a man is standing outside your window by closing your curtains. The third point you made about disambiguation is also irrelevant to the point that the IEEE journal cited uses prefixes in a way that are non-IEC. Also your third point is a straw man logical fallacy since you misrepresented what the editor wrote and then presented it in your own words. Fnagaton 22:49, 2 April 2008 (UTC)

The members of the "Institute of Electrical and Electronics Engineers" are not just IT professionals. The typical issue of Spectrum covers power generation and transmission, electric automobiles, satellite communications, radio systems, electronic sensors and the occasional article on computers. The readers have more expertise with megawatts and megahertz than megabytes. Thunderbird2, could you provide some samples of wide circulation magazines that use the IEC binary prefixes. Technical journals that publish completed papers from authors tend to allow MB, Mbyte or MiB. I am thinking about magazines that have complete editorial control of the articles. -- SWTPC6800 (talk) 00:50, 3 April 2008 (UTC)

Google: "magazines using iec prefixes" First link User:Swtpc6800/Adoption second link User:Swtpc6800/Standards. Congrats ;) Fnagaton 01:02, 3 April 2008 (UTC)

I do not claim MiB is in widespread use, nor have I ever done so. It is used by those publications that strive to be unambiguous. A magazine is free to make that choice and most prefer the ambiguous MB. Thunderbird2 (talk) 10:43, 3 April 2008 (UTC)

Published by the IEEE. It speaks volumes about the lack of acceptance of the IEC prefixes when an IEEE publication doesn't enforce their use. Fnagaton 11:12, 3 April 2008 (UTC)

The journals published by the IEEE and the ACM predominantly use MB and Mbyte. (You also see the occasional paper using MiB.) The current IEEE Computer Society Style Guide has this entry. MB: megabyte; use Mbyte (40-Mbyte hard disk, 12 Mbytes of memory) [5]

A common claim by the IEC advocates is that the IEC prefixes are use by organizations and "publications that strive to be unambiguous". Could someone name a few? (Other than standards groups.) Who is striving to be "ambiguous"? -- SWTPC6800 (talk) 00:57, 4 April 2008 (UTC)

FWIW, The current IEEE Computer Society Style Guide also has this entry.

M: SI prefix for million or mega (40-Mbyte hard disk, 12 Mbytes of memory)[6]

This defines 12 Mbytes of memory = 12,000,000 bytes and we all know that is incorrect. Doesn't this further illustrate the need to get it right in Wikipedia, even the IEEE Computer Society doesn't get it right. IMO, IEC Binary prefixes are a good way to get it right. Tom94022 (talk) 19:05, 5 April 2008 (UTC)

---

• 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)

from Headbomb's talk page

From Headbomb's talk page

I've just noticed this on Headbomb's talk page:

FCL and "consensus"

Headbomb: In the interests of helping to get the entire greenbox its much needed consensus, I've voted to support it and have given Fnagaton my permission to vote on my behalf. I just can't be watching over this frequently enough to adapt to rapidly changing events. I do ask that you make sure that what is going to MOSNUM has a proper consensus. Although Omegatron and Thunderbird2 complain that FCL didn't have a proper consensus when it was posted, outside, uninvolved editors agree that it did. And it is now on MOSNUM, where it calls for no longer using the IEC prefixes. If push came to shove, I'd organize a big-ass, Wikipedia-wide vote and FCL would have seriously deep tap roots. I would see it as a step backwards if the greenbox replaces everything--including FCL--only to be followed immediately by bitter complaints about how it didn't achieve a proper consensus. I'll very quickly take a strong stand that FCL goes right back in if some elements prevail in their claims that the binary prefix-related portion of the greenbox didn't have a consensus. Do things the right way. Good luck. Greg L (talk) 23:04, 5 June 2008 (UTC)

• What kind of argument is that? The binary prefix related part of FCL was about the only part of FCL that did have consensus. Greg L has repeatedly argued that he and I worked together to find a form of words that was acceptable to both of us. And I agree with him. That is why I don't understand why he and Headbomb are arguing against it now. This is the only part of Headbomb's proposal that is controversial. We have a form of words that is acceptable to all parties, but whenever I suggest we use it I am shouted down and reverted. In what sense is that maximising consensus? Thunderbird2 (talk) 10:26, 7 June 2008 (UTC)

• Misrepresenting the consensus by quoting individual comments out of context is not a valid argument, you'll note that above Greg has actually supported the text with his comment "Greg L (talk) 22:53, 5 June 2008 (UTC)". Your change was reverted because you refused to give valid reasons to substantiate your position and because stronger arguments with stronger reasons were given by multiple editors. Fnagaton 10:44, 7 June 2008 (UTC)

• First, it wasn't an argument for anything. Greg wants things to be done the "right way" so there's no revert war à la FCL, and I agree with that. And, BTW, that form of word is not acceptable to all parties. If it were, it wouldn't have been reverted now would it? Fact is that that form moves about 3 votes up, and about 8 votes down (which is hard to consider an "increase" in consensus). It's not that we "ignore" you "just because you're against the IEC units", it's that your arguments are weak. You've got I don't like it (aka not an argument worth anything) and 2) Wikipedia is a democracy (while it's not).

Since Wikipedia is not a crystal ball, that familiarity is needed, that IEC units have near-zero adoption, and that Wikipedia is not a place to promote anything (which is a shame IMO, else we could use IEC units legitimatly), then it follows that IEC units shouldn't be used here. Headbomb (ταλκ · κοντριβς) 13:08, 7 June 2008 (UTC)

Headbomb: In the interests of helping to get the entire greenbox its much needed consensus, I've voted to support it and have given Fnagaton my permission to vote on my behalf. I just can't be watching over this frequently enough to adapt to rapidly changing events. I do ask that you make sure that what is going to MOSNUM has a proper consensus. Although Omegatron and Thunderbird2 complain that FCL didn't have a proper consensus when it was posted, outside, uninvolved editors agree that it did. And it is now on MOSNUM, where it calls for no longer using the IEC prefixes. If push came to shove, I'd organize a big-ass, Wikipedia-wide vote and FCL would have seriously deep tap roots. I would see it as a step backwards if the greenbox replaces everything--including FCL--only to be followed immediately by bitter complaints about how it didn't achieve a proper consensus. I'll very quickly take a strong stand that FCL goes right back in if some elements prevail in their claims that the binary prefix-related portion of the greenbox didn't have a consensus. Do things the right way. Good luck. Greg L (talk) 23:04, 5 June 2008 (UTC)

From MOSNUM talk page (too big to load)

• First, it wasn't an argument for anything. Greg wants things to be done the "right way" so there's no revert war à la FCL, and I agree with that. And, BTW, that form of word is not acceptable to all parties. If it were, it wouldn't have been reverted now would it? Fact is that that form moves about 3 votes up, and about 8 votes down (which is hard to consider an "increase" in consensus). It's not that we "ignore" you "just because you're against the IEC units", it's that your arguments are weak. You've got I don't like it (aka not an argument worth anything) and 2) Wikipedia is a democracy (while it's not).

Since Wikipedia is not a crystal ball, that familiarity is needed, that IEC units have near-zero adoption, and that Wikipedia is not a place to promote anything (which is a shame IMO, else we could use IEC units legitimatly), then it follows that IEC units shouldn't be used here. Headbomb (ταλκ · κοντριβς) 13:08, 7 June 2008 (UTC)

My arguments are weak? Let’s analyse yours:

1. that form of word is not acceptable to all parties. If it were, it wouldn't have been reverted now would it? You tell me. Name me one editor, other than yourself, to whom the FCL wording on binary prefixes is not acceptable.
2. Wikipedia is [not] a democracy: Sure, but then what is the relevance of “3 votes up, and about 8 votes down”?
3. Wikipedia is not a place to promote anything: Again, agreed, but it does not follow that “IEC units shouldn't be used here”. Use and promotion are quite different things. Where there is no consensus on a statement, the best policy is silence.

Thunderbird2 (talk) 14:08, 7 June 2008 (UTC)

1. Well other than me, there's Greg L, Fnagaton, Dfmclean, Pyrotec...

• Precision: I meant that these people agree with me that my proposed wording is better than yours.

1. You brought votes as an absolute mesure of consensus, and said that your wording increased it. Why then did the votes not aligned themselves to "support" when you struck the section about disambiguation?
2. Yes, it follows. The deprecation is partial, as in you can use IEC units when quoting sources, when a a clear majority of relevant sources consistently use then, and on articles pertaining to IEC units. I've asked you (and others) give me one example of a use of IEC unit that is currently forbidden by the MOSNUM but which should be allowed because it would follow the spirit of the MOS. It's been over two weeks now, so I'm lead to believe that you don't provide one because you can't provide one.

Headbomb (ταλκ · κοντριβς) 14:22, 7 June 2008 (UTC)

1. But that's precisely my point. Greg L makes it clear above that he does support FCL. So why do you insist that he doesn't?
2. That's a very good question, but I cannot answer it. You need to ask Greg L why he would vote against something that he supports. Perhaps there was a misunderstanding (Greg is often quick to question my motives).
3. er ... what are you talking about? The wording forbids all use of IEC units except in very limited exceptions. There is no point in picking out any one article because my reasoning applies to all articles that do not currently disambiguate. Are you saying there are none left?

Thunderbird2 (talk) 15:55, 7 June 2008 (UTC)

1. And Greg L also made it clear that this wording summarizes the core FCL in a concise and efficient way.
2. You should ask yourself if your interpretation of Greg L's post isn't flawed. Greg did not vote "against" something he supports, he voted that this wording was at least equivalent, but I'm under the impression that he finds it superior to the old FCL since it is more concise, and more to the point.
3. If your reasoning applies to all article, then it shouldn't be a problem finding an example. But considering I've asked you at least 10 times by now to give an example of how the letter of the proposal prohibits a use of IEC units that should be allowed under the spirit of the MOS, and considering that you repeatedly failed to provide any, I'm forced to conclude that you simply can't. Unless you bother giving examples, this discussion is over as far as I'm concerned.

Headbomb (ταλκ · κοντριβς) 16:11, 7 June 2008 (UTC)