Wikipedia talk:Manual of Style/Dates and numbers/Archive 61

Archive 55

←

Archive 59

Archive 60

Archive 61

Archive 62

Archive 63

→

Archive 65

[[August 13, 2004]]

I see there are now articles for many specific dates such as August 13, 2004. I ran across such a link in an article. I'm thinking that linking to the full date is generally discouraged but cannot find this specifically addressed in the current guidelines or recent talk archives. Should I change such links to the standard linking format? --GregU 08:41, 5 December 2006 (UTC)

Definitely change them, because they don't respond to users' date preferences.

The guidance on the page says "The day and the month should be linked together, and the year should be linked separately if present". Does it need to be any more explicit than that?

Stephen Turner (Talk) 09:41, 5 December 2006 (UTC)

Perhaps not, but I had my doubts thinking general guidelines are to link to the more specific topic (eg, Convair 580 vs needing to mention it is an airplane), and why do they have such articles if you never link to them, and maybe guidelines hadn't caught up to new developments. I will fix the link I found. --GregU 10:14, 5 December 2006 (UTC)

I'm afraid that I now encourage people to disobey the MoS on the matter of linking any dates, given the shambolic state of this function on WP. IMV, better to sacrifice the auto-formatting function while it's still displayed as a link. Simple as that. Tony 13:16, 5 December 2006 (UTC)

Encouraging people to disobey the MoS is just wrong. Either try to get the MoS changed, or do what the MoS says (or bug the programmers of MediaWiki to add an unlinked date format thingy). Shinobu 04:58, 7 December 2006 (UTC)

It's a form of protest. Do something about it, like supporting a push to have the techs disentangle the autoformatting and linking processes. This was attempted earlier in the year, but fizzled out for want of energy. Meanwhile, I'm not putting up with a seriously unsatisfactory system. Tony 06:50, 7 December 2006 (UTC)

The more I think about it, it does seem like in this case, the current rule is putting form ahead of function, which is not a good thing. Again I'm not sure if specific date pages like August 13, 2004 are frowned upon or not; I could find no discussion of them. But if they are accepted, the most logical thing to do functionally is to link to that specific date. The date page should then link to the more general August 13 and 2004 pages. Until the larger issue of separating formatting from linking is tackled, maybe it would be wise to make a simpler code change and also autoformat dates like this. --GregU 10:29, 7 December 2006 (UTC)

We don't have the ability here to make code changes, only to agree style guidelines based on the existing code. Stephen Turner (Talk) 10:32, 7 December 2006 (UTC)

Which is why, IMV, the MoS should not insist on the use of blued-out dates. Why support (no, make obligatory) a bad technical feature? I'm not budging until autoformatting is rendered BLACK, just like the rest of the text. If you take a look at the last attempt to have the techs change this ridiculous system, I think one of them said something to the effect of "oh, we did it that way because people want to link to date pages". Hello? Tony 11:23, 7 December 2006 (UTC)

(de-indent) - so start/reactivate a proposal to change the system. If the developers believe there's consensus for the current way of doing things, you can try to show that consensus exists that it should be changed. I assume you're referring to Wikipedia:Date debate as the discussion earlier this year? -- nae'blis 22:17, 7 December 2006 (UTC)

This is one thing I'll never understand. I'd have sworn that no developer on this earth would claim that linking and formatting have anything to do each other, yet last time we brought the issue up everything degraded into a bicycle-shed discussion. I also proposed a suitable new syntax on bugzilla, where there seemed to be some consensus and lot of noise. I then stopped participating as after posting there my spam amount increased by at least a factor of eight (no mail address obfuscation). Apparently nothing came really out of it anyway. —Gennaro Prota^•Talk 22:45, 7 December 2006 (UTC)

Any support for reaching consensus on a single date format (outside of exact quotes). Since Wikipedia is a single body of work, it would be nice if there was consistency across it. Good arguments have been made for 7 December 2006 as a format, as it requires no additional commas. That looks weird to my U.S. eyes, but I would tolerate it for consistency purposes. Even if preferences are ultimately kept, I think a single date format should be chosen as the preferred entry method, as it will provide users who are not logged in a consistent experience. I definitely think linking should not be the method in which dates are formatted for user preferences. --MattWright (talk) 22:56, 7 December 2006 (UTC)

There's been something to get date prefs without linking? Hmm... I missed that. Would anyone mind doing me a favour and leave a note on my talk page next time it comes up? Doesn't matter who, but especially if I'm inactive (which is most of the time), I'd like to know. If a discussion's active now, point me to it. Thanks.  :-) Neonumbers 00:36, 8 December 2006 (UTC)

Are there people who defend the existing syntax and believe that all dates should be linked, and linked only to [[Month Day]], [[Year]]? Or is it common ground that people think linking and preferences should be separated? Is linking only being supported because it is the only way to display preferences in dates? --MattWright (talk) 02:32, 8 December 2006 (UTC)

See my post above… I don't know what the consensus might be *now*, but last time the issue was raised (and I was there) not everyone was agreeing about the separation. I can't recall exactly why… And, yes, AFAIK linking is only supported because it is the only way to apply the preferences. :-( —Gennaro Prota^•Talk 05:17, 8 December 2006 (UTC)

I suspect that Gennaro is correct: separate the functions, and the untidy peppering of blue that we must put up with to autoformat will go away; as well, the tension and nastiness that goes on between the faction that wants to blue every chronological item (including "20th century", 1890s and 2005, where autoformatting is irrelevant), and those who don't, will probably dissolve. It's clear to me that linking trivial chronological items is based on confusion of the autoformatting and linking functions. Both of these outcomes would be good for the project. Tony 10:27, 8 December 2006 (UTC)

I don't think many people defend the current situation, but I get the impression that the developers don't consider it a priority. Also the bugzilla discussion didn't really reach a consensus about what the correct format for date preferences without linking should be. Stephen Turner (Talk) 11:49, 8 December 2006 (UTC)

Thanks for the link to the bugzilla discussion. I searched it myself yesterday but I couldn't find it at first and, being a little late in the night, I gave up. I might well be misled by a few bad examples, but my experience with the MediaWiki guys and their responsiveness is quite far from encouraging. —Gennaro Prota^•Talk 13:24, 8 December 2006 (UTC)

Reading through both Wikipedia_talk:Date_debate and the previous bugzilla push, it seems to me that a new push will have more chance of succeeding if:

(1) it comes from as many people as possible, all at once, as though a petition; and

(2) keeps the matter as simple as possible.

I suggest that we ask that:

• the current date-linking syntax be retained (so there are no complaints from pro-linkers)
• a new syntax be created in exact parallel to the linking syntax, simply by substituting <<date>> for [[date]], rendering the date autoformatted but not linked, and thus coloured black.

The initial comment, then, would list people who sign up here, ask for the new parallel syntax to be created, and set out the arguments for it as briefly as possible.

Does that sound like a good strategy? Tony 14:39, 8 December 2006 (UTC)

That doesn't sound bad; another option that we used the other night in a RL consensus meeting was to agree in principle that we wanted to do the thing, then try to decide what the mechanism would be. That may be impossible to sort out on Wikipedia, but I think if we archive Wikipedia_talk:Date_debate and refactor the main page, and try to get things started again as mentioned above, we could get somewhere. I can help. -- nae'blis 15:31, 8 December 2006 (UTC)

I would certainly support such a push, but I think I'm less optimistic than you about the chances of success. Stephen Turner (Talk) 15:47, 8 December 2006 (UTC)

Ditto. See for instance my comment #25 in the bugzilla discussion. Why there tends to be such detrimental nitpicking is really beyond me. —Gennaro Prota^•Talk 16:08, 8 December 2006 (UTC)

I think if we come up with a proposal to vote on this time, we should make no mention of the actual format we want the developers to use. Some people were arguing for or against specific formats, such as <<date>>. I think our concern is not what the format is (we can leave that to the developers to best decide), but that there exists a format we can use to enact preferences and avoid linking. --MattWright (talk) 18:20, 8 December 2006 (UTC)

I don't mind that strategy, but I'd like to specify that the format be "chosen by developers, preferably as simple and short as possible, such as <<date>>". Is that a good idea? Tony 04:40, 9 December 2006 (UTC)

Why specify that? I think the bug report lists other great ideas, like {{date|}}, which could be a wrapper to <date></date>, etc. which may have advantages. I just think that we want this changed so that linking and date prefs aren't using the same syntax and that anything you add to that request is just more stuff that can be debated and used against the idea of separation of these two functions. The simpler you keep it, it seems the less likely to raise objections. Make it a clear win that people want linking and preferences untangled, and *then* the actual syntax can be argued over. That's my opinion anyway. --MattWright (talk) 05:36, 9 December 2006 (UTC)

Can we hash out the request here or on a sub-page somewhere before it is submitted to polish it and agree on something? I was going to write something up and start a list like this as well, but didn't get the time yet. --MattWright (talk) 05:36, 9 December 2006 (UTC)

I agree with Matt. Let's see what we're signing up to first. Stephen Turner (Talk) 08:07, 9 December 2006 (UTC)

Seems pretty clear. I for one am agreeing "in principle" that wiki needs functionality that allows date formatting preferences to work without turning every mention of a date into a pointless link. –Outriggr § 08:58, 9 December 2006 (UTC)

I agree with Outriggr. Worst case scenario we could apply some HTML formatting to override the link's default color -- for example, "click here". Maybe we can rig up a template to do just that? --Stratadrake 01:46, 10 December 2006 (UTC)

Thank you all for your support. May I repeat MattWright's suggestion above that we keep our request as simple as possible (single-issue, let the developers decide on the details, I guess). Previous attempts appear to have come unstuck through continued debate over details. Tony 07:12, 10 December 2006 (UTC)

I'm with Outriggr and Tony1. I agree in principle that auto-formatted non-linking dates is a Very Good Idea, and that the worst thing we can do in support of that idea is to over-specify it. The first sentence of the request should be the entire request, with the remainder justifying it. RossPatterson 19:04, 10 December 2006 (UTC)

Strong support, this has been previously discussed at Wikipedia:Date debate. —Quarl ^(talk) 2006-12-10 08:38Z

• Comment my opinion about all this issue is: we already have a mechanism (preferences) which allows the user to choose a preferred date format or to specify that he/she has no preference at all. That should already mean that —regardless of any linking or whatsoever— a logged in user should either see all dates as they are written (no preferences) or as he/she prefers. Currently it is not so, and this is the first problem, or at least an oddity. Secondly, date formatting is just one aspect of localization. Why Mediawiki offers an option to format dates but not to choose, for instance, the decimal separator is beyond me. Finally, I believe that *auto*formatting (when the user is logged in) should be the default, in absence of any syntax. What we need is a syntax to *inhibit* localization, which would be used, for instance, in quotations and the like. Do we agree on this? —Gennaro Prota^•Talk 13:40, 10 December 2006 (UTC)
  • No, I don't think I agree. I think that your suggestion would put more burden on the Wikipedia servers, because it would have to scan all text, not just marked-up text. I'd also be worried about false matches. And for other localization: I agree with you in principle, but I really recommend keeping that out of the discussion, because the discussion has stalled in the past when those issues are raised. Stephen Turner (Talk) 14:16, 10 December 2006 (UTC)

Like Stephen, I agree in principle; but it's just too radical in the current context. Getting the developers to act will require simplicity and unanimity. Any complications and they're likey to take the easy way out and just say "nah". Tony 14:24, 10 December 2006 (UTC)

• (moved by Tony to keep debate and list separate). I continue to prefer that the MoS recommend exactly one format for dates (just as there's exactly one set of rules for how to place other punctuation around quotation marks, and one set of rules about capitalizing article and section titles). But, if this new syntax will allow all dates to have exactly the right commas (as discussed in the section to which I link earlier in this paragraph), and if it will do away with some of the fighting over when a date should be cross-referenced (for the sake of referencing, not formatting), then I support it. Even if those two criteria were met, supporting this proposal would still not be my first choice. My first choice, as I've said multiple times, is to have only one order in which to write the parts of dates (preferably "Sunday 10 December 2006", with punctuation as required only by its placement in the rest of the sentence, and with "A.D." (before the year) or "B.C."/"B.C.E."/"C.E." (after the year) added as required) and for encoding to do nothing but turn the date into a cross-reference. As may be obvious, my first concern is doing away with syntax that results in faulty punctuation, and the two concerns that share second place for me are making the current style of encoding be only about cross-referencing (thus reducing some battles over that) and standardizing the order in which we write the components of dates (so that editors stop warring over "December 10" vs. "10 December").

Personally, I would prefer this as well, but I think it may be much more controversial than just eliminating the links, which seems to be something almost everyone agrees on. Theoretically, if a new syntax is designed, it should take into effect these other concerns. I don't know that "input conformity" is necessary (requiring editors to input in a certain order), but certainly I would like to see "output conformity", where a date either displays under a user's preferences or displays in a single style throughout Wikipedia for anonymous users, regardless of input method. I would expect if the entire date was wrapped in a single syntax, comma concerns could be worked out automatically. --MattWright (talk) 22:21, 10 December 2006 (UTC)

Yen vs. Yen

Is there any preferred disambiguating prefix for ¥ to differentiate Japanese yen from Chinese Renminbi? "¥" is not mentioned under the good style examples but it is the sole prefix form used at the Renminbi article. —  AjaxSmack  22:04, 11 December 2006 (UTC)

If there is, I'm not aware of it. My suspicion would be JP¥ and CN¥ respectively, though I wouldn't have a clue.

For the Renminbi article, there would probably be no need to differentiate one from the other as the article is clearly about the Chinese currency. It might help if you could post the article you're working on (or one or more of them). Neonumbers 08:28, 13 December 2006 (UTC)

You could use the ISO 4217 code, i.e. "CNY" and "JPY"; for CNY you can also say RMB. It's common to write e.g. "USD" instead of $ since there are many countries that call their currency the "dollar". Another method is to link to the currency like this: ¥, though that one has the disadvantage that the reader has to mouse-over to see what it is, and it won't show in print. —Quarl ^(talk) 2006-12-15 04:32Z

Rationale for "Where applicable, use uppercase rather than lowercase letters: 0x5AB3, not 0x5ab3"?

Hi,

what is the rationale for this? Is it just something like "pick up one just to be consistent" or are there any other reasons? FWIW, all other things being equal I generally prefer lowercase, as it avoids making the notation stand out with respect to the surrounding text. Also, where would the guideline be "not applicable"? Perhaps in quotations? I guess this last point needs a clarification. —Gennaro Prota^•Talk 09:36, 16 December 2006 (UTC)

Consistency. Full stop. That's pretty much all there is to it. As for why uppercase to lowercase, well, I find where numbers are in contexts where they seem to be done "properly" (i.e. formally) they tend to be uppercase, but I don't claim to be an expert in the field.

Most guidelines are not applicable in quotations. For the uppercase vs. lowercase things, I personally would consider this to not be one of them (i.e. is is applicable), because in my view it is too negligible a change — similar to, say, putting commas in the number in "Retailers sold 49258230 copies of Singstar in the first two months of sales", which you probably would do. It's a tough call though. It is generally difficult to find exceptions to guidelines, but they do occur occasionally: unless there's awesomely brilliant reason otherwise, follow the guideline. Neonumbers 09:56, 16 December 2006 (UTC)

Whoops, just read the guideline and now I see what you mean by the "applicable" part. The "where applicable" in that sentence is intended to refer to "where there are letters in the number", e.g. it wouldn't be applicable for a number like 0x3825 because there aren't any letters that can be lower/uppercase in it! Neonumbers 10:01, 16 December 2006 (UTC)

• Thanks. I was bold and tweaked the section a bit (though I still think that we non-native speakers should rarely touch the MoS :-)). Note that I also tried to make clear(er) that 0b is not a C prefix. Personally I feel that "use uppercase" is a bit of over-specification (sweat the small stuff) and that this is a usage that there's no need to standardize across different articles. Incidentally (and pedantically): in Italian we would likely use a colon after "For numbers in bases other than base ten" (we would also likely prefer starting the list entries with a lowercase letter, though that becomes difficult when there's more than one sentence in each entry — we use lowercase after ':' but uppercase after '.'). Is that different in English? (Sorry, I'm the quality paranoid! :-)) —Gennaro Prota^•Talk 19:35, 16 December 2006 (UTC)

• Oh, and I forgot this (which I was going to fix but thought to discuss first): there's no such a thing as a "non-base-ten number": a number is a number; what changes is the notation or the system of numeration. —Gennaro Prota^•Talk 19:47, 16 December 2006 (UTC)

Yes, you're pedantically right on these :), go ahead and make the changes; I think they're small enough to not need discussion first. —Quarl ^(talk) 2006-12-16 21:52Z

Given that half the purpose of the manual is to encourage consistency, and that in an encyclopedia, consistency is generally pretty important (especially on issues of neatness like this one), I still say the uppercase guideline is good.

For the colon, yes, you're right, a colon would make sense there; a comma can be used but these days we tend to use colons... and if a comma was used, it's then standard practice for the bullet points not to start with capital letters. Colon before a bulleted list normally means capitalised list items, I think (not sure). As for sentences, yes, in English, after a colon, we normally use lowercase: like this.

As for non-base-ten numbers... you know what we mean by that, right?  ;-) Technically, I suppose you're right... if you change it, try not to make it longer or more wordy than it already is. Personally, I think it communicates the message sufficiently, but I won't complain about a change if it makes it clearer but not much longer. (And I thought I was a perfectionist :-P)

I must say I'm not an expert on programming languages; basically the principle behind our splitting of the two situation is that context matters, i.e. the notation should be appropriate to context. Neonumbers 12:20, 17 December 2006 (UTC)

I avoided the colon/comma issue altogether, by removing the sentence containing it (not all sections introduce lists with a sentence, so I guessed the removal was ok); that also got rid, I think, of the upper/lowercase issue.

In general, I'd like to attach a concise rationale section to MoS pages (and articles, if possible). So far, I haven't precisely figured out how to effectively make that, though. It would probably go at the top of the talk page and be similar to what we get with the {{todo}} template. But this is completely in nuce and any idea is very welcome. When it will be more than a vague intent we could bring it to the village pump. —Gennaro Prota^•Talk 13:36, 17 December 2006 (UTC)

I've put the sentence back, this time with a colon, and with slightly different wording. Really, colon/comma, it's not that big a deal, no-one notices these things. In my humble opinion, the sentence provides a good context-setter for the section (the header doesn't count, in my book, anyway).

Don't quite understand what you mean by the rationale section, but sounds interesting. Neonumbers 02:11, 18 December 2006 (UTC)

It is an idea with a proven effectiveness in software development and other collective processes (including ISO standardization - C99, for instance, has a detailed rationale). I know no better way to describe it than Beman Dawes' words:

Rationale is defined as "The fundamental reasons for something; basis" by the American Heritage Dictionary.

Beman Dawes comments: Failure to supply contemporaneous rationale for design decisions is a major defect in many software projects. Lack of accurate rationale causes issues to be revisited endlessly, causes maintenance bugs when a maintainer changes something without realizing it was done a certain way for some purpose, and shortens the useful lifetime of software.

Rationale is fairly easy to provide at the time decisions are made, but very hard to accurately recover even a short time later.

© Copyright Beman Dawes 2003.

Distributed under the Boost Software License, Version 1.0. (See http://www.boost.org/LICENSE_1_0.txt)

—Gennaro Prota^•Talk 15:45, 18 December 2006 (UTC)

When we were discussing this not too long ago (late 2005 methinks, search the archives) I guess I got people to agree upon uppercase, because most fonts nowadays use lining decimal digits, not old style. The latter fit well with minuscels, the former do not. We cannot ensure either one, though. Christoph Päper 14:36, 18 December 2006 (UTC)

For the entire manual, or for each section in turn? Does the lead paragraph that currently sits at the top of this manual count as one? Neonumbers 22:36, 18 December 2006 (UTC)

I'll not let you indent more than me! :-)

Seriously, you can see that the quote above holds: not even the persons who wrote it can remember the details. That's not a criticism against you: it's normal, and that's why experience suggests writing rationales down. —Gennaro Prota^•Talk 23:07, 18 December 2006 (UTC)

No I get the rationale for including rationales, I mean, like, are you suggesting that we include a rationale for each section in turn in the manual (e.g. one for units, one for non-base-ten notations, one for times, etc.), or one rationale section for the entire page? Neonumbers 01:27, 19 December 2006 (UTC)

Ah! I thought you were replying to User:Crissov. Now I understand the indentation! :-) I've resized his image, to limit confusion. I haven't thought of the details (yet). In practice, however, any *choice* is to be given a reason for. Perhaps everything could be in a subpage (of the project page or of its discussion page), with a standardized link to it on the manual page proper. I think it is an important goal to try to stabilize the manual: it does need stability, the more so as the number of Wikipedia articles increases; or we would be like continually changing the rules while the game is in progress (with the difference, compared to a game, that we should retroactively adapt all the previous "moves", i.e. "fix" the style of existing articles). —Gennaro Prota^•Talk 08:42, 19 December 2006 (UTC)

I've gone (or am going) into a new section down the bottom for this topic. Neonumbers 10:15, 19 December 2006 (UTC)

Octal notation

Is it really a good idea to use the C leading-zero convention for octal? Wikipedia isn't a programming book, it's an encyclopedia, and we shouldn't presume that only programmers (or worse yet, only programmers who work in C) will read the computer-related pages. The "0x1234" notation for hexadecimal isn't transparent to non-programmers, but at least it won't be confused with 1234₁₀, something you can't say for the "01234" octal notation. There are other notations, and like '1234'O they all are pretty poor, but at least they're not easily confused. RossPatterson 01:19, 17 December 2006 (UTC)

• Good point. It would seem relevant in programming-related articles though. Since it's pretty rare to use octal nowadays maybe it should have to be explained when used. —Quarl ^(talk) 2006-12-17 01:29Z

• Despite being a C++ programmer I agree. Also, the 0b prefix is very perplexing. All things considered I think the mathematical notation should be used everywhere except where employing a specific programming language syntax (whatever the language is). Another exception could be contexts with lot of numbers (including tables and similar), such as the endianness article: writing so many "₍₁₆₎" there can be quite distracting (arguably). BTW, I was thinking to write a little template to standardize the note/explanation wording and format. —Gennaro Prota^•Talk 10:26, 17 December 2006 (UTC)

• Some languages, such as Verilog, use the 0b prefix (Verilog also uses 0o for octal). —Quarl ^(talk) 2006-12-17 21:15Z

• Ah! :-) Thanks. I guess the "correct" (conforming to the intent) guideline is thus: "In the context of computer, data-modeling languages and other specific formalisms use the notation established by that language (e.g. in C use 0x for hexadecimal; in Verilog use 0b for binary)". Prefer uppercase letters if allowed by the language syntax. In all other articles use the subscript notation. Prefer uppercase as well. —Gennaro Prota^•Talk 21:37, 17 December 2006 (UTC)

I guess I would support a manual change so that, in programming languages, the guideline is to use the notation of that language. I just wonder if there'd be situations that that wouldn't cover. Neonumbers 02:13, 18 December 2006 (UTC)

It should be fine to use the notation of the relevant programming language, per article. In that case each article should have an explanation of the notation or a link to a project-space article about notation. It would help discussion if we had a list of articles that have numbers represented in non-decimal bases. —Quarl ^(talk) 2006-12-18 02:24Z

I favour suffixed b, o, d and h in computing articles (i.e. neutral on programming language), but math-style subscripts in all other articles. Alas, the outcome of the not too distant discussion was different. Christoph Päper 14:40, 18 December 2006 (UTC)

Rationales

(Continued from above)

I agree that some stability is needed, but many would argue that standards can and do change, especially with new browser support and the like (for example, the use of proper dashes is now meant to be more common), and as well as that, Wikipedia is still (arguably) developing and new conventions continue to be developed. I would have to sympathise with those people. Stability's a bit too much to ask at this point in time.

What I'm trying to figure out is how to do so without having too much of the manual being rationale (thereby making it harder to find an actual guideline). Could it be as simple as adding, "because..." after statements, where applicable? Would we need something more solid or formal? The important thing is not to write too much. Neonumbers 11:47, 19 December 2006 (UTC)

All good points. I'm trying to figure out that too. Just a note: I didn't mean "stability" as "immutability", but we should be a little more cautious than elsewhere with the MoS. What about changing the subject here to draw other editors' attention, or bringing this to the village pump? —Gennaro Prota^•Talk 12:39, 19 December 2006 (UTC)

Yes, I think most people would agree with you in that sense. You might have noticed that undiscussed changes are quickly reverted? Though I believe that the manual should only be changed with consensus, and where there is none, the old/original/former guideline should remain standing, in order to retain some stability, I guess. But I know many disagree with this stance; they argue that guidelines need consensus to remain in place. Whoops, getting sidetracked.

Anyway, personally I think it might be wise to solidify thoughts before going to the village pump because it is a rather fundamental proposal, in my opinion, anyway. Will support your decision if you decide to do so though. Neonumbers 10:58, 20 December 2006 (UTC)