Wikipedia talk:Manual of Style/Dates and numbers

Archives at: /archive1 - /archive2 - /archive3 - /archive4 - /archive5 - /archive5a - /archive6 - /archive7 - /archive8 - /archive9 - /archive10 - /archive11 - /archive12 - /archive13 - /archive14 - archive14a - /archive15 - /archive16 - /archive17 - /archive18 - /archive19 - /archive20 - /archive21 - /archive22 - /archive23 - /archive24 - /archive25 - /archive26 - /archive27 - /archive28

Currency

Following on from an archived discussion on currency conventions, I'm hoping to nail down some specifics on dealing with currency: comments are welcome at Wikipedia:Naming conventions (currency). Ziggurat 02:17, 28 September 2005 (UTC)[reply]

Units of mass in precious stones

(Discussion moved from Talk:Diamond)

I think the article will be improved by having specialist weight units (carats) supplemented with non-specialist weight units (grams). I made edits to that effect but the article was reverted to remove gram values. See: http://en.wikipedia.org/w/index.php?title=Diamond&diff=24265758&oldid=24260125

This topic was discussed previously at:http://en.wikipedia.org/wiki/User_talk:Bobblewik/units_of_mass#Units_of_mass_in_precious_stones Perhaps we have drifted apart from what was said in that discussion. I would like to find a solution. Can we go through it again please? Bobblewik 23:07, 28 September 2005 (UTC)[reply]

Aside from the simple fact that diamonds are not sold by the gram, converting every carat value to grams does (IMO) impede the flow of the article. The very first mention of "carat" in this article is both wikified and its value converted into kilograms; this gives a clear indication that it is a unit of mass, and if further explanation is necessary, the reader can click through to the carat article. Furthermore, the Diamond#Carat section gives an in-depth explanation.

As for the "specialist" nature of the carat: it's now common for would-be gem purchasers to do a little research before buying, and the term carat has long since entered the lexicon of the general public. It's used in advertisements, TV shows, mainstream movies, and literature. Most jewellery stores (e.g., Peoples, Birks) have informative posters and signs next to display cases to educate the unfamiliar, of which there are increasingly few. As you yourself said in the May 2005 discussion linked to above: "When I first discovered that the carat was simply 200 mg, I was astonished that it was so simple a conversion." (Emphasis mine.) A simple conversion needn't be invoked each and every time. I don't know where in the world you are, but consider that a great many Americans (who make up a sizeable fraction of our readership) are unfamiliar with the gram itself, but that doesn't mean we should convert every g/kg value to ounces and pounds. I think the article is fine as it is. -- Hadal 03:48, 29 September 2005 (UTC)[reply]

I pretty much totally agree with Hadal; the conversion is informative the first time it is made, and useful in situations where bulk mining data are mentioned, but beyond that it is pedantic and interferes with the flow, without adding anything. This is not like giving the height of mountains, where the conversion is useful every time; it is more like giving the translation of a foreign name. Our article on Japan, for example, notes that natives actually call it Nippon, but doesn't then go use the construction "Japan (Nippon)..." every time the word Japan is used. - Bantman 18:50, 29 September 2005 (UTC)[reply]

Times

We've already standardised date format. It seems to me strange that any time format is allowed given that it is 24-hour, and, furthermore, that the manual actually specifically says not to edit an article just to change the time format (which, as you could probably tell, was exactly what I was about to do).

Like dates, there are lots of different time formats. And like dates, it would be better if they were all the same. I don't know about regional formats though.

Anyway, there are two things in time formats that annoy me when I see them, and I'd be very surprised if others here disagreed with me:

When people write 3.25. Times don't use dots, I thought — it was always meant to be a colon, like 3:25.
Inconsistency in using AM and am and a.m. and A.M.. I know the manual says to avoid 12-hour times (a principle which I oppose), but anyway, this inconsistency is blatant (unlike numbers as words). So this should be standardised. Personally, I prefer lowercase. Don't mind about dots, as long as it's consistant.

There is of course one other thing, that is the thing about 12-hour and 24-hour clock which I understand is very controversial and probably won't gain consensus, though if anyone is like me and wants it to be 12-hour in prose (not technical or tables), please drop a word.

Any thoughts? (If I don't post something for ages it means I've been caught up elsewhere, I'll try and check here as often as I can) Neonumbers 08:47, 3 October 2005 (UTC)[reply]

I have a brilliant idea. Let's create a robust template to handle times. Something that would take a time and zone parameter. For example, an instantiation could look like: {{time|2:17 PM|EST}}, which would output 2:17 PM EST (19:17 UTC). I don't know how hard it would be to do that, but the PHP code to convert the times and uniformly case the PM/AM would be incredibly simple. We could then use a bot to snarf up all the times and formatthem uniformly. Local time zones in which 24-hour clocks are preferred would display 24-hour time, and time zones in which 12-hour clocks are preferred would do that, but the UTC time would always print. If a time zone is unknown, the editor can pass LOCAL as the parameter, and the 24- or 12-hour format will be preserved. --Mm35173 19:06, 11 October 2005 (UTC)[reply]

Nice idea, but I'm sceptical about its feasibility — the date convention (I know it's being debated) has worked well for a while now; I very rarely see a date that hasn't been correctly formatted. So I don't think a template's the solution in this case because it's a number format and I highly doubt a template would become common use.

My concern is that the current guideline is a non-guideline and, like dates, times should follow a consistent format. This is one of those things you can flip a coin for — it doesn't matter that much so long as they're all the same (but I don't actually want to pick one completely at random).

If I were to suggest that the format (say) 3:45 p.m., 12 noon, 12 midnight, 12:34:56 a.m. for 12-hour and 23:45, 13:42:36 for 24-hour be standardised, wouldn't that be useful for a manual of style? Neonumbers 06:48, 14 October 2005 (UTC)[reply]

Tell me, Mm35173, if somebody is trying to show that when an event took place, the streets in that residential neighborhood were quiet because it was 4 o'clock in the morning, local time, exactly what good would it do me to know only what time that was in my time zone? Or what time that was in UTC? Or both? Maybe the idea isn't so brilliant after all. Gene Nygaard 16:13, 14 October 2005 (UTC)[reply]

To partially answer my own question, I suppose we could change your "unknown" to "either unknown or the local time is the relevant time", but who are we going to get to even read the instructions on how do it by the time we add all the possibilities, let alone follow those instructions. Gene Nygaard 16:20, 14 October 2005 (UTC)[reply]

Maybe if I keep at it long enough, I'll get to my real point. The notion that there are "Local time zones in which 24-hour clocks are preferred" is what really has me buffaloed, and it is whatever you might come up with for a replacement for that wording that is likely to be the greatest complicating factor by far. Gene Nygaard 16:24, 14 October 2005 (UTC)[reply]

There are exceptions to any rule. The Hebrew calendar calculates its dates based on times in a 24 hour clock that begins at 6 Template:PM, because the Jewish day begins at sunset and 6 Template:PM is the average time of sunset over a whole year. This must not be converted to 18:00, because 18:00 in the Hebrew calendar means noon. Actually, even noon should not be written as 18:00 because in the Hebrew calendar an hour is divided into 1080 parts (halakim), not into 60 minutes. Noon should be written 18h—a typical Hebrew calendar time might be written as 5h 204p. — Joe Kress 05:21, 19 October 2005 (UTC)[reply]

Okay... well, I'm just going to steer this discussion back to its intention (or at least my intention)... For times that use the (Western) 12-hour or 24-hour, 60 minutes to an hour, 60 seconds to a day, format, with am and pm for 12-hour but not twenty-four hour; and this includes localities such as France that (feel free to correct me) use the 12/24-hour clock but not am and pm, preferring instead to use morning, afternoon and night... well anyway, times that follow the 12/24-hour clock:

We pick a consistent format. This is things such as, use colons not dots (or dots not colons), use a.m. not am nor AM nor A.M. (or whatever version we choose), do/don't use a leading zero for the hour (or, use a leading zero for 24-hour but not 12-hour), things like that.

And, this consistent format in place, we allow the editing of articles (by "allow" I mean, it should generally be okay to, I do not imply that this manual is law) to change the time format to conform to this.

I mean, let's face it, other time systems are almost never used in an English encyclopedia and we can't possibly cover all of them here. The people involved in those areas can work something out — but the 12/24-hour clock format is a big issue that concerns just about everyone. So, just the 12/24-hour clock.

Any thoughts on this? Neonumbers 10:41, 19 October 2005 (UTC)[reply]

There having been no comments for the past while, I'm going to propose something.

Context will determine whether the 12-hour or 24-hour clock should be used.

Times in the 12-hour clock should with a colon(s), and lower case "a.m." and "p.m.". These suffixes generally cannot be omitted. "12 noon" and "12 midnight" should be used instead of "12 a.m." and "12 p.m."; some readers find the latter ambiguous.

24-hour clock times follow the same format, except without the a.m./p.m. suffixes. Discretion may be used to determine if leading zeroes should be used. 00:00 refers to midnight; 12:00 refers to noon.

Examples:

12-hour clock	Not	24-hour clock	Not
2 p.m.	2pm	14:00	14.00
2:34 p.m.	2.34 PM	14:34	1434
12:04:38 a.m.	12.04 38″ A.M.	00:04:38 or 0:04:38
12 noon	12:00 p.m.	12:00

I foresee a debate that takes the lines of "no consensus"; "no discussion", and so on. I waited one week from the last message and there were no replies, and three weeks from the first I posted to which there were no replies answering my question — so the best I can do is propose this change and see who objects. If no-one has strong objection reason then I think it's reasonable to assume people are okay with it.

It is not worth debating, in my opinion, which form of AM am A.M. a.m. is better because let's face it, none of them are "better" than any other and a simple plurality vote could decide it just fine; I'm sure many won't even have a preference.

If there are no objections for ten days, I will replace the current "Time formatting" section with the text above on 5 November 2005. Neonumbers 06:59, 26 October 2005 (UTC)[reply]

Proposed Currency Section

Following on from the page on currency style - Wikipedia: Naming conventions (currency) - I'd like comments on this proposed section, to be added to the end of the page:

For currency, use the appropriate symbol (before the quantity) or name of the currency unit (after the quantity), for example:

"$100" or "100 dollars" not "100$"
"€100" or "100 euros"
"¥100" or "100 yen"

For national articles or those where the type of currency is unambiguous it is not necessary to denote which currency unit is being used. However, it is necessary to indicate the nationality of currencies in internationally oriented articles or articles referring to more than one currency of the same name. This is done to avoid confusion and potential ethnocentrism. For example, "US$100" or "100 U. S. dollars" (not "100 US$", "$100 (US)", or "USD 100"); "A$100" or "100 Australian dollars."

Standard abbreviations are given at the article on the currency, for example:

We need a guideline, but I'm not happy about the automatic dismissal of the ISO 4217 codes which are the only unambiguous method we've got for indicating currencies. B$ = Bahamas, Barbados, Belize, Bolivia or Brunei? Are formulations such as "USD $100", "$333 (CAD)", or "MXN $250" really unacceptable? Let's explore all the available alternatives. –Hajor 00:58, 4 October 2005 (UTC)[reply]

I'm happy to explore the alternatives, that's what the talk page is for! :-) I'm suggesting this method as

the most common standard in current Wikipedia articles
the most common standard in international newspapers (Guardian, Times)
the World Bank standard
the 'cleanest' technique

That said, I have no objections to the alternative styles you list; if we're going for a standard-to-all-articles style I still favour my proposed technique, but if we're going for an article-consistent style instead they're fine.

Ziggurat 01:20, 4 October 2005 (UTC)[reply]

In full support for the existence of this, for standard-to-all-articles. That said...

I thought €, by convention, was written after the number, e.g. 45€, and for decimals e.g. 44€99. Or is this just regional differences? I don't know for sure, but that's what I thought so I thought I'd bring it up, feel free to correct me.
I prefer US$ to USD, because it's in more widespread use. "USD", like many other international "standards" (like SI units, for example) should only be used in specialised or technical contexts.
There is a major downside to using lots of different forms, that is that it looks messy; even if they are consistent within the article, their inconsistency within the encyclopedia degrades the encyclopedia's appearance.
I don't want to halt the exploration of alternatives before it's happened, but things like $333 (CAD) and all the other ones are, well, shall we say I've never before seen that format in my life.

And, I have a suggestion:

Generally, use the US$ format. If there is risk of confusion with one currency only (like B$), specify at the top of the article in italics ("In this article, B$ refers to Bahamas dollars"). In certain contexts, it may be better to use the USD format; if this is chosen it must be applied to the entire page and the first appearance of each must be linked to the appropriate page.

By certain contexts, well, I don't really know what I mean, I guess I mean in tables where there are lots of different currencies at it's completely unrealistic to specify each one so therefore we turn to our unambiguous standard. Also, in specialised articles that require it, but I don't know what articles would as I have no expertise whatsoever of the area. But anyway, in normal prose USD should be avoided because US$ is more common and understood.

Just to clarify myself, I don't see this as a compromise between standard and non-standard, I am completely against pitiful compromises on manuals of style because it is compromises that make them fail. This suggestion is what I think is best for good style with what I know at present (which may be very little). Neonumbers 10:16, 4 October 2005 (UTC)[reply]

Interesting replies. Has anyone got a link for those codes as used by the World Bank? Googling for "currency codes" on site worldbank.org only gives me results that use ISO 4217. I actually suspect there isn't a canonical list of those codes that covers all the world's currencies, and that once you get past the better known dollars, most of them seem to be pretty ad hoc.

Which leads into my next comment. What's been said so far has mostly focused on dollars, pounds, yen, and euros. And I rather suspect that's the case with the two style guides (Times and Guardian) -- they're very centered on the northern industrial world. If the aim here is to set a global standard (gulp), then we need to consider the full range of world currencies -- dollars and pounds, sure; but francs and lempiras and dinars and rupees, too. Cast the net a whole lot wider.

On reflection, perhaps this is something that needs to be taken on a case-by-case basis. Maybe I wasn't casting my net wide enough, either. Those examples I gave above really only work well with currencies that use the £ or $ signs (does anyone else use ¥ besides the Japanese?). For instance, saying

"A ride on the Mexico City Metro costs MXN $2.00" or "a ride on the Santiago Metro costs $250 (CLP)"

doesn't sound too bad, but it would be frankly bizarre to say

"A ride on the Cairo Metro costs EGP L.E.0.75" or "a ride on a Guatemalan bus costs GTQ Q3.50."

Much better in those cases to use "...costs L.E.0.75" or "costs GTQ 3.50."

(One downside of the ISO Codes is that the standard recommends they be used without $, £, etc, but that's very difficult to do in everyday texts such as these encyclopedia articles -- it feels very unnatural, counterintuitive to write a dollar amount without including the dollar sign.)

Another alternative -- we are a wiki, after all -- would be to use neither system of code and simply to rely on a link to the currency from the symbol to make it clear what we're talking about: $100, £100, ₪100. That would make the text flow more neatly, but it would have one major drawback: including the ISO 4217 three-letter code makes it crystal clear whether you're talking about ARS or ARP pesos, RUR or RUB rubles, MXP or MXN pesos, ALL or ALK leks, etc. That's lost if we just use the naked symbol, without the ISO clarification.

One thing I don't like about those US$, Z$, RD$, codes is they don't always distinguish between the marker that's used in the country (such as Brazil's R$) and the combination of the domestic marker and additional identifier (such as US$, C$, etc.), in the sense that that's not what's printed on the banknotes or what people write on their checks -- ie, for international consumption only. Thus: the Eastern Caribbean Central Bank's officially sanctioned symbol for the East Caribbean dollar is "$". EC$ is just some form of disambiguation they use internationally to avoid confusion. Also, from an aesthetic point of view, some of them -- even govt. sanctioned ones, such as Barbados's "Bds$" -- are frankly hieroglyphic.

Sorry -- came out a bit rambling, the above. Essential summary: US$, A$, etc. are good (and internationally recognized) for disambiguating one dollar from another, but the system breaks down once you're past that first group of familiar currencies: Is there one for the Uruguayan peso? Is a similar set of symbols used with the pound sign? (I couldn't think of any xx£ examples.) ISO codes are utterly unambiguous but -- as noted above -- not that familiar to non-specialists not accustomed to the world's more arcane currencies and (as also noted) not that easy to work into a grammatically flowing sentence. It may very well be that one system is appropriate for the world's most familiar currency, but not right for the kwanzas and the like that no one's ever heard of. Let's discuss this some more. –Hajor 15:14, 4 October 2005 (UTC)[reply]

Some of the proposals above look really bizarre to me: USD $100, $333 (CAD), MXN $250, $250 (CLP), EGP L.E.0.75, GTQ Q3.50. They double up the name or even give a wrong name (like mixing $ and peso). Written as USD 100, MXN 250, CLP 250, EGP 0.75, GTQ 3.50 they would make perfect sense. This is the form described by the ISO 4217 standard. −Woodstone 20:32, 4 October 2005 (UTC)[reply]

The World Bank standard (pdf) says US$ or U. S. dollars, but for all other currencies suggests that you should "consult Lotus notes" for the accepted abbreviation, whatever that is. Regarding this: "the Eastern Caribbean Central Bank's officially sanctioned symbol for the East Caribbean dollar is "$". EC$ is just some form of disambiguation they use internationally to avoid confusion. " New Zealand is the same; $ is the symbol here (of course) and NZ$ is appended when talking internationally. Ziggurat 20:41, 4 October 2005 (UTC)[reply]

You're right about the standard prescribing "USD 100" etc (without the symbol) but, as I noted above (and I quite understand if you missed it), it's very difficult to get lay writers, in lay contexts, to overcome the urge to indicate a dollar amount with a dollar sign. Problem with (eg) "AUD 100" is, outside a specialised context, it's not intuitively a currency amount. Hence the "doubling up". Of course, that may very well be the best argument against using the ISO codes at all. Or one in favour of "CAD 100" on first use, $100" on second, and "$100" subsequently.

Re "mixing $ and peso" -- $ is the symbol used by all the world's pesos, plus a couple of others (the boliviano and the real, for instance). Yeah, our dollar-, pound-, and euro-wielding editors might not be aware of that, but protecting them from having their horizons involuntarily expanded doesn't seem to be a good reason to deprecate standard local use. –Hajor 21:02, 4 October 2005 (UTC)[reply]

Furthermore, it was a peso sign before it was a dollar sign. Gene Nygaard 16:15, 6 October 2005 (UTC)[reply]

I wonder if a full reliance on links (e.g. $100) would be such a good idea — it's still an encyclopedia, and you can't really see links once you print the article (with a printer).

That aside, I'd like to just resuggest my earlier suggestion, because I didn't read anything about it: where necessary, put "In this article, NZ$ refers to the New Zealand dollar" at the top of the article except obviously not with New Zealand because that's unambiguous and therefore unneccessary. Only where necessary.

I think that that would be a good solution because it removes ambiguity without sacrificing understandability. Like I said before, it won't work where there's lots of currencies on the same page, in that case use those ISO codes no-one knows about. If there's really so many currencies it's better to revert to ISO codes, then I figure it'll probably be techincal/specialised anyway.

Of course, I don't claim by any means to be a currency expert, so if that's the stupidest solution ever please say so and explain why. But my point: ISO codes are not ideal and while their are plenty of situations where they'd be of good use, in articles where only one or two currencies are referred to I make my suggestion (as above). Neonumbers 07:00, 6 October 2005 (UTC)[reply]

Actually, as far as I know, ISO 4217 does not prescribe USD 100, MXN 250 etc, but 100 USD, 250 MXN etc. I would myself never hesitate about writing "100 USD" or "800 SEK" or the likes in an article. Maybe it's because I'm European and we are more used to international standards than Americans are, I don't know, but I really can't see how anyone, anyone, can read "100 USD" and not immediately think "a hundred US dollars". I feel really strongly that if a common currency symbol (most often $) is used throughout an article to mean the same currency, then say so at the top if it's not obvious, and that's fine, but never ever use the $ symbol if the context needs disambiguation. I don't like US$, and I certainly don't like "$100 USD" which clearly means "a hundred dollars US dollars". And we need the ISO codes for non-dollar currencies anyway. There are for instance at least seven countries sharing the currency name "krona", so the "100 yen" trick won't work here, and there's no symbol to denote it.

As I see it, the only reasonable alternative to the ISO codes, when there are several currencies involved in the same article, is writing out the entire currency each time. "There was a transfer of 800,000 Swedish kronor (roughly 100,000 US dollars) to the establishment, which added an additional 50,000 Euros." Something like that. But I think that's unnecessarily obtuse. Use the ISO code, and link it to the currency. Anyone will understand USD and EUR right away, and if someone is dumbfounded by SEK, he can just hover over the link. (This has the additional benefit of not having to use "kronor", a Swedish plural, in English, or contemplate translating it to "crowns".) -- Jao 07:53, 6 October 2005 (UTC)[reply]

I prefer US$125 in most situations, linked on first occurrence.

I find 125 USD acceptable in some situations.

For an isolated occurance, 125 United States dollars is okay.

I hate £3.75bn for £3,750,000,000 or A$1.45m for A$1,450,000.

Even worse is Rs 2.5 crores for Rs 25,000,000, or Rs 47 lakhs for Rs 4,700,000. Gene Nygaard 16:52, 6 October 2005 (UTC)[reply]

We appear to have run out of steam without reaching anything close to consensus. Does anyone want to try a watered-down proposal for language to include: perhaps Gene's first line for "familiar" currencies and his second line for "unfamiliar" ones (except there'd be a large grey area where "familiar" is inherently tinged by geographical bias and hence POV). Or should we continue to take matters in each article on a case-by-case basis? One guideline that should be included, and one on which I imagine consensus would be a given, is the use of lower-case letters for currencies: euros and francs, not Dollars and Rupees. –Hajor 16:44, 11 October 2005 (UTC)[reply]

Skatebiker 07:35, 12 October 2005 (UTC) I think that using currency can be rather relaxed by e.g. using lower case names, ISO 4217 three letter codes, but e.g. US$ 100 os OK as well. But Z$ can be confusing, use rather ZW$ for Zimbabwe dollar.[reply]

Non-base ten numbers

128.186.24.87 changed the non-base ten numbers section recently, to spell out the bases, thus 2345_six rather than 2345₆. Last time I checked mathematical convention was to use the number form 2345₆, which is how it was before. I could not find a discussion on this change (there was one to introduce the section, I was part of it); if there was one, do tell me. This user noted only that it "made more sense", not that it was proper convention. What is normal convention for showing bases? Neonumbers 22:21, 6 October 2005 (UTC)[reply]

I doubt that there is a uniform, consistent style used for this.

Some people apparently don't like using base ten numerals to specify the base; it seems to me that our words for numbers are at least as base-ten dependent as the base-ten numerals, and I'd even argue more so.

Skatebiker 07:35, 12 October 2005 (UTC): Another proposal is to standardize the extra digits required for bases greater than ten. Using e.g. T and E for ten, eleven for duodecimal and A and B for the same numerals in hexadecimal is confusing. I propose the digit set 0123456789 ABCDEFGHJK LMNPQRSTUV WXYZ (omitting the 'I' and 'O' preventing confusion with '1' and '0', possibly the 'S' might be omitted as well for the '5') which covers all bases up till 34.[reply]

I cannot imagine that there would be enough use of duodecimal numbers on Wikipedia to worry about any perception of inconsistency. Battle it out on the couple of articles which might discuss them.

It doesn't usually matter for integer bases less than 10; if there is some reason to use other symbols, that can be explained when they are used.

The only bases greater than 16 that are likely to be of encyclopedic interest are vigesimal (Mayan numbers) and sexagesimal. You might be able to find graphics of the Mayan glyphs consisting of bars and dots and a football-shaped shell for zero, but otherwise when they are written out, it is customary to use two-decimal digit representations of the vigesimal numbers, and the same is nearly universal for representation of sexagesimal numbers (witness the common sexagesimal fractions of a degree used in latitude and longitude). These are usually separated by a dot or a colon or some other symbol such as the prime and double prime or superscript Roman numerals or written in columns, so that the digit-pairs are clear. I don't see any real need for single-character representations of anything in higher bases than hexadecimal numbers. Gene Nygaard 18:25, 12 October 2005 (UTC)[reply]

The format I last discussed is what is used at Maya calendar for the vigesimal numbers—not strictly vigesimal, either, but three digits for a vigesimal count of tun (years of 360 decimal days) and two digits for the count of the days in that tun: "The Long Count started at 13.0.0.0.0 on Julian day 584283", etc. Gene Nygaard 18:36, 12 October 2005 (UTC)[reply]

Well, I have a (junior) maths textbook and a C++ progamming learn-in-21-days book, both which reckon the 1234⁶ is standard. Well, in any case, both use that format. I understand if people are sceptical about these being proper references, but I've never before seen any other convention on the matter. Neonumbers 10:44, 19 October 2005 (UTC)[reply]

Did you mean 1234₆? (okay to delete this if so and corrected) Gene Nygaard 11:06, 19 October 2005 (UTC)[reply]

Whoops, yep, that's exactly what I meant - thanks for pointing that out :-) Neonumbers 09:25, 20 October 2005 (UTC)[reply]

talk page oddity

I notice that there is no article/project associated with the talk page Wikipedia talk:Naming conventions (calendar dates). When I go to that talk page, and click the "project page" tab, I'm redirected to Wikipedia:Manual of Style (dates and numbers).

I find this confusing. Should we somehow merge the 2 talk pages associated with that single project page? --DavidCary 15:46, 8 October 2005 (UTC)[reply]

More about overlinking of dates

There was a recent discussion (Wikipedia_talk:Manual_of_Style_(dates_and_numbers)#Dates_linking_convention_currently_ludicrous) about overlinking date elements. Just in case people did not read the references to a proposed solution, below is a quote from: Village pump archive:

I support this proposal. I agree that linking to dates is a generally cause of over-linkink. i think thjat shuch links, as links, are usually pointless, and should be removed if there were to be another way to apply date preference formmatting. I also think that most links to partial dates (D/month without year, or year alone) are already pointles, and i have started to remove them when I edit articles that have such links, although i don't go looking for them.

I have no idea if the proposal is technically hard or easy. I find it hard to belive that it is impossible. Note that instead of _10 Jan 2005_ we could have #Date(10 Jan 2005) if that were technically easier to implent. DES 22:07, 31 May 2005 (UTC)[reply]

There's no need for special syntax, the software can recognise dates in plain text. -- Tim Starling 09:35, Jun 1, 2005 (UTC)

That would be much simpler if implemented! I presume that on occasions (such as this) where we want to see a specific format not altered by preference then putting the date in nowiki tags would allow that? (i.e. 01 June 2005 would appear as per your preference and <nowiki>01 June 2005</nowiki> would always appear that way). Thryduulf 12:50, 1 Jun 2005 (UTC)

Does anybody know how to implement this? Bobblewik 13:38, 6 August 2005 (UTC)[reply]

I think the first step will be to put a feature request on bugzilla. Outside of that, I'll point any of the developers at the discussion if I happen to see them later. Thryduulf 09:54, 7 August 2005 (UTC)[reply]

I tried getting into bugzilla but failed. I would be grateful if somebody else make the request. Bobblewik 16:11, 9 October 2005 (UTC)[reply]

Number notation

Skatebiker 07:48, 12 October 2005 (UTC): In the Number notation section of Wikipedia one is encouraged to write large numbers to split up the digits in groups by three separated by commas. This is against the ISO 31 rule and, moreover, ambiguous in many cases as the comma can be used as a decimal point. Why does Wikipedia not observe the ISO standard ? I propose to change the guideline to avoid writing large numbers with commas (or dots) separating groups of three digits. This is ambiguous particularly for numbers under 1 million. E.g. 123,456 can be interpreted as hundred twentythree point/comma four five six or hundred twentythree thousand four hundred fivty six which is comfusing. ISO 31 advises using spaces (preferably thin spaces HTML :  ) instead. Commas or points in numbers should only be used as a decimal separator between integer and fraction part.[reply]

Moreover using scientific notation writing the exponent notation as usual in computer output or calculator display. This is easier readable. E.g. 5.67e-8 reads easier and takes less space than 5.67×10^-8. So that I propose in the guidelines as well.

I agree totally. I came here looking for a reason why the style guide deliberately contravenes ISO 31. As wikipedia is truly international, that doesn't make sense to me. I will welcome your change Yaf201 13:59, 12 October 2005 (UTC)[reply]

The ISO standard is widely ignored, and its use is almost always considered unusual in many countries. I notice, for example, that the English and Japanese Wikipedias tend to use commas but also a mix of the other forms to a lesser extent; German, Dutch (Netherlands), Italian and Spanish use dots, French, Polish, Bulgarian, and Swedish use spaces. Portuguese uses a mix of dots and spaces, and more often than others will also tend to just show large numbers with no spacing. This information was gathered by looking at the front page and searching for "yen" and "giga" on each site. For some, I had to poke around to find more examples to confirm common usage. The point here is that stomping on common usage in favor of a standard, no matter how prestigious the standards body, is not what Wikipedia is about. If it were, we'd also exclude the use of words that are not listed in the OED.... I suggest that we simply try to make sure that within an article, there is a consistent usage that is appropriate for the subject. If you're discussing SI units, then it makes sense to use ISO numbers, but if you're discussing a topic relating to the English-speaking countries that use commas, I don't see why you would use anything but commas. -Harmil 16:28, 12 October 2005 (UTC)[reply]

That ISO 31 standard has not achieved much of a following in general usage outside Wikipedia, so there is no particular reason why Wikipedia to follow it. Can you cite particular style guides which might prescribe it for general use, or certain publications which do in fact follow this rule?

Part of the problem is that the standard itself, by its own terms, deals specifically with usage in connection the International System of Units (with maybe a few non-SI natural units and things like that; it doesn't deal with usage of English units, for example). It isn't presented as a general rule. It can be emulated in other usage, but the standard technically doesn't apply to any usage outside SI. Nobody looks to this standard for the expression of monetary units, or for the expression of population counts, for example.

However, using that format with SI units and not with other units (something occasionally seen in Wikipedia and elsewhere) is downright silly.

I wouldn't want to be the one responsible for making all the changes if were were to change the policy to require spaces.

When that format is used, the spaces should be non-breaking spaces. But that has rarely been done on those fairly rare occasions when that format has been used on Wikipedia. This is more important than any "thin-space" recommendation, for a character whose existence most editors aren't even aware of (and one still, I think, not well implemented in at least one of the major browsers, a problem which has been discussed in the past, resulting in spaces bigger than a normal space). There are also separate "thin space" and "non-breaking thin space" characters in Unicode, IIRC, but at least in the browser in which thin space works for me, the   representation of this character is interpreted in a nonbreaking way.

A thin space, and even a normal-sized nonbreaking space, make editing difficult, because these characters are not normally available on our keyboards. They are also not available in the character list which now appears at the bottom of English Wikipedia edit pages (something that is also clumsy for more that isolated use of any of these characters).

There isn't that much ambiguity in the usage within the English language. Most of our problems with it come in edits by non-native English speakers, or more so by rough translations from some foreign-language source (including other Wikipedias). Similarly, there are problems with unconventional division not into thousands but into curious numbers called lakhs and crores by editors from India.

I don't like the second proposal, and think we should discourage the use of that exponents with "e" or "E" format. It may indeed be more familiar to computer geeks, but there are also many people taught in the old school, and the 10ⁿ is more recognizable to most computer geeks than the "e" notation is to people not brought up with that usage. The E works fine for computer languages using ASCII character set without superscripts and subscripts (and only a couple of those superscripts as characters, none negative, in various extensions of ASCII). I would like to see more use of the engineering notation variant, with exponents divisible by 3, but wouldn't want it as a guideline for general use to the exclusion of the one digit before the decimal point type of scientific notation. Gene Nygaard 17:08, 12 October 2005 (UTC)[reply]

The ISO 31 number standard is the normal standard in South Africa. Although the comma is widely used as the decimal separator, the point is readily recognised and never assummed to be a thousands separator. Using spaces instead of commas for thousands separators is instantly recognisable in all languages, including all variations of English. If wikipedia is going to deliberatly encourage the use of commas instead of spaces as thousands separators, the style guide should say why and accept the potential for ambiguity.
99 999 and 99.999 are unambiguous; 99,999 is not and should, in my opinion, be avoided. Strict adherence to ISO 31 would allow use of the comma as a decimal separator. I would suggest that, because of its different meanings in different countries, wikipedia style guide should deviate from ISO 31 by discouraging use of the comma in English language articles.

I also am not keen on the second proposal. I think the 10ⁿ format is more recognisable, but that is my subjective view. --Yaf201 08:56, 13 October 2005 (UTC)[reply]

Strict observation of ISO 31 is not what I propose but just the writing of large numbers separated by commas or points is what I discourage. This spaces is a strict option from ISO31 but   or normal spaces is also OK and even no separation at all for not too large numbers (e.g. under a million). So I'd rather write The distance of the Moon is 384400 km. 384.400 km or 384,400 km appears to be in a low Earth orbit.

I agree here not te prescribe use of commas as the decimal sign in Engligh language articles. Skatebiker 09:42, 13 October 2005 (UTC)[reply]

That 99.999 is no more unambiguous than 99,999 is; many people do use the dot as a thousands separator, and I have changed numerous Wikipedia articles which have done so. Yet as I write this, you can still find it in hundreds of articles such as Aircraft carrier and Swisstopo and La Pampa Province. It's just that you are less likely to see 99.999 for 10⁵ − 1 in English by primary English speakers than you are in some other languages such as German, but we often import information from languages using that convention into Wikipedia, or have it added by users more familiar with some other language. Gene Nygaard 22:11, 13 October 2005 (UTC)[reply]

My first attempt at using a non-breaking space failed and my example above had 99 at the end of one line and 999 at the beginning of another. So I ditched   and instead used   I copied this from a well known web page ie www.wikipedia.org!!!! It's a pity there isn't an easier way of putting this in on my keyboard. A space is not the ideal option for separating groups of digits, but it's much better than a comma or a dot Yaf201 11:49, 13 October 2005 (UTC)[reply]

I agree with Skatebiker and Yaf201 that the Manual of Style (MoS) definitely should not be encouraging diametric violation of ISO 31. Because the comma is widely used as the decimal point outside the USA, it should not be recommended as a thousands separator in Wikipedia MoS. Note that using a thousands separator is entirely optional (ISO 31-0, Sect. 3.3.1; BIPM, SI brochure, Sect. A1.4.2), and if used, is never applied to numbers having only four digits (NIST SP811, Sect. 11.11) unless aligning a column of numbers. Therefore, one can use either a space character or no thousands separator at all, but not a comma nor a dot. This mistake indeed needs to be corrected in the MoS and changed to something like the following. "A space character (regular space, &nbsp, or &thinsp) can be used as a thousands separator to separate groups of three digits, if desired, though this is not required. But a comma character should not be used as a thousands separator (because the comma is widely used as the decimal sign outside the USA). Whether a space or no space is used as a thousands separator will depend on the situation at hand, but since a thousands separator is optional, omission often tends to be preferable." --Simian, 2005-10-13, 21:10 Z

I hear a lot of writers are following a standard called written English. Most literate educated English-speakers have never even heard of the European decimal comma, ISO recommendations, and engineering notation (apologies to our more versatile South African friends). Figures and other elements of encyclopedic text should be exactly what people expect them to be, and not make them change their point of reference just to read.

Spaces as separators in numerals don't work right, anyways:

Using regular spaces as separators makes numbers break at the end of a line, which is unacceptable.
Entering non-breaking spaces using   make wikitext laborious to write and hard to read.
A Unicode non-breaking space character can be typed as option-space on a Mac keyboard, but some common browsers will silently convert it to a regular space during any subsequent edit.
Using a thin space is the best typographic style for European thousands separators, but the character isn't supported correctly by any font that comes with Windows, can't be typed easily, and   in wikitext has the same disadvantages as  .

Please don't enter numerals in European format. —Michael Z. 2005-10-14 01:38 Z

Don't think ISO 31 is a European format. It's an international standard, widely used in some of the USA text books for decades. Nonetheless, you make some excellent points regarding on-line thousands separators. At the same time, we shouldn't push an idiosyncratic local practice upon an international audience, in violation of the international standard widely used, including partially within USA. So I think we can agree, based on your comments, that since the thousands separator is entirely optional, both in ISO 31 and in USA practices locally, then the best option appears to be omission in most cases. Many text books and documents in USA already omit the thousands separator to no ill effect. Let's all agree to quit recommending in the MoS that commas be inserted; they aren't required in USA. --Simian, 2005-10-14, 02:48 Z

I think Simian's suggestion is the best compromise. The dot and the comma are not acceptable for thousands separators in an international forum (if Wikipedia were purely American or British it would be a different matter). The various forms of spaces have typogrphical problems, so I now think that thousands separators should be avoided altogether and the decimal separator can be either the dot or the comma depending on the preference of the writer and/or the regional practice of the area / country being written about.

In the UK, digits are not normally grouped after the decimal point, even if they are before it, so one would write 9,999,999.9999999 wheras in ISO format, this would be 9 999 999.999 999 9. So I see no problems in writing 9999999.9999999, although in real life that degree of precision is unlikely to be required, except in scientific and technical fields where ISO 31 will apply and scientific notation is likely to be used --Yaf201 08:58, 14 October 2005 (UTC)[reply]

Ok good idea, do discourage the commas and dots other than the decimal sign. The breaking spaces is indeed an issue as in 'normal' HTML text one can use <nobr>number_with_spaces</nobr> to prevent breakup at the end of a line but Wiki swallows these <nobr> HTML tags. Maybe an option to allow these tags again (not only for numbers but for all text to prevent the problem with    . Anyway do not mandate the thousands separator. Skatebiker 09:18, 14 October 2005 (UTC)[reply]

The ISO standard being "widely used in some of the USA text books" is far from it being widely used. Saying "we shouldn't push an idiosyncratic local practice" about the standard English-language thousands separator is like saying we should reconsider our parochial use of the Latin alphabet. People who read English know what the thousands comma means, including South Africans according to the discussion above. They don't all know that a comma can also be a decimal point. The ISO notation is based on the normal number format of European languages, and it is different from the normal English-language form.

Writing 9999999.9999999 is a problem, because it is poor writing style. Quick: is that about ten million or a hundred million? If the reader can't determine the order of magnitude without using a finger to count digits on the screen, then the editor has failed.

It's also incorrect that four-digit numbers should never have a comma. They should have a comma when they're in a table column below twelve-digit numbers, for example. —Michael Z. 2005-10-14 10:50 Z

Writing 9999999.9999999 is a problem, because it is poor writing style. Quick: is that about ten million or a hundred million? If the reader can't determine the order of magnitude without using a finger to count digits on the screen, then the editor has failed.

That's a fair point, Michael. To be honest, I'd be unlikely to use this degree of precision and I'd write somthing like "nearly 10 million". If I needed to be this precise, it would almost certainly be in a technical or scientific article when the ISO format of 9 999 999.999 999 9 would be appropriate. Would you write 9,999,999.999,999,9? Yaf201 14:43, 14 October 2005 (UTC)[reply]

The separation after the decimal point is of little utility, and is almost never seen with commas. We are generally much more in the order of magnitude of the number, than we are in the precision to which it is expressed.

In other words, we want to be able to tell whether it falls into the "millions" category, or if it is "thousand millions" or "billions", whatever we want to call it. And when you get to bigger -illions, that's best left to the reader, who can tell either tell herself or himself that 9,999,999,999,999 is in the "billions" or that it is in the "trillions" range, whichever is familiar to that reader, something that isn't so easy if someone else who might have different understandings of those words has already done it.

OTOH, once we get to the decimal point, we read it either in our own minds or in speaking it out loud as "point digitname digitname digitname". and we don't care so much if the precision is down to the millionths or billionths or whatever. Gene Nygaard 15:16, 14 October 2005 (UTC)[reply]

Users Skatebiker and Yaf201 are using faulty logic in assuming that since there are occasions in which the separators can be omitted, and because omitting them doesn't change the value of the number, that omitting them is an acceptable writing style for all purposes. It most certainly is not.

Mzajac is also correct on his other point. Hardly anybody claims (I don't know if I've seen it other than the arguments of some in this section) that using separators in four-digit numbers is unacceptable. Oh, sure, some people do express that rule for specific types of numbers. One common one is not to use separators in calendar years less than 10,000. But nobody says that you should never use it with fourdigit numbers, and it is broader than tables where consistent usage is normally desirable.

One of the biggest problems with the spaces format is that it is almost always pushed as a part of the use of the International System of Units, and those pushing its use there often recognize that they have no real authority for usage outside that context.

But there are also many people who feel strongly that having different rules in that context than for other numbers such as population counts would be silly, so they quite justifiable stick with the normal rules and do not follow the rules some SI proponents would like them to follow.

Of course, if SI is actually used to full advantage, there would be very little opportunity to use thousands separators in the first place. Judicious choice of prefixes, or the use of scientific or engineering notation, generally avoids the need for them

So even if some technical journals follow this rule, few people are going to learn it because there is only limited actual use of it in a technical context. Therefore, it would logically (and does in fact) have minimal effect on general usage.

For example, if SI were used to full advantage, we would not see things like "The average distance from the Moon to the Earth is 384,403 kilometers" (Moon), but rather "384.403 Mm".

We wouldn't see "distance of about 80,000,000 km" (Mars), but rather "distance of about 80 Gm".

We wouldn't see "about 120,000 parsecs across" and "10,000,000 kelvins" (NGC 4555); instead, we'd see "about 4 Zm across" and "10 MK".

As you can see, people who have little use for the convention aren't really in a strong position to be urging it upon everyone else. Gene Nygaard 12:21, 14 October 2005 (UTC)[reply]

I agree regarding four-digit numbers when aligning a column of numbers; and I have now inserted, into my original sentence, the phrase "unless aligning a column of numbers" (highlighted in green).

Michael, SI has been the federal measurement system of USA since 1992. You keep erroneously implying that an arbitrary, nonpreferred system is somehow a preferred measurement system of "English-language" countries, which is not the case. SI is the preferred, federal measurement system of USA since actually 1988; and SI specifically forbids using the comma as a thousands separator. Therefore, using the comma certainly isn't the normal or preferred "English-language form" -- and the MoS is just plain wrong, and needs to be fixed. And you're incorrect in thinking SI (e.g., ISO 31) notation is a "European format." SI is used by all countries worldwide. It is the format preferred by USA since 1988. By no stretch of the imagination is SI a "European format." Also a few others herein implied that SI is somehow only for scientific applications, while some other system is for nonscientific applications. Please eradicate this gross misconception. SI applies to all facets of measurement. It became the federal measurement system of USA since 1992 for commerce, trade, business, and nonbusiness -- not just scientific applications.

Let's agree to quit recommending the wrong format in the MoS. It's not the correct nor preferred system. Where required, &nbsp works fine in the interim until we develop a wiki markup for thin space, keeping in mind that the thousands separator is entirely optional and should be used sparingly. Also, Gene Nygaard is correct in saying the thousands separator can be omitted to the right of a decimal point, keeping in mind that it's optional, as stated in SI by BIPM. --Simian, 2005-10-15, 18:40 Z

I'm not too uptight about things like commas in four-digit numbers, I just don't want to see us over-specify the convention with rules that ought to be regularly disregarded by writers. There has to be room for common sense and exceptions.

But I'm in Canada, where at least in theory, we've been officially completely metrified since the 1970s[1] (with respect to Simian, the US and UK are not). No one in general Canadian usage uses spaces for thousands separators or decimal commas (except of course in French). These SI notations originate in European languages and are comfortable to readers of European languages (I did not mean to imply that SI is in some way "politically European"). SI notation is fine in disciplined scientific writing, but English readers are comfortable with the traditional comma-decimal notation.

If we were to officially mandate SI notation for all of Wikipedia, I would be satisfied with that. It may be jarring to most Anglophone readers at first, but it would be consistent and easy enough to get used to. But until that happens (and we all know it's not likely), we should consistently use the numeric notation readers expect and not something out of an engineering or astronomy publisher's style guide. —Michael Z. 2005-10-20 17:59 Z

Using a separator with four digits before the decimal point is acceptable in broader contexts than alignment of tables. Omitting it is optional outside of particular contexts such as calendar years, one of the few places where using it would be considered inappropriate.

The official style guide for the U.S. government is the U.S. Government Printing Office Style Manual. If you follow the link to Chapter 12 (the html version is rather crudely formatted compared to the pdf version, but either will work for this), you find the GPO Style Manual rule:

"12.14. The comma is used in a number containing four or more digits, except in serial numbers, common and decimal fractions, astronomical and military time, and kilocycles and meters of not more than four figures pertaining to radio."

Of course, their use of "kilocycles" is a dead giveaway that they aren't really on top of things! Curiously enough, they also have this:

"12.9. Units of measurement and time, actual or implied, are expressed in figures."

...
"e. Use spaces to separate groups of three digits in a decimal fraction. (See rule 12.27.)

0.123 456 789; but 0.1234"

Note also that SI is a system of units; it does not "forbid" anything.

The BIPM (or CGPM) doesn't has no authority outside the metric system. Expressing such a rule as applicable to the metric system, with no authority to change anything in any other use, is tilting at windmills.

If the ISO expects to promulgate a rule of general applicability, it needs to do so in cooperation with the people who actually write the style guides for various types of writing.

If the ISO expects to successfully promulgate such a rule of general applicability, it needs to make a serious effort at better outreach, and not do silly things such as overcharging for its standards in this area, so that it will reach those with a more casual interest in their rulings.

You see, don't you, that nobody has given ISO any plenary authority to write or to amend our manuals of style for us.

BTW there is another much lesser-used format for the thousands-separator (and I just recently edited it out of one Wikipedia article using it). That is the use of the apostrophe as a thousands separator: 37'252'500. Gene Nygaard 19:04, 20 October 2005 (UTC)[reply]

I forgot to mention that from the way the BIPM expresses its rule, it obviously applies only to the British and the French. Americans or Canadians or Australians or Pakistanis or Chileans or Fijians or whatever aren't mentioned in the unofficial English version of the rule, and likely not in the official French version either. Gene Nygaard 19:13, 20 October 2005 (UTC)[reply]

Number notation: application

How are issues like these finally resolved? It appears there are 6 individuals contributing to this discussion. 3 who don't like the current MoS entry and would like to see something more international and 3 who prefer the status quo. That probably means that the vast majority of wikipedians don't care and will carry on doing their own thing. In that case, should this entry in the MoS just be deleted and we accept that there will be a variety of number styles used across wikipedia? The intro to the style guide says that wikipedians are not bound by the style guide. I, for one, will never use commas as thousands separators (nor as decimal separators in English, come to that), whatever the style guide says - to me it is just plain WRONG. And I suspect that Messrs Harmil, Nygaard and Mzajac will never use anything but UK/US format. Maybe an acceptance of diversity is what's needed? --Yaf201 12:49, 14 October 2005 (UTC)[reply]

Even if this does fall into Category:Stupid human tricks along with things like driving on the left side of the road, and writing from right to left, that's not enough in itself to change existing guidelines.

Just as Wales should not have some roads on which you drive of the left side and some on which you drive on the right side, and the English language should not have some situations in which we write from left to right and some in which we write from right to left, Wikipedia should strive for a minimum of consistency on this issue, not a free-for-all "acceptance of diversity". I'd accept spaces, had that been the standard from the beginning (and ISO and others were pushing that format long before Wikipedia ever existed, so it could have been). But that isn't the case, and there is insufficient justification to change the existing guidelines now, and lots of problems associated with making such a change now. Gene Nygaard 13:14, 14 October 2005 (UTC)[reply]

What problems would changing the guidelines cause? No one is proposing a full scale re-edit of articles just to change number formats. I certainly don't believe that changing the MoS to advise against use of the comma will prevent it being used in future - just as the current guidelines will not prevent me using spaces or avoiding thousands separators altogther. On reflection, I am more convinced that a descriptive approach to this issue would be better than a prescriptive approach. After all, most wikipedians are out there writing and editing articles rather than worrying about number formats. I only came here because I am the weird sort of person who decided to read the MoS before jumping in feet first. I couldn't understand why use of commas was advised and I still can't. "We've always done it that way" has never been a good reason to me. --Yaf201 14:16, 14 October 2005 (UTC)[reply]

A related problem is that many of the standards-setters such as CGPM and ISO are lost in their own little world, so out of touch with the real world, that they make no effort to reach out to those who actually set the standards for the style used in newspapers, books, and the like.

Furthermore, they had so little clout in the early days of computing that, even though they prescribed an international symbol for ohms, until Unicode was introduced and became fairly well established, most of us had no convient way to make this symbol Ω on our computers. Sure, many web pages used clumsy kludges, such as using graphics files for this symbol (but though the other letters were scalable, those weren't, often making things look funny). Actually, it goes back even further than that; they didn't have much more clout with those making daisy wheels for typewriters, either.

Another related problem is that these organizations often charge outragous prices for their standards, ensuring that they won't be bought by anyone outside of their captive audience of those required to do so because various governments have adopted those standards as applicable to a particular activity. They aren't going to be purchased, or followed, by those with only a casual interest in the subject. Gene Nygaard 12:58, 14 October 2005 (UTC)[reply]

I can't comment on the connection of CPGM and ISO with reality. But it seems to me that we're not going to hit consensus on the number format issue. So why not look at this issue another way? Should the MoS be prescriptive or descriptive? Should it aim to clarify by imposing rules for us to follow or to clarify by providing explanations of what we have done? If the MoS itself says that contributors are not bound by its contents, then I think it should be the latter. The number section could just describe the various number formats that the reader is likely to encounter on wikipedia? --Yaf201 13:13, 14 October 2005 (UTC)[reply]

Skatebiker 08:24, 15 October 2005 (UTC):[reply]
Then I have a completely different idea. For each user logged in one can set preferences like skin, timezone, etc. So why not number format ? As Wikipedia is virtually completely script driven on PHP (therefore 'wikifies' the content which is edited by the user) it is therefore possible to 'wikify' numbers to the user's preferred number format as e.g. '''bold text''' 'wikifies' to bold text. Simple PHP regular expressions functions like preg_replace() do the job.
A number like 9,999,999,999.9999 will be 'translated' into the user's preferred format. But in numbers containing a single point or comma like 2,005 is may not work.

Instead, why don't we just create a new wiki markup for &thinsp? This would address the issue Michael Z. brought up in his second and fourth bullets. Whatever the Wikipedia software converts it to will be transparent to the user, and secondly, it will have contextual meaning, a big advantage. Third, it will be upward compatible in the future whenever all browsers correctly display a nonbreaking thin space (though there certainly would be no rush on this, since &nbsp works fine, these days, in the interim). Can anyone think of an excellent markup symbol for &thinsp? --Simian, 2005-10-15, 22:07 Z

No,   doesn't "work fine" either. It often makes edit screens very difficult to work with as is. If we were to replace all the comma thousands separators which this six-character-and-no-visible-space abomination (and eight characters for the thin space), many of the exit screens would be really horrible messes.

Furthermore, we already have people sticking in unnecessary nbsp between numbers and units of measure, because this guideline suggests that silliness. There are a few occasions when it is nice to not have a break there, but there is absolutely no reason to present that as a general rule. Gene Nygaard 04:06, 16 October 2005 (UTC)[reply]

It works acceptably, iff it is used sparingly. That's all. Gene Nygaard 04:09, 16 October 2005 (UTC)[reply]

To clarify, I'm referring above to wiki markup, not html markup. I currently propose that we use (create) a wiki markup symbol consisting of two semicolons (;;) to represent a so-called "&thinsp" (even though initially it will actually be &nbsp). An example follows.

10;;000;;000.000000 would render as 10 000 000.000000

So can anyone tell us if there's any conflict with using two semicolons embedded between two numerals? Note that the symbol must be embedded between two numerals in order to qualify as a valid thousands separator. Is this unique and not in use? Can we move forward with this idea and resolution? --Simian, 2005-10-17, 05:48 Z

Okay, here's my take (some of which may already be resolved, I accept):

Context matters. Most ISO standards cannot be applied to most general contexts. Scientific notation cannot be used to represent, say, money, or the number of seats in a legislative house, or the population of a country. That said, the ISO debate seems to have died already.
With regard to scientific notation, 1.234×10_n, and only that form, is correct. Other methods of representing it are used on calculators and similar devices only.
With regard to decimal points with dots and commas, I had no idea that any English speaking nation anywhere used the comma as a decimal point and a dot as a thousands separator, but that might just be me.
I don't like this idea of adding this to markup. These are numbers. Adding it to markup would be a very poor solution, because numbers appear all the time and as I say, context matters.
Does this make me the seventh contributor? Anyway, most people (unlike me) find better things to do than discuss things on a MoS talk page! This is just my interest, because I think this is one of the backbones of a good encyclopedia.

The thing I want to bring to attention here is that there is no one-size-fits-all solution. Because of their very nature, natural-scientific articles will always display large numbers or even small numbers differently to social-scientific articles. The best we can do is make a suggestion for each, or explicitly mention what not to do. Neonumbers 09:47, 20 October 2005 (UTC)[reply]

year zero

I suppose I open an old wound here, but I'm not going to search through 27 archives. Maybe there should (also) be a single index to all the archives. Anyway...

I'm abhorred. Wikipedia does not use a year zero? I know that that causes a problem with old dates because the Romans didn't yet know about the zero. But there have been more changes in dating, such as the change to the gregorian calendar, so why not take this next logical step. Surely, Wikipedia should prefer an ISO norm (ISO_8601#Dates) over an illogical tradition. At 1st century someone even removed the reference to that 'alternative'. This is sort of like only using feet and removing all translations into meters. Actually, it's even worse, because one can work quite decently with other systems than the metric system, but leaving out the zero would make modern science impossible. Even the simplest basics wouldn't work anymore. The invention of the zero is one of the greatest leaps ahead in human knowledge.

Suppose some aliens would pass by Earth, have a look at that great encyclopedia they see we have and happen to first read the 1st century article. Surely, they'd have to conclude that, since we haven't invented the zero yet, we're not worth contacting. :) And it looks extra stupid comsidering the table at the bottom. It looks like we have a great big gaping hole in our decimal system. How is it we have a '0' in our system but don't use it as a separate number? DirkvdM 05:45, 13 October 2005 (UTC)[reply]

Generally speaking, I like ISO standards, because they discourage us from believing that the way we do things is the way the rest of the world does them. I certainly have fallen foul of the American date format, missing a teleconference because i thought it had been scheduled for 5/6, which I read as 5th June not May 6. ISO 8601 is one way of avoiding that and current Wikipedia style of using month names is another. I'm happy with either.

Logically there should be a year zero, but I doubt little confusion actually arises because wikipedia doesn't use it. Maybe the wikipedia style guide should allow the use of any calendar eg, Gregorian, Julian, Jewish, Islamic etc as long as the ISO date is also given? Having said that, I personally don't like the fact that the ISO date is based on the Gregorian calendar - maybe it could have had a more culturally neutral basis? But I suppose we're stuck with it --Yaf201 09:23, 13 October 2005 (UTC)[reply]

Agreed it is just normal logic that a year 0 does exist as the natural number 0 does exist. Skatebiker 09:27, 13 October 2005 (UTC)[reply]

About using the gregorian calender as a basis; you have to pick one and a neutral one would have been one that no-one uses, which would be 'politically correct' but impractical. Now at least several hundred million people (?) don't have to change what they're used to. I'm afraid that using year 0 as a Wikirule is not going to happen because there will be too much opposition. But deleting a reference to it at 1st century certainly won't do, so I'll go and change it back. To change the text on this project page I'd like to have a little more consensus first, though, so I'll first wait for any further reactions. DirkvdM 18:26, 13 October 2005 (UTC)[reply]

If you really feel the need to do math with dates, just remember that the zeroth year of our calendar is called 1 AD; it shouldn't be too hard after that (also keep this in mind if you think that the twentieth century started in the year 2000). But using a different name for what ninety-nine percent of the world refers to as the year 1 BC would be completely contrary to the spirit of Wikipedia's conventions. —Michael Z. 2005-10-13 19:27 Z

The use of year zero was a convention of astronomers before it was included in the ISO 8601 data transmission format. Nonetheless, for a long time the Wikipedia software, though it used the all-digit YYYY-MM-DD format as its preferences option, it did not handle dates wikified in that format with a negative year properly, nor the display in that format of years wikified in other formats (at least one of these, I think it was both). In fact, I was the one who made the bug report to Bugzilla that finally got it fixed only a few months ago, after I had brought up the problems a few times on this talk page. Gene Nygaard 20:34, 13 October 2005 (UTC)[reply]

Michael, I acknowledge that tradition goes against logic here, and both need to be mentioned (if only so as not to confuse those who only know about the traditional way). So the notions that the 20th century started in 2000 or 2001 should both be mentioned where applicable. As well as the the first year of our calendar being '1 AD' or 'year 0' (note the difference in notation - the year before that would be '1 BC' or 'year -1' respectively). But you say the zeroeth year is 1 AD. The zeoroeth year? What is that? Ah, there's an article on zeroth. Apparently that's a computer term (where it does indeed make some sense). Not quite what you had in mind, though, I suppose. DirkvdM 08:58, 14 October 2005 (UTC)[reply]

Well, the basic definition in zeroth is exactly what I was thinking of: "The zeroth item is the initial item of a sequence, if that sequence is numbered beginning from zero rather than one." I meant that precisely 2000.5 years after the (nominal) date of the birth of Christ is the middle of the 2001st full year, the year we label 2001. In the same way, a one year old baby is in its second year of life, but no one argues that this is a lapse of logic or that "leaving out the zero" makes science impossible.

I agree that ISO dating should be mentioned and explained here. I've been using the ISO short date notation for a while because it is much less ambiguous than "01/01/01", but until reading this discussion I had no idea that it had a year zero, and used different numbering for years BCE. I'm quite surprised that the ISO people would move the start of their calendar a year earlier than the start of the traditional Western calendar. —Michael Z. 2005-10-14 10:27 Z

I suppose a central problem is the notion of a 'start of the calendar'. Time is continuous and where one puts the zero (or one) is completely arbitrary from a non-religious point of view. All other units have an absolute 'point zero', but with time one can not even place it at the Big Bang because that is just a theory and it is not even known when it took place. And it would make for very cumbersome dates. So I suppose ISO just took one system that happens to be in wide use and made that more logical. The only problem arises with years before year 1 where a precision of a year or less is needed. Before, say, -5000 that is rather unlikely to happen, so the only problem lies with a few thousand years of which so little is known that the difference is irrelevant.

A not-yet-one-year-old baby is in its first year of life, which is year zero (which is confusing, which is probably the reason that some shift it and use 'zeroth item'). (btw, you don't say a baby is zero years old because you use more precision that case - months, weeks, days, hours). This is however a different system than the one that puts 2000.5 years after year 1 in the middle of the 2001st full year' because that system doesn't use a year 0 (unless you put the birth of Christ at 1 January 0).

By the way, you seem to imply (earlier) that 99% of people don't acknowledge the year 0. But most people will first learn about the number system (with a 0) and then maybe later learn about the leaving out of the 0 by some systems. I was in my thirties when, to my surprise, I learned about this. It's like with the way kids learn language. First they learn the logic and then the exceptions, thus for a while using words like 'ringed' in stead of 'rang' and the like. DirkvdM 08:04, 15 October 2005 (UTC)[reply]

When a user's date format preference is set to ISO format (YYYY-MM-DD), 1 BC becomes -0000, not 0000. That is not necessarily an error but is an idiosyncrasy. In any case, it cannot be 0 because ISO 8601 requires at least four digits for any year (the option of just the last two digits was deleted from the 2004 edition). On the other hand, astronomical dating does permit year 0, without requiring four digits. Of course, all earlier astronomical years are shifted by one: −1 is really 2 BC (but historians never use a year zero so when they use negative years they regard −1 as 1 BC).

A disconcerting ISO 8601 requirement which cannot be tolerated in Wikipedia is the requirement that all dates, including those before 1582, be in the Gregorian calendar. This would produce havoc with historical dates because almost all sources use Julian calendar dates before 1582. Thus Wikipedia's date preference does not change any month/day when using the ISO date preference. — Joe Kress 05:21, 19 October 2005 (UTC)[reply]

Adjectival use of dimensions

Someone just changed "a 100-millimetre (4-in) pipe for 10 miles (16 km)" to "a 100 millimetre (4 in) pipe for 10 miles (16 km)". I was taught that compound adjectives are hyphenated: "4 in" means "four inches", "4-in" means "four-inch". Which is correct? —Michael Z. 2005-10-20 18:44 Z

I can't comment on the inches and miles, but I'd expect "a 100 mm pipe for 16 km" to see millimetres and kilometres written in full looks strange to me and the hyphen looks decidedly wrong. I don't know of any rules for this, that's just how it looks to me. 192.85.50.1 12:32, 21 October 2005 (UTC)[reply]

Most style manuals recommend not hyphenating abbreviations but do recommend hyphenating compound adjectives. Some examples:

a 100-millimetre (4 in) pipe for 10 miles (16 km)
a four-foot-tall statue
a 100 m dash

—Wayward ^Talk 12:47, 21 October 2005 (UTC)[reply]

I guess in running text writing out "hundred-millimetre pipe" would be preferable. Would one ever abbreviate this "100-mm pipe", or always "100 mm pipe"?

In many articles about artillery and tanks this can appear many times on a page, and there isn't a clear preference. Many editors and respectable publications write "125mm gun" without a space, but others dislike this. —Michael Z. 2005-10-21 15:04 Z

Ahem. The text was discussed many times before it went in the Manual without a hyphen. Then a hyphen was added without discussion on 20:44, 14 September 2005. Thus whoever changed it back was actually correcting an undiscussed change in style. Just look at the history.

We discussed the hyphen several times. We also looked at what is said in other styleguides. There is currently no Wikipedia policy. Anyone that would like to create a Wikipedia policy should read the previous discussions. Please look in the recent archives of this talk page. Bobblewik 17:32, 24 October 2005 (UTC)[reply]

Am I wrong in remembering the earlier discussion as dealing specifically with numeral and unit symbol combinations, and not with spelled out words for which the rules can be and often are different? Gene Nygaard 21:53, 24 October 2005 (UTC)[reply]

Yup, B., I remember putting that hyphen in, with an edit summary explaining why I thought it was correct. I vaguely remember some related discussion, but not the details—couldn't find it when I looked, and perhaps I'm remembering something else.

The example cited was placed to demonstrate the use of units in running text vs. tables, and notation of source units vs. converted units. It's confusing because the two examples of measurements are used one as an adjective and the other as a noun, but there was no indication that this was meant to be a guide for those two different uses, or that that was even considered. I thought it hadn't been, and explicitly made an annotated change that attempted to resolve this. Editors' usage is all over the place, now there's a revert war which has finally removed the distinction instead of explicating it.

If there's no policy regarding this question, then how can you say am I creating new policy by changing what's there? By this reasoning, wasn't whoever originally wrote it the other way guilty of creating a new policy without agreement?

Guess I'm just a big dope. When I have some time on my hands, I may delve into the talk archive and see if I can find the discussion you're alluding to. But since it was inconclusive, I think I'll just keep it simple and discuss the pertinent facts here now.

Wayward's suggestion looks pretty good to me. I would add that in a tank history article where it appears many times, a contraction of the space like "100mm gun" reads quite smoothly, but "100 mm gun" seems awkward to me every single time. I start reading "hundred millimetres gun", oh, oops; "hundred-millimetre gun". I've also tried out pedantically sticking to hyphenating adjectives, but "100-mm gun" doesn't look so hot either.

I'd like to agree on a set of acceptable guidelines, because it's difficult enough to read an article with dozens of letter-and-number fragments, like "the Pzkw-IV with its 88, and T-34-85 tanks of 1943 with 76.2mm guns and 60 mm of armour," etc. etc., having to read three different notation formats. It's time-consuming and difficult just to determine what is already in use in a long article like this before editing, and usually there are two, three, or more inconsistent formats already there, some merely differing in style, and some definitely incorrect. —Michael Z. 2005-10-25 05:09 Z

I understand that you would have liked a hyphen. There is nothing wrong with starting an informed discussion again about Wikipedia having a hyphen style. As far as that example is concerned, JimWae has adjusted it so that it demonstrates the bullet points without confusing the issue with hyphens. That seems good to me. Regards Bobblewik 08:46, 25 October 2005 (UTC)[reply]