Misplaced Pages

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

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
< Misplaced Pages talk:Manual of Style Browse history interactively← Previous editNext edit →Content deleted Content addedVisualWikitext
Revision as of 02:52, 5 March 2008 editSesshomaru (talk | contribs)Rollbackers40,876 edits Concern: new section← Previous edit Revision as of 03:03, 5 March 2008 edit undoGimmetrow (talk | contribs)Administrators45,380 edits Concern: people still not aware it works for IPs tooNext edit →
Line 420: Line 420:


] (or any other section I'm aware of) does not clarify that commas '''have to''' be inserted for full dates which are wiki-linked. Example; a comma automatically appears in ] ] (note that it does not for ] ] ] and February 14 2008). In other words, if the date is linked, the comma is visible to viewers even though it is not edited into the context. So, can someone see the logic in ? To me, this is like placing the |right| to an image which already has a mark-up like |frame| or |thumb| which sets the image to the right by default. My proposal — the guideline '''should say''' that a comma does not need to be inserted for a correctly linked date. Is this understandable? ] <small>(] • ])</small> 02:52, 5 March 2008 (UTC) ] (or any other section I'm aware of) does not clarify that commas '''have to''' be inserted for full dates which are wiki-linked. Example; a comma automatically appears in ] ] (note that it does not for ] ] ] and February 14 2008). In other words, if the date is linked, the comma is visible to viewers even though it is not edited into the context. So, can someone see the logic in ? To me, this is like placing the |right| to an image which already has a mark-up like |frame| or |thumb| which sets the image to the right by default. My proposal — the guideline '''should say''' that a comma does not need to be inserted for a correctly linked date. Is this understandable? ] <small>(] • ])</small> 02:52, 5 March 2008 (UTC)
: See also ]. Some people still don't realize a comma is added in ] ], and removed in ], ], even for IP editing. The revert was based on a misunderstanding. ] 03:03, 5 March 2008 (UTC)

Revision as of 03:03, 5 March 2008

Archiving icon
Archives
General Binary prefixes Years and dates See also


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

General IT prefix discussion

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

Do you have any opinion on the topic that is being discussed here? — Aluvus t/c 13:02, 17 January 2008 (UTC)
Yes I do. A few peoples here are trying to get the Manual of Style to adopt an obscure method of measuring computer storage. This edit war has been going on for several years. You are arguing over the rules of the edit war. The real question is should the Manual of Style follow a standard that had not reached 1% adoption in the real world after 9 years. -- SWTPC6800 (talk) 14:52, 17 January 2008 (UTC)
Just let me extract the interesting parts of your text: "few people", "an obscure method of measuring computer storage", "war", "1% adoption", "real world". Hopefully people will realize how pointless this discussion is. Don't waste your time, don't let them trick you. As long as this topic is under tight control of certain individuals, you can't win. Again don't waste your time with facts. They shall be ignored, absolutely, without remorse. --217.87.122.179 (talk) 05:57, 2 February 2008 (UTC)
You are wrong and do not attempt to misrepresent other editors with your incorrect anonymous rants about "certain individuals". Fnagaton 10:03, 2 February 2008 (UTC)


Whether manufacturers are using these units is irrelevant. Fact is that the units are used inconsistently. Sometimes they have a binary meaning, sometimes a decimal one. Many of the readers wil not be aware which meaning is applicable in a specific mention of the unit. Therefore it is the task of an encyclopedia to make sure the reader is able to draw the correct conclusion. This can be achieved by always adding a conversion to (or a confirmation of) a standardised and well documented unit. We achieved consensus to do it that way a while ago. According to the guidelines units from a primary source should come first. So the usage would be:
  • with decimal meaning: 64 MB (61 MiB)
  • with binary meaning: 64 MB (=MiB)
Woodstone (talk) 19:42, 17 January 2008 (UTC)
Fact, KB, MB, GB are defined by standards organisation to be power of two. Fact, some manufacturers use other meansing. Lets say for the sake of argument some manufacturers started using KiB but in a decimal sense, that would be inconsistent use, so what then? It's not *always* needed though, just disambiguate (if you need to at all) the first occurrence in an article. Fnagaton 22:18, 17 January 2008 (UTC)
Regardless of how inconsistent sources are, a conversion to standard units would always tell the user unambiguously what the correct meaning is. I agree that if the same number is used several times, one conversion might be enough. But it is just a welcome service to the reader to convert every number at least once. −Woodstone (talk) 22:31, 17 January 2008 (UTC)
I'm just going to quote "Fact is that the units are used inconsistently" and "Regardless of how inconsistent sources are" then grin for a while because I find it funny. ;) Seriously though the JEDEC, who are the standard organisation for memory and who have majority consensus, do define kilobyte etc in their standard. So which standard body is the better one to choose, the one that has a tiny 0.5% use (no consensus) in the real world or the one that has the huge majority consensus? And then if there is any use that differs from the JEDEC standard then make a point of disambiguating it with exact numbers of bytes. Fnagaton 22:56, 17 January 2008 (UTC)
I see your point about fun: it is funny: the more inconsistent usage is, the more there is a need for conversions. You may know exactly in which cases a particular interpretation is standardised by JEDEC, most people have never even heard about JEDEC. Why not help them by addding a conversion? −Woodstone (talk) 23:03, 17 January 2008 (UTC)
Because according to the JEDEC it's not inconsistent, it is powers of two in size. Following on from the above I could point to companies using KiB but in the decimal sense. Then I could say "inconsistent" and then you'd have to drop pushing for KiB to be used, to ape the arguments used by some IEC supporters for example. Pushing for a particular style of prefix isn't actually the point, as we'll see in a second. What happened is that some other "standards organisation" came along and invented a new term, but it's not used except by a microscopic minority. However the question isn't about what standards organisation is best or whatever, no matter how tempting that is it doesn't actually tackle the real issue and it just causes people to sit behind their preferred camp. Remember you cannot say IEC is consistent since it has been shown IEC is inconsistent with the consensus in the real world. Also remember you cannot say IEC is not ambiguous because of the companies that use KiB in the decimal sense and also because JEDEC define it to be not ambiguous. The question is, why advocate something that only has a tiny 0.5% support, i.e. doesn't have consensus? Fnagaton 23:09, 17 January 2008 (UTC)
Well, a kilobyte appears to be 2 raised to the power 10 (=1,024) in most systems and one megabyte can be either 1,000 kilobytes or 1,024 kilobytes; it gets a bit difficult to determine how many bytes there are in a particular wiggit. Some system is need to sort it out. I've lost track of the arguments, what's your proposal to sort it out - I don't think context is a valid approach.Pyrotec (talk) 23:45, 17 January 2008 (UTC)
The most common use being power of two. The only non-ambiguous way which also doesn't use neogolisms, i.e. is consistent with consensus, would be the following: Follow JEDEC or be consistent with the sources relevant to the article. If something uses JEDEC specified prefixes but in a non-standard sense then use the units found in the source but disambiguate by stating the exact number of bytes in brackets. Otherwise (and rarely) if some other units are used (like IEC) in the article due to being consistent with sources then disambiguate with JEDEC. Fnagaton 00:00, 18 January 2008 (UTC)
Or we forget it all for now and just make sure the guideline stays as it is in its stable state. Fnagaton 00:02, 18 January 2008 (UTC)
There is some confusion on binary versus decimal units of computer storage. However the computer industry and the technical press do not think is significant enough to change to a new units system. Fnagaton is very generous to say that the IEC prefixes have 0.5% acceptance. The industry treats kibi and gibi as something the IEC made up one day. It is not Misplaced Pages's mission to promote a failing standardization effort. If the IEC binary prefixes gain significant support Misplaced Pages could consider using them. -- SWTPC6800 (talk) 01:55, 18 January 2008 (UTC)
Now that's one horrible misuse of a quote. Did you think it applies because the headline looks fitting? I suggest you actually read this policy. It's also not legit (and I don't need any policy to back this up) to use arbitrary made up numbers like "0.5%" in a discussion. --217.87.122.179 (talk) 22:03, 2 February 2008 (UTC)
0.5% is not arbitrary and is not "made up".
Historical use search terms Results
kilobyte -wikipedia 1,940,000
megabyte -wikipedia 6,190,000
gigabyte -wikipedia 3,640,000
Total: 11,770,000
IEC Search terms Results
kibibyte -wikipedia 28,800
mebibyte -wikipedia 17,100
gibibyte -wikipedia 19,000
Total: 64,900
Consensus for historical use: 99.449%
Fnagaton 22:51, 2 February 2008 (UTC)
It's good that you explain how this figure was determined. This shows that the value is less than useless. Many results may to a certain extent show that something is widely known. The opposite is not true. Lack of results does not prove anything. Not to mention that this method is still arbitrary because it excludes the short forms which are far more common in my experience. Of course it's obvious that MiB has more meanings than Mebibyte and MB has also many meanings in different areas. Last but not least, this method excludes not only results from wikipedia or citing wikipedia, it excludes any kind of result which mentions or links wikipedia which may have nothing to do with this topic. --217.87.122.179 (talk) 00:15, 3 February 2008 (UTC)
The preponderance of evidence shows that real world consensus is against your point of view. What evidence have you given in reply? Nothing, no evidence, you've just written waffle about "less than useless". The numbers are facts that do not support your point of view so you are wrong again because when you claim "it's less than useless" does not make it so. Misplaced Pages is excluded for the very good reason that a while ago someone made many hundreds of changes to use kibibyte etc and that means including Misplaced Pages would contaminate real world results. Also Wikiepedia is excluded from the results to show real world use. You also showed a search earlier on that did "-wikipedia", unless you now want to retract your earlier post? Trying to do a search for the much shorter versions like MiB ("Men in Black" for example) is also much more likely to pickup use of those three letters that has nothing to do with computers so your point is not well thought out because your proposal would have less much meaningful results. Fnagaton 01:07, 3 February 2008 (UTC)
It is Misplaced Pages's mission to provide clear and accurate information to the general readership. If unit like MB is met, it is never obvious what quantity this represents. Usage depends on the context (e.g. disk, memory chip, data tranfer). Many people do not know which is used when, and even less what JEDEC is and if it applies to the particular occurrence of the unit. The solution is giving a conversion to a world standard. Even if that standard not often used, it is still well documented and unambiguous—just what is needed to eliminate uncertainty. −Woodstone (talk) 09:33, 18 January 2008 (UTC)
Woodstone, as explained above what you see as "never obvious" is a red herring because what you call "the world standard" is not actually a "world standard" and it is not unambiguous. The real question is this, why advocate something that only has a tiny 0.5% support, i.e. doesn't have consensus? Fnagaton 12:04, 18 January 2008 (UTC)
No, the real question is: how can we inform the reader clearly and unambiguously about the meaning of quanties given. Just using MB does not do that, because its meaning is context dependent. So what device are you proposing to achieve the goal of being informative. −Woodstone (talk) 12:41, 18 January 2008 (UTC)
Like I said above, express the exact number of bytes as disambiguation in brackets. For example 2KB (2 bytes) is the only unambiguous way of stating the number of bytes without using neologisms and it also shows that in this case it is using the binary context. Fnagaton 13:27, 18 January 2008 (UTC)
No, "2 KB (2^11 bytes)" is not unambiguous at all because there is always the possibility of mistakes. In this case, I'd assume the editor forgot the "i" and typed KB instead of KiB. Or worse, maybe someone added (2^11 bytes) because he assumed 2 KB was meant to mean 2048 when in reality it's really 2000. You might think it's "obvious" from the context, but context can only provide a rule of thumb. In many cases, the editor was just careless and typed "KB" instead of "kB". Many people don't know that SI prefixes are case-sensitive and that 'K' is incorrect as abbrevation for kilo (1000, one thousand). Thus, a chain of errors and "well-meant" edits can cause the following: 2000 bytes -> 2kB -> 2KB -> 2048 bytes. Same applies to "bits". Last but no least, this kind of hint reinforces the idea that KB absolutely means 1024. Sometimes less is more. If you think writing "(2^11 bytes)" is useful at all, why don't you drop the "2 KB" completely? It's not common practice in Misplaced Pages to write the same twice in different words. --217.87.122.179 (talk) 21:13, 2 February 2008 (UTC)
You are incorrect because "2 KB (2^11 bytes)" is not ambiguous and because it expresses exactly the number of bytes that are used. You are also incorrect because your "what if there is a mistake" scenarios are also irrelevant red herrings because as already stated in the guideline "...one must be certain... before disambiguation" and trying to throw out using a particular unit just because someone might edit an article incorrectly is no valid reason at all. Taking your point of view that would mean nobody changing anything because there might be a mistake somewhere. Thus your "many people" point is also irrelevant because if someone is not certain then they shouldn't be editing on a topic they are not certain about. Also changing KB to KiB when in the uncertain "many people" scenario you use is also wrong because the person is not sure what they are doing and could change something incorrectly. Dropping the "2 KB" completely is also not correct since as I have posted before consistency with the terms used in the reliable sources relevant to the subject is important. You are also wrong because disambiguation, "writing the same twice in different words", is very common. Fnagaton 21:24, 2 February 2008 (UTC)


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

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

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

I really like the way this is heading, if it can be made to work. If there were such a guideline, I wonder whether it would actually be followed though. I think it is worth trying. Thunderbird2 (talk) 16:30, 18 January 2008 (UTC)
Yes using 2 and 10 notation would make it completely unambiguous and it also gives a very good hint as to what format is used for binary or more rarely decimal. Also it lets articles use the type of units that are used in the sources. Which is a bonus since maintaining consistency with sources as well as following the real world consensus is a really important issue for me and I suspect many others think the same. Of course as with disambiguation it need not be everywhere, just so that the article makes sense. Fnagaton 17:00, 18 January 2008 (UTC)
The suggestion appears to have some merit. Note: powers of three in decimal, e.g. 10, means that everything is rounded in thousands; and powers of ten in binary, e.g. 2, means that everything is rounded in kilobytes (=1,024).Pyrotec (talk) 17:11, 18 January 2008 (UTC)
I'm not sure how many readers wil be comfortable with this notation. In any case, I think what is being suggested is that for the binary meaning of the prefixes, it should be written as a power of 2, where the exponent is a multiple of 10. For the decimal meaning of the prefix, it should be written as a power of ten, where the exponent is a multiple of 3. --Gerry Ashton (talk) 17:28, 18 January 2008 (UTC)
I'm not sure whether Gerry Ashton's comment relates to my comment above, or an early one. My comment related to a question by Fnagaton which has since been edited, so it reads differently now & is no longer a question. My interpretation of Woodstone's comment, was a sequence of thousands & kilobytes, e.g 0.02*10, 0.2*10, 2.0*10, 0.02*10, 0.2*10, 2*10, etc, and a similar sequence for kilobytes (sorry I'm too lazy to do the binary sequence in kilobyte sequences). But if someone wants to see it?Pyrotec (talk) 17:43, 18 January 2008 (UTC)

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

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

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

How about: "This memory stick from company X is labeled as 1MB (1024×10bytes)" Fnagaton 18:09, 18 January 2008 (UTC)
How about: "This memory stick from company X is labelled as 1MB (2×10bytes)" (not "*" as above). Rich Farmbrough, 14:03 1 February 2008 (GMT).
or "This memory stick from company X is labelled as 1 MB (1.024 million bytes)" Thunderbird2 (talk) 14:10, 1 February 2008 (UTC)
No. These are the worst options. In one regard it fails as soon as you get to a billion and especially beyond because US and European billion differ. The next higher magnitude which will be common in 2-4 years (tera respectively tebi) has no layman equivalent. If you write "1 MB (2^30 bytes)" any sensitive reader would assume that 1 MB is always exactly 2^30 bytes. There is no reason to assume a unit would differ depending on context. The solution is very simple, use units correctly or don't use them at all. If a unit has supposedly more than one meaning, it is by definition not a U-N-I-T. unit comes from unity. No unity, no unit. Kindergarten logic suffices. --217.87.122.179 (talk) 06:07, 2 February 2008 (UTC)
You are wrong 217.87.122.179 because the units are de facto standards used in the real world and Misplaced Pages is descriptive not prescriptive. To use neologisms that are very rarely used in the real world (<1%) only confuses the matter even further. Fnagaton 09:53, 2 February 2008 (UTC)
He is right in so far that the IT industry’s adoption of metric prefixes, beginning 40 years or so ago, in a different than standardised sense is the root of the problem. Only that made ambiguity possible. Separate binary prefixes should have been developed back then, but they weren’t, leaving us with the mess.
You are right that Misplaced Pages is descriptive – in intention at least, by its importance and influence nowadays, being part of the real world, it is defacto quite prescriptive! –, but you are also wrong, because its style guide, unlike encyclopaedic information, has to be prescriptive to some degree. MOS may very well choose to adopt a rule by reason that would not have been derived from observing common usage. IT prefixes used to be such a case, where MOS editors came to the conclusion that it’s better to diverge from common and source usage, adopting an international public standard instead to make the project less ambiguous and more homogenous. Some months ago this changed (after epic-length, tiresome discussions), because some article authors, like you, didn’t like to adapt their habits. The descriptivism myth evolved.
You are also wrong in that you didn’t respond to any of the points the IP user raised; just called him wrong, repeating your weak arguments once again. He does have at least one very valid argument: “There is no reason to assume a unit would differ depending on context.” — Christoph Päper 14:07, 2 February 2008 (UTC)
The IP user and you are wrong because it is fallacious to try to claim something is "different than standardised sense" just because a so called standards body decides to produce something contrary to what is the de facto standard. You are also wrong because the MOS is not prescriptive beyond what is actually common sense. You are also wrong because I did respond to the "points" the IP user raised, you will note this is the case since I wrote "because the units are..." giving a perfectly valid and correct reason. What you claim is the IP user's "valid argument" is actually shown to be a red herring by the very fact that the units have well known use. You are also wrong because the arguments put forward by me are stronger than what you have put forward and just because you disagree doesn't mean you are correct. Actually I'm giving you the benefit of the doubt here because you have put forward no such counter argument, instead you have attempted to question my motives and claimed a valid logical reason is somehow "repeating your weak arguments" without giving any supporting evidence. You are also wrong in your summary of the history of this topic and I demand that you retract your misrepresentation about what you think my motives are. Fnagaton 18:39, 2 February 2008 (UTC)
You are reacting on trigger words again instead of reading carefully and responding adequately. First came decimal metric prefixes (which I wrote about), then came bits and bytes (and octets and words), then came binary “adaptation” of SI prefixes in IT – with the side effect of capital k which I welcome –, then came disambiguity, then came IEC prefixes, then came Misplaced Pages. Where am I wrong here?
There is no such thing as common sense, never use it as an argument. The MOS is not prescriptive in the sense that it would say people what to do, but it’s prescriptive in the sense that it says what articles should look like in the end. (And yes, it’s often watered down in that regard, which I consider a failure.)
The IP users said, a unit with multiple meanings was not a unit by definition. You say that (he’s wrong and) the units under discussion were being used with multiple meanings, trying to prove your but actually also proving his point. His definition can’t be wrong, it just may not match yours.
The (here logical, not empirical) expectations of the readership are quite the opposite of a “red herring” argument in a discussion about our style guide! If the prefixes, when applied to bits and bytes, always were used in a binary sense (and decimal everywhere else), your point might stand, but they ain’t, e.g. in rates (kbit/s etc.).
I tried to limit my response (after I couldn’t suppress it completely), because I think everything has been said on the matter, although people still come to different conclusions, because their views about the role of Misplaced Pages and its MOS differ. (You try, intensional or not, to devalue the other position by calling it prescriptive and neological, which aren’t bad things per se, neither is de facto.) If I agreed with your presuppositions I would probably come to the same conclusion, because I don’t contest most of the facts you bring up again and again, thinking or at least implying that this was what needs to be discussed when actually we disagree on a higher level, which makes your points irrelevant – weak probably was an inappropriate or misleading term.
You’re in no position to demand anything from me (nor anyone else here), but, please, feel free to correct or at least discredit my summary, my view of the process.
Gee, I wish there was anything besides carnival outside so I hadn’t felt the temper to engage in this again. — Christoph Päper 01:24, 3 February 2008 (UTC)
You are incorrect because you are at fault here for not "reading carefully and responding adequately" (as you put it). This is because you misrepresent what I write and you attempted to misrepresent my motives in your summary of the history of this topic when you wrote "because some article authors, like you, didn’t like to adapt their habits". You are utterly wrong to try to misrepresent what you think are my motives. You are also wrong when you say there is no such thing as common sense because common sense is a large part of building consensus. Next we get onto you misrepresenting what I write. This is because I point out his "argument" (from 06:07, 2 February 2008 (UTC)) is a red herring and yet you insist on trying to rewrite my point to mean something else entirely. Just so you are perfectly clear, what you wrote is rubbish because I never wrote what you claimed I wrote. You are using a straw man, so your "point" is irrelevant and false. Fnagaton 02:01, 3 February 2008 (UTC)
I’m sorry it took me so long to respond, but I had much more important, non-WP things to do lately. Actually, I’m just taking a break from them.
So you think I misunderstood you or your motives. Maybe I did, big deal, happens all the time. You wouldn’t even have noticed if I hadn’t paraphrased what I understood and remembered (“misrepresent” you call it), just like I noticed your misreading. It doesn’t help, though, that you don’t explain where and how I misunderstood exactly. I assume it’s only about the changing habits part.
Nobody denies that kilo, mega and giga (at least) with bit or byte are often being used and understood in a binary sense instead of their classic, metric decimal one. Nobody denies that this occasionally results in ambiguity (in any imaginable way). Nobody is happy with the situation, although many take it as a given. Nobody intends a unit (or prefix) to have more than one meaning, although in practice (i.e. your de facto) occasionally one does. The IP user raises this point to a defining quality of a unit, you pragmatically don’t and call this (intentionally) irrelevant to the discussion (“red herring”). Am I right so far?
My main argument, which you ignored, still stands: We have different ideas of the purpose and foundations of this style manual. Therefore we cannot come to the same conclusion! So every argument is moot until we agree on the basic principles.
Whenever you claim the MoS was descriptive not prescriptive you are right and wrong at the same time, because a descriptive observation once published becomes a prescriptive rule in the understanding of many. This is how grammar and orthography “rules” came to be (for most natural languages).
Anyhow, a suggestion for compromise for the time being, although I would much prefer consensus in the long run:
SI prefixes are decimal and do not need disambiguation in general, but when applied to bits or bytes (incl. words and octets) without composition with any other units (as in rates, e.g. kbit/s) their meaning has to be disambiguated (one possibility is the replacement by IEEEIEC prefixes, which are always binary), except for RAM chips when used with a preferred number based on a power of 2 where they take a binary default meaning and only need disambiguation when having a decimal meaning.Christoph Päper 19:36, 21 February 2008 (UTC)
I can see you are continuing to misrepresent me because I did not ignore your argument, your "argument" is fallacious for the reasons I have already given above and previously on this topic. Your compromise is not good because it does not represent real world consensus. Your "compromise" chooses IEEE which you prefer, which is not a compromise at all, it is pushing your own point of view. For example it is disingenuous to say "SI prefixes are decimal" and not mention the fact that the JEDEC defines K = 2, M = 2 and G = 2 when being used for semiconductor storage capacity and also because recent legal rulings have stated that despite what SI/IEEE/IEC claim the de facto standard is different. RAM chips commonly use the units KB, MB, GB in the binary sense, for example and this is defined in the JEDEC standard. If you really want to get into the whole "orthography" argument then you're going to be refuting your own point of view because orthography is to use correct spelling according to what is considered to be accepted (i.e. generally approved) and established use. In this case orthography easily refutes using the -bi prefixes because it is obvious they are not accepted and established use. Fnagaton 08:42, 22 February 2008 (UTC)
Gosh, either my English is worse than I thought or productive discussion with you (on this subject) is close to impossible.
I don’t care whether we use IEC prefixes for disambiguation. I just want to limit ambiguity inside and among WP articles. (Ambiguity outside WP is outside the scope of this style manual.) To achieve this we can either
  1. adopt something with mutual exclusive meanings (e.g. SI and IEC prefixes, despite ambiguous usage outside WP),
  2. disambiguate (SI prefixes) inline each and every time or
  3. specify in MoS where we assume which default meaning (for SI prefixes), that wouldn’t have to be disambiguated, and where it’s too dubious to choose a default.
The current guideline does nothing to achieve the goal, uses only partially the second option. My suggestion for compromise does the third, although I very much prefer the first. Maybe I set the requirements for a binary meaning of SI prefixes higher than you would like, but with preferred numbers in the field of semiconductor storage capacity most cases would still be covered to your satisfaction. I see no good solution for file sizes, though, because files can be stored on different media (binary or decimal) and can be transmitted (decimal). — Christoph Päper 17:10, 22 February 2008 (UTC)
I note your continued misrepresentation and use of weak personal attacks, this shows that you are not interested in valid debate. You are also wrong because the current guideline fixes what you think is ambiguous by encouraging the exact number of bytes to be specified in the disambiguation or in footnotes. For example "256 KB (256×2bytes)". The first option "adopt something with mutual exclusive meanings" ignores real world consensus and makes articles inconsistent with their sources and actually doesn't solve the problem of using -bi units that can also be ambiguous. The second option "disambiguate (SI prefixes) inline each and every time" is not logical since the purpose of disambiguation is not to include brackets (or similar inline text) after every number in an article, it is usually the case that only the first occurrence of any such number needs disambiguation. The third option "specify in MoS where we assume..." is only going to get my support if it follows the real world consensus, i.e. not use -bi. Otherwise it is just going to be pushing point of view against consensus. The best option, which you don't list, is to use the terms found in the majority of reliable sources relevant to an article. This means internal consistency for articles over and above consistency for the whole of Misplaced Pages. Fnagaton 17:33, 22 February 2008 (UTC)
The IP user raises only one valid point, that even more confusion will arise when larger memory becomes available. In respect of (computer) memories, in the real world units do change depending on context - read the discussions above: a million can mean 1024 x 1000 and 1024 x 1024 depending whether is a megabyte of storage on a hard drive, memory stick, etc - go and look at amazon.com. The IP user appears to be confused, it is not misuse of units in wikipedia that causes problems it is inconsistent use of units in the computer industry that causes the problems. Misplaced Pages MOS is attempting to add clarity to the confusion that already exits.Pyrotec (talk) 19:52, 2 February 2008 (UTC)
I've changed my view upon reflection. The computer industry uses megabytes, Gigabytes, etc, the difference in UK and US definitions of a billion is irrelevant as it is unlikely that billion will be used as a description of the number of bytes.Pyrotec (talk) 20:20, 2 February 2008 (UTC)
Indeed, that's what I meant when I said earlier the point put forward "is actually shown to be a red herring". It's like saying "the sky is blue and that proves that I'm right about cell meiosis". Fnagaton 20:35, 2 February 2008 (UTC)
Maybe you don't know that "billion" is not only an English word. Billion is still frequently mistranslated as "billion" when it actually means 10^9 in one (European) language and 10^12 in the other like French or German. The UK might have adopted the US meaning by now, that's not true for any other country. You see it's almost the same issue as Megabyte vs. Megabyte. One is 10^6 and the other is 2^20. Keep in mind that this neither the American nor the British Misplaced Pages, it is an international effort. As there is no official authority for the English language, really nobody can decide which meaning of billion is correct but it is trivial to avoid these few well-known sources of confusion. --217.87.122.179 (talk) 00:00, 3 February 2008 (UTC)
No, you didn't mean that. If you read carefully, the term billion was only a part of argument. Calling it a "red herring" makes clear that you assume bad faith, especially your "sky is blue..." blah blah shows that you are interested in facts or any kind of useful discussion. There actually over 120000 Google hits for '"billion bytes" -wikipedia'. I don't know which formula Pyrotec used to determine his assumed probability but I'd think we can all agree that this isn't the right place for speculation about the future. For the record, a billion bytes is in US-American English equivalent to a gigabyte, that's why it's already in use. I was talking about Terabyte (tera means 10^12) which is less common for now and which has no well-known -illion equivalent. So it'd be called 1000 billion or a million million but nobody knows what's the marketing industry is going to establish. Nonetheless "billion bytes" is actually used despite the assumed low probability. —Preceding unsigned comment added by 217.87.122.179 (talk) 20:56, 2 February 2008 (UTC)
Yes I did mean that so do not presume to tell me what you think I really meant because when you do so you are misrepresenting me and what I wrote. Also your incorrect accusation of "bad faith" shows you have not presented a valid argument because the term "red herring" is actually referring to the logical fallacy, which your "argument" is actually using. This is also pointed out by Pyrotec as being irrelevant. Fnagaton 21:08, 2 February 2008 (UTC)
Okay, then I'm relieved that I could help in making clear what you actually meant because it wasn't obvious at least to me. I don't quite agree with your presumed definition of red herring but discussing this would be another one and off-topic anyway. --217.87.122.179 (talk) 21:58, 2 February 2008 (UTC)
Red herring fallacy also known as irrelevant thesis or conclusion. You'll see what I wrote is correct. Fnagaton 22:43, 2 February 2008 (UTC)
Not taking either side, but the Google test is worthless. As is citing voluntary standards (as are the IEEE's, IEC's, and JEDEC's) as examples of "policy". Voluntary standards are just that, and it's hardly surprising you can find standards which reflect common usage. Consider:
mile -wikipedia - 24,300,000
kilometer -wikipedia - 1,520,000
inch -wikipedia - 26,000,000
centimeter -wikipedia - 6,800,000
pound -sterling -wikipedia - 11,200,000
kilogram -wikipedia - 8,240,000
acre -wikipedia - 3,420,000
square kilometer -wikipedia - 1,660,000
Can these results be used to argue that preference should always be given to imperial units of measure, since apparently more English-speaking people will be familiar with them? Can they be used to decide on a case-by-case basis which units are preferable? Can you say that common use is universally more important than standardization in every case or vice versa? No matter how you concoct the Google Test argument, it is always flawed.
Experience with Misplaced Pages should tell you that no amount of dialog on this will ever settle the issue wholly in favor of or against IEC prefixes. There's zero editorial direction on this site, and unfortunately the MOS as a whole is more or less a farce (used merely when it is convenient in an argument), so fights like this will keep breaking out. I strongly suggest you look for a middle ground where the use of IEC prefixes is accepted in some contexts and the common prefixes are accepted in others. Pages like the one on floppy disks really do need some concise method to deal with the prefix ambiguity, and the IEC prefixes are one such way.
Basically, the way the MOS currently reads is the only way it can read. In reality there's no such thing as standardization on Misplaced Pages, so that argument won't work. The current reading explains the history of the debate, lays out the facts (common use versus ambiguity) and doesn't take any strong position. The only change that might be useful is provision for changing prefixes to IEC variants where appropriate and discussed beforehand. This excludes contentious en masse changes, but still acknowledges that there are some circumstances in which utilization of IEC binary prefixes might be useful. (maybe also remove the mention of the JEDEC, which is utterly comical since their standards have nothing at all to do with standard prefixes for unit measures)
You will never convince each other. You will not be able to defeat the common usage argument. You will not be able to defeat the ambiguity argument. You will never end this debate by brow beating the same tired and cyclical arguments into one another. I humbly suggest just leaving the dead horse alone and letting the editorial ebb and flow take its course. Otherwise you're just wasting your own time in neverending trite rhetoric. -- 74.160.99.252 (talk) 20:27, 11 February 2008 (UTC)
Unfortunately the IP user from Germany (not you 74.160.99.252) but the other user from 217.87.122.179 above (and their other IPs in that ISP range) decided that instead of trying dialog they would vandalise ANI, several talk pages including mine and an admin. Eventually leading to several semi-protects and range blocks. The ambiguity argument has been refuted since it relies on the false premise "nobody uses -bi in other ways except binary" because it has been shown that -bi has been used in the decimal sense. Fnagaton 20:39, 11 February 2008 (UTC)
I'm pretty sure 74.160.99.252 is the same person you're talking about. --85.25.12.31 (talk) 21:28, 11 February 2008 (UTC)

Years linked in a list

Years should not be linked in lists. I was working on a list of films and removed all of the year links since it is possible that the list could possibly be linked to every year since motion pictures was invented (or shortly thereafter). I think that year links in lists is a really bad idea. If this has been covered before, I couldn't find it. - LA @ 02:44, 9 February 2008 (UTC)

List of disaster films? I agree linking every "Year in film" article looks peculiar, but in short lists or tables it's common to link years to "Year in film" articles (See Austin Nichols#TV and filmography, for instance). It seems to me a question of scale. Gimmetrow 04:21, 9 February 2008 (UTC)
For authors bibliographies or actors' filmographies I agree, linking to the years is good. However, if the list of items by a subject which could be extremely long, it is a bit much. That is my opinion anyway. - LA @ 05:39, 9 February 2008 (UTC)

Please don't link years unless piped; even then, hardly any reader will bother to click it, since it looks like one of those useless plain-year-links we've spent a long time trying to weed out of WP. Consider spelling out the first one (1901 in film) to suggest that the subsequent blue years are piped. Tony (talk) —Preceding comment was added at 08:15, 9 February 2008 (UTC)

Actually Tony, I got rid of the (XXXX in film) year links.
Let me give you an example...Let's say that someone starts a List of red widgets. Each red widget on the list has a year in which it was released. There are hundreds of widgets out there, so someone makes the XXXX in widgets lists. Each widget's article has a link to that year in widgets. So, the first batch of widgets was released in 1901. There are a hundred or so, a dozen or more are red. Each widget gets an articles because widgets are notable on principle. So, now there are dozens of red widgets released every year. The new widgets are added to the list and are linked to the years in their articles. The list of red widgets doesn't need to be linked to those year in widgets lists because of the fact that the articles are already linked.
I hope that made sense. - LA @ 08:58, 9 February 2008 (UTC)

So is this accepted or not? I don't want to do a lot of year link removals if this is not accepted. What I am looking for is a general guideline, such as "Editors should not link years on list pages." - LA @ 07:07, 16 February 2008 (UTC)

Do the year links help readers to understand the topic (as required by the guideline)? If not, get rid of them. They're ungainly and harder to read than normal text. Tony (talk) 10:12, 16 February 2008 (UTC)
I'm a bit conflicted about this one. If the " in film" articles aren't linked as years within film articles, then will this put these articles at risk of being orphaned? If so, then how are we to create a useful linkage situation for these articles? Girolamo Savonarola (talk) 08:11, 24 February 2008 (UTC)

Don't wikilink units in infoboxes & tables?

This change was just made (change in bold):

  • In tables and infoboxes, use unit symbols and abbreviations; do not spell them out. They should not be internally linked with wikipedia pages.

Why not? Was this change discussed anywhere? —Preceding unsigned comment added by Gerry Ashton (talkcontribs) 18:42, 13 February 2008 (UTC)

added line - is there a better way to phrase it. CorleoneSerpicoMontana (talk) 21:25, 13 February 2008 (UTC)

I don't understand the need for this change. Please explain. Thunderbird2 (talk) 21:31, 13 February 2008 (UTC)
I'm opposed to this change. In infoboxes and tables, space is at a premium, so there no room to explain units. Hence, the need for wikilinks is greater than in the text of articles, not less. --Gerry Ashton (talk) 22:00, 13 February 2008 (UTC)
I agree with Gerry Ashton. Thunderbird2 (talk) 22:09, 13 February 2008 (UTC)
I'd rather see links to unit articles in the text but if the unit does not appear in the text & needs linking, why not link from an infobox or table? Generally, yes, in tables & info boxes should use abbreviations but not always, obvious examples are where the abbreviation is not well recognised, could easily be misread or doesn't even exist. Shall we not look into a rephrasing of the whole point? Jɪmp 02:53, 14 February 2008 (UTC)
re-worded. This comes from working with alot of sports infoboxes where the weights and heights are detailed in both imperial and metric systems. CorleoneSerpicoMontana (talk) 08:40, 14 February 2008 (UTC)
Can you point us to a specific example that causes a problem? Then we can try to help you solve it. Thunderbird2 (talk) 09:02, 14 February 2008 (UTC)
The articles from the UK, and Australia at least work in st, lb, & kg, along with ft, in & m. I don't believe the need to be linked as it only makes the infobox garish. The units themselves are described in metric and imperial units and it seems that were someone not used to using either system, which frankly seems unlikely they can go through the search feature. This is a small problem as it is only a very small percentage that currently link units. CorleoneSerpicoMontana (talk) 09:08, 14 February 2008 (UTC)
See: Misplaced Pages:Only make links that are relevant to the context "What generally should not be linked" "Plain English words, including common units of measurement." Lightmouse (talk) 10:30, 14 February 2008 (UTC)
My view is that non-SI units should be linked somewhere in the article, and preferably on first use. If they are linked outside the infobox, there is no need to do so again inside it. Thunderbird2 (talk) 17:55, 14 February 2008 (UTC)
Depends on the unit. Rods and perches should be linked, simply as rare words, independently of this guideline; linking ton is one way to deal with ambiguity (although explanation, perhaps in a footnote, would be better). But linking foot is as unnecessary as linking leg. Septentrionalis PMAnderson 03:17, 15 February 2008 (UTC)
In that line, the "stone" as a unit of measure mentioned by CorleoneSerpicoMontana is a rare word to most native speakers of English, let alone to almost all of the many readers we have who are not native speakers of English.
But to say that in infoboxes and tables, units should not be linked is nonsense. There are many SI units which should be linked as well (how many of you understand joules and katals and kelvins and luxes and becquerels well?), as well as hundreds of Fred Flintstone non-SI metric units, English units, and units of a number of other old systems of measurement from all over the world. "Infoboxes and tables" include more than those just listing an athlete's height an weight. They use all sorts of strange and uncommon units.
Like Pmanderson/Septentrionalis says, there is usually not any real need to link feet. There is also not any good reason to link inches or meters or kilograms. But pounds often need to be linked for disambiguation purposes, especially in the thousands of articles we have using both the pound and the pound, as well as to disambiguate both of them from the various currencies of the same name). But even for pounds, when it is a listing of a persons height and weight, there is no crying need for any link. We aren't going to be thinking these are pounds sterling nor wondering what they are in terms of euros, and while some miseducated science-trained people might be confused enough to think they are pounds-force, that's their problem not ours. One little link isn't going to remedy their miseducation, if they've already ignored the evidence of the conversion to kilograms rather than newtons and everythig else.
I agree with Gerry Ashton's point that linking of units is slightly more necessary in infoboxes and tables than in running text. Furthermore, linking in text should not necessarily preclude linking on first appearance in boxes and tables, nor vice versa. For one thing, it isn't always clear which comes "first" in everybody's reading habits, and boxes and tables are likely to be considered in isolation without even reading the text by some, while others will be reading the text and paying little attention to everything else. Gene Nygaard (talk) 14:23, 29 February 2008 (UTC)

Links to "As of xxxx": how large a benefit?

Links to "as of xxxx" lead to solitary years. According to Misplaced Pages:As of, it is supposed to be used if you "want to ensure that people will update it". I do not believe that it actually works like that. For it to work, a reader would have to start at the redirect page and see an article, go to the article and then identify that they know something more than is already there. There are far too many unlikely human actions for me to believe that it has a significant effect on Misplaced Pages. There are doubts expressed on the Misplaced Pages:As of talk page too. Is this simply another variation on date linking where there are believers and non-believers? How large is the benefit that is claimed and is it worth the added blue noise that makes good links harder to see? Lightmouse (talk) 15:09, 15 February 2008 (UTC)

I read that about three times and I hope you'll forgive me for first asking for clarification.
I think it's to ensure people update the sentence with the link in it, for example, in "As of 2008, John Key is the Leader of the Opposition in New Zealand", that people will update it to "As of 2009, Joe Bloggs is the Leader of the Opposition in New Zealand" or "As of 2009, John Key is the Prime Minister of New Zealand" if it changes from year to year (that sentence was not an election prediction, btw).
I suppose the linking helps people who specifically want to track down those sentences do so, so they can update them? Neonumbers (talk) 10:00, 17 February 2008 (UTC)
  • I'm unconvinced that the reasons are so well thought out, and am suspicious that linking such items is little more than a carry-over of the obsession with linking plain years. At least there's a rationale for the "as of" linking; but it's a flimsy one: editors at a centralised list of as-ofs are not in the best position to know when and in what way such time-tagged information should be updated. It is the guardians of the articles in which it occurs who are best placed, and we must continue to rely on them—and knowledgeable casual users—to update as-of information, just as we rely on them to update articles in so many other ways. The disadvantage of bright-blue splotches is not easily outweighed by the chance that an as-of editor will monitor, alert, tend to, or themselves update the item at the right time in the right way. Best not to link, I say. Tony (talk) 10:39, 17 February 2008 (UTC)
Neonumbers, let me try and clarify what I think is going on. Yes, it is often stated that it helps people who want to update the information but have you considered how you would actually do this? I can only see two ways in which a link to an 'As of' article would work:
  • 1. Links to 'As of xxxx' redirect to 'xxxx'. This seems to me to be consistent with the idea that they have no real function. However, you could argue that an editor determined to update an 'As of xxxx' fact can go to the redirect and look at 'what links here'. Then you need to pick an article that you think you know something about. You can then read the article and see if the 'as of xxxx' link in the article can be updated with something you know better. This seems an inconvenient and unlikely set of events that I cannot imagine it is a routine process for Misplaced Pages, if it happens at all I would be surprised. Yet there are thousands of 'As of xxxx' links. I can't imagine wanting to do such a thing but if I did, I would not waste my time with the unfocussed Misplaced Pages redirect. I would want a focussed search on a specialist topic. I could go to google and search Misplaced Pages for 'as-of-2008 New-Zealand politics'.
  • 2. Links to 'As of xxxx' are a highlight within the article. Any reader passing by will see the highlight. Thus we could use bold highlighting As of xxxx and achieve the same effect. Again, I do not believe that such highlights are proportionate. Any editor is capable of reading 'As of xxxx' without a highlight and knowing that it is capable of being edited just as any other piece of text.
My belief (like Tony's) is that these are a carry-over from the obsession with linking plain years and should be treated as such. Lightmouse (talk) 11:15, 17 February 2008 (UTC)
WP:As of has a point. Anyone reviewing an article with 1991 census statistics should now update them to 2001. (This may not be what the article needs most; but it is one of the things it needs.) The link is, and may work as, a reminder to do this. Septentrionalis PMAnderson 17:08, 17 February 2008 (UTC)
Ah right I get you now Lightmouse. I don't have much to say on it—I'd want to hear from someone heavily involved in those links, I simply don't have an opinion on their usefulness because I'm not involved with updating dated statments—but I just wanted to say thanks for the clarification, I appreciate that. Neonumbers (talk) 06:08, 21 February 2008 (UTC)
  • The as of solo year linking silliness should be done away with. If we want to encourage people to update (example) this information after January 2008, the {{update after}} template can be added with {{update after|2008|01|01}}. The inline flag remains invisible in the text until the date specified in the template is triggered. That's what we should be encouraging. See 7 World Trade Center#Building opened. There is nothing helpful added by the use of the as of links, while the update after template is quite useful. It's invisible until the date triggers it to show. As of is covered by WP:MOSNUM#Precise language, and the year link adds nothing. SandyGeorgia (Talk) 14:54, 24 February 2008 (UTC)

Uncertain but sandwichable dates (x/×)

Another user from the GA review of Albin of Brechin suggested that I take the issue of x/× dating here in order to established notes on the MoS guide regarding these. I use em all the time, as they are necessary for historical clarity and accuracy in many of the article upon which I work, but I too cannot find anything. Any thoughts people? Regards, Deacon of Pndapetzim (Talk) 21:35, 15 February 2008 (UTC)

I.e., "began to reign in 86x" or "8xx". Do we want to advise on these? They are (semi-)standard usage; but they are writing for specialists, not for the general reader. Except in the rare case where a last digit is known and a middle digit is uncertain, they are usually replaceable by "in the 860's". Septentrionalis PMAnderson 17:42, 16 February 2008 (UTC)
I don't think that's what Deacon of Pndapetzim meant, I think (s)he meant the use of "died 1286 × 1292" to mean, "died between 1286 and 1292".
I've never seen that before, but if it's standard practice that would generally be useful, I don't mind seeing it in the manual—but I would need to be convinced it would be readily understandable by most educated readers. Neonumbers (talk) 10:18, 17 February 2008 (UTC)
I've never seen it before either; I think "between" or, for the actual case, "1244 or 1245", would be better. If a symbol were used, I would expect a hyphen or dash, but I suppose that would overexcite the WP:MOSDASH enforcement unit. A virgule "1244/5" is usual when the event is dated to a period of twelve months that doesn't begin in January, but that is ambiguous (with the equally conventional use of the virgule to mark the period between January and March 25). Septentrionalis PMAnderson 17:04, 17 February 2008 (UTC)
It's an essential part of some types of historical writing ... and you can communicate a lot of information very quickly with it. It doesn't really mean "between", as it includes the dates/years which enclose it. It's a wee bittie similar to the way ≤ is used in Maths. I'll give you an example of a text, Watt's Fasti Ecclesiae, p. 152, Deans of Glasgow, s.v. Salomon:
"Not yet dean Mar. x May 1159 (RRS, i. 194); occ 6 Jan. 1161 x 20 Sept. 1164 (......); occ. 1 Nov. 1164; occ. 7 Mar. 1175 (......)".
s.v. Herbert:
"Not yet dean 1179 x 1196 (......); occ. 1188 x 1189 (......); occ. 1179 x 1221 (......); occ. 1204 x 1207 (......)"
That's a pretty specialist book, but you encounter is often enough in normal scholarly works. In say an article on Albin of Brechin, where it was brought up for the first time, it may get a little tedious to keep saying between and etc every sentence, when you can say "he occurs DATE x DATE, DATE x DATE and DATE x DATE". At any rate, this is used extensively in the lingua anglica and so the MoS should definitely cover it in some way, even if it's to forbid its use. Regards, —Preceding unsigned comment added by Deacon of Pndapetzim (talkcontribs) 11:41, 28 February 2008 (UTC)

Quick NBSP question

Under the NBSP section, the MoS states "In compound items in which numerical and non-numerical elements are separated by a space, a non-breaking space (or hard space) is recommended to avoid the displacement of those elements at the end of a line." and as an example, gives "19&nbsp;kg" as an example. My question is, if I wrote out "19" as "nineteen", would I still put a non-breaking space in-between the number and the unit of measure? In other words, which would be correct: "nineteen&nbsp;kg" or "ninteen kg"? Thank you. Dlong (talk) 16:38, 19 February 2008 (UTC)

That (nineteen kg) would breach WP:MOSNUM. Also, if you prefer {{nowrap}} to nbsps, you can use that. SandyGeorgia (Talk) 16:42, 19 February 2008 (UTC)
Better use "nineteen kilogram", with a normal space. Full numbers go with full names. &mminus;Woodstone (talk) 17:52, 19 February 2008 (UTC)
In other words, irrespective of the non-breaking space (which I do not have a view on) use either "19 kg" or "nineteen kilograms". (surely not "nineteen kilogram" ?) Thunderbird2 (talk) 17:55, 19 February 2008 (UTC)
A normal space in "nineteen kilograms" (plural) will be just fine—a line break between those words won't look awkward or be hard to read. Neonumbers (talk) 03:43, 21 February 2008 (UTC)


I don't think the current wording makes that clear at all.

Followup. Suppose you have "is Cp = 38.171 J mol K at"

Tell me:

  1. Where you think the current MoS rule "recommends" non-breaking spaces. How many? All seven spaces? only some of them? Five? One? Three?
  2. Where this should logically be allowed to break.
  3. Whether they are different.

I'd say our screwball rules, read literally, clearly call for one nbsp in this case (before the J)—and that one is precisely at the place where it is most logical to allow a line break.

You may well think that the rules call for more than that. Explain where, and explain why that is so in terms of the current rule.

Now, don't peek at the coding until you've answered the parts above, and I'll put in the nbsp which to me seem absolutely essential: "is Cp = 38.171 J mol K at ..." Well, maybe not absolutely essential: there is an alternative for two of them; you can use a centered dot instead, but it should not be the dot on the line used in the actual article from which I borrowed this expression.

Obviously, there are a lot of people writing these rules who are incapable of grasping anything more complicated than "19 kg" when it comes to measurements, who might be blissfully unaware that people do use much more complicated numbers and much more complicated units than that. Our rules used to call for a nonbreaking space only in that situation, between a number in numerals and a symbol for a unit of measurement (metrologists like to distinguish these "symbols" from ordinary "abbreviations", which unlike the symbols are usually language-dependent and might change in the plural be followed by a dot or be italicized and things like that).

  • Why was it changed, without discussion, to even apply to spelled-out names of units of measurement in any case, whether they are preceded by a number in words or by a number in numerals?
  • And why hasn't it ever been changed to recommend non-breaking spaces in the places where it really matters, such as within a number itself (e.g., 14&nbsp;3/16 in) and within the symbols for a unit (which are not "numerical and non-numerical elements ... separated by a space"), such as the "J&nbsp;mol&nbsp;K" in my example. Gene Nygaard (talk) 10:43, 28 February 2008 (UTC)

Ordinal centuries in WP:MOSNUM

Where is the discussion regarding this? As I noted in the edit summary, the edit that made this change was based on the mistaken assumption that the spelling out of century numbers was disfavored prior to the re-organization of the page, but this is incorrect: prior to the re-organization the MOS allowed for either "17th" or "seventeenth", which was the long-standing consensus for several years over numerous discussions. —Centrxtalk • 08:09, 24 February 2008 (UTC)

I can't remember where the discussion was, or even whether it was at WT:MOS or WT:MOSNUM. That's a consequence of the present chaotic way in which MOS discussions are conducted. (Join the push for coordination! See Wikipedia_talk:MOS#WikiProject_Manual_of_Style.) But note this wording, from the current provisions of WP:MOSNUM:

Ordinal numbers are spelled out using the same rules as for cardinal numbers. The exception is ordinals for centuries, which may be expressed in digits (the 5th century CE; 19th-century painting).

That is vague! And it is replicated at WP:MOS. What is the force of that may, exactly?
I suggest you raise the matter for discussion at WT:MOSNUM, once more. Never mind that there may have been a spurious consensus one way of the other in the past. Just about every such consensus turns out to be equivocal. With respect, if you want to change a current provision, do it with current discussion.
– NoeticaTalk 08:37, 24 February 2008 (UTC)
The meaning of the word "may" is the same here as its English definition, and the same as used in every other recommendation, regulation, RFC, legal document, etc. See, for example RFC 2119. "May" does not mean "must" or "must not". There is nothing vague about it.
The MOS has never disclaimed the use of spelled-out numbers for centuries, in all its seven years. There was no discussion to have it do so, as you can see in the archives around that time period; the change to have it do so was made as a result of a misunderstanding, in this edit. —Centrxtalk • 09:07, 24 February 2008 (UTC)

Above copied from

I've started a discussion of ordinals in centuries and millenniums here.
--ROGER DAVIES  09:28, 24 February 2008 (UTC)

Context should influence style

In scientific contexts, the trend to express numbers in numerals goes much farther than in literary ones. I find "three," "two," and sometimes, even "one" (!) expressed consistently, within text passages, in numerals, in both popular and scholarly scientific publications. The rule in ordinary English composition that was taught almost universally in America, and appeared in Wariner's, prescribed (if I recall correctly) spelling out words for numbers which consisted of single words, like "seventeen" and "sixty-five." "Newspaper style" was considered exceptional. As far as I know, there's no reason to discard that rule, except in articles on technical and scientific topics, where spelled-out numbers would seem strange and archaic. I advocate amending this manual of style to reflect the rules of common usage and their dependence on subject matter. "There were 6 icebergs" would be correct in Science, but wrong in The Hudson Review. Unfree (talk) 20:02, 24 February 2008 (UTC)

This used to be in the style guide but was lost at some point. Do note that this is not universal for any scientific usage. If the number is a measured unit directly relevant to an experiment or a physical description, then the numeral is common, but not if the number is used as a common number. For example, "10-foot pole" only if the pole was measured to be 10 feet, but "ten-foot pole" if it is a common pole of this variety; or "In a mapping of region X, there were 6 icebergs" but "We encountered six icebergs on our expedition". —Centrxtalk • 23:09, 24 February 2008 (UTC)

Years and dates

BCE/CE is not a good notation. Most people don't recognize it as they do with the BC/AD notation. The reson for using BCE/CE should be that is less religiously controversial, but it only common for christians and jews. I suggest trying to find a new meaning for the abbreviations without mentioning especially Domino (Latin for Lord) which I've understood is the most controversial word.

To be a bit constructive I should probably come with some suggestions:

BC/AC : Before Counting/After Counting or Before Ciphr/After Ciphr (Ciphr=latin for zero) Magnus Andersson (talk) 17:18, 26 February 2008 (UTC)

Allow me to ascertain that I have understood your proposition correctly, my dear fellow: are you suggesting that we should create a new chronology system?
This is inadvisable for many reasons. The most basic one is that we are an encyclopaedia; we only use existing means of noting the passing of time. It is not our job to create any new such means, or different ways to interpret them, and even if we did, nobody would understand them anyway, so it would be pretty useless. Besides, the Common Era notation enjoys wide usage and recognition in the scientific community, as any serious scientist would tell you; in addition, good articles using this notation should link to the Common Era article in its first instance, so people unfamiliar with it can learn what it is (and know about it thereafter).
The International Organization for Standardization is probably the institution you ought to contact for such suggestions. Who knows, they might even be interested. ;-) Misplaced Pages, however, is an encyclopaedia: we record, we do not create. Waltham, The Duke of 18:00, 26 February 2008 (UTC)

DWT

The shipping term deadweight ton refers to a long ton (2240 lb) of deadweight. It is abbreviated as "DWT". A similar term, deadweight tonne, refers to the same but this time in tonnes (1000 kg). The problem is that it seems that the same abbreviation, "DWT", is used. Russ Rowlett's Dictionary of Units of Measurement has this to say.

deadweight ton (dwt)
a traditional unit of weight or mass used in the shipping industry. The deadweight tonnage of a ship is the difference between its weight when completely empty and its weight when fully loaded. This includes the weight of everything portable carried by the ship: the cargo, fuel, supplies, crew, and passengers. The deadweight ton is traditionally equal to the British ("long") ton of 2240 pounds (1016.047 kilograms). However, more and more often it is being taken to equal the metric ton (exactly 1000 kilograms, or 2204.623 pounds).

How do we go about dealing with the ambiguity? It has been suggested, by Haus, that we choose a standard for Misplaced Pages. Other means of disambiguation have also been suggested. So far four approaches have been considered. Symmetry would have us consider a fifth (I do like symmetry). Let me list them.

  1. Let "DWT" always stand for long tons of deadweight and spell deadweight tonne(s) out whenever necessary.
  2. Let "DWT" always stand for tonnes of deadweight and spell deadweight ton(s) out whenever necessary.
  3. Avoid the abbreviation, "DWT", altogether and always spell both terms out.
  4. Use "DWT (metric)" and "DWT (long)" for tonnes and long tons respectively of deadweight.
  5. Use "DWTmetric" and "DWTlong" for tonnes and long tons respectively of deadweight.

Here are some of the advantages and disadvantages that I see with these.

  1. This follows tradition. As far as I can tell, this is the most common meaning of "DWT". However, I've got only my own Googling to to support this and we're aware of the American dominance of the web. Also, as the decades, centuries ... millenia ... wear on ... Misplaced Pages is forever, right. The long ton meaning of "DWT" might fall out of favour.
  2. Against tradition & common use but may be forward-looking, this has the added advantage of naturally conforming to standard Misplaced Pages practice in which conversions to metric are generally given whereas conversions to avoirdupois are generally not and in which (in text as opposed to infoboxes) the units converted from are generally spelt out and the units converted to are generally abbreviated: in other words 2. allows "125 deadweight tons (127 DWT)" whereas with 1. we can only have either "125 DWT (127 deadweight tonnes)" or "125 deadweight tons (127 deadweight tonnes)". Of course, both 1. and 2. require that readers and editors be familiar with the Misplaced Pages standard — this may be a big ask.
  3. This avoids any possibility of ambiguity and is unbiased towards this or that system of measurement but means that we have to have a lot more text.
  4. This again avoids the ambiguity and bias. It allows both terms to be abbreviated. It makes it clear to those none too familiar with shipping that it is a long ton rather than a short ton (or even a metric ton) which is being refered to. However, it is kind of ugly especially if you're a conversion, e.g. "125 deadweight tons (127 DWT (metric))", even more so if you want to abbreviate both units, e.g. "125 DWT (long) (127 DWT (metric))".
  5. This has the advantages of 4. whilst avoiding the ugliness, however, it could be argued that a subscript is part of the symbol therefore "DWTmetric" & "DWTlong" could be seen as being symbols of our own invention.

So, what say you? What do we do here? My preference is going to 5. (I had been keen on 4. until I started typing examples out & saw how it looks). Jɪmp 07:29, 4 March 2008 (UTC)

Just to point out that we're not the only ones having difficulties with this, the GPO uses inconsistent deinitions where "ton=long ton," "t=metric ton (or tonne)," but "dwt"="deadweight ton." My inclination is also orbiting #4 and #5 above. On the surface, it seems that a clever use of wikilinks could be used to stave off confusion, but it seems to work poorly on long pages with many uses of the forms "DWTmetric" & "DWTlong" Cheers. Haus 15:05, 4 March 2008 (UTC)
Overall I too would prefer #4 or #5 (the latter being better due to being prettier). It should be remembered however that the problem of ambiguity also extends to sources - for instance this very useful website lists a DWT figure for mosts ships but I've no idea whether they're in tons or tonnes (presumably the metric ones, but is that an assumption I can make?). -- Kjet (talk · contribs) 15:32, 4 March 2008 (UTC)
Of course, your linking could go like this "DWTmetric" & "DWTlong" but, yes, disambiguation via links is problematic not only for the reason mentioned above but also because it requires the reader to click on the link (unless they're familiar with the tool-tip-hover-over trick), which can be a great distraction and which will be impossible if you're sitting on the train with a copy of the article you'd printed during lunch. Jɪmp 16:23, 4 March 2008 (UTC)
My two cents.
Avoid "DWT" entirely. Spell out deadweight when appropriate.
  • For what it's worth, you also see "dwt tons"; the "t" at the end of dwt doesn't even have to come from "tons" or "tonnage" in any flavor; rather, some look it as the "wt" being a common abbreviation of "weight" with a d stuck in front to identify "deadweight".
Any discussion of using "tonne" is inappropriate without also considering American English, where it is a metric ton not a "tonne", and French, where tonne is as ambiguous as ton is in English.
What is needed with all the ton of different "tons" used in shipping is more clarity in what is being measured. More clarity on the meaning of "light weight" and various other things used as well as dead weight. More clarity on basics such as whether the measurement is a measurement of volume or one of mass. For example, what do we do with submarines? Their surface displacement is a normal measurement of mass, but their dived displacement is essentially a measure of volume: Archimedes' principle, a floating object displaces its mass and a submerged object displaces its volume.
It is truly unfortunate that the BIPM and other standards agencies consider any tons acceptable for use with SI, and doubly unfortunate that they choose to specify a symbol for it (t) that is also used for long tons or for short tons.
To be more specific on my first point. I especially mean not to use "DWT" (nor the more appropriate lowercase "dwt") as a symbol for a unit of measure. It is less objectionable to use it as part of the identification of the quantity being measured, but you should not have a number followed by "dwt" used as a unit symbol, whether standing alone or the subscripted suggestions above. It's part of the general rules about not attaching information to the units of measure, and especially not to the metric units. Using something like psia or psig is frowned upon for the same reasons.
  • Unacceptable: The ship is 9,400 dwtlong (9,400 dwtmetric)
  • Acceptable: The ship has a dwt of 9,400 long tons (9,550 t)
Gene Nygaard (talk) 18:55, 4 March 2008 (UTC)
So, we have a sixth option.
6.  Don't use "DWT", use "dwt". However, "dwt" is an abbreviation of "deadweight" not "deadweight tonne" or "deadweight ton". Neither use "deadweight tonne" nor "deadweight ton" but treat "deadweight" like "height", "length", "speed", etc.
Of course, "dwt" (lower case) is the symbol for the obsolete pennyweight (here's another example of "wt"'s standing for "weight" ... also "cwt") but if (when we're talking about deadweight tonnage) we're not using "dwt" as a symbol for a unit of measure, there can be no confusion.
One must admit that Gene's approach is the easiest to comprehend as it follows the norms of English — "The ship has a dwt of 9,400 long tons (9,550 t) and the captain has a height of 6 foot 2 inches (188 cm)." We'd also avoid the temptation to use the fancy unconventional linking I suggested above (linking "DWT" to Tonnage and the subscripts to articles on their respective unit).
Gene, I suppose this means that the likes of "bhp", "shp", etc. is also frowned on.
Jɪmp 01:14, 5 March 2008 (UTC)
I like the #5 option. I wouldn't use dwt because of the pennyweight measurement. —MJCdetroit 02:00, 5 March 2008 (UTC)

Prices are numbers too

We often don't bother to give numbers to four significant figures, and, wishing to avoid pedantry and the wasting of space, I therefore changed

for US$19.99, £12.99 in the UK or AU$24.99 in Australia

to

for US$20, £13 in the UK or AU$25 in Australia

in this edit. Realizing that this might be controversial, I immediately announced the change on the talk page of this popular article. To my surprise, it got just one (unfavorable) response. What do you people think? -- Hoary (talk) 10:04, 4 March 2008 (UTC)

For some purposes exact numbers are preferable, and for others they are unnecessary. Unnecessarily reducing the accuracy of data can make it less useful to some people. In the case of prices, the difference between £12.99 and £13 is negligible; but there is no advantage in changing £12.99 to £13. If you are writing an article and you want to say £13 instead of £12.99, fine; but don't edit other people's work to make this change as you just annoy people and potentially make the data less useful.--Toddy1 (talk) 19:19, 4 March 2008 (UTC)

The size of a thousand

Commas are used to break the sequence every three places left of the decimal point; spaces or dots are never used in this role (2,900,000, not 2 900 000).

says the manual under the heading Large numbers. We do intend this to start a 1,000, don't we? I'm suggesting we tighten the language to make it clear what exactly we mean by large. Are we considering numbers in the range of 10,000 > x ≥ 1,000 to be large here? Jɪmp 14:36, 4 March 2008 (UTC)

Concern

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

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