Wikipedia talk:Manual of Style/Dates and numbers

I'm working on a {{val}}-like template

It would solve the problems of {{val}} with numbers with many digits, although users would have to specify breaks by hand. For example {{User:A. di M./margins|−2.002|319|304|3622(15)}} would yield −2.0023193043622(15).

It could also have other uses, too. See more examples on User:A. di M.#Testing /margins. The template itself is at User:A. di M./margins. I've put it in my userspace rather than in the template space because I'm not sure about how to name it.

(I haven't included support for automatic handling of exponential notation, uncertainty, etc. yet, but I might add it later. As for the margin size, I've used 0.25em for consistency with what {{val}} does, but personally I would use smaller margins, e.g. 0.2em.) --A. di M. (talk) 11:02, 5 February 2009 (UTC)

• This is great. The advantage is that it can handle big values, which Val can not, and it can handle values that Val generates rounding errors on. I’ve been working on [Wikitech-l] with developers trying to find a solution to the Val problem (so far, to no avail). The only trouble with this new template is it needs to have big bold instructions to users on how to properly delimit values per ISO / NIST / BIPM convention, which never leaves a single dangling digit; you either have two, three, or four digits in the final group as a consequence.

  As for the em-width, it is a tradeoff; different editors see different widths on their hardware/software platforms.

  Are you going to be doing the scientific notation aspect too? Greg L (talk) 23:22, 6 February 2009 (UTC)

There's no template template:thinspace yet that simply replaces each "|" with a thinspace; that would be nice, for when people want to use thin spaces. - Dan Dank55 (push to talk) 15:26, 7 February 2009 (UTC)

Done. For example, now {{thinspace|J.|R.|R.}} Tolkien displays J. R. R. Tolkien. --A. di M. (talk) 21:23, 7 February 2009 (UTC)

A bug-free version of {{val}} could be implemented using the string-manipulation functions in mw:Extension:StringFunctions. That extension is not installed (see Special:Version), and I don't know where to ask to get it installed. —AlanBarrett (talk) 14:11, 9 February 2009 (UTC)

Val is now fixed

• (*Whew*) I just got through with a full month of interacting (cajoling, pleading on my worn knees) with the developers who provide the parser functions that template authors rely upon. mw:Extension:StringFunctions is buggy and hasn’t been released. Besides, it would still be lacking a couple of features necessary to make a {{val}}-like tool. Really, the string functions required for {val} would be extraordinarily easy for a skilled developer to code—perhaps a half-evening of work. The problem lies with intangibles like “setting precedent” by making a software tool every time we whiney-ass editors and template authors have a wild notion of what we *think* might be valuable to Wikipedia; the developers have their own ideas on important matters like these.

  Now that I’ve done my prima dona-bashing on developers, one of them, Robert Rohde, fixed some behind-the-scenes math business that {val} relies upon so it no longer suffers from its seemingly random rounding errors. In other words: {val} now works!

  By “fixed”, I mean that {val} now is perfectly predictable. And, though predictable, {val} is not perfect. According to Robert, {val} is good only up to 10 significant digits. I haven’t done elaborate experiments, but I see that it can do twelve-digit tasks like this:

1.23456789012 (ends with 12)

1.23456789011 (ends with 11)

1.23456789013 (ends with 13)

1.23456789014 (ends with 14)

1.23456789015 (ends with 15)

1.23456789016 (ends with 16)

1.23456789017 (ends with 17)

1.23456789018 (ends with 18)

1.23456789019 (ends with 19)

Note that {val}’s math-based delimiting technique means it still can’t handle tasks like {{val|1.2300|(20)|e=-23|u=kg}} because the trailing zeros disappear and you just get 1.2300(20)×10⁻²³ kg. At least this is consistent behavior. When one encounters a value that ends with a zero, they can use Margins, by A. di M.

Although {margins} won’t ever choke on values that end with zeros or which have loads of digits, it needs to be used with care by editors to ensure the values are delimited per ISO/NIST/BIPM convention, which never leaves a single, dangling digit. Thus, the last group of digits must always have two, three, or four digits. And, last I checked, authors using {margins} to make scientific notation with negative exponents must remember to not type a keyboard hyphen and to use the true minus sign (−) from the Insert pallet so it looks good when superscripted.

Admin fix needed

BTW, this means someone can temporarily unlock MOSNUM and correct the last sentence of the the “Decimal points” passage on {val} to read something like this:

Note that {{val}} will not work with values that end with a zero (which can happen when uncertainty is expressed), and may not properly work beyond about 10 to 12 significant digits.

Also, at the “Uncertainty” section, it can be revised to something like this:

{{val}} is meant to be used to automatically handle all of this. Note that {{val}} can not handle digits with more than about 10 to 12 significant digits and can not properly display signficands that end with a zero. Thus, if you have a value that should display like 1.452800(25) × 10⁻²³, {{val}} will generate 1.452800(25)×10⁻²³.

Note that I tested {val} to 13 digits, and it works most of the time, but—randomly—it will generate error codes about 20% of the time.

Greg L (talk) 22:23, 9 February 2009 (UTC)

Revised Decimal subsection's line goes over margin

I don't know what is the optimal solution, but, depending on your screen, resolution, text size and sidebars, you may see the line that includes the dozen significant digits and breaks go over the right end of your screen. (I use the "mini-browser" sidebar in Netscape Navigator 9.0.0.6 for my Watchlist.) It's possible that the "nowrap" required by the example means that this problem isn't fixable, but perhaps some administrator (since the page is fully protected) could insert an appropriate break, unwrap or blockquote to keep the text within the margins. Thanks.—— Shakescene (talk) 01:06, 11 February 2009 (UTC)

Epiphany behaves like that too. But this works correctly. Maybe that's a problem with using the thin space character within "nowrap" spans; if this is the case, they might be deprecated in favour of the new template {{gaps}}. --A. di M. (talk) 20:35, 11 February 2009 (UTC)

• That was a half-day-long bug due to unclosed <spans>. It was quickly fixed and {{val}} is now bug-free. That little incident lead me to quickly make this Val sandbox to check for a wide variety of template behavior. If you get two error flags in the top section of the page, append ?action=purge as a suffix to the end of the URL and hit [enter]. This occurs when the server that fed the request has math settings that can only handle up to 12 digits. If you purge/refresh and the error flags go away, then your request was served by a 14-digit-capable server. Eventually, as they replace old servers in Wikipedia’s server farm, the percentage of time that this happens will go to zero (a matter of weeks). Then, only the 15-digit numbers on the page should produce error flags.

  If you want to speed up the purge iteration time, you can try using Val microsandbox Greg L (talk) 03:36, 18 February 2009 (UTC)

Free form way of specifying dates

Readers of this thread may be interested in examining the documentation for {{start-date}}. This is an example of a date-time template that imposes fewer restrictions described by opposing camps in previous date formatting debates. It addresses the numerical accuracy interests such as those of the microformat / metadata camp interested in accurate ISO8601 dates, and those interested in readability, imposing far fewer restrictions concerning formating or using templates such as for Julian dates precisely. Examples:

Start-date & End-date usage (colors for emphasis only):

Sample below displays 7 December 1941 (1941-12-07), and microformat date: 1941-12-07TZ {{start-date|7 December 1941}}

Sample below demonstrating how days, timezones and hours, minutes and seconds can be shown. (Order often not important). Displays 5:43PM HST, December 7, 1941 (1941-12-08UTC03:43), and microformat date (corrected for UTC): 1941-12-08T03:43Z {{start-date|5:43PM HST, December 7, 1941}}

Sample below demonstrating use of links with dates. Displays links to day of month and year pages. December 7, 1941 (1941-12-07), and microformat date: 1941-12-07Z {{start-date|December 7, 1941|[[December 7]], [[1941]]}}

Sample below demonstrating use of Julian calendar dates. Displays 9 June [O.S. 30 May] 1672 (1692-06-09), and microformat date: 1692-06-09Z {{start-date|9 June 1692|{{OldStyleDate|9 June|1672|30 May}} }}

I have proposed that the old way of specifying dates in wonky error prone forms be deprecated. Specifically, this sort of template is completely unnecessary: Eg:{{Start date|1941|12|7|18|Z|df=yes}} might seem to be the correct syntax for the december 7 example above, but the user must do their own conversion to UTC, and they can't format the way they like to. They also may run into bugs. The above example displays as:

18:0Z, 7 December 1941 (1941-12-07T18:0Z)

I propose that a new family of templates that allow contributors total freedom in formatting dates, using links or templates, which simultaneously allowing the precision folks such at the microformats/ ISO8601 crowd to express dates in their gregorian oriented with the accuracy they desire. This particular template correctly generates ISO8601 date/times between -6999 BC to 6999 AD in natural language and properly handles time zones and date arithmetic in natural forms (eg "february 08, 2009 next sunday" delivers 2009-02-15). Most of the magic is not in the template but an underlying wikitext function, but the point is that in many if not most cases there is no longer any technical need to use wonkey templates requiring separate parameters for year month and days as many have advocated in the past. If anyone is interested in a customized form of this free form template or have ideas for it being even more simplified or able to perform additional functions, please contact me.

Users interested in verifying the ISO values emitted by these examples may see them by turning off CSS in their browsers, (eg: in Opera, use the view Author versus user mode and set one mode to no style sheets). -J JMesserly (talk) 08:50, 9 February 2009 (UTC)

As has already been pointed out to you elsewhere, the example which displays as "18:0Z, 7 December 1941" is not in one of the formats listed on {{Start date}}'s documentation. "GIGO" applies. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:09, 9 February 2009 (UTC)

That's fine. As I asked before, if the example is wrong, then what is the correct way of expressing it using the old {{start date}} template, and why should it be so complicated for users to read and understand? {{start-date}} is a different approach that many contributors will find much more flexible and intelligible for their editing requirements. Of course, the MOS community can make their assessment. It is true this is a new untested template and there may be bugs to fix with it. I am ready to address the bugs that come up, so if you find any, please report them on the template's talk page and I will get to them as soon as possible. -J JMesserly (talk) 22:58, 9 February 2009 (UTC)

I don't recall seeing you ask that before; but {{Start date|1941|12|7|18|00||df=yes|-10:00}} returns 18:00, 7 December 1941 (-10:00) (1941-12-07T18:00-10:00). If you have an issue with that, I can only reiterate, once again, that you have been invited to raise them on that template's talk page. You appear to still not have done so. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:08, 10 February 2009 (UTC)

(undent) The issue I raised here is obvious from your example. The syntax is needlessly unintelligible and complex. I propose that the Manual of style state that human readable templates are preferred to that are less human readable. -J JMesserly (talk) 17:45, 10 February 2009 (UTC)

That's not a MOS issue, but feel free to take that to WP:VPP. I suggest you first make {{Convert|one and three-quarter inches|cm}} work. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:42, 10 February 2009 (UTC)

A surprising assertion. Your proposal at Bot requests is to convert large numbers of intelligible dates into the unintelligible form above. Let's see if others agree if readability for editors is not a relevant issue for MOS to address. -J JMesserly (talk) 18:53, 10 February 2009 (UTC)

MoS is concerned with article content, not the internal format of templates. The proposal at BOTREQ, which already has consensus and would already be completed if the bot operator concerned had not suffered a bereavement, is to replace prose dates with a widely-used-by-consensus template, emitting both hidden microformat properties, also agreed by consensus, and an equivalent prose date for human readers. If you wish to prevent the use of {{Start date}}, please demonstrated consensus by nominating it for deletion. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:59, 10 February 2009 (UTC)

P.S. Here is an example of the change requested in the BOTREQ; note that the text visible on the page does not change. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:08, 10 February 2009 (UTC)

Andy, the Hudson's Bay Company article contains the {{Infobox Company}} template, which the proposed bot would act upon. Please explain what the result would be, both in terms of the new parameter, and in terms of the microtext that would be emitted, for the parameter foundation = May 2, 1670. --Gerry Ashton (talk) 20:33, 10 February 2009 (UTC)

If I could step in here Gerry, the microformat date emitted would look like this: 1670-05-02. The old template syntax would be {{start date|1670|5|2}} = "May 2, 1670 (1670-05-02)". A bigger question is what he does with Bacardi, which also uses {{Infobox Company}}

foundation = [[Santiago de Cuba]], [[Cuba]] ([[February 4]], [[1862]]) 

With the new template, it would be {{start-date|February 4, 1862|[[February 4]], [[1862]]}} Andy, what do you propose your concensus of one bot do to Barcardi's foundation date? What will the wikitext for the template look like? -J JMesserly (talk) 04:41, 11 February 2009 (UTC)

If J JMesserly is right, and the bot actually replaces "May 2, 1670" with {{start date|1670|5|2}} then the HTML source sent to the browser will be

May 2, 1670<span style="display:none"> (<span class="bday dtstart updated">1670-05-02</span>)</span>

This is wrong, because microformats, like ISO 8601, are always in the Gregorian calendar, and the founding date of the Hudson's Bay Company is May 12, 1670, Gregorian. --Gerry Ashton (talk) 05:06, 11 February 2009 (UTC)

You can verify the answer above with the Opera browser by going to View.Style.User Mode, the template emits Gregorian date of (1670-05-02) as you feared. Of course the new template format is trivial: {{start-date|May 12, 1670|May 2, 1670}} = May 2, 1670 (1670-05-12), which produces the correct date normalized into gregorian calendar form had it existed back then: (1670-05-12Z). (Note to self- got to get rid of the superfluous Z when no time specified) BTW- I am pretty good at Bots and would be happy to make the bot runs so that Julian dates would be expressed correctly in ISO8601. Of course, this would require use of the newer template. I am pretty sure I can dig up the code that does Julian to Gregorian conversions, but we would do small trial runs to spot check it before going whole hog on everything. -J JMesserly (talk) 05:17, 11 February 2009 (UTC)

I propose that the BOT run ignores dates before (IIRC) 1750. Later, once {{T;|Start date}] is changed to emit the correct Gregorian date, another run could be made. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:22, 11 February 2009 (UTC)

George Washington's family bible recorded his birth as the "11th Day of February 1731 / 2".[1] We now state the first President's birth date as February 22, 1732. The old style dates were often expressed as "1731 / 2" because the New Year could be March 25 or January 1. Happy birthday George. -- SWTPC6800 (talk) 05:39, 11 February 2009 (UTC)

By the way, for those concerned about this normalization of Julian dates into Gregorian values- these microformat emitted ISO values are not necessarily seen by users- it is an interchange format. A historical application would presumably know very well that it would have to convert the Gregorian distored ISO date back into the correct Julian form before displaying it. -J JMesserly (talk) 05:47, 11 February 2009 (UTC)

Microformats use ISO 8601. The standard is very clear about that. What I've seen of the microformat standards are equally clear. If a historical application sees a microformat, it knows that the date is (A) Gregorian, (B) a mistake, or (C) a damn lie.

As for using a bot, how is the bot supposed to figure out what calendar the date is in? It depends on the time period and the location. If the location is someplace that observed neither the Julian nor Gregorian calendar, it's anybody's guess what calendar was used. --Gerry Ashton (talk) 06:08, 11 February 2009 (UTC)

• REQUEST FOR CLARIFICATION: Is this a discussion/proposal to replace our currently 'layman' dates with "computer nerd" dates throughout WP? Ohconfucius (talk) 10:03, 11 February 2009 (UTC)

• Sounds like a recipe for chaos. We have a very good system now—basically a binary one, both formats readily understandable by everyone in the world. The community takes a conservative line now on needless complications in date formatting. Tony (talk) 11:46, 11 February 2009 (UTC)

Ohconfucius: the Bot request referenced earlier would convert numbers into the form of the example above by PigsontheWing: {{Start date|1941|12|7|18|00||df=yes|-10:00}} and would eliminate any date links they used. The counter proposal is to use a less nerdy alternative template that would express the date in human readable form. The template with the dashes is the new template. The templates with no dashes is the older more numerically oriented template.

Tony1- The existing system is good, and the principle of needless complication of formatting is a good one. What is driving this change request to either accept {{start date}} or the alternative {{start-date}} is admittedly speculative at this point. You no doubt have seen those world icons with coordinates popping up on many pages. Today using browser toolbar addons, and next year as browser standard functionality, users visiting these pages will see a map button activate- could be (google maps/ yahoo maps/ name the user's favorite selected map site). You click the button, and suddenly you are looking at the 1000 foot view of the Parthenon. Pretty cool. The requirement to do this is for wikipedia to emit dates using standard templates that emit the metadata, and some of these make the wikitext markup look pretty nerdy. My proposal is to use a format with the least Frankenstein effect while also emitting the needed dates. Now, I said, admittedly speculative. Here's why. Today, there is no applications like Yahoo or google maps that show people times and locations in their historical context. But they could. Imagine a google earth where you could navigate in the fourth dimension of time. You could visit the battlefields of WWI, and see photos of the carnage and the battlefields, see 3D models of the trenches, etc. So just as you can click on the activated map icon in your browser, you could click on an event and see its time and location depicted on their site. Why should we do anything before these sites materialize? Chicken egg problem. You have to have data to make such applications anything more than toys. No one wants to provide the data until the applications materialize. What I am proposing is a template that emits the needed metadata (microformat) dates with the hope of enhancing Wikipedia's role in being the preeminent source of free and accurate knowledge that these leading edge applications use. I personally come at this from the history enthusiast point of view- I don't care about microformat technology in particular, but I am willing to go with anything that works, and it does. I should also note that hours and minutes are not supported in current templates and this is relevant for some events. For example, JFK assassination, or military events- first naval engagement between Japan and US in WWII outside the entrance of Pearl harbor at 8:43am Hawaii Standard time on December 7, 1941. -J JMesserly (talk) 17:33, 11 February 2009 (UTC)

There are already applications which parse hCalendar microformats. For that reason if no other (and there are other, good, reasons) it is important that the microformat metadata which we emit is valid, accurate, precise, but not overprecise. Wikipedia already has templates which emit dates for use in microformats, and you have been invited time and again to raise any issues with them on their talk page, but have still not done so. Perhaps you should leave these matters to people who do care for microformat technology; and therefore take great care to apply it correctly. As to your claim that "hours and minutes are not supported in current templates"; JFK was declared dead at 1:00 p.m., CST (19:00 UTC); {{Start date|1963|11|22|19|00||-07:00 renders as 19:00, November 22, 1963 (-07:00) (1963-11-22T19:00-07:00) and emits 1963-11-22T19:00-07:00; alternatively {{Start date|1963|11|22|13|00||}} renders as 13:00, November 22, 1963 (1963-11-22T13:00) and emits 1963-11-22T13:00.  () is currently transcluded around 10,000 times, and has been in use - without any significant complaints - since July 2007. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:39, 11 February 2009 (UTC)

Folks did Julian dates wrong for a long time too. Inertia of bad practice is not argument for its needless perpetuation. The assertion appears to be that is that the MOS community has no place in making a statement that wikitext markup not be needlessly complex. I suggest that it is precisely their duty to do so, because errors are much more difficult to correct if they are needlessly complex. Lack of clarity with data encoding leads even engineers to make mistakes of assuming miles when the units were kilometers, resulting in a billion dollar pile of junk on mars. Consider the following markup for the time JFK was died, reported as approximately 1pm CST:

	wikitext	display	microformat
old	{{Start date|1963|11|22|19|00||-07:00}}	19:00, November 22, 1963 (-07:00) (1963-11-22T19:00-07:00)	(1963-11-22T19:00-07:00)
new	{{start-date|November 22, 1963 1pm CST}}	November 22, 1963 1pm CST (1963-11-22UTC19)	(1963-11-22 T19Z)

Besides the ease in coding and understanding the time, note the glaring difference that should be obvious to affeciandos of time. The first case due to its obscurity and non reliance on robust system support for time calculation the editor did not make the correct adjustment for it not being daylight savings time. Time zone adjustment is what the meaning of the -7:00 is, and for Dallas, it is either -6:00 for winter, or -5:00 for summer as explained in the upcoming link. Actually that's not the only error this hypothetical contributor has made, the correct microformat expression of this time with the time zone adjustment as the editor is attempting to do is actually 1963-11-22T13:00-06:00, and their syntax in the wonkey {{start date}} template should be changes to reflect that (for explanation see ISO time zone syntax. Everyone makes mistakes, even microformats enthusiasts. So how can we expect content experts to understand this stuff? Who is going to spot that error with the syntax in such a unnecessarily complex form? I am interested in exposing this kind of information, and it is true I am not religious about one particular technology or another. I study what a particular format requires, and I am good at writing code that adheres to standards. I just don't see any need for the requirements of the microformats folks to make it more difficult for contributors at WP to spot and fix errors. -J JMesserly (talk) 20:57, 11 February 2009 (UTC)

Can we have a specification for this design at: Wikipedia talk:Manual of Style (dates and numbers)/Specification for 'son of autoformatting'? Lightmouse (talk) 12:54, 11 February 2009 (UTC)

There are two competing designs being discussed: One family of templates using dashes in the name, and one family that doesn't. I champion the newer templates with dashes in the template name eg: {{start-date}}. These newer, templates takes no sides in autoformatting questions. Do you require a specification to that effect? The contributor is in control of format and can choose to use auto formatting templates in the second parameter or not. All the template cares about is the accuracy of the date-time in the first parameter. This is the value exposed to the outside world, and if the second parameter is present, then the only people that see it is those with CSS turned off. The old template {{start date}} does do autoformatting, and so I leave it to the champions of that template to respond on their position regarding autoformatting. -J JMesserly (talk) 18:00, 11 February 2009 (UTC)

{{Start date}} can have auto-linking/ formatting of dates, or not; whatever the community decides. It used to Auto-link dates, but this was removed recently (not by me). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:42, 11 February 2009 (UTC)

Moratorium on futher conversions to use older template:Start date

Given the example that even one of the authors of the template {{start date}} forgot how to use it (see above example on date of JFK death) due to its obscure rules, I propose that there be an indefinite moratorium on any future bot runs converting articles from use of intelligible dates to the far less human readable form that {{start date}} uses. Unnecessarily complex encodings present obstacles to contributors to Wikipedia. As shown, they can present obstacles even to those who are expert in their use. Since there are templates that achieve the same goal and are far more readable, there is no need for conversion to the old {{start date}} template. Presumably if no one comments, this principle is recognized as well supported by the example above. -J JMesserly (talk) 15:39, 12 February 2009 (UTC)

Completely agree. Such a template should not be used if it can only be understood by persons of an IQ greater than ten. Ohconfucius (talk) 16:13, 12 February 2009 (UTC)

I agree for a different reason: the template is incapable of working with non-Gregorian dates, and it is difficult for a bot to tell what calendar a date is in. --Gerry Ashton (talk) 16:30, 12 February 2009 (UTC)

I have already told you that I suggest not converting non-Gregorian dates. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:03, 13 February 2009 (UTC)

Yet again, J JMesserly resorts to falsehood to further his arguments. I "misnunderstood" nothing; I merely neglected to amend the text copied from the "-07:00" example on [[2]]. {{Start date}} is already used in over 10,000 articles. J JMesserly has been repeatedly invited to raise any concerns with {{Start date}} on its talk page (as indeed any editor may), but has yet to do so. Though I created that template some time ago, I am not the author of its current code.And consusus-buiilding is Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:01, 13 February 2009 (UTC)

I apologize for any offense taken about my mischaracterisation of the error. Whatever the reason for the error, if even an enthusiast can make such an mistake when making his case for a template, then this is strong evidence that templates with obscure encoding rules should not be used when substitutes are available. Human readability is a strong principle in standards these days, and it seems to me this principle ought to be a general MOS guidance for all wikitext. For now, I propose that the MOSNUM guidance specifically make Tony's "needless complications" principle explicit as it applies to use of date templates when more human readable substitute templates are available. Any objections to this addition to the page? -J JMesserly (talk) 21:10, 13 February 2009 (UTC)

To date, there have been no arguments opposing the moratorium. -J JMesserly (talk) 23:24, 14 February 2009 (UTC)

…apart from all those in my responses to J JMesserly's misleading FUD on WP:BOTREQ. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:02, 15 February 2009 (UTC)

You oppose the moratorium? The argument at BOTREQ was that the bot run was uncontroversial. Clearly that is not the case. What is your argument in favor of the old {{start date}}? I think it is fair to represent opinion here that it needlessly complicates wikitext representation of dates. Your response? -J JMesserly (talk) 23:25, 15 February 2009 (UTC)

My response is already at WP:BOTREQ. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:27, 15 February 2009 (UTC)

(Quote Copied from BOTREQ by J JMesserly)::There is no controversy. Please avoid unnecessary drama. There is no obscurity and the template is not "error prone"; unlike the supposed alternative. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:06, 13 February 2009 (UTC)

If this is an out of context quote, then perhaps Pigsonthewing could add the additional context. How it is accurate on the BOTREQ page to represent this issue as one with no controversy (when multiple contributors here have stated the old template is unnecessarily complex), or asserting that the old template is not obscure or error prone without countering the arguments presented here? -J JMesserly (talk) 21:40, 17 February 2009 (UTC)

{val} wording update

{{editprotected}} After a couple days of troubleshooting and e-mailing back and forth with the developers, it turns out that {{val}} has inconsistent results with 13 and 14-digit significands because roughly 20% of Wikipedia’s servers are old ones running Fedora. In a matter of weeks, those outdated servers will all be replaced so all are like the new ones, which are running Ubuntu. Once that happens, {val} will reliably handle 14-digit numbers. In the mean time, it can only properly generate 12-digit numbers 100% of the time. User:Dragons flight, who is a developer, has volunteered his efforts and done a fabulous job revising the number-crunching engine that {val} uses. Val now requires ten times less processor cycles (overhead) to render numbers than it previously did, and it now handles significands that end with zeros. Thus, values with uncertainty, such as 1.2345678900(32)×10⁻²³ kg properly display without dropping off the (seemingly) non-significant digits.

In the mean time, MOSNUM needs to be updated with the proper advise regarding {val}…

---

At Decimal points, please replace the last paragraph with this:

• For numbers with more than four digits after the decimal point, these can be separated (delimited) into groups of three by thin spaces protected by {{nowrap}}, or with {{val}}, which obtains the same appearance using margins instead of thin space characters. Per ISO convention (observed by the NIST and the BIPM), there must never be a single, dangling digit so the last group must always comprise two, three, or four digits. Thus, the progression is as follows: 1.123, 1.1234, 1.12345, 1.123456, 1.1234567, 1.12345678, 1.123456789, etc. Note that {{val}} handles the grouping details automatically, e.g. it knows to take "0.1234567" and generate 0.1234567 (with a four-digit group at the end). Due to server-related issues, {{val}} can reliably handle no more than 12 significant digits. Optionally, truncated representations of mathematically defined constants with fifteen or more digits after the point can use groups of five digits (e.g. "e = 2.71828 18284 59045…"); in this case, the number of digits used between the point and the ellipsis, being arbitrary, should be a multiple of five (or of three, if three-digit groups are used).

---

At Notations, add this bullet point at the top:

• The template {{val}} can be used to facilitate the generation of scientific notation. It is a flexible tool that allows editors great latitude and should must have arguments (each section between the vertical bars) properly entered in order for it to generate output that is compliant with formating conventions.

---

At Uncertainty, replace the last paragraph with this:

• The template, {{val}}, may be used to automatically handle all of this.

---

I can see that this entire section covering big numbers, decimal points, delimiting, etc., needs to be revised and harmonized. That is for later after MOSNUM is no longer locked down. Though editors will have to hunt for relevant information, at least what they find will be correct. Greg L (talk) 01:25, 12 February 2009 (UTC)

•  Done per noncontroversial documentation update. --MASEM 02:07, 12 February 2009 (UTC)

• Thank you much, Masem. Greg L (talk) 02:20, 12 February 2009 (UTC)

Ahem. <nitpick>Actually, BIPM doesn't say "never". In the SI brochure, they say "However, when there are only four digits before or after the decimal marker, it is customary not to use a space to isolate a single digit. The practice of grouping digits in this way is a matter of choice; it is not always followed in certain specialized applications such as engineering drawings, financial statements, and scripts to be read by a computer." The examples in the margin read "either 3279.1683 or 3279.1683". While I think that allowing the latter format would only make Wikipedia more messy than it already is, we shouldn't misquote the BIPM (even if that is not a quote), so "... there must never be a single, dangling digit so the last group must always comprise ..." should be replaced with "... it is customary not to leave a single digit at the end, so that the last group comprises ...". (Also, the 2008 draft of ISO 80000-1 says "If the groups are separated this shall be done consistently, i.e. the first group in the integer part and the last group in the decimal part may contain one, two, or three digits, but not four digits", but fortunately it hasn't been approved yet; that is just one of many unreasonable requirements such as "Numbers shall be printed in roman (upright) type, irrespective of the type used in the rest of the text", which would declare the '74 Jailbreak in {{AC/DC}} incorrect.) </nitpick> Also, Shakescene and I have noticed that using "thin spaces protected by nowrap" can produce silly output (see #Revised Decimal subsection's line goes over margin above), so it should be deprecated.

So I suggest to replace the above with:

• For numbers with more than four digits after the decimal point, these can be separated (delimited) into groups of three. Per ISO convention (observed by the NIST and the BIPM), it is customary not to leave a single digit at the end, so that the last group comprises two, three, or four digits. Thus, the progression is as follows: 0.123, 0.1234, 0.12345, 0.123456, 0.1234567, 0.12345678, 0.123456789, etc. The template {{val}} can be used to handle the grouping details automatically, e.g., {{val|0.1234567}} generates 0.1234567 (with a four-digit group at the end); but due to server-related issues, {{val}} can reliably handle no more than 12 significant digits. In cases where {{val}} fails, the template {{gaps}} can be used, but the position of the gaps has to be specified by hand.
• Optionally, truncated representations of mathematically defined constants with fifteen or more digits after the point can use groups of five digits (e.g. e = 2.718281828459045…); in this case, the number of digits used between the point and the ellipsis, being arbitrary, should be a multiple of five (or of three, if three-digit groups are used).

--A. di M. (talk) 10:50, 12 February 2009 (UTC)

• Agreed; “never” was wording I should not have used. Your wording is very logically precise. Of course, we could have always used the words “on Wikipedia, editors should not” in order that we have a consistent house style. Thanks A. di M.. Greg L (talk) 22:00, 12 February 2009 (UTC)

  P.S. Here at leŭksman: Your donations at work: new servers for Wikipedia, is something that relates to how {val} will one day soon work consistently at 14 digit resolution. Greg L (talk) 22:04, 12 February 2009 (UTC)

  But isn't the whole MOS about what Wikipedia editors should and should not do? :-) --A. di M. (talk) 22:43, 12 February 2009 (UTC)

• Certainly. The difference lies in the subtleties of the wording. Note our *advice* on percentages:

The [percent] symbol is unspaced (71%, not 71 %).

That is quite blunt. One could just as easily have made a more factual statement about it that was more suggestive via a bully pulpit:

According to the BIPM’s SI Brochure–5.3.7 Stating values of dimensionless quantities, or quantities of dimension one, the BIPM is clear about the SI writing style with regard to the “%” symbol; it states as follows: “When it [the percent symbol] is used, a space separates the number and the symbol %.” This calls for 75 %, not 75%. However, it customary to not do so.

Quite rightly, we flout the rule of the SI and simply follow current literature on this issue. And, quite rightly, we make a very definitive statement that one does not put a space between the numeric value and the percent symbol; we have a consistent, non-awkward-looking house style as a result. Now…

I agreed with your proposed wording regarding {val} and digit grouping. I think your wording is better by being more accurate without opening up Wikipedia to an unnecessary hodgepodge of number formats.

If you are trying to make a broader point about the purpose of MOSNUM and the extent to which editors should (or must) comply, I don’t feel I can contribute to this tangent. Perhaps this discussion belongs on one (or both) of our talk pages. I think, as a practical matter, MOS and MOSNUM are style guides that must have flexibility on certain points and be more specific and definitive for others. Greg L (talk) 00:40, 13 February 2009 (UTC)

←My point was that "On Wikipedia, editors should" is redundant wording serving very little purpose, as it could apply to most of the MoS. (Anyway, you agree with my proposed wording, so this is moot.) As for percentages, I prefer the current, "blunt" wording. Most users will have never heard of the SI brochure nor care about what it says. Most users will be used to seeing unspaced percent signs. And I wouldn't be surprised if there were style guides recommending not to put a space before % signs. So the "blunt" statement perfectly serves its purpose; the "more factual statement" with "a bully pulpit" would only bloat the MoS text even more. (There already are such statements as "Use discretion when it comes to using scientific and engineering notation. Not all values need to be written in it (e.g., do not write the house was 1.25×10² y old, but rather the house was 125 years old in 2008 or simply the house was built in 1883)", I wander how <sarcasm>many</sarcasm> people would write "the house was 1.25×10² y old" if the MoS didn't tell them not to do that.) Anyway, I don't care about that too much, arguing on the wording of some style rule when everyone agrees about its content is quite a waste of time.

Next question is: Who can afford and is willing to buy the new ISO standard when it is officially published in order to decide whether the "Per ISO convention (observed by the NIST and the BIPM) ..." above should be replaced with "Per BIPM convention, also observed by the NIST, ..."? :-)

English Style Guide: A handbook for authors and translators in the European Commission 4.14: “In English, the sign is always closed up to the figure. Note that section 6.4 of the Interinstitutional Style Guide requires a space before the sign in texts for official publication. However, this requirement need not be observed by authors or translators as the space will be inserted automatically at the publication stage.” See also: "Percent_sign#Spacing". <rant>Sounds like the frog eaters are trying to impose the typography of their *cough* lan... *cough* ...guage *cough* to the whole worldthose at BIPM were more familiar with French than English typography, and maybe they didn't just realize that the latter has different rules. IIRC, they used to only allow the comma as a decimal point regardless of language, before they realizing that in English everyone used the period and eventually allowing it.</rant>

--A. di M. (talk) 10:50, 13 February 2009 (UTC)

• We are in agreement. I wasn’t advocating the bloated version. Greg L (talk) 04:44, 14 February 2009 (UTC)

• Does a change still need to be made to MOSNUM? Can you verify what that change has to be below? --MASEM 12:19, 14 February 2009 (UTC)

The wording immediately below the {{editprotected}} tag above (same instruction as now w.r.t. placement of gaps, but without the "must never" normative wording, and with thin space characters replaced with {{gaps}} to work around the problem Shakescene has found) would be OK, I guess. --A. di M. (talk) 00:24, 15 February 2009 (UTC)

I’ve taken the liberty of borrowing heavily from A. di M.’s proposed wording (particularly the “it is customary” language) and added more detailed guidance in several places for the benefit of less experienced editors. The two bullet points below would replace the last bullet point in Decimal points. It also clarifies a distinguishing point about 12 digits to the right of the decimal point v.s. 12 digits total in the signficand. Per Jimp’s suggestion below, I’ve also revised ‘manual’ delimiting to the use of {{gaps}}, which I see is now in article-space.

---

• Numbers with more than four digits after the decimal point (high-precision numbers) can be separated (delimited) into groups using the {{val}} template, which uses character-positioning techniques rather than distinct characters to form groups. Per ISO convention (observed by the NIST and the BIPM), it is customary to not leave a single digit at the end, thus the last group comprises two, three, or four digits. Accordingly, the recommended progression on Wikipedia is as follows: 1.123, 1.1234, 1.12345, 1.123456, 1.1234567, 1.12345678, 1.123456789, etc. Note that {{val}} handles these grouping details automatically; e.g. {{val|1.1234567}} generates 1.1234567 (with a four-digit group at the end). Due to server-related issues, {{val}} can reliably handle no more than a total of 12 significant digits in the significand. For significands greater than this, editors should delimit high-precision values using the {{gaps}} template; e.g. {{gaps|1.234|567|890|123|45}} → 1.23456789012345.
• Optionally, truncated representations of mathematically defined constants with fifteen or more digits after the point can use groups of five digits (e.g. e = 2.718281828459045…); in this case, the number of digits used between the point and the ellipsis (the character comprising three periods), being arbitrary, should be a multiple of five (or groups of three if three-digit groups are used).

---

If someone finds a mistake or has some other improvement, please consider the above two paragraphs between the rules as a group-product worksheet to which anyone may contribute. Just leave a short note below stating your edit summary. Greg L (talk) 01:06, 18 February 2009 (UTC)

"47° S" or "47°S"?

In a sentence such as

The latitude of New Zealand, from approximately 34 to 47° S, corresponds closely to that of Italy in the Northern Hemisphere.

should there be any space between the degree and the S for south? MOS:NUM isn't consistent with itself: the section "Non-breaking spaces" uses one in "5° 24′ 21.12″ N" uses one; the 'Quick "how-to"' in "Geographical coordinate doesn't, the output of the templates mentioned there doesn't, the example about Oslo does.

Does that mean that both formats are acceptable? (FWIW, I did use a space in that sentence,[3] as I think it is more legible with the space.)

(BTW, sometimes the double prime ″ sign is replaced by a quotation mark " or by two prime signs ′′. Should that be fixed?)

A. di M. (talk) 10:11, 15 February 2009 (UTC)

The usage should be consistent with the standard for degrees Celsius or Fahrenheit, e.g. "The temperature was 36°C at 36°S latitude". Since there's no essential difference between the two usages, and Wikipedia specifies no space in degrees of temperature, it should probably be the same for degrees of geographical coordinates. Checking the Canadian government style manual, I see that's their standard. It's probably best not to use quotation marks for the double prime, although those of us with smudged reading glasses have trouble seeing the difference, e.g. "5°24′21.12″N".RockyMtnGuy (talk) 18:39, 15 February 2009 (UTC)

Why do you say there's no essential difference? Temperature are not angles, after all. BTW, there often is a space between the number and the symbol in temperature, e.g., “36 °C”, so there is no consistence between the two, anyway (it would have to be “47 °S”, but I haven't seen anybody put a space before the symbol for the degree of arc). Anyway, in “36 °C” (or “36°C”), the “°C” is the symbol for the unit of measurement, whereas in “47°S” (or “47° S”) the “°” is the symbol, whereas the “S” just specifies what is being measured. --A. di M. (talk) 19:45, 15 February 2009 (UTC)

Hum... Our article "Geographic coordinate system" not only doesn't address this issue, but is also inconsistent with itself. And "Degree symbol" only says that there is no space before the sign for degrees of arc, but some people use a space and some don't for degrees Celsius and degrees Fahrenheit. --A. di M. (talk) 19:53, 15 February 2009 (UTC)

Within the US, the way to symbolize "degree Celsius" is officially decided. The Congress authorized the Secretary of Commerce to interpret the International System of Units (SI), and the Secretary of Commerce recognized the National Institute of Standards and Technology's Special Publication 330 as one of two documents interpreting SI for the US. That publication states

The numerical value always precedes the unit, and a space is always used to separate the unit from the number. Thus the value of the quantity is the product of the number and the unit, the space being regarded as a multiplication sign (just as a space between units implies multiplication). The only exceptions to this rule are for the unit symbols for degree, minute, and second for plane angle, °, ′, and ″, respectively, for which no space is left between the numerical value and the unit symbol.

This rule means that the symbol °C for the degree Celsius is preceded by a space when one expresses values of Celsius temperature t.

I believe the interpretation is the same in other countries, and that it would be reasonable to follow the same style for °F. --Gerry Ashton (talk) 20:20, 15 February 2009 (UTC)

The Canadian government style manual differs from the US government style on this point (as well as a number of others). The US government would say 10° N. (space after ° and a period after N) and 10 °C (space before °, but no period after C) while the Canadian government would say 10°N (no space, no period) and 10°C (no space, no period). It would be interesting to see how the other Commonwealth countries approach this matter.RockyMtnGuy (talk) 23:59, 15 February 2009 (UTC)

I don't know what manuals RockyMtnGuy is referring to. The manual I quoted indicates that when writing an angle, it would be 10°. It does not address what to do when that is combined with a direction. Unfortunately, the US government does not speak with one voice. A variety of styles can be found in various US government publications. Special Publication 330 is authoritative with respect to SI, but not necessarily with respect to other units. --Gerry Ashton (talk) 00:59, 16 February 2009 (UTC)

Sorry, I was looking at the US Government Printing Office Style Manual; and the The Canadian Style by Dundum Press in co-operation with Public Works and Government Services Canada. They differ on a variety of issues, including this one. The US NIST Special Publication 330 seems to be derived from the USGPO style manual, but is not as extensive. Other sources vary. I think most authorities view the difference as being inconsequential since it's unambiguous either way. The Wikipedia coord template gives 57°18′22″N 4°27′32″W which seems to be as good as anything.RockyMtnGuy (talk) 18:30, 16 February 2009 (UTC)

Huh? In chapter 9, paragraph 50, it writes "10° N. 25° S." with the space after the ° sign... --A. di M. (talk) 19:38, 16 February 2009 (UTC)

It would appear that A. di M. correctly quoted the U.S. Government Style Manual and that RockyMtnGuy's summary made at 23:59, 15 February 2009 (UTC) is incorrect with respect to that manual. It would also appear that as far as angles measured in degrees are concerned, the U.S. Government Style Manual and Special Publication 330 are not inconsistent. --Gerry Ashton (talk) 19:46, 16 February 2009 (UTC)

Oops! Sorry, I wasn't paying close enough attention. Yes, the USGPOSM uses 10° N. (space after °) but 10 °C (space before °). A subtle point. It's not an issue if you don't use spaces, since the ° symbol serves in lieu of a space, so it slipped past me. I corrected my comments above to correspond.RockyMtnGuy (talk) 22:20, 16 February 2009 (UTC)

Why is this page fully protected?

There was no edit warring at the time of protection, the only reason given what "Oh noes, what about the vandals!" as if they would not be reverted in less than 5.39124(27)×10⁻⁴⁴ s. (turns out there was edit warring ... back in november!) It's been nearly 3 months now. It's ridiculous that we have to ask permission to move a comma around. This is not kindergarten! Let experienced editors freely edit the page by default. If there's actually a problem, then lock the MOSNUM down, but don't lock it down for something silly like fear of vandals. The biggest level of protectiion that this pages warrants by default is edit=autoconfirmed and move=sysop. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 11:25, 15 February 2009 (UTC)

Wikipedia:Requests for arbitration/Date delinking. —Locke Cole • t • c 11:38, 15 February 2009 (UTC)

Ah. But if that is the problem, couldn't one just merge the subsubsection "Linking and autoformatting of dates" into MOS:LINK#Chronological items? Surely it is silly to lock the whole MOS:NUM because of concerns about one three-sentence subsubsection. (BTW, the last link in the "See also" should be updated to point to Wikipedia:Manual of Style (links)#Chronological items, now that WP:CONTEXT#Dates was merged there.) --A. di M. (talk) 14:16, 15 February 2009 (UTC)

Trying to speak unbiasedly here, but given the arbcom case has brought up concerns on general behavior issues here, even if just the problem is with date delinking, it is probably best to keep it fully protected until at least some indication which way ArbCom is going to take the case (if it's just about bot behavior, then I don't see the need to be protected, but there's so much its impossible to tell which way). Editprotected requests work on non-controversial changes, and I'm watching this (greg l has dropped a message when one was needed as well), so other sections that have to be updated can be. --MASEM 15:10, 15 February 2009 (UTC)

• The ArbCom is a fiasco-and-a-half that won’t be ruling on much, if any actual substance; they seem to be primarily interested in addressing who’s been sticking their tongue out the farthest. I’m all for working out guidelines here on this talk page with Masem and others keeping a watchful eye over editor conduct, and posting work product to MOSNUM when something is ready for prime time. If that proves to be successful, maybe we can dip our toes in unlocking MOSNUM. If it doesn’t prove successful, maybe we can take a long hard look at why we can no longer make progress on anything.

  Right now, there are some areas of MOSNUM, such as the entire Section 3 (Numbers), that needs to be harmonized and streamlined so there is less duplication and editors can find information where one would reasonably expect it. I see no need to have complete paralysis here while ArbCom tries to decide if their processes suffer from a serious hiccough, or are galactically dysfunctional.

  BTW, some time ago, I saw a post on an admin hangout here on en.Wikipedia from an admin from the Persian (Iranian) Wikipedia. He had problems with editors putting death-to-Israel flags and pictures of SCUD missiles on their user pages. These editors were also editing articles with a strong, POV-pushing, anti-Israel bent. He came to en.Wikipedia for guidance as to what to do. The advise from our admins was along the lines of “WTF? Get some help, here’s the Wikipedia principle you adhere to, and get tough.” It seems to me that circumstances here on en.Wikipedia can sometimes spiral out of control to the point that even admins here question whether they can do anything about it. Greg L (talk) 01:44, 18 February 2009 (UTC)

Archive links

Most talk pages have links to all the archive pages in the archivebox. This one currently does not. Apparently there was an effort to keep DA discussions in separate archives? Sometime before Dec 7, >3000 edits ago, someone added the (mislabelled) links "118 (D12)" and "118 (D13)" and since then the archive index is untouched. The missing archive links 113-115, 119, 120 are basically all DA discussions.

So what is the scheme and what can be done to fix it? I can update the index easily enough, but is it also desired to strip out the non-DA threads into a separate archive? Franamax (talk) 18:17, 16 February 2009 (UTC)

No, just label them as D something and provide separate links to them in the D series - the third section of the existing box. That would be very helpful. Septentrionalis PMAnderson 17:16, 21 February 2009 (UTC)

"John is thirteen years old" or "John is 13 years old" ?

When this sentence occurs mid-paragraph and is the only occurrence in the article of a number which is the proper or preferred style? I can't seem to find a specific mention of this in the MoS. Also, is there an easy way to search the archives of all the MoS talk pages, and ONLY the MoS talk pages? -- OlEnglish ^(Talk) 19:19, 16 February 2009 (UTC)

WP:MOS#Numbers as figures or words says "As a general rule, in the body of an article, single-digit whole numbers from zero to nine are spelled out in words; numbers greater than nine are commonly rendered in numerals, or may be rendered in words if they are expressed in one or two words (16 or sixteen, 84 or eighty‑four, 200 or two hundred, but 3.75, 544, 21 million)." There are some exceptions, but I don't think any of them apply to this case. --Gerry Ashton (talk) 19:30, 16 February 2009 (UTC)

I see, I recall seeing that but I was wondering if there's a general rule when dealing specifically with references to someone's age, not birthdate, just age number; I wasn't sure if maybe there's a preference when referring to how old someone is to use numerals instead of words, because I've seen it in several GA-class articles where numbers are expressed in words throughout the entire article EXCEPT in sentences such as the one in the heading. -- OlEnglish ^(Talk) 21:33, 16 February 2009 (UTC)

Some style manuals indicate that all ages should be in numerals, even if they are less than 10, e.g. "John is 9 years old. Jane is 7." The US and Canadian government style manuals both use this rule.RockyMtnGuy (talk) 22:29, 16 February 2009 (UTC)

But the Wikipedia style manual doesn't it seems. So should it be updated to clarify this? -- OlEnglish ^(Talk) 22:43, 16 February 2009 (UTC)

The whole section should be removed, or made into a discussion of alternatives. This is an effort to codify English usage, and as such foredoomed. Septentrionalis PMAnderson 00:20, 17 February 2009 (UTC)

Absolutely. It's pointless to try and force usage in this fashion. -- Earle Martin [^t/_c] 05:38, 17 February 2009 (UTC)

Much of that is fine as useful guidance or hints, so long as it's clear that none of it's obligatory. There are just far too many variables to give any strong rules. In writing the lead for The Bronx, I wrote that, among New York's Five Boroughs, it was 4th in population, 4th in area and 3rd in density of population, not because it's my usual preferred style, but because this particular sentence seemed more readily readable that way. Someone else changed the ordinals to third and fourth, and I haven't yet tried to revert because it doesn't make that much difference to me. But there are other cases where I'd very much want to use "third" and others where I'd strongly prefer to write "3rd". Similarly the MOS's line about 19th-century versus nineteenth-century or 19th century vs nineteenth century (or as many of us would still write, Nineteenth Century) doesn't make much sense to me. Much better to trust the editors who are actually writing a specific article with some feeling for who their potential readers would be.

But, although I have not the patience to dig up the relevant archive, my opinion is that about a fifth (20%) of the current MoS needs to be fairly directive, such as where certain machines or people (e.g. the colour-blind) can't read certain formats, or where there's a danger that something might be incomprehensible, ambiguous, misleading or defamatory to readers of a different background, another fifth should be strong advice, and the rest should be simple guidance. There should probably be at least two discrete documents. With those 384 policies that every editor is supposed to know and follow, the danger is that the most important ones will just get lost in the muddle of trivia. And uniformity for its own sake is neither desirable nor possible, because Wikipedia is very different from printed books. —— Shakescene (talk) 01:38, 18 February 2009 (UTC)

OlEnglish, the link and excerpt given by Gerry Ashton seem to answer your question. You have freedom of numeral! Use tact, poise and reason. And please ignore the sniping from the peanut gallery. These poor unfortunates have nothing better to do :D --Goodmorningworld (talk) 01:15, 18 February 2009 (UTC)

Thinspaces

It's time to remove the bit about thin spaces. There was a discussion some time ago about the use of these and it was found that they were problematic because they don't render properly on all browsers (including the version of Internet Explorer I'm using right now). Greg's gaps (used by {{val}} and {{gaps}}) came to the rescue with the added advantages (or what some, including me, might consider essential features) that they are already non-breaking and vanish on copy & paste (allowing numbers to be directly input into spreadsheets or other calculational applications). JIMp _talk·cont 23:37, 17 February 2009 (UTC)

• Definitely. It’s much easier that way for editors too. Last I had looked, {{gaps}} was in user-space. I see it is now in prime time. I’ve revised the wording to reflect this.

  BTW, I completely douched 3⁄4 of this page by accidentally coding {[tl|gaps}} (with a curly bracket followed by a square bracket) in the first paragraph of this post.[4] Man-oh-man, Wikipedia’s server engine doesn’t like that; it simply wouldn’t show the entire last three-quarters of the page, including my post with the goofed-up brackets—not even in edit view. I had to go to a pre-edit, historical page, grab all that pre-goof code, and completely replace the contents here. Maybe {[tl|gaps}} is a fluke, or maybe this is a purposeful code I didn’t know about that is intended to mess with spacetime so you can go back into history and make it so Hitler had never been born. Greg L (talk) 01:11, 18 February 2009 (UTC)

en-gb / en-us

Paragraph 2 seems to be a valid argument for having at least two English Wikipedia versions. 84.9.125.170 (talk) 23:09, 22 February 2009 (UTC)