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

message: If you do this, then I think that, if a date appears within parentheses, it should automatically be replaced with "(see XXXX in music)" (or "video gaming" or whatever). SharkD (talk) 03:49, 17 December 2007 (UTC)
replies: text: That would in way, way too many cases auto-violate the the principle that such "YEAR in TOPIC" links should only be made when the linked-from item is genuinely significant within the context of that year.  For example: SOME_RANDOM_FILM_NAME (1993), on one hand, versus SOME_VERY_SIGNIFICANT_FILM_NAME took the 1993 "Best Picture" Oscar on the other.  And that probably isn't even a good example, really.  It is hard to come up with a generalized case for when one should make such links; it is much easier to say that most of them should simply be deleted, as blue-link "noise". — SMcCandlish [talk] [cont]  ‹(-¿-)› 23:09, 18 December 2007 (UTC)
thread_title: Parentheses

message: I am pleased to announce that we have a complete draft proposal for you to inspect, comment on, and modify.
Just go to the working group's development page, read the instructions at the top, and take it from there.
Or click "show" to see a draft, right here:
See a full draft of the proposal
 
----
– Noetica♬♩ Talk 07:05, 16 January 2008 (UTC)
thread_title:  Markup for the hard space: update 

message: Per Mustafa_Kemal_Atat%C3%BCrk
*Mustafa Kemal Atatürk, born Ali Rıza oğlu Mustafa (May 19, 1881 (adopted) – November 10, 1938)
How should an assumed birthday (which may be correct), be listed? 
-thanks Byzerodivide (talk) 01:44, 19 January 2008 (UTC)
replies: text: I would use "c. 1881" and explain in the article. I wouldn't use the word "adopted". Readers might think his birth date is unknown, but he was adopted by people who were not his natural parents on May 19, 1881. --Gerry Ashton (talk) 01:59, 19 January 2008 (UTC)
thread_title:  How to list assumed / adopted birthdays 

message: Editors are invited to join a discussion at WT:MOS. We present the working group's completed proposal for new hard-space markup, and call for your suggestions.
– Noetica♬♩ Talk 03:46, 21 January 2008 (UTC)
thread_title:  Discussion of the hard-space proposal 

message: What's the preferred way of doing birth/death dates? Wikipedia:Manual of Style (dates and numbers)#Dates says ISO dates are not common within prose but the birth/death dates in the first sentence of a typical biography — "Joe Bloggs (January 1 1900 – December 31 1980)" — aren't really prose per se. On the other hand, Wikipedia:Manual of Style (dates and numbers)#Dates of birth and death doesn't give any ISO examples either. What is the community consensus about this? Thanks. howcheng  {chat} 01:34, 18 January 2008 (UTC)
replies: text: That's not a bad question—I would consider those dates to be part of the prose, even if they are in parentheses, because they are part of what is read by the reader in the prose (as opposed to, say, a table).  Neonumbers (talk) 10:35, 27 January 2008 (UTC)
thread_title:  ISO birth/death dates in biographies 

message: Which of these is correct: "the 5 mile (8 km) road" or "the five-mile road"? Thanks. Epbr123 (talk) 19:35, 29 January 2008 (UTC)
replies: text: It depends; what article are you thinking of putting it in? --Gerry Ashton (talk) 19:38, 29 January 2008 (UTC)
replies: text: I made these changes to Tumbler Ridge, British Columbia, but I'm not sure if I was right. Epbr123 (talk) 19:43, 29 January 2008 (UTC)
replies: text: Spelling out the number is correct for small numbers. The hyphen between the number and the unit is not addressed in Wikipedia's Manual of Style, as far as I can see. A style guide from NIST says "When a metric value is used as a one-thought modifier before a noun, hyphenating the quantity is not necessary. However, if a hyphen is used, write out the name of the metric quantity with the hyphen between the numeral and the quantity." The Wikipedia MOS allows, but does not require, two word numbers to be spelled out (for example, fifty-six). If a hyphen were also used for the unit, the result might look awkward (for example, fifty-six-kilometre road), so I wouldn't use the hyphen except in situations where there are several numbers near each other, and I want to avoid confusion. --Gerry Ashton (talk) 20:10, 29 January 2008 (UTC)
replies: text: Ok, thanks. I'll revert the changes I made. Epbr123 (talk) 21:33, 29 January 2008 (UTC)
replies: text: The hyphen is discussed.  Numbers are spelt out but this is a distance we're talking about here.  General practice (at least on WP) is to write measurements out in numeral form, though spelt-out forms seem to be acceptable.  Thus use either "the 5-mile road" or "the five-mile road".  As for the metric conversion, why not include it?  Conversions are generally not spelt-out (neither the numerical value not the unit name).  Hyphens are not used abbreviations so the above would become either "the 5-mile (8 km) road" or "the five-mile (8 km) road". Jɪmp 01:46, 30 January 2008 (UTC)
thread_title:  Measurement query 

message: :* I would like to weigh in on this issue with this proposal: The overriding principal of the SI with regard to technical writing and general written communications is to unambiguously and easily communicate in a language-independent fashion using internationally and well-recognized units, symbols, and style. For instance, even though percent and its symbol (%) are not formally part of the SI, it is recognized by the BIPM and ISO for use with the SI because it is widely recognized and simplifies communications.There are currently two practices for delimiting numbers in the mantissa: spaces, and commas. It’s currently a free-for-all in the decimal place and only two practices are observed: 1) delimiting with a space, or 2) no delimiting whatsoever. Clearly, long chains of decimals in a row are extremely hard to parse and demand to be delimited. Trying to get all contributors to provide spaces in the decimal portion of numbers would be difficult but I would hope that official Wikipedia policy would be that the preferred method of numeric notation to the right of the decimal place is to delimit every three digits with non-breaking spaces {exceptions would be 1) where the last group consists of four digits and 2) where a group of five digits is delimited so the last group comprises two digits}. Further, I would propose that Wikipeida would recognize that the best practice is to permit the use of reduced-size non-breaking spaces (i.e.  ), which is an SI-compliant form that observes best typography practices. Examples:Best typography practices:3.141 592 6535 and 1,579,800.762 04Acceptable delimiting:3.141 592 6535 and 1,579,800.762 04Further of course, the Euro practice of delimiting the mantissa with non-breaking spaces (preferably reduced-size ones) would also be acceptable.Clearly, my proposal also holds that practices like “1.414213562373095” should be strongly discouraged or prohibited.Greg L (my talk) 21:53, 15 December 2007 (UTC)
thread_title: Grouping of digits: Specific proposal (obsolete)

message: Please, for the love of $deity, can someone point me in the write direction to put forth a recommendation that we use the international / universal dating convention of DD/MM/YYYY rather than MM/DD/YYYY as is becoming prolific.  Whilst I appreciate this is due to many of our editors and authors being of American origin, and no one system is correct, the most widely used system is smallest to largest, not medium to smallest to largest and we should perhaps adhere to that more stringently.  At present reverting the use of two styles for dating will be a lot of work, but the longer we leave it the worse it will get. 58.107.154.192 (talk) 02:51, 3 February 2008 (UTC)
replies: text: According to this manual of style, generally dates should be written in one of the forms that spells out the name of the month. ISO 8601 dates (that is, YYYY-MM-DD) may be used in "long lists and tables for conciseness and ease of comparison". DD/MM/YYYY and MM/DD/YYYY are both unacceptable. In my opinion, there is no chance whatever that either of these formats will ever be tolerated in any Wikipedia manual of style because of ambiguity. Feel free to replace them everywhere except direct quotations. --Gerry Ashton (talk) 03:36, 3 February 2008 (UTC)

text: If you create an account, you can configure your date preferences to show dates in whatever format suits you.  This is (unfortunately) much more practical than attempting to get the entire project to switch to one format.  — Aluvus t/c 04:09, 3 February 2008 (UTC)
thread_title:  Universal Dating 

message: An editor has recently changed "9th century" to "ninth ..." and several similar changes, in Bath, Somerset.  MOSNUM says "Use numerals for centuries (the 17th century); do not capitalize century. " The example isn't as powerful as it could be, as "17" would be written as a number in any case.  Could we change the wording to "Use numerals for centuries (the 9th century); do not capitalize century."? PamD (talk) 00:43, 27 January 2008 (UTC)
replies: text: Sounds good to me. Tony (talk) 01:23, 27 January 2008 (UTC)
replies: text: As no-one else has commented in a week, I've made that change now. PamD (talk) 07:44, 3 February 2008 (UTC)
thread_title:  Single-digit centuries 

message: This page is 657KB; every time I try to edit I get an edit conflict or hung on load time.  SandyGeorgia (Talk) 05:00, 1 February 2008 (UTC)
replies: text: Made two archives and cut it down to 218k. Anyone object to automated archiving through User:MiszaBot? Perhaps archive threads after no comment for 15 days, with a max archive size of 150k? Gimmetrow 08:55, 1 February 2008 (UTC)
replies: text: Sounds good, Gimmetrow. Tony (talk) 06:19, 3 February 2008 (UTC)
replies: text: Automated archiving, I like the sound of that—maybe even a 10-day inactivity period might be enough.  Neonumbers (talk) 10:01, 3 February 2008 (UTC)
thread_title:  Holy smokes, archive please 

message: Dear fellow colleagues: the idea is to centralise debate and consensus-gathering when there are inconsistencies between the pages. The most straightforward way is to have MOS-central prevail, and to involve expertise from sub-pages on the talk page there, rather than the fragmentary discourse—more usually the absence of discourse and the continuing inconsistency—that characterises WP's style guideline resources now. Of course, no one owns MOS-central, and we're all just as important to its running as other editors. I ask for your support and feedback HERE. Tony (talk) 12:12, 5 February 2008 (UTC)
thread_title:  Proposal to formalise the relationship between MOS and its sub-pages 

message: The line for May 15 2005 is not correct. When there is no comma in this format in the wikitext, a comma is added for (at least some) IPs and users with no date preference. Likewise, for 15 May, 2005 the comma is removed for (at least some) IPs and users without preferences. Gimmetrow 23:16, 6 February 2008 (UTC)
replies: text: You are absolutely right. I have changed the table to red-X these formats. There are only 2 acceptable formats for full dates in WP text, not 4. Chris the speller (talk) 16:46, 8 February 2008 (UTC)
replies: text: I cannot agree to putting green check marks next to formats that are not "acceptable" according to this guideline. There would have to be consensus that these are acceptable; this has already been discussed, with a few editors trying to loosen the standards based on the assumption that people who care how it looks will set a preference, while other editors pointed out that it does not put WP's best foot forward for new or occasional readers. I will change the table back, for now. Chris the speller (talk) 17:18, 8 February 2008 (UTC)
replies: text:  According to what part of the guideline are they "unacceptable"? Gimmetrow 17:59, 8 February 2008 (UTC)
replies: text: The section "Full date formatting" shows the 2 formats that are acceptable for full dates (day of month, month and year); other formats are unacceptable, and for years all but the two have been unacceptable. There have been proposals to loosen the standards, but no consensus, as many editors feel that 2 formats are enough (or even too much). Chris the speller (talk) 02:32, 9 February 2008 (UTC)
replies: text:  What are you talking about that is not one of the "2 formats"? Gimmetrow 02:41, 9 February 2008 (UTC)
replies: text: The guideline shows 14 February 1991 and February 14, 1990 as acceptable formats for full dates. The table also shows two variations on those, one (UK-style) but with a comma added, and the other (US-style) but with the comma removed. I did not mind that the table included these for completeness, because they can be found in use within WP, but objected to the implication that these were equivalent to the accepted formats. I think the table is OK now, as it no longer equates them. Chris the speller (talk) 17:09, 9 February 2008 (UTC)

text:  Wikitext of the form "14 February, 1991" displays as one of the "acceptable" formats, right? Gimmetrow 19:41, 9 February 2008 (UTC)
replies: text: Text entered as "14 February, 1991" is displayed unaltered, and is not acceptable because there should not be any comma. Did you mean to put some square brackets in your example? --Gerry Ashton (talk) 19:53, 9 February 2008 (UTC)
replies: text:  We're discussing dates linked for autoformatting, with the specific context of the forms mentioned in the table under that section. I would have thought that was understood. Gimmetrow 22:36, 9 February 2008 (UTC)

text:  Do whatever you want, but at least present how the system actually works. Gimmetrow 23:25, 9 February 2008 (UTC)
thread_title:  Commas in linked dates 

message: Please see this example. Tony (talk) 12:51, 7 February 2008 (UTC)
replies: text: At the time of my post, it hadn't gone off-topic. We still need to determine which guideline should prevail. At the moment, MOSNUM and MOS say different things. Tony (talk) 07:35, 10 February 2008 (UTC)
thread_title:  Why we should all be supporting the proposal to coordinate MOS and its sub-pages 

message: Below are the latest specifics of the proposal:
:* We’ve been discussing the details and merits of a template/parser function (magic word) to make life easier for editors when expressing delimited numeric equivalencies—with and without physical units. The fundamental motivation underlying this effort is this obvious truth: delimiting numeric strings to the right of the decimal marker serves precisely the same purpose as does doing so to the left of the marker and is very much needed on Wikipedia. It would avoid number strings like this: 2.718281828459 which actually appeared in Natural logarithm until a few weeksa go. A full-featured use of the template/parser function would allow an editor to type  in order to obtain the following: 6.02246479(30) × 1023 kgThe parenthetical (30) in the above value denotes the uncertainty at 1σ standard deviation (68% confidence level) in the two least significant digits of the significand.
:* In summary, the above template/parser function functions as follows: 
:* The use of a template/parser function like this greatly simplifies things for editors. To generate the above value, one currently must hand-code the following: 6.02246479(30) × 1023 kg   (*Phew*)
:* As can be seen in the above code, the template/parser function uses non-breaking spaces ( ) on both sides of the “times” (×) symbol and just before the unit symbol. Thus, there would be no line-end occurrences like the following:
:::The Planck constant would be fixed, where h = 6.62606896 ×10–34 J·s,or…The avoirdupois pound is defined as exactly 0.45359237kg, making one kilogram approximately equal to 2.205 lb.
:* Although highly capable and feature-rich, this template/parser function wouldn’t be cumbersom for simple tasks. It would work similarly to how  produces  and  produces . For instance, one need only type  to obtain 6.022464 or they could type  to obtain 1,579,800.298728You could also pick and choose just the features needed. For instance  yields 1.356392733 × 1050 Hz and  yields 0.45359237 kg
:* One of the things that has been standardized by the ISO, the BIPM, NIST, ect. is that delimiting in the decimal shall not leave a single dangling digit, like “0.001 4”. Accordingly, the progression of delimiting goes as follows:2.12.122.1232.12342.123452.1234562.12345672.123456782.1234567892.12345678902.123456789012.1234567890122.1234567890123The logic tree underlying this parsing method is shown in Digit-counting parsing logic, below.This template/parser function will avoid future occurances of editors hand-coding improper, hanging digits—as exemplified in this section of Font size, which features this numeric string: 0.187 985 755 2 mm
:* Even nicer, the template/parser function wouldn’t use “spaces” to delimit the fractional portion of the significand (the portion of the significand to the right of the decimal marker). Instead, it would use what typographers refer to as “pair kerning” via em-based control of margins (e.g. ). Margin positioning is part of what the Web-authoring community calls span tags, which, in turn, is part of Cascading Style Sheets (CSS). Effectively, what appears to be a space would really only be a visual effect caused by the precise placement of the digits; the “spaces” wouldn’t be separate, typeable characters.To see the difference, slowly select the two values below with your mouse:
:::6.022464342 (via em-based span tags, note how the cursor snaps across the gaps)
:::6.022 464 342 (via non-breaking spaces, note how the spaces can be individually selected)
::One might ask “Why is em-based margin control via span tags nice?” Note how, as you select the two values above, the lower version has spaces that can be selected because they are distinct characters. By using the technique illustrated in the top example however, people will be able to select entire significands from Wikipedia and paste them into Excel, where they will be recognized as real numbers! This beats the hell out of the current system, where (as exemplified at Font size) simple regular spaces and non-breaking spaces are used to delimit numbers. These values can’t be copied and used in Excel without first hand-deleting each of the spaces from every value. Until the spaces have been deleted, Excel treats the numbers as text strings upon which mathematical operations can’t be performed.
:* The use of spans requires that they be closed with an equal number of . Note the example code shown in the third bullet item down in this list.
:* In summary, here is a concise list of examples highlighting the flexibility and convenience of this template/parser function. All the editor does is follow the parsing map:
:::
:::Leave feature blank if not required
:::Separator bars are not required if you input only the value
:::  → 6.02214179(30) × 1023 kg
:::  → 1,579,800.298728
:::  → 1.356392733 × 1050 Hz
:::  → 0.45359237 kg
:::  → 6.022461
:::  → 6.0224613
:::  → 6.02246134
:::  → 6.022461342
:* This proposal is founded on the following assumptions: 1) commas should be used to delimit the integer portion of the significand, 2) narrow gaps should be used to delimit the fractional portion, and 3) a template/parser function should be made to facilitate delimiting the significand and to also simplify the formatting of the rest of numeric equivalencies (such as relative standard uncertainty in concise form, base-ten exponents, and setting off unit symbols with a non-breaking space). The reasoning underlying this is addressed in Rationale for using “comma delimiting” with “narrow-gap delimiting”, below. As regards how Wikipedia readers already recognize and accept gap-delimiting to the right of the decimal marker, see Making a case for why narrow gaps are already well-accepted on Wikipedia, below.
: Greg L (my talk) 03:46, 2 February 2008 (UTC)
thread_title: Overview

message: :: In the mean time, the logic tree for delimiting to the right of the decimal marker would be as follows:
:::Q1: Are there five or more undelimited digits remaining after the decimal marker? No=Stop / Yes=Advance three digits and prepare to add span gap. Goto Q2.Q2: Is the span gap to be added following the digit “1”? No=Add a span gap of 0.25 em and then goto Q1 / Yes=Add a span gap of 0.2 em and then goto Q1.
:: Greg L (my talk) 20:51, 1 February 2008 (UTC)
thread_title: Digit-counting parsing logic

message: In any discussion of delimiting numbers to the right of the decimal marker with gaps, we must also settle on what to do to with the integer portion of the significand (the left-hand side of the decimal marker). I advocate using commas for two reasons:
: 1) Most articles on Wikipedia already use commas. It’s what U.S. readers expect and is a convention that Europeans are accustomed to encountering. Trying to do the integral any other way wouldn’t be well received and the template/parser function simply wouldn’t get used.
: 2) Few numbers simultaneously require delimiting on both sides of the decimal marker. In other words, it will be a rare number where commas (a U.S. style) and narrow spaces (a European/SI style) are juxtaposed within a single value.
Note the above examples (copied from Kilogram and Font size). In those examples, only the third example (the definition of the meter) has five or more digits in both the integral and fractional portions of the significand. All the others require delimiting only on one side of the decimal marker or the other, but not both.  Greg L (my talk) 20:06, 31 January 2008 (UTC)
thread_title: Rationale for using “comma delimiting” with “narrow-gap delimiting”

message: I’ve seen many Wikipedia articles that feature space-delimited numbers to the right of the decimal marker and they’ve been stable for years without one single “drive-by shooting” by an unregistered editor-in-a-hurry  attempting to “fix” the ‘funny-looking’ values. Font size is just one such example; there are too many Wikipedia articles to count. This is clear proof that essentially all readers readily recognize that what they’re looking at are space-delimited numeric values. If this can occur with full-width spaces, then reduced-width ones—which just look “right”—will be even easier and more natural for readers. Delimiting numeric strings to the right of the decimal marker serves precisely the same purpose as does doing so to the left of the marker and is very much needed. Greg L (my talk) 19:42, 1 February 2008 (UTC)
thread_title: Making a case for why narrow gaps are already well-accepted on Wikipedia

message: In “Continuing Discussion” below, Tony asked whether MOSNUM policy regarding the use of this template/parser function should be “framed as mandatory or optional”, my suggestion would be a formal policy as follows:
::
::Per current MOSNUM policy, numeric values must  have the integer portions of their significand (the digits to the left of the decimal marker) delimited with commas and the decimal marker must be a full stop (.), e.g. 1,234.567. Further now, the use of the  template/parser function (magic word) is “encouraged” and is the “preferred” method for delimiting numeric strings with five or more digits in the fractional portion of the significand (the digits to the right of the decimal marker). The use of  delimits values like 6.022461342 so they have the following appearance: 6.022461342 (making them easier to parse) and simultaneously retains their functionality as Excel-pasteable numeric values.In furtherance of this policy, the fractional portion of significands may no longer be delimited using either spaces or non-breaking spaces (e.g. coding 0.187 985 755< or 0.187 985 755 to produce 0.187 985 755) because such text strings can break at line-end word wraps and/or are not treated as numeric values when pasted into Excel. Values such as these should be irreversibly “upgraded” via use of . “Irreversibly” means that it is impermissible to convert a value that is delimited with  to a simple, non-delimited numeric string.Further, numeric equivalencies that can wrap between the value and its unit symbol (e.g. 75.2 kg), as well as numeric values expressed in scientific notation (e.g. 15.25 × 106) that were neither created with the  template nor unified with a non-breaking space and can therefore wrap on either side of its times symbol (×), should be “upgraded” via either 1) the use of non-breaking spaces, 2) use of the  template, or 3) use of —exclusively so if the value has 5+ fractional-side digits.
::
The effect of this is that new editors who don’t know of the template/parser function or how to use it wouldn’t be doing anything “wrong” when they write “3,210.123456”. Existing, hand-entered values like this, which meet the proposed MOSNUM policy, would be considered as acceptable (though not ideal) and may be irreversibly upgraded. Articles like Font size, which use the non-Excel-pasteable non-breaking spaces (and also leave dangling single digits) would become “incorrect” and should be irreversibly upgraded.  Greg L (my talk) 07:59, 13 February 2008 (UTC)
thread_title: Proposed policy for adoption

message: I believe broader consensus is required before asking for someone to devote time to coding this. So far as I know, outside Wikipedia, the appearance of number separations may be outlined thus:
*Use comma as decimal separator (rejected in English Wikipedia).
*Use full stop as decimal separator
**No separators in integer or fraction parts
**Comma separators every three places in integer part, none in fraction part
**Space (thin or thick) every three places in both integer and fraction part
**Ad-hoc methods adopted for a particular table or a particular publication
The existing rules in WP:MOS and WP:MOSNUM were chosen from the above options. Since no one uses comma separators in the integer part combined with thin space separators in the fraction part (remember, I'm talking about appearance) the existing rules should not be read to mean that the fraction part is fair game. It would be necessary to gain consensus on both talk pages for the concept of the appearance of thin spaces in the fraction part. --Gerry Ashton (talk) 06:09, 15 February 2008 (UTC)
replies: text: *The section "Making a case for why narrow gaps are already well-accepted on Wikipedia" is an expression of one editors impression of what is tollerated. Assuming the impression is correct, it only shows that both spaces and commas are widely used as separators; it presents no evidence that using commas in the integer part and spaces in the fraction part of the same number, or in the same article, is accepted as good style.I oppose this proposal on the grounds that it is a bastard. --Gerry Ashton (talk) 17:39, 15 February 2008 (UTC)
replies: text: * OK, that’s fair enough. Greg L (my talk) 20:24, 15 February 2008 (UTC)
replies: text: * If this does get implemented, there is one good point: if consensus were ever established to use the appearance of spaces for both the integer and decimal parts, it would be trivial to modify the template/parser function accordingly, and all the numbers written with that function would instantly take on one of the styles that is recognised outside Wikipedia. In fact, I like the template/parser function fairly well, except for the comma. --Gerry Ashton (talk) 06:03, 16 February 2008 (UTC)
replies: text: * “In fact, I like the template/parser function fairly well, except for the comma.”  I was hoping you’d come around Gerry—if only a bit. No worries, mate. In the Kilogram article, there are a boat-load of numbers delimited using this span-based technique. Yet, out of the entire article, there is only a single value that simultaneously required delimiting on both sides. I’d guess that 95% of the time, other editors will use  for the types of values typically seen in Kilogram. As I stated above, “it will be a rare number where commas (a U.S. style) and narrow spaces (a European/SI style) are juxtaposed within a single value.”  At least on those rare occasions, the value’s left-hand side will conform to the comma-delimited (U.S.) style officially endorsed for use on en-Wikipedia and won’t stand out like a sore thumb. Greg L (my talk) 19:35, 16 February 2008 (UTC)
thread_title: Broader consensus needed

message: Congratulations to all; the proposal was accepted and presented to a developer on 02-15-08 to be made into a parser function. Thanks for your passionate and hard work on this  proposal. As many of you have no doubt noticed, the debates and comments here resulted in my having to go back to the Overview section many many times to modify and/or add bullet points to incorporate your many observations and suggestions.
It might be a bit premature to check-mark this as resolved (and move it to an archive) as technical issues may arise during the developer’s work. Currently, the Overview section serves as a concise central reference source/depository that can be conveniently updated when corrections and additionals are required. I suggest we leave this here and archive it after the parser function is delivered.
In advance, thanks to the anonymous developer(s) quietly volunteering their time in the background to provide us the tools that make our editing life easier.
Greg L (my talk) 05:56, 16 February 2008 (UTC)
thread_title: NOTICE: Accepted and advanced for development